Development process improvement/2010 Q3 plan

Short term project management goals.

Task tracking

From a tooling perspective, Bugzilla as currently configured isn't cutting it for us. Priyanka and Robla are evaluating alternatives. Ultimately, here's a list of things we're looking at:

• Must-have:
  • web-based (for collaboration)
  • multi-project
  • calendar/scheduling
  • assignments & resource management
  • time tracking per task/user/project
• Nice-to-have
  • Gantt charts
  • public/private projects
  • fine-grained access to projects by user
  • basic accounting & budget management
  • requirements management

In the short term, the processes and tooling should be optimized toward milestone-based releases, and give us flexibility to experiment with different methodologies within a milestone.

Need to address community interaction needs.

Project pages

Every significant feature should, at a minimum, have a page on mediawiki.org. "Significant" is a judgment call, but any project that involves more than one person for more than one week generally qualifies (though subtasks of larger projects don't need their own pages).

Sections for the feature pages:

• Feature justification
• User requirements
• Specification
• Software design document
• Test plan
• Documentation plan
• User interface design docs
• Schedule
• Task management (e.g. link to relevant Bugzilla queries)
• Release management plan
• Community management plan

Each bullet may be followed by " - yeah, that would be nice". However, note that anyone should be able to ask for more. They may not get it, but a good-faith negotiation should be made to fulfill the need represented by the request, and to document any information surfaced in writing.

More often than not, there should probably be at least a couple of sub-bullets under each of these with a miniature version of each. In some cases, it's going to be important to break the bullets up into their own sections and even own pages.

Some projects are going to require more process than others. Deadline-driven projects will require much more thought than other projects.

To the greatest extent possible, these pages should be maintained on a public wiki, such as mediawiki.org or meta.wikimedia.org, rather than on an internal wiki. This allows the community to collaborate. The wiki gnomes can flesh out feature ideas and help keep things tidy, organized, and up-to-date.

We'll be looking into Semantic MediaWiki to help keep this organized.

The project category

Rather than keep this information on a single wiki page, there should be a well-defined categorization scheme for the feature pages. An "Archive:" namespace should be created, and feature pages that are known to be outdated should be moved into this space without hesitation (if someone wants to update it, they can move the page back).

If there are MediaWiki tricks that make it easier to compile a table rather than just the standard category, those tricks should be considered so long as the result is still maintainable. Custom MediaWiki extensions should be considered to help build a table.

The roll-up

There will be a page which rolls up the significant projects in progress, and reports basic status information. This is a well-organized one-page printed document that clearly and accurately summarizes the current engineering activity of the organization, not a dumping ground for large quantities of detailed documentation that may be less current or not as well organized. That said, it needs to inspire confidence that there is plenty of well-vetted detail work behind the one-pager (i.e. one page of vague hunches isn't so useful).

The EPMs will be responsible for pulling this together, drafting it, and posting to the techblog.

Note: this is not a comprehensive list of every half-finished project that people are waiting on. This is purely a statement of "what is engineering working on right now", and an optional small section "what is engineering not working on that everyone is asking about".