On 12/12/18 2:18 PM, Andrew Bogott 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.
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.
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.
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 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.
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.