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

[Michael Korcuska]

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. 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.

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.

> 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
>
> TO UNSUBSCRIBE: send email to pedagogy-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"

-- 
Michael Korcuska
Executive Director, Sakai Foundation
mkorcuska at sakaifoundation.org
phone: +1 510-931-6559
mobile (US): +1 510-599-2586
skype: mkorcuska