New Developers/Quarterly/2018-07

From MediaWiki.org
Jump to navigation Jump to search

This is the fourth edition of the New Developers Quarterly, a report covering activities, metrics, surveys and lessons learned in the Onboarding New Developers program. This report covers April to July 2018.

Your questions and feedback are welcome on the talk page.

To receive a notification when a new report is published, subscribe.

Timeline[edit]

Newcomer-focused events, programs, and activities between April–June 2018:

New developers metrics and trends[edit]

See also Technical Collaboration Metrics - Onboarding New Developers

Volunteers contributing patches for review[edit]

167 volunteers contributed between April–June 2018. (Source; number of entries in "Submitters" table due to phab:T184741)

QoQ: +3.1%. YoY: +14.4%.

Data updated on 23 July 2018.

New volunteers attracted[edit]

49 new volunteers contributed between April–June 2018. (Source)

QoQ: -9.3%. YoY: -25.8%.

Data updated on 23 July 2018.

New volunteers retained[edit]

Percentage of volunteers active one year (±3months) after their first contribution, out of all new volunteers attracted one year ago. (Source: Calculation on data)

QoQ: -45.0%. YoY: 0.0%.

Data updated on 23 July 2018.

Quarterly data (April–June 2018)[edit]

Review of changesets by new volunteers[edit]

236 changesets were contributed by new volunteers. (Source: Calculation on data[1]. Changeset status data as of 23 July 2018.)

Projects with most new volunteers[edit]

49 new volunteers contributed to XXX repositories. (Source: "Repos by New Authors")

Outreach events[edit]

  • Wikimedia Hackathon 2017 (May 2017):
    • Attracted 37 new volunteers.
    • Retained 1 new developer who was active three quarters after the event (April–June 2018). (Source)
  • Wikimania Hackathon 2017 (August 2017):
    • Attracted 47 new volunteers.
    • Retained 2 new volunteers who were active two quarter after the event (April–June 2018). (Source)

Outreach programs[edit]

New developers survey analysis[edit]

Read through below for a quick summary:

We sent a survey to 48 new developers who submitted code for the first time between April–June 2018 with a goal to understand more clearly demographics and background, motivations, challenges and needs of our new developers.

Out of the 48 new developers to whom we reached out, 13 (27%) completed the survey.

Demographics and background information[edit]

  • Respondents of the survey were from United States (3), India (2), Germany (2), Israel (2), China, Italy, Netherlands, Turkey
  • Almost near half (~46%) of the respondents said they belong to the working professional category
  • ~85% identified themselves as male, ~15% as female

Motivations[edit]

Respondents indicated different venues through which they learned about Wikimedia and felt encouraged to contribute to the projects: use of a Wikimedia project at their workplace, Google Summer of Code, mailing list, etc. A few of them also mentioned that they are already part of the movement.

Challenges[edit]

Challenges that new developers experience is as follows: learning the process to contribute and committing changes, testing the code especially in Wikisource projects, waiting for a review on code contributions, understanding Gerrit code review tool, poor documentation, and lack of response or help.

Experience contributing to Wikimedia[edit]

~54.4% (n=5) respondents said they are likely to recommend Wikimedia for code contribution to friends and colleagues. ~64% (n=7) respondents said they are satisfied with their experience contributing to Wikimedia.

Suggestions for improvement[edit]

Here are some suggestions made by new developers (responses below have been only slightly edited):

  • Provide a faster out-of-the-box dev environment. The Vagrant machine is very slow, and installing everything from scratch is too much time consuming.
  • There should be a way to forward reviewers attention to a specific code change.
  • Bring the code review process into Phabricator as well, instead of relying on a third party tool, Gerrit.
  • Have cloud instances where an individual can deploy their code; that way support a temporary, automated way to test commits with smaller changes quickly.
  • Help newcomers to participate effectively instead of making them feel unprofessional. Everyone needs some time to find your way around in a new system.

Former developers survey analysis[edit]

We also sent a survey to 30 developers who were last active in July-September 2017 with a goal to understand more clearly what made them stop contributing.

Out of the 30 developers to whom we reached out, 1 (3.3%) completed the survey. Though from the low response rate, there isn't much to conclude, however one of the responses that we received from a developer is eye-opening:

"A bug is found and reported; a patch is submitted; nothing happens for a year and a half; the patch gets out of date, then gets updated and submitted by another programmer; many months later nothing has happened... You need to prioritize going through ALL the patches that have been submitted and either accept or reject them. Currently you're neglecting them, and that stinks. Maybe you should stop allowing any new bugs to be filed until you deal with the old ones."

Footnotes[edit]

  1. Steps: After extracting the list of "New Authors", use that list to filter on authors on Gerrit and its "Status" section.