Assignment module development proposition

Assignment module development proposition

by Oleg Sychev -
Number of replies: 12
Picture of Core developers Picture of Plugin developers

Hi, everyone there. I'm from Volgograd State Technical University and we use Moodle for some time there. There is a need to get a much more capable version of assignment to match our need thought, and we can do it. The propositions is placed in http://docs.moodle.org/en/Development:Assignment_development

The development has two main focuses:

  • to allow individual tasks for assignment (quite common situation in education)
  • to allow students to work in small groups on the assigmnet (another common occasion)

I would be doing this as plugin for assignment or new activity module, were it not for some inherited problems. It will make heavy use of assignment code, so there would be quite much trouble backporting to it any fixes/improvments that will be done in assignment.

As for assignment plugin, two issues are:

  1. we will need a copy of every current plugin for new plugin
  2. current assignment code isn't very much modular and useful for inheritance/overriding, so we must override it in many ways with similar code and get similar backporting troubles.

So the best way I can think of is to develop assignment module instead (it will make assignment also much more flexible for plugins). If new features will be too cumbersome for anyone (thought they looked far worse in textual description than on practice), he can turn they off and get almost usual assignment, as it now (maybe with some minor cosmetic changes).

The hard thing is to get some sort of overall agreement really fast. I'll need help to doing the bulk of the job, and considering conditions there I can get it only for December. The details are not important, but it would really makes all thing much more possible if we can know will this development be accepted or rejected by community.

Average of ratings: -
In reply to Oleg Sychev

Re: Assignment module development proposition

by Oleg Sychev -
Picture of Core developers Picture of Plugin developers

Well, this sort of thing looks quite complex.

If there would be no big assignment changes to 2.0, than we can write it as a module to 1.9 and test in some real courses during spring, so it'll become stable to the summer.

In reply to Oleg Sychev

Re: Assignment module development proposition

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Have you looked at the workshop module, and some of its more modern replacements like peerlight? They do some of what you want.
In reply to Tim Hunt

Re: Assignment module development proposition

by Oleg Sychev -
Picture of Core developers Picture of Plugin developers

Hi, Tim!

Our teachers fear workshop greatly, so the students is safe from it. Широкие глаза

Actually, all that peer assistment stuff isn't much useful in our circumstances (while it's often stuns a teachers and students). Not much culture of self/friend grading there, which often leads to bullying or unconditional support of other students. It would be long and hard work to incorporate it in our process (well, maybe later - right now there are much more urgent things).

The options we mostly needs is underdeveloped there (or not present at all). I think this modules have different goals and uses than ours.

Thanks for peerlight anyway (modules and plugins database is quite bloated and search isn't easy). Thought we hardly can adopt plugin in itself, Team used there is much better word than Workgroup Улыбка.

There is a way to cope our module with assignment while keeping it a separate activity, but it require some refactoring in assignment (and cleaning up some assignment code by the way). Feel free to see and comment on subtasks in MDL-17329 if you like. Your may propose something very good in the area.

In reply to Oleg Sychev

Re: Assignment module development proposition

by Petr Skoda -
Picture of Core developers Picture of Documentation writers Picture of Peer reviewers Picture of Plugin developers
Hello,

I personally do not like current assignment module much. The main reason is that there was not enough time to convert the grading part into new gradebook plugins. We can not have two grading interfaces at the same time - this can not work sad.

If we move grading into gradebook plugins there will not be much left from the old assignment - only the submission part and comments from teachers. Comments are another ptoblem - all modules are doing it separately now - I thing there should be some shared core feature which would be used in blogs, glossaries, assignemtns, wikis etc.

Group work, hmm why not use some new wiki in group mode instead? "Wiki === collaboration", if we add good file support and grading it might seem like a more suitable tool.

Adding code for group based access would require maybe 2x as much code and would make maintenance harder in future. Wiki, assignemnt or any other modules in 2.0 should share much more code IMHO - gradebook plugins, comments, ratings, file management if we want to minimise maintenance costs and improve quality in general.

There is always a lot of room for inovation and any complex highly customised modules, but I personally think that the activities should be simple, flexible, consistent and first of all very easy to use.



I think it might be easier for you to fork current 1.9.x assignment module and start tweaking it in contrib. Benefits for you would be:
  • no need to wait for general agreement - if 2.0 goes in opposite direction you would not be affected
  • no problems with upgrades in dev phase, you would need only migration of data from existing assingments
  • you can change db storage freely
  • you do not need to maintain current types
  • easier distribution and more feedback



I did read you comments and proposals in wiki, tracker and here - this looks very promising - good luck! smile


Petr

In reply to Petr Skoda

Re: Assignment module development proposition

by Oleg Sychev -
Picture of Core developers Picture of Plugin developers

Hello, Petr.

First of all, where should I look for these mysterious gradebook plugins, to get acquainted with them and see, can they be useful for us? Have to mention, thought, that I'm not a fan of idea to forbid resubmittions after grading - grade is a form of feedback to the student, sometimes much more effective than comment only (students, that motivated by the grade more than knowledge they got did exists, and quite in numbers Зло). I'm for an option for the teacher to make a grade final when he/she desires so - more flexible thing. So the comments alone isn't sufficient IMHO.

Group work doesn't cost much in code after we separate submission from grade, individual tasks much more so- with all editing, custom fields and so on, but they are quite needed. Workgroup/team is usually a 2-4 students working on a task, not an academical group (25-30 students) which are Moodle groups, so I don't think group mode in wiki (or anywhere) is useful for team management, sorry.

What we really need is a sort of center to distribute individual tasks to the students/teams (often avoiding duplication) and collect results of their work.

P.S. current types of an assignment was one thing that (after cleanup) we thought to inherit from assignment, avoiding creating a parrallel set of them. The we can get bonuses from maintainig them from a Moodle (while Moodle can get bonuses from our cleanup). I'm personally and professionaly not fond of separate code blocks with similar purposes.

In reply to Oleg Sychev

Re: Assignment module development proposition

by Petr Skoda -
Picture of Core developers Picture of Documentation writers Picture of Peer reviewers Picture of Plugin developers
hi,

1/ all the mysterious gradebook code is in /grade/* and /lib/gradelib.php
2/ I agree preventing submission after grading should be configurable
3/ our gradebook is designed only as a one way communication
4/ I think that comments should be allowed from both teacher and student
5/ group support code size may or may not be significant - but you need to test all possible configurations and scenarios which adds significant code maintenance costs
6/ expected 25-30 group size is not correct - we have groupings now exactly for this reason wink

Petr


In reply to Petr Skoda

Re: Assignment module development proposition

by Oleg Sychev -
Picture of Core developers Picture of Plugin developers

Hi,

1/ i know where gradebook code located, I just unable to find things you call gradebook plugins without further clarification

4/ agree to somewhat extent, but it can results in discussion (and there can be more than one teacher).

5/yes, self-organizing groups is a tricky thing to get worked; it'll be probably in experimental mode for some time

6/ groupings still in experimental mode, and they don't tell much for many people; anyway I don't see how group support can be useful to teamed assignment - there is a case, where different assignments in one course will have different teams. Unless context-wide groups Круто will  be implemented of course(which will be a very good, modular solution).

In reply to Oleg Sychev

Re: Assignment module development proposition

by Petr Skoda -
Picture of Core developers Picture of Documentation writers Picture of Peer reviewers Picture of Plugin developers
1/ oh, I thought this is obvious - users can see list of plugins in top left corner of most gradebook pages (Report, imprort and export plugins). Developers usually recognize plugins easily by seeing version.php and db subdirectories with access.php

4/ what is the problem? anybody who may grade and person allowed to submit would be able to add comments

6/ groupings are not experimental in HEAD anymore - I do not understand your comment, there seems to be some misunderstanding
In reply to Petr Skoda

Re: Assignment module development proposition

by Oleg Sychev -
Picture of Core developers Picture of Plugin developers

1/ You point then is to use report plugin for the assignment grading interface? Or I miss something?

4/ the problem is to not end up with another forum substitute of some sort. Maybe some sort of automatic link to forum discussion related to this submission (automatically created on first demand) will allow less code duplication.

6/ For me, workgroup or team (i.e. students that work on one project/submission) is something related to the specific course-module instance, not course as a whole. It well may be that on different tasks in one course people will be grouped in teams differently, it really is sometimes. Current grouping/group system isn't help at all there, as the groups are course-wide.

The only solution is to make groups context-dependent, just as roles - and this would be quite elegant, addressing many issues (ranging from most voted site-wide groups throught category-wide groups to the site-wide groups overrides on some courses (quite traditional issue in universities)). Then we can have cm-wide groups too. I even may be able to lend a hand should it be implemented, but probably can't do all the work by myself.

In reply to Oleg Sychev

Re: Assignment module development proposition

by Petr Skoda -
Picture of Core developers Picture of Documentation writers Picture of Peer reviewers Picture of Plugin developers
1/ yes - this will require changes and improvements in gradebook core

4/ no - it is exactly my aim to create something vaguely similar to forum discussion which is shared by all activities and modules

6/ this is not true at all - grouping is a set of groups which may be used in activity context

The concept of site-wide groups will be something different - major problem there are enrolments that is why it was not implemented in 1.9.x (will be in 2.0).
In reply to Petr Skoda

Re: Assignment module development proposition

by Oleg Sychev -
Picture of Core developers Picture of Plugin developers

1/ A new sort of plugin? Just let's keep in mind usability. Having a comment to describe any manual grade (well, quiz have it even to non-manual grades) is important. When you have about 200 students on 10 assignments, any additional mouse click on grading/commenting is quite painful cost. The current interface do well with it, separating comments from grades should do no worse.

6/ Then I can see no place for small teams at all. They can't be a groups (as they are needed an activity context) and can't be a grouping because they are smaller than academical groups. Actually it's quite strange to have a bigger units in smaller context. And groupings is a partial solution. Personally I think they add quite much similar code to the modules (to check with groups and groupings them), while responding only on several specific cases of groups organisation (even if the cases arise in such large organisation as OU).

Site-wide groups is only a partial solution too. Other, more specific cases, that will inevitable arise, are not voiced now just because site-wide groups is most urgent things. Even now I see several problems with site-wide groups that will arise in almost any university of our country at least (many of them starting using Moodle) Well, maybe create a separate discussion to discuss groups?

The more general solution will be to have context-dependent groups (well, I'm not the first to mention it), Moodle just have a fine set of contexts (almost perfect, only one flaw maybe). Just simple sketch of possibilities from current thinking :

a/ group can be created in any context from site to activity level

b/ user can enroll in a group on any context level (using enrollment plugins)

c/ group defined in some context can be enrolled in any lower-level context by person with appropriate authority (teacher, without enrolling plugins) (in two modes probably - enroll group as a unit, or enroll people only allowing to regroup them in lower-level context in a new groups)

d/ maybe a default group in the course for backward compatibility

Then all code in the modules can use several simple functions (just as has_capability now), not this awful 'check group, grouping mode and grouping' thing - while overall system will be highly flexible and configurable to any means. All complex code will be located in groups lib. Enrollment plugin modifications will be quite easy too, no need of complex things there.

Can elaborate, if you would like to consider this possibility, maybe creating a page in the wiki. I'm certainly lacking resources to implement all this by youself, but may participate - this is in our interest.

In reply to Oleg Sychev

Re: Assignment module development proposition

by Petr Skoda -
Picture of Core developers Picture of Documentation writers Picture of Peer reviewers Picture of Plugin developers
1/ usability is in this case separate from internal implementation

6/ no, no, no and no - please study the current group and especially groupings design in 1.9.x first - there are several wiki pages related to groups redesign in 1.9.x, a lot of inline docs and the most important part is use of groups api in activities.