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

[John Leasia]

One comment way below...

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. 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.
>
>  
>
jl> I agree the distinction between course and project sites produces at 
times artificial boundaries that don't need to be there. But it has 
helped, here anyway, distinguish what one can do in one site type vs 
another. Here, the desire was to make course sites (sites representing 
official courses for which you registered for and paid money to take, 
representing the U, etc. etc.) somewhat consistent. So students wouldn't 
wonder where Resources were in one site vs another where the instructor 
decided to call one Class Notes and another References or whatever. So 
we have limits on what an instructor can change in a course site w/r to 
order of tools, which tools etc. Project sites are more customizable - 
the owner can do what they want. It is convenient to be able to speak 
about different types of sites, and perhaps even have some control over 
various aspects of one type of site over another.

Ok, we do have more and more project sites being used for some type of 
course work, and there no longer is much distinction between which tools 
you can add to either site. But the 'official' course site is of a form 
that is consistent between any course.

I do agree that a site is a site - that's how Sakai 2 is after all, just 
all sites that have metadata  causing them to be treated differently - 
but we loose some flexibility in not having the ability to categorize 
sites or spaces or containers or whatever they are. I would think 3 
should be flexible enough to allow some artificial categorization of 
sites or not depending on the institution's needs. Maybe this is part of 
templating, and configurations in the template provide some control over 
how a space created from the template can be modified..

>>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"
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/pedagogy/attachments/20090729/3ea74d4a/attachment.html