Developer Advocacy

The Developer Advocacy team (called Developer Relations until June 2018) supports developers using Wikimedia web APIs and software projects to spread and improve free knowledge.

Our primary focus is to help developers build and scale successful projects using Wikimedia web APIs. We encourage them to contribute to our free and open source projects as a way to achieve their own goals.

You can find us on IRC at.

Developer Advocacy is part of the Technical Engagement group at the Wikimedia Foundation.

About Developer Advocates
 Areas of focus for Developer Advocates 

Developer Advocates support and grow the existing MediaWiki and Wikimedia FLOSS developer communities by coordinating participation in Hackathons and outreach events like Google Summer of Code, Outreachy, and Google Code-in.

Developer Advocates are technical contributors with strong communications skills, who focus their efforts on creating tutorials, sample code, blog posts, conference presentations, and other outreach to make using their organization's software platform easier.

Developer Advocates also collect feedback from the developer communities they serve and present the it to Product Managers.

ننخ === About Technical Writers ===

Areas of focus for Technical Writers:

As part of the developer advocacy team, the technical writer works with Wikimedia's technical teams, individual contributors, and technical collaborators in the Wikimedia movement and wider FLOSS community to foster a friendly and open community of technical communicators and documentatarians.

The technical writer has an in-depth understanding of technical documentation needs and requirements. They work with developers and community members to create clear, effective technical documentation for Wikimedia projects. They develop, maintain, and evolve standards for clear writing, and support individuals who want to become better writers.

The technical writer on the developer advocacy team is rarely engaged solely in writing technical documentation, though they may certainly design and write specific documents when called upon to do so. The technical writer thinks about technical documentation across Wikimedia projects holistically and recommends best practices and improvements. The technical writer works with Wikimedia staff and community collaborators to help individuals strengthen and their documenation writing skills.

The technical writer identifies and creats necessariy resources that make the task of documenting the technical aspects of projects easier for users at varying levels of technical or writing proficiency. The technical writer asks questions and listens to feedback in order to understand the most effective ways to communicate complex technical topics to a wide variety of audiences.

Some work that falls within the scope of a technical writer:


 * Audit and analyze existing documentation to maintain continuity of style and content and to identify reuse opportunities
 * Produce high-quality and easy-to-understand documentation for a variety of software engineering processes, API documentation, FAQs, user guides, standard operating procedures, etc
 * Partner with developer advocates to improve critical existing documentation and prioritize documentation
 * Work with Wikimedia technical teams to craft messaging (blogs, stories, announcements, etc), that are accessible for non-technical audiences
 * Together with the Communications and Design teams, author style-guides and standard templates for specific types of documentation and audiences
 * Create curriculum and expand the community of writers contributing to public documentation
 * Improve Toolforge onboarding and help documentation in partnership with Developer Advocacy and volunteers
 * Improve ORES technical documentation in partnership with volunteers
 * Develop guidelines and templates for effective tutorials, FAQs, and other common technical documentation
 * Create and curate a documentation portal for Wikimedia technical products with an initial focus on software architecture and coding standards
 * Continuously gather user feedback and evaluate user experiences. Incorporate feedback to improve documentation
 * Facilitate an ongoing special interest group to surface needs and discuss priorities and improvements

Documentation
Coordination of entry-level and mid-level documentation with a focus on documentation for volunteer contributors that encourages developers to use Wikimedia data and APIs. Coordination of volunteer documentation efforts.

Events
Organization of online and face-to-face events (except for the Wikimedia Technical Conference or international Hackathons), and smaller events for hacking, training, and promote new technologies.

Community
Outreach programs for new free and open source contributors. Bug management and 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.

Planning
You can follow our work and get involved. Contributors of all disciplines and skill levels are welcome!

The planning process is based in Phabricator. The team breaks down their planning into several levels: A roadmap (per quarter plus a backlog, in a Phabricator team project), selected quarterly goals, and monthly sprints (in Phabricator sprint projects).

Every significant task that doesn't belong to a regular workflow needs to have its own Phabricator task associated to the team project.

Roadmap
The roadmap can be found at https://phabricator.wikimedia.org/tag/developer-advocacy/

The roadmap presents columns for every quarter. For status information and the exact month, click the column header to get to the workboard for each quarter. We keep a view of two or three future quarters.

The roadmap reflects
 * goals and other actions required to implement the strategy and the WMF annual plan
 * events and other predictable activities
 * other tasks in our backlog

New tasks are placed automatically in the backlog. Then we move them to the column of the quarter that seems more appropriate, usually once a month during a team meeting.

There is no common definition of a roadmap across the Wikimedia Foundation teams. The closest reference is Wikimedia Foundation Annual Plan/2015-16.

Quarterly goals
We followed the process for defining quarterly goals used at Wikimedia Engineering/2017-18 Goals, Wikimedia Engineering/2016-17 Goals, Wikimedia Engineering/2015-16 Goals.


 * Also see the corresponding quarterly columns on our Phabricator workboard
 * January - March 2018 (as part of the Technical Collaboration team)
 * October - December 2017 (as part of the Technical Collaboration team)
 * July - September 2017 (as part of the Technical Collaboration team)
 * April - June 2017 (as part of the Technical Collaboration team)
 * January - March 2017 (as part of the Technical Collaboration team)
 * January - March 2016
 * October - December 2015
 * July - September 2015
 * April - June 2015
 * July 2014 - March 2015
 * July 2013 - June 2014
 * July 2012 - June 2013

Monthly sprints
Tasks targeted for the current quarter on the team workboard get added to monthly sprints (expressed via monthly columns on the workboard of quarterly projects) by task assignees / team members.

Before April 2016, the team used monthly Sprint projects in Phabricator. For older monthly sprint projects before the team name was changed in Sep2015, see Oct2014, Nov2014, Dec2014, Jan2015, Feb2015, Mar2015, Apr2015, May2015, Jun2015, Jul2015, Aug2015.

Quarterly check-ins
The Wikimedia Foundation performs WMF Metrics and activities meetings/Quarterly Reviews, later renamed to Quarterly Check Ins:


 * Jan - Mar 2017: c:File:CE_APRIL_2017_Quarterly_Check_In_(Q4)_Slide_Deck_1.pdf&page=19
 * Oct - Dec 2016: Part 1, Part 2
 * Jul - Sep 2016
 * Apr - Jun 2016, page 17ff.
 * Jan - Mar 2016, page 6ff.
 * Oct - Dec 2015, page 18ff.
 * Jul - Sep 2015, page 8ff.
 * Apr - Jun 2015, page 27ff.
 * Jan - Mar 2015, page 22ff.

Workflows
These are regular tasks that usually don't make it to our goals or backlogs explicitly, but take a significant portion of our time and attention.

Everywhere (within reason)

 * Help newcomers with technical questions, reporting their first bugs, or looking for first tasks to contribute.
 * Help keeping discussions friendly, intervening in specific situations if needed.

Phabricator

 * Scan new tasks, bringing them into good shape and looking for potential issues that need escalation.
 * Triage old tasks in order to push forward bugs or feature requests that require higher attention, or resolving obsolete reports.
 * Oversee the creation and renaming of new projects.
 * Assist Operations in the Volunteer NDA process.
 * Assist Release Engineering handling Phabricator bugs and feature requests, and upstreaming Wikimedia requests.

For a more detailed description of workflows, see Bugwrangler.

Events

 * Plan and run a continuous stream of online Tech Talks and Wikimedia Tech meetups in San Francisco.
 * Find ways to make events accessible to all participants.

Gerrit

 * Check old open code reviews in Gerrit in order to push for updates, bring new reviewers, or close the review.

Team history
Before July 2018, this team was called Developer Relations. Before September 2015, this team was called Engineering Community. Check the reasons for the change and follow our previous activity in the links on the Engineering Community Team template on MediaWiki wiki.