Page MenuHomePhabricator

Categorize #goodfirstbug (née #easy) tasks by required skills / scope, potentially as project workboard columns
Open, NormalPublic

Description

good first bug has limited usefulness as it exits now:

  • People sometimes use it for internal purposes and not for new developers (or at the very least don't take the effort to write an understandable description etc). E.g. T146008
  • Some tasks are labelled as easy by the maintainer; others by random people who think it might be easy but don't have a very good grasp of the potential problems. Even in the first case, seemingly easy tasks can turn out to be very hard (e.g. T85685). There is no way to tell if someone verified that the task is easy (that essentially means writing the patch for it in your head, so it takes non-trivial effort).
  • "Easy" spans a wide range, and the typical scenarios where we need easy tasks fall into different parts of that range, from "one-liner change on which you can learn using gerrit" to "a beginner can do it in a few days with guidance".

It would be nice to come up with some sort of triaging system. Some ideas:

  • create a workboard with a default "untriaged" column and some others; moving a task out of untriaged means that at least the requirements for https://phabricator.wikimedia.org/tag/easy/ have been checked
  • define difficulty groups for the typical use cases (GCI warmup, GCI normal, Outreachy microtask) and have a workboard column for each. For example:
    • copyedit: the task can be solved without setting up a developer environment (e.g. i18n message change, simple CSS change, trivial bugfix such as wrong visibility for a method). Good for a total beginner to go through account creation, get familiar with git & gerrit.
    • local env: something very easy that an experienced contributor could solve without thinking about it, but it does require a local development environment (ie. a good task for leading a new developer through vagrant etc. without them getting frustrated with the task itself)
    • GCI: should take 2-3 hours for an experienced contributor
    • Outreachy microtask: should take about a full day for an experienced contributor

See also:

Related Objects

Event Timeline

Tgr created this task.Sep 29 2016, 12:56 AM
Restricted Application added subscribers: TerraCodes, Aklapper. · View Herald TranscriptSep 29 2016, 12:56 AM
Qgil added a subscriber: Qgil.Sep 29 2016, 7:06 AM

I like this proposal a lot. Thank you @Tgr !

This is great, I really like this proposal!

Only recommendation is practical/organizational -- I'm not sure if Phabricator allows for this, but can we have those tags under one grand tag like "mentoring" ?

This way, we can also search the whole "Mentoring" tag and see all of those, or we can search for each separately, depending on the context of what we want to do. Same goes for new contributors that may want to start contributing but are open to tasks that are of either of those difficulty/complexity levels.

Also, a couple more comments:

  1. Some tasks will likely have more than one tag on them, especially the "Outreachy microtask" can be a little more generic, but I think that doesn't really matter, it's just something we should take into account.
  2. Speaking of "Outreachy microtasks", it could probably be a little more generic. If we define it as "Mentorship microtask" we can use them as a 'bank' of tasks for GSoC, Outreachy, and any other mentorship/internship we have, since most of them require more or less the same requirements.
  3. Same can be said about GCI -- it might be too specific, especially if we run into another type of short-term mentorship that is similar (like cooperation with schools or some project) -- we can find an alternative name for these, maybe? They will also likely overlap with the other tags, especially with the copyedit and local env tags, since those define the complexity rather than the scope.
  4. It would be great if we could have a single "go-to" page outlining the general rules for each of those, especially when it comes to our external internships like GSoC, GCI and Outreachy - they each have slightly separate rules of what you can and can't do or expect from an intern and it can be a little confusing. Outreachy allows for documentation, for instance, but GSoC doesn't, etc
Tgr added a comment.Sep 29 2016, 8:28 AM

Only recommendation is practical/organizational -- I'm not sure if Phabricator allows for this, but can we have those tags under one grand tag like "mentoring" ?

I was thinking of workboard columns (and keeping the single good first bug tag) but subtags would work as well. In that case mentoring could be an umbrella project. The main difference is I think that with workboard columns you could make searches like "show all easy tasks in mobile projects" but not "show all Outreachy-level tasks in mobile projects", and with subtags it would be the other way around (as Phabricator cannot search by workboard column and cannot make real boolean queries for tags).

It would be great if we could have a single "go-to" page outlining the general rules for each of those, especially when it comes to our external internships like GSoC, GCI and Outreachy - they each have slightly separate rules of what you can and can't do or expect from an intern and it can be a little confusing. Outreachy allows for documentation, for instance, but GSoC doesn't, etc

The tag description page(s) can be used for that (like the easy tag is now: https://phabricator.wikimedia.org/project/profile/169/ ) although they become less visible when a workboard is created.

Tgr added a comment.Oct 1 2016, 1:57 AM

The main difference is I think that with workboard columns you could make searches like "show all easy tasks in mobile projects" but not "show all Outreachy-level tasks in mobile projects", and with subtags it would be the other way around (as Phabricator cannot search by workboard column and cannot make real boolean queries for tags).

Actually workboards can be filtered on their own interface (and with subtags one can of course search by the umbrella tag) so both solutions would work. Which should it be? I would go with workboards, it's more transparent (no change outside the good first bug project page) and maybe less effort; no strong preference though.

Thanks! This is great, and I agree with all points made in Tgr's summary.

T131706: Have Mentored bugs between working on "Annoying little / easy bugs" and being an experienced developer? feels related when it comes to categorizing tasks for contributors who recently joined, hence I'm adding @01tonythomas as CC (who has a lot of expertise when it comes to obstacles for onboarding).

  • People sometimes use it for internal purposes and not for new developers (or at the very least don't take the effort to write an understandable description etc).

Do you think that "proper description" is clear enough on https://phabricator.wikimedia.org/tag/easy/ ? If not, what would you add as a recommendation to people adding the good first bug tag?

601 open #easy tasks to check and move into future workboard columns... I hope to connect a request to crowdsource this with the public Google Code-In call/announcement (T144273).

  • define difficulty groups for the typical use cases (GCI warmup, GCI normal, Outreachy microtask) and have a workboard column for each.

Yes!

  • copyedit: the task can be solved without setting up a developer environment (e.g. i18n message change, simple CSS change, trivial bugfix such as wrong visibility for a method). Good for a total beginner to go through account creation, get familiar with git & gerrit.

I understand the intention but would that imply that we allow (or even encourage) not testing patches? :-/ For example I've seen too many untested non-working {GENDER} patches and the task 'looked' trivial. (Cannot come up with a better name either such as 'one-liner', would be too limiting plus might still require testing in a dev environment.)

  • local env: something very easy that an experienced contributor could solve without thinking about it, but it does require a local development environment (ie. a good task for leading a new developer through vagrant etc. without them getting frustrated with the task itself)
  • GCI: should take 2-3 hours for an experienced contributor
  • Outreachy microtask: should take about a full day for an experienced contributor

Assuming these four items are a sorted list / scale from very easy to less easy I'd love to have better names. 'Outreachy microtasks' and 'GCI' likely require a 'dev environment', we've also had GCI tasks like 'fix three typos' or stuff like that, and I'm not sure that Outreachy microtasks should really take way more work than GCI tasks.

Maybe we can relate those new good first bug 'sub-categories' to sections on https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker ?

More bikeshed:

  • The name good first bug and its implications can be pretty demotivating. Because things are not always that easy at all. Thinking of "#Starters" and renaming mw:Annoying little bugs accordingly.
  • I was thinking of having mentors listed for tasks. But it's not a good idea to have single points of failure; people come and leave; we should make folks reach out to teams instead; plus mentors are for T131706.
Aklapper triaged this task as Normal priority.Oct 11 2016, 4:36 PM

adding something more to this one:

copyedit: the task can be solved without setting up a developer environment (e.g. i18n message change, simple CSS change, trivial bugfix such as wrong visibility for a method). Good for a total beginner to go through account creation, get familiar with git & gerrit.

Sub/child tasks which are similar and share a common subtasks are super good for begineers, like take a look at https://phabricator.wikimedia.org/T147390. If an experienced dev can create all those subtasks, and maybe fix one - it would be easy for a beginner to take a look at it, and solve a few from the list.

Qgil added a comment.Oct 27 2016, 1:25 PM

Would this task be a good topic for the Wikimedia-Developer-Summit (2017) ? If so, the deadline to submit new proposals is next Monday, October 31: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/Call_for_participation

Marking T149564 as subtask, in the sense that let's focus the attention on that Summit session now, and let's see what are the next steps resulting from it in a few weeks.

@Aklapper @srishakatux in your experience, how relevant is this problem today in the context of onboarding new developers? What is the current status in terms of thoughts or plans?

Starting with the current situation: I consider the workboard of good first bug as not helpful:
Currently the "Doing" column (created in 2015) seems to just duplicate the Patch-For-Review tag (I mentioned that in T65577#3810955)?
It seems that @Framawiki recently moved quite a bunch of tasks into that column. I'm not entirely sure why. For example, some tasks received a patch ages ago, that patch is CR-2 in Gerrit, and has not seen any updates since then. I would not call that "Doing". :) But maybe I'm missing something here? Hence CC'ing @Framawiki.

It seems that @Framawiki recently moved quite a bunch of tasks into that column. I'm not entirely sure why. For example, some tasks received a patch ages ago, that patch is CR-2 in Gerrit, and has not seen any updates since then. I would not call that "Doing". :) But maybe I'm missing something here? Hence CC'ing @Framawiki.

Since all the tasks having Patch-For-Review indicate that a partial job has already started, I have moved these to the corresponding column. So it's a very obvious duplicate, but I think it's not so bad for visibility reasons.
It has allowed me to find several abandoned patches, and there is still a lot to review.

Aklapper added a comment.EditedDec 17 2017, 10:58 AM

but I think it's not so bad for visibility reasons.

@Framawiki: I think it is bad. It creates additional manual work (someone needs to move tasks to the column) and noise for anybody (column change notifications), without a clear gain. I want to remove that column. Anyone can easily filter tasks on that workboard which [do not] have the Patch-For-Review tag.
Plus in my use of language, "a partial job has already started" does not imply "Doing" if some patch from years ago needs rewriting. That's not my understanding of "Doing", to the contrary.

In T146960#3842930, @Aklapper wrote: that

Plus in my use of language, "a partial job has already started" does not imply "Doing" if some patch from years ago needs rewriting. That's not my understanding of "Doing", to the contrary.

In my language, "Patch for review" indicate that something is waiting for review :) and implicitly that the current patch is a blocker for newer ones. The problem come from years ago patchs need to be triaged, cleaned and potentially mark as "abandoned" if it can't be merged.

@Framawiki: I agree that Patch-For-Review is not the best wording (when we introduced that tag we could not find a shorter phrase which means "there is a patch in some state in Gerrit related to this task and maybe that patch is helpful or not").
But that feels unrelated to my question: What's the actual problem solved by manually duplicating work, if all tasks under "Doing" have that tag anyway? Why do we/you need or want to track "Doing" for good first bug tasks?

@Framawiki: FYI, I'm planning to remove the "Doing" column from the workboard, as I don't see any advantage in having it (see previous comments).

@Framawiki: FYI, I'm planning to remove the "Doing" column from the workboard, as I don't see any advantage in having it (see previous comments).

Hello, I understand your arguments and I don't see anything against it, it can only simplify things.

I removed the link to the workboard on https://phabricator.wikimedia.org/project/profile/169/ as I do not see how that helps anybody.
(No idea if there is an easy way to move all "Doing" items, maybe by hiding that column?)

I added links to "Open tasks without patches" and "Open tasks with patches" to the sidebar (which offers exactly what people did beforehand by manually dragging tasks from one column to another, for reasons I do not really understand), plus added mouse-over hints what that means.

Elitre added a subscriber: Elitre.Feb 13 2018, 6:01 PM

@Framawiki: FYI, I'm planning to remove the "Doing" column from the workboard, as I don't see any advantage in having it (see previous comments).

I understand your arguments and I don't see anything against it, it can only simplify things.

Workboard column "Doing" emptied and hidden now on the good first bug workboard.

(We could now in theory discuss which columns we want.)

Aklapper renamed this task from Better triaging system for easy tasks to Better triaging system (categorization) for easy tasks.Sep 24 2018, 10:04 AM

Seeing Tgr's categorization proposal for difficulty groups above (copyedit; local env; GCI; microtask), mw:WMCS/Our_audiences came to my mind as a similar example (No technical skills needed; Some code; Code and command line; System administration).

Aklapper renamed this task from Better triaging system (categorization) for easy tasks to Categorize #goodfirstbug (née #easy) tasks by required skills / scope, potentially as project workboard columns.Sep 30 2018, 8:00 AM
Aklapper lowered the priority of this task from Normal to Low.Jul 17 2019, 11:31 AM
Quiddity updated the task description. (Show Details)Aug 22 2019, 8:53 AM
srishakatux updated the task description. (Show Details)

Taking this up! Will share a concrete idea on the next steps in some time.

srishakatux raised the priority of this task from Low to Normal.Aug 22 2019, 9:08 AM
Elitre removed a subscriber: Elitre.