Why not close tickets more aggressivley?

[marcelstoer]

I regularly come across tickets that are clearly obsolete, duplicates, outdated or already fixed. Whenever I do, I leave a comment, suggesting they be closed (e.g. #4004). Unless the author closes them, they usually stay open.

I wonder if it's a conscious decision by the maintenance team to rely solely on ticket authors to close them in such situations. Are you intentionally not relying on ticket bots to help you clean up the issue list, or is that because the issue has never come up before?

[jeremylong]

It is not a conscious decision - more limited time and resources. If I am working on ODC when I see one of these comments (which are helpful! thank you!) I will close them.

I recently re-enabled the lock action to prevent people from posting on old closed issues. However, using a bot to close old issues, at least for this project, hasn't felt right to me. Don't get me wrong, I'm all for it - but many of the old tickets might still be valid. However, no one has had time or energy to work on them (there are number of npm related issues).

I do think we could come up with some rules:

• questions with no activity in 30 days, close
• enhancements more than 2 years old with no activity, close
• bugs more than 3 years old close

I know the 2-3 years are a long time span and after looking at the results we might consider going shorter. @aikebah @nhumblot @chadlwilson thoughts on this? I agree with @marcelstoer we likely should do something more automated.

[chadlwilson]

I do agree with the general sentiment of @marcelstoer - even when I am poking around trying to do some triage I tend to give up after a few instances of coming back to issues I have seen before, or are wontfixes etc.

While some automation might help, I would have some of the same concerns as Jeremy on just blatantly closing stuff due to being old. To do that fairly tends to require enough time to reopen issues and mark them as "not stale" etc, which can meet some of the same time/effort bottlenecks on triage as the original problem. I suspect the major bottleneck is perhaps

• only @jeremylong and maybe 1-2 others actually having ability to fully triage/close/label issues?
• lack of clear guidelines/understanding about how we want to do triage so people are acting consistently (e.g bias towards close unless OP engages, bias towards open and wait for bot to close if stale)

Personally I feel there is a lot of cruft left open here when waiting for an OP who never responds (given the lack of bot automation to come back and clean up), and the project is perhaps a bit lenient here rather than "probably not an issue, try this, get back to us and will re-open if it doesn't fix the issue".

There was an issue I commented on a while ago (which I can't find now) which was an example of this where, @aikebah seemed to indicate he managed issues with filter combinations rather than just closing certain FP Report issues for whatever reason.

A few ideas

• One possibility might be to extend the set of triagers here, while providing some guidance about how Jeremey would like issues to be triaged to the folks he is comfortable extending that too. (maybe that exists?)
• Consider migrating questions (109 of 500 open issues) away to Discussions instead? Not sure how people feel about this, but personally I don't like mixing such things or navigating through sets of label filters to exclude them. In my opinion, issues are largely for maintainers, discussions/questions should be for the maintainers AND the community. Anecdotally a number of the questions here seem to be people being a bit lazy and asking for 1-on-1 support rather than googling/figuring things out. Maybe better to move that more clearly to a forum mechanism?
• another middle-ground for 'part' of the problem might be to extend the bot automation for "FP Report" to allow the permissioned folks to interact with the bot to label and/or close FP Report issues (100 of 500 open issues) - rather than extending broader permissions to close/label/triage issues to folks. Right now we can merge auto-suggested fixes, but not close ones we have investigated and rejected as needing to be fixed in upstream data. I think @aikebah might have some of these permissions though, given he can label issues like [FP]: org.eclipse.microprofile.config.microprofile-config-api for CVE-2022-45129 #6885

[marcelstoer]

Thank you for the very thoughtful feedback. I sympathize with a lot of the points you both raised. It's not an easy topic and I've had such discussions many times, both in the context of OSS projects and at work.

IMO the main goal should be to trim the issue list to a more manageable size and to increase focus. Personally, I am usually discouraged to create an issue for a project whose issue list already is considerably large.

Personally I feel there is a lot of cruft left open here when waiting for an OP who never responds

For projects I'm responsible for I usually take the position of "If they don't care, why should I?" when OPs don't respond anymore. A bot that adds a stale flag and leaves a comment to that effect giving OPs a grace period of ~2 weeks helps tremendously to get rid of those sorts of issues.

Consider migrating questions (109 of 500 open issues) away to Discussions instead?

👍

OT: I feel these could be closed #1742, #5973, #6432, #6758

[aikebah]

@jeremylong I'd be all up for automated closures on inactive tickets.

On my side it's also mostly a lack of time to spend on this project that leaves various older tickets open. When I have very limited time to spend I typically start top-down working my way through newly emerged FPs to get them handled where possible. When I have a bit more time to spend my first priority lies in fixing bugs on the codebase. Closing old ones is lowest on my list of priorities which indeed results in the observed state of long-standing open tickets.

On the 'open in won't fix' FP reports as they are a valid CPE attribution and only surface a mismatch between user's expectation and ODC design choices (most won't fix/NVD tickets), vulnerability source policies (OSSIndex has stricter rules on when they consider a vulnerability fixed) or sometimes just a lagging behind in acknowledging fixes in the datasources used:
Those I typically tend to keep open for a while, because otherwise typically we see the same ticket re-appear in no-time by someone else that runs into the same and opens a new ticket, not spotting the already closed one. Every now and then I try to spend some time to cycle through those and close them down if they're unmodified for at least 2 months.

[jeremylong]

@chadlwilson @marcelstoer - I'm all for having others with additional rights to help with the project. The only issue is that we would have to move the repo to https://github.com/dependency-check in order to have more than contributor access. I've been hesitant to do this in the past because all of the links and documentation have been on my personal repo for so long. However, I think it is time. I'll open a new issue to announce/discuss the move.

[jeremylong]

See #7235

[ftiercelin]

a suggestion: automatically close tickets tagged with nvd, e.g. #7178

[nhumblot]

Hi 👋

Regarding a bot closing stale tickets automatically. I am personally not sure about it like @chadlwilson stated, some tickets are stale not because they are irrelevant, but because we do not have the time to contribute to it, or lack additional contributions.

But I see these bots often used in big OSS projects. It may work in these big projects as they have full-time contributors and maybe because it is less third-party dependent as dependency check. I think it would be great to setup some guidelines on ticket triaging for starters.

A bot could still be useful when we append a specific label, like "need for more information" or "unable to reproduce". If you would like to introduce one globally, I wouldn't see this as a big concern though.

Regarding the discussion labels, I always saw them as good opportunities to open a PR to improve the documentation, but I always preferred to focus on bug fixing first. Maybe should I reconsider this approach?

I didn't focus much time on dependency check lately, I am sorry for that. My work requires a lot of involvement already, doesn't support me in doing open-source, and I prefer to have some time to rest, away of software engineering. I could provide help in the triaging as it can involve shorter commitment time than fixing some difficult to reproduce bugs. I would appreciate any priority list to focus onto the project and help you folks! 🧸