Wikimedia Product Guidance/Community involvement

The Wikimedia Foundation understands that community involvement in the design and development process is paramount to fulfilling our mission to provide essential infrastructure for the wiki projects. Foundation Product teams intend to be collaborative and receptive to feedback throughout the life cycle of a product.

Early feedback

Foundation Product teams should collaborate and share information with the communities about software features considered, as early as possible in the project timeline. The communication of proposals can include goals, plans, early designs and other information.

Community members may provide feedback about specific products and features from their early stages, through the communication channels supported by the project. Ideally, problems that have the potential to block further development will be identified at that stage, but sometimes concerns will not surface until the development phase.

A "blocker" is a bug, missing feature, or other problem that the development team decides should temporarily block deployment at some or all wikis. Communities are invited to submit bug reports and other concerns that they have, so that the development team can determine whether those problems should affect the deployment plans. A proposed blocker can have a big effect on a project, even if the proposed blocker has questionable relevance or legitimacy. Therefore, in order for a proposed blocker to be considered as possibly changing the course of a software project, it should:

• be filed in the related Wikimedia Phabricator project or MediaWiki.org project page, and be identified explicitly as a proposed blocker, to distinguish it from other bugs or feature requests.
• be consistent with the bigger picture: Wikimedia's mission, principles, strategy, annual plans, supported technologies, etc.
• demonstrate familiarity with the project plan and actual use of the feature when available.
• be actionable, e.g., "It doesn't work on this device" or "This product doesn't support oversight functions", rather than "I just don't like it" or "I think this product is a waste of money".
• use constructive arguments, data, actionable alternatives, and collegial tone.
• provide proof of a community consensus when speaking in the name of a community.
• take prior discussions and agreements into account. There must be very good reasons to re-open a settled topic.

The same quality criteria are expected from the developers or other contributors disagreeing with these proposed blockers.

Ultimately, the final decision about whether each proposed blocker should actually block development or deployment belongs to the development team, not to communities.

Deployment on individual wikis

During the development cycle, there is a point when features are released to targeted users. When a feature is being released to the wikis through publicly documented deployment waves, communities can influence the best timing for the deployment of a product or major feature in individual wikis:

• Communities pleased with a new feature or product can request to be included in the first waves, after showing proof of interest in their community discussion channel.
• Communities with specific concerns or internal discussion can request to have the deployment to their wikis delayed to a later wave by following the process outlined below.
• Communities with no strong opinions will be scheduled by the development teams.

It may happen that one or just a few communities will keep pushing back a new product or feature, while all the rest are satisfied with it. The likely scenarios are that either the new product or feature will keep spreading until reaching full coverage, or the community's concerns will ultimately persuade the development team to change the product plans.

In order to delay the deployment of a new product or feature in an individual wiki, the local community must provide a link to a community discussion and the list of actionable bugs, missing features, or other problems that they would like the development team to consider for "blocker" status. (Ideally, all proposed blockers are tasks filed in Phabricator.)

Development teams participate in the discussion about the proposed blockers to determine whether they are sensible, consistent with the project, actionable, realistic, etc. If the development team decides that none of the proposed blockers should delay deployment, then the deployment will proceed. If the development team decides that some or all the proposed blockers should delay deployment, and then addresses those proposals, the community will be asked for a new review. If no surprises are found, the deployment will proceed.

Some software deployments and most software removals are mandatory. Some deployments, such as offering a new API, cannot be handled as successive waves of deployments over time (instead, these deployments happen everywhere at once). In those cases, local communities will not be able to influence the timing.

Local configurations

Some local configurations can only be set server-side, usually by Foundation development teams. In some cases, separate configurations can be set for logged-in users and anonymous users. Generally speaking, core community members can represent their own interests well, while development teams can bring data and analysis about readers and other contributors.

Given these circumstances, communities should have a chance to discuss these local configurations, in these terms:

• Communities have priority for defining the first configuration to be tested for features primarily affecting experienced contributors.
• Wikimedia Foundation teams have priority for defining the first configuration to be tested for features primarily affecting readers and new contributors.
• Goals and data gathered need to be included in the release plan, and the data gathered needs to be shared (unless there are privacy concerns, which should be explained in the release plan).
• If an initial configuration is not producing the expected results, the development teams can test alternatives before they settle on a stable configuration.
• Ultimately, the responsibility for defining product configurations belongs to the Wikimedia Foundation.

Thank people

Volunteer time is a scarce and precious resource. Thank people for constructive feedback, even if you ultimately disagree with their advice. If an individual volunteer contributes significantly to your project, be sure to acknowledge their contributions, just like you would acknowledge a similar contribution from a fellow staff member who worked in another team. The Language team does this consistently by including acknowledgments and highlighting volunteer contributions in bold in their monthly reports (example).