Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-dev] Vote to stop bug auto-closing in all Eclipse platform projects



Op vr 18 feb. 2022 om 15:54 schreef Mickael Istria <mistria@xxxxxxxxxx>:


On Friday, February 18, 2022, Sebastian Zarnekow <sebastian.zarnekow@xxxxxxxxx> wrote:
> The Bot that does the auto-closing at Eclipse though doesn't give a heads-up, many tickets are never looked at.

I personally look at all notifications I receive from Bugzilla and react to auto-close tickets either by taking the decision of not reopening, or by reopening with extra info, just like it's recommended in the message.
And I'm happy with it bith as a reporter and a committer.

In this case you are a friendly user, so although you are happy with it as a reporter, it might not be representative of the larger user community.
I get your point of having a reminder to look into a ticket again, It is only a pity that it takes 2 years to get the reminder to look into an issue again. As you get a reminder, you did have shown some interest in the bug before. A more gentle reminder, such as a report that is emailed to you or a query you run yourself would give a better impression of the project.
Also way too often bugs are closed without any reaction from the project to it, there are currently at least 473 open bugs in platform without any comment from a committer [1]. By the time the auto-close reminder comes in, most users already gave up expecting any comment on the bug. The auto-close is just a confirmation that the bug is ignored and the project doesn't seem to care.

 

But if some people take the decision to not care about those notifications ,don't read them, don't react and fully ignore the bug just like if notifications were not sent, then it's not really the process or the bot notifications that's to blame if some bugs are ignored...

If after reporting a bug, the bug was totally ignored by the project, why should I as a reporter care if it gets auto-closed? Personally, why should I spend my limited time on re-opening issues when they get auto-closed? I won't magically get time to work on a bug if it is auto-closed. I will re-open when I find the time to work on the bug. I consider a bug labeled with "stalebug" as an open bug anyhow.
 

> If the only interaction with the reporter is an automated `Please reopen`

It's not what the message that comes with auto-close recommends as possible reaction, and I've personally seen -and even fixed- several bugs that I would have ignored if there were no notification. Maybe it's not something you've encountered yet,but it does exist anyway.

Again, the problem here is that you need a notification to care about a bug at all. Auto-closing should be a final resort, and the majority of auto-closed bugs should be fixed or be inreallant by the time they get auto-closed, this is currently not the case. Please consider another kind of gentle reminder.


> it's just sad and the poorest version of valuing contributors.

I find keeping the bug open and letting reporter face a heavy silence or build hope that it will just get fixed while no code contributor will care to fix it is in the end less nice to contributors that telling them "hey that's old! Is it still relevant? If yes, please reopen"

If the reporter waits for the auto-close reminder, before sending a reminder himself, he already gave up hope to get any reaction, let alone to get a fix. So instead of a reminder, it is a confirmation that the issue is indeed ignored, why would a reporter bother to keep interest in a project that ignores its input?

> IIRC whenever people ask how to contribute, part of the answer is also "file bug reports".

Who told that the goal or even the real effect here is to reduce the amount if incoming bug reports? There's probably something you misunderstood.


In the end it is all about perception, I am not against an auto-close of bugs as a final resort. However, given the current state of the project, the auto-close can be for many the confirmation that the project is dying and they are moving away. Also, given the amount of resources, the auto-close period should be in line with that.

It would be better if bugs are triaged, and re-evaluated by committers instead of an automatic process. There used to be a process in which at bugs were triaged and labeled as "helpwanted" or "low-priorty" [2]. But of course this takes up scarce resources. Note that being actively working involved with bugs is one way to show that a project is alive, if you are lucky you might attract some new committees in the process too.
Instead of just discussing the auto-closing of bugs, I would rather like to see a discussion to revamp a bug-triage process and reminder process, in which auto-closing might have its role. E.g. auto-closing bugs marked with "needinfo" after only weeks would make sense to me.


+1 for stop auto-closing in its current form.

Regards,
Rolf


Back to the top