Development process improvement/Communications recommendations

From MediaWiki.org
Jump to: navigation, search

Over the past few years, volunteer developers of the MediaWiki software have perceived an increasing gap between the Wikimedia Foundation (WMF) and them. This gap has been especially visible in two main areas:

  • Users have felt neglected and ignored when they asked for bugs to be fixed or features to be implemented. They don't have a clear understanding of the best way to have an impact on technical decisions, or what WMF engineers are working on (and why).
  • Unpaid developers have perceived isolationism from paid developers. They too feel excluded from discussions and decisions, notably as a result of paid developers heavily relying on synchronous communication (online or IRL), instead of more conventional asynchronous communication channels unpaid developers have been using.

Until recently, the WMF lacked the financial and human resources required for a real product strategy that could satisfy its community of users. With a more stable financial situation, the WMF is now engaged in the process of growing its technical department in order to better support these users. It will be the role of the newly-established Product Strategy department to establish productive ways to engage in two-way communication with users (and other stakeholders) to identify the technical projects the WMF engineers will work on[1]. Still, efforts remain to be undertaken to be more transparent and efficient in one-way communication such as technical announcements. The first part of this document provides some recommendations on this topic.

About the second issue (isolationism of paid engineers), long-time community developers have rightfully argued that the best way to close this gap is for paid developers to work as closely as possible to unpaid developers, and to really be a part of the developer community, instead of just "getting feedback"[2][3]. The second part of this document provides recommendations about how to work towards this goal.

Tech announcements[edit]

One of the challenges faced by the development and operations community is how to communicate with their users: the local communities of more than 700 wikis using their software and their platform. Software updates or infrastructure changes sometimes need to be advertised to allow users to prepare for them. In the past, the use of inappropriate communication channels has led to information being too prominently displayed or, on the contrary, being lost.

Wiki-independent channels[edit]

The following venues should be used only for important announcements:

Large wikis[edit]

The largest wikis have community newspapers or other announcements venues. They also have dedicated mailing lists (activity varies). On the other hand, they have a large audience, who may not like disruptive announcements like the use of CentralNotice.

Almost all tech announcements can be left at or sent to the following places:

On wiki pages, English can generally be used; the message will be translated by local volunteers. Translations are preferred on mailing lists.

The use of CentralNotice is discouraged on large wikis because of its disruptive nature and its annoyance potential.

Medium and small wikis[edit]

Smaller wikis may not maintain a community newspaper, or may not even have a local Village pump. The Distribution list on meta provides links to the village pump where it exists, and to other pages likely to get attention from the local community if there is no village pump (for example, the Community portal or the talk page of the wiki's main page). If this approach doesn't work, it's possible to check the wiki's recent changes and identify active users.

Most small wikis don't have a dedicated mailing list, but it may be possible to reach them through the Wikimedia translators mailing list translators-l.

On small wikis, the use of CentralNotice is less disruptive because of the smaller audience. It is thus possible to use CentralNotice to push important information to the community, but alternate channels should be tried first.

Tools & communication channels[edit]

General considerations[edit]

Synchronous and asynchronous communication[edit]

Generally, well-established asynchronous communication channels like mailing lists and wikis should be the primary means of communication. This will allow peers not located in the San Francisco office to be as included as possible in discussions and decisions. "Peers" is intended in a loose sense, i.e. every person involved in the development of the technical platform, whether they're paid or not: developers, designers, EPMs, etc.

Synchronous communication has advantages, notably in terms of bandwidth. Phone / video calls can't be avoided completely; when they're absolutely necessary, they should be advertised early and opened to whoever is interested (unless confidentiality is required, which rarely happens). Also, archives, logs or minutes should be made available systematically for documentation purposes. Not only will this allow absent peers to look them up, but it will also attendees to use them as reference.

The paid engineering staff is slowly converting to an agile development methodology. In this methodology, "scrum" meetings are mostly used for task tracking, and not to take decisions. This is a good opportunity to make special efforts to stick to this format, and leave the decision making processes (and their rationale) on public fora.

Project-specific aliases are not used by paid developers. However, private emails are sometimes used for discussions that don't necessarily require confidentiality. Such discussions should be moved to the general development public list. Unpaid developers will generally prefer to get too many mailing list emails detailing projects they're not interested in, rather than having to complain about the lack of transparency every time. This also argues in favor of separating the MediaWiki development discussions from the general wikitech-l list.

Paid developers have to make efforts to work more openly, but at the same time unpaid developers should also try to be more welcoming and less prone to harsh criticism.

MediaWiki and Wikimedia technology[edit]

Another current issue is the confusion caused by the similar names used for the organization (Wikimedia) and the software (MediaWiki)[4]. A good example of this confusion is the number of MediaWiki users who join the #wikimedia IRC channel instead of #mediawiki to ask for software support. The confusion is even worsened by the fact that we have a unique bug tracker located at bugzilla.wikimedia.org, dealing with issues related to both Wikimedia websites and the MediaWiki software.

There are obviously strong ties between Wikimedia projects and MediaWiki: all Wikimedia projects use the MediaWiki software, and the MediaWiki software is primarily developed with Wikimedia projects in mind. However, there is also a growing community of MediaWiki users who are not Wikimedia users and we should provide them with tools relevant to them.

Wikimedia projects and MediaWiki are separate products and they should be acknowledged as such. The separation between MediaWiki and Wikimedia technology happened early as far as IRC channels are concerned. mediawiki.org and wikitech are also separate wikis, even if some pages aren't where they belong. It is only natural to also have separate mailing lists.

Mailing lists[edit]

IRC channels[edit]

Wikis & other web tools[edit]

Notes and references[edit]

  1. Improving Commons upload interface, Erik Möller, wikitech-l, September 2, 2010.
  2. Community, collaboration, and cognitive biases, Aryeh Gregor, wikitech-l, June 8, 2010.
  3. Community vs. centralized development, Aryeh Gregor, wikitech-l, September 2, 2010.
  4. This section was originally published in Wikimedia & MediaWiki bugs, issues and requests, Guillaume Paumier, March 4, 2010.