Mostly group management

Owned by Former user (Deleted)
Last updated: Sept 09, 2009Version comment
12 min read

1. Basic community features

To make more room for the Hard Problems, I won't bother to detail the many use cases which fit now well-established collaborative paradigms. Here are a few sample activities:

  • Create a personal workspace with a digital repository, some public documents, and an blog on which any registered user can comment.
  • Create a publicly accessible interest group. Joining the group gives shared access to a workspace including a discussion board, notifications, announcements, a calendar, and a wiki. The group can be dropped at any time.
  • Create a by-invitation-only research project site including archived messages, chat room events, and video clips.
  • Form personal contact lists from known users.
  • Send a message to people who've indicated on their calendar that they're attending a certain event.
  • See which public groups a person belongs to.

2. Memberships from external systems

Hierarchical memberships and contextual roles derived from a course management interface

American universities typically derive information about classes, enrollment statuses, instructor assignments, and so forth from an SIS department. Other externally managed "enterprise" data might include course descriptions, department organizations, cohort memberships, tutorial groups, and lab or discussion sections and leaders. Currently in Sakai, the Course Management API is the most generic interface to such externally managed data. The upcoming IMS LIS standard targets the same functionality, and should find wider use among clients (e.g., Moodle and Blackboard as well as Sakai) and implementations (e.g., out-of-the-box integrations from PeopleSoft and through LDAP attributes).

The canonical LMS/CLE use case is that the instructors, students, and other people officially related to a course want a multi-purpose online workspace that automatically includes all the course members that SIS knows about and maps official roles to online application permissions in a consistent and natural way. The workspace may also include (or be restricted to) officially maintained subgroups of the course (such as lecture sections, scheduled labs, or discussion groups). It should be possible to address the subgroups separately and to give them special access to particular areas or resources. (Oliver Heyer)

Memberships and roles derived from Shibboleth attributes

On the discretion of the authenticating system, Shibboleth can pass attributes about a logged-in user along to the client system. The client system can then translate these attributes into a local group membership or role. As with LDAP queries, to maximize usefulness, the attributes will probably be as standardized as possible (e.g., based on EduPerson).

For example, QMShibb can be configured to map a Shibboleth-provided list of groups to group membership in an online assessment system. For another example, a Drupal installation can map a Shibboleth attribute to a list of Drupal roles. (E.g., "If the attribute HTTP_SHIB_EP_AFFILIATION matches 'student@mit.edu', give the user the roles 'authenticated user, student user'.")

In this case, an external source of memberships can be specified without the membership list being readable. For example, someone at the University of Leeds might set up a website which will automatically be accessible by anyone certified by Shibboleth as a member of the "bioinformatics" group at the University of Manchester. But that doesn't give anyone at Leeds a way to view the full set of Manchester students who might fall into that category. (Andrew G. Booth, Paul B. Hill, Steve Swinsburg)

Hierarchical memberships derived from LDAP queries

Oxford University uses LDAP as a central source of membership lists, such as "all first year students studing Medieval English" and "all staff in Exeter College" or even the intersection between the queries. The source groups are pure membership lists (with no intrinsic role mappings, for example). These query-based groups are used as sources of installation-wide group memberships or workspace memberships. Additional members can be added to these linked but internally-managed groups, and named sub-groups can draw from them. A person should no longer appear in internally-managed groups or sub-groups when the person disappears from their source LDAP-query.

There is a natural hierarchy to many of these lists, such that each college within the university might have a top-level workspace (accessible to all members of the college) and each tutorial group within the college might have a sub-area, while each academic department might have their own top-level workspace with lectures and seminars as sub-areas. An individual workspace might exist in multiple hierarchical positions (e.g., a Latin tutorial workspace might be found either from a college or from a department). Memberships and roles within a workspace might be inherited from a "parent site" regardless of hierarchical positions – in effect, treating an existing workspace within the LMS as an "external" authorization source. (Matthew Buckett, Adam Marshall)

Maintaining links to sources

Sources of memberships and roles generally have more to them than a bare list of user identifiers. It may be important to preserve access to them even aside from their status as feeds.

For example, during much of a term, the most important aspect of a student's enrollment in a class might just be that the same person shows up in the course's online workspace as a "student". When it comes time to submit final grades, however, the integration may need to check on enrollment properties such as pass/fail selection or the elected amount of credit.

As another example, a tutorial section's leader and meeting times may need to be maintained along with memberships.

Knowledge of the original source can also be important when negotiating conflicts between external systems, as described below. (Oliver Heyer)

Changes to available source groups

In August, an instructor creates a workspace for Fall 2008 Chem 1a, integrating its memberships and roles to memberships and roles associated with the class's two lecture sections, five lab sections, and two discussion sections. In September, the chemistry department realizes that there are only enough Chem 1a enrollments to fill four lab sections, so they cancel the fifth. "Chem 1a Fall 2008 Lab 005" then disappears from the course management system. At the end of September, the instructor goes to check section memberships in the course workspace. This should not fail because of the "missing" lab. Either the integration should gracefully handle the concept of "all existing sections, dynamically determined" or the instructor should be notified that the source section no longer exists and be given the chance to remove that link. (Oliver Heyer)

Modifying derived memberships

The link between online memberships and externally-defined memberships is not equivalence. We may want to give online memberships to people who do not officially (or do not yet officially) play a role according to SIS. That means reconciling multiple sources of membership changes. For example, an instructor wants to let officially enrolled students automatically gain access to her class workspace, but doesn't want to punish students who are still working their way through SIS official channels, and also doesn't want to have to monitor the status of every "early" student separately. Workspace membership therefore needs to be based on a combination of external integration and internal intervention. (In a local integration, we automatically converted "manual" memberships to "externally provided" memberships when they first showed up in the feed. In Sakai 2.* course site management, "manual" memberships stay manual. In Sakai 2.* section management, section memberships are either all-external or all-manual, but can be switched from one type to the other.) (Oliver Heyer)

We will also want to be able to create and manage new subsets of a membership list, while maintaining a dependent link from the source memberships to external systems. (That is, if a student drops the course, that student no longer appears as an active member of our inside-the-workspace "Third Week Research Project" team.) A few special examples follow.

Including visibility rules from external sources

Students may have officially requested non-disclosure of certain information in the systems with which we integrate. The legal requirements of FERPA frequently come up in the United States; typically this might include a rule that official instructors of the class are the only participants who can see certain information about an enrolled student. (Hospitals attached to medical schools may have a different set of stringent requirements set through HIPAA.) Similarly, when integrating with social networking groups, already existing privacy settings should be respected when available. Clearly this requirement overlaps heavily with profile management, but there is at least some piece that involves group-and-role integration. (Robin Ove, Diana Lee Perpich)

3. Managing subgroups of external members

Space-limited student sign-up

Each year, about 100 medical students sign up for elective projects (with associated online workspaces) with a supervisor. Each supervisor can only work with 4 students at most. Some supervisors and topics are much more in demand than others, and so competition can be fierce.

A lecture course with a typical enrollment of more than a thousand students is associated with fifty tutorial groups, each with their own meeting times, leaders, and mailing list. Again, it's important for enrolled students to be able to compete fairly for spots in their most desired group. (Stephen Marquard)

Randomized grading groups

The Instructor of a 100-student lecture class has 3 TAs who grade all assignments. Each student must complete all of the same assignments. The Instructor divides the class into 3 groups for each assignment, each group comprising different, randomly chosen members. (Motives might include breaking up TA-student connections, encouraging a demographic balance, or simple convenience.) Each group is assigned a TA who is responsible for grading the associated assignment. (Oliver Heyer, David Horwitz)

The remaining pedagogical use cases are all slavishly copied from Clay Fenlason's list of Georgia Tech Group and Course Requirements.

  • "Capstone" experiences extend across 1 or 2 semesters with groups of varying size, but typically around 4-5. These students will produce project deliverables of varying types (written and oral reports, software solutions, peer ratings, etc) as they move through different stages of the design and often work with customers external to the university.
  • Problem-based learning: Several problems during a term are introduced to students who then may work in teams of 3-5 and need to pull together information from a variety of resources in order to fully address the problem. Student presentations of their work on the problems may be included.
  • Group notetakers: Rotating student groups of up to 10 or so students take notes for a single course and produce editable public versions of those notes for the rest of the class.
  • Video research projects: Teams of students from a single course perform a technical research project and document solutions via the production of a video.
  • Distributed teaming for engineering design: Students from multiple campuses collaborate on teams for the purpose of creating design solutions to complex problems. Teams typically confined within one term but may be enrolled in multiple courses.
  • Paired problem solution presentations: Students choose or are assigned a partner to work with on daily or weekly problem sets. One of these pairs is then randomly selected to present their attempt at a solution for one of the problems from the recently assigned set. The class discusses the problem.
  • Vertically integrated project teams: These support large scale, complex, multi-year projects in engineering with perhaps a dozen students from sophomore through graduate level and from a variety of majors. A single student may participate in the project for 1 or more years but students enter and leave the team each term. External stakeholders may have significant roles to play.
  • "Jigsaw": Students work in small groups to develop knowledge/expertise about a given topic and to determine effective ways of teaching this knowledge to others. These "expert groups" then break up and move to new "jigsaw groups." ( Each jigsaw group now consists of students who have developed expertise in different subtopics.) Each "expert" in the jigsaw group then assumes the role of teacher and instructs the other members of the jigsaw group about the subtopic.
  • "Test-Taking Teams": Students work in teams to prepare for exams and then take the exam first individually and next as a group.
    This collaborative learning process involves three steps: (1) the group studies for the exam together; (2) individuals take the exam; and (3) the group takes the exam (students rejoin their groups to reach a consensus on the answers and submit a group response to the test). Rationale: By working together to prepare for the exam, students help each other understand the content. Because each student first takes the test independently, this process emphasizes individual accountability. By retaking the test as a team, individual students benefit from the collective knowledge of the group. This technique is used for both short quizzes and tests for covering larger amounts of material--and since the group score is usually better than the individual scores, the technique is often used to demonstrate the value of collaborative learning. Individual grades are determined by using both individual test grades and group test grades. Scores are weighted (for example, two-thirds for individual plus one-third for group).
  • "Feedback Teams" (Peer-Review, Peer Editing): Students critically review peer work (either in pairs or small groups) and provide feedback on each other's essays, reports, research papers. or projects. This works best when students are given guidance on what to look for (rubrics) and guidance on how to make constructive suggestions. Once feedback is exchanged, students take feedback into consideration and revise/prepare their final product. Typically students include their peer review forms when they submit their completed product to the instructor for evaluation.

4. Federating membership sources

Merging external memberships

We frequently need to create project-oriented, subject-matter-oriented, departmental, or cross-listed workspaces whose memberships are drawn from multiple courses or multiple campuses. Naturally, however, we can't accidentally let a teaching assistent in a lecture class grade herself in a seminar. For this and other reasons, it's important to preserve backward links to the original information sources, and to define clear ways to reconcile role-mapping conflicts. (Oliver Heyer)

Merging from multiple external authorities

A CLE may draw both on SIS-controlled course management data and on personnel or other data.

For example, along with the usual course sites and project sites, I may want to grant special access to departmental administrators or to set up an alumni workspace. These external systems are frequently administered by different external bodies and use different role and group vocabularies. Mapping needs to be configured as part of any integration.

Also, in a large university, sources of membership for a single person often overlap. (E.g., a university museum curator might also teach a course, or a staff member in the multimedia department might be a graduate student.) Again, reconciliation methods are needed.

Large multi-campus universities or universities which include the option of study abroad may need collaborative spaces which combine memberships from different identity management or course management systems.

Finally, when searching for contacts, I might want to combine criteria from different integration sources ("undergraduates" vs. "staff"; "English tutors" vs. "Chemistry tutors"). (Kirk Alexander. Oliver Heyer)

Cohort spaces with course-specific areas

Boston University hosts student Teams which span courses and sites. Each Team coordinates on a long-term project and attends courses as a Team. Group grades are factored into individual grades. In MBA and some other programs, a similar long-lived student grouping is called a Cohort, and the Cohorts are enrolled in course offerings as a unit.

Ideally in such an arrangement, the following site hierarchy would be supported: A primary site would operate as the Team or Cohort collaboration space, and administered by a special coordinator not necessarily represented by enterprise data. Sub-sites would be course sites governed by individual instructors and registrar data. The course sites tend to be peripheral to the students' collaborative work. (Clay Fenlason)

Freshman advising groups

Incoming pre-med students for the upcoming term are given a social networking space in which to begin interacting with each other and their advisors. As they officially enter the university, they continue to be able to use the community space to set up schedules, connect with fellow students, and participate in informal advice forums. (Lucy Appert)

Supervising students across courses

At Cambridge University, supervisors are graduate students who have been assigned a group of students. In some cases, the supervisor may supervise the students across quite a few different courses; in other cases, the supervisor sticks to just a course or two. The balance varies by discipline and by supervisor. Inside a course context, a supervisor sees the enrolled students who are assigned to her. (Laura James)

Shared educational resources

An instructor who is going to teach the next semester of Calculus 101 automatically has access to the workspace and resources associated with the "canonical course" of Calculus 101 across all semesters. Within the workspace associated with that semester, the instructor can either link directly to the cross-semester resources or make local revisions. (Stephen Marquard)

Access to previous work

A student who took Freshman Comp three years ago refers back to that class's associated workspace, including their own contributions. (Stephen Marquard)

Alternatively, students create and manage their own project sites and portfolios, linking to (and storing) course-related or project-related material across multiple courses, working groups, and applications, with easy access to and from the original context. (Adam Marshall, Stephen Marquard)

Program goals and course activities

Program goals (viewed at a discipline-level context that may cut across multiple departments) link into course activities (mostly defined and met in course-specific contexts). A program coordinator can view the goals and ratings published by course instructors but can't necessarily change them. A course instructor can link course activities to program goals and ratings, but doesn't necessarily get to see goals and ratings published from other courses. (Sean Keesler)

Grouping by previous enrollments

An instructor wants to compare the final grades of students who took a prerequisite course with students who didn't.