Proposed work - changing aggregation methods in the Gradebook

Proposed work - changing aggregation methods in the Gradebook

by Dave Cooper -
Number of replies: 4

Hi all,

There is currently an issue that is in progress on our tracker: https://tracker.moodle.org/browse/MDL-50062 and would like to make people aware of the changes that we are working on. Any feedback/opinions are very welcome and everything will be taken on board smile

<short summary of the tracker issue>

The current issue is that when a grade item that uses Weighted Mean as the aggregation method is changed to an aggregation method that uses extra credit, the item is then treated as extra credit. 

</short summary of the tracker issue> 

There are also some other similar bugs that could also be described, but they all stem from one main problem: We use aggregationcoef in the database to represent more than one piece of information. Specifically, we use it to represent the weighting of a grade item for Weighted Mean items and we also use it to represent whether or not an item is extra credit for Simple Weight Mean/Mean of Grades/Natural Weighted items. To add to this, Natural Weighted items also make use of a second aggregation coefficient column: aggregationcoef2. 

So it's a bit of a mess.

At HQ, we have spent a lot of time discussing the issue and there have been a few suggestions put forward (as well as the ones on the tracker issue). In an ideal world, we would be able to preserve data when changing from one aggregation method to another (i.e. swapping from Weighted Mean -> Natural and then back to Weighted Mean) and keep weighting/extra credit information in an elegant manner. However, the task of doing that is exceptionally large, given the current database schema and the fact that in situations, switching from one aggregation method to another and expecting the weights to directly translate and maintain a sensible meaning just doesn't make sense.

We will be putting together a patch this sprint that does the following: when switching from one aggregation type to another, aggregationcoef (and aggregationcoef2) data will be wiped. This is the cleanest way to deal with the inconsistencies that are currently present (and doesn't require a huge overhaul). In addition to this, we will be updating help strings for the gradebook to ensure that users are made aware that changing aggregation methods will result in them not being able to retrieve previous weighting/extra credit information. We will also be documenting this in the docs pages too.

As mentioned at the beginning of this post, we strongly encourage the community to comment on this and voice their opinions/concerns, as this is extremely important to us.


Thanks,

Dave


In reply to Dave Cooper

Re: Proposed work - changing aggregation methods in the Gradebook

by Emma Richardson -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers

Maybe I am missing something or it is too complicated to implement, but wouldn't it just be simpler to separate them out into two different tables?  This has caused issues before.

In reply to Emma Richardson

Re: Proposed work - changing aggregation methods in the Gradebook

by John Okely -

I agree that would be better. Unfortunately, it may not be simple. Luckily extra credit is currently treated in roughly the same way throughout all aggregation methods. But weighting is not, so we'd need to make the call on whether to have different columns/tables for each weight.

In reply to Dave Cooper

Re: Proposed work - changing aggregation methods in the Gradebook

by steve miley -

key take away -  Yes, please do this, notification is good to, i like that,  but if you can preserve extra credit, that would be good.    ok, now more detail 


I was in a discussion with Bob Puffer, Carly Born, Mark McKay, Todd Williams, Ratana Lim yesterday discussing this.

We believe that the weight should be cleared / initialized when  changing aggregation methods, but the extra credit status preserved if possible.   But, to be clear, I'd much rather have both extra credit and weights cleared, than none. 


Comments on why preserving weights might not make sense:

When moving from weighted mean to natural, it doesn't make a lot of sense to preserve the weights as the units are different and the math would be too complex. 

weighted mean - weights relative to each other (1,1,3,5) or ( 2 , 2, 5, 10) ...

Natural - sum of % reaching 100%   (20%, 30%, 50%) 





I want to list two scenarios that can trigger this behavior though, i believe we generally just think of the first :

1. changing the aggregation method for a category/course(total)

2. moving an item from one category (with one aggregation method) and another category with a different aggregation method.


We came up with a fix (at least for the primary permutation (leaving weighted mean) for #1.  We don't have a fix for #2.    With many institutions wanting to change to Natural, getting a fix in so the gradebook doesn't get messed up as it does now by setting items as extra credit should be a priority.   Its really quite messy and confusing and leaves a bad taste seeing what happens to a current gradebook moving from weighted to natural right now in 2.8.    I'd lobby for a partial/simple fix that addresses the use case in #1 if #2 can't be solved. 


Those are my two cents. 

BUT, that being said, in a future release, it would be nice if those fields aggregationcoeff,  aggregationcoeff2 were changed to (weight, extra credit) and used properly in all agg methods. That would have prevented this from being an issue. 


Thanks,  Steve



In reply to steve miley

Re: Proposed work - changing aggregation methods in the Gradebook

by Robin Leung -

I've reported this issue from the beginning of the tracker issue and can't believe it has evolved into such a big discussion (not realizing the complexity of the issue).

I've been just catching up all the activity that I've missed in the past month or so. Thanks for raising this issue in the tracker and now the community. I cannot agree more with Steve's points above, especially #1. I, too, agree that a quick and partial fix will allow the community to start using Natural grading the way it is intended to be, simple and natural.