Should we use github issues to steer development of ERPNext?

Continuing the discussion from Lowering the pile of issues on github - Call for Volunteers:

the title basically says it all …

Would it be a good idea to use the github issues as (the one and only) tool to steer the develpment process of ERPNext?

I mean in terms of lining out the general roadmap and following up on how it is being implemented

upside:

  • extremely transparent (which should be motivating for the Community to engage more directly)
  • One central point to turn to with any matters related to this process for everyone

challenges

  • requires detailed instructions/guideline on how to use labels, projects & milestones
  • requires strict empowerment of those instructions
4 Likes

I’d say: ‘yes’

  • Even the ‘challenges’ (once overcome) will help to get to a more structured and open process
  • To have a complete open process can turn out to be a big selling point (I mean who else has that?)
  • This may also lead to more engagement of everybody

I agree. Some thoughts noted below:

  1. There may be issues which could be a ‘nice to have’ vs a ‘must have’. So we would need to figure out prioritization.
  2. There may be features that are not yet Github issues. So benchmarking against other contending software may be a good way to come up with a feature list that we want to aspire to.

Principally though, I stand by getting the current code base to high level of maturity by closing as many issues than to add new modules entirely. Even the benchmarking exercise would come after.

3 Likes

Yup, definitely agree that using the issues can help with the development roadmap. But I think we can do this initially and until the Foundation can figure out the direction where ERPNext is headed and build from there.

Although I think it would be nice if we could create Vision, Mission, and Goals for ERPNext so that these can steer us forward and help us with which issues to focus on and which issues have lower priority. :slight_smile:

2 Likes

This is a great topic. So here are my thoughts on this:

First - keep it all in git issues for the transparency piece alone. As an open source community driven project, transparency is very important. Lots of other companies or non-profits that control development are still transparent (think Red Hat or Canonical). I think this project should follow that model.

Second - github is an excellent platform and is well known. While we would need to provide some level of “education” on how this particular project wants to use labels, projects, and milestones, that is not that big a deal. Just write a page on it in our documentation area and have that link be a prominent feature somewhere.

Third - We leave opening an issue still wide open, but you don’t have to allow everyone edit access to the issues list. As an example I have opened many issues, but just recently was offered the opportunity to help the project further by being granted more rights to the project repository. Those contributors that are active in the discussion forums and show a willingness to help the project move forward (and can follow the rules :slight_smile: ) are granted access to the git issues for editing/management.

lastly - We do need a road map of some kind. Git issues don’t lend themselves very well to that, so having some kind of webpage or something w/ graphics or a gantt chart or something would be good. Include a mission, vision, etc to it. Discuss the 50,000 ft view or something to give a broad stroke look at the future picture. I definitely think a really good feature list is important so we can start to compare with other platforms out there and determine what to get in to the platform.

From a prioritization planning perspective, I mentioned in the planning for v9 thread that we can use git voting to get a sense of the popular items. We can also use some kind of voting mechanism to determine what the various releases are. I proposed that 8.1 be a bug/defect only release and that 8.2 was going to be an “all things accounting module” release. That was simply a suggestion, but if we use some kind of voting mechanism to get a sense from the community on what the hot topics are, then you will get the best bang for your development time.

I really like where this project is going! Keep up the good work.

3 Likes

I agree with most of the observations, suggestions

  1. Might be a good time to having a broad vision statement.
  2. The GitHub Wiki is a great place to discuss roadmap
  3. Continuous improvement (maturity) and new features should go hand it hand. No reason why we should focus on only one.
3 Likes

unless the wiki is not git (if I am not mistaken), so no branching, no PR’s, no issues … wouldn’t a repository with files work best to collaboratively develop such a thing?

That is an idea. Lots of other projects have documentation only repositories and all the markdown and images are there.

If we went this route, I would suggest that the repo have everything you need in it to be able to download and build local copies leveraging some kind of make process that is cross platform (e.g. you can run it on windows, linux, or mac)

Agree with @rmehta. Of course, only from user/hobbist coder perspective, I’ve no knowledge on software engineering best practices whatsoever.

But, as we can usually see on these forums, most users can come up with, at least, one killer, deal-breaker feature that ERPNext lacks for them to finally be able to use a system that, otherwise, has them all excited (one of them being actually me :wink: ). Most modules have such “problem”, it’s more about where’s each user’s focus.

Spending lots of dev-hours on ironing out bugs on modules that need (and eventually will, on the short run) some major overhauling or will even be re-written seems pretty wasteful, IMHO.

Of course, there’s also no use for a system with tons of features and lots of nasty bugs that would render those features unusable.

So, balance is probably the keyword here.

2 Likes

one reason could be that by adding features you also add bugs/shortcomings by definition and whether you are adding more bugs/shortcomings then you iron out the system as a hole has more flaws then before.

So, from my perspective I may put a focus on reducing bugs and making existing features better.
That does not mean to stall implementing new features completely. I’d just put priority on making things that already exist work better

1 Like