Re: Closing NEEDSINFO bugs after 30 days

[Harald Sitter]

On Mon, Nov 19, 2018 at 1:12 AM Myriam Schweingruber  wrote:
>
>
>
> On Fri, 16 Nov 2018 at 14:22, Harald Sitter  wrote:
>>
>> On Fri, Nov 16, 2018 at 2:16 PM Boudewijn Rempt  wrote:
>> >
>> > On vrijdag 16 november 2018 14:11:29 CET Harald Sitter wrote:
>> >
>> > > - human sets needsinfo
>> > > - 15 days pass: bot posts reminder
>> > > - reporter comments
>> > > - N days pass: bug gets automatically dropped back to whatever the
>> > > previous state was?
>> >
>> > Yes, that would be perfect! As far as I'm concerned, N can be 0 or 1.
>>
>> Cool. Should be easy to do.
>>
>> Any disagreements from the rest of the community?
>>
>> TLDR: if the original reporter comments on a needsinfo bug it gets
>> automatically switched back to whatever the state before needsinfo was
>
>
> It slightly disturbs my triaging routine, as I routinely check the NEEDSINFO 
> I set within a month (and I have saved searches for this), so could "my" bugs 
> be excluded, please? It is a really short time span, I always consider people 
> to be away for longer than just two weeks (holidays, etc) which is very often 
> the case. Some bug reports do answer on a regular basis, just noth within 2 
> weeks in all cases.

This is about the original NEEDSINFO discussion, not related to the
question I posed, is it?

If the timing seems unsuitable I'd like changing it discussed within
the bug squad. I am just the code monkey, in that capacity I'd like to
avoid a wall of conditions for every person doing bug triage.

HS

Re: Closing NEEDSINFO bugs after 30 days

[Myriam Schweingruber]

On Fri, 16 Nov 2018 at 14:22, Harald Sitter  wrote:

> On Fri, Nov 16, 2018 at 2:16 PM Boudewijn Rempt  wrote:
> >
> > On vrijdag 16 november 2018 14:11:29 CET Harald Sitter wrote:
> >
> > > - human sets needsinfo
> > > - 15 days pass: bot posts reminder
> > > - reporter comments
> > > - N days pass: bug gets automatically dropped back to whatever the
> > > previous state was?
> >
> > Yes, that would be perfect! As far as I'm concerned, N can be 0 or 1.
>
> Cool. Should be easy to do.
>
> Any disagreements from the rest of the community?
>
> TLDR: if the original reporter comments on a needsinfo bug it gets
> automatically switched back to whatever the state before needsinfo was
>

It slightly disturbs my triaging routine, as I routinely check the
NEEDSINFO I set within a month (and I have saved searches for this), so
could "my" bugs be excluded, please? It is a really short time span, I
always consider people to be away for longer than just two weeks (holidays,
etc) which is very often the case. Some bug reports do answer on a regular
basis, just noth within 2 weeks in all cases.

Regards, Myriam
-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org

Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)

Re: Closing NEEDSINFO bugs after 30 days

[Harald Sitter]

On Fri, Nov 16, 2018 at 2:40 PM Alexander Potashev  wrote:
>
> пт, 16 нояб. 2018 г. в 16:35, Boudewijn Rempt :
> >
> > On vrijdag 16 november 2018 14:31:39 CET Alexander Potashev wrote:
> >
> > > You only considered to case when human sets NEEDSINFO. If NEEDSINFO is
> > > set by a script, we may have the same problem, would you suggest
> > > implementing the same behaviour?
> >
> > We don't have the script setting NEEDSINFO, do we? At least, I didn't see it
> > in Harald's list of options.
>
> Hopefully we don't. I noticed such change in some bug reports, however
> all of them are attributed to Andrew himself, not the "bug janitor"
> account. Sorry for the noise.

Indeed. There is no such script and there are no plans for such a script.

As mentioned in the other thread: if a bug change/comment was not made
by the janitor account it's not an automated change. A human may still
use boilerplate triage text on multiple bugs mind you :)

HS

Re: Closing NEEDSINFO bugs after 30 days

[Alexander Potashev]

пт, 16 нояб. 2018 г. в 16:35, Boudewijn Rempt :
>
> On vrijdag 16 november 2018 14:31:39 CET Alexander Potashev wrote:
>
> > You only considered to case when human sets NEEDSINFO. If NEEDSINFO is
> > set by a script, we may have the same problem, would you suggest
> > implementing the same behaviour?
>
> We don't have the script setting NEEDSINFO, do we? At least, I didn't see it
> in Harald's list of options.

Hopefully we don't. I noticed such change in some bug reports, however
all of them are attributed to Andrew himself, not the "bug janitor"
account. Sorry for the noise.

-- 
Alexander Potashev

Re: Closing NEEDSINFO bugs after 30 days

[Boudewijn Rempt]

On vrijdag 16 november 2018 14:31:39 CET Alexander Potashev wrote:
 
> You only considered to case when human sets NEEDSINFO. If NEEDSINFO is
> set by a script, we may have the same problem, would you suggest
> implementing the same behaviour?

We don't have the script setting NEEDSINFO, do we? At least, I didn't see it 
in Harald's list of options.

-- 
https://www.krita.org

signature.asc
Description: This is a digitally signed message part.

Re: Closing NEEDSINFO bugs after 30 days

[Alexander Potashev]

пт, 16 нояб. 2018 г. в 16:22, Harald Sitter :
>
> On Fri, Nov 16, 2018 at 2:16 PM Boudewijn Rempt  wrote:
> >
> > On vrijdag 16 november 2018 14:11:29 CET Harald Sitter wrote:
> >
> > > - human sets needsinfo
> > > - 15 days pass: bot posts reminder
> > > - reporter comments
> > > - N days pass: bug gets automatically dropped back to whatever the
> > > previous state was?
> >
> > Yes, that would be perfect! As far as I'm concerned, N can be 0 or 1.
>
> Cool. Should be easy to do.
>
> Any disagreements from the rest of the community?
>
> TLDR: if the original reporter comments on a needsinfo bug it gets
> automatically switched back to whatever the state before needsinfo was

Hi Harald,

You only considered to case when human sets NEEDSINFO. If NEEDSINFO is
set by a script, we may have the same problem, would you suggest
implementing the same behaviour?

-- 
Alexander Potashev

Re: Closing NEEDSINFO bugs after 30 days

[Harald Sitter]

On Fri, Nov 16, 2018 at 2:16 PM Boudewijn Rempt  wrote:
>
> On vrijdag 16 november 2018 14:11:29 CET Harald Sitter wrote:
>
> > - human sets needsinfo
> > - 15 days pass: bot posts reminder
> > - reporter comments
> > - N days pass: bug gets automatically dropped back to whatever the
> > previous state was?
>
> Yes, that would be perfect! As far as I'm concerned, N can be 0 or 1.

Cool. Should be easy to do.

Any disagreements from the rest of the community?

TLDR: if the original reporter comments on a needsinfo bug it gets
automatically switched back to whatever the state before needsinfo was

Re: Closing NEEDSINFO bugs after 30 days

[Boudewijn Rempt]

On vrijdag 16 november 2018 14:11:29 CET Harald Sitter wrote:

> - human sets needsinfo
> - 15 days pass: bot posts reminder
> - reporter comments
> - N days pass: bug gets automatically dropped back to whatever the
> previous state was?

Yes, that would be perfect! As far as I'm concerned, N can be 0 or 1.

-- 
https://www.krita.org

signature.asc
Description: This is a digitally signed message part.

Re: Policy on stale bugs (was Re: Closing NEEDSINFO bugs after 30 days)

[Andrew Crouthamel]

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.

In regards to Haralds script, it is fully functional now and appears to work 
very well.

 Original Message 
On Nov 16, 2018, 4:37 AM, Luigi Toscano wrote:

> Andrew Crouthamel ha scritto:
>> I've been spending a lot of time browsing, searching, and filtering our bugs
>> in Bugzilla. One of the areas I've found that could use improvement, are the
>> NEEDSINFO bugs. Often, bugs are placed into this status, either awaiting
>> additional information or backtraces, never to be updated again. We have
>> NEEDSINFO bugs dating back to 2009.
>
> Hi,
> the (semi)automated process which pings and then closes NEEDINFO bugs was
> implemented, but I've noticed another policy which was never discussed (as far
> as I know) here: bugs opened for a while
>
> I disagree with this policy, and I'm not alone (at least another maintainer
> asked for his product to be excluded):
> - not all projects distinguished between CONFIRMED and UNCONFIRMED (now
> REPORTED), so it's possible that a perfectly valid bug or request (especially
> requests) seems stale. You may say that it's easy to flip the status again.
> I'd say that it's a unneeded step.
> - at most the script could add a new comment asking for updates, but not
> immediately change the status out of the blue.
> - as mentioned, it was not discussed.
>
> Please disable it for now, or just enable it for projects who explicitly wants
> it for now.
>
> --
> Luigi

Re: Closing NEEDSINFO bugs after 30 days

[Harald Sitter]

(Pulling this back to the NEEDSINFO thread since it sounds unrelated
to what Luigi was writing about in the Policy on stale bugs thread)

On Fri, Nov 16, 2018 at 12:51 PM Boudewijn Rempt  wrote:
> I know it's well-meant, and it does help to get old bugs resolved -- but it
> really should use a script that checks whether the original reporter has added
> a comment since it was set to needinfo, and in that case just reopen it.
>
> I know that the script that was intended to do that didn't work, and I've
> tried to figure out whether I could fix it, but failed in that. But right now,
> the closing to WORKSFOME plays havoc with my bugzilla routine -- and worse, it
> makes me hesitate to put bugs in the NEEDINFO state.

So... the current behavior is:

- human sets needsinfo
- if no human responds within 15 days since last update the bot posts
a reminder (this can repeat ad infinitum if the status doesn't get
changed away from needsinfo but comments get posted)
- if no human responds within further 15 days the bot closes the bug
(which may also happen if information was provided by the status was
not changed in 30 days)

e.g.

- human set needsinfo
- 15 days pass: bot posts reminder
- reporter comments
- 15 days pass: bot posts reminder
- 15 days pass: bot auto-closes

If I understand your suggestion you'd like it to switch automatically
out of needsinfo upon comment from the original reporter?

e.g.

- human sets needsinfo
- 15 days pass: bot posts reminder
- reporter comments
- N days pass: bug gets automatically dropped back to whatever the
previous state was?

Re: Policy on stale bugs (was Re: Closing NEEDSINFO bugs after 30 days)

[Harald Sitter]

On Fri, Nov 16, 2018 at 10:37 AM Luigi Toscano  wrote:
> Please disable it for now, or just enable it for projects who explicitly wants
> it for now.

As mentioned on IRC: everyone please note that unless a change was
made by bug-jani...@kde.org it was not actually done automatically (or
not that I know of anyway).
To that end please please please do not confuse needsinfo reminders
and closures (which are automated) with changes the bug squad does (a
human doing it). Confusing the two makes it really hard for everyone
to know what we are talking about.

If the janitor does a change that you think is incorrect please poke
me with link as it's possibly a bug in the bot, or may need policy
adjustments.

HS

Re: Policy on stale bugs (was Re: Closing NEEDSINFO bugs after 30 days)

[Christoph Feck]

On 16.11.2018 12:50, Boudewijn Rempt wrote:

 -- and worse, it makes me hesitate to put bugs in the NEEDINFO state.


Worse. Bugs that never have been in NEEDSINFO seem to automatically get 
this state after some time of inactivity now.

Re: Policy on stale bugs (was Re: Closing NEEDSINFO bugs after 30 days)

[Boudewijn Rempt]

On vrijdag 16 november 2018 10:37:08 CET Luigi Toscano wrote:

> the (semi)automated process which pings and then closes NEEDINFO bugs was
> implemented, but I've noticed another policy which was never discussed (as
> far as I know) here: bugs opened for a while
> 
> I disagree with this policy, and I'm not alone (at least another maintainer
> asked for his product to be excluded):
> - not all projects distinguished between CONFIRMED and UNCONFIRMED (now
> REPORTED), so it's possible that a perfectly valid bug or request
> (especially requests) seems stale. You may say that it's easy to flip the
> status again. I'd say that it's a unneeded step.
> - at most the script could add a new comment asking for updates, but not
> immediately change the status out of the blue.
> - as mentioned, it was not discussed.
> 
> Please disable it for now, or just enable it for projects who explicitly
> wants it for now.

I know it's well-meant, and it does help to get old bugs resolved -- but it 
really should use a script that checks whether the original reporter has added 
a comment since it was set to needinfo, and in that case just reopen it.

I know that the script that was intended to do that didn't work, and I've 
tried to figure out whether I could fix it, but failed in that. But right now, 
the closing to WORKSFOME plays havoc with my bugzilla routine -- and worse, it 
makes me hesitate to put bugs in the NEEDINFO state.


-- 
https://www.krita.org

signature.asc
Description: This is a digitally signed message part.

Re: Policy on stale bugs (was Re: Closing NEEDSINFO bugs after 30 days)

[Luigi Toscano]

Luigi Toscano ha scritto:

Andrew Crouthamel ha scritto:
I've been spending a lot of time browsing, searching, and filtering our bugs 
in Bugzilla. One of the areas I've found that could use improvement, are the 
NEEDSINFO bugs. Often, bugs are placed into this status, either awaiting 
additional information or backtraces, never to be updated again. We have 
NEEDSINFO bugs dating back to 2009.


Hi,
the (semi)automated process which pings and then closes NEEDINFO bugs was 
implemented, but I've noticed another policy which was never discussed (as far 
as I know) here: bugs opened for a while

(sorry) ... are switched to NEEDINFO.



I disagree with this policy, and I'm not alone (at least another maintainer 
asked for his product to be excluded):
- not all projects distinguished between CONFIRMED and UNCONFIRMED (now 
REPORTED), so it's possible that a perfectly valid bug or request (especially 
requests) seems stale. You may say that it's easy to flip the status again. 
I'd say that it's a unneeded step.
- at most the script could add a new comment asking for updates, but not 
immediately change the status out of the blue.

- as mentioned, it was not discussed.

Please disable it for now, or just enable it for projects who explicitly wants 
it for now.



--
Luigi

Re: Policy on stale bugs (was Re: Closing NEEDSINFO bugs after 30 days)

[Jaroslaw Staniek]

On Fri, 16 Nov 2018 at 10:37, Luigi Toscano 
wrote:

> Andrew Crouthamel ha scritto:
> > I've been spending a lot of time browsing, searching, and filtering our
> bugs
> > in Bugzilla. One of the areas I've found that could use improvement, are
> the
> > NEEDSINFO bugs. Often, bugs are placed into this status, either awaiting
> > additional information or backtraces, never to be updated again. We have
> > NEEDSINFO bugs dating back to 2009.
>
> Hi,
> the (semi)automated process which pings and then closes NEEDINFO bugs was
> implemented, but I've noticed another policy which was never discussed (as
> far
> as I know) here: bugs opened for a while
>

Hi
As a heavy user of NEEDINFO  I am also not enthusiastic and asked by email
for exclusion but no reaction so far.

Bug reports that I work with can easily be 6 years old and this means
nothing in the development speed that I face. In a commercial environment
maybe it's different - so old reports are really invalid, but here now I
only get more work - I need to resort to notification emails one by one, it
will take months.
Also e.g. if a bug has 10% of missing "NEEDSINFO" and dozen of comments
with valid discussion and input, how can it be abandoned automatically
based on time since the original report?
I am not sure if we can assume it is of any help that valid bugs are set as
resolved by non-project persons (who have never had a contact with a
maintainer), without proper project knowledge.

At least the bugs are not CLOSED so it's possible to query them. But how
useful is to spend time on it?
Please at least do not close them. We have to deal with the consequences
with our users. Possibly facing decline of bug reports because they see
they are resolved without proper action.

I also think something else was not considered, what applies at least to
projects I maintain: people do use old software and do not upgrade
especially on Linux e.g. due to the misunderstood thing called LTS. Hence
they face with problems that are discussed in these old bug reports. The
fact that old software is unmaintained does not mean that the report,
convert into new reports or tasks for newer software versions, for the
docs, and so on. If we automatically set bugs as resolved I seen that as a
disservice for the project.


> I disagree with this policy, and I'm not alone (at least another
> maintainer
> asked for his product to be excluded):
> - not all projects distinguished between CONFIRMED and UNCONFIRMED (now
> REPORTED), so it's possible that a perfectly valid bug or request
> (especially
> requests) seems stale. You may say that it's easy to flip the status
> again.
> I'd say that it's a unneeded step.
> - at most the script could add a new comment asking for updates, but not
> immediately change the status out of the blue.
> - as mentioned, it was not discussed.
>
> Please disable it for now, or just enable it for projects who explicitly
> wants
> it for now.
>
> --
> Luigi
>
>
>
>

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - kde.org
KEXI:
: A visual database apps builder - kexi-project.org calligra.org/kexi
  twitter.com/kexi_project facebook.com/kexi.project t.me/kexi_project
Qt Certified Specialist:
: linkedin.com/in/jstaniek 

Policy on stale bugs (was Re: Closing NEEDSINFO bugs after 30 days)

[Luigi Toscano]

Andrew Crouthamel ha scritto:
I've been spending a lot of time browsing, searching, and filtering our bugs 
in Bugzilla. One of the areas I've found that could use improvement, are the 
NEEDSINFO bugs. Often, bugs are placed into this status, either awaiting 
additional information or backtraces, never to be updated again. We have 
NEEDSINFO bugs dating back to 2009.


Hi,
the (semi)automated process which pings and then closes NEEDINFO bugs was 
implemented, but I've noticed another policy which was never discussed (as far 
as I know) here: bugs opened for a while


I disagree with this policy, and I'm not alone (at least another maintainer 
asked for his product to be excluded):
- not all projects distinguished between CONFIRMED and UNCONFIRMED (now 
REPORTED), so it's possible that a perfectly valid bug or request (especially 
requests) seems stale. You may say that it's easy to flip the status again. 
I'd say that it's a unneeded step.
- at most the script could add a new comment asking for updates, but not 
immediately change the status out of the blue.

- as mentioned, it was not discussed.

Please disable it for now, or just enable it for projects who explicitly wants 
it for now.


--
Luigi

Re: Closing NEEDSINFO bugs after 30 days

[Thomas Baumgart]

Hi,

On Dienstag, 18. September 2018 22:17:08 CEST Nate Graham wrote:

> Thanks for taking the initiative on this, Andrew. I think everything you've 
> laid out makes sense, and I like those messages. +1.

+1. This is very much appreciated. More below ...

> 
>   On Tue, 18 Sep 2018 12:56:09 -0700 Andrew Crouthamel 
>  wrote  
>  > 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. 

Well, it has been said in another comment of this thread that the status 
will/can change automatically once a comment is added (hopefully the automated 
ones don't count). So that should not be a problem. On the other hand, even if 
the status would remain to be NEEDSINFO, I expect that the procedure starts all 
over again and another warning is issued after 15 days.

[...] proposed e-mail text removed

+1 for the proposals. They sound good to me.


-- 

Regards

Thomas Baumgart

https://www.signal.org/   Signal, the better WhatsApp
-
Did you hear about the guy who got his whole left side cut off?
He's all right now.
-



signature.asc
Description: This is a digitally signed message part.

Re: Closing NEEDSINFO bugs after 30 days

[Nate Graham]

  On Tue, 18 Sep 2018 13:23:19 -0700 Albert Astals Cid  
wrote  
 > El dilluns, 17 de setembre de 2018, a les 20:01:15 CEST, Andrew Crouthamel 
 > va escriure: 
 > Unless we can check if there has been no comment after the comment that 
 > changed the status to NEEDSINFO, it that's possible, seems good to me. 

Yeah, I agree, and I think Andrew's latest email covers this case.

Nate

Re: Closing NEEDSINFO bugs after 30 days

[Nate Graham]

  On Tue, 18 Sep 2018 13:23:19 -0700 Albert Astals Cid  
wrote  
 > El dilluns, 17 de setembre de 2018, a les 20:01:15 CEST, Andrew Crouthamel 
 > va escriure: 
 > Unless we can check if there has been no comment after the comment that 
 > changed the status to NEEDSINFO, it that's possible, seems good to me. 

Yeah, I agree, and I think Andrew's latest email covers this case.

Nate

Re: Closing NEEDSINFO bugs after 30 days

[Albert Astals Cid]

El dilluns, 17 de setembre de 2018, a les 20:01:15 CEST, Andrew Crouthamel va 
escriure:
> I've been spending a lot of time browsing, searching, and filtering our bugs 
> in Bugzilla. One of the areas I've found that could use improvement, are the 
> NEEDSINFO bugs. Often, bugs are placed into this status, either awaiting 
> additional information or backtraces, never to be updated again. We have 
> NEEDSINFO bugs dating back to 2009.
> 
> I believe it would be best, if these unactionable bugs are closed after 30 
> days of inactivity. This would become a KDE Bugzilla policy going forward, 
> and one we could even implement as a bot if possible in the future. For 
> example, the Chromium project Sherriffbot does this today. But for now, I'd 
> like it to become a manual Bugsquad action item to check. It cannot be 
> expected to leave a bug open indefinitely, if the reporter cannot be bothered 
> to provide the additional requested information. It's unfair to our 
> developers to be unsure when to close an abandoned bug, and contributes to 
> lessening the signal-to-noise ratio of our issues in Bugzilla.
> 
> This is already a policy at many other projects such as The Document 
> Foundation, Chromium, and Fedora. Additionally, several of our developers 
> within KDE are already doing this.
> 
> Thoughts?

In my expirience people routinely forget to change the status back when they 
provide the information so I don't think it's a good idea.

Unless we can check if there has been no comment after the comment that changed 
the status to NEEDSINFO, it that's possible, seems good to me.

Cheers,
  Albert

> 
> Andrew Crouthamel

Re: Closing NEEDSINFO bugs after 30 days

[Nate Graham]

Thanks for taking the initiative on this, Andrew. I think everything you've 
laid out makes sense, and I like those messages. +1.

Nate


  On Tue, 18 Sep 2018 12:56:09 -0700 Andrew Crouthamel 
 wrote  
 > 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  
 > wrote: 
 >  
 > > On Mon, Sep 17, 2018 at 8:25 PM Nate Graham n...@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, 
 > > 

Re: Closing NEEDSINFO bugs after 30 days

[Andrew Crouthamel]

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  wrote:

> On Mon, Sep 17, 2018 at 8:25 PM Nate Graham n...@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

Re: Closing NEEDSINFO bugs after 30 days

[Ilmari Lauhakangas]

Ilmari Lauhakangas kirjoitti 18.9.2018 klo 14.13:

Harald Sitter kirjoitti 18.9.2018 klo 13.40:

Anywayyy... I can throw together some automation so long as someone
tells me what exactly the process should be :P


Wait a bit as I have just been in contact with Andrew about re-using the 
automation LibreOffice already has for this. I need to ask our QA 
engineer about some details.


Ilmari


It turns out this task was not automated. It does have some Python 
scripting to figure out reports in need of closing: 
https://wiki.documentfoundation.org/QA/Bugzilla/Gardening#Cleaning-out_NEEDINFO:_30_days_later


Pinging reports untouched for a year is automated, though. See the 
bugzillaAutomation, bugzillaChecker and common scripts in 
https://gerrit.libreoffice.org/gitweb?p=dev-tools.git;a=tree;f=qa and 
look for "untouched". I hope it helps.


Ilmari

Re: Closing NEEDSINFO bugs after 30 days

[Luigi Toscano]

Harald Sitter ha scritto:

On Tue, Sep 18, 2018 at 12:59 PM Boudewijn Rempt  wrote:


Would it also be possible to automatically remove the needinfo status if the
reporter adds a comment after it's set to needinfo?


Yes.




I know that this proposal was rejected in the past, but if the needinfo flag 
is used instead of a separate NEEDINFO status, the flag is removed 
automatically when the person set in the needinfo flag answers:


https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Needinfo

--
Luigi

Re: Closing NEEDSINFO bugs after 30 days

[Harald Sitter]

On Tue, Sep 18, 2018 at 12:59 PM Boudewijn Rempt  wrote:
>
> Would it also be possible to automatically remove the needinfo status if the
> reporter adds a comment after it's set to needinfo?

Yes.

Re: Closing NEEDSINFO bugs after 30 days

[Ilmari Lauhakangas]

Harald Sitter kirjoitti 18.9.2018 klo 13.40:

Anywayyy... I can throw together some automation so long as someone
tells me what exactly the process should be :P


Wait a bit as I have just been in contact with Andrew about re-using the 
automation LibreOffice already has for this. I need to ask our QA 
engineer about some details.


Ilmari

Re: Closing NEEDSINFO bugs after 30 days

[David Edmundson]

> One of the areas I've found that could use improvement

IMHO it's really not a huge problem*.

If a reporter doesn't answer back, then they clearly don't care.
If its marked as needsinfo it's not in my lists, it doesn't affect me as a
dev in the slightest. They're filtered out by default, I have to go out of
my way to include needsinfo ones.

I have no objections to the proposal, but in terms of what I think will
have best effort-reward, dead products and dead bugs aren't a problem, the
active ones are where resources will pay best.

David

*Making sure to reopen bugs after the commenter replies is a different
story where we do sometimes miss useful things.

Re: Closing NEEDSINFO bugs after 30 days

[Boudewijn Rempt]

Would it also be possible to automatically remove the needinfo status if the 
reporter adds a comment after it's set to needinfo?

On dinsdag 18 september 2018 12:40:09 CEST Harald Sitter wrote:
> On Mon, Sep 17, 2018 at 8:25 PM Nate Graham  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


-- 
https://www.krita.org

signature.asc
Description: This is a digitally signed message part.

Re: Closing NEEDSINFO bugs after 30 days

[Harald Sitter]

On Mon, Sep 17, 2018 at 8:25 PM Nate Graham  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

Re: Closing NEEDSINFO bugs after 30 days

[Andrew Crouthamel]

No problem, I can make that part of the procedure until we figure out an 
automated method. After two weeks, send out a reminder, then two weeks later 
close if no activity.

Andrew Crouthamel

‐‐‐ Original Message ‐‐‐
On Monday, September 17, 2018 3:10 PM, Michael Reeves  
wrote:

> I would definitely have a warning message posted when this is about to 
> happen. I have no objection as.long is clear what information is needed. I 
> would be inclined to do this manually even if the system doesn't.
>
> On Mon, Sep 17, 2018, 2:39 PM Scott Harvey  wrote:
>
>> Can Bugzilla be configured to add boilerplate to the email that goes out
>> with a NEEDSINFO that reads "This bug report will be closed after 30
>> days unless blah blah blah"?
>
>>

Re: Closing NEEDSINFO bugs after 30 days

[Michael Reeves]

I would definitely have a warning message posted when this is about to
happen. I have no objection as.long is clear what information is needed. I
would be inclined to do this manually even if the system doesn't.

On Mon, Sep 17, 2018, 2:39 PM Scott Harvey  wrote:

> Can Bugzilla be configured to add boilerplate to the email that goes out
> with a NEEDSINFO that reads "This bug report will be closed after 30
> days unless blah blah blah"?
>
>
>

Re: Closing NEEDSINFO bugs after 30 days

[Andrew Crouthamel]

At worst case, we could edit bug/create/user-message.html.tmpl which is the 
text that shows at the top of the bug creation page.


Andrew Crouthamel

‐‐‐ Original Message ‐‐‐
On Monday, September 17, 2018 2:38 PM, Scott Harvey  wrote:

> Can Bugzilla be configured to add boilerplate to the email that goes out
> with a NEEDSINFO that reads "This bug report will be closed after 30
> days unless blah blah blah"?

Re: Closing NEEDSINFO bugs after 30 days

[Scott Harvey]

Can Bugzilla be configured to add boilerplate to the email that goes out 
with a NEEDSINFO that reads "This bug report will be closed after 30 
days unless blah blah blah"?

Re: Closing NEEDSINFO bugs after 30 days

[Nate Graham]

  On Mon, 17 Sep 2018 11:19:59 -0700 Adriaan de Groot  wrote 
 
 > This depends on the state change *to* NEEDSINFO having a comment or other  
 > message that is sufficiently directive: "we need  in order to 
 > do  
 > anything with this bug". Or, in general, we'd need to keep in mind that that 
 >  
 > state change needs to have a clear and explicit question towards the 
 > reporter. 

Yes, this is what we do. In fact, not only is it documented at 
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging#Ask_for_any_missing_information,
 but Bugzilla actually makes it mandatory: you're not allowed to change a bug 
to NEEDSINFO without a comment.

+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.

Nate

Re: Closing NEEDSINFO bugs after 30 days

[Adriaan de Groot]

On Monday, 17 September 2018 20:01:15 CEST Andrew Crouthamel wrote:
> This is already a policy at many other projects such as The Document
> Foundation, Chromium, and Fedora. Additionally, several of our developers
> within KDE are already doing this.

This depends on the state change *to* NEEDSINFO having a comment or other 
message that is sufficiently directive: "we need  in order to do 
anything with this bug". Or, in general, we'd need to keep in mind that that 
state change needs to have a clear and explicit question towards the reporter.

In my own projects I do tend to to an intent-to-close pass over bugs, adding a 
comment "this will be closed in a week unless you speak up and provide the 
requested information."

[ade] (generally in favor)


signature.asc
Description: This is a digitally signed message part.

Closing NEEDSINFO bugs after 30 days

[Andrew Crouthamel]

I've been spending a lot of time browsing, searching, and filtering our bugs in 
Bugzilla. One of the areas I've found that could use improvement, are the 
NEEDSINFO bugs. Often, bugs are placed into this status, either awaiting 
additional information or backtraces, never to be updated again. We have 
NEEDSINFO bugs dating back to 2009.

I believe it would be best, if these unactionable bugs are closed after 30 days 
of inactivity. This would become a KDE Bugzilla policy going forward, and one 
we could even implement as a bot if possible in the future. For example, the 
Chromium project Sherriffbot does this today. But for now, I'd like it to 
become a manual Bugsquad action item to check. It cannot be expected to leave a 
bug open indefinitely, if the reporter cannot be bothered to provide the 
additional requested information. It's unfair to our developers to be unsure 
when to close an abandoned bug, and contributes to lessening the 
signal-to-noise ratio of our issues in Bugzilla.

This is already a policy at many other projects such as The Document 
Foundation, Chromium, and Fedora. Additionally, several of our developers 
within KDE are already doing this.

Thoughts?

Andrew Crouthamel