Request for comments - read if you're a module developer!

Request for comments - read if you're a module developer!

by Juliette Culver -
Number of replies: 24
As some of you know, I've been doing some work on groups in Moodle that with a bit of luck might make it into 1.8.

This work will necessarily involve a change to that API that modules use in order to support groups. The old functions will be still supported but in an extremely limited way. Later on, I'll be looking for volunteers to either do the work for specific modules or to check the changes that I make smile

We obviously don't want to change this API more than once if we can help it, so I'm throwing myself to the lions posting some documentation and a copy of the API on the wiki so you can have a look at it now and get back to me here if you have any comments or questions.  Suggestions for improvements to either the API or the documentation are also very welcome and do let me know if there's something important that I've overlooked.

Here are the docs and here is a copy of the API.

One issue is whether modules should be forced to 'declare' whether they support groups - there could be three options: no support, legacy support, and full support. It would then be possible not to let a grouping be specified for an activity if it's not appropriate.
Average of ratings: Useful (1)
In reply to Juliette Culver

Re: Request for comments - read if you're a module developer!

by N Hansen -
I've read what is in the docs, and while I can see a couple new features here and there, honestly overall, this is written in a way that makes little sense. There is no clear definition of what a grouping is and the use of the present tense to refer to future development is confusing, especially since what you describe in present tense to refer to the future sounds almost exactly like the way groups work now. I think you need to clearly state how this new system WILL BE different from the way it is now and use the appropriate tense to refer to things.

 I also am concerned with the idea of "letting roles settle" and then integrating groups further with roles. If as you say you only want to change things once, then it seems prudent to wait on this until a clearer picture of roles emerge.  Also, I would be concerned that if you don't coordinate the two closely you will wind up creating group-role combinations that don't work as one might expect them to work.
In reply to N Hansen

Re: Request for comments - read if you're a module developer!

by Juliette Culver -
Sorry I've deliberately written everything in the present tense so that the docs won't need to be changed later. I'm sure you can cope smile I'll make it clear however, and a section on the differences is probably a good idea though. I'll add one in.

To be honest, I just don't have time to change everything I've done to fit in with roles at the moment particular as the code for that isn't stable yet. What I've doen is actually going to make integrating with roles and permissions easier rather than harder than it currently would be and you can't currently set roles for groups so the issue of group-role combinations that don't work as you expect isn't going to come up. If somebody else wants to take what I've done, extend roles and permissions to cope with groups and integrate everything beautifully then I have no objections smile To be honest, I can't see roles-groups integration coming for a fair time because it's quite a minefield. It certainly won't ever happen unless some improvements are made to groups first, believe me.
In reply to N Hansen

Re: Request for comments - read if you're a module developer!

by Juliette Culver -
I've tweaked the explanation of groupings a bit - is it any clearer now? If not, please can you let me know exactly which bits aren't clear and what precisely is confusing you? I genuinely do want to make it as clear as possible, but I've spent so long thinking about groups that it's really hard to see this from an outsider's perspective any longer! I do think that the stuff I'm doing with groups is basically 'right' though and much needed, but if people think there's a better way of doing things or want to write an alternative API, then I'm more than happy to listen to them or take a look smile
In reply to Juliette Culver

Re: Request for comments - read if you're a module developer!

by N Hansen -
Tell me if the below example is a good understanding of this. You can have a grouping (I'll call it alpha) that consists of groups A and B. You can have a grouping (I'll call it beta) that consists of groups C and D.

Students assigned to the groups are as follows:

A
student 1 and 2
B
student 3 and 4
C
student 1 and 3
D
student 2 and 4

You can apply grouping alpha to one activity, and grouping beta to another. This allows you to divide up the groups of students differently depending on the activity.

Is that correct?

Now, I think you mentioned something about certain activities not being visible at all. Can you say something more about that?
In reply to N Hansen

Re: Request for comments - read if you're a module developer!

by Joan Codina Filba -
Some doubts and requests...
  1. A student can be only once in a grouping?
  2. There is the possibility of auto-enrollment to activities, with a limit per group? Or what is similar, can an activity be assigned only to a group? and with which visibility rules.
  3. There is the possibility to have a a hierarchy of groups?  For example for a course there are two teachers that tutor half of the students each, but then they can subdivide the group in different ways for different activities
In reply to Joan Codina Filba

Re: Request for comments - read if you're a module developer!

by Juliette Culver -
I meant this to be a discussion of the API but I should have realised that you can't bring this sort of thing up without answering more general questions smile

1. A student can belong to more than one group in a grouping.

2. Depends what you mean by auto-enrollment. I haven't implemented sign-up sheets yet, but the new interface allows students to be assigned randomly to groups (either with the number of students per group or number of groups specified). Activities are assigned to groupings not to groups. The visibility depends on the permission settings for the grouping.

3. The case you give is possible to do by creating appropriate groupings but the editting teacher would need to create them rather than the two tutors. I'm planning a nice 'merge groups' interface at some point in the future automatically and there's also an interesting issue of who has permission to create and modify groupings with which users, but I want to concentrate on getting the basic infrastructure right at the moment.
In reply to N Hansen

Re: Request for comments - read if you're a module developer!

by Juliette Culver -
That's correct. I'll put an examples in the docs at some point when I have a bit more time.

The activities not being visible isn't something that you need to worry about as a module developer. It's basically making groups behave as people expect them to - if a set of groups is assigned to an activity then if a student isn't in any of those groups they don't see that activity. This isn't the case with the way groups work in 1.6 and that confused lots of people.

Is there a particular module that you work on by the way?
In reply to Juliette Culver

Re: Request for comments - read if you're a module developer!

by Dan Stowell -
I find "N" is never afraid of being critical! tongueout Often very helpful in answering others' queries though.

Juliette: In your first code example (in the "groups documentation for devs"), if a given student is in multiple groups and they haven't yet specified which group they're "in" for the purposes of their current pageview, what value will
groups_m_get_selected_group()
return? An arbitrarily-chosen one of the user's groups? False? (I'd guess and recommend that it should be the latter.) It would be worth mentioning this case in the examples.

I've nothing deeper to add, since I'm pretty much overwhelmed by the roles/xmldb/groups changes and very short on brain capacity at the moment...
In reply to Dan Stowell

Re: Request for comments - read if you're a module developer!

by Juliette Culver -
Don't worry, I know about her reputation smile Still not the sort of response that encourages you to spend your weekends on improving the Moodle code though!

In answer to your question, yes, it will return false. Thought I'd put that in the PHPDocs at least - will go and make sure it's there.

I've been thinking a bit more about how to get roles and groups integrated (have written about this in my blog here if anyone's interested). I think it will definitely need at least a few changes to the existing roles code which is something I don't want to even start to contemplate until it's relatively stable, and it won't be trivial. It'd definitely be nice to just get modules to change their code once, but I'm not sure how realistic it is. I'll think about it some more once I'm a bit more familiar with the roles and permissions code. It might still be possible to integrate the permission functions sensibly.
In reply to Juliette Culver

Re: Request for comments - read if you're a module developer!

by Enrique Castro -
Picture of Core developers Picture of Particularly helpful Moodlers
I strongly miss to thing in the docs and API

a) there is NO description of what a grouping or set of groups is, what is for
The concept must be explained in detail, since it is the core of the  possible functionality. Please, tell  me if I'm  wrong in the following description/explanation (I'm more a teacher than a developer).

A grouping is a way to organize groups, is a group of groups, a set of groups. You can distribute the same students in Groups A,B,C..  and in Groups 1, 2, 3, 4. Groups A,B,C constitute Grouping X and groups 1,2,3,4 constitute Grouping Y. Are a way to gather together students differently with different criteria. You can think of Groupings  as the criteria or motives to have students grouped in difefrnet ways.

The important point to remark is that module instances can choose what Groupings they will use. Thus, at the module configuration form the teacher will see the "group mode" option and a "grouping" option that specifies to which set of groups that groupmode applies to.

Groupings can the be used to restrict activity access. Let say you want to create an assignment activity only for the more advanced 25% and the less able 25% of the class. Simply create a new Grouping "Extra" with two groups 'Advanced' and 'Special', all the other students of the class are not members of any of this two groups. Set the assigment to user Grouping Extra and "Separate groups" (or the equivalent under Roles & permissions) et voilá, students that are members of 'advanced' or 'special' can see the activity and submit an assignment, the other people will see the error message "sorry, you need to be member of a group to see this activity"

There are two ways to setup groupings
a) as a set of groups: the teacher creates a lot of groups and afterwards decide to assign one to GroupingA and the other to GroupingB. The existence of the groups is independent of the groupings. A particular group can be assigned to several Groupings.
b) as a scope were the group "lives": Once created a Grouping, groups are created within that Grouping. Groups that belong to a grouping cannot be assigned to other grouping.

There are activities that support multiple group membership. For other activities a given student should be member of just one group. (for instance consider the assignment, example. It doesn't makes sense to receive two submissions from the same student in a single assignment, one as member of group 'advanced' and other as member of group 'special necessities')

Thus it makes sense for Groupings to provide functionality to:
- distribute students between groups of the grouping
- self-assignment of students to a group of the  grouping
- check for multiple membership conflicts

A Grouping should  have settings to define if multiple membership is allowed for students between groups of the grouping  (exclusive single group or multiple membership), to set the maximum number or places in each group of the grouping (for student self-assignment) and a visibility setting to make the Grouping public and usable by modules/students or not, and ever more potential parameters (creating groups within the Grouping by students, not teacher, or at least setting the group profile as editable by students etc,)

In see functions in the API to get groups in use and members and permissions of members of that groups but I do not see in the API anything to manage Goupings themselves, or to specify that a module should use a particular grouping. Without this part of grouping management, the functions listed in your proposed API are more focused on permissions than in exposing the new functional possibilities that Groupings open.

By the way, what I did the last year was to add a "Scopeid" field to the course_modules table. This field set from a new option in the config form mod.html for the modules (I add it to standard  'footer' settings  groupmode and visibility). I created two new tables for Scopes (Groupings) definitions and scopes memberships (which groups were in what scope). And modified all datalib.php group functions to accept a new parameter scope (default to 0, meaning getting all groups disregarding the scope). For instance in a module the config setting stores a "scopeid" parameter. When entering the module view.php script and getting the $cm object you get a $cm->scopeid attribute. Then to manage groups you can call  setup_and_print_groups($course, $groupmode, $urlroot, $scopeid). Changing just half a dozen of lines for each module was enough to adapt it to Grouping/Scopes.

b) there is NO  provision for the concept of a group as a team of students
As a teacher the main fault  I see in Moodle  is the lack of the Team concept: a small group of students that work together in the same activity. The example is the typical assignment to be done by teams of 2-5 students, all of then receiving the same base grade plus some "extra" points to refine assessment with basis in individual contribution to group work.

Moodle concept of groups is more that of cohorts or sections: different classes within the same course. However, in many sites each section has its own moodle "course".  I and others have been using moodle groups to manage small teams of students. These are two completely separate meanings but concepts that can co-exists, even more now in an scenario with multiple groups membership and fine permissions contexts.

I have been thinking about adding to Moodle a new type of user, a Team, not like a group but as a user that can submit assignments, post in forum, answer quizzes. And I think that it introduces more problems than solves. From the beginning: a registered user would need to pass for a an additional login-like step to post as a Team, rather than  as himself, etc.

I would prefer an scenario where some Grouping could be set at course level to define classes or sections of the course. And then other groupings used by individual activities. Some activities can even manage themselves the team concept: treat contributions from a user that is member of a group as a group-contribution. This makes sense for some activities, but not for others. A good example is the wiki module (the old ewiki from Mike Chuchward) when set in group-wiki mode (a separate setting from groupmode, that actually drives to 9 different behaviours for the wiki module). I do have a version of Assignment that allow group-submission and group-assessment: a single member submit and all members appear as submitted, the teacher only sees a file, not  n-replicas of the same file (one for  each member), grade the group and each member gets graded automatically (browse the Assignment forum for ULPGCassigment).

What is important is that this type of usage of groups must be in mind, and acknowledged when designing a library to extend groups functionality in Moodle.

I hope these thinkings would be useful.


In reply to Enrique Castro

Re: Request for comments - read if you're a module developer!

by Juliette Culver -
Thanks for the detailed comments, Enrique. I guess the word 'set' isn't in the everyday usage of non-mathematicians - should have realised! I've got round to putting an example on the wiki now which should help and I think the interface will make everything much clearer. I'd like a better word than grouping - I originally used group set but decided I didn't like it in the end - but haven't been able to think of one.

Your explanation is pretty much spot on. One small difference - once a group has been created in a grouping it can also be assigned to another grouping. The settings you suggest for a grouping will either be there or are things that I'd definitely like to add in the future and have made sure will be possible to add.

The modules themselves don't need to manage groupings - the new groups interface will do that. I haven't posted anywhere near all the code here! I've only put up the parts that will affect modules.  The settings for groupings will all be set in the groups interface too.

I'll respond to your other points sometime, but don't have time to do them justice now!
In reply to Juliette Culver

Re: Request for comments - read if you're a module developer!

by Enrique Castro -
Picture of Core developers Picture of Particularly helpful Moodlers
Module instances do not need to manage groupings, agreed. They only need to declare the grouping they are working with.

Regarding group pertenece to groupings, you may realize I wrote about two possible ways to setup groupings. Technically there is no problem in having a group to be a member of several Groupings. It is a matter of ways of usage and user interface.

Having multiple group membership is a Good Thing. Following with my example in other thread I do want a given student to be member of three distinct groups, let say TheoryA, Lab2 and Project5. But probably it doesn't make sense to have this student in groups Lab2 and Lab3 simultaneously. The same is aplicable to groupings. In moodle <1.6 we had single group membership, as moodle 1.6 we have plain multiple group membership, which is prone to confusion. There is no provision to devise or setup rules about who can be a member of what group.  To actually restrict the flexibility that 1.6 allows (any student in any and all groups). The two ways to setup Groupings imply different modes to enforce such rules.

a) as a set of groups: the teacher creates a lot of groups and afterwards decide to assign one to GroupingA and the other to GroupingB. The existence of the groups is independent of the groupings. A particular group can be assigned to several Groupings.

In this scenario the user interface has two completely separate and unrelated pages to create groups and add students to them, and on the other hand to create Groupings and add groups to them.
The 'add students to group' could be the standard /course/groups.php page of moodle 1.6 (the one with the three columns available students/groups/studenst in group) , with teacher creating groups and adding students witout restrictions: students do not disappear from the leftmost column and can be added to several groups.
If a Grouping is declared as "exclusive" (a user can be member of a single group in the grouping), the 'add group to grouping'  new page should include code to check for conflics: a user that is member of two or more groups in the grouping. When adding a new group to the grouping

But the teacher can decide to add new students to a group after the group has been included in a Grouping. If using the regular /course/groups.php page of moodle 1.6 the teacher can add the same student to several groups in the grouping, breaking the rule (or this page should include code for checking membership also)

b) as a scope were the group "lives": Once created a Grouping, groups are created within that Grouping.
I see this arrangement as more "natural" as a user interface. First the teacher creates/selects a grouping, then goes to the groups page. This page is not independent of groupings. In this groups page there would be a menu to select a Grouping and a message/title indicating the currenttly selected grouping. All groups created are automatically assigned to the current selected Grouping. Depending on if this grouping is exclusive or not the add  student function  behaves as in 1.5 (students disappear from the available column as they are added to groups) or as 1.6 (increasing the membership counter but always available to be selected as member of another group). It is much easier for the teacher to distribute students manually this way.

The core idea is that there should be selectable rules to define student membership to groups and group membership to groupings. The minimal rule would be to set esclusive-single vs. multiple membership. And a mechanism to enforce that rules.

By the way Juliette, are you introducing Groupings into 1.7 or is the target a later version?

Enrique
In reply to Enrique Castro

Re: Request for comments - read if you're a module developer!

by N Hansen -
Enrique-Are you suggesting that the difference is between allowing groups to belong to more than one grouping and to allow groups only to belong to one scope? If so, I don't know if the latter is more "natural" as a user interface (to be fair, let's just say it solves the problem you needed to solve in your own courses), but from everything I have read so far I really like what Juliette has come up with.

 Here's why:

I've got a course that is divided into 3 units. The students progress through the units one by one. Unless they have paid for all 3 or have completed one and then paid for the next, students should only have access to unit 1. Those who have completed an earlier unit should have access to earlier units. As Juliette's system seems to work, I could put students into 3 groups: unit 1, unit 2, and unit 3. I could create 3 groupings: unit 1 (consisting of group unit 1), unit 2 (consisting of group unit 1 and group unit 2), and unit 3 (consisting of group unit 1, group unit 2, and group unit 3). When it comes to activities, I would assign them to the appropriate grouping depending on what unit they belonged to.

Now, as far as I understand it, this division of my course may be possible using the upcoming roles. The only difference I see between roles and groupings is that while students in certain roles/groupings won't be able to access certain activities in both, they will still see links to them with roles but wouldn't with groupings.

Now, the scopes system just doesn't do what I need it to do. As far as I understand it, it still gives everyone access to every activity, it justs breaks down the students in a different manner for each activity. Juliette's probably could do that too, but it also allows the teacher to restrict certain activities to only certain students, which is actually a much requested feature here, more so I believe than simply what scopes does.

Now, I think the request for comments should be opened up to actual users of Moodle. I hate to say this, but this seems to have turned into a "my system is better than your system" discussion between two developers and the ultimate judge should be the actual users as to what is most useful to them, not the developers.
In reply to N Hansen

Re: Request for comments - read if you're a module developer!

by Enrique Castro -
Picture of Core developers Picture of Particularly helpful Moodlers
Dear Nicole, I actually like the proposal of Juliette. The "scopes" word is just the term I got some time ago to make into moodle 1.5 but the concept is identical to Juliette's Grouping. I'm not fighting "for my system", I do have a system that has worked for a year, and that allowed to restrict activities to a single scope/grouping, but need  improvements to work in new moodle >1.7 with roles and permissions. And I do think that the ideas put forward by Juliette are in the right direction. Actually, her system is better, has explicit group permissions and is developed to work with global groups and roles system in moodle >1.7, no doubt about that. There is no alternative system competing.  But there are minor points that need clarification, that's all.

In fact, I was trying to expose what you claim in you last paragraph: case usage examples of real moodle teaching. The use of groups as small team is a keypoint.

If I undesrtand correctly how Groupings work, your setup will not work. All students will have acces to unit 3  form the beginning, not  unit 1. To get progression from "can see unit 1' to 'can see unit 1 & 2' or '1 & 2 & 3'  you should (if I am not wrong) set the Groupings inversely:
Grouping Unit 1 with groups (unit1, unit2, unit3) : all students can see Unit 1 content
Grouping Unit 2 with groups (unit2, unit3) : students in groups unit2 & 3, but not 1, can see content.
Grouping Unit 3 with groups (unit3) : onlu unit 3 studenst can see its content
This assumes a given student  promote from group unit1 to group unit2 when completing unit 1 and paying for unit2. A student do not belong to two unit groups simultaneosuly. Just unit1, unit2 or unit3. Is this what you  have in mind?

An alternative setting could be having students in three non-exclusive groups: unit1 students have payed only unit 1. If they pay unit 2 they get into unit2 group, without leaving unit1 group. So now you have the same student in two groups unit1 and unit2.

You could setup three Groupings again to restric acces to the Units content, but as
Grouping Unit 1 = (Group unit 1)
Grouping Unit 2 = (Group unit 2)
Grouping Unit 2 = (Group unit 3)

And the final effect would be the same as before, unit1 students see only Unit 1 content and unit3 students see all Unit 1-3 Content activities.

What scheme actually wil work better? depends on your organization, and payment scheme. If paying the fee for Unit 2 only wil allow implicit access to Unit1 (without explicit paying for Unit 1) then the first approach would be more appropriate. But if you expect payment por Unit 1 , and then payment for Unit 2  and then 3 (or paying the 3 units at once) then the second approach would be  better. For instance, if you want to know who has payed Unit 1, just search for unit1 members. In the former approach the same would require to search for groups  1 and  2 and 3 (someone in unit3 must have paid unit1 in the past, but you do not know when he did).

This is only my vision of how this usage example can be designed using the Grouping concept, I may have completely misunderstood the Groupings.

Enrique
In reply to Juliette Culver

Re: Request for comments - read if you're a module developer!

by Dan Stowell -
"grouping scheme"?
In reply to Juliette Culver

Re: Request for comments - read if you're a module developer!

by Enrique Castro -
Picture of Core developers Picture of Particularly helpful Moodlers
Hi again Juliette,
As a teacher I need to wonder which goups a user is member of, quite often. I work in a course with several small groups. A student can be in Theory1, and Lab3 and Project6 groups. If I want to post a message to this guy and his Lab3 group partners in a forum, first I need to know that he is actually in Lab3, not Lab2 group.
This is a task very difficult to perform  now in moodle 1.6. You need to go to  user page  and start to list  group by group  until you find the precise group he is in. The user interface lets you search which students are in a known group, but not which groups a known student is member of.

The function already exists : get_groups() or user_group(), replaced by something like
function groups_m_get_groups_for_user but without the _m_ (getting all groups this user is in this course, not just module),  but we are lacking a user interface to perform this task. Have you defined any interface for this task?

What I have done previously as a customization of Moodle at ULPGC is to modify print_user() function to add a line Group: X, Y, Z that will inform of the groups the user is member of in the  user listing if set to "more detailed" (in user/index.php). But perhaps adding this function to groups page could be more appropiate.

Enrique
In reply to Juliette Culver

Re: Request for comments - read if you're a module developer!

by Ray Lawrence -
Ref: "Set"

I seem to recall from my school days that the word "set" has the most definitions in the English language - 32 IIRC.
In reply to Enrique Castro

Re: Request for comments - read if you're a module developer!

by Robert Brenstein -
I just want to second a need to work in the team concept somehow. It has been discussed a few times but nothing more. Having teams is as important as having roles IMHO. I have seen requests for it ever since I started using Moodle a few years ago. Regardless of the way teams are actually implemented, the concept is closely tied to groups from user point of view and thus should be discussed together.
In reply to Robert Brenstein

Re: Request for comments - read if you're a module developer!

by Joan Codina Filba -
Yes, we also need teams as  groups of students that work together. This is a very important issue in most of our courses.
But I think that Moodle needs a wise discussion of what a course is, how can be divided into groups, if a teacher must be responsible of each group or not, if a group can also have more subgroups, restrictions in groups (for example a student can only be in  a group or not, all members of a subgroup must be of the same group, maximum size of groups) how teams are related to groups and activities: visibility rules, distributions of tasks between students or teams, grading...
But fist we must think why we need groups:
In our case we need groups because the same course has for example two groups with diferent teacher that are splited in two subgroups in lab sessions.
And they must do some homework by teams of 2 students that needs to be evalutated.  But also they have to do a project during the semester in teams of 5 students, and these teams may be choosen by the teacher or the students themselves.
For the project each team does the same project while for homework  each group has to send a different exercice of the ones proposed.
A team is seen by the teacher as a single student, and all the students of the team receive the same grade an comunication from the teacher, they could also share a working space where to interchange information between them or construct documents in a collaborative way
A group is a set of students that are put together for some reason but that they act as single students.
I think Moodle needs a higher level design of this subject.
Average of ratings: Useful (1)
In reply to Joan Codina Filba

Re: Request for comments - read if you're a module developer!

by Enrique Castro -
Picture of Core developers Picture of Particularly helpful Moodlers
All the usage scenarios you depict can be manages by groups and groupings as Julitte propose. What we need is been able to specify/restrict activities to certain groupings, and that is just a little step. At ULPGC we did that for 1.5 even.

Team assessment should be managed at module activity level. The purpouse or rationale for grading can only be set within the context of each particular activity.  What I do have clear is that grades must be individualized. Even if coming from a group-activity, all grades must be attributed to identified persons in the act of grading. For instance, we cannot have a table for Team grading, and let the actual composition of the team to change afterwards. If grading a  group-activity, each member of the group receives a grade as if he/she had done the activity alone. The module can keep track of the history  of changes, but not grading.

With this in mind it is quite feasible to adapt modules for group-work. The ewiki module is a good example. You may find a group-assignment included in our custom module ULPGassignment, available in that forum.

That's why I see teams more related to groups than to new roles or other user concept in Moodle. Actitivy is always individual people working within a group not a Team personality incarnated by several different students.

What moodle needs is good support for groups that allow, at the same time, use as class cohorts and as small teams, depending on the context. I expect to have a working demo in few days.

Enrique
In reply to Joan Codina Filba

Re: Request for comments - read if you're a module developer!

by Enrique Castro -
Picture of Core developers Picture of Particularly helpful Moodlers
Just to be more precise.
I think that groups and groupings, together with grouping-specific activities and group-aware activities can do the trick, even in 1.6, at the technical level. But there could be some confusion by using groups to such different things as course sections or small teams. It is not  a matter of the internal group API but of user interface design, of organizing concepts to work. I think the grouping/goups API and the behavior described by Juliette in the docs is the right thing.

Perhaps, the only things that could be added (and is a maybe) is an explicit field to consider a group/grouping as a Team and an specific permission/role as team leader/submitter. The team field could be another attibute of  a group, like its name or id. If could be use to check usage: avoid that a teacher sets a cohort-group as an assignment-submitting team or viceversa, using a 3-member small team as a whole-course section. That is , more for user-error checking than for internal needs. The proposed API includes some group-permissions. There is a 'student contribute' permission (i see it used in the context of forums, for instance). Perhaps a 'student submit' permission could be useful to manage access to different activities. Having "student contribute'  permission as an array for each activity,  for each group is too much. But I see usage need to allow a small team of studenst to comunicate between them in a forum/wiki (a la separate groups nowadays) (wich requires all members to be grantes contribute permissions) and at the same time only one of them been allowed to actually submit a group-assignment.

Another thing that is commonly demanded is hierarchical groups. In you example Joan, you have Theory grouping (two groups, one for each teacher). And Lab grouping (4 groups, 2 for each teacher). But if I understand correctly you want a way to ensure that Lab1 and Lab 2 groups are populated by students from Teory1 (and Lab3 and Lab4 from  Theory2 students). A way to specify that Lab1, Lab2  groups is related/associated/child/subgroup of Theory1. I would add a field 'parent' to group attributes, meaning other group this one is a subgroup of. Only 1 parent, not multiple, that would be a mess.

These modificantions would allow to change the way groups are populated, how the /course/groups.php page works (that with the three columns: available students/groups/group students). Now te teacher can add any student to any group, there are no provision to enforce rules of pertenence to groups/subgroups. My ideal scenariois as follows:

There is a Grouping menu first in the page that allows to select the grouping the we are viewing (or all groups). If set, all groups created with this page are automatically added to that grouping.
 When a group is selected in the central column its "parent" field is readed and the left column of avaliable students is modified to list only current members of parent group, thus ensuring only  those students can get into this subgroup. Other menus should allow to specify the parent group for each newly created group or the grouping or to select manually available students within a grouping/group. With this interface the nanaging task of the teacher (keeping track of which student should  go to each group) would be much aliviated.

Finally, a "manual override" could be added to allow a teacheredit to add a stutents to any group, avoiding all checkings. There is always a need for 'special cases', in universities  'special cases' is the rule. 





 

In reply to Enrique Castro

Re: Request for comments - read if you're a module developer!

by Joan Codina Filba -

Yes, I agree mostly with you.
You talk about the API of groups, I'm talking about "end user" functionality. And we must agree in what are the groups for. Then once we know why we want groups, it's time to see how it can be managed inside moodle. So my discussion was not which functions to implement, but why the current groups are not useful to me, and for what I need groups.
You and me share the same concept of university, but I'm sure that other people have very different issues about groups, and I wanted them to express their opinion. I don't know if people needs groups that go beyond a course?
And once the groups are defined  then its time to discuss what do we want to do with them:
    For me it's important the concept of a workgroup: where when students comunicate with the teacher all members of the group get a copy of the conversation, being sure that all of them share the same information. The idea of a working space where they can share files, data .. a portfolio for group? or a wiki.
  Also, as you pointed, the idea of distributing/assigning tasks/resources to groups, is also a very important isue.

I know that to program this is a huge task, but at least the API should be rich enough to allow this in a future.

Se you in Tarragona!

Joan


In reply to Joan Codina Filba

Re: Request for comments - read if you're a module developer!

by Enrique Castro -
Picture of Core developers Picture of Particularly helpful Moodlers
Actually, it can be achieved with minor changes to moodle 1.6.1. We at ULPGC used last year a grouping implementation we called group scopes with 1.5. We are applying those customizations to moodle  1.6.1+ for new academic course. In a few days we will have a site were you could play with groupings.
In reply to Enrique Castro

Re: Request for comments - read if you're a module developer!

by marco farfan -
Hi Enrique, i'm really courious about yours "group scopes" for moodle 1.6 It promise to be a good solution for something that i'm really looking for.
When do you expect to have it done?
Thanks in advance...
Marco