MarkUs Blog

Since Tara, Fernando, and Farah have been focusing on the development of features, they have decided to use a similar evaluation scheme.

Specifically, Tara, Fernando, and Farah will each be graded individually based on the following marking scheme:

1) Feature completion: 30%

• For simple grade entry, this means:
  • An instructor can create a grade entry form and can assign TAs to enter the marks
  • An instructor and the appropriate TAs can enter grades into the form
  • An instructor can upload/download a grade entry form in CSV format
  • Students can view their grades for a grade entry form

• For logging, this means:
  • A developer can log a message
  • A developer can specify the log level that he wants
  • An administrator can specify the desired type of rotation
  • An administrator can specify the desired file names and path of the log files
  • Localized messages for using I18n

• For the notes system, this means:
  • Students can see nothing related to the notes
  • An instructor or a TA can create new notes on groupings
  • An instructor or a TA can view existing notes on a grouping when creating a new note
  • A user can edit or delete notes created by him/herself
  • An admin can edit or delete any notes
  • An instructor or a TA can see an aggregate view of notes on the new Notes tab
  • The groupings object designation for notes should be extended to also work for assignments and students

2) Feature testing: 20%

• For simple grade entry, this means:
  • There should be tests for instructors, TAs, and students to ensure the above functionality exists as desired

• For logging, this means:
  • Messages are logged properly
  • Log Files are rotated properly
  • Log level severity are differentiated and send to the corresponding log file

• For the notes system, this means:
  • There should be tests for instructors, TAs, and students to ensure that the functionality does or doesn’t exist as desired

3) Documentation: 20%

• The code should be documented
• The tasks for this feature should be split up into tickets with clear descriptions
• There should be a document posted under “MarkUs Component Descriptions” on the DrProject site that explains the current state of the feature, future plans, etc.
• There should be a short screencast of the feature posted on the DrProject site if applicable

4) Overall Process: 30%

• Blog posts, status reports, or review requests indicated steady progress throughout the term
• A thorough design process was followed
• Demonstrated good programming practice
• Consulted with other team members about design/implementation decisions and/or helped other team members (eg. through blog posts, review requests etc.)
• For Tara, Overall Process also includes maintenance (i.e. other tickets)

Fernando would also like the following breakdown for these categories:

1. Feature completion (30%)
   • Logging – 15%
   • Notes System – 15%
2. Feature testing (20%)
   • Logging – 10%
   • Notes System – 10%
3. Documentation (20%)
   • Logging – 10%
   • Notes System – 10%

Tara would also like the following breakdown for these categories:

1. Feature completion (30%)
   • Maintenance – 10%
   • Notes system – 20%
2. Feature testing (20%)
   • Maintenance – 5%
   • Notes system – 15%
3. Documentation (20%)
   • Maintenance – 5%
   • Notes System – 15%