[13:32:07] <Hora>  so then where am i integrating the graphs i worked on, kurtis?
 [13:32:27] <kschmidt_>  Good question hora
 [13:32:33] <Hora>  should i just let you do that while i work on something else?
 [13:32:33] <kschmidt_>  I haven't seen what you have for graphs yet
 [13:32:40] <kschmidt_>  So we'll look into that
 [13:32:45] <Hora>  ok
 [13:32:49] <kschmidt_>  I think that the graph you generated will be the graph in the mock up
 [13:33:00] <jerboaa>  m_conley, yep we definitely should put some stat data aside from runtime data
 [13:33:02] <Hora>  yep, that's the one
 [13:33:22] <kschmidt_>  Yes, so that's where your work is going to be going.
 [13:33:38] <kschmidt_>  We'll discuss implementation after the meeting (or later)
 [13:33:43] <Hora>  ok
 [13:33:46] <Hora>  sounds good
 [13:33:46] <kschmidt_>  I think that's all I have to talk about
 [13:34:02] <karenreid>  Great. mi_sa and viv, your turn :-)
 [13:34:21] <mi_sa>  there's a lot of discussion going on about the db schema
 [13:34:22] <viv>  alright, mi_sa do you want to go first?
 [13:34:29] <mi_sa>  to accomodate saving orignal marks
 [13:34:39] <mi_sa>  and state of remark process
 [13:34:52] <mi_sa>  some people seem to like adding 3 states to the marking_state
 [13:35:08] <mi_sa>  and saving old marks as a text file with the remark request
 [13:35:32] <mi_sa>  mike thinks that adding 3 states would add complications to the grader UI
 [13:35:52]  *** jerboaa dislikes the idea of saving stuff in files - It could get messy
 [13:36:18] <m_conley>  i guess I think it'd be weird if I was a grader, and the marking state dropdown menu had: "unmarked, partial, complete, remark requested, remark complete"
 [13:36:49] <karenreid>  I don't think the dropdown should have that
 [13:36:51] <mi_sa>  there was a suggestion to add a column to the marks or extraMarks to indicate if it was an original mark or remark
 [13:37:09] <jerboaa>  m_conley, we could filter the unneeded - i.e. separate view and model
 [13:37:10] <m_conley>  mi_sa: I'm OK with having a second column - remarking_state.
 [13:37:32] <m_conley>  jerboaa: yes, we could - I guess that's the complication I was talking about.
 [13:37:46] <m_conley>  this isn't a huge deal, I guess it's just a matter of personal preference. :p
 [13:37:48] <karenreid>  Couldn't we have the icons for remark requested and remark complete in the status column on submissions? and not in the dropdown?
 [13:38:13] <m_conley>  karenreid: yes, we could. I think that would imply a new column - remarking_state.
 [13:38:44] <karenreid>  Is that going to make the performance of the submissions table worse?
 [13:38:45] <mi_sa>  did you want a separate icon for remark complete vs just complete?
 [13:39:07] <jerboaa>  karenreid, a bit
 [13:39:10] <viv>  I think we discussed before that an extra column might be too much since remarks aren't going to happen that often
 [13:39:18] <karenreid>  mi_sa, you are right, we don't need a separate icon.
 [13:39:34] <mi_sa>  viv, column in a table in the db, not the UI
 [13:39:37] <m_conley>  hrm.
 [13:39:44] <viv>  ah ok
 [13:40:20] <m_conley>  how much of an impact would this new column have on speed?
 [13:40:27] <m_conley>  (in the DB table)
 [13:40:32] <m_conley>  i don't think *too* much.
 [13:40:40] <karenreid>  Could we overload the status column, but not show all the states in the dropdown on the grader page?
 [13:40:59] <m_conley>  karenreid: we could - but then what does it display if we're in "remarking_requested" state?
 [13:41:04] <karenreid>  m_conley: we might be okay.
 [13:41:20] <karenreid>  m_conley: complete or partial
 [13:41:36] <karenreid>  released == remkark_complete
 [13:41:56] <m_conley>  hm.
 [13:42:22] <viv>  should we just have a flag that indicates whether a submission is in for a remark vs a normal submission? and just reuse states?
 [13:42:44] <mi_sa>  there's a problem with that
 [13:43:12] <mi_sa>  you can't distinguish between a complete state with an incoming request and a complete state with remark finished
 [13:43:30] <mi_sa>  in both cases, there's a remark submission and complete
 [13:43:31] <m_conley>  right.
 [13:43:38] <viv>  ah right
 [13:43:54] <mi_sa>  yeah that's why there was a second boolean column in the blog post schema
 [13:44:21] <mi_sa>  so it just comes down to using 2 boolean columns, or adding 3 states to the marking_state column
 [13:44:25] <karenreid>  hmm
 [13:44:43] <mi_sa>  (or adding a remark_state column)
 [13:45:01] <mi_sa>  where column means column in the db (not UI)
 [13:45:01] <karenreid>  I don't really like adding more columns if we don't have to, but I don't want to clutter up the dropdown when remark requests are going to be relatively uncommon.
 [13:45:43] <m_conley>  well
 [13:45:54] <m_conley>  maybe we should just try one, and see if we like it?
 [13:46:01] <karenreid>  I have an idea
 [13:46:09] <m_conley>  go
 [13:46:21] <karenreid>  what if we only show the remark requested status in the dropdown when that is the current state?
 [13:46:42] <karenreid>  only the student is going to set it to remark requested
 [13:46:48] <m_conley>  i like that idea
 [13:46:59] <karenreid>  so the TA and instructor shouldn't need to set the state from the drop down.
 [13:47:01] <mi_sa>  i thought the 'submit' button does that
 [13:47:16] <karenreid>  mi_sa: exactly
 [13:47:29] <m_conley>  mi_sa: i think karenreid means that submit will set the state in the db to remark_requested
 [13:47:42] <mi_sa>  yes, that was the original plan
 [13:47:42] <m_conley>  mi_sa: and then iff we're in that state, then in the grader view, the state will appear in the dropdown
 [13:47:49] <karenreid>  then the grader will release the submission when the remarking is finished.
 [13:48:01] <m_conley>  karenreid: i like that solution.
 [13:48:10] <karenreid>  I think that means we add one more state to the status field.
 [13:48:16] <karenreid>  "remark requested"
 [13:48:35] <mi_sa>  we need something to indicate that there is an original set of marks
 [13:48:41] <m_conley>  and then where the dropdown is created in the view, check to see if we're in that case before adding the remark requested option.
 [13:48:46] <mi_sa>  when the state goes back to being complete
 [13:48:54] <m_conley>  ah, good point
 [13:48:58] <m_conley>  we need to remember that we did a remark
 [13:49:01] <mi_sa>  yes
 [13:49:06] <karenreid>  right.
 [13:49:29] <m_conley>  this is wayyyy tougher than it seemed to be at first glance. :p
 [13:49:39] <mi_sa>  so if we do it that way we either need 3 more states, or some column that indicates existance of 2 marks
 [13:50:13] <viv>  i think i prefer the extra column over 3 more states
 [13:50:16] <karenreid>  Don't we need just one more state for remark complete?
 [13:50:32] <mi_sa>  we also need remark in progress
 [13:51:04] <mi_sa>  because we need to show both grades during the process
 [13:51:05] <viv>  there needs to be some sort of indication that the grader is in remark grading
 [13:51:07] <karenreid>  you might be right.
 [13:51:09] <kschmidt_>  I've got to go, talk to everyone next week
 [13:51:18] <mi_sa>  bye kurtis
 [13:51:19] <karenreid>  thanks kschmidt_
 [13:51:21] <m_conley>  kschmidt_: bye
 [13:51:21] <viv>  bye kurtis
 [13:51:27]  kschmidt_ (~KurtisSch@wi-secure-3921.cc.umanitoba.ca) left irc: Quit: kschmidt_
 [13:51:38] <Hora>  I have to leave now guys, sorry to interrupt but I just wanted to say bye!
 [13:51:46] <karenreid>  bye Hora
 [13:51:50] <mi_sa>  byee
 [13:51:55] <Hora>  Oh, looks like it's not such a bad time since Kurtis just left too
 [13:51:55] <viv>  bye Hora~
 [13:52:08]  Hora (~Hora@S01060016b62644df.vc.shawcable.net) left irc: Quit: Hora
 [13:52:13] <mi_sa>  so A) add 3 states to the marking_state column
 [13:52:46] <mi_sa>  B) add remark requested state to marking_state column and a column indicating existance of 2 marks
 [13:52:51] <mi_sa>  B )*
 [13:53:31] <m_conley>  ok, got an idea
 [13:53:51] <karenreid>  The question is whether there is some other way to identify the existence of the original marks and the need to display the remark request tab
 [13:54:07] <m_conley>  how about 6 states total for marking_state: "unmarked, partial, complete, remark_requested, remark_in_progress, remark_complete"
 [13:54:27] <m_conley>  AND a boolean flag to tell us that a remark has been requested
 [13:54:37] <m_conley>  er, hold up
 [13:54:42] <m_conley>  no, sorry, that's redundant.
 [13:54:44] <m_conley>  *sigh*
 [13:54:46] <mi_sa>  we don't need the boolean :)
 [13:55:06] <viv>  well the boolean would be able to help us determine which states to show to graders?
 [13:55:14] <m_conley>  viv: that's what I was originally thinking
 [13:55:22] <mi_sa>  there _is_ a way, since the mark and extramark table will need an extra column to indicate whether it's the orignal or the remark
 [13:55:31] <mi_sa>  but i'm thinking that will be slow
 [13:55:32] <karenreid>  The reason I like the states is that it reflects the actual workflow, but it has to be efficient for coding and db too.
 [13:56:15] <m_conley>  Then how about we go with the 6 states, and see if maybe the UI stuff I'm worried about isn't so bad?
 [13:56:16] <NelleV>  I'm lost. Remarks are for when a student want more information on something ?
 [13:56:35] <m_conley>  maybe use a combination of the 6 states, and karenreid's solution - hiding some states depending on current state?
 [13:56:50] <mi_sa>  when a student wants his/her assignment re-marked (re-graded)
 [13:56:56] <karenreid>  How hard would it be to do a bit of analysis on the number of queries under the different models?
 [13:57:05] <mi_sa>  (that previous one was for NelleV)
 [13:57:21] <karenreid>  NelleV: when students think the grader got it wrong and want to get the mark changed.
 [13:57:32] <NelleV>  then, wouldn't that be simply a boolean ?
 [13:57:34]  viv (~viviensue@CPE001a70e9c2cd-CM001cea371e90.cpe.net.cable.rogers.com) left irc: Remote host closed the connection
 [13:57:50] <karenreid>  I feel like I'm trying to make performance decisions by guessing.
 [13:57:52] <m_conley>  karenreid: I'm not sure the number of queries will change - we'll still be retrieving the result model, and that'd include the new fields. It just fattens up the result, is all, I think.
 [13:58:02] <NelleV>  my assignment has been graded, and I don't agree. I flag it, the assignment goes back to "partial"
 [13:58:03]  viv (~viviensue@CPE001a70e9c2cd-CM001cea371e90.cpe.net.cable.rogers.com) joined #markus.
 [13:58:12] <m_conley>  NelleV: but that also unreleases it
 [13:58:24] <NelleV>  m_conley: that's implementation details
 [13:58:31] <mi_sa>  NelleV, it's a little more complicated than that because we need to save grades and show both
 [13:58:44] <NelleV>  hum, ok. That would make sense :s
 [13:58:47] <karenreid>  The problem is that we want to be able to keep the original grades. (which could be kept as a text blob rather than as part of the marks table)
 [13:59:07] <karenreid>  (but I'm not sure there is an advantage to doing that.)
 [13:59:10] <NelleV>  mmh.. I have the feeking that more states would just confuse people
 [13:59:32] <NelleV>  the flag could be something else than a boolean, and link back to the previous grades
 [13:59:33] <mi_sa>  I agree with jerboaa on that one that saving in a text file is ugly
 [14:00:10] <NelleV>  so when that column is not NULL, it means the assignment is being regraded, and we can print both of the results
 [14:00:28] <NelleV>  all that kept in the database
 [14:00:33] <m_conley>  maybe we're thinking about this on the wrong model - we've been talking about adding something to the Result model, when the Result isn't being remarked, it's the Submission being remarked
 [14:01:05] <m_conley>  a Submission could have a boolean - remark_requested, and if it does, then it also has an associated remark_result, along with the result
 [14:01:08] <NelleV>  mmh, indeed, I was thinking about adding a flag to the submission model, not the results
 [14:01:19] <m_conley>  and that remark_result is just a Result - with the same marking states
 [14:01:55] <NelleV>  I think I agree with m_conley (but I have a massive headache and can't think straight so...)
 [14:02:22] <m_conley>  i wish we were all around a wipeboard. :/
 [14:02:22] <mi_sa>  i need to leave soon for class
 [14:02:30] <viv>  m_conley: that'd be nice
 [14:02:59] <m_conley>  karenreid: so where do we go from here, do you think?
 [14:03:09] <karenreid>  m_conley: that is starting to make sense.
 [14:03:10] <NelleV>  so results belongs to submission. If we want to regrade an assignment, it does make sense to just create another object results
 [14:03:25] <m_conley>  right
 [14:03:31] <karenreid>  How does submission know it has more than one result?
 [14:03:41] <m_conley>  a boolean flag - remark_requested?
 [14:03:42] <karenreid>  (and which results belong to a submission)
 [14:03:43] <NelleV>  therefore, the database schema is much more simple: all the remarkmark tables etc are dropped
 [14:03:58] <m_conley>  and then the Submission will have a member called remark_result
 [14:04:00] <m_conley>  ?
 [14:04:01] <NelleV>  I'd do a boolean flag, but that would limit us to one single remark
 [14:04:13] <karenreid>  one single remark is oky
 [14:04:16] <karenreid>  okay
 [14:04:40] <viv>  this boolean would be in the result object right?
 [14:04:45] <m_conley>  no - in the Submission object
 [14:04:46] <NelleV>  viv: yes
 [14:04:50] <NelleV>  nope
 [14:04:52] <m_conley>  er
 [14:04:56] <NelleV>  agreed with m_conley xD
 [14:05:36] <karenreid>  sort of makes sense to me.
 [14:05:36] <NelleV>  remark_requested should also be in submission, I think
 [14:05:42] <m_conley>  mmhmm
 [14:05:46] <viv>  if it's in the submission, how do we link with which result object as remark?
 [14:06:00] <m_conley>  viv: a new member for the Submission - remark_result
 [14:06:03] <viv>  oh ok
 [14:06:07] <viv>  i must've missed that
 [14:06:22] <m_conley>  most Submissions won't have a remark_result
 [14:06:25] <NelleV>  viv: the boolean can actually be not a boolean, but result_id
 [14:06:37] <viv>  mhm
 [14:07:17] <m_conley>  So wait - a student makes a remark request, and that creates a NEW Result, and attaches it to the Submission via a member called remark_result
 [14:07:34] <m_conley>  and that's how we know if a remark has been requested? If the remark_result member is a Result?
 [14:07:50] <NelleV>  it makes everything so much more simple from an implementation point of view, and maintenance point of view. Remarking an assignment is the same thing as marking it.
 [14:08:06] <NelleV>  m_conley: that would work, wouldn't it ?
 [14:08:14] <m_conley>  it would, i'm just rolling it around in my head. :p
 [14:08:21] <viv>  m_conley: that makes sense I think
 [14:08:33] <m_conley>  this is worth a blog post, if not a short novel.
 [14:08:36] <NelleV>  I think the next step would be to rewrite a blogpost about that :p
 [14:08:54] <m_conley>  mi_sa / viv: what do you think of this idea?
 [14:09:40] <mi_sa>  i'm not sure i understand all of it
 [14:09:50] <mi_sa>  my class starts in one minute though
 [14:09:58] <karenreid>  viv and mi_sa : It would be worth taking a stab at writing it up and bug NelleV and m_conley for clarifications when you get stuck.
 [14:10:11] <m_conley>  do it
 [14:10:19] <mi_sa>  i'll write it up but i'll bug you guys here later
 [14:10:31] <mi_sa>  because i still don't know what we decided on
 [14:10:34] <mi_sa>  :)
 [14:10:34] <m_conley>  mi_sa: i'll be away until tonight - maybe send e-mail for me, if you need me.
 [14:10:35] <karenreid>  mi_sa: have a good class