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.