Closing NEEDSINFO bugs after 30 days

Andrew Crouthamel andrew at crouthamel.us
Tue Sep 18 20:56:09 BST 2018


Thanks Harald,

I've spoken with buovjaga and x1sc0 regarding their LibreOffice QA procedures: https://wiki.documentfoundation.org/QA/Bugzilla/Gardening#Task:_Cleaning-out_NEEDINFO

Linked there are some scripts that are run either automated or manually. The NEEDSINFO one is manual right now. Here is the full listing of scripts: https://gerrit.libreoffice.org/gitweb?p=dev-tools.git;a=tree;f=qa

Maybe you could craft something similar that could be cron'd.

If you end up investigating the LO scripts, the createMassPingLists.py apparently uses a JSON file that is created from https://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/esc-reporting/esc-collect.py

For procedures I'd like to do the same as you recommend:

> -   3 days pass -> comment gets added
>
> -   15 days pass (33 days since status change) -> reminder comment again

* Bugs placed into NEEDSINFO status will received a reminder if the ticket is:
  - At least 15 days old
 AND
  - Has not received any comment within 15 days
* If a bug remains in NEEDSINFO for another 15 days with no comment, it will be closed as RESOLVED > WORKSFORME.
* If a bug remains in NEEDSINFO with a comment provided within less than 15 days, no action will be taken (as it does not meet the above criteria).

That way if devs/reporters are conversing in a ticket while in NEEDSINFO status, it won't get closed accidentally.


Here is a reminder email:

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!


Here is a closure email:

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!



Andrew Crouthamel

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, September 18, 2018 6:40 AM, Harald Sitter <sitter at kde.org> wrote:

> On Mon, Sep 17, 2018 at 8:25 PM Nate Graham nate at kde.org wrote:
>
> > +1, in favor, especially if we can close them in an automated fashion. Closing bugs isn't as frustrating for filers as it used to be anyway, since if they ever show up again with new information, they can just re-open them.
>
> Should be easy to program this if we are agreed on the procedure.
>
> What I would suggest is:
>
> -   15 days after the bug has entered NEEDSINFO and not received any
>     further comments a comment is automatically posted "yada yada this bug
>     report needs info, please provide it or ask if you don't understand
>     what's needed, else closure in 15 days of inactivity" (message TBD
>     obviously)
>
> -   30 days after the bug has entered NEEDSINFO and not received any
>     further comments it gets closed with a comment "yada yada no data
>     provided, if you feel you can provide data reopen and provide data"
>
>     by throwing in a comment to "warn" 15 days after the status change
>     it's not too spammy while also acting as a reminder in case the
>     subscribers meant to provide the info but then forgot.
>
>     Personally I would even say the 15 day reminder should be sent every
>     15 days of inactivity, because of the reminder aspect (might be a bit
>     too spammy though?)
>
>     e.g.
>
> -   NEEDSINFO change
>
> -   15 days pass -> reminder comment
>
> -   3 days pass -> comment gets added
>
> -   15 days pass (33 days since status change) -> reminder comment again
>
>
> (could be different comment "this bug appears to have gone stale,
> please provide info or nudge out of needsinfo")
>
> Anywayyy... I can throw together some automation so long as someone
> tells me what exactly the process should be :P
>
> HS





More information about the kde-community mailing list