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

[Clay Fenlason]

I'm supportive of the desire to avoid the course/project site
dichotomy, but I don't mind talking about a "simple course site" for
now, for pragmatic reasons.  Part of the point in my mind is to help
people imagine how courses might be different in Sakai 3, and to
facilitate that kind of thinking at first by starting with simple and
familiar terms.  I don't, in fact, think of this "simple course site"
as a deliverable for Sakai 3 so much as a heuristic for rethinking
course support in Sakai 3; a way to synthesize a number of design
issues (and hopefully draw together various projects) to a first
order.

But it should probably still be noted that Sakai 3 has a concept which
is poised to supersede the site type in Sakai 2, for good or ill -
it's the "site template."  The fundamental differences between the
template and the type, as far as I understand them, is that the former
has something more to say about structure, and also that individuals
(or organizational units) can create their own templates. They are not
all institutionally configured, in other words, but I think we can
imagine that the user lexicon will pick up on template names in the
same way that they've picked up on project and course sites.  I
imagine statements like, "Well, for my creative writing course I use
my own template that's kind of halfway between a course and a personal
blog. Would you like me to share it with you?" The first instinct is
to see infinite possibility, but I think expediency and simplicity
will over time leave a relatively small set of standard templates as
cookie cutters of best practices.

That said, this relatively small set will probably start to separate
and harden around families of practice like "Science course with a
lab," or "Professional education cohort" or "Distance Learning."

~Clay

PS Was I supposed to mention groups in there somewhere? Or be helpful?

On Fri, Jul 24, 2009 at 4:35 PM, Ray Davis<ray at media.berkeley.edu> wrote:
> 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
>>>
>
> _______________________________________________
> 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"
>