User:SSethi (WMF)/Sandbox/Plan for improving outreach and increasing retention of new wikimedia developers

Note'': This is just a research and planning document; text in here is not polished and still in draft mode. The most feasible ideas that came out of this planning will be used for future reference of the Developer Relations work around onboarding new developers in Wikimedia projects.''

With this plan, the goal is to achieve a sustained increase of new developers contributing to Wikimedia projects clearly departing from the current stagnant trend. This plan is part of the Wikimedia Foundation Annual Plan FY2017-18 - Community Engagement - Program 12 Onboarding new developers. Related task on T176487

Timeline
Phase 1: December, 2017


 * List venues through which we bring in new contributors
 * Developer Relations together writes challenges we are facing, our current approach, and ideas for improvements in outreach and retention in bringing new contributors through these venues

Phase 2:  January, 2018


 * Srishti to propose takeaways and action items from information collected in Phase 1
 * Developer Relations together reads takeaways and action items, suggests more, and refines them

Phase 3: February, 2018 onwards


 * Developer Relations to pick from the most feasible ideas to implement in their areas

Phase 1
Listing newcomer venues: current approach, challenges, and ideas for improvements

Google Summer of Code / Outreachy
Current approach


 * Recognize newcomer contributions through blog posts, newsletters, etc
 * Conduct surveys to understand newcomer experiences
 * Provide mentoring tool for better communication support
 * Invite newcomers to become mentors in Google Code-in
 * Showcase well-curated projects on-wiki
 * Run informational session before the program

Challenges


 * There is a vast array of projects ongoing in Wikimedia, and GSoC is a program that helps us bring in contributors at zero cost. How do we leverage the opportunity and scale up?
 * Lack of interest and good mentors from both within and outside the Foundation
 * Not able to draw diverse pool of applicants
 * Systematic approach to conducting outreach and keeping newcomers engaged after the program

Ideas for improvements


 * Focus more on potential long-term contributors after the program
 * Develop a personal growth plan for each student (e.g. Phab:T183335)
 * Help them prepare to be mentors in the future editions
 * Educate them about grants
 * Invite them to participate in our future events
 * Encourage them to conduct outreach in their local community
 * Invite them to be participate in a GSoC / Outreachy lightning showcase at the annual Hackathon
 * Coordinate with the scholarship committee of Wikimania and Wikimedia Hackathons
 * Promote more projects and start the process early
 * Increased developer outreach in featured projects
 * Draw more mentors
 * Systematic approach to conducting outreach and keeping newcomers engaged after the program
 * Keep in close communication with them for the first year, then move them all to a mailing list
 * Quarterly newsletter to inform previous year candidates about movement-related activities, events, programs, and opportunities
 * 

Google Code-in
Current approach


 * Recognize newcomer contributions through "write a blog post" GCI. Link to those posts / list achievements in a WMF blog post and wikitech-l@ posts to summarize achievements
 * Encourage GCI winners to apply for Hackathon attendance
 * We did not contact the previous year's students because we often do not have their email addresses. However in 2017 we did have ex-students as mentors, for the first time

Challenges


 * Very young contributors 'exploring'; less commitment to project / organization; high fluctuation and quick changes of interest. Though, long-term bonding seems to happen via IRC conversations, to make personal 'friends'
 * Lack of interest and mentors (and tasks) from within WMF - always the same (great) individuals.
 * Collecting potential GCI tasks over the year and keeping those tasks updated & unresolved. Same challenge in general for #easy tasks. Making teams have this in mind and marking tasks as such.
 * Stressful contest rules constraints that we cannot change, e.g. 36h review rule

Ideas for improvements


 * Same as every year: https://www.mediawiki.org/wiki/Google_Code-in/Lessons_learned
 * Contact students at end of the contest and point out ways to follow-up opportunities? But: We do not have email addresses. Hence: How
 * Explore the possibility of using Zulip to keeping in touch with students
 * Just like we have a "CL's, you know the drill email," we have a similar one for DR's (perhaps every quarter) sent to technology teams with a few specific asks such as:
 * Any possible-tech-projects that you would like to help add to the workboard or the new developers landing page?
 * Hackathon is coming up.. we need mentors, etc.
 * Here is a list of easy tasks that require your attention and a description update, etc.
 * 

Online technical spaces
Current approach


 * Point random people in various places to our newcomer docs (how to contribute, new developers landing page, etc.)
 * Data on wikimedia.biterg.io to identify new devs and survey them

Challenges


 * Too much / outdated / unstructured documentation (it's a wiki) -- cf. T169599
 * Too many communication channels to follow / cover / find the right one
 * no central knowledge base
 * On IRC, cannot look up previous questions / topics
 * Support on IRC is time intense and does not scale (only helps one person)
 * Task / project specific questions vs general infrastructure / workflow questions
 * Apart from individuals (Tgr etc) we ignore venues such as StackOverflow and Reddit.
 * Missing on online outreach
 * Difficulty in understanding code contribution process
 * Choosing what to work on initially
 * Feel intimidated to ask questions on IRC
 * Not so clear task descriptions
 * Are we keeping track of who contributed, needs code review help, if so then how etc?

Ideas for improvements


 * There be a #wikimedia-newcomers channels where folks could help one another
 * Online outreach through events, Twitter chats, get ourselves in listed in external projects, repositories, etc.
 * Testing out the mw:New_Developers guide framework
 * 
 * 

Universities
We are not set up yet to support teaching and learning open source in universities through Wikimedia projects by professors or among student developer communities

Phase 2
Listing possible ideas for going forward

Online outreach
To help scale our efforts and bring larger impact:


 * Adopt a systematic approach to support volunteers interested in teaching Wikimedia tech or onboarding developers from their local communities through online courses, campus or leadership programs. That way prepare them to be better organizers or leaders in their networks. Some inspirational projects:
 * https://reps.mozilla.org/events/#/period/future/
 * https://campus.mozilla.community/
 * https://mozilla.teachable.com/p/mozilla-campus-club-training
 * Participate in online events such as Hacktoberfest, get ourselves listed in repositories where we are not there yet
 * Partner with a university to help facilitate teaching of open source through Wikimedia projects and document the process
 * Participate in Mozilla’s Open Leaders program and work with other open source communities to understand their work on this topic

Newcomer documentation

 * Continue to improve documentation guides and produce tutorials on topics related to Wikimedia tech.
 * Discuss on topics related to improving installation processes, code contribution infrastructure, etc with other teams.

Systematic approach to onboarding developers in our technical spaces

 * Improve our approach of #easy tasks. Consider the “Mentored” and “WelcomePatch” bugs approach followed by Mozilla. Also, that way keep track of bugs resolved by new developers on a frequent basis.
 * Existing resource about #easy categories: https://phabricator.wikimedia.org/T146960
 * Andre's views on Mozilla's approach of mentored bugs: https://phabricator.wikimedia.org/T78639#1932603
 * Follow closely activity of a new developer in Gerrit. Receive an email notification when a new developer submits a patch and ensure it gets reviewed soon. Help them connect with code reviewers, advocate for or develop best code reviewing practices. IMO, an example of a harsh code review offered to a new developer: https://gerrit.wikimedia.org/r/#/c/403586/
 * Continue to test our mw:New_Developers framework, what is working well, and what could be improved

Close collaboration with technology teams
Get technology teams to agree on offering support: help curate easy bugs, mentor projects in outreach programs and events, offer newcomer friendly projects, frequent check-ins with DevRel’s (as we currently work in silos, overheard at the DevSummit :P), possible tech projects, etc.

Growth plan for new developers
Track on a quarterly basis, new developers who participate in our events, outreach programs and are active contributors in our technical spaces and develop a one year growth plan for them. Example: https://phabricator.wikimedia.org/T183335. Share with them opportunities through newsletters, mentoring or communication mediums, etc.

Developer community resource hub

 * A collection of all things developers such as mw:New_Developers, outreach programs, how to contribute, events, upcoming events, hackathon guide, MW Hacker guide, upstream projects, etc. Example: https://community.redhat.com/
 * 

Phase 3
Work in progress for action plans laid out in second phase:


 * In line with the idea of adopting a systematic approach to onboarding developers in our technical spaces:
 * Phab:T188244 - Develop an easy to use workflow to monitor new developer patches that land in Gerrit (ongoing)