Page MenuHomePhabricator

Better recommending of tasks suitable for new technical contributors
Closed, ResolvedPublic

Assigned To
Authored By
Oct 31 2016, 1:24 PM
"Love" token, awarded by srishakatux."Like" token, awarded by Qgil."Like" token, awarded by Tgr."Like" token, awarded by Miriya52."Like" token, awarded by Aklapper."Like" token, awarded by Trizek-WMF."Like" token, awarded by Johan.


Session title

Better recommending of tasks suitable for new technical contributors

Main topic

How to grow our technical community

Type of activity

Unconference session



=== 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 [[ | mw:Annoying_little_bugs ]] from numerous pages, such as [[ | 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 ==

== 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:

Better recommending of tasks suitable for new technical contributors

Day & Time: Jan 09, 13:30

Room: Cypress

Phabricator Task Link:

Facilitator(s): TheDJ

Note-Taker(s): QuimGil


Purpose: See

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.

Related Objects

Event Timeline

Aklapper triaged this task as Low priority.

@cscott: I don't see how T149948 is specifically related to small, self-contained, well-described tasks for new contributors.
Care to elaborate?

There is also OpenHatch (MediaWiki, Vagrant, gadgets), not sure if that's used by anyone.

There is also OpenHatch (MediaWiki, Vagrant, gadgets), not sure if that's used by anyone.

Related: T146969: Support OpenHatch

However, I think it is better to focus first in the source of the problem (how to maintain lists of good tasks for first contributors). Once this is solve, exporting to OpenHatch or other contexts should be a relatively straightforward technical problem.

So here is an idea: create an opt-in list of software projects welcoming contributors, work on "Better recommending of tasks suitable for new technical contributors", and forget (for now) about the rest.

Hard requirements for a project to join this list:

  1. Active maintainers welcoming new contributors and explicitly requesting to join the list.
  2. Documentation for first time contributors.
  3. Easy tasks for starters.

Nice to have:

What Developer-Advocacy offers:

  • Support promoting your project in developer events, outreach programs, communication channels.
  • Technical support and other types of help guiding new volunteers towards successful contributions.
  • Bonus points for your contributors applying for scholarships and grants.
  • Possibility to organize bug triage, code review, and documentation sprints.

This is just a raw proposal, you get the idea. We would focus our attention and effort in the projects willing to play ball, and in exchange of that we would de-prioritize all the rest. Better than trying to support and find a solution for everybody.


Hard requirements for a project to join this list:

  1. Active maintainers welcoming new contributors and explicitly requesting to join the list.
  2. Documentation for first time contributors.

On specific info how to develop? Makes sense if applicable. But no need to create (/duplicate) docs for the sake of having docs. mw:Wikimedia Apps/Team/Wikipedia Android app hacking is a good example of useful info.

  1. Easy tasks for starters.

...and someone feeling responsible to keep that list of easy tasks updated.

I am wondering whether this session is really a good fit for a pre-scheduled one (jn a bigger room with video recording). It looks like this could perfectly be a hands-on discussion/workshop where ~15 people go through the points above? In other words, an Unconference session.

Also, can we start working/discussing here? I tried, with a proposal. :)

Silence. I will move it to Unconference. If you think this is a bad idea, we can still reconsider it.

Unconf is perfectly fine; thanks!

To maintain the consistency, please consider referring to the template of the following task description:

Tgr updated the task description. (Show Details)
Aklapper raised the priority of this task from Low to Medium.Jan 4 2017, 10:09 PM

To the facilitator of this session: We have updated the unconference page with more instructions and faqs. Please review it in detail before the summit: If there are any questions or confusions, please ask! If your session gets a spot on the schedule, we would like you to read the session guidelines in detail: We would also then expect you to recruit Note-taker(s) 2(min) and 3 (max), Remote Moderator, and Advocate (optional) on the spot before the beginning of your session. Instructions about each role player's task are outlined in the guidelines. The physical version of the role cards will be available in all the session rooms! See you at the summit! :)

Note-taker(s) of this session: Follow the instructions here: After the session, DO NOT FORGET to copy the relevant notes and summary into a new wiki page following the template here: and also link this from the All Session Notes page: The EtherPad links are also now linked from the Schedule page ( for you!

Ah, alright, that empty one was linked in several places already so I copied content over. Sorry :)

Aklapper moved this task from May to June on the Developer-Advocacy (Apr-Jun 2017) board.

Resolving as this Developer Summit 2017 session task has served its purpose. It is superseded by the Onboarding New Developers program / T164084: [FY 17-18] Program 12: Onboarding new developers and its subtasks (such as T165920), focusing on software projects with available and committed mentors, instead of separate good first task tasks which offer no committed mentors and do not provide a long-term onboarding perspective.

Which exact role good first task tasks are going to play in the long-run has still to get sorted out in the context of our on-wiki documentation for potential new developers (cf. T167065: Revise outreach program documents), however it is already clear that we will recommend good first task tasks way less than in the past.