Tim's Gradebook thoughts
My thoughts on the gradebook stuff, having just read Petr and Eloy's long jabber discussion (only developers will be able to access that).
The key thing is something Eloy said (sorry can't find the exact quote now):
- We need to define what we mean by a grade in Moodle, with a simple model for what can change them, and how.
I think that once we are agreed what we are trying to do, a consensus for how best to structure the code will be easy. But we first need a description of how grading in Moodle work, and we need to try to write it in teacher's langauge. If you like, we should write the one-page help file "Introduction to Grades in Moodle". (There does not seem to be anything like that now!)
Things I think everyone agrees on
- Grades should be stored centrally in the gradebook.
- Every grade-item has a minimum and a maximum, and the grade for each student will be between those two limits.
- Activities, etc. should only manipulate grades through a defined API.
- Some activities have an automatically calculated grade.
- Teachers need to be able to manually override any grade, with an optional comment, or grade any grade item that is not automatically generated.
- (Similarly there are calculated/imported columns in the gradebook, which teachers may want to manually override for some students.)
- The key problem is, what happens when the automatically computed grade value changes after a teacher has manually overridden the grade?
More thougths
A. Problem 7. is really the one we are all arguing about. If only we can solve that, I think the rest is easy. Actually, there is a related issue, what happes if, in some peer-review module, Student one grades Student two, then the teacher overrides that grade in the gradebook. Then Student one tried to change his grading.
B. Petr has this language "modules 'propose' grades into gradebook", and 'Final grading' when a teacher edits a grade in the gradebook. I don't think I understand this yet - there may be a good technical solution here. However, I am sure that this lanuage would be totally incomprehensible to most teachers, and they are the people who really need to understand how this works. I would like to read how Petr would describe his proposal to end-users.
C. I think it should not matter whether the grading UI or information is shown in the gradebook, or individual activities. Grading is an absolutely fundamental part of a VLE. It is one of the strands that ties a whole course and its activities together. Therefore, I think it is inevitable that there will be grade-related UI both in the modules and it the gradebook. However, for this to be managable, it is even more important that there is a single underlying model of what a grade is in Moodle, and that all the information ends up centrally stored in the gradebook.
That is, we should know what we mean by actions like
- activity module M automatically calculates that student S has earned grade G for this activity; or
- User T has given student S grade G with comment C on grade item M;
and what effect they will have on the contents of the gradebook in all cases. If we can do that, then it does not matter where a particular bit of UI that a user can use to trigger one of these actions happens to be.
D. If you like, this is an argument for a Model-View-Controller architecture.
- There should be a central model of what a grade is. That is the information that is actually stored in the gradebook.
- There should be a fixed API for manupulating grades. That is, the controller should make a limited set of actions available to the rest of Moodle.
- We should have the ability to have multiple views of the central grading data, and multiple interfaces for updating it. We already have lots of plug-in views in the gradebook itself (both for viewing and updating). But to give teachers and students the interface they expect, we need UI for seeing and updating grades in the activities too.
