[WIP] Workflow Restructuring

[scribblemaniac]

This is a PR for changing the development workflow. There are a few motivations behind these changes:

• Many critical bugs have only been discovered after release. With our slow development cycle that means that many users are frustrated by bugs in the latest stable release that have been fixed for a long time. Release candidates do not seem to help with this.
• Pull requests are very slow to be accepted.
• Related to the previous point, all responsibilities related to reviewing a PR are left to the developers because they are the only ones able to easily build the pull requests. Developers are needed for code review, however quality assurance as well as evaluation of the interface/front-end implementation of features is something that can and perhaps should be done in part by regular users.
• Lack of clarity for development team permission and operational expectations.

Related to the technical changes in this PR, there are multiple changes to how we operate that will take affect along with this PR. First I will say that currently these are just proposed changes. We have discussed most of these changes in Discord but nothing is written in stone, and if we implement something and it does work out we can always modify or scrap it. With that said, here are the changes as currently proposed:

• New odd-even versioning scheme. The odd version numbers will be released every 3 months and will contain feature updates (from the master branch, see New workflow). Even version numbers will be released 1 month after each odd version and contains only bugfixes (from the bugfix branch, again see New workflow). The idea is that this will give users enough time to find any critical bugs in releases and developers to patch these bugs without having to wait such a long time for a stable version to be released with the fixes for these bugs.
• New project structure and workflow. The new way I have proposed this to operate can be summarized with the following diagram:
  
  There's a lot going on here, but let me try to break it down. The master branch will still contain the latest accepted bugfixes and features, and the release branch still contains releases, but there are now a new branch for bugfixes and potentially multiple new branches for major features. Where exactly you commit will depend on the nature of the changes you are committing:
  • If you have a minor feature, it can be committed/pulled directly to master.
  • If you have a bug fix, then it should be committed/pulled to both the bugfixes branch and master. Since the bugfixes branch will be behind master, it will probably be easiest if you do your changes on a clone of the bugfixes branch and then merge that branch into master.
  • If you have a major feature that should be reviewed first, you can commit it directly to feature/ branch in the main repository. If you do not have write access, create a PR to such a branch, not master. This PR can be immediately accepted with only minimal review (to assure the CI scripts have not be modified maliciously). Then a PR will be created from the feature branch to master which will be reviewed properly.
    The reasoning for using this two step process is because it allows us to create automated builds for major features before they are approved. This opens things up for people willing to test our program and addresses many of the motivations presented at the beginning of this post.
  • At release time, what will happen depends on the type of release. For bug fix releases, the release branch will be updated to match the bugfixes branch. For feature releases, the release branch and the bugfixes branch will be updated to match the master branch.
  • If a hotfix is necessary, it should be treated as a normal bug fix and a release should be made the same way as a normal bug fix release. Given our new versioning scheme, this hopefully will never be necessary.
• The above changes do not address the final issue in the motivations section. Since this is a point of conversation in our upcoming team meeting, I will wait until we've discussed it there before writing anything specific here. Basically we need to explicitly document our procedures for decision making, adding/removing team members, etc. See final list.

Note that all these things should be thought of closer to guides than requirements. Yes we all need to follow this if it's going to be functional, but despite all the new formalities, the emphasis should remain on providing an open, inclusive experience for everyone, especially for new developers. If somebody does not follow the expected way of doing things, help them to fix it and learn for the future, do not judge, criticize, etc.

Here is a tentative list of what this pull request will change:

• Internal pull request builds uploaded online
  • Appveyor build (Windows)
  • Travis build (macOS + Linux)
  • Modify PR builds to provide additional debug information and labeled with PR title
• Add a link to the pull request build in the pull request. Possibly use github-pr-status, the Github API directly, or some other similar tool.
• Separate nightly builds into bugfix and feature builds?
• Document new development workflow
• Develop and document team member expectations for:
  • merging pull requests
  • committing directly to master/bugfixes
  • reaching consensus on deadlocked issues
  • adding new team members
  • removing inactive team members
• Create template for "repeated" pull requests (an internal feature pull request that was originally from a fork)