Technical Collaboration Guidance/Community decisions

This is a recommendation for software projects following the Technical Collaboration Guideline (TCG). It might be useful to address problems related to products and features developed before or outside the TCG, but the processes described will work better when a project has followed that guideline since their inception.

Early feedback
The Wikimedia Foundation designs and develops software as part of its mission to provide the essential infrastructure and an organizational framework for the wiki projects. This development must be collaborative and receptive to feedback throughout the life cycle of a product.

Foundation Product teams should, as early as possible in the project timeline, share information about projects with the community. This communication can include goals, plans, early designs and other methods of communication.

Communities may provide feedback about specific products and features since their early stages, through the communication channels supported by the project. Ideally, frontal blockers (problems blocking further development) should be identified at that stage. Communities can also propose blockers about implementation aspects during the development phase.

The submission of blockers may have a big impact in a software project, also (or precisely) in cases of questionable relevance or legitimacy. Therefore, blockers aiming to change the course of a software project should meet certain quality criteria: The same quality criteria are expected from the developers or other contributors disagreeing with these blockers.
 * A report filed in the related Wikimedia Phabricator project or MediaWiki.org project page, identified explicitly as a proposed blocker, distinguishing it from other bugs or feature requests.
 * Consistency with the bigger picture: Wikimedia mission, principles, strategy, annual plans, supported technologies…
 * Demonstration of familiarity with the project plan, and actual use of the feature when available.
 * Use of constructive arguments, data, actionable alternatives, and friendly tone.
 * Proof of community consensus when speaking in the name of a community.
 * Prior discussions and agreements need to be taken into account. There must be very good reasons to reopen a settled topic.

Ultimately, the responsibility to define whether a problem reported is a blocker or not belongs to the development team.

Deployment on their 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 their wikis:

It may happen that one or just a few communities will keep pushing back a new product/feature while all the rest are happy with it. The likely scenarios are that either the new product/feature keeps spreading until reaching full coverage, or the community concerns grow and ultimately force a change of product plans.
 * Communities excited about 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.

In order to delay the deployment of a new product/feature in their wikis, communities must provide a link to a community discussion and the list of actionable blockers proposed (ideally, all blockers are tasks filed in Phabricator).


 * Development teams participate in the discussion focusing on the proposed blockers (whether they are sensible, consistent with the project, actionable, realistic…)
 * If the development team solves the blockers, the community will be asked for a new review. If no surprises are found, the deployment will proceed.

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, communities can represent their own interests well, while development teams can bring data and analysis about readers and other editors.

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


 * Communities have priority defining the first configuration to be tested for features primarily affecting existing editors.
 * WMF teams have priority defining the first configuration to be tested for features primarily affecting readers.
 * 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 must be shared beforehand in the release plan).
 * If an initial configuration is not providing 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.