Technical Collaboration Guidance/Community decisions

This is a recommendation for software projects following the Technical Collaboration Guidance (TCG). The TCG contains advice that 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 works with the wider communities to design and develop 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 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 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 proposed blockers may have a big impact in a software project, also (or precisely) in cases of questionable relevance or legitimacy. Therefore, proposed blockers aiming to change the course of a software project should meet certain quality criteria:

• 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
• The report must 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 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.

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 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:

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

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

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 proposed blockers are tasks filed in Phabricator).

• Development teams participate in the discussion about the proposed blockers (whether they are sensible, consistent with the project, actionable, realistic…).
• If the development team accepts that the proposals should block deployment, and then 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.