Frappe Cloud Support Partners Foundation Frappe School

Why should one still create Github issues? (>3000 open issues)

I know it is a provocative question: But why should one still create Github issues if there are thousands of open issues (dating back > 8 years)? I am aware of the general purpose of the issues. But let’s be honest. Does anyone think that people will still look at the open github issue #1739 (just some random number) from some time in 2016? It seems if issues get older than ~3 months nobody looks at them again (besides if others find them via a Google search and keep pushing them on the forum or if the issue is really bugging many).
What can be done to reduce the number of (unnecessary) open issues? It seems there are too few in the core team and active developers to address this.

(This is meant as a a constructive question - not just a complaint. Maybe this is normal in an open source project. I am a newbie open to learn).


It’s…complicated. :slight_smile:

Personally, I get a lot of value from the github issues repo. If I hit something that I think is a bug, I’ll usually search there before I search these forums because I tend to get better results. If you think of the issue list as a public error log of sorts, it can be quite useful to see what other people are running into.

I think some people want the issues to be a to-do list for the devs, but that’s not how open source works. That said, it does certainly feel like ~80% of the issues should be closed, either because they deal with old versions of the software or because they lack clear steps for bug reproduction. It’d be a good project for someone who wants to contribute without programming skills.

1 Like

I have scrolled through the issues on Git. My personal opinion is mostly are due to users lack of software understanding. Many can just be closed by moderators without giving a solution as ot exists already.

1 Like

I think reducing the number of unnecessary, low-quality issues would increase the reputation of this project for people thinking about adopting ERPnext and additionally help developers to really focus on issues that are important.
I mean 25% of all issues ever created are open!!! That creates the impression to the outside as if the software is just full of bugs and nobody cares about fixing them. I know that’s not true (ERPnext is a magnificent, powerful and well-maintained software). It’s just a (not so ideal) brand message that is also conveyed…

Unfortunately, the new version (13) of ERPNext has brought a lot of issues to things that were working very well in the past. I haven’t posted new issues, but definitely this number will grow in time.

1 Like

A lot of projects use bots to handle issues. For example, if an issue is open for a long time with no update, then a bot will add a comment: “Is this problem still valid?”. If no answer comes, then it can be marked stale with a label, and can be closed after some more time.

Of course this is just one part.

The other part is that a bug triage team is needed who make sure that issues are of high quality, include the necessary information to reproduce … etc. Such issues could receive another label, e.g. “confirmed” or “triaged”. Such issues would not be closed automatically by the bots. I think this is something where the community could help a lot, but the exact procedure needs to be defined and documented.

Finally: other successful projects, like the Godot Engine (with 5000+ issues) decided to split feature proposals into a separate repository, so issues on the main repository are reserved for bugs. This could be a good solution for ERPNext as well.



What is the official stand point by the Frappe Team on this topic? Is it wanted to have thousands of open issues to not lose track of any issue that was ever recorded or would it be beneficial addressing this and trying to reduce the number of open issues?
(There are several ways to address this as pointed out by previous posts above)