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 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.