On Tue, 2018-10-02 at 22:24 +0500, Michael Holloway wrote:
I think I can provide some context here, because this
really seems to be
about something specific. The Reading Infrastructure team recently
inherited maintenance responsibility for the Wikimedia maps stack,
resourced on a very limited basis. Along with that, we inherited a backlog
of many hundreds of tasks, many of which have seen no activity for years.
For the past couple of months, a few of us have spent an hour each week
trying to work through the backlog trying to triage all of these. In the
course of these grooming meetings, we have closed more than a few tasks
based on a combination of not having the resources to work on them, and it
not seeming likely that anyone else will, either; the theory here is that
it can better reflect reality to openly decline a task than to let it
languish in a backlog indefinitely.
If this contravenes the relevant norms, I apologize. If you were upset by
the closing of what you believe to be a valid maps ticket, please feel free
to reopen. Thanks.
Has it been considered to keep tasks open and set the Priority field to
'Lowest'? Plus potentially add the #Needs-volunteer project tag (though
nobody knows what that tag is supposed to exactly imply, I'm afraid)?
*If* separate project tags for "the software code base" vs "our team's
workboard" exist, it could also be an option to remove the "team
project tag" with a comment that the team does not have resources to
work on this. The latter completely depends on team workflows as some
teams have Herald filter rules to automatically add their "team project
tag" to tasks associated with a "software code base" tag they maintain.
In general, it is possible to exclude tasks with a certain priority or
certain tag from search results and from being displayed on workboards.
And on a high meta-level, hoping to offer some perspective:
Many people who use task tracking systems in collaborative free and
open source projects are not used to a single authority. This is
directly related to not necessarily realizing that product management
requires saying No/Wontfix/Declined to many bugs and ideas.
In theory, when the code base is public and welcomes contributions, a
random stranger could drive by and provide a patch for a low[est]
priority ticket that has been open for years. It's unlikely but not
impossible. That's why some people might expect tickets to remain open
if those tickets are not "completely out of scope" for the project.
andre
--
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/