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

Ray Davis ray at media.berkeley.edu
Thu Jul 30 16:29:18 PDT 2009


Thanks, Robin. We've talked about these issues but they haven't been 
called out much in our documentation yet, and so I just added a section 
on "Including visibility rules from external sources" to the Big Book of 
Hard Problems:

http://confluence.sakaiproject.org/display/SAKDEV/Federated+Authorization+Use+Cases

Please take a look and correct anything that seems off.

The main reason for our reticence so far is that personal information 
(user profiles, user data, user directory attributes, etc.) and how it 
gets passed around, displayed, and customized seems to properly belong 
to a different project. Obviously there's a lot of overlap between 
personal profile management and group membership, but equally obviously 
they tend to be handled in different workflows, different areas of the 
display, different services... If this particular small project team 
tries to take on too much of the universe at once, we don't stand a 
chance of success. We'd like to collaborate with some other small 
project team who can be the expert in that other-but-related space.

Another example of an overlapping-but-different small project is how to 
make it easy to integrate Sakai 3 with any of the many log-in / 
authentication / ID systems that we use. (This is a pretty specialized 
area of technology in which I confess I always feel out of my depth.) I 
covered some of Sakai's past history on all this at:
http://confluence.sakaiproject.org/display/SAKDEV/Sakai+2+integration+issues
Of the three big Sakai 2 integration points described there, I hope our 
team will be able to stay somewhat focused on the third, which also 
happens to be where we've had the most experience. But since I don't 
personally control any employees or large sums of money, this has to be 
taken as wishful speculation. :)

Best,
Ray

On 7/29/09 10:23 AM, Robin E. H. Ove wrote:
> Hello all,
> Let me just say I am new to this up front. This has been a very 
> thoughtful discussion and I have begun reviewing the confluence docs. 
> Thank you so much for this project! One issue I seem to be missing 
> information are current thoughts in handling the FERPA needs of students 
> who have officially requested non-disclosure of information via the 
> Registrar and how it is maintained globally throughout the Sakai 3 
> toolset, perhap via role mapping. I get a sense that with the new user 
> functionality to set privacy settings will cover much of this, but with 
> the the larger impact of 'external' membership and external social 
> networking hosts how will we ensure those student's privacy?  It is 
> common for users of social networking software to be unaware of how to 
> effectively manage their own privacy settings, so what can we do to 
> limit risk in the environments we institutionally control?
> 
> Thank you for the community participation!
> - Robin Ove
> UC Santa Cruz
> At 8:03 AM -0400 7/29/09, John Leasia wrote:
>> 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 
>>>> <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.
>>>>    
>>>
>>>
>> 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 
>>>> <mailto:pedagogy at collab.sakaiproject.org>
>>>> http://collab.sakaiproject.org/mailman/listinfo/pedagogy
>>>>
>>>> TO UNSUBSCRIBE: send email to 
>>>> pedagogy-unsubscribe at collab.sakaiproject.org 
>>>> <mailto:pedagogy-unsubscribe at collab.sakaiproject.org>
>>>>  with a subject of "unsubscribe"
>>>>    
>>>
>>>  
>>
>> _______________________________________________
>> 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"
> 
> 
> -- 
> 
> Robin E. H. Ove, Sr. Manager
> ITS Instructional Technology Group
> Instructional Support and Media Development
> Faculty Instructional Technology Center
> ------------------------------------------------
> University of California, Santa Cruz
> MS: ITS East Communications
> 1156 High St.
> Santa Cruz, CA 95064
> 831-459-2436
> http://ic.ucsc.edu
=


More information about the pedagogy mailing list