Bug P3
Status Update
No update yet.
Comments
ma...@gmail.com
We may consider to use a stale bug bot similar to the one available on github [1].
[2] is a study on how that bot is used.
[1]https://github.com/apps/stale
[2]https://www.researchgate.net/publication/331718820_Should_I_Stale_or_Should_I_Close_An_Analysis_of_a_Bot_that_Closes_Abandoned_Issues_and_Pull_Requests
[2] is a study on how that bot is used.
[1]
[2]
ma...@gmail.com
Also mentioned recently was (for this record):
1. Could we auto-close issue with state AwaitingInformation if no update happened with X days after the status was set?
2. We should review the states that an issue can have and see if they still make sense.
1. Could we auto-close issue with state AwaitingInformation if no update happened with X days after the status was set?
2. We should review the states that an issue can have and see if they still make sense.
ma...@gmail.com
Relates to [3] https://crbug.com/gerrit/11170 but may progress in parallel.
os...@gmx.de
first let me point out that currently an unprivileged reporter can *not* re-open their issues. there are good reasons for that, but without an (actually lived) process that _guarantees_ that comments/objections on closed bugs are actually followed up to, you have a setup that is extremely disrespectful towards the reporters. and that's been my experience with this bug tracker throughout - comments on closed issues apparently go straight to /dev/null.
if you declare bug bankruptcy, make sure to exclude feature requests.
if you implement auto-closing AwaitingInformation, you need to consider in whose court the ball is. if it's not the reporter, *don't* close.
if you declare bug bankruptcy, make sure to exclude feature requests.
if you implement auto-closing AwaitingInformation, you need to consider in whose court the ball is. if it's not the reporter, *don't* close.
ek...@google.com
> first let me point out that currently an unprivileged reporter can *not* re-open their issues.
Thanks for pointing this out. I was not aware of this.
> if you declare bug bankruptcy, make sure to exclude feature requests.
yeah, likely features should be excluded
> if you implement auto-closing AwaitingInformation, you need to consider in whose court the ball is. if it's not the reporter, *don't* close.
+1
Thanks for pointing this out. I was not aware of this.
> if you declare bug bankruptcy, make sure to exclude feature requests.
yeah, likely features should be excluded
> if you implement auto-closing AwaitingInformation, you need to consider in whose court the ball is. if it's not the reporter, *don't* close.
+1
ma...@gmail.com
Governance meetup updates on this Issue:
- PolyGerrit component is already triaged, daily or so.
- Backend component is partially triaged.
- Plugin and other components are yet to be potentially reworked.
- We are about to come up with a bug policy alongside cleaner components.
- More to come also as Gerrit plugins and core domains get further clarified.
[Monorail components: ESC]
- PolyGerrit component is already triaged, daily or so.
- Backend component is partially triaged.
- Plugin and other components are yet to be potentially reworked.
- We are about to come up with a bug policy alongside cleaner components.
- More to come also as Gerrit plugins and core domains get further clarified.
[Monorail components: ESC]
os...@gmx.de
have you specifically considered the case of issues which are being commented on after being closed? closed issues won't appear any more in any query which filters for untriaged tasks, so no triaging task force will catch them. *theoretically* this is a problem only for issues without an owner, but in practice there are also non-responsive (outdated) owners. what to do with the backlog of issues which have already slipped through the net?
br...@google.com
We talked about this issue in today's ESC meeting, because it has the ESC label on it.
We don't think that the number of open issues is a huge problem for Gerrit at the moment. It is more important to actively triage incoming issues.
So we don't think that as ESC we want to actively pursue this. Thus I am removing the ESC label.
Let me know if you need further input or disagree.
We don't think that the number of open issues is a huge problem for Gerrit at the moment. It is more important to actively triage incoming issues.
So we don't think that as ESC we want to actively pursue this. Thus I am removing the ESC label.
Let me know if you need further input or disagree.
br...@google.com
[Monorail components: -ESC]
os...@gmx.de
that may be your perspective, but as a past reporter i beg to differ.
also, some people actually do their homework and avoid filing duplicates, and instead vote or comment on the old issues - but you'll never know when you just ignore them (compounded by the fact that old issues often have stale assignees). this obviously affects feature & change requests more than bugs, as these are less likely to go stale.
if you want to insist on your "process", then make it _very_ explicit that you _want_ people to file duplicates - mozilla does it that way, counter to every other project whose policy i'm aware of. but that's most probably because they rightfully don't trust non-technical users to reliably recognize duplicates. also, they actually have a team that does nothing else than maintaining the bugtracker.
also, some people actually do their homework and avoid filing duplicates, and instead vote or comment on the old issues - but you'll never know when you just ignore them (compounded by the fact that old issues often have stale assignees). this obviously affects feature & change requests more than bugs, as these are less likely to go stale.
if you want to insist on your "process", then make it _very_ explicit that you _want_ people to file duplicates - mozilla does it that way, counter to every other project whose policy i'm aware of. but that's most probably because they rightfully don't trust non-technical users to reliably recognize duplicates. also, they actually have a team that does nothing else than maintaining the bugtracker.
ma...@gmail.com
We recently improved on some specific parts of backlog traging; [3] below.
[3]https://www.gerritcodereview.com/support.html#google
Given this and the difficulty of updating so many left-behind issues, this is closed for now.
If needed, older issues can always be revived by interested parties.
A potential follow-up though could be to add a new mandatory field, about the reported-against version (or release).
This is now an action for community managers to pursue.
This way, one could easily close no longer supported version-labeled issues (based on EOL).
Or, amend such issues so they get properly carried over to an upstream (still impacted) version.
Upon releasing a new version, the release manager would then have to seek after such downstream or base issues.
[3]
Given this and the difficulty of updating so many left-behind issues, this is closed for now.
If needed, older issues can always be revived by interested parties.
A potential follow-up though could be to add a new mandatory field, about the reported-against version (or release).
This is now an action for community managers to pursue.
This way, one could easily close no longer supported version-labeled issues (based on EOL).
Or, amend such issues so they get properly carried over to an upstream (still impacted) version.
Upon releasing a new version, the release manager would then have to seek after such downstream or base issues.
ek...@google.com
[Empty comment from Monorail migration]
is...@google.com
Edits were made to reflect the following in Monorail: auto-CCs.
Description
Due to the high number of legacy issues it's hard to spot the issues which are still relevant.
To address this problem we focused the last hackathon on bug-fixing and quite a lot of effort was spend on closing old issues, but the progress was not as good as we had hoped.
This issue is about reducing the number of open lagacy issues to a sane level and to ensure that the remaining open issues are reproducible and well described, so that they can be picked up easily.
One idea that was discussed is to declare bug-bankruptcy and close all open issues which are older than 6 months. If this closes bugs which are still relevant, they may be reopend by the reporter.
This issue is about persuing the idea of declaring bug-bankruptcy or finding other ideas to reduce the number of legacy issues.
[1]