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
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
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)[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
| 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
| 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. |
Notes and references
- ↑ Improving Commons upload interface, Erik Möller, wikitech-l, September 2, 2010.
- ↑ Community, collaboration, and cognitive biases, Aryeh Gregor, wikitech-l, June 8, 2010.
- ↑ Community vs. centralized development, Aryeh Gregor, wikitech-l, September 2, 2010.
- ↑ This section was originally published in Wikimedia & MediaWiki bugs, issues and requests, Guillaume Paumier, March 4, 2010.