
On Tue, Nov 14, 2006 at 07:48:14PM -0800, Jon Phillips wrote:
- "Paint by Number" projects
============================== I think the reason our roadmaps, bug/rfe trackers, etc. haven't worked at getting more people contributing, is because oftentimes the procedure for doing the fix or implementation is extremely obscure.
yes, majorly!
From my own personal experience, the codebase can be quite difficult to
understand until someone gives you some clear guidelines. Sometimes 90% of the effort is just figuring out *what* to do.
Yes, especially with all the migration and refactoring going on...
But if an experienced core developer put in 1 hour just describing how to do a task, then later someone with less experience could use that description as a map to doing the solution.
Yes, especially with really big tasks...this outline would help many many people.
It may seem that this would be inefficient - it may take less total manpower for the developer to just do the work directly. However, for the core developer, they could probably outline several tasks in the time it'd take them to complete one. Even more importantly, the end benefit is that the new developer gains expertise that may enable them to contribute more in the future.
IOW, "Give a man a fish, he'll eat for a day; teach a man to fish, and he'll eat for a lifetime."
An interesting experiment would be for a core developer to spend a day going through bugs or rfes and rather than investigate them, to simply describe the steps they themselves would take to do it, and encourage others to give it a shot. Then later look back and count how many of the tasks were able to be completed by someone else. I bet we'd see a large net gain.
I agree...I wish I knew the complete codebase better, but will start to do more on the tasks I could do. Others, what do you think? Maybe we could make a day for this...like the day of painting by numbers and just use this as our general strategy for bugs for devs. Thoughts?
Ok, Bryce, this is an awesome list. Lets put some of these into a plan of action. What do others think?
Here's some thoughts on plans around the paint by numbers idea...
1. Select (say) 3 areas in the codebase to focus on, that + There are many bugs/rfe's of relevance + Core developers think are important to be worked on + Won't be too intimidating to novices + Several people already understand moderately well
2. Write up a few paragraphs describing what our objective is, and how to define a "paint by numbers" project.
3. For each area, create a short guide page that collects tips, tricks, links to more info, contact persons, etc.
4. Assemble listings of bugs/rfes in each of the target areas + Group by topic, filter out top priorities, sort by difficulty + Identify ones to be turned into "Paint by Number" projects
5. Recruit the people who understand the areas + Explain what the goal is - getting more developers involved + Email them the stuff from #2 + Ask if they could go through one section of the above list and describe the steps to be taken + Mark items as ready once someone's described them
6. Invite new developers to help undertake the projects + Write posts on our PR channels identifying cool tasks + Recruit from past patch contributors + Recruit from newbies on mailing list or irc channels + Point interested people at the info from #3 + Follow up with them to see if they've run into any issues you could help them with
7. Give thanks to each person who participates
Bryce