Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Gradebook 2.x architecture: Difference between revisions

From MoodleDocs
No edit summary
mNo edit summary
Line 18: Line 18:
; Grading logic and UI implemented in activity modules : Grading tools like single point grade, scale-based grading or a new rubric-based grading should be handled by the Gradebook core with a rich set of interface toward activity modules (and eventually other plugin types).
; Grading logic and UI implemented in activity modules : Grading tools like single point grade, scale-based grading or a new rubric-based grading should be handled by the Gradebook core with a rich set of interface toward activity modules (and eventually other plugin types).
; Manual and auto grades interaction : What should happen in this scenario has never been defined: 1. Student makes first attempt at the quiz, gets grade of 50%, this is pushed to the gradebook. 2. Teacher manually edits the grade to be 60%. 3. Student makes second quiz attempt and scores 75%. What should the gradebook show now?
; Manual and auto grades interaction : What should happen in this scenario has never been defined: 1. Student makes first attempt at the quiz, gets grade of 50%, this is pushed to the gradebook. 2. Teacher manually edits the grade to be 60%. 3. Student makes second quiz attempt and scores 75%. What should the gradebook show now?
== Suggested solutions and improvements ==
The gradebook to be still represented as a tree of grade items. There is no need to change this. Grade items may be associated with an activity module (multiple grade items per mod are supported) or a gradebook category. Grades are aggregated from the leaves of the tree to the root grade item that represents the total course grade.
[[image:gradebook-tree.png]]
In the example above, there are two grade items associated with modules in the course. These two are aggregated into a single item associated with a grades category. This category grade item is aggregated together with yet another grade item (that itself is populated via grader report) and form the course total grade.
=== Introducing grade values states ===
This is a suggestion to extend the grade_grades table so that every grade item can actually hold three independent values:
* ''Available'' grade value - This is the value that comes from the source - from the activity module, from the grader report or as a result of the aggregation at lower levels. It behaves as an input buffer that just keeps the most recent incoming value.
* ''Overridden'' grade value - This is the value of the grade defined in the gradebook.
* ''Effectual'' grade value - This is a public value of the grade, it is used for aggregations at higher levels, it is being exported, displayed to users etc.
[[image:gradebook-buffer.png]]
The key point of this new scheme is how and when the ''effectual'' value is populated. The container (column) holding the effectual value is populated during the grade ''approbation''. Whenever a process of approbation is executed (typically during the recalculation of the gradebook tree), the following procedure is taken:
* If the value of overridden grade is not null, then use it as the effectual value (and break as we are finished)
* If there are no approbation conditions defined, take the available grade value and use it as the effectual value
* If there are some approbation conditions defined, evaluate the list of conditions. If the evaluation passes, use the available grade as the effectual grade value
The approbation conditions mechanism should support at least the following types of conditions:
* Date-based conditions - This would replace the current hidden-until feature
* Event-based conditions - Things like "take the grades into account when all submissions are assessed"
* Manual trigger - special type of an event. The teacher can easily order the gradebook to "take the grades into account NOW" by clicking a button or so
At the moment, we are unable to distinguish between the incoming ''available'' grade and the outgoing ''effectual'' grade value. Therefore it is not easy to put a grade on hold. For teachers in schools, it is pretty natural to have some grades already known but not having them counted into the total grade yet.
To be decided: do the conditions have to pass to take the overridden value into account, too? That is - if there are some approbation conditions defined, is the overridden value dependent on them or not?
=== Data storage ===
0 - 100, min max
=== Introducing gradebook engines ===

Revision as of 23:31, 30 March 2011

Gradebook 2.x architecture
Project state Planning
Tracker issue MDL-25423
Discussion N/A
Assignee unassigned


This page summarizes some initial ideas and suggestions that may help to resolve Stage 3 of the Gradebook improvements project.

Current issues

These are some of the most important issues with the current Gradebook design that this spec tries to deal with. See http://www.mindmeister.com/89537697/gradebook-2-x-issues-braindump for even more issues.

The grades appear in the gradebook immediately (MDL-25439)
The grade values are stateless. We need a way how to store grades in the gradebook but exclude them from aggregations yet. Currently, the hiddenuntil feature tries to solve this but it is pretty limited and hacky (MDL-25440).
Students and teachers may see different values
Because of how grades hiding is implemented currently, it is practically impossible to pre-populate whole grades tree and/or export reliable data (because they are dependent on the current role permissions).
Unable to alter grades processing
There is a demand for alternate methods of grades processing (eg grades over 100% or negative grades) due to local conventions in various countries and school systems.
Grading logic and UI implemented in activity modules
Grading tools like single point grade, scale-based grading or a new rubric-based grading should be handled by the Gradebook core with a rich set of interface toward activity modules (and eventually other plugin types).
Manual and auto grades interaction
What should happen in this scenario has never been defined: 1. Student makes first attempt at the quiz, gets grade of 50%, this is pushed to the gradebook. 2. Teacher manually edits the grade to be 60%. 3. Student makes second quiz attempt and scores 75%. What should the gradebook show now?

Suggested solutions and improvements

The gradebook to be still represented as a tree of grade items. There is no need to change this. Grade items may be associated with an activity module (multiple grade items per mod are supported) or a gradebook category. Grades are aggregated from the leaves of the tree to the root grade item that represents the total course grade.

gradebook-tree.png

In the example above, there are two grade items associated with modules in the course. These two are aggregated into a single item associated with a grades category. This category grade item is aggregated together with yet another grade item (that itself is populated via grader report) and form the course total grade.

Introducing grade values states

This is a suggestion to extend the grade_grades table so that every grade item can actually hold three independent values:

  • Available grade value - This is the value that comes from the source - from the activity module, from the grader report or as a result of the aggregation at lower levels. It behaves as an input buffer that just keeps the most recent incoming value.
  • Overridden grade value - This is the value of the grade defined in the gradebook.
  • Effectual grade value - This is a public value of the grade, it is used for aggregations at higher levels, it is being exported, displayed to users etc.

gradebook-buffer.png

The key point of this new scheme is how and when the effectual value is populated. The container (column) holding the effectual value is populated during the grade approbation. Whenever a process of approbation is executed (typically during the recalculation of the gradebook tree), the following procedure is taken:

  • If the value of overridden grade is not null, then use it as the effectual value (and break as we are finished)
  • If there are no approbation conditions defined, take the available grade value and use it as the effectual value
  • If there are some approbation conditions defined, evaluate the list of conditions. If the evaluation passes, use the available grade as the effectual grade value

The approbation conditions mechanism should support at least the following types of conditions:

  • Date-based conditions - This would replace the current hidden-until feature
  • Event-based conditions - Things like "take the grades into account when all submissions are assessed"
  • Manual trigger - special type of an event. The teacher can easily order the gradebook to "take the grades into account NOW" by clicking a button or so

At the moment, we are unable to distinguish between the incoming available grade and the outgoing effectual grade value. Therefore it is not easy to put a grade on hold. For teachers in schools, it is pretty natural to have some grades already known but not having them counted into the total grade yet.

To be decided: do the conditions have to pass to take the overridden value into account, too? That is - if there are some approbation conditions defined, is the overridden value dependent on them or not?

Data storage

0 - 100, min max

Introducing gradebook engines