Wikimedia Developer Summit/2017/Easy tasks

From mediawiki.org

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 (which project?) 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 owrk.
Google Code-in is working well. Maybe we need to have that process for the rest of the year.
Google Code-in gamifies the systen with incentives. If that works, maybe we should borrow it.
Think what incentivizes 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 formualated, well documented... However, the Easy task list is just intimidanting.
(Discussion about sending people to lists vs giving them a 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 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 contriibutor. Creates a social bond.
What happens when someone solves an Easy tag? Now basically nothing. We don  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 mentors for Easy tasks
  • (missed this one)
  • Eventually create a new list / tag for curated list.
  • 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 ategorization pr programming languages
  • Discuss incentives.
Retrieved from "https://www.mediawiki.org/w/index.php?title=Wikimedia_Developer_Summit/2017/Easy_tasks&oldid=2374575"