View Thread > H2O Meta > 0.5 Feature Priorities > Priorities
Now that we have a list of potential features, the next step is to prioritize
which features should be implemented in the 0.5 release and in what order. Each feature has a guestimated number of days associated with it. We have about 120 developer days before a release in mid-February. Your job is to pick out which features should be included in the next release (all of your features should only take 120 days to complete) and then, *very importantly*, to prioritize when those features should be implemented. Once we set a concrete release date in February, the release date will be firm, while the number of features we complete will not, so the priority of the features will determine which features will definitely get into the release and which may not.
As our esteemed leader, Jonathan Zittrain will be ultimately responsible for putting together the final list of priorities for the release, but the feedback we get from this discussion will play a very important role in his decision.
For the list of features, see:
http://h2odev.law.harvard.edu/viewcvs/*checkout*/h2o/docs/plan/feature-priorities.csv?rev=1.6
In terms of a functional tool that will be used by professors, teachers, and other distance and face-to-face educators, it seems that there are a few major priorities. A reliable system is at the top of that list, with good management tools shortly behind. I see management as including things like adding users, deleting projects, searching posts, adjusting how questions get routed, etc. At a still important but somewhat less so level, I include improving UI for the users, so that students can understand the system with a minimum of hand-holding by the instructor/TA. (And for general happiness in using the system.)
Based on these ideas, I have selected the features from the larger that best seem to meet these requirements. I have added to the priority field of the items I chose, with 1 = highest priority, 3 = lowest. My total comes out to 118 estimated days.
I hope this is helpful!
H2O Feature option,,,
Priority,Type,Time,Description
1,Rotisserie,15,Full text rotisserie post search
1,Directory,10,"Project section support (management, display, integration with UI, routing)"
1,Rotisserie,10,Add crank error cases - better error testing for the crank
1,Directory,5,Bulk user load (allow administrator to load users from a CSV file)
1,Directory,5,Bulk project acceptance page -- a single page with all applicants to a project with a 'reject' and an 'accept' column that lets a leader accept/reject users en masse.
1,Rotisserie,3,"User visible round crank -- allow project leaders to manually crank a round instead of waiting for the round duration to end. We have this implemented in a way that developers can access it, but it's not simple or well tested enough for users."
1,Directory,3,Project Deletion - ability for the project owner to delete a project.
2,Rotisserie,10,Manual adjustment of response routing - allow a project leader manually to assign any post to any student during a time between the routing of posts and the sending of the routed assignments.
2,Rotisserie,5,Creation of rotisserie from templates - copy from another rotisserie to start the creation of a new one
2,Content,5,"Help Content - first stab at help, including at least help on all the forms"
2,Rotisserie,5,Add absolute date picker to date fields and to round start/end (so that the user can choose either round durations or specific end dates)
2,Directory,4,Project announcements. Includes a form for project leaders to enter them and display of them on the home page and the project profile page.
2,Directory,3,Confirmation of email change - email is only confirmed during registration currently. It would be nice for it always to be confirmed.
2,Rotisserie,3,Self ratings for posts - allow a user to rate his own post as particularly interesting and maintain this rating separately from other ratings. This feature allows a student to mark his best work so that a viewer can have a good idea of which post to view from the user's profile page.
2,UI,3,"Help system infrastructure - support for inluding '?' links in the module headers, which link to popup help content"
2,Rotisserie,3,Additional questions in rotisserie rounds -- allow project leader to add a question to each round
2,UI,3,Current Projects box from exxtreme front page mockup -- includes summary of current projects with links to assignments and announcements.
3,UI,5,Improve ui of view rotisserie page to use as much of the exxtreme ui as possible -- the exxtreme ui for this page is much cleaner
3,Directory,5,"More project privacty options: Show questions, but not answers; Show questions and answers, but not participant profiles; show profiles, but not emails"
3,Rotisserie,3,"Random routing with no repeats within a project (easy best try - Joe should not be assigned to Sue more than once within a given project, we'll give preference to non-repeat assignments but won't implement a complicated algorithm to try to guarantee it)"
3,Directory,3,Show all visible posts written by the user on the user profile screen page (and get rid of the contextually driven stuff that's confusng and poorly done). Group posts by project / rotisserie
3,Rotisserie,3,Improve dates in alerts. Include absolute due date in assignments (7/12/2002 5:13 intead of just 24 hours). Round to nearest hour when within a couple of minutes (to avoid the 23 hours 59 minutes thing). Convert to whole days when appropriate (1 day 6 hours instead of 30 hours).
3,Rotisserie,2,Word count support on response page - provide a word count button to help participants manage the length of their posts.
3,Directory,1,free text search for users ('hro' should return 'hroberts')
3,UI,1,Include 'Current H2O Time' somewhere in header.
The reasoning behind this prioritization scheme is clear and very helpful.
A comment on the user visible round crank which is listed as priority 1: this feature is problematic in that participants may be in the middle of composing their response when the round is prematurely cranked. Although participants may have submitted a response, it may be partial, and the participant may have intentions to edit it before the round deadline. If we implement this feature, we need to include a warning mechanism with a reasonable duration before the premature crank takes place...
I hadn't thought through both the engineering and usability issues associated with a premature crank. Your comments on possible ramifications are important to consider. Perhaps the system itself would not need to have the built-in delay for warning users, but rather this could be part of the documentation for such a feature? It would likely reduce the engineering issues, and give the instructor the freedom to choose how much warning to give students of a premature crank.
On reflection, except for pretty unusual circumstances (perhaps the instructor was not familiar with how the rotisserie worked and allocated too much time for a round), I don't see a huge need for this feature. I would recommend dropping it in on my priority scale down to 2 or even 3.