Triage: closing Stale Issues and Pull requests

[jukzi]

To keep a maintainable list of Issues and PRs i would like to close Issues and even PRs where

• no active Contributor is showing interest within ~ 1 Months,

with link to https://github.com/eclipse-platform#community:
Closing as not-planned due to inactivity. Please see https://github.com/eclipse-platform#community
I suggest that Eclipse® IDE Working Group or Individuals who would like to get paid for fixing Issues could leave a message there how to get involved if wanted.
The rule implies that Issues created by active Contributors should not be closed without request to allow contributors to queue up work for later.
The period is rather short to give the creator a timely feedback and reflects the current reality that active contributors typically react within a week or never.
It does not hinder anybody to reopen.
With "active Contributor" i mean both committers and non-committers who are actively contributing to Eclipse IDE.
A list of closed issues as not planned can still be shown with a filtered search like:
https://github.com/issues?q=is%3Aclosed+reason%3A%22not+planned%22+user%3Aeclipse-platform

WDYT?

[mickaelistria]

+1 for this, and there were already several attempts and discussions about it, and while it helped reducing the backlog and keeping focus, it's worth mentioning that auto-closing also irritated some reporters (contributors) who made angry comments on the tracker.
However, keeping everyone happy by keeping false hope is IMO not much nicer on the long run than being honest and clearly set expectations.

1 month is IMO way too short. Even the most active and available contributors sometimes get silent on an issue for a month because some other work took higher priority or just took some time-off. IMO somewhere between 3 to 6 months is more correct. I don't think "the current reality that active contributors typically react within a week or never" is a reality, but more your perception. Some data would be necessary to confirm this or not.

I also don't think we should distinguish casts of contributors here. A reporter is an active contributor too, and sometimes there are reported that are more active than some committers. So it's simpler and more fair to just set the same warning and the same rule for every issue, independently of who reported it or who took action.

[laeubi]

As mentioned on earlier discussions, closing issues to get a "clean backlog" is one of the worst things one can do for an open source community.

Just because no one is fixing things yet, do not mean they are not worth it, if one likes to "plan" things, github offers projects (even though I doubt there is much interest in "planing" time):
https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects

If one wants to mark an issue (independent on the "level" of the reporter) there is the help wanted label. "Not planed" is a more polite way for saying "won't fix" and not a collection of things one might want to do.

[iloveeclipse]

As mentioned on earlier discussions, closing issues to get a "clean backlog" is one of the worst things one can do for an open source community.

Fully agree with that.

What is the motivation to have "clean backlog"? "Keeping focus"? On what? On issues that were entered recently? So "recent" issues are worth to fix but "old" not? How does it help to the project?

• If the "focus" is needed - why not just pick the oldest or most "severe" issue to work on?
• If it is not clear how "severe" an issue is, why not quickly evaluate severity of the issues before starting the work, based on common sense what is important and what not, and add appropriate label to triaged issues?
• if the issue is not reproducible, why not ask for steps to reproduce?
• If there are doubts about "is this still relevant" why not ask reporter instead of closing the bug?
• and now if the reporter doesn't respond and the issue can't be reproduced it can be closed.

"Not planed" is a more polite way for saying "won't fix" and not a collection of things one might want to do.

Also fully agree with that.

In my opinion, if one cares about clean backlog, the solution is to methodically go over issues reported and process them one by one with the help of the points above, plus monitor incoming issues and process them in same way.

Summary:

• Closing bugs just because they are old doesn't help anyone, so clear NO here.
• I'm OK for closing bugs that can't be reproduced or unclear and reporter doesn't respond after asking for clarification.

[akurtakov]

There are downsides of each way:

• auto closing - valid issues will be closed
• not auto closing - fixed, duplicated or no longer relevant issues will stay open

Unfortunately it's a trade off to be taken by each side. Issues after some time have passed are most likely to be irrelevant than recently open ones. Automation that pokes contributors to look into issues/PRs after some period (even without closing) is helpful despite the "noise".
Whatever is decided, it will have downsides that can be fixed only by more people involved in the project.

[HeikoKlare]

I agree that auto-closing stale issues as an approach to clean the backlog may not be the preferable solution.
On the other hand, probably no one denies that an unmaintained list of issues is bad for reporters of issues as well as for those willing to fix them. At least for someone who is willing to contribute and has not worked on the project for months or years, it is quite hard to understand which issues may be relevant/severe/worth to fix first.

From my point of view, it would be best to tackle this problem in the beginning, i.e., whenever an issue is created. It should then be identified whether the issue is valid and how relevant and severe it is. A valid, severe issue should probably not be closed just because no one addresses it. But if the issue is specific for a single adopter, the conditions for keeping the issue open might be different.

Just some ideas on what could be done on issue creation to improve the backlog state:

• Severity assignment: The issue can be assigned a severity (from an overall project's perspective). That may not be the severity for the reporter but gives an indicator whether it is relevant for the overall project to address the issue.
• Reproduction description (for bugs): There has to be a precise description how to reproduce the issue. There is already an issue template in the SWT repo which asks you to provide a description for reproduction. It would be even better to have a reproducing test case that can be used for regression testing after addressing the issue. In case the issue is primarily relevant for certain adopters, an according test case may be requested from them. In case the issue is severe for the overall project, it might be worth that some committer transforms the reproduction description into a test case. It would also be an option to have a kind of "issue test class" containing these reproduction tests of reported issues, which can be executed once in a while to see whether issues have already been fixed or still exist.
• Complexity assignment: It could also be interesting to assign an estimation of the complexity to address an issue. Maybe this is not that relevant for existing contributors, but it could be helpful for new people willing to contribute. It could also be used to maintain a list of "good first issues" to attract new contributors.

This could be a proactive approach during issue creation in addition to the reactive approach from #127 (reply in thread) for existing issues or those that have not be processed that way.
While I think that these things could be valuable, it is clear that they increase the effort for creating/processing an issue and the question is whether reporters/contributors/committers are willing to invest that.

[mickaelistria]

In eclipseide-jdtls, I've introduced a blurb that is in the issue template when someone reports an issue. It looks like

"""

• I understand reporting an issue to this OSS project does not mandate anyone to fix it. Other contributors may consider the issue, or not, at their own convenience. The most efficient way to get it fixed is that I fix it myself and contribute it back as a good quality patch to the project.

"""

I believe it actually sets the expectation at the right time and may motivate people to join the effort as they report, instead of letting them wait and hope and then seeing their issue report months later by lack of interest, generating a ton of frustration.
Maybe the Eclipse Platform/SDK project could consider having such warning in issue template as well?

[jukzi]

Please also note that i never advocated automated closing. I think it as kind of welcoming service to get any human feedback even if it's a refusal. That can't be done with templates.

[HannesWell]

Fully agree, but unfortunately I don't think we have the man-power to do that for every issue.

When working on Eclipse in my free-time (which is most of my contribution time) I mainly do this out of interest and I have to admit that it is not very interesting and therefore motivating for me to deep-dive into someone else problem in an area I'm not very familiar with or where I don't know the answer quickly or if I did not cause the problem due to a previous change.
And if I cannot say much to an issue at the moment I think it also does not help much to say only "Hello and thanks for the issue, we will look into it (maybe) sometime in the future."

[HannesWell]

As already said by others and in other discussions, I also think that auto-closing bug-reports gives a very bad user-experience and at least I would be frustrated and therefore understand if reporters are.

Nevertheless anything else that helps to make bug-reporters expectations meet the reality and make them aware of the possible ways to get their bugs fixed IMHO helps:

• Link to https://github.com/eclipse-platform#community or similar places as often as possible
• Have a bot that mentions https://github.com/eclipse-platform#community after some time if the issue did not get any attention
• Add a template as suggested by Mickael that also includes https://github.com/eclipse-platform#community and generally better prepares reporters as suggested in Triage: closing Stale Issues and Pull requests #127 (comment).
  • Search for duplicated issues is ideally done by a reporter of a bug before creating a new one. Maybe this should be mentioned more often?
• anything else that does not close the issue.