Session title

Better recommending of tasks suitable for new technical contributors

Main topic

How to grow our technical community

Type of activity

Unconference session

Etherpad

https://etherpad.wikimedia.org/p/devsummit17-EasyTasks

Description

=== 1. The problem ===

FOSS projects have a **chicken and egg problem**: Some interested people manage to join IRC or a mailing list, state that they want to contribute, and expect us to tell them what to work on.
However, FOSS projects have a "scratch your own itch" attitude so we expected contributors to choose themselves what to work on.
We link to [[https://mediawiki.org/wiki/Annoying_little_bugs | mw:Annoying_little_bugs ]] from numerous pages, such as [[https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker | mw:How_to_become_a_MediaWiki_hacker ]].

* Links to Phabricator queries on mw:Annoying_little_bugs are sorted by functionality areas (Phabricator projects as search criteria), require another click, and the Phabricator **results might get incomplete** as project naming and organization changes in Phabricator.
* Some potential contributors mention which **programming languages** they know. We can recommend projects but do not offer a "list" of projects per programming language.
* Some **project developers/maintainers are not aware of `#easy`** and do not mark tasks as such. For existing `#easy` tasks, the lists are not much nurtured by developers/maintainers.
* There are also different **levels / scopes of 'easyness'** (technical requirements or required knowledge for a new contributor) which currently are not exposed either.
* After a contributor has worked on an `#easy` bug, we do not have a **follow-up concept** in place how to make contributors grow their knowledge and become regular developers.
* Bonus bikeshed if too much time is left: The terms "Annoying little bugs" and "easy" might not be the best names (I get frustrated if I cannot fix a bug supposed to be "easy" and I don't see how many of those starter bugs are "annoying").

=== 2. Expected outcome ===
* Answers or agreement on approaches to (some of) the problems outlined above in the bullet points.
* Generally more awareness of (correctly) applying the #easy tag across developer teams.

=== 3. Current status of the discussion ===
See links listed below.
(If you want to discuss a specific aspect already covered by a task listed below, please use that task listed below. For general or high-level comments on recommending tasks that are suitable for new technical contributors, please use this very task.)

=== 4. Links ===
* #easy
* {T146960}
* {T136866}
* {T122683}
* {T131706}
** "and then what" (e.g. "mentored bugs") is related to {T148557}


== Proposed by ==
@Aklapper, @srishakatux

== Preferred group size ==
15-20

== Any supplies that you would need to run the session ==
Post-its and markers

== Interested attendees (sign up below) ==

# @Qgil
# @Tgr
# @Miriya52
# Add your name here

-----

Quick copy & paste of Etherpad content:
=================

Title:
Better recommending of tasks suitable for new technical contributors

Day & Time: Jan 09, 13:30

Room: Cypress

Phabricator Task Link: https://phabricator.wikimedia.org/T149564

Facilitator(s): TheDJ

Note-Taker(s): QuimGil


**SESSION SUMMARY**

Purpose: See https://phabricator.wikimedia.org/T149564

People come to IRC and ask for a task to do. They get a link to a page with a list of possible things. Here starts a problem of missing expectations.

(Andre goes through the points listed in the Phabricator description)

T146960: Better triaging system for easy tasks

Gergo: one option would be categorizing easy tasks in a workboard?
TheDJ: maybe it is better to start by agreeing the problem.

As a developer, marking something as Easy is... not easy, because you don't have the perspective of a newcomer.

We became with Easy tasks as a way to get newcomers involved.

(...)

Different motivations for putting Easy tag. Onboard potential volunteers? I don't have time for this / it's not enough important to me?

Easy tasks goes together with willingness to mentor.

Has there been attempted other names? "Needs-volunteer" was used in the past.

In Mozilla we have "Good first tasks". They need to have good documentation, mentors...
How to assure they requirements are in place?
It works for us. Someone owning this problem and in charge to define the process.

In open source projects the passion needs to be the motivator. If this is not in place, then the rest won't work.

Google Code-in (GCI) is working well. Maybe we need to have that process for the rest of the year.

Google Code-in gamifies the system with incentives. If that works, maybe we should borrow it.

Think what incentives open source contributors. For instance "certificates" that you have resolved bugs for one of the largest websites of the Internet.

As a new contributor, I know that when they find "Annoying little bugs" they bookmark it, the name is good. But then it takes a long time to find a task.

A document "solving your first task", explaining the basis who to ask, etc.

We have a bit of these docs, but they are spread. There is so much to read... We provide too much information. Overwhelming.

Outreachy intern: that process is good, with a board, tasks with mentors... Those tasks are well formulated, well documented... However, the Easy task list is just intimidating; too long

(Discussion about sending people to lists of tasks vs giving them an explicit task.)

Summary so far:

* Easy tasks should be mentors assigned.
* Whoever tags it should mentor it?
* Google Code-in, anyone can propose but then someone needs to validate.

What about a separate list of tasks started from scratch, curated, shorter.

When tasks are presented to newcomers, they should be reviewed and, if needed, rewritten. Currently we just add the tag.

Meeting someone first makes a whole difference. Step 1: meet your mentor. This is more time consuming upfront, but probably better to establish an emotional link and get a longer term contributor. Creates a social bond.

What happens when someone solves an Easy tag? Now basically nothing. We don't track this, we don't follow up.

Imagine an email or something congratulating when someone finishes a first task... asking what went well, what was difficult. That would help us improve.

Feedback loop ok, but we need to be careful because that also brings a lot more work to some mentors vs others.

Gergo: this is another incarnation of our problem of not seeing developers as an audience. We don't do surveys...

(Everybody has spoken up, great!)

(Andre makes a summary of things so far, 15 minutes left)

Still would like to discuss:

T136866: Improve per-programming-language listings

(It is clear that this would be useful, especially for the less used languages !JS !PHP but there is discussion about how to do this).

Action items:
* Discuss having explicit mentors for Easy tasks (vs. tagging as easy because someone else should do something)
** Make sure mentors have IRC etc. contact info on their Phab user page
* (missed this one)
* Eventually create a new list of tasks / separate tag for curated list (cf. "needs mentor" column on GCI board)
* Include topic for discussion in WMF Annual Plan, as a way to reach to a decision about goals and resources to get this done (or not)
* Discuss a categorization per programming languages
* Discuss incentives.