Project Github Issues cleansup

[adw]

Can you explain what you mean by that, @nokke?

[nokke]

Autoclose: not necessarily actually automated, but set rules for closing old tickets that mean you don’t have to think hard about individual tickets, e.g. “we close tickets with no activity for a year that don’t have a clear statement about the value it would bring”.

@alimirjamali

Clearing Github from invalid or outdated issues is value to users IMHO

I agree, and it can justify closing tickets without engagement (sensitively and fairly, but that’s its own topic).

Volunteer time: what you get from whoever turns up to look into the tickets. If volunteers feel you’re making good use of it, you’re likely to get more of it in the future, and vice versa. In this context, random selection has some basic benefits, but adding filters to it can be a cheap way of making better use of this time.

[qubist]

Nice initiative.

It probably deserves its own forum section.

[alimirjamali]

@nokke

Autoclose: not necessarily actually automated, but set rules for closing old tickets that mean you don’t have to think hard about individual tickets, e.g. “we close tickets with no activity for a year that don’t have a clear statement about the value it would bring”.

@nokke

You might be interested in this specific issue and the related discussions:

Github Issue #7270 - qubes-issues bot for warning and closing stale issues

Opened on Feb 14, 2022 by adw.

Many valid arguments against and in favour of using a bot for closing issues. With notes from Qubes OS project leader, core team members and sister project (Whonix) leader.

[nokke]

Yes, that’s good and it looks like there’s actually a consensus there.

I think people leap to automation because otherwise individuals get attacked for carrying out the rules, but agreeing the rules is the important bit.

I don’t think it’s ideal that tickets have to be “closed” rather than labeled, it’s just something that the GH user experience (and every other ticketing system, to be fair) pushes us into - things like counts of open tickets and default search options are what makes it important they’re closed.

My point here is not to push that judgement onto individual community members or let them spend effort on tickets that shouldn’t be open.

GH web doesn’t seem to have options for filtering issues by age / last activity, but I’d guess there must be a straightforward API to do this and find, to use an example from the ticket, how many issues haven’t been touched in a year. Not so easy to automate whether the value field makes sense, but that doesn’t mean there can’t be a policy for manual closing.

[renehoj]

@nokke

GH web doesn’t seem to have options for filtering issues by age / last activity, but I’d guess there must be a straightforward API to do this and find, to use an example from the ticket, how many issues haven’t been touched in a year.

You can use a filter like this:
created:>2024-01-01 comments:0 is:open

edit:
this might be closer to what you are looking for
is:issue is:open updated:<2024-01-01

[nokke]

Perfect.

There seems to have been a mass update on 2023-08-13, which was the last update for over half of the open issues.

[nokke]

On a related note, what about merging/closing old pull requests (example)?

[adw]

@nokke

Autoclose: not necessarily actually automated, but set rules for closing old tickets that mean you don’t have to think hard about individual tickets, e.g. “we close tickets with no activity for a year that don’t have a clear statement about the value it would bring”.

Ah, I see. Yes, historically we’ve already been doing that by closing issues that pertain only to EOL Qubes releases after one year with no significant activity on that issue.

The reason for my confusion about your statement is that @alimirjamali does not have any say over when issues get closed. He’s just a (saintly) volunteer who is offering his time and expertise to help the project. Conversely, the project doesn’t have any say over how volunteers like @alimirjamali use their time.

In other words, there is no one in a position to decide to make this happen:

@nokke

For this, you may be better off with a more ruthless autoclose than using volunteer time in many cases.

However, it doesn’t sound like that’s a problem, since both sides are already doing well of their own accord.

@nokke

I agree, and it can justify closing tickets without engagement (sensitively and fairly, but that’s its own topic).

We already do this with resolutions, IMHO.

@nokke

I don’t think it’s ideal that tickets have to be “closed” rather than labeled, it’s just something that the GH user experience (and every other ticketing system, to be fair) pushes us into - things like counts of open tickets and default search options are what makes it important they’re closed.

From https://www.qubes-os.org/doc/issue-tracking/#understanding-open-and-closed-issues:

Every issue is always in one of two states: open or closed, with open being the default. The open and closed states mean that, according to our available information at present, the issue in question either is or is not (respectively) actionable for the Qubes team. The open and closed states do not mean anything more than this, and it’s important not to read anything else into them. It’s also important to understand that closing an issue is, in effect, nothing more than changing a virtual tag on an issue. Closing an issue is never “final” in any sense, and it does not affect the issue itself in any other way. Issues can be opened and closed instantly with a single button press an unlimited number of times at no cost. In fact, since the open and closed states reflect our available information at present, one should expect these states to change back and forth as new information becomes available. Closed issues are fully searchable, just like open issues, and we explicitly instruct all users of the issue tracker to search both open and closed issues, which GitHub makes easy.

There’s some kind of widespread cognitive bias whereby people think closing an issue means something more than it actually does, and this causes them to dislike closing issues for reasons that aren’t reflected by reality.

@nokke

My point here is not to push that judgement onto individual community members or let them spend effort on tickets that shouldn’t be open.

I don’t think that’s currently happening.

@nokke

but that doesn’t mean there can’t be a policy for manual closing.

As mentioned above, there already is, and it’s already been continuously implemented for years.

The vast majority of open issues are still open for one of two reasons:

1. They’re enhancement requests that haven’t been implemented or declined yet.
2. They’re bug reports that haven’t been diagnosed yet.

Auto-closure doesn’t really make sense in either case. Human analysis and judgment are required, and those are limited resources.

@nokke

On a related note, what about merging/closing old pull requests (example )?

That’s up to the documentation and website maintainer (@unman), but in general, it doesn’t make sense to close such PRs just because they’re old. For example, the current oldest one on that list is still being worked on, but it’s not ready to be merged yet.

[nokke]

@adw

There’s some kind of widespread cognitive bias whereby people think closing an issue means something more than it actually does, and this causes them to dislike closing issues for reasons that aren’t reflected by reality.

@adw

The open and closed states mean that, according to our available information at present, the issue in question either is or is not (respectively) actionable for the Qubes team.

@adw

Auto-closure doesn’t really make sense in either case. Human analysis and judgment are required, and those are limited resources.

Thanks for the details. Auto-closing more or less aggressively is a more complex tradeoff, and doesn’t need to make the same decisions as the process here. Though it’s closely related, it’ll be easier if I just avoid talking about closing and auto-closing.

If we’re seeing some unreviewed tickets in random sampling that don’t look worthwhile, then there may be an easy opportunity to present a richer set of tickets to volunteers, by filtering some out with minimal case-by-case judgement. When I looked at a small sample of tickets, I saw some where the “what’s the value?” field is empty or vague (and it’s not obvious from the rest of the ticket) - it’s not uncommon. Based on that, the chances are this sort of filter would make a difference, and that’s good particularly when there are lots of tickets and limited capacity. That’s why I’m suggesting it as a next iteration here.

@alimirjamali

Clearing Github from invalid or outdated issues is value to users

It is, but clearing invalid issues requires the experience to assess them, so I wouldn’t expect most users to make the decision for most tickets. So without a more basic filter we’d either end up with volunteers doing irrelevant work, or lots of requests to experienced contributors to review whether tickets are valid. I think we could do without either.

We’ve already hit an edge case, where a ticket with really unclear value (not the ticket’s fault - the RFP itself is vague on why it’s valuable) was successfully picked up for someone’s first contribution, and that’s something we don’t want to get in the way of. I don’t think it makes a good argument for not filtering, though, not with the volume we have. There’s already a “good first issue” label that’s not widely used atm (4 open issues) and maybe could be, though I’m not sure how we could make that happen.

[alimirjamali]

@nokke

It is, but clearing invalid issues requires the experience to assess them, so I wouldn’t expect most users to make the decision for most tickets. So without a more basic filter we’d either end up with volunteers doing irrelevant work, or lots of requests to experienced contributors to review whether tickets are valid. I think we could do without either.

The current situation is a project management decision. Usually if anyone/any group has problems with management aspects of a FOSS projects, there are the following choices:

1. Fork the project with their rules.
2. Follow project rules even if they disagree.
3. Forget the project.

I am personally OK with the current rules and I am trying to play within the rules. Maybe I am a volunteer that is doing irrelevant work. But I am doing it in my free time. And I am not forcing anyone else to follow me. If I am asked by the project management to change my current path or stop what am I doing, I will do it. Otherwise I am not going to discuss it further as I am not a decision making person in this specific case.

[nokke]

@alimirjamali

The current situation is a project management decision.

It doesn’t seem to involve project management or centralized policy. You’ve been given feedback on possible practical implications of what you’re doing and a suggestion for improving it. That is all. That discussion might involve things you’re not interested in or don’t want to take responsibility for, and that’s up to you.

[adw]

@nokke

There’s already a “good first issue” label that’s not widely used atm (4 open issues ) and maybe could be, though I’m not sure how we could make that happen.

The problem is that it also requires experience and judgment to decide which issues should get that label. However, the upside is that having the label on only a small number of issues makes the list much less overwhelming. I mean, if there are only four of them, and they’re still not getting done (or only getting done very slowly, at a rate of one per year on average, for example), then the problem is probably a lack of new contributors rather than the label not being applied enough.

[nokke]

I think people need a larger selection of “good first issue” tickets, because they still need to match the ticket to their specific experience (and interest) - the same reason as why a large list could be overwhelming. Since someone stepped up quickly when one such issue was made “front of mind” for the whole community, it might just be a case of making people more aware that the label exists and is used (if it actually was).

@adw

The problem is that it also requires experience and judgment to decide which issues should get that label.

Then probably the only current opportunities to get this happening consistently (if it’s not already - I’m assuming there would be more tickets with this label if it was) would be the initial review of new tickets and whatever regular reviews there are.

[parulin]

@nokke

We’ve already hit an edge case, where a ticket with really unclear value (not the ticket’s fault - the RFP itself is vague on why it’s valuable) was successfully picked up for someone’s first contribution, and that’s something we don’t want to get in the way of.

I don’t understand why? The fact that the value of this issue didn’t seem important was a good way to get me into it. The only downside I see is that someone more skilled (unman ?) will have to waste some time reviewing it.

[nokke]

Yes exactly, this is a good thing and we don’t want to get in the way of it.

[alimirjamali]

Ok. We are now below the 2000 open Github Issues psychological barrier. Many of the closed issues have received actual fixes and improvements. Although small improvements, but useful in many cases. Thanks everyone who helped to achieve it. There are even more fixes in the pipleline which are currently under review.

@adw If any of the core team developers feels that we are more of a nuisance in any area causing more harm than help, please do not hesitate to inform us. So we could try to focus on other areas.

[kenosen]

Should we open an issue to see if we’ve been an issue?

[adw]

@alimirjamali

@adw If any of the core team developers feels that we are more of a nuisance in any area causing more harm than help, please do not hesitate to inform us. So we could try to focus on other areas.

No, I’m quite sure they feel the opposite: That you all are wonderful and that your contributions are immensely helpful and very welcome!