Friday, May 2. 2008
Community-Driven Worklog? Anyone Interested?
Peter has suggested this before, and I think it's a great idea. Basically, Peter's gripe is that currently, there is no way for community members to propose new worklog tasks for either the MySQL engineering team, or more likely, the external contributor community, to work on.
As a little background, the MySQL Forge Worklog system is simply a public-facing, read-only interface which shows our internal development roadmap tasks. We have an internal Worklog system which our engineering teams use to track progress along various milestones and projects. The Forge worklog shows all tasks which have been marked as "public" in the internal system. You may be surprised to learn that more than 90% of our internal worklog tasks are marked public.
In the public Worklog system, you'll see tasks that have been assigned to a developer, tasks that are unassigned or in progress, and tasks that have been (tentatively) allocated to appear in future versions of MySQL (6.x, 7.x, 8.x, etc). It is interesting to browse the tasks on the worklog to get a picture of what the future of the MySQL server holds.
But, while it is great to be able to comment on these worklog tasks (simply go to a task, login to the Forge, and post a comment in the area to the right), that only goes so far. It would make things interesting if the community could truly drive the development roadmap itself by proposing and advocating for their own worklog items. And, I plan on making this a reality.
Taking Action - A Community-Driven Worklog
My wonderful team lead, Giuseppe, has given me the ability to focus on coding the Forge and PlanetMySQL this quarter. This means that I have the time to work on a community-driven Worklog system. Below, I give my thoughts on what I will add to this system, along with the help of Robert van der Mast, who I am mentoring in a Google Summer of Code project related to the Forge.
Keeping a Single Interface
One thing I want to ensure is that as much as possible, we keep to a single interface for viewing and editing all worklog information. My vision to enable a community-driven worklog system is to have a interface which adds new Worklog tasks into the public MySQL Forge worklog database and marks such additions as "PROPOSED BY COMMUNITY" or something like that, but having such tasks "mixed in" with the rest of the Worklog Tasks on the Forge. I don't really see a need for a separate "community worklog" module or similar. Agree? Disagree?
Ability to Assign the Task to an External Contributor
So, along with being able to propose a new worklog task, we would also need to be able to assign the task to an external contributor, so that people viewing the task in the worklog system would be able to know that the task is under development by someone. How should such a system work? Should we limit the ability of assignment to only Forge users? This seems to be a more reasonable capability than simply allowing a text box for entering someone's name... Should there be an ability to add more than one contributor? Should the list of assignable contributors include MySQL developers as well? What are your thoughts?
Your Feedback
I am very interested in getting feedback about this. Feel free to add a comment to this entry or email me at REVERSE('moc.lqsym@yaj'). Thanks, Baron, for the email obfuscation... 
Having the option to assign worklogs to only forge users would allow more flexibility to the system, like finding all worklogs assigned to specific users, etc.
And the option of having more than one users assigned a worklog would be very useful on bigger tasks.
that's a very good idea!
In terms of assigning worklogs I can see several models:
1) Anyone can assign anything to anybody. (the "Bazaar" model)
2) Only the creator of the entry can assign to or add people. (the "sourceforge" model)
3) The creator and "admins" can assign to or add people. (Admins probably being MySQL employees/developers)
In an ideal world, I would prefer model 1, but I think that would deteriorate rather quickly...
In reality model 3 is probably the best. It would be even better if "admins" doesn't only mean MySQL employees but also "core people" from the community. In that way it would work like most open source projects are run: By contributing good content or work people get "promoted" and gain more rights, because they have earned them. That way contributors wouldn't feel locked out and that's exactly the reason we want to have a public, community-driven worklog, right?
I think every worklog task should be assignable to any Forge user, and that includes MySQL devs. Of course there has to be a validation step with assignment, because this is a voluntary thing, not something your manager assigns to you
Specifically the assignee should be required to acknowledge the assignment.
There should be only one Worklog, I agree. Since people want to work with MySQL not against it (hopefully), we should strive to have one unified tool to manage it.
Eric, I'd love to see community trees hosted alongside the Worklog. That way the community would finally have a place where the various patches are united and accessible. In order to maintain some sort of order, I'd propose there should be a tree associated with each Worklog entry. It doesn't have to be a separate tree, but somewhere the patch should live, no?
CLA or no CLA. I'll leave that to the lawyers...
cheers,
-k
Calendar
|
February '10 | |||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
