Community Engagement (Product)/Collaboration process/Draft

This page is a drafting space to define and explain community engagement activities within product development. Its stages are currently incomplete.

Product teams include WMF staff across a range of expertise: product managers, engineers, designers, QA testers, design researchers, community liaisons. Due to the collaborative nature of the Wikimedia movement, community liaisons act as the bridge between communities and product teams: supporting clear channels of communication in an effort to work with communities as partners in product development.

Concept edit

New feature proposals and submissions for current problems or new ideas.

This phase presents and initially describes the impetus and logic behind any product or individual feature. During this phase, reasoning behind the feature must be defined, communication surrounding scope with users.

Things that the concept needs to communicate: edit

  • What is the problem we're trying to solve? (or, what is the opportunity being created?)
    • Include supporting data/information/strategic ideas
  • Who is this product intended for? (All users? All editors? New editors?)
    • Is there a where in here too? Some features may work more effectively in Commons, some may work only for Wikidata. Is it specifict to a locationation, such as all RtL languages?

Tasks to consider from CL perspective edit

There will be times when not all of these will be done, but this could serve as a potential checklist of to-dos

  • Phabricator tag created
  • Ensure MW documentation states the rationale clearly and presents necessary data
    • Support/follow conversation on Discussion pages of documentation
  • Survey, RfC or consultation
  • Newsletter/TechNews announcement
  • Discussion of ideas in appropriate channels

Plan edit

Things to communicate in this phase: edit

  • How does it need to function?
    • Try to identify technical constraints and blockers
    • Are there users, such as functionaries, who need accessibility?
    • Is this intended to change/fix/break any existing workflows for users?
  • What is the criteria for success?
  • What are the milestones to move from stage to stage?
  • Is there a minimum viable product?
    • Collaboration on defining use cases vs. edge cases
  • What do users need from this product/project?

Tasks to consider from CL perspective edit

There will be times when not all of these will be done, but this could serve as a potential checklist of to-dos

  • Recruiting users to Design research
  • Supporting feedback from users, clarifying with communities
    • Helping to triage requests
    • Supporting clear asks in the form of user stories or other actionable requests
  • Planning and regular meetings with product teams
    • acting as conduit for questions, concerns
    • bringing community perspective to meetings.
  • Supporting outbound communication from product teams

Process for community engagement per development stage (currently outdated) edit

Introduction and Concept Prototype and Review Evaluate Production Launch Maturing and Support
Tools and methods used
  • MediaWiki Product Page
  • Newsletter/Tech News articles
    • Setting up for product-specific news features (depends)
  • Community Consultation with clearly defined parameters (maybe)
  • Targeted sitenotice for notifications (?)
  • Notifications in relevant official communication channels
  • Coordination with Design Research
  • Targeted Talk Page messages
    • Pointing to Product Feature Pages
    • Pointing to Design Research
  • Newsletters and Tech portal updates
  • Product Talk Page conversations
    • Review with Product team
      • (standardized process TBD)
  • Working with Design Research
  • Watchlist notifications
  • Beta Feature notifications (Need to build)
    • General notifications?
  • Broad notification for affected users
    • Broad-scale notification
  • Guided Tour/screenshots/related information creation for launch
  • Product pages on MediaWiki for ongoing communication
    • Collaboration with Communications Dept
  • Working with Release Engineering to ensure timeframes
  • Site Notices/Central Auth
  • Guided Tours
  • TBD
Communications
  • Who is this product intended for?
  • What problem does this solve?/ Why is this feature needed?
  • Where - Which projects or language projects is this for?
  • When Timeframes, deliverables
  • How Technical constraints? Does this need to work in a particular way?
  • Change Is this product intended to change any workflows?
  • Is the feedback or request within scope of this project?
  • Checks across teams for legal/volunteer team issues (does it conflict with admin tools?)
  • Does this product inadvertently break or fix any workflows? (unintended consequences)
  • Notification of known launch dates
  • Watching for for last minute functionality and legal concerns
  • Working with Comms Dept for launch
  • Gauging user feedback
  • Base numbers of adoption rates, increased usage, faster load time (what’s working?)
  • TBD

Additional information edit