Development process improvement/Versions and phases

From mediawiki.org

Problem statement[edit]

  • The Wikimedia Foundation engineering team has indicated an intention to use an Agile development methodology, but doesn't have the proper tools to implement it. Adapting or creating such tools is not a priority at the moment.
  • 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[edit]

  • Use version numbers / milestones to disambiguate between different states of features & 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 and reduced ambiguity
  • increased efficiency: goals for each phase / version

Drawbacks and ways to mitigate them:

  • switching costs: limited
  • other?

Example[edit]

  • 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.

Numbering scheme[edit]

The numbering scheme is very much up to the developers & EPMs. Software versioning article on Wikipedia provides some context.

For projects where version numbers aren't appropriate, use phases (phase 1, phase 2, etc.) but generally prefer version numbers for software projects (e.g. Extension:CentralNotice should have version numbers instead of phases (2, 3)). "Phases" are more appropriate for operations projects.

Implementation[edit]

Almost none of the WMF-supported projects currently underway have been specifically labeled. Thus, a first step is to assign version numbers to all of them. The next step will be to continue to increment version numbers as development continues.

  1. Go through Category:WMF Projects 2011q1 and assign version numbers in collaboration with developers & EPMs
  2. Add version numbers / phases to the template for project pages
  3. Add version numbers to bugzilla for the appropriate products/components

Proposed labels:

Operations[edit]

Features Engineering[edit]

Content Quality and Editorial Tools[edit]

Discussions and Interactions[edit]

Multimedia Tools[edit]

General Engineering[edit]

MediaWiki development[edit]

Wikimedia analytics[edit]

Fundraising[edit]

Mobile[edit]

Offline[edit]

Retrieved from "https://www.mediawiki.org/w/index.php?title=Development_process_improvement/Versions_and_phases&oldid=476319"