All comments/suggestions to date all sound good, but there are also a great many git issues listed in the frappe and erpnext repositories that should seriously be considered. Some of them are quite old, but still very valid. Let’s not loose sight of them!
One thing I struggle with is what is on the real published road map. My suggestion would be to tag the issues we think we want in a specific version (e.g. 8.1, 8.2, 8.3, 9.0, 9.1, etc.) and then have the community vote on them and then the ones that get the most votes are prioritized. I am thinking that there are a number of “themes” in the various old issues that could be combined and worked on for minor versions. One thing that comes to mind is a collection of asset management issues could be combined into one minor release. Major releases get big new features like the medical/healthcare module or big framework updates (like a move to python 3.5) and minor releases include new/updated features to existing modules. There is nothing wrong with going to 8.10 if there are 10 modules that need a bit of work! Human Resources has a number of git issues as a theme for example as well (e.g. lots of folks asking for payroll improvements 
)
I think that there needs to be a way to support n-1 version for some period of time as well. Not everyone can upgrade right away. So in the recent cycle, there was supposed to be a bench command to keep yourself on the 7.x branch, but it was never implemented. Can we see about doing issue/bug issues only in the n-1 version for say 6 to 9 months? Then those that have custom apps still get a bit of time to upgrade their code to work on newer platform version.
I would like to see improvements in the release cycle. For example, when a PR/Commit is updated the comments give little to no information as to what was either added or fixed. An update of “Minor Fix” means absolutely nothing. Every PR/Commit should be linked to a git issue that provides context and the code that was changed. This happens haphazardly today. Git issues should then be closed quickly to keep the listing clean of current real open ones and not a smattering of ones that are not really open any more, but have not been closed. There should also be a period of time where code is added to develop branch that needs to be tested. There have been a number of times where I have put in a git issue for a bug to see it fixed and closed and merged to master to find that the “fix” did not fix. I never had the chance to test to see if it was fixed from my end before it went to master branch. In time they eventually get “fixed”, but outside of the original git issue.
Documentation must keep up with the changes to code! Right now there are a good deal of discrepancies between what is in code vs what is documented. I would suggest that you all change the PR/Commit acceptance process that says if your code changes behavior then there needs to be a corresponding documentation update/commit included in the PR. This will, of course, slow down the deployment of new code, but will greatly enhance the platform as documentation will always match the code.
So… Any of this could be implemented outside of v9.x. I just thought this thread about going to 9.x was a good place to open up commentary on the process of how things are done.
Thanks
James