[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