Technical communications

Rationale and timeline
In Fall 2010, Rob Lanphier was contracted to execute an assessment of then-current Wikimedia engineering activities and processes. He also provided recommendations about how to improve said processes.

One of these recommendations was to create "project pages" to increase transparency and accountability, as well as to facilitate volunteer engagement in activities led by Wikimedia engineering staff.

The first project pages were started in late 2010, with little success. Many of them remained stubs, or even empty.

Guillaume Paumier resumed work on this project in March 2011. After putting the infrastructure in place (using templates), he started to create, update, rewrite, and organize the pages.

As of late July 2011, most project pages are in place and up-to-date.

Main pages

 * Wikimedia Engineering — Main portal for Wikimedia engineering activities
 * Wikimedia Features engineering
 * Wikimedia Mobile and Special Projects engineering
 * Wikimedia Platform Engineering

Current work

 * Wikimedia engineering reports (ongoing)
 * Communications support for engineering staff
 * Tech/Ambassadors: improving 2-way communication between "tech people" and editors (content creators & curators). This includes the Fall 2012 consultation described below.

Context
Communication between Wikimedia contributors and "tech people" (primarily MediaWiki developers, but also designers and other engineers) hasn't always been ideal. In recent years, Wikimedia employees have made efforts to become more transparent, for example by writing monthly activity reports, by providing hubs listing current activities, and by maintaining "activity pages" for each significant activity. Furthermore, the yearly engineering goals for the WMF were developed publicly, and the more granular Roadmap is updated weekly.

Now, that's all well and such, but what's more interesting to discuss is how we can better engage in true collaboration and 2-way discussion, not just reports and announcements. It's easy to post a link to a new feature that's already been implemented, and tell users "Please provide feedback!". It's much more difficult to truly collaborate every step of the way, from the early planning to deployment.

Some "big" tech projects sponsored by the Wikimedia Foundation are lucky enough to have Oliver Keyes who can spend a lot of time discussing with editors, basically incarnating this 2-way communication channel between users and engineering staff. But Oliver can only do so much: he has to focus on a handful of features, and primarily discusses with the English Wikipedia community. We want to be able to do this for dozens of engineering projects with hundreds of wikis, in many languages, and truly collaborate to build new features together. Hiring hundreds of Community Liaisons isn't really a viable option.

There are probably things in the way we do tech stuff (e.g. new software features and deployments) that drive editors insane. You probably have lots of ideas about what the ideal situation should be, and how to get there: What can the developer community (staff and volunteers) do to get there? (in the short term, medium term, long term?) What can users do to get there?

Instead of just postulating that "The problem is X" and "The solution is obviously Y", we've started an extensive consultation process to learn from users, to hear them, to listen to their complaints and their ideas on how to fix the issues. We're hoping that this open and collaborative thinking process will yield better results than a one-sided analysis.

Phase 1: en and fr wikis

 * Goal: Start the consultation on a few select wikis (to give us enough time to follow up appropriately) in languages we know (so we can participate in the discussion) to give us a first overview of the issues and possible solutions
 * Timeline: Week 43 (2012)

English language projects (tech) village pumps:
 * w:Wikipedia:Village pump (technical)/Archive 104
 * wikt:Wiktionary:Grease pit/2012/October
 * b:Wikibooks:Reading room/Archives/2012/October
 * v:Wikiversity:Colloquium/archives/October 2012
 * species:Wikispecies:Village Pump no response
 * s:Wikisource:Scriptorium no response
 * q:Wikiquote:Village pump no response
 * n:Wikinews:Water cooler/technical
 * commons:Commons:Village pump/Archive/2012/10

French language projects village pumps:
 * w:fr:Wikipédia:Le Bistro/25 octobre 2012
 * commons:Commons:Bistro/archives/octobre 2012
 * n:fr:Wikinews:Salle café/2012/octobre
 * b:fr:Wikilivres:Le Bistro/Messages actuels
 * q:fr:Wikiquote:Le Salon/octobre 2012 no response
 * s:fr:Wikisource:Scriptorium/Octobre 2012
 * v:fr:Wikiversité:La salle café/43 2012

Phase 2: Summary and wider outreach

 * Goal: Widen the circle of consultation by reaching out to more wikis, after summarizing the initial findings from Phase 1 in order to limit duplication, and to mitigate the fact that we'll be less involved and reactive in a wider and more multilingual consultation.
 * Timeline: Weeks 48–49 (2012)

Summary

 * Volume and scatteredness of information

Issues:
 * There needs to be a human filter and conduit between users and developers, to bubble up serious issues and good ideas with consensus.
 * Pointing out things that don't work well and suggesting improvements on Village Pump (or other on-wiki forum) is often a waste of time.
 * Developers can't cope with the huge amounts of feedback (often duplicate) of the community.
 * Users can't cope with the huge amounts of technical information which is also scattered and difficult to find. Technical documentation, announcements and discussions are on other sites (mediawiki.org, meta-wiki, bugzilla, tech blog, etc.) or mailing lists
 * Users are unfamiliar / intimidated by bugzilla.

Possible solutions:
 * (short/medium) Set up a network of local tech teams/ambassadors to act as liaison. (historical example).
 * (medium) Tie in Bugzilla with CentralAuth and/or allow bug reporting from a wiki page (bug 27001).
 * (medium) Make w:Template:Tracked an extension and use it to link back from bugzilla to relevant on-wiki discussions. Make it possible to 'watch' an issue trough it.
 * (medium/long) Archive mailing lists posts on-wiki, allow posting to the mailing list from the wiki.
 * (long) Set up a tech search engine that has some understanding about latests changes and is able to find relevant blog posts, bugzilla tickets and projects based on that context.
 * (long) Cross-wiki watchlist/notifications and subscriptions by topic (see Echo).


 * Missing information

Issues:
 * It's often unclear who is responsible for what and who to contact about what problem.

Possible solutions:
 * (short/medium) Set up a wizard to guide people through the appropriate process and venue depending on what they want to achieve (on wiki? Bugzilla? i18n may be an issue)


 * Other

Issues:
 * Hub pages like Wikimedia Features engineering don't allow users to watch all projects easily.

Possible solutions:
 * (short) Extend the StatusHelper gadget to include a button on hub pages to "Watch all projects on this page".
 * (long) Build this into Echo.

Phase 3: Overall summary and plan

 * Goal: Consolidate and summarize findings from Phase 2, and identify solutions to try out (in the short, medium and long term) to fix the issues discovered.
 * Timeline: Week 50 (2012)

Phase 4: Experiments

 * Goal: Try out solutions identified in Phase 3
 * Timeline: Weeks 51+ (2012) and Q1–Q2 (2013)

Documents

 * Status helper — Specifications for a tool (gadget, extension) to make updating statuses less painful
 * Development process improvement/Pages organization — Legacy proposal for organizing the project pages