On 12/12/18 5:12 AM, Giovanni Tirloni wrote: I think to some degree it depends on the kind of task.  If the task describes an actual bug, then it seems wrong to close it if the bug still exists, even if fixing the bug is low priority. There was a recent fracas about this regarding the foundation wiki -- the communication team closed a bunch of issues that they didn't have time to fix, and the reporters took great offense. My first thought about this is that if an issue real but we just can't work on it, it should be left open but as lowest priority. If an issue isn't real (or there's disagreement about what should be done but the 'do nothing' side wins out) then closing wontfix seems OK.  Actually closing a bug that isn't resolved, though, seems wrong to me since people will re-report the same issue rather than finding the existing discussion of an issue.

On 12/12/18 2:18 PM, Andrew Bogott wrote: Agreed. I think I'm coming at this issue (is there any issue?) from the perspective that keeping the bug report open will only serve to give a false feeling to the reporter that someone will look at it. It's like projects like Fedora Linux do: after 2 releases, they will automatically close all tickets for release-2 _unless_ the reporter steps in and says they are still having the problem and can reproduce on a current release. We don't have releases to guide our process, that's why I proposed a time limit instead. Yes, I remember that. If that was a simple issue of how tickets were being closed, I would consider the whole thing very silly because I believe teams should be allowed to self-organize in the way they find most effective (we're using Kanban, others aren't). But the whole situation seemed to be a venting opportunity for a lot of other long standing issues, that relationship seemed to be deteriorated since a long time. My point being, simply closing the tickets shouldn't be taken as an offense but I understand that's not a opinion shared by the majority. My concern is that the platform is an evolving thing. What was a problem 2 years ago could not be a problem anymore today. I keep bumping into tasks that are 2-4 years old and then confirm the problem is gone. If we had an automated process in place, and considering we are very few and the workload is high, I think it'd be fair to share some responsibilities with reporters and ask them to confirm issues are still a problem after X months or accept they will be closed. A list of people with elevated privileges could always mark a certain task as "frozen" to avoid it being closed, if they think that it affords it. For instance, we have a long standing task to select a PaaS platform, there is no reason to have that automatically closed. We have various tasks about tools not working years ago, there's no reason to keep them open. I think my main points here are: 1) I see a problem with the amount of open tasks we have (and I'm not sure others agree, please provide your feedback) and 2) I believe maintaining these tasks should be a shared responsibility of reporters and fixers. -- Giovanni Tirloni Operations Engineer Wikimedia Cloud Services

On Wed, Dec 12, 2018 at 9:58 AM Giovanni Tirloni <gtirloni(a)wikimedia.org> wrote: The discussion here was constructive, so thank you all for that on what can be a contentious issue in our larger technical community. Giovanni, I would recommend that you have a discussion with Andre about ideas you may have for large scale workflow changes in Phabricator even if they are confided to "our" projects/tags. In his "bugmaster" role Andre has spent a lot of time documenting common practices in our community and comparing them to other communities he has worked with or studied. My current feeling is that it is appropriate to close tickets which are related to projects that have been abandoned and undeployed. For most others I would recommend the "lowest" prioritization approach that Andrew mentioned. I do agree that this makes viewing some tags in exclusion like the "all mail" problem you mentioned, but we do have our own tags that we can add/remove from issues to make tracking a bit less chaotic. Bryan -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Manager, Technical Engagement Boise, ID USA irc: bd808 v:415.839.6885 x6855