On 12/12/18 5:12 AM, Giovanni Tirloni wrote:
On 12/12/18 7:31 AM, Alex Monk wrote:
Sounds to me like it'd just be more work because someone would have to go around reviewing the tasks it closes and probably reopening the majority. Also it doesn't make much sense to do this at a project-level, if it's done it should probably be across the whole of Wikimedia Phabricator.
If we start small and prove it works, it's easier to expand to make it a general policy. Starting big from the beginning is going demand consensus which will be hard to get, understandably.
Just because there hasn't been anyone to work on the task doesn't mean it's now irrelevant.
It gathers were there is interest from both parties, the one who reported and the one who is available to fix it.
Closing tasks doesn't mean they will disappear. They will still exist and serve their purpose to document what may once been an issue. Also, we can mark them with a tag "frozen" so they're skipping from the automated process.
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.
I understand it's a different perspective from what has been adopted so far but the tasks are currently unmanageable as is. You can't realistic get a list of open tasks and know what is still broken, what needs work, etc. It's more like Gmail's "All Mail" at this point.
When projects like Kubernetes, from where I draw my experience with this method of work, adopted this policy, it initially caused some stress but I rarely see any complaints (if any) after it was implemented. I don't mean to piggyback on the Kubernetes hype but they are a very large project with a huge number of contributors, so I believe their experience is relevant.
The alternative is to keep the status quo if there is consensus this is desired. I'm fine with that too.