#easy 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: {T122683}