MarkUs Blog

MarkUs Developers Blog About Their Project

Sections: specifications & ideas

with 5 comments

One of the functionality we would like to implement this semester is section management.

Here is the content of this post

Details specifications

  • Group management : the groups should be formed of two or three students of the same section ;
    • instructors need to be able to add the students section through the web interface or via the CSV file upload.
    • the student list should have filter to sort students per section.
    • instructors should be able to switch from two modes, in the assignment property tab:
      • groups have to be formed with students from the same section.
      • groups DO NOT have to be formed with students from the same section.
    • when switching to this mode, the application should display a warning message if some of the students don’t have a section associated to them.
    • students should see whether the groups have to be formed of students in the same section or not.
    • when the mode is activated, inviters should not be able to invited students in another section than theirs.
    • if some students don’t have a section, inviters with no section will be able to invited only students without any sections.
  • Deadlines : Each section needs to be associated with one specific deadline ;
    • this functionality can be enabled only if groups are limited to same-section students.
    • when enable, instructors can specify one deadline per section in the assignment property view.

If deadlines are specified per sections, it is logical that submissions rules could be too. For the first implementation, we will disable submission rules.

Database schema


Sections table

This table is used to save all the sections. In the case of UofT, it should be from 2 to 3 sections. For Centrale Nantes (a French engineer school), 12 sections (groups).

id: int
name: string

Users table

We added a foreign key to sections. This is mostly used for students, but can also be used for Graders (we could then map graders to groups per sections).

Assignments table

There are a lot of options that can be added with the new section scheme.

section_due_dates: boolean, false
section_groups: boolean, false
section_submission_rules: boolean, false

Section_due_dates table

This links assignments and section, to add a specific due date to each section for an assignment.

id: int
section_id: int, fk
assignment_id: int, fk
due_date: date

If you have any thought, please chime in !

Written by nvaroqua

January 25th, 2010 at 10:08 am

Posted in Uncategorized

5 Responses to 'Sections: specifications & ideas'

Subscribe to comments with RSS or TrackBack to 'Sections: specifications & ideas'.

  1. Nelle:

    Looks good, and makes sense to me.

    Are Instructors able to create Groupings that have StudentMemberships across different sections?



    25 Jan 10 at 2:57 pm

  2. @Nelle

    I totally by that. Good job. It seems like MarkUs will going to have the possibility added to subdivide users for an assignment into sections. Alright!

    The thing which bothers me is that there is an assignment due_date and potentially a due date of the section. The cleaner solution to me seems to have one big section in the case one would use assignment’s due_date attribute of your current proposal. What do you think? Too invasive?

    Following the “an instructor is allowed to do anything” concept, I would say yes. MarkUs should issue a warning in that case, though.


    25 Jan 10 at 3:40 pm

  3. @Mike: Like Severin said, I think Instructors should have every right. I think the best solution is to have a warning message if the instructor does so. I’ll add this warning message to the specifications
    (which can be found here

    @Severin, I wondered about this due-date problem: it bothered me too. (we’ll have the same issue with submission rules)
    We could maybe consider to implement sections with tree structure (adding a column belongs_to, as a foreign key to another section), with the top node “all”. In this case, we could get rid of the due_date column.
    On one hand, it would allow to (in the future) implement sections and subsections (sections of sections).
    On the other hand, I don’t know if subsections would ever be useful, or if it is worth the trouble implementing this. But I think it is the most proper way to code this.


    25 Jan 10 at 5:54 pm

  4. Nelle, this sounds good to me!

    Will attaching graders work differently as well when there are sections? (i.e. will an instructor want to assign graders based on sections?)

    Farah Juma

    25 Jan 10 at 10:53 pm

  5. @Farah Karen wanted to have the possibility to do this. I don’t know yet how this is going to work (can graders be part of two different sections for example ?), but will think about it.


    26 Jan 10 at 4:19 am

Leave a Reply