MarkUs Blog

MarkUs Developers Blog About Their Project

New marking scheme proposal

with 11 comments

A PDF file is included in this blog post about the new marking scheme. It contains User Stories, functional and implementation details.

– Three implementations are discussed and we want to know what you think about them.
– We also need approval from Karen about the User Stories.

New marking scheme proposal (v1.1)

In answer to Karen’s comment, this is 2 more database scenarios  Scenario4And5.

We hope to discuss about the new marking scheme on the IRC meeting tomorrow.

– Ulaval Trio

Written by simonlg

October 16th, 2009 at 12:46 am

Posted in Uncategorized

11 Responses to 'New marking scheme proposal'

Subscribe to comments with RSS or TrackBack to 'New marking scheme proposal'.

  1. The user stories look good to me. (I sent back a few edits to the trio.)

    I tend to prefer scenario 1, mostly because it keeps the 2 marking schemes relatively independent. I can imagine wanting to add a third scheme (say for peer evaluation) at some point.

    I do wonder whether it is possible to combine the flexible_mark and rubric_mark tables. They seem to hold the same data.

    Looking forward to reading other comments.

    Karen

    16 Oct 09 at 2:54 pm

  2. Updated file to version 1.1 (in the post). Corrected most english problems kindly pointed out by Karen.

    gabrielrl

    16 Oct 09 at 3:55 pm

  3. In answer to Karen’s comment, I have added a link in the post that gives some explications and 2 more scenarios. I have sent it by email, to Karen, Simon and Gabriel saturday morning, but I think it is preferable to publish it on the blog.

    NOTE: Watch out, scenario 5 is different from the one I sent by email.

    melagaud

    18 Oct 09 at 11:36 pm

  4. Like Karen, I prefer Scenario #1, but with creating new ones for the flexible marking scheme data and leaving the existing ones as is. I really don’t like the idea of renaming stuff. I do agree with Karen that we should keep the marking schemes as independent as possible.

    After reading Melanie’s Scenarios 4 and 5, I am a bit confused. I expected that we wouldn’t be able to change the marking scheme once marking has begun. Or if you do, then I think that any existing marks should be thrown out, but what if marks have already been released? Then we shouldn’t be able to change the marking scheme for the assignment since all students should be marked equally. Separating the flexible and rubric mark tables seems like duplicating of data – we already have that information in the assignments table, which is linked (via several others) to the mark table.

    That’s just my two cents though – it appears that you three have already thought through this quite a bit. I still think that we should discuss the scenarios a bit more at the meeting this Friday since we’ve all had more time to actually look over them by now.

    Tara Clark

    21 Oct 09 at 1:29 pm

  5. We would not be able to change marking scheme once the marking has begun.

    Is it even possible to modify an assignment when the marking has begun ?

    I prefer scenario 1 because we won’t have any problems with 2 foreign keys in the Mark table.

    simonlg

    22 Oct 09 at 4:29 pm

  6. It’s a tricky problem, to keep previous marking results once one switched the marking scheme. I’m basing my reasoning on the fact that it’s desired, say for marking an assignment twice with different marking schemes for research purposes.

    I am favoring scenario 4, but using a join table in order to keep previous marking results in the database. Hence I’d suggest something like this:

    Assignment < ActiveRecord::Base has_many :rubric_criteria, :through => marking_criteria, :class_name => "RubricCriterion", :\order => :position
    has_many :flexible_criteria, :through => marking_criteria, :class_name => "FlexibleCriterion", :\order => :position
    ...
    end

    MarkingCriterion < ActiveRecord::Base has_many :rubric_criteria, :class_name => "RubricCriterion", :\order => :position
    has_many :flexible_criteria, :class_name => "FlexibleCriterion", :\order => :position
    end

    And as we go adding more marking schemes add more classes which are linked through MarkingCriterion. What do you think?

    Severin

    22 Oct 09 at 5:21 pm

  7. I like scenario 1 as well. I think it’s a good idea to keep the two marking schemes independent. Tara’s concern about renaming tables is something good to keep in mind. Renaming “mark” to “rubric_mark” would make the database schema easier to understand. But, this change would need to be made in a lot of places. So, I think there are valid reasons for going either way.

    Farah Juma

    23 Oct 09 at 11:51 am

  8. In our last IRC meeting everybody agreed to go with scenario 4, and Karen thought that finally that was not that important to keep old gradings when the instructor decides to change of marking scheme. After the meeting, I rest a bit and I suddenly had an idea! Scenario 4 can keep old gradings, we just need to add a field marking_scheme_type and here we go… I wish I thought about it before, but I guess that’s in talking together that good ideas comes out 😉 What do yout think of it?

    melagaud

    23 Oct 09 at 2:18 pm

  9. Melanie,

    If you are talking about a marking_scheme_type attribute in the marks table, then I’d rather do single table inheritance on the Marks table. That’s almost the same. Don’t you think?

    Severin

    23 Oct 09 at 6:34 pm

  10. […] the new marking scheme proposal. This report comes in answer to all discussions we had about the first iteration. It contains the decisons we have taken about each of the following […]

  11. […] Original proposals for FlexibleCriteria from Laval students […]

Leave a Reply