[DG: Teaching & Learning] Sakai 3 groups, roles, and course sites

[Ray Davis]

I'll inline my own comments as well, but the short version is: I believe 
we're in extreme agreement and that what you're (rightly) reacting to 
are gaps in this email message which you'll find filled in the documents 
at our project quasi-space.

In other words, if you'd sent my message to me, I'd probably have 
written similar comments back to you. :)

On 7/24/09 12:57 PM, Michael Korcuska wrote:
> Comments inline....
> 
> On Jul 24, 2009, at 12:01, Ray Davis wrote:
> 
>> The recently staffed Sakai 3 "Groups" project is tackling a lot: group
>> management, roles, permission mappings, and integration with group
>> memberships in the Real World -- notably the real world memberships of
>> classrooms, tutorial groups, and academic departments. Currently the
>> best place to track and aid our progress is an odd little side-room in
>> the sakai-dev Confluence space:
>>
>> http://confluence.sakaiproject.org/display/SAKDEV/Creating+and+Managing+User+Groups 
>>
>>
>> (I'm certain that this URL will change -- we still need to get a
>> dedicated collaboration space and task-tracking -- but given all the
>> conference discussions and how many of you we'll be bothering over the
>> next few months, I didn't want to wait any longer to send this
>> introduction.)
>>
>> We're starting with a somewhat risky split between a UX effort focused
>> on good basic "group management" and a service development effort that
>> tries to lay a foundation for flexible real-world integrations.
>>
>> In Sakai 3, such integrations won't be _confined_ to "course sites" but
>> they certainly need to _include_ them. To put it more verbosely, two
>> aspects distinguish a course site from other online collaborative spaces:
>>
>> (A) Incorporation of (or integration with) existing academic social
>> structures. This may include basing online access and user roles on
>> things like department position, cohort membership, class enrollments,
>> section assignments, tutorial groups, librarian specialties, and so on.
>> We know that some installations will mimic these associations by
>> entering all the data by hand, others will fill them in automatically
>> from campus systems, and still others will let end-users themselves
>> decide how and when to create Sakai workspaces from those systems. But
>> no matter which approach is taken, at the end of the process,
>> participants consider themselves in the context of a real-world academic
>> community.
> 
> You've thought about this a lot more than I have, but I'm not sure that 
> this as a distinguishing aspect of course sites.

A big reason we wanted to send a Project-In-Progress alert to the 
sakai-dev and Teaching & Learning groups ASAP is that members of both 
lists have started to define "course site" support in Sakai 3. I dislike 
that terminology myself (for the reasons you mention below), and in the 
project team and in interviews with target users I'm trying to use terms 
like "collaborative space" or "workspace" instead. But in this case I 
wanted to make people who are working on what *they* call "course sites" 
in Sakai 3 aware that we're working on the social-integration aspects of 
those "course site" things. Otherwise, we might lose the opportunity to 
meet real needs together and gain opportunities for misunderstanding and 
duplication of labor.

> There are sites of 
> various types that could benefit from provisioning and role assignment 
> based on existing academic social structures.  I *think* we should be 
> dealing with the management of group (and subgroup) membership as 
> separate from the purpose of that group existing. I want to create a 
> group. That's just a list of people or other groups and, perhaps, a rule 
> about how long that group will persist (or some such). That membership 
> and the persistence of that group can be managed manually by the group 
> owner (me), provisioned by an external system, created from a rule 
> inside Sakai itself (everyone who has accessed a particular resource?) 
> or some combination. I don't see where we need or want to do anything 
> course specific at this level.

The workspace name, persistence, and memberships will be 
course-specific, so you must mean you don't need anything *else* to be 
course-specific. And yes, that was my point. If I say I want an online 
space for my chess club, what I get is "a chess club site"; if I say I 
want an online space for my English composition course, what I get is "a 
   course site." Note, though, that I haven't said anything yet about 
students being treated as second-class citizens in that site, or 
anything about grades or assignments. So far it's just a collaborative 
workspace for a real-world community called "a course."

Sakai 2 has poor support for this type of "course site" because it ties 
default notions of roles and permissions too rigidly to an external 
source of memberships. One of our principal goals for Sakai 3 is to 
break that assumption apart, so that we can *refer* to and *draw* from 
the communities that exist in a university or college, but do so without 
*restricting* how those communities work together online.

> Of course as you give group members access to a site they need to have 
> roles/permissions assigned. Here there are sets of 
> traditional/conventional roles where the concept of a "course" does have 
> meaning and can really help. Knowing that the site I'm giving my users 
> access to is associated with a course will help a great deal in 
> assigning roles/permissions.  And the situation of creating a group and 
> site for a course is going to be very common. So the interface will need 
> to make this simple and straightforward and, perhaps, bypass many of the 
> complexities that are likely to be available.
> 
> Again, you've thought about this more than I have.
> 
>>
>> (B) Specifically pedagogical functionality: assignments, grading, use of
>> mentor-like roles, and so on.
>>
>> Either of these can make an online collaborative area seem more like "a
>> course" than like (say) "a wiki which happens to include some students
>> and instructors." If successful, our project will (among other things)
>> directly support the first aspect and help to support the second.
> 
> Agreed.
> 
> One of my goals, maybe not shared by others, is to begin to lessen the 
> distinction between site types in the minds of users. There is a good 
> deal of "I can't use a project site for a course" or "It's a project 
> site, I can't have a gradebook in that" thinking that I encounter with 
> folks who are new to Sakai.
> 
> I'm almost of the mind that we shouldn't use terms like "course site" 
> and "project site" at all.  Rather, you have a site that has certain 
> capabilities.  So instead of saying "is it a course site" we would say 
> "have you added the standard course capabilities" to your site? I do 
> think how we talk about these things matters, at least a little, as 
> we're designing Sakai 3. I even suggested we lose the term "site" in 
> favor of "space" in order to emphasize we are making something that 
> *could* work quite differently.  I'd be interested in other people's 
> thoughts.

My own are entirely supportive. I'd like to avoid the heavy historical 
baggage of the "course site"/"project site" dichotomy except when 
referring specifically to Sakai 2 capabilities that need to be carried 
forward. Again, though, there actually was a "Course Sites" BOF at the 
conference and there actually is a "Simple Course Site" effort underway 
at present, and so I felt compelled to use the term in this message.

Thanks,
Ray

> 
>> Obviously, though, it can't be successful without a massive amount of
>> assistance. Please keep us in mind as you bump into related issues,
>> enabling technology, and good role models, and please don't be startled
>> when we come begging for favors.  :)
>>
>> Best,
>> Ray
>>
>> _______________________________________________
>> pedagogy mailing list
>> pedagogy at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/pedagogy
>>