Development process improvement/Communications recommendations

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. 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". The second part of this document provides recommendations about how to work towards this goal.

Tech announcements

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

The following venues should be used only for important announcements:

• The general Wikimedia announcement list mail:wikimediaannounce-l. This list is moderated.
• Wikimedia blogs: the Tech Blog and Wikimedia Blog

Large wikis

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:

• Community newspapers like the Signpost (in English), the Kurier (in German). For a full list of existing community newspapers, see the interlanguage links of the Signpost.
• Local village pumps (see Distribution list). Some projects have a tech-specific village pump, like the Technical village pump or the Café dos programadores; in this case, the dedicated page should be used. For a full list of such pages, see the interlanguage links of the Technical village pump.
• Some wikis have watchlist notices.
• Project mailing lists like wikien-l or wikifr-l (see the full list of lists)

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

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

• Communication

General considerations

Synchronous and asynchronous communication

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

Another current issue is the confusion caused by the similar names used for the organization (Wikimedia) and the software (MediaWiki). 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

• Mailing lists

List	Stats	Description	Assessment	Recommendation
MediaWiki discussions between peers
Maps-l	stats	Map integration	Status: Fairly active list about the integration of open maps in MediaWiki wikis	status quo
Mediawiki-i18n	stats	MediaWiki internationalisation	Status: Reasonably active list about the localization of MediaWiki	status quo
MetaVid-l	stats	[no description available]	Status: Fairly inactive list about the MetaVidWiki project and MetaVidWiki development	Add short description
Offline-l	stats	Using Wikimedia projects and MediaWiki offline	Status: Stillborn list; never used	If deemed useful, advertise it; if not, retire it.
Wikidata-l	stats	[no description available]	Status: Stillborn list; almost never used; unclear purpose	If deemed useful, advertise it; if not, retire it.
Wikitext-l	stats	[no description available]	Status: Discussions about wikitext, the parser(s), etc. Uneven activity	Add short description.
Announcements / Discussions with MediaWiki users
MediaWiki-announce	stats	MediaWiki update and security announcements list	Status: Active announcements list	status quo
Mediawiki-api	stats	MediaWiki API announcements & discussion	Status: Support list for users of the MediaWiki API	Make it clearer it's a support list. Few technical discussions about the API and its development seem to happen there. Maybe rename to Mediawiki-api-users.
Mediawiki-api-announce	stats	MediaWiki API announcements	Status: Active announcements list	status quo
Mediawiki-enterprise	stats	[no description available]	Status: Fairly inactive list about the corporate use of MediaWiki. The traffic doesn't seem to warrant a dedicated list.	Merge with the general support list?
MediaWiki-l	stats	MediaWiki announcements and site admin list	Status: Active support list for MediaWiki users	Rename to "MediaWiki-users"?
Mediawiki-sv	stats	[no description available]	Status: Fairly inactive support list in Swedish for MediaWiki users. The traffic doesn't seem to warrant a dedicated list.	Retire? The general support list is already advertised as "multilingual"
Wikimedia technology discussions between peers
Mobile-feedback-l	stats	[no description available]	Status:	Find out what this list is about
Mobile-l	stats	Mobile server and supported mobile platforms	Status: Active for a few months when it was created, then died	Open the archives; advertise if useful, maybe repurpose or expand the scope
Wikibots-l	stats	Wikimedia bot editors discussion	Status: Fairly inactive but useful list for developers and users of automated editing frameworks for Wikimedia sites	status quo
Wikitech-l	stats	Wikimedia developers	Status: A very active list mixing MediaWiki development discussions and Wikimedia-tech-specific discussions	Split into Wikitech-l (focusing on Wikimedia-tech-specific discussions) and MediaWiki-dev (focusing on MediaWiki general development)
Wikivideo-l	stats	Opportunities for video in the Wikimedia universe; tech help	Status: Stillborn list; never used	?
Xmldatadumps-l	stats	Discussion List for Wikimedia's XML Database Dumps	Status: Fairly active list	status quo
Announcements / Discussions with Wikimedia users
WikimediaAnnounce-l	stats	[no description available]	Status: Fairly recent, moderated, low-traffic general announcements list for Wikimedia news. Few tech-related posts at the moment	status quo for now
Wikitech-ambassadors	stats	Coordination of technology deployments across languages/projects	Status: This list if very recent, but its scope is a bit unclear; it seems to be both for announcements and feedback.	status quo for now
MediaWiki automated notifications
MediaWiki-CVS	stats	MediaWiki CVS commits	Status: Well, it's been a long time since we used CVS...	Rename to a VCS-independent name such as mediawiki-commits.
Wikimedia automated notifications
Newprojects	stats	Announcement list for new Wikimedia wikis	Status: Fairly recent list, useful for a couple of people like SWMT members or bot owners	status quo
MediaWiki & Wikimedia automated notifications
Wikibugs-l	stats	Monitor updates to the Bugzilla bug tracker	Status: Currently mixes notifications about MediaWiki bugs, MediaWiki feature requests, Wikimedia site issues, Wikimedia site requests, etc.	Split into different lists, for example mediawiki-bugs and wikimedia-tech-issues (see below)

IRC channels

• MediaWiki on IRC

List	Publicly logged?	Topic	Assessment	Recommendation
#mediawiki	yes (toolserver)	"MediaWiki support and development <http://www.mediawiki.org/>"	Status: Very active channel, mixing support questions & answers (including bot answers), discussions between peers (developers), automated notifications for commits, bugzilla changes and unit testing.	Discuss a possible development channel among MediaWiki developers (e.g. #mediawiki-dev), where everything related to development (i.e. everything but support) would take place, and merge/forward #wikimedia-dev into it.
#mediawiki-codereview	no	"MediaWiki code review feed <http://www.mediawiki.org/wiki/Special:Code/MediaWiki>"	Status: The channel is mostly comprised of automated notification of commits and code review comments. Hardly any human ever hangs out in the channel; we usually let CIA-1, codurr & ChanServ discuss together.	status quo
#wikimedia-dev	yes (prototype.wm.o)	"Channel where WMF #mediawiki staff and community developers discuss and can be contacted about current WMF software projects (usability, ...)"	Status: Very recent channel meant to replace #wikipedia_usability. The channel has been criticized as a place where paid developers stay among themselves without the "noise" of #mediawiki.	See recommendations for #mediawiki.
#mediawiki-i18n	no (forbidden)	http://translatewiki.net channel - Software internationalization for MediaWiki and other projects	Status: The channel is pretty active and has a defined scope. However, MediaWiki isn't the only project being localized at translatewiki.net. #translatewiki currently forwards to #mediawiki-i18n	Rename to #translatewiki. Possibly, log the channel publicly to allow for asynchronous reading of discussions.
#wikimedia-tech	no	General channel for Wikimedia technology discussions & status	Status: This channel has been advertised as the place to go for Wikimedia participants when they want to ask questions about or report issues with the servers & technical infrastructure or Wikimedia websites. It works well in this role.	Bugzilla notifications related to Wikimedia-specific issues and requests should be broadcast here instead of the MediaWiki channel.
#wikimedia-operations	no	Wikimedia servers & infrastructure administration	Status: #wikimedia-operations seems to be to #wikimedia-tech what #mediawiki-dev would be to #mediawiki: a place where peers discuss very technical details that users usually don't care about.	status quo
<name hidden>	no (forbidden)	a private channel to discuss security-related topics; opened to trusted paid and unpaid people	Status: This channel used to be the "operations" channel, but these discussions were recently moved to #wikimedia-operations.	Make an effort to move all non-security discussions to public channels such as #wikimedia-tech.
#semantic-mediawiki	yes (toolserver)	"Semantic MediaWiki - http://semantic-mediawiki.org"	Status: A support and development channel for the Semantic MediaWiki extension.	status quo

Wikis & other web tools

List	Scope	Assessment	Recommendation
mediawiki.org	the MediaWiki software	Status: mediawiki.org hosts the documentation for MediaWiki, and some of the development materials & discussions. It also hosts the Code review tool. Recently, it has started to be used more for planning and coordination of development (including work sponsored by the Wikimedia Foundation). Some documentation has recently been included that is relevant to the Wikimedia infrastructure but not to MediaWiki.	Stick to the original scope and move Wikimedia-specific pages (such as ops-related project pages) to the wikitech wiki.
meta.wikimedia.org	Coordination platform for Wikimedia projects	Status: "meta" hasn't really been used recently for technology-related content.	It is fine for feature-specific research to be attached to the features on mediawiki.org. However, Wikimedia-specific user research & studies should be hosted on meta. Features derived on this research should be documented on mediawiki.org and reference it.
usability.wikimedia.org	Usability and User Experience projects for Wikimedia	Status: The wiki was hardly used by anyone except the paid staff of the Wikimedia Foundation working on the two usability-related grants (Wikipedia usability initiative & Multimedia usability project). By being a separate, isolated wiki, it failed to really engage users & peers. As these projects have come or are coming to an end, the wiki is now mostly dead.	Ideally, move the whole content to mediawiki.org or meta depending on their relevance, and close the usability wiki. As a second-best scenario, lock the wiki and point to the documents there.
wikitech.wikimedia.org	Wikimedia servers & infrastructure administration	Status: A bit messy, and quite underutilized.	Use wikitech to host the documentation on ongoing ops projects such as the Virginia data center. Possibly, open it to more people (with an appropriate access policy) to help maintain it and keep it up to date. Possibly, rename (to wiki.tech.wikimedia.org ?) in case tech.wikimedia.org becomes a hub for Wikimedia technology.