Engineering Community Team/Developer Relations team

A team focusing on the success of developers using Wikimedia APIs and software projects.

The WMF Engineering reorganization of April 2015 focused on better supporting our core audiences: new users, readers, casual and advanced, editors, donors… However, the developer audience was unaddressed. This proposal aims to fill this gap evolving the Engineering Community team with a mandate to integrate and promote all the developer-facing efforts pushed by several teams.

Problem

 * The use of our APIs and the size of our developer community don't correspond to the richness and relevance of Wikimedia. Growth is between slow and stagnant.
 * Developers are strategic partners in Wikimedia's mission, but we don't have one team or a common strategy to address this core audience.
 * The Engineering Community team comes close, but they have been focusing on our existing developer community (mostly volunteers involved in Wikimedia software projects) rather than third party developer outreach.
 * We haven't approached the big mass of third party developers that could contribute to our mission while using our free knowledge for their own purpose through our APIs.
 * Without good quality developer documentation and committed technical support, we are not able to scale our engagements with technical partners either.

Solution
This solution is implementable today with our current structure and budget.
 * Move the focus of the Engineering Community team towards third party developers using our web APIs to spread and improve our free knowledge base.
 * Define a common strategy for third party developers aligned with the goals of Engineering Community, Services, Reading Infrastructure, Labs, Community Tech, Strategic Partnerships, and Community Resources.
 * Rename "Engineering Community" to "Developer Relations".
 * When the budget permits and only after showing first positive results, increase the capacity of the team in the areas of developer advocacy and technical support.

Developer Relations mission
Support developers using our web APIs and our software projects to spread and improve Wikimedia's free knowledge.

Strategy
Help developers build and scale successful projects using Wikimedia web APIs. Encourage them to contribute to our open source projects as a way to achieve their own goals.

Developer offering
Our multiple and sometimes disparate efforts targeting developers must be articulated in a single and consistent developer offering: All these pieces exist today, but most of them are precarious, disconnected, under-resourced, and lacking a common plan.
 * APIs to extract, publish, edit, and monitor Wikimedia content from external apps and services.
 * Datasets for offline applications and research.
 * Tools to develop Wikimedia-based services as well as MediaWiki gadgets, templates, bots, extensions, and MediaWiki itself.
 * Documentation for third-party developers and open source contributors.
 * Technical support by our developer community, our own engineers, and paid services by third-party consultants.
 * Training online (self-paced, scheduled sessions) and in selected locations.
 * Hosting in Wikimedia Labs for prototyping, testing, and provision of community services.
 * Events including big and focused hackathons, online and in-person meetups worldwide.
 * Promotion of Wikimedia powered projects through our media and community channels.
 * Introductions to first open source development tasks, possible projects, possible mentors and partners.
 * Internships for junior developers, on-site or online, run by Wikimedia or external (i.e. Google Summer of Code).
 * Grants to support small and mid-sized software projects aligned with the Wikimedia mission.
 * Partnerships with tech organizations aligned with the Wikimedia mission.

One key metric
Number of active users of Wikimedia web APIs hosted in Wikimedia Labs and third party servers.

(We don't have this metric today, see T102079 Metrics about the external use of the Wikimedia APIs)

Other measures of success

 * Number and volume of successful content contributions to Wikimedia content projects made through third party applications or Wikimedia Labs.
 * Number of volunteer and third party developers contributing to our open source projects, and volume of their merged code contributions.
 * Number of visitors of our new Developer Hub.
 * Number and volume of non-reverted Developer Hub content contributions made by volunteers.
 * Number of job candidates and new employees or contractors recruited through our developer activities.

Staff
The Developer Relations team can start its activity with a refocus of the Engineering Community team and shared goals with other teams contributing to the developer offering. ECT's quarterly goals for July-September 2015 already point to this direction.

From there we can review the need to grow the team's capacity based on quarterly results, new goals, and business cases presented.

Areas
The Developer Relations team covers different areas requiring its own focus and unique skills. These areas could be covered with a combination of Developer Relations staff, other individuals or teams at the Wikimedia Foundation with shared goals, and contractors.

As team lead, Quim Gil pursues the team goals coordinating the different areas. He doubles as product manager for now.

Events
Organization of online and face-to face events, including the MediaWiki Developer Summit, the Wikimedia Hackathon, Wikimania's hackathon, and smaller events for hacking, training, and promote new technologies.
 * 1 events coordinator -- Rachel Farrand.

Short term goal
The Wikimedia Developer Summit 2016 and the Wikimedia Hackathon 2016 include outreach to third party developers, and the events have enough content for them (training, showcase, meet the developers...).

Wikimedia open source community
Outreach to new open source contributors. Facilitation of an OSS development backlog together with Community Tech and other teams and volunteers willing to contribute developer sources. Supervision of community health and metrics.
 * 1 community manager -- Andre Klapper, partly keeping his role, partly evolving it a bit.

Short term goal
By December 2015, a solid community-driven backlog will guide and inspire the development efforts of the Community Tech team, GSoC and Outreachy mentors, Individual Engagement Grants applicants, and volunteers of different skill levels willing to contribute to Wikimedia open source software projects.

Developer documentation
Creation and maintenance of a developer hub at dev.wikimedia.org. Coordination of entry-level and mid-level documentation. Coordination of volunteer documentation efforts.

1 technical writer -- S Page (from the Reading team)

Short term goals
By September 2015, the Developer Hub prototype will be integrated in mediawiki.org.

By December 2015, dev.wikimedia.org will be the one-stop shop for developers willing to consume and contribute to Wikimedia's free knowledge.

Wikimedia Tech advocacy and support (WAITING FOR RESOURCES)
Promotion of Wikimedia APIs and software projects via online channels, meetups, and conferences (our own and third parties, wherever interested developers can be found). Support to developers, directly and through improvements to our documentation and feedback to our Engineering teams.
 * 2 developer advocate engineers dedicated to promotion and support.

Short term goal
A Developer support task force will be organized with volunteers, addressing questions within 24h in existing support channels (including mediawiki.org's Support Desk, stackoverflow, Facebook) and promoting dev.wikimedia.org as official destination.

Key partners

 * Strategic Partnerships for the definition of needs from technical partners and other third party developers.
 * Services and Reading Infrastructure for alignment on API and documentation goals.
 * Community Tech for alignment on the developer backlog and collaboration with open source developers.
 * Wikimedia Labs operations team, for promotion and use of Labs.
 * Community Resources for alignment on grants and other types of paid support.

Developers, a core audience
On April 2015, the WMF Engineering reorganization bet on empowering our teams to focus deeply on their audiences. Teams were created for several core audiences including readers, editors, and core community contributors. The Developer Relations team aims to complete this bet by addressing the developer core audience.

Types of developers
We have 4+1 main audiences to cater: The 5th audience being the developers of upstream projects we rely on.

There are many fuzzy lines and overlaps between these audiences, and there are other sub-audiences as well (i.e. gadget and template developers).

Third-party developers first
Until now, our developer efforts have focused on supporting current volunteers contributing to our projects, at the expense of neglecting the promotion of our APIs and the outreach to new third-party developers. The proposed Developer Relations team bets on a change of focus, prioritizing the engagement with new third-party developers. Why? We are leveling up the game for all Wikimedia developers.
 * The universe of potential users of our web APIs is bigger, the entry barrier is lower, and the opportunities for innovation and user reach are more open.
 * In order to target third-party developers effectively, we must keep high standards of documentation and support comparable with the leaders in this area.
 * By focusing on effective third-party developer outreach, we bet on a percentage of conversion of those developers into open source contributors, and in an overall improvement of our documentation and support.

Share in the sum of all knowledge via API
APIs have become a basic tool for partnerships and collaboration. If you want to collaborate with an organization, you can start by simply read the docs and use their APIs. Companies that have successful partnership, distribution and user acquisition strategies all have good APIs. Good examples are Facebook, Google, Twitter, Mailchimp, Yelp, Amazon.

Modern, simple-to-use, well-documented APIs are a prerequisite for success. Therefore, if we want to be successful at partnerships, distribution and user acquisition, we too must have multiple APIs that are modern and well-documented.

An API is only as good as its documentation
Even when we have APIs that offer interesting results, developers need to either have a lot of time or very good contacts in our community to find them and get the most of them. This is the problem we were trying to solve with the Data & Developer Hub project, which has been impacted by the WMF Engineering reorganization and needs a continuation plan.

Recruitment pipeline
The success of the Developer Relations team contributes to the success of our recruitment efforts, both for new hires and technical volunteers.
 * Increasing our outreach and improving our developer experience means increasing the pool of potential candidates that are already familiar with what Wikimedia offers to the World and can offer to them.
 * Increasing the number and diversity of third party developers using our APIs and becoming familiar with the software that enables them means increasing the pool of potential code contributors to our projects scratching their own itches.

Empowering developers in our open source platform
If developers want an API or another feature in our platform, they have the possibility to scratch their own itch. Wikimedia is a large and very active open source project. However, the solution is usually not as simple as uploading a patch. The Developer Relations team can help steward these open source contributions, connecting developers with common interests, and maintaining a backlog of open requests to feed the WMF roadmap and volunteer efforts.

Collaboration with Labs, Research & Data, and other developer facing teams
The Developer Relations team will not be the only team that supports developers, and this is a good thing. Other teams will be directly interfacing with developers as well, e.g. Wikimedia Labs or Research & Data. Especially under the current assumption of very limited resources, it is better to keep all the people and skills in their own teams. We will coordinate with them, asking for more resources only in the areas requiring professional attention that fall out of the scope of other teams.