[01:30:38]  NelleV (~nelle@unaffiliated/nellev) joined #markus.
 [01:30:53]  #markus: mode change '+o NelleV' by MarkUsBot!~MarkUsBot@li136-145.members.linode.com
 [01:35:43]  NelleV_ (~nelle@unaffiliated/nellev) joined #markus.
 [01:36:06]  #markus: mode change '+o NelleV_' by MarkUsBot!~MarkUsBot@li136-145.members.linode.com
 [01:37:13]  NelleV (~nelle@unaffiliated/nellev) left irc: Ping timeout: 250 seconds
 [02:06:03]  Nick change: NelleV_ -> NelleV
 [02:26:34]  NelleV (~nelle@unaffiliated/nellev) left irc: Quit: leaving
 [05:06:46]  divarvel (~divarvel@ARennes-351-1-41-142.w82-126.abo.wanadoo.fr) joined #markus.
 [05:16:16] <divarvel>  hi
 [08:31:03]  bwinton (~bwinton@CPE0016cba51b90-CM001cea87a4d2.cpe.net.cable.rogers.com) left irc: Ping timeout: 250 seconds
 [08:31:40]  bwinton (~bwinton@ joined #markus.
 [08:51:50]  jerboaa (~sgehwolf@nat/redhat/x-ptkfgsqxwfmppdqu) joined #markus.
 [08:52:16]  #markus: mode change '+o jerboaa' by MarkUsBot!~MarkUsBot@li136-145.members.linode.com
 [12:26:27]  m_conley (~m_conley@173-230-185-103.cable.teksavvy.com) joined #markus.
 [12:26:49]  #markus: mode change '+o m_conley' by MarkUsBot!~MarkUsBot@li136-145.members.linode.com
 [12:29:37]  karenreid (~karenreid@red-gw43.cs.toronto.edu) joined #markus.
 [12:30:06]  #markus: mode change '+o karenreid' by MarkUsBot!~MarkUsBot@li136-145.members.linode.com
 [12:32:09]  evanb (~Evan@bas15-toronto63-1177891691.dsl.bell.ca) joined #markus.
 [12:48:29]  jiahui (40b4570d@gateway/web/freenode/ip. joined #markus.
 [12:57:44]  kschmidt_ (~KurtisSch@wi-secure-3921.cc.umanitoba.ca) joined #markus.
 [12:57:51] <kschmidt_>  Hello
 [12:57:52] <m_conley>  hello all
 [12:58:06] <evanb>  hi everyone
 [12:58:28] <karenreid>  Hi, how is everyone surviving the middle of the term?
 [12:58:38] <kschmidt_>  Lots of exams and assignments
 [12:58:45] <kschmidt_>  But going okay
 [12:59:06]  viv (~viviensue@CPE001a70e9c2cd-CM001cea371e90.cpe.net.cable.rogers.com) joined #markus.
 [12:59:11] <karenreid>  I'm seeing a lot more bleary-eyed students (and faculty) around here.
 [12:59:21] <m_conley>  karenreid: yeah, that's about right. :)
 [12:59:22] <evanb>  I have an exam or an assignment due today in every class :S but its going alright :)
 [12:59:37]  *** karenreid ducks
 [12:59:53] <evanb>  karenreid, I may use a grace day or two for yours ;)
 [13:00:03]  Hora (~Hora@S01060016b62644df.vc.shawcable.net) joined #markus.
 [13:00:10] <karenreid>  that's what they are for.
 [13:01:04] <karenreid>  (Evan is in my OS course as well. I think it is safe to say that It is notorious for its workload.)
 [13:01:39] <evanb>  yes it certainly is
 [13:01:50] <karenreid>  We have had more users using different corners of MarkUs, so more issues have been coming up.
 [13:02:10] <m_conley>  that's good.
 [13:02:19] <m_conley>  i noticed some more issues being filed
 [13:02:50] <karenreid>  :-)
 [13:03:13] <m_conley>  Hora: playing with your patch now - should have a review up soon
 [13:03:18] <karenreid>  I'm starting to develop quite a distaste for github's issue tracker.
 [13:03:25] <m_conley>  oh no. :/
 [13:03:32] <Hora>  m_conley: awesome, thanks!
 [13:04:13]  victorivri (~chatzilla@CPE00222d732132-CM00222d73212e.cpe.net.cable.rogers.com) joined #markus.
 [13:04:35] <karenreid>  I'm finding I want to give a bunch of issues highest priority in the sense that there are some issues that I'd really like to have resolved by Christmas.
 [13:04:51] <karenreid>  (There are also a few annoying UI bugs in the issue tracker)
 [13:05:03] <karenreid>  Okay, we have almost everyone, so let's get started.
 [13:05:13] <karenreid>  It seemed like a slow week for almost everyone.
 [13:05:14] <kschmidt_>  Can you do something to highlight the ones important to you (and the team)?
 [13:05:24] <kschmidt_>  I'm a little behind on my bug fixes so I wouldn't mind being given some
 [13:05:50] <m_conley>  karenreid: yes - a "priority" label, or some such, that'd be helpful, I think.
 [13:05:55] <karenreid>  Should I create a new label for ?
 [13:06:09] <karenreid>  okay. I'll try to do that oday.
 [13:06:25] <karenreid>  kschmidt_ if you want to tackle 143, that's a high priority one.
 [13:06:52] <karenreid>  I've been trying to move the most important ones to the top, so *I* can see them, but a label would help everyone else.
 [13:07:01] <kschmidt_>  Yup, I'll look into that one
 [13:07:09] <kschmidt_>  Do we have a method for claiming tickets worked out yet?
 [13:07:28] <Hora>  i think we just make a comment?
 [13:07:32] <kschmidt_>  Ok
 [13:07:54] <m_conley>  a comment - or create a label with your name, and attach
 [13:07:57] <m_conley>  kinda ad hoc. :/
 [13:08:20] <karenreid>  As I was saying, it is okay to have a slow week or two, but it is going to be hard for the rest of the term to set aside time for this course, so please be careful not to start to let your MarkUs work slide every week.
 [13:09:19] <karenreid>  Let's start today with kschmidt_ and Hora since they were at the top of the blog post in the punchlines
 [13:09:31] <Hora>  ok
 [13:10:26] <Hora>  before we get into the graphing, i just want to mention that my review for issue 117 is stalled
 [13:10:49] <m_conley>  on it
 [13:10:55] <Hora>  m_conley, you said you'd take a look, so that's great
 [13:11:00] <Hora>  i hope i can finish that up soon
 [13:11:09] <Hora>  and get it merged
 [13:11:16] <m_conley>  thanks for mentioning though. Good to keep us on our toes.
 [13:11:26] <Hora>  :)
 [13:11:57] <Hora>  ok, as for the graphing i've started working on some functions that prepare grade distribution data for Bluff
 [13:12:35]  jiahui_ (~irchon@d64-180-87-13.bchsia.telus.net) joined #markus.
 [13:12:43] <Hora>  karenreid: should the student grade distribution show how many students got a certain grade, or percentage? right now i'm working on both
 [13:12:56] <Hora>  could that be an option for the professor/student, to see either or?
 [13:13:26] <karenreid>  it could be an option, but for simplicity, I'd pick one for now, and then add a ticket to make it optional.
 [13:13:36] <Hora>  ok
 [13:13:49] <karenreid>  My inclination is to go with percentage.
 [13:13:53] <Hora>  i'll do the percentage then, it's a bit easier :P
 [13:13:59] <Hora>  ok
 [13:14:01]  jiahui_ (~irchon@d64-180-87-13.bchsia.telus.net) left irc: Client Quit
 [13:14:54] <karenreid>  When I talked with mi_sa and viv about the remarking interface, I asked them to try to figure out what the smallest piece they could get reviewed was. If you can start to get even a placeholder into the existing code, so that it can be reviewed, and you have something to build on, that would be great.
 [13:14:56] <Hora>  i should get a review in about this tomorrow
 [13:15:03] <karenreid>  great!
 [13:15:56] <karenreid>  kschmidt_: anything to add? which graphs are you working on?
 [13:16:21] <kschmidt_>  I added the graphing framework in. Then Hora had planned on doing some work while I was doing exams.
 [13:16:33] <kschmidt_>  So hopefully I can see Hora's issues and use them as needed
 [13:16:52] <kschmidt_>  Otherwise I'm going to have to see what other graphs are needed and start adding some helper functions for them
 [13:17:04] <Hora>  kschmidt_, i should get a review in tomorrow, for the grade distribution graphs
 [13:17:09] <kschmidt_>  Good
 [13:17:15] <karenreid>  sounds good
 [13:17:27] <kschmidt_>  I might use that in some way and try to generate a graph that shows the grade dist per TA
 [13:17:37] <kschmidt_>  See if one TA is being too generous
 [13:17:44] <karenreid>  that would be useful
 [13:18:01] <karenreid>  I have another request that doesn't involve graphs, but would be really useful.
 [13:18:24] <kschmidt_>  Alright
 [13:18:29] <karenreid>  We have a hard time seeing whether the grading has been completed,
 [13:18:42] <karenreid>  and which TAs aren't finished, or where the holes are.
 [13:19:05] <kschmidt_>  Alright
 [13:19:16] <kschmidt_>  I can look into that as well
 [13:19:19] <karenreid>  We've talked about producing a grid, of groups vs. criteria, with colouring to show which are incomplete
 [13:19:23] <kschmidt_>  If anyone has an idea though, feel free to shout it out
 [13:19:37] <karenreid>  It would be nice to also easily identify which TA is responsible for the holes.
 [13:19:47] <Hora>  ok
 [13:19:57] <karenreid>  Or even to have a summary of how many for each TA are complete.
 [13:20:12] <karenreid>  It is a little more complicated now that we can assign TAs to critera.
 [13:20:25] <m_conley>  maybe a simple progress bar?
 [13:20:32] <Hora>  so TAs are assigned to both groups and criteria, right?
 [13:20:39]  mi_sa (~chatzilla@b2240-04.cdf.toronto.edu) joined #markus.
 [13:20:49] <Hora>  and multiple TAs could be working with the same groups?
 [13:20:49] <kschmidt_>  A progress bar would show that they aren't finished, but not what they aren't finished
 [13:20:55] <m_conley>  kschmidt_: true
 [13:21:10] <karenreid>  true, but summary information is also useful
 [13:21:21] <karenreid>  I'd suggest getting a graph or two finished, so that we can make use of the work you have done with Bluff first.
 [13:21:31] <karenreid>  And then one or both of you can look into this one.
 [13:21:49] <Hora>  ok
 [13:21:57] <karenreid>  We might not even get to it.
 [13:22:33] <karenreid>  I'm really hoping that at the end of the term we will have something that can be used in January and a framework to continue adding more reporting features.
 [13:22:56] <karenreid>  Okay, moving on. Let's switch to evanb, jiahui, and victorivri
 [13:23:17] <victorivri>  i'm here :-P
 [13:23:23] <m_conley>  nice blog posts!
 [13:23:31] <evanb>  m_conley, thanks!
 [13:23:31] <karenreid>  just about to say that!
 [13:23:55] <victorivri>  thanks for the comments - they were very helpful
 [13:24:15] <evanb>  Victor and I had a very productive day on Saturday
 [13:24:32]  *** karenreid realizing I haven't commented on evanb's post - sorry
 [13:24:33] <m_conley>  that's good. :)
 [13:24:58] <jiahui>  i looked at evan's blog post, i think i will work on developing sample testing setups
 [13:25:03] <jiahui>  and also some bug fixes
 [13:25:21] <karenreid>  I really like the fact that you are identifying bugs and weaknesses in what was done before. This will really help strengthen the system.
 [13:25:55] <evanb>  karenreid, wsa there anything important that we left out?
 [13:26:36] <karenreid>  I'll look over the post more carefully after the meeting and add comments. Looks pretty good so far.
 [13:26:54] <evanb>  sounds good
 [13:27:26] <karenreid>  jiahui: sounds good too.
 [13:27:36] <evanb>  I think Jiahui and I will be working on the framework itself for the rest of the term and Victor will work on the security/vm side
 [13:27:37] <m_conley>  victorivri: have you had a look at snowflock?
 [13:27:56] <victorivri>  m_conley: not really
 [13:28:09] <victorivri>  but i will today
 [13:28:11] <karenreid>  one drawback of snowflock is that it is built on xen which may be harder to convince an IT person to install
 [13:28:17]  *** jerboaa is not really sure if we should add that amount of complexity (snoflock) just yet
 [13:28:25] <m_conley>  karenreid: oh. Didn't know that. :/
 [13:28:28] <karenreid>  I agree with jerboaa
 [13:28:53] <victorivri>  yeah, i was thinking with starting with increasingly progressive prototypes
 [13:29:10] <victorivri>  1st gen: sequential testing
 [13:29:17] <victorivri>  2nd gen: VM pooling
 [13:29:21] <victorivri>  etc
 [13:29:32]  viv (~viviensue@CPE001a70e9c2cd-CM001cea371e90.cpe.net.cable.rogers.com) left irc: Remote host closed the connection
 [13:30:01] <karenreid>  One thing I was thinking of was whether some places might rather send the tests to another physical server that was more secure.
 [13:30:09]  viv (~viviensue@CPE001a70e9c2cd-CM001cea371e90.cpe.net.cable.rogers.com) joined #markus.
 [13:30:12] <victorivri>  *i meant increasingly complex
 [13:30:29] <karenreid>  victorivri, I like your approach.
 [13:30:43] <m_conley>  karenreid: yeah, I can see that happening.
 [13:30:49] <jerboaa>  karenreid, ideally that shouldn't matter if VM or physical machine
 [13:31:18] <karenreid>  I agree, and it makes for a nice separation between what is MarkUs's concern and what is the concern of the test server.
 [13:31:27] <victorivri>  jerboaa is right, as long as there is an ip to communicate the basic functionality should be the same
 [13:31:50] <karenreid>  I.e. MarkUs is going to have to trust that the test server is secure whether it is a VM or a physcial server.
 [13:31:50]  jiahui_ (~irchon@d64-180-87-13.bchsia.telus.net) joined #markus.
 [13:32:09] <karenreid>  alright, how about viv and mi_sa
 [13:32:10] <karenreid>  ?
 [13:32:27] <mi_sa>  i've started implementing the marking state changes
 [13:32:42] <mi_sa>  i was wondering, do you want to differentiate states between a completed marking and a completed remarking?
 [13:32:50] <mi_sa>  or is 'complete' fine for both?
 [13:32:55] <karenreid>  Nice GUI mockup by the way!
 [13:33:15] <mi_sa>  vivien's work =)
 [13:33:18] <karenreid>  My first instinct is that complete is fine for both
 [13:33:26]  jiahui_ (~irchon@d64-180-87-13.bchsia.telus.net) left irc: Remote host closed the connection
 [13:33:41] <mi_sa>  okay, so that means i may need to add another field called remark_exists or something like that
 [13:33:54] <mi_sa>  because we want to display old and new in the results tab if remark is partial or complete
 [13:34:00] <viv>  they were your ideas too :)
 [13:34:25] <mi_sa>  i made the ugly sketches, you turned them pretty
 [13:34:25] <karenreid>  yes, sounds good
 [13:34:34] <mi_sa>  ok
 [13:34:36] <viv>  I've started on coding up (at least the GUI) for remark settings for assignment properties and that should be up on review board soon..
 [13:34:37] <m_conley>  question: is there a limit on how many times a student can request a remark?
 [13:34:47] <mi_sa>  yes
 [13:34:50] <mi_sa>  just once per assignment
 [13:34:56] <mi_sa>  he/she can edit their request
 [13:35:09] <mi_sa>  until the prof actually looks at the request and starts remarking
 [13:35:25] <mi_sa>  he/she can also cancel an existing request
 [13:35:31] <m_conley>  ok, cool.
 [13:35:46] <mi_sa>  sorry, they can edit until they press submit
 [13:35:57] <mi_sa>  so they can save it while working on writing up the request
 [13:36:09] <viv>  or delete it and request another one if the prof hasn't seen the request yet
 [13:36:10] <mi_sa>  but after they submit, they have to delete their existing one if they want to make changews
 [13:36:16] <mi_sa>  yup
 [13:36:33] <viv>  i'm wondering.. should we be uploading code for GUI separate from code for say changes to the model?
 [13:36:38] <m_conley>  i see, ok, cool. I'm digging the mock-up, btw.
 [13:36:46] <mi_sa>  :)
 [13:36:51] <jerboaa>  question: how do you plan to avoid conflicts? i.e. prof starting to remark while student is editing?
 [13:37:08] <mi_sa>  if the prof starts the remark, the assignment is unreleased
 [13:37:15] <mi_sa>  so the student can't change anything at that point
 [13:37:28] <viv>  I think as soon as the prof "collects" the assignment for remarking, it unreleases the mark
 [13:37:40] <viv>  and the student won't have access to edit the request anymore..
 [13:37:49] <m_conley>  viv: if you can break your review requests down to a particular unit, like updating the models, that helps. It's a fine balance - we also want to see the big picture.
 [13:38:04] <jerboaa>  but what if at time x a student starts editing something
 [13:38:22] <viv>  hmm we haven't thought about that yet :x
 [13:38:26] <jerboaa>  and at time y a prof starts remarking, but student hasn't finished
 [13:38:30] <mi_sa>  student can't edit after submission
 [13:38:35] <m_conley>  viv: so it doesn't have to split across model/UI code...maybe just split across different "areas of work", if that makes sense. :/