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.
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 ) 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.
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 ). 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.
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