New Developers/Quarterly/2017-10

Overview
Goal, possible candidates, scope, etc.

Stats below represent volunteer developers only.

Key findings

 * Finding 1
 * Finding 2
 * Finding 3

Trends in attraction and retention between mm 2016 – mm 2017
Via KPIs of Onboarding New Developers program

{| class="wikitable" style="background-color: white;" ! style="background-color:#A9F5A9;" | Metric ! style="background-color:#A9F5A9;" | Statistics ! style="background-color:#A9F5A9;" | Source
 * colspan="3" |QUARTERLY (July 2017 – September 2017)
 * colspan="3" |QUARTERLY (July 2017 – September 2017)

Changesets received, merged and abandoned


Received - 148

Merged - 85 (57.43%)

Abandoned - 36 (24.32%)

Still new - 27 (18.2%)


 * Calculation on Community Metrics data

Comment: The initial 637 changesets shown were incorrect - The author_name `LibraryUpgrader`(a semi-automated tool) has been manually excluded from the calculation.

Active contributors
More than one changeset in Gerrit
 * 17 out of 45 (31.4%)
 * "Contribs" column of "New Authors" of Community Metrics

Three projects with most received contributions
mediawiki/extensions/examples - 12

mediawiki/core - 6

apps/android/wikipedia - 4

other - 25
 * "Repos" by "New Authors" section of Community Metrics

Outreach events
Developers attracted and retained attracted (number ~ %)
 * Wikimania Hackathon 2017

Wikimedia Hackathon 2017

attracted (number ~ %)

Retained (number ~ %)



Outreach programs
Developers attracted and retained attracted (number)
 * Google Summer of Code 2016 / Outreachy Round 13

Retained

Newcomer documentation page views
On a daily average
 * Pageview_analysis_of_five_new_developers_focused_documentation_on_MediaWiki.png to contribute - 494

Developer hub - 245

How to become a MediaWiki hacker - 69

New Developers - 16

Outreach programs - 4
 * [https: / tools.wmflabs.org pageviews ?project="mediawiki.org&platform=all-access&agent=user&start=2017-07-01&end=2017-09-27&pages=How_to_become_a_MediaWiki_hacker" ||Developer_hub|How_to_contribute|New_Developers|Outreach_programs Pageviews tool
 * colspan="3" |Data last updated on September 28th 2017
 * }
 * }

Survey analysis
We sent a survey to new developers who submitted code for the first time during July - September 2017 timeframe. The survey was designed using the Qualtrics platform, with a goal of understanding more clearly demographics and background, motivations, challenges and needs of our new developers. We planned to pilot the survey in two rounds: Out of the 35 new developers to whom we reached out, 9 (25.7%) people completed the survey. Four people started filling out the survey but didn’t finish, indicating that the completion rate of our survey was 69%.
 * 35 new developers who submitted code in July or August (still ongoing)
 * XX new developers who submitted code in September (yet to do)

Note: Since we got quite a few responses, the analysis of this survey may not be entirely justified, and actions for next steps and recommendations indicated in this report (coming soon! ) may not have many conclusions from the survey.

Below are the results from the survey:

Other professional development activities outside work
Contributing to open source, attending conferences, leading local Wikimedia community, organizing meetups, etc.

Contributions
Types of contributions Frequency of making contributions {| style="min-width: 900px" !


 * {Graph:Chart |
 * Frequency of making contributions
 * 1 – Once in a few months (44.44%)
 * 2 – Once a month (0%)
 * 3 – A few times a month (33.33%)
 * 4 – Does not apply to me because: (0%)
 * 5 – A couple times a week (11.11%)
 * 6 – Once a day (0%)
 * 7 – Multiple times a day (11.11%)
 * 8 – Other (0%)
 * 8 – Other (0%)






 * 44.44% of respondents of this survey said they contribute code to Wikimedia projects once in a few months and 33.33% a times a month
 * }
 * }

Motivations
New developers who participated in the survey indicated that they first heard about Wikimedia as a place to contributing code: First topics or projects new developers worked on: lexeme, wikiclass, bug fix, extension: ArticleToCategory2, Pywikibot and Wikimedia site request, newsletter, etc. New developers chose to work on a project as they:
 * Through Wikimedia members at a conference
 * From a friend
 * Through African Wikimedia developers project
 * Github
 * By installing MediaWiki themselves
 * Taking inspiration from bug fixes made by viewing them on Wikimedia's Gerrit
 * Found it interesting
 * Project was a good fit for their graduate studies
 * Could share their research by working on the project
 * Wanted to improve the project
 * Wanted to get started with fixing bugs, submitting patches, etc.
 * Were being asked to do so at work
 * Wanted to learn new things and to minimize burden on Wikimedia developers
 * Heard about it at a hackathon

Challenges
Understanding of Wikimedia's code contribution process

Suggestions for improvement
Here are some suggestions made by new developers (responses below have been only slightly edited):
 * Standard toolbox over in-house or unusual systems (Gerrit, Phragile, ...)
 * More autonomy for development teams: build a trust-based DevOps culture allowing teams to adopt Continuous Integration/Continuous Delivery practices and deliver value in small iterations (current deployment guide mentions a lead time of over six weeks for new services!).
 * Breaking focused services out of the monolithic MediaWiki core.
 * Be bold with code changes. Approve more patches in a timely fashion. Enlarge the group of developers who are authorized to approve patches.
 * Surveying and documenting conventions on how to interact with other developers through Phabricator and Gerrit.
 * Git commit message guidelines suggests "To express that a commit resolves a bug, add Bug: Txxx in the footer at the end of the commit message." What do you do when the commit doesn't resolve the bug because the bug has multiple items? The "Bug: Txxx" footer should _always_ be there, because that automatically adds a change notice to Phabricator. That convention isn't made particularly clear from the guidelines.
 * Fix the IP ban that devoid access to Phabricator
 * Be better on follow up issues
 * Better guides. Make more documentation on Wikitech. So that we can contribute more.