"After GHOP: the plan" as posted in the other thread, except as a wiki page.

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

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:
    1. Task is proposed.
    2. Task proposal is reviewed, feedback given.
    3. Task is revised.
    4. Steps 2-3 are repeated until task is marked rtbc or won't fix.
    5. Accepted task is posted to the task-doing queue.
    6. Task is claimed by a student.
    7. Student has up until the time limit to do the task.
    8. 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.
    9. Task is completed and marked for review.
    10. Task is reviewed, and feedback given.
    11. Steps 9-10 are repeated until task is marked rtbc or otherwise approved as specified by the task ("deliverables").
    12. 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

webchick's picture

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.

  • Remove the requirement for the special project for managing the creation/review of task proposals. Instead, use the normal "post issues to issue queue" way of suggesting changes, and indicate tasks are "DROP tasks" when appropriate (we'll add another category to the "Categories" vocabulary on issues to handle this)).

    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. :)

  • Post DROP tasks to the issue queue that makes the most sense. SimpleTest for SimpleTest issues. CCK for CCK issues. For odd-ball and/or hybrid tasks ("create some module that doesn't eixst yet," "add hook_uninstalls to these 5 modules"), we probably need a "special" project for assigning these to like we currently do with the GHOP project. But this should be avoided if at all possible, since doing this cuts out the entire community who is /not/ actively monitoring that queue. I'm actually pretty -1 to those "hybrid" tasks anyway, as experience has shown that the more straight-forward a task is, the better.
  • Time limit for all tasks is a week from claim, or a week from last time work was posted, whichever is later. How does this work?
    1. Task is posted, marked DROP.
    2. User A posts a comment on February 01 saying, "I'm going to work on this" or whatever (oh, that's another thing. None of this "I claim this task" requirement crap :P), and assigns it to themselves.
    3. On February 03, User A posts some interim work. Timer resets on the task.
    4. Various people review, and task is marked back to "code needs work"
    5. By February 10, no new progress has been posted by User A. So User B comes along and says "Ok, I'll take it now" or whatever and assigns it to User B instead. The task's 7 day timer gets reset again, and User A loses the chance to finish the task unless User B also over-extends their time limit.

    I believe that this will accomplish the following:

    • Keep tasks from being locked in perpetuity, at least without some progress being shown.
    • Allow for more complicated tasks that take longer than a week.
    • Allow for people who are keen but have a lot of things going on and might not be able to plow through something in 7 consecutive days.
    • Eliminate the need for the significant overhead of fine-grained tracking of all task due date statuses.

    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.

  • Eliminate "importance", at least for now. It's quite subjective and I could see us wasting a lot of time debating back and forth on the merits of tasks. Maybe later if that "comment_alter_taxonomy" module or whatever gets finished, we could revisit this idea, and tag tasks as like DROP-Expert/DROP-Beginner or DROP-Importance-High/DROP-Importance-Medium. For now, let the tasks' difficulty/target audience advertise themselves by their titles, like all other Drupal issues.
  • Eliminate the tracking of karma points. Yes, I know this is going to be contentious. There are three reasons I suggest this:
    • We don't (and probably never will) have User Points module or its equivalent on drupal.org. We would therefore need to setup a separate site for tracking this kind of thing, and that gets very dangerous as pulling people into a "sub" community is the last thing we want to do. We rather want people to become more involved in the Drupal community itself.
    • Because of this, the only way to track these points would be with a manual (thus time-consuming) process. All potential task claimers/mentors would need to be registered to othersite.org, and be required to log in there every once in awhile to see what's going on. We all know how well this worked on code.google.com. ;)
    • in "normal" day-to-day Drupal work, there is no concept of karma "points." Only that of a karma "feel." For example, "cwgordon is really awesome at patch reviews" or "Boy, that boombatower person really knows his stuff about SimpleTest." The point of the program would therefore shift to building a reputation in the Drupal community, rather than a "score" or "tally" of things completed.

So. New workflow.

  1. Someone gets an idea of a bite-sized task that would take someone a week or less to complete (or finds one in the queue).
  2. They mark it as a DROP task, by tagging it and changing the title to DROP: [whatever]
  3. Administrators of DROP are monitoring a View that shows a list of all issues marked DROP. At their leisure, they can filter out any spectacularly bad tasks. All others should be given a chance to get vetted/scoped by the community.
  4. Person claims a task by posting a comment saying such, and assigning to themselves (let's not get picky about this; sometimes people forget... the main point is to state intent).
  5. Person who claimed the task posts interim work, community reviews. Repeat until RTBC.
  6. If more than 7 days have passed since person who claimed the task last posted w/ work attached, another person can come by and claim the task if they want.
  7. At the end of each month, a report is posted to the larger community much like our GHOP status reports, that highlights tasks that were done, who did them, and what the overall progress is. This helps keep the recognition factor, without resulting in a lot of overhead in maintaining point counts and the like. Other rewards might spring up from generous members in the community as well, you never know. :)

Whew. What do you think?

Angie:

birdmanx35's picture

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

birdmanx35's picture

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

birdmanx35's picture

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

catch's picture

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

cwgordon7's picture

I think the idea was: Drupal REALLY Open Participation

this sounds rad

beeradb's picture

count me in!

sounds cool, when time I'd

CorniI's picture

sounds cool, when I have time I'd participate as a student ;)