Question Editor ProgramFeature brainstorm, no particular order:
For packet-submission tournaments, questions by one team have to stay together (can be combined with other team, but no scattering) Perhaps this sort of thing can be controlled by an authorship attribute? Author of a question defaults to Harvard, but we can batch a set of questions to be, you know, UCLA's or whatever--and then we can keep track of what packet(s) they're in--perhaps make it able to generate a report of that info. If UCLA's just freelancing, no problem; if they have a packet, then they'd better be in only one packet. questions have edited-by and comments (and difficulty?) and tags / categories See how distribution is looking (both across entire tournament and within a packet) Ability to merge / import? I can export out all the lit, give it to Ted, he can edit it, save it, and give it back to me, and I can merge it in Or, if it ends up being an online thing, even easier (Ted can log in his own darn self... hm, we need to think user-friendliness) Login is something I'm interested in thinking about--how we register users, etc. I'm thinking perhaps for now only @.harvard.edu? The other issue--yeah, we should support input from nicely marked up text, but the bigger thing is keeping it all online. This should work as seamlessly as possible. Exporting should totally work for packet-creation, though. No question can appear in multiple packets (or even the same packet multiple times) These problems might be easily solved via the very nature of how we define a packet--a packet is just a bucket. If you put a question in the bucket, you can't put it in there again, since it's in the bucket. We take it out of the bucket to put it in another... The bigger challenge would be the issue of multiple import--i.e. we import the same question twice since we're not thinking. Solution: be able to import .doc or antiworded .docs. At the very least, we want to do manual import only on packets that will never need anyone else (i.e. the submitting team) to update them again. You (AW) sum up what I (BY) was thinking much better than what I was trying to say. Part of it, too, is if I lose track of a question that has already been written and I decide for whatever reason to resubmit it. I think some of your concerns are best addressed by precisely assigning living, breathing people their roles: once you've written a question, you can consider that issue settled and if Ted turns your Kipling tossup into a tossup on a Kipling work you've never heard of and you don't recognize as Kipling, you don't just readd your Kipling tossup--you, rather, have to trust that the only thing that ate your tossup was an editor, not the software. (Key issue: make sure that the software does not in fact eat tossups!) The software is never going to be subtle enough to recognize "hey, that's a Kipling tossup, and we already have 2/0 grumpy British imperialists!"--the best we hope for is it noticing two identical answer lines. Eventually, it'd be nice to be able to filter by question-author, so I could look for all the tossups I wrote and see what exactly has become of them, and Dennis Sun could look up all the tossups marked "DS" and get back all the ones he and/or Dallas wrote We totally need to implement a sort of search/ report facility. That's not necessarily too hard; it's just letting the user construct a query. That's actually pretty damn easy; it's the pretty printing that's harder. Or, hell, just give you the minimum: each user by logging in gives us his id, therefore his name, therefore his initials, so we can just generate a list of tossups he's written for him on the fly. It depends on proper tagging, which is something that might not be a priority for CS50 purposes but will be presumably addable before actual 1.0 "release" I'm not sure what you mean by "proper tagging." When I add a tossup to the database, it defaults to author me unless I say author none (foreign packet) or enter another author from the team. Database pushes that back along with other stuff. Right - I mean, keeping track of characteristics of questions. Exactly what we decide to keep track of will presumably grow as the project gets more robust. If it's easy to implement, by all means implement it. As far as priorities go, it might not need to be too high of one. Little clicky expanders to display answer line, entire question, or entire question plus comments Searching for appearances of a word / duplicated words Mark questions as unwritten / assigned / unedited; keep track of question-writers and editors "QUESTION POOL" with all questions, default sort by subject Packets (with names) that we can put questions into (via drag and drop!) Output to RTF or LaTeX (or even to a format readable by a moderating program) Vague list of important things, in some notion of order:
#1: Make sure it saves.
In order for it to be somewhat useful, we do need functionality of questions and packets If we include everything that we've thought of, it might end up looking pretty busy - I (BY) am trying to picture a way to display all the stats and categories about questions without making it too overwhelming. Only bare minimum idea of category needs to be implemented now, if that - maybe just a few default categories and a default distribution (and not all the customizable / sub-distro "World Lit", "Common link" ideas)
Tagging questions and adding more data about them (e.g. written by, edited by, mark as unwritten, date of last edit, comments, difficulty) seems like something BY might be able to work on separately How about separate screens? The one widget in the Google Webkit that allows you to stack expandible menus sounds good: you could have one menu of "views"--by subject, by packet, etc.--and another menu of search, build a query, whatever.
Search is useful, but again fairly low priority
We eventually would like to be able to look at packets both sorted by category (e.g. HFT or T-Party spreadsheet) and randomized for actual playing. I (BY) think getting one of those done is ambitious enough in the short run.
Multi-login (as AW suggests above) is a good idea, but in the short run probably simply giving access to default user without login (whether passworded or not) seems realistic reasonable assumptions for 0.1: answer lines: 1 answer only
no multiple users: once you go to the page, you're logged in as default user
Categories: default, with default distribution (e.g. Science, Lit, Hist, RMP, etc.) predefined
Bonuses: all 3-part 10/10/10
Packets: can be randomized later, default view is by category No importing, minimal exporting
Things to focus on:
Getting saving working (hee hee, gerunds)
making entry convenient (and eventually stylish) Attaching them to packets properly (and eventually stylishly)
Use Patent Claims
Include Install Instructions
These details are provided for information only. No information here is legal advice and should not be used as such.