Jump to content

WMF product development process/Communities

From mediawiki.org

Overview

[edit]

Wikimedia Foundation Product Development has a set of phases that centers on tasks and potential stakeholders involved. The high level draft presented is a set of tasks and stakeholders involved in our current and future development.  This was evolved from an earlier draft review that incorporated feedback from multiple processes and expectations.

The tasks and stakeholders presented are a general guideline and potential checklist.  Each team may have its own mix of responsibilities or stakeholders, and some phases may not apply.  Community involvement or interaction is expected throughout the phases, ideally through established team or feature feedback mechanisms and in collaboration with our Community Liaisons.

Stages of the process

Understand

[edit]

Generative research and a checkpoint where you get to know users and their context. This is where you define problem & opportunities and analyze and synthesize (see patterns, gain insights) understanding. Understanding could come from our communities, Community Liaisons, internal Product Audiences, Design Research, Research & Data, Partnerships and Communications.

Communities and communication checklist - Understand
  1. The investigation to define a problem is documented in public
  2. Relevant stakeholders have been invited to participate in the discussion
    • If there is prior discussion, it has been reviewed
    • Discussion is facilitated/mediated as needed
    • Participate in the determinization of results
  3. Impact on user workflow has been researched
    • These results have been discussed with those it would impact

Concept

[edit]

New feature proposals and submissions for current problems or new ideas.  These items could involve or be generated from areas like general discovery or ideation, research, technical debt and/or strategy.  Submissions could come from our communities, Community Liaisons, internal Product Audiences, Design Research, Research & Data, Partnerships and Communications.

Communities and communication checklist - Concept
  1. This solution has been presented for discussion
    • This solution takes into account its shortcomings and explains them
    • This solution takes into account its benefits and explains them

Plan

[edit]

Planning and prioritization involve defining the inputs (people, forecasting, resources), outputs (tasks), outcomes (metrics), defining milestones, dependencies and maintenance tasks. These tasks are driven by Product Managers, Engineering and User Experience and may include participation, validation or checkins with Communications, Team Practices, Security, Community Liaisons, API/Services, Release Engineering and Legal teams.

Communities and communication checklist - Plan
  1. Initial roadmap is determined, published, and communicated
  2. Have a rollback/revert plan - as simple as "We are willing to"

Develop

[edit]

Backend and front-end development takes place and carry the selected concept forward to implementation.  Quality and performance are important checks.  If any issues or bugs are found the feature may roll back to Design depending on the severity of issues found. Testing via labs, prototyping, a/b tests, surveys, flow analysis, user sessions, and community validation of progress. The tasks are driven by Product Managers, Engineering and User Experience and could include participation, validation or checkins with Research & Data, Architecture and Operations, Data Analyst, Community Liaisons, Operations, Team Practices, API and Services, Performance and Architecture. Bugs, analysis and feedback in this round can send features back to the design phase.

Communities and communication checklist - Develop
  1. The product accounts for community moderation tools (+sysop, oversight, checkuser, abuse filter, etc.)
  2. Wireframes and/or prototypes have been communicated
  3. Bugs identified as blockers before by CLs and/or communities are discussed and fixed
  4. Performance and quality notes are taken and communicated
  5. Translators are contacted about system messages

Release

[edit]

Reviews by dependent stakeholders from the concept stage to validate concept completion. Community review and initial feedback on the development may influence release & rollout timing.  Teams will be analyzing performance and adoption.  If any issues or bugs are found the feature may roll back a stage or two depending on the severity of issues found. Announcements or events may also be created around releases.  These tasks could apply to alpha, beta and production level feature releases. The tasks are driven by Product Managers, Communications, Community Liaisons, Release Engineering and could include participation, validation or checkins with Operations, Legal, and Security. Bugs, analysis and feedback in this round can send features back to the build phase.

Communities and communication checklist - Release
  1. Concept and resulting product are reviewed for completeness
    • This review is documented
    • Including translations
  2. Each stage of release has a feedback loop (alpha, beta, production)
  3. Determine order of release (which wikis on which dates)

Maintain

[edit]

After a feature is released ongoing maintenance is measured through feedback loops and analysis, retrospectives, metrics and impact reviews and identification of improvements. Community review and feedback on real usage and interaction is measured and teams will be analyzing performance and adoption.  Improvements or new features restart the process and planning and milestones will be created. The tasks are driven by Product Managers, Performance, Data Analysts, Design Research, Research & Data, Community Liaisons and Security. Any iterations to the product will result in the process restarting.

Communities and communication checklist - Maintain
  1. Document clear ownership of maintenance, even if that means documenting something is unmaintained/abandoned