MarkUs Blog

MarkUs Developers Blog About Their Project

Meeting minutes – October 23rd 2009

with 3 comments

Minutes from last MarkUs Developers’ meeting that took place on October the 23rd 2009.

Gabriel was absent
Mike was on and off due to network problems while attending a conference

  1. Meeting opening at 12:03
  2. The new flexible marking scheme:
    • Karen raises the question whether it is important to reduce the number of tables;
    • To Melanie it isn’t important, what matters is reducing inquiries and creations speed while optimizing room usage. She votes for scenario 1;
    • Karen states that on a maintenance point of view : “we want to make sure that changes don’t have to be made in more than one place, and that we aren’t adding unnecessary pieces”;
    • Melanie asserts with Farah that she is confortable with scenario 1 since she’s going to use those tables (criteria and marks);
    • Farah likes scenario 1 and she’ll only need the marks table;
    • Karen says that keeping the code clean and simple is more important than worrying about the number of tables;
    • Severin asks for the specifics between scenario 1 and 4;
    • Melanie answers that scenario 4 is interesting but: “we will have to keep the marking_scheme_type in table mark, to know to what marking_scheme each mark are associated”;
    • Severin asks Melanie about the comment he made;
    • Melanie answers: “yes! For me this suggestion fits, almost entirely, with scenario 3. Maybe with some variation in keys, but at the end we need a way to tell to marks table to what marking scheme each record are associated. I have designd a schema based on your idea, I can post it in scenarion 1, the marks associated to each marking scheme are in there own table, so it is easy to figure out to what marking scheme they are related”;
    • Mike Gundelroy pops in and tells us about “Rails’ polymorphic relations” stating that someone should look into that. (Simon takes note);
    • Karen says she isn’t worried about keeping previous marking results in the DB and that we should focus on the simpliest solution. On that regard, scenario 1 seems the simpliest to her;
    • Melanie thinks that DB matters shouldn’t influence the development choices. She sees the application as a “coat” above the DB “coat”;
    • Severin disagrees to have 2 markings table (rubric_marks and flexible_marks) and if we drop previous results once we change it – we’re fine;
    • Karen says that works for her because it is unlikely that an instructor will want to keep previous results once marking scheme has changed though there is an argument about keeping the data trail;
    • Melanie fears of what might happen if the marking scheme is changed by mistake though we could give the instructor a warning;
    • Simon, Tara, Severin and Fernando all votes for the warning while Karen remembers the others that we do that in other context, like uploading a group file;
    • Simon is back with some fast reading on polymorphic associations and says that is should do the trick keeping the marks in one table (he’ll look further on that);
    • Karen asks to look further on polymorphic associations and disadvantages of scenario 4. She’s ok with making the descision now;
    • Severin remembers Simon that we’re doing something similar for users – single table inheritance;
    • Simon asks if the name “flexible” is still ok and Karen says that it is, for now;
    • Severin points out we should keep that documented (Rubric based marking vs. Flexible marking);
  3. The new icon for “ready to mark”:
    • Karen is happier with the blue square, just for visual distinction;
    • Melanie states that the blue square dosen’t mean much to her though;
    • Severin points out that Mike had suggested a green flag;
    • Karen is not sure whether the green flag really represents “ready but not started” but the blue square stands out from the other icons;
    • To Tara, the flag means “problematic” rather than “started”;
    • Severin is quite indeferent on this (after all, it’s one line of code to change);
    • Karen states we will stick with the blue square for now;
  4. Messaging system:
    • Karen congratulates Tara for the document she wrote and raises what is the “big question” to her: what will be the mechanism for adding comments?;
    • Simon proposes a new tab;
    • Tara anwers it is definitely not the way to go to create comments on assignements/groupings;
    • Karen says it might be a button;
    • Tara thinkgs of something similar to the way notes are added in ReviewBoard, but not on lines of comments. She adds: “So you click on a button and then a dialog pops up, without greying out the rest of the page, and you can see previous notes on the grouping and add a new one”;
    • Simon propose expanding a div instead of a dialog;
    • Severin asks to what a note sticks? line of code/submission/grouping?;
    • One the things Karen liked about the proposal is that notes can attach to a variety of different components; She wonders if we could have a higher level button (or div) that would know about the context while she reminds we want to make it simple;
    • Severin asks whether grouping should be the common denominator?;
    • Tara answers that: “A grouping is linked to an assignment, so using the grouping is the best idea for talking about a group and an assignment combination. I see there being a button, say on the line with the list of submission files, saying “Notes (x)” where x is the number of notes so far, if there are some and then clicking on that button would pop up the div of some sort showing the notes and a form”;
    • Karen’s original idea was that notes would be applied to submissions or groupings.
    • Severin thinks the commonvdenominator might be the user then;
    • Tara answers that there could be multiple people within a group and the TA would most likely want to comment on the submission as a whole;
    • To which Severin answers: “right, so a note on a submission would be attached to every student member of that grouping. That duplicates things, but it would make it most universally applicable such as notes about individual users, submissions, even labs (once simple grade entry is in place). filtering notes appropriately might be a challenge”;
    • Karen thinks she and Tara will have to take this offline and fill in this part of the proposal (which sounds good to Tara). She also thinks that the more general approach is appealing, but she’s concerned about making it too complicated, and wondering about how useful the generality will be;
  5. Logging:
    • Fernando uploaded a review request for v2 of the logging proposal;
    • Severin is not sure about the class name anymore (although he suggested it) Logger4Markus;
    • Fernando likes the name and Karen smiles, Severin retracts himself saying that it’s not important anyway;
    • Karen asks about the next steps;
    • Fernando thinks he just needs a “ship it”. He’s waiting on the reviews;
    • Karen asks if he thougth about the basic log messages that we should be putting into the code;
    • Fernando didn’t thought about that but remembers it is pretty straight forward to add things and Severin would like other people weigh on this;
    • Simon asks that unit testing be made on the logger class;
    • Karen asks Fernando to spend a bit of time adding the basic messages when the structure is set and asks him for some testing too;
    • Fernando will add the messages to the locales file (which Severin thinks is a good idea to use I18n right away);
    • Karen says that once a bunch of messages have been added, and we have it up on markusproject.org, we should be able to let it run for a bit and then see what info we can get from the logs (Serverin states that, once commited, this should happen automatically [on markusproject.org]);
    • Severin thinks we should be really scarce with error/fatal messages;
    • Fernando remembers that he did separate the errors from the info messages (Severin knows, but sill…);
  6. Grade entry:
    • Karen inquiries to Farah if she has any comments/questions about the grade entry form;
    • Farah had a busy week but she”ll be working a lot more on grade entry this weekend and next week. She has no question at the moment;
  7. Quick word on tests:
    • Karen makes sure that everyone is still keeping up on writing tests.
    • Severin notes he sees a lot of improvement has happened;
    • Karen everyone to keep working on it;
    • Simon says: “Just to make you think about it : Writing tests in ruby is really necessary because there isn’t a compiler checking errors. You have to run your tests to ensure your refactoring didn’t break anything”;
    • Severin wonders what does a compiler checks, other than syntax (to which Simon answers: if the method exists, for one);
    • Melanie asks about emphasis on TDD;
    • Severin says that if we do it as Adam Goucher has suggested, it might not be very painful. Little switches back and forth – red – green -refactor;
    • Adam Goucher pops in to tell us that: “The hardest part about following someone else’s (poorly documented) test suite is figuring out their assumptions and style so please document these things”;
    • Karen suggests a good blog post topic: “given that you have been told that TDD is a good idea, are you doing it, how hard is it to follow…;
  8. Evaluation scheme:
    • Karen starts by probing the group for any questions about the evaluation scheme (stating that ULaval students are kind of bound by their course requierments);
    • Simon (from UL) wonders if they have to write an evaluation scheme;
    • Karen replies that they could send their course’s one and chip in on what methods should be used (if they weren’t bound) to evaluate them.
    • Melanie and simon reply they can do that;
  9. Other news:
    • Karen tells that Diane is planning to try again to use Markus for the next assignment, so she has her fingers crossed that we won’t find any new showstoppers. On top of that, the patches are working fine for her in her course so far. There will also be a demo at the department Research In Action Showcase on Nov 17. It’s a pretty big affair with lots of industry people invited. Mike, Severin, and her will be working on a poster and demo for it, which they will undoubtedly look for feedback on;
  10. Meeting closing at 13:06.

Written by gabrielrl

October 29th, 2009 at 11:31 am

Posted in Meetings,Minutes

3 Responses to 'Meeting minutes – October 23rd 2009'

Subscribe to comments with RSS or TrackBack to 'Meeting minutes – October 23rd 2009'.

  1. […] Posted by Gabriel Roy-Lortie on 2009/10/29 The last MarkUs developers’ meeting minutes are now available here. […]

  2. Gabriel, I think you mean that Mike was attending a conference, not assisting a conference. assister à une conférence = attending a conference, but assisting a conference = aider à organiser une conférence 😉

    Tara Clark

    29 Oct 09 at 12:00 pm

  3. Tara, you’re right! I made the correction. Thanks! 🙂

    gabrielrl

    29 Oct 09 at 12:06 pm

Leave a Reply