Developer Advocacy

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

Our primary focus is to help the developer community build and scale successful projects using Wikimedia technology. 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.

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
 * 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
 * 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>Developer Advocacy/Metrics|metrics.

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

We mainly use Phabricator for planning work. You can find our workboard at tag/developer-advocacy/.

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

Our Phabricator workboard columns have the following meaning:


 * To Triage: New tasks are placed automatically in this column. Then we move them to the column that seems more appropriate. Such moving can be done by anyone in the team. If the task does not seem trivial, it is to be brought up in our team meeting as a routine. Ignore the "Priority" value of a task in this column, as it might be the Priority of another team.
 * Backlog: We have looked at tasks in this column. Tasks here could be assigned to a team member but we rather want to avoid cookie licking. If it is likely that we soon want to work on a task, we might give that task a higher priority or move it to Consider for next quarter.
 * Team radar: Tasks that are interesting to us but we do not work on and do not drive these tasks. Hence we do not close these tasks but only remove our team project tag if at all.
 * Consider for next quarter: Tasks we might work on soon. Tasks should have an assignee.
 * Quarterly: Tasks we plan to work on in this quarter. Tasks should have an assignee.

Quarterly goals
We followed the process for defining quarterly goals used at Wikimedia Technology/Goals. (Previously this was Wikimedia Engineering/2016-17 Goals and Wikimedia Engineering/2015-16 Goals.)


 * Also see the corresponding quarterly columns on our Phabricator workboard
 * July - September 2019: Wikimedia Technology/Goals/2019-20 Q1
 * April - June 2019: Wikimedia Technology/Goals/2018-19 Q4
 * January - March 2019: Wikimedia Technology/Goals/2018-19 Q3
 * October - December 2018: Wikimedia Technology/Goals/2018-19 Q2
 * July - September 2018: Wikimedia Technology/Goals/2018-19 Q1
 * April - June 2018: Wikimedia Technology/Goals/2017-18 Q4
 * 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

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 SRE 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.

Contact
You can contact the entire team
 * by adding a comment on the Discussion page of this very page, or
 * by creating a task in Phabricator under tag/developer-advocacy/ if you are sure that we are the correct team for a specific task.

To contact individual team members, see the contact information on the individual user pages (linked above).

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.

Before April 2016, the team used monthly Sprint projects in Phabricator to plan work. 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 performed Quarterly Reviews for a while. They were 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.