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.