Question is if "could be accomplished by a Volunteer" (what does that mean? No access restrictions to required infrastructure etc? When can something NOT be acc by a volunteer?) is similar enough to "suitable to get a first approach of our code base for new developers" ("easy" tag). I'm afraid not.
@Lydia_Pintscher once explained the reason for "need-volunteer" but I cannot find it in Phab, emails or IRC logs.
If I remember correctly, the argumentation was that
- trivial enough to tag it as "easy"
- unimportant enough that noone of your team plans to work on it to set the lowest priority
both do not cover "not entirely trivial but could be worked on by volunteers and would be welcome but as not totally unimportant after a long time non-volunteers would have to work on it anyway"? Though that really sounds to me like "just raise priority after that certain time, and add such tasks earlier to your planning sprint project that starts in six months", personally.
So to me this is rather about sorting out the priority value set if you rely on volunteers ("need-volunteer"?).
I'd really like to keep the need-volunteer tag. Wikidata has a lot of open tickets. A considerable amount are requests that either are questionable, will likely be done as part of some larger effort or need a lot more thinking. A part of all bugs I have gone through and determined:
- it is something we actually really really want (as opposed to maybe but not so sure about it really)
- it doesn't need a lot of discussion anymore to figure out how to do it
- it doesn't interfere with anything we're currently working on
- it can be done without a huge amount of super special knowledge about Wikidata
They get the need-volunteer tag. Those might well be tasks we work on anyway in 2 or 3 sprints. The priority field does not cover this. Priority is independent of this assessment.
This list is then used whenever someone asks where they can help out with Wikidata development.
I would suggest getting rid of analytics-volunteering and use a combination of need-volunteer and analytics instead.
@Aklapper when the analytics team discussed identifying tasks a volunteer could take on, we also saw the opportunity to create a work board with 3 columns: easy, medium, hard. We haven't done this yet and it's not urgent.
I can see some benefits to consolidating everything under one tag "need-volunteer". Let me discuss this with my team first and get their buy in.
Ah. Thanks! Those easy ones should probably also have an "easy" tag, for consistency and less isolation (when a new contributor is simply searching for all open tasks with "easy" tags).
In T78617 we have been discussing that the opposition between "volunteers" and the maintainers of a project (assumed to be non-volunteers) is problematic. After some convincing I agree now, but I see the same risk in the labels mentioned here.
What do we mean when we say "needs volunteer"? In fact what we mean is that the regular team members are not planning to work on such task any time soon, or ever, but that still, such feature would be welcomed by the maintainers. I guess we are also implicitly saying that the maintainers are aware of this task, and that even if they don't have to work on it themselves, they would be happy giving some guidance to whoever wants to take them. These tasks are somehow curated.
So what about #Contributors-Welcome?
We leave behind the volunteer vs non-volunteer wording, and we put the focus on the real axis: new contributors vs regular maintainers, on tasks that the maintainers think that are very useful and well suited for someone new. Some of these tasks will also be easy, and will incorporate the related #easy tag.
Contributors are basically always welcome, except for when the infrastructure setup does not allow contributing. That's basically the same discussion as the confusing "Needs Volunteer" priority value.
and we put the focus on the real axis: new contributors vs regular maintainers
In that case, shouldn't it be #New-Contributors-Welcome ?
Those tasks are not just for new volunteers ;-) And I'd contest "contributors are always welcome". We have an open project but there are legitimate reasons for a task to not be open for contributions. For example I have a number of tasks that don't look like it but are freaking time consuming and I'd feel really bad for anyone taking this on.
"Good-For-Volunteers" or "Ready-For-Volunteers"?
I believe this is what Lydia and Kevin have in mind when they use these labels. Some tasks are better than others for volunteers, even if all of them are open and waiting.
Analytics-Volunteering is more verbose in its description:
This is a tag for analytics tasks that could be accomplished by a Volunteer. The tasks have been vetted by the engineering team to be appropriate and avoid stepping on each other's toes.
I think we can extrapolate this description to any other team or project willing to use "Good-For-Volunteers" / "Ready-For-Volunteers".
- Analytics-Volunteering project removed from tasks; Need-Volunteer added.
- Updated Analytics-Volunteering task description and archived.
Corresponding query (hmm, Analytics isn't an umbrella project? Meh) to find these tickets is now https://phabricator.wikimedia.org/maniphest/query/L0DA69IJ6Gi7/#R (Feel free to save and share that query!).