Engineering Community Team/Developer Relations team
 | This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. |
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
[edit]- 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
[edit]- 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.
This solution is implementable today with our current structure and budget.
Developer Relations mission
[edit]Support developers using our web APIs and our software projects to spread and improve Wikimedia's free knowledge.
Strategy
[edit]Help developers build and scale successful projects using Wikimedia web APIs. Encourage them to contribute to our free and open source projects as a way to achieve their own goals.
Developer offering
[edit]Our multiple and sometimes disparate efforts targeting developers must be articulated in a single and consistent developer offering:
- 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 free 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 free and 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.
All these pieces exist today, but most of them are precarious, disconnected, under-resourced, and lacking a common plan.
One key metric
[edit]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
[edit]- 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 free and open source projects, and volume of their merged code contributions.
- Number and volume of non-reverted Web APIs hub content contributions.
- Number of job candidates and new employees or contractors recruited through our developer activities.
Staff
[edit]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
[edit]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
[edit]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
[edit]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 free and open source community
[edit]Outreach to new free and 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
[edit]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 free and open source software projects.
Developer documentation
[edit]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
[edit]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)
[edit]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
[edit]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
[edit]- 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.
- Wikimedia Labs operations team, for promotion and use of Labs.
- Community Resources for alignment on grants and other types of paid support.
Background
[edit]Developers, a core audience
[edit]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
[edit]There are different types of developer that we cater for, and they have different needs.
Developers interested in using our web APIs have essentially the same needs for documentation and support.
- Those running their own projects independently from Wikimedia are third party developers.
- Those directly involved in Wikimedia can be mainly Wikimedia tools developers (organized around Tool Labs) or Wikimedia mobile apps developers.
Developers interested in using the MediaWiki platform form another family with common needs. The majority contribute open source code with a focus on Wikimedia, others write open source software independently from Wikimedia, and some of them write their own proprietary software.
- MediaWiki developers focus in MediaWiki core, extensions, and skins. Other technical contributors (designers, testers, documentation writers...) get involved in the same processes.
- There are developers specialized in several areas of development on top of the MediaWiki platform:
- MediaWiki bots
- MediaWiki gadgets
- MediaWiki templates
Finally, there are upstream developers not necessarily involved in Wikimedia, who work on software products and components that we use and deploy in Wikimedia servers.
Third-party developers first
[edit]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?
- 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 free and open source contributors, and in an overall improvement of our documentation and support.
We are leveling up the game for all Wikimedia developers.
Share in the sum of all knowledge via API
[edit]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. Organizations that have successful partnership, distribution and user acquisition strategies all have good APIs. Good examples are Facebook, Google, Twitter, Mailchimp, Yelp, Amazon.
We must consider our web APIs like any other software product: check who are the stakeholders and what are they trying to achieve, and then work to meet their needs.
An API is only as good as its documentation
[edit]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
[edit]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 free and open source platform
[edit]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 free and open source project. However, the solution is usually not as simple as uploading a patch. The Developer Relations team can help steward these free and 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
[edit]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.