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

In T146960#2676286, @Mooeypoo wrote:

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 task 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).

In T146960#2676306, @Mooeypoo wrote:

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.

In T146960#2676416, @Tgr wrote:

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 task project page) and maybe less effort; no strong preference though.

@Aklapper do you see any relation between this task and T144273: Organize and coordinate Wikimedia's participation in Google Code-In 2016?

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 task tag?

• 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

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 task 'sub-categories' to sections on https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker ?

More bikeshed:

• The name good first task 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.

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.

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 task 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.

In T146960#3841668, @Aklapper wrote:

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.

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 task 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).

In T146960#3881395, @Aklapper wrote:

@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.

In T146960#3881405, @Framawiki wrote:

In T146960#3881395, @Aklapper wrote:

@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 task workboard.

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

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).

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

@Aklapper and I brainstormed on this task a few weeks ago. As the first step, we've added a big blue button "Pick from the latest tasks" on the Good first bugs page that links to five latest Phabricator tasks with no owners and patch put in for review: https://phabricator.wikimedia.org/maniphest/query/4Q5_qR51u_oz/#R . We agreed to regularly check the quality of the latest 10 good first bugs: https://phabricator.wikimedia.org/maniphest/query/YI3AKhXg_L8Y/#R