Please stop automatically closing GitHub issues

ERPNext
1

I recently discovered something in ERPNext that I would personally call a bug. I researched it, collected information and took my time to carefully lay out the issue in Filtering in lists does not work as expected for hierarchical data (such as territories) · Issue #17394 · frappe/frappe · GitHub. In total, I believe I spent some 2 hours on this issue.

2 months later, my issue is closed by some bot with the message

This issue has been automatically marked as inactive because it has not had recent activity and it wasn’t validated by maintainer team. It will be closed within a week if no further activity occurs.

This is not only disrespectful towards someone who wished to contribute, the picture someone gets by looking at the closed issues is a complete distortion of reality.

Just not getting around to handling the various reports seems not enough reason to just ignore and close them. Please get rid of the bot.

6 Likes
2

This is reported many times

https://github.com/frappe/erpnext/pull/25838
https://github.com/frappe/erpnext/issues/22742
https://github.com/frappe/erpnext/issues/21363
https://github.com/frappe/erpnext/issues/18813

There was another attempt to “properly” fix: fix: Descendants of including self by netchampfaris · Pull Request #15360 · frappe/frappe · GitHub

But all options explored have one problem or another and introduce breaking behavior for sure. Which is why it hasn’t been fixed yet.

2 Likes
3

We use GH as our primary issue tracker right now. But a good chunk of reported issues are:

  1. Not correctly reported i.e. lack any kind of actionable info
  2. Duplicates / old issues
  3. just random cries for help

There’s only so much we can do, so to prioritize stale bot has to be there.

ref: chore: update stale rules and apply on issues by ankush · Pull Request #28816 · frappe/erpnext · GitHub

Is closing stale issues really a good idea?

In an ideal world with infinite resources, there would be no need for this app.

But in any successful software project, there’s always more work to do than people to do it. As more and more work piles up, it becomes paralyzing. Just making decisions about what work should and shouldn’t get done can exhaust all available resources. In the experience of the maintainers of this app—and the hundreds of other projects and organizations that use it—focusing on issues that are actively affecting humans is an effective method for prioritizing work.

To some, a robot trying to close stale issues may seem inhospitable or offensive to contributors. But the alternative is to disrespect them by setting false expectations and implicitly ignoring their work. This app makes it explicit: if work is not progressing, then it’s stale. A comment is all it takes to keep the conversation alive.

3 Likes
4

Hi Ankush,

Thanks for taking the time to reply.

This is reported many times

Yes, it was, and all reported issues are closed, and yet the problem is not solved. In my report, I make reference to those other reports and state clearly why their solution is not sufficient.

A good chunk of reported issues are:

  1. Not correctly reported i.e. lack any kind of actionable info
  2. Duplicates / old issues
  3. just random cries for help

There’s only so much we can do, so to prioritize stale bot has to be there.

I’ve been around in open source long enough (+25y) to know the challenges well.

I fully agree with you that many issues fall into one of the mentioned categories. But by applying stale rules indiscriminantly against all reports, no matter if they fall into one of those categories or not, is disheartening for those who are indeed trying to make a real contribution.

Here is how other, successful projects handle the same challenge:

  • Insufficient information: Feedback is requested from the reporter. Here, a stale bot could indeed support with removing/closing issues if no feedback is provided after some time.
  • Duplicates: Linking to the duplicate with subsequent closure of the report. This also helps future visitors understand that the issue is actually resolved.
  • Random cries for help: Remind the reporter that the forum is the place for general discussions and close the issue.

ERPNext is an open source project. Some users, such as myself, may be paying for services but no one is paying for the software. I understand that my issue must be interesting for enough people, particulary developers, for it to be looked at and solved. As an alternative, if the issue is that important to me, I can pay someone to have a go at it.

But just because no one feels the need to work on my issue, does not mean that it’s not an issue or, worse, that it has been solved. On the opposite, the issue I reported is “actively affecting humans”, as you put it in your justification.

So, by closing my issue without putting any work into it, you actually do set false expectations to visitors of your GitHub page because it will seem that your team is a lot more active than it actually is.

If there has been no interaction with an issue whatsoever, it should not be closed.

4 Likes
5

I got rid of it for a while, lets see where things go: chore(meta): disable stale bot on issues · frappe/erpnext@c66c1e2 · GitHub

6

Let’s see where things go.

I appreciate it but it won’t go anywhere good without some minor amount of moderation. IMO the most important thing is for developers and other contributors to spend some time on categorization and validation. All issues that cannot be validated even after reconfirmation, can and should be closed. All others should remain open, with no time limit.

Because it’s not realistic to go through this validation quickly, I recommend to differentiate between a bug report and a validated bug report. I would probably add a new label called something like “bug-unconfirmed” that is automatically added to all new reports and changed to “bug” only once it was validated. Needless to say, only the ERPNext team should have the permission to do this validation.

This leaves you with plenty actual issues and there is no deadline for you or anyone else to solve them. However, if one decides to work on some issues, he won’t have to do the validation first but can just grab a bunch of issues and start working on them. Developer effectiveness should increase.

Having said that, you may want to consider locking down GitHub to just issues, i.e. bugs and vulnerabilities, and use the forum for feature requests. This should give you two benefits:

  1. You should get more interaction and votes on the forum which gives you an indication how to prioritize the requests. (This is also supported on GitHub, of course, but regular users are more likely to participate in the forum)
  2. Feature requests by nature can be vague while issue reports should be very specific. By allowing both types of requests on the same platform, you may risk people using the same vagueness for issue reports as for feature requests.

IMO, every issue on GitHub should be formulated in such a way that everyone with the same system can easily reproduce it. If one does not have sufficient information or knowledge to formulate the issue in such a way, they should be directed to the forum and the issue closed. The same is true if the error stems from a configuration issue - GitHub should not be the platform to explain someone how to configure his system.

BTW, and this is important: this also means that you and other developers have to be stern and act according to your own rules. If you’re going to make exceptions and answer simple configuration questions on GitHub, you can’t expect other users to follow the rules and go to the forum for their questions.

By applying these measures, I believe it should bring down the number of issues on GitHub considerably while at the same time increase the quality of the reports.

3 Likes
7

Yes. I entirely agree with you and second your suggestion.
I had the same experience a couple of times as well. I stopped contributing issues in the last year or so because I became frustrated with the maintainers decision to close issues automatically. This might have started after I pushed for more active work on the open issues. I am not sure it went in the right direction. It’s great that we have now less than 2000 issues on Github (that means 1000 less than about a year ago). Not sure if it is the right approach to make the repo seem tidier, closing issues that people haven’t had time to work on, yet. If this is done automatically, it discourages to open new issues after people realize that their issues are just closed automatically. Why should I spend the time to write a detailed description of a bug or so, if the issue is automatically closed because nobody worked on it for several months. I get it that this is a ressource-constrained environment and we might have a lot of open issues. Just closing issues automatically is not a good solution in my opinion.

2 Likes
8

Just read through the thread you linked. Everyone seems to agree that a very significant part of the issues in GitHub are of such a low quality that they could just be closed and that there needs to be some clean-up.

The question is now, of course, how this should be approached and who will do the actual work.

IMO, particularly @kisg 's comment included some very helpful, actionable ideas. And I think he makes a good point when he writes:

I think this is something where the community could help a lot, but the exact procedure needs to be defined and documented.

9

I love the idea of a distinguishing “confirmed” and “un-confirmed” bugs. Just because no one wants to work on an Issue, doesn’t mean it’s still not a bug or enhancement opportunity.

This is definitely a balancing act.

  • Too many Open Issues, and it’s not only a mess to sift through. But it discourages anyone from adding to the pile.
  • Too many “nope, closing it” actions and you’re not only losing visibility to real problems. But also discouraging anyone from creating new/more Issues.

The laissez faire maintenance of ERPNext is probably difficult enough already for the Maintainers, without the above adding to the challenge.

4 Likes
10

There should be a system to tag issues as Hot Issues also, especially for the issues that break the functionality for all types of users. There are many issues that resulted in new functionality being introduced as unusable.

It’s very important and relevant to maintain the credibility of Frappe and ERPNext by addressing such issues by the Frappe team and the collective efforts of the community.

There should be category as Hot Issues at discussion forum too.

11

For what it’s worth, many of these suggestions have been implemented at various points, though it is always hard to keep momentum because of the work involved. Right now, bugs that have been verified by the maintainers get marked with the tag [valid].

2 Likes