Posted below is that plan as a wiki page. Everyone, feel free to edit it; just don't start a flame war ;) .
===
Ok, it sounds like people think this is generally a good idea. Here is a rough draft of how it's going to work. Nothing here is set in stone: I'll let everyone else argue over the specifics ;) .
- Two projects on drupal.org: one for proposing short-term tasks, another for actually doing them. The advantages of this are:
- We get to use drupal.org's project trackers.
- The task proposal and task doing stay separate.
- Proposed tasks get reviewed by the community, and once marked rtbc, moved over to the task-doing issue queue.
- Tasks have several things they didn't have before:
- A time limit:
- It can be variable, as some tasks may take longer than others.
- It's still good to have, because it keeps things moving.
- An importance factor:
- Some tasks are simply more important than others: making bluemarine recolorable, for instance, is of far more importance than porting module X to Drupal 6. (Maybe importance isn't the right word... impact? difficulty? educational?)
- This way the students who claim more adventurous tasks aren't penalized.
- Workflow:
- Task is proposed.
- Task proposal is reviewed, feedback given.
- Task is revised.
- Steps 2-3 are repeated until task is marked rtbc or won't fix.
- Accepted task is posted to the task-doing queue.
- Task is claimed by a student.
- Student has up until the time limit to do the task.
- If the task isn't finished by the time limit, attempt to contact student; allow three days in which to that. Extensions may be granted.
- Task is completed and marked for review.
- Task is reviewed, and feedback given.
- Steps 9-10 are repeated until task is marked rtbc or otherwise approved as specified by the task ("deliverables").
- Task is finished.
- Notes on workflow:
- Students may work on more than one task at a time.
- If a task has been waiting more than three days for review, the task's owner gets negative karma points.
- Students may claim tasks they've proposed.
- The term "Students" does not just apply to 13-18 year olds: everyone is a student of life.
- Drupal dojo: the dojo may become more and more involved in this as we go on. I think it's better to start them off as separate things and watch them naturally merge together rather than try to force cohesion where it might not belong.
- Who's running this thing? Anyone who wants to. Anyone can review task ideas, as well as tasks themselves. In the case that no one contributes (which I'm sure you won't do), I'll step in to review task ideas, etc.
Comments
A counter-proposal
We spoke at length about this in IRC, so I'm just summarizing for everyone else's benefit.
This proposal maps pretty closely to the way the GHOP contest was run. In general this is a good thing, as the contest was clearly a rousing success. However, in terms of raw overhead it's a very bad thing.
I can't speak for other admins, but I know of my 5 hours/day I allocated to managing this program, 4.5 of them were spent on various administrative stuff (writing/editing documentation, changing task statuses, sending emails to students/mentors reminding them stuff is due, keeping up on the ghop admin mailing list, bugging people for task ideas/reviews, etc.), and only .5 on actual review of students' work. :( That really sucks. :( This overhead makes sense in the context of an international contest; there's money at stake, if someone takes issue over a decision there needs to be a record of what happened, etc. But I would much rather, now that GHOP is pretty much over, have this map more with Drupal's core development processes, as that's much lower overhead, and also a better match for our community.
Logical concerns that might arise from this decision are:
Q: But what if crappy tasks are marked DROP?
A: We either remove the DROP category assignment after the fact, or we mark it "won't fix" if it's a crappy task altogether (e.g. "Make Garland 100x more ugly than it currently is" ;)).
Q: But what if the task lacks details and it's unclear what all is involved?
A: Then we handle it like we handle any other feature request/bug report that's unclear: mark it active (needs more info) and ask clarifying questions.
Basically, if enough people are monitoring this program, either of these situations should be resolved almost instantaneously. And in the meantime, tons more tasks can be created unimpeded, and folks can start working. :)
I believe that this will accomplish the following:
The only people who need be concerned with the due date of a task are the person who claimed it, and the person who wants to claim it but currently can't because it's already claimed, if such a person exists. For everyone else, it's a non-issue. If the person who claimed the task fails to post work by Feb. 10, and no one else claims it in 6 months, User A can come back and post the finished results. Who cares? The task gets done. ;) The main point is not to stop User B from working on it if they're so-inclined and User A isn't. So this rule sets a guideline that allows them to take over the task with no hurt feelings.
In summary, for all intents and purposes, the only person who cares about the deadline of a task is the person who wants to claim it. They either hold off, if the task's still in progress, or claim it if the 7-day deadline has passed.
So. New workflow.
Whew. What do you think?
Angie:
First of all, thank you for you and the other admin's commitments; it's very much appreciated. I could go on and on about the things this opportunity has provided for me, but suffice it to say I appreciate it.
Second, you're right; since it's our project, we don't have to run it like Google's, and I think that this method will suffice for most tasks. You've both said it all, but I'm glad to help in anyway.
We should have a name brainstorm sometime.
Also
I think that View that you mentioned should be open to the public... having different issue queues is fine, as long as everyone can view them all in one place.
Also, your points on the UserPoints thing makes sense.
And One More Thing
Haha, sorry about the multiple comments here. I just wanted to say that there needs to be a simple way for you to tell how long it has been since a task has been claimed. Maybe some kind of block?
webchick's counter proposal
webchick's counter proposal sounds great. Agree that layers of complexity are best added when needed later, if at all, 7-day rolling deadlines and lack of karma points also good.
Once this is up and running it'd be good to get this included alongside Patch spotlight/bingo and the rest so it's a one-click from the contributors block for day-to-day issue queue workflow, as well as the monthly report (although I'm not sure this should be monthly, monthly stuff can be hard to maintain and easy to filter out, but regular updates are sound anyway).
Are we actually going to call it DROP then? It's ideal, but it's a bad acronym.
Drupal Mentoring Programme :(
DROP
I think the idea was: Drupal REALLY Open Participation
this sounds rad
count me in!
sounds cool, when time I'd
sounds cool, when I have time I'd participate as a student ;)