Development process improvement/Communications recommendations

Over the past few years, the Wikimedia community has perceived an increasing gap between the Wikimedia Foundation and them. This gap has especially been visible in two main areas related to technology:
 * Users have been feeling neglected and ignored when they asked bugs to be fixed or features to be implemented. They don't have a clear understanding of what the best way is to have an impact on technical decisions, or what WMF engineers are working on (and why).
 * Unpaid developers have been perceiving 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 Wikimedia Foundation didn't have the financial and human resources to have 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 Product strategy department to find appropriate ways to engage in two-way communication with the 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 close 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.

Large wikis
The largest wikis have

en.wikipedia


 * project mailing list
 * wikipedia signpost http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost
 * local tech village pump http://meta.wikimedia.org/wiki/Distribution_list
 * announcement list: https://lists.wikimedia.org/mailman/listinfo/wikimediaannounce-l
 * blogs

to avoid
 * centralnotice (efficient, reaches everyone, but disruptive)

large & medium wikis

if possible, translated:
 * local counterparts of the signpost, ie. http://de.wikipedia.org/wiki/Wikipedia:Kurier ; see interlanguage links of http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost for a full list
 * local village pumps http://meta.wikimedia.org/wiki/Distribution_list
 * project mailing list

English:
 * announcement list https://lists.wikimedia.org/mailman/listinfo/wikimediaannounce-l
 * blogs
 * centralnotice (efficient, reaches everyone, but disruptive)

small wikis


 * list of local village pumps http://meta.wikimedia.org/wiki/Distribution_list
 * small wikis: talk page of the wiki's main page
 * active participants talk pages (check that automatically)
 * translators mailing list
 * centralnotice (efficient, reaches everyone, but disruptive)


 * announcement list
 * blogs

Tools & communication channels

 * Communication

Mailing lists

 * Mailing lists

IRC channels

 * MediaWiki on IRC

Wikis & other web tools

 * CodeReview
 * Bugzilla (prototype)
 * Xplanner (prototype)
 * IdeaTorrent (prototype)
 * Semantic MediaWiki (prototype)
 * face-to-face, phone & video discussions
 * Private email

Peers

 * developers
 * WMF staff & management (including non-developer staff involved in software development: designers, product managers, EPMs, etc.)

Users

 * Wikimedia "editors" (e.g. Wikimedia participants not involved in development)
 * general public (including the press & donors)
 * API users
 * Data dumps users
 * users of MediaWiki outside Wikimedia (including enterprise use)

Peers

 * RfCs, peer discussion
 * report & check-in (i.e. person status)

Users

 * support request
 * bug report
 * feature request
 * call for testing
 * user research
 * strategic product research

Peers & Users

 * reference, documentation (including project status & progress)
 * announcement

Process notes

 * task tracking
 * scheduling at various levels (roadmap, target versions, milestones, daily scrums...)
 * bug squashing periods
 * CodeReview periods
 * lightweight general process applicable to all developers + additional processes for paid staff if necessary (but should still remain fairly lightweight)