Releases
Stand-alone merge requests that are labelled, or parent issues, should be moved to the release project when closed. This is because I found it easier to update the CHANGELOG.md after all merges for a given release are completed rather than in each feature/bug fix branch. Otherwise, every feature/bugfix branch will have a merge conflict in CHANGELOG.md, making parallel work much harder to do.
This means when making a new tag, the release project has to be reviewed, and a pr for changelog changes has to be added based on "in progress" items. After a release tag is made all issues and merges in "in progress" should be moved to competed and a new prep merge should be made for the next release, setting the project version to the next expected release, and a header in changelog added for it so we know we are on an 'in-progress' release.
Support
New bugs need to be triaged. Triage includes making sure they have complete enough information to be worked on, and to decide their priority. In progress bugs are either high or low priority. When a bug or support issue is completed, and and any associated pull requests attached (bugs), it can be moved to review. Once any associated pr's are reviewed, they can be merged. If the issue is deemed complete, it will be closed and moved of the support project, or it will be moved back to high/low priority for further work. If a closed bug needs to be re-opened or re-done, it might appear in the development project and be sprinted with a milestone instead.
Develop
Milestone development/ active sprint. Backlog is where issues begin. Todo are ready to be worked on and selected for the current sprint. Active issues are in progress. Done is ready for review. When the issue is closed it should be removed from the project.