Development process improvement/Pages organization

Requirements
Content
 * greater emphasis on the two things people care about most: status and roadmap.
 * One page that links to all of the other important docs
 * No initialisms/acronyms in page titles.
 * a conspicuous banner on top identifying it as a WMF project page, and not an extension/manual page.
 * Project specifications, documentation, feature requests should be in subpages where possible.

Basic project information
 * Project page template should have in infobox on the side with the following Project information:
 * name
 * team
 * start and end dates
 * category magic

Classification
 * Per quarter categories (automatic using template dark magic if possible, to lower maintenance)
 * Time-based category should appear only on main project page not on content subpages
 * Categories with unambiguous names
 * We should not rely on subpage convention for categorization: Make one category per project (which will appear on all pages)

Location
 * All project pages on a single wiki
 * Project pages go under main namespace, e.g. Article assessment, Liquid Threads
 * But detailed documentation can be elsewhere, e.g. on wikitech:

Structure
 * An index of some kind (or master category) for all pages

Maintenance
 * As little maintenance as possible

Relation to extensions, subprojects & releases
 * Different phases or a project, and subprojects, should be regarded as different projects
 * e.g. We shouldn't have "Article feedback", "UploadWizard" or "Analytics upgrade", but "Article feedback pilot", "UploadWizard 0.1" and "udp2log deployment"
 * Project page template should link to the extension's page, if it exists

Information: That's really all we need as far as tracking is concerned. The link can lead to a more detailed page (on mw.o or elsewhere, say, wikitech) with even more links if needed.
 * Group (features, general engineering, operations, fundraising, mobile, offline)
 * Project title
 * Project short description
 * Link
 * Status
 * Status history
 * Roadmap, target date
 * Team
 * Program manager

Places to display these pieces of information:
 * Monthly reports
 * Individual project pages
 * Wikimedia engineering projects (formerly WMF Projects) (basically, the same as monthly reports, but formatted differently)
 * ⇒ Information can be stored in a template and individual piece accessed through a #switch to be displayed appropriately

Problem statement

 * The Wikimedia Foundation engineering team has stated a will to use an Agile methodology, but doesn't have the proper tools to implement it.
 * There is a lack of distinction between the different versions, or phases, of each Wikimedia engineering project. Some hackish workarounds include time-based labels (e.g. "2010 Q3 plan") or ambiguous names (e.g. "LiquidThreads v2"). This is causing several issues:
 * the difficulty to track the status and roadmap of projects
 * the difficulty to report or fix bugs, since bugs may refer to different versions, in which the bugs may already have been fixed.
 * incorrect or misleading information (e.g. Extension:LiquidThreads lists the WMF team members as contacts, although these contacts refer to the current work being done, and not to the released extension, which is the subject of the Extension page).

Proposed solution

 * Use of version numbers / milestones to disambiguate between different states of features & projects
 * For projects where version numbers aren't appropriate, use phases (phase 1, phase 2, etc.) but generally prefer version numbers. "Phases" are more appropriate for operations projects.
 * Echo these version numbers in bugzilla for easier bug tracking & feature planning
 * Use "mysterious future"-like version for unplanned features.

Advantages:
 * easy to implement, easy to transition from later
 * more relevant bug reports
 * increased transparency
 * increased efficiency: goals for each phase / version

Drawbacks and ways to mitigate them:
 * switching costs: limited
 * other?

Example

 * The current LiquidThreads extension is released as version 2.0.
 * In 2010, the Wikimedia Foundation decided to "adopt" LiquidThreads and to support its development, in order to assess its wider use as a discussion system on Wikimedia projects. A major redesign of the interface was started, labeled inconsistently as "LiquidThreads v2" (sic) and "LiquidThreads redesign".
 * In 2011, the decision was made to not only redesign the interface, but also make major changes to the back-end. Neither of these changes have been specifically labeled besides a generic "LiquidThreads rewrite". Since both are going to significantly change the feature, these changes should be bundled under a "LiquidThreads 3.0" label.

Implementation
Almost none of the WMF-supported projects currently underway have been specifically labeled. A first step would thus be to assign release numbers to all of them. The next step will be to continue to increment version numbers as development continues.


 * Go through Category:WMF Projects 2011q1 and assign version numbers in collaboration with developers & EPMs
 * Add version numbers / phases to the template for project pages

Community-led projects
It would be nice to record them somewhere; or even include them in the new structure?
 * Deglobalization
 * WMF Projects/New auth designs

Project categories

 * Category:WMF Projects → Category:Wikimedia engineering projects
 * Category:WMF Project Proposals → Category:Wikimedia engineering projects proposals
 * Category:WMF Projects 2010q3 → Category:Wikimedia engineering projects active in 2010-Q3
 * Category:WMF Projects 2010q4 → Category:Wikimedia engineering projects active in 2010-Q4
 * Category:WMF Projects 2011q1 → Category:Wikimedia engineering projects active in 2011-Q1
 * WMF Projects → Wikimedia engineering projects

Engineering reports

 * Put them all in Category:Wikimedia engineering monthly reports
 * WMF Engineering Overview October 2010 → Wikimedia engineering report/2010/October
 * WMF Engineering Overview November 2010 → Wikimedia engineering report/2010/November
 * WMF Engineering Overview December 2010 → Wikimedia engineering report/2010/December
 * WMF Engineering Overview January 2011 → Wikimedia engineering report/2011/January
 * WMF Engineering Overview February 2011 → Wikimedia engineering report/2011/February

Dependent project pages
These pages shouldn't be attached to their parent pages.

Note: fix double redirects.