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