The changes you see were due to me. The Status change was a convenience to me for follow up, but as noted, has caused alarm. My apologies for that. I am already in process of sending updates and resetting the status, but am doing so in blocks to not spam anyone. Give it a few days and all will be well. <br><br>In regards to Haralds script, it is fully functional now and appears to work very well. <br><br><br><br><br>-------- Original Message --------<br>On Nov 16, 2018, 4:37 AM, Luigi Toscano < luigi.toscano@tiscali.it> wrote:<blockquote class="protonmail_quote"><br><p dir="ltr">Andrew Crouthamel ha scritto:<br>
> I've been spending a lot of time browsing, searching, and filtering our bugs<br>
> in Bugzilla. One of the areas I've found that could use improvement, are the<br>
> NEEDSINFO bugs. Often, bugs are placed into this status, either awaiting<br>
> additional information or backtraces, never to be updated again. We have<br>
> NEEDSINFO bugs dating back to 2009.</p>
<p dir="ltr">Hi,<br>
the (semi)automated process which pings and then closes NEEDINFO bugs was<br>
implemented, but I've noticed another policy which was never discussed (as far<br>
as I know) here: bugs opened for a while</p>
<p dir="ltr">I disagree with this policy, and I'm not alone (at least another maintainer<br>
asked for his product to be excluded):<br>
- not all projects distinguished between CONFIRMED and UNCONFIRMED (now<br>
REPORTED), so it's possible that a perfectly valid bug or request (especially<br>
requests) seems stale. You may say that it's easy to flip the status again.<br>
I'd say that it's a unneeded step.<br>
- at most the script could add a new comment asking for updates, but not<br>
immediately change the status out of the blue.<br>
- as mentioned, it was not discussed.</p>
<p dir="ltr">Please disable it for now, or just enable it for projects who explicitly wants<br>
it for now.</p>
<p dir="ltr">--<br>
Luigi<br><br></p>
</div>