Group Management Project Glossary

It's just semantics but having a common language will go a long way in effectively gaining a shared understanding of the problem space and project.
Please add any terms relevant to the project. If you know synonyms used at other locations capture that too along with where it's used.

Collaboration space: An online set of resources and applications which multiple people use to communicate, collaborate and share information. The space may enable a variety of communication methods (email, discussion, etc.) and sharing of documents and other information.
Community: A group of people who share a common interest, residence, occupation, workplace, etc. A clear distinction is notoriously difficult, but most people probably think of a "community" as being larger than just a "group", and when we select a "team" (or some other set of people) it's generally from some communal context.
Course Cohort: An externally defined group whose manager is an instructor of record, and which may comprise other externally-defined groups as sections. Course Cohorts generally have additional data or restrictions demanded by the SIS. (from: http://groups.google.com/group/sakai-kernel/web/georgia-tech-group-requirements)
- Also referred to as: Lecture, Course, Class, Primary Section
Course Site: Two aspects distinguish a course site from other online collaborative spaces: (A) Incorporation of (or integration with) existing academic social structures, often basing online access rights and user roles on things like department position, cohort membership, class enrollments, section assignments, tutorial groups, librarian specialties, and so on. (B) Domain-specific functionality: assignments, grading, use of mentor-like roles, and so on.
Grader: Someone responsible for grading assignments and/or entering grades into the system for a group of students (entire class, section, subset of either). They may or may not also be a TA.
Group: A collection of people, groups, or some combination of the two. Groups may persist or be dynamic. Dynamic groups may be constructed ad hoc by some query, generated by either the system or some user action, and are transient. (from: http://groups.google.com/group/sakai-kernel/web/georgia-tech-group-requirements)
Instructor: Teacher of a course.
- Also referred to as: Faculty, lecturer, ...
Parent Group: The group whose membership a subgroup is drawn from. A subgroup can sometimes be a parent to smaller subgroups.
Permission: See Roles and permissions.
Provisioned: Data provided from 3rd party party application. Most common in regards to groups is Student Information Systems (SIS) & LDAP. We also want to think about provisioning group members from web apps like facebook, google docs, email clients... (uPortal refers to an external source of groups as a component service; Crowd calls it a directory connector.)
Relationship: In a personal context such as an online portfolio or an OpenSocial-style site, I have relationships with people ("Mentors", "Collaborators", "Friends", "Family"). A person's relationship to me determines what they can see and what they can do with material associated with me. In other words, relationship modifies an individual's contacts in the same way that a role modifies a group membership. When viewed from the outside, it looks like a role of a group named after an individual: "Chem 1a's Students" and "Daphne's Friends". As with roles, once we're inside the social context, the proper noun disappears: in the Chem 1a classroom, we just think of "the students"; on my Facebook page, I just think of "my friends."
Role: A role indicates a person's tasks, responsibilities, qualifications, or expectations in some context. It may be associated with a collection of software privileges or permissions. It may determine an application's UX (e.g., the blog presents different workflows to the the owner and the commenter). It may also be used to map between disparate social contexts (e.g., externally-managed classes and sections with roles like "Instructor of Record", "Enrolled Student", and "Teaching Assistant" might feed internal workspace memberships and roles).
Scenario: Stories about users activities as they happen in context and relate to other activities. They define the way a user needs to complete an activity or string of activities. They may include what information users already know and need to know, what mental models and expectations they already have in the space and how their context affects the way they get work done (e.g. frequent interruptions tell us the system needs to help users keeps track of where they are in a process). Another way to think about them in regards to use cases is as specific instance of *likely* several use cases as they are linked together to get work done.
Section: A real-world subgroup for a course. In some universities, courses can be split into several large lecture sections each term, with smaller subgroups meeting in discussion, lab, or studio sections. At UC Berkeley, official student enrollments and final grades are tied to lecture sections (which are thus called "primary sections"), but practices and terminology vary widely across institutions. See Course and Site Structure Patterns for examples and details.
Subgroup: Subset of members drawn from a larger parent group. Some scenarios include a requirement that each group member belong to one-and-only-one subgroup of a certain type, or a need to find members who don't belong to any subgroups.
Subject Coordinator: [SAKDEV:CSUs requirements]?
Subsite: Site that has a hierarchical relationship with another site. Sections or student groups might have subsites of the course site.
TA: Teaching Assistant. Someone assisting in the teaching of class. They may help the instructor with a large lecture class or be responsible for one of more lab, discussion or other type of sections.
- Also referred to as: GSI,
Use Case: Short, high-level functional description of requirements. It should have at minimum a Verb + Noun and can include a subject or context if critical to understanding. A good rule of thumb is to keep their titles 5 words or less. A full blown use case describes the steps the user will go through to complete the use case.