Development process improvement
|
Engineering processes improvement
Increase transparency and organize Wikimedia Foundation's engineering efforts more efficiently
|
Project justification
With the Wikimedia Foundation Tech department growing at the pace that it is, we need to figure out ways of communication with each other and the rest of the world about what we're doing, and how we're doing it. The communication & collaboration mechanisms we come up with should be appropriate for the scale of organization that we are, and facilitate collaboration with community volunteers to both increase the impact of Wikimedia Foundation employees, as well as ensure focus on issues that matter to the community.
Project deliverables
- Document summarizing the current situation, detailing the requirements, offering recommendations and outlining an implementation plan.
Topics to be covered
- Processes for communications & collaboration:
- within WMF engineering staff, in particular
- task tracking
- bugs vs. features
- project management, scheduling, milestones
- between WMF engineers & volunteer developers
- between WMF engineering staff & Wikimedia community, in particular:
- announcements
- between WMF engineering staff & research community? (optional)
- within WMF engineering staff, in particular
- Assessment & recommendation of tools to implement the strategy
- and recommended configuration of these tools
User goals
« Community »
(to split up into more specific groups, see above)
- understanding of what the Wikimedia Foundation is investing in
- ability to provide input into ongoing initiatives
- opportunity to identify and volunteer in areas where they are likely to have the greatest impact and assistance from the Wikimedia Foundation
Wikimedia Foundation employees and management
- ability to see the quick summary of how things are going; when intervention is needed and when things are sailing along smoothly.
Specifications
Software design document
Test plan
Documentation plan
User interface design docs
Schedule
A couple of different people have been thinking about this over the past few months. There was a formal evaluation process done by Rob Lanphier in May-June 2010. The last phase is planned to be completed by October 2010.
Input phase
- collect links to previous documents, discussions, resource pages, etc.
- review existing documentation: rob's pages, etc.
- discuss with stakeholders: Chad, MW devs, engineering staff
- ideal bug tracker? integration with MW, CodeReview, etc.
- we should have a concrete set of requirements at the end of this
Analysis phase
- determine a draft workflow consistent with Rob's proposed feature development lifecycle
- explore the implementability of this workflow with bugzilla & with (semantic?) mediawiki
- discuss it with Guy & other bugzilla folks?
- discuss it with Ryan Lane
- Alolita will demo how she uses XPlanner so that we can come up with a good system for timeline tracking and chart generation
- document, document, document everything we do, so the recommendations are traceable
Recommendations phase
Finish and publish the document
Task management
- Bug list related to our bugzilla setup
Release management plan
Community management plan
Status updates and notes
- Tracker/PM tool
- Summary of discussions with people at Bugzilla about using Bugzilla for Project Management
- 2010 Q3 assessment
- 2010 Q3 plan
- Prototype Xplanner: http://project2.wikimedia.org:8080/xplanner-plus/
- Prototype SMW: http://ryandlane.com/sandbox/Main_Page
- Prototype bugzilla http://project2.wikimedia.org/bugzilla/index.cgi
- Prototype Statusnet: none yet