internal workflow for handling incoming pull requests

The following steps have been agreed on how to handle incoming PRs

Team "Editorial/Redaktion"

• discuss/decide upon whether or not the additional functionality is a desired enhancement of Boost Union, if not --> communicate to PR owner
• if desired, check if an issue exists, if not --> issue creation by us or by PR owner, link to PR via keyword "resolves #ISSUE-NUMBER"
• check in the body of the PR whether all automated checks have been passed, if not --> communicate to PR owner, if necessary contact DEV team for help
• if it is decided that the PRs functionality is a desired enhancement of Boost Union and all checks have been passed, change issue status to "ready for test"

Team Testing

• functional testing (issue status: in progress testing)
• if there are issues with the PRs functionality --> documentation and communication to PR owner, set status of issue to "In progress DEV"
• if Team Testing has no issues, hand over to Team Peer Review and set the issue status to: "Ready for Peer Review"

Team Peer Review

• At the beginning of the peer review -> Add yourself as peer reviewer to the PR -> (optionally) add a comment to the PR, informing the PR creator with some words of gratitude that you will be doing the review now.
• Team Peer Review has documented a plugin-independent separate checklist on a separate wiki page. Check the PR against the checklist and post the checklist as comment in the PR.
• Choose the right merge mode: -> "Squash and merge" should be used by default -> "Create a merge commit" should be used if you really want to keep the individual commits of the PR, for example if you added your own changes in a "Review changes" commit to the PR.
• After you have merged the PR, delete the PR branch - but only if the branch is without the Boost Union repo, we do not want to delete branches from forks from PR creators.
• As soon as the PR is merged, schedule the backport and set the issue status to: "Ready for Backport"
• As soon as the PR is backported, add testing instructions to the PR for the release test:

Testing instructions:
* Test steps: <Add steps here>
* Related documentation: <Link to README>
* Differences on Moodle 4.2 and 4.1: None

and hand over to Team Testing and set the issue status to: "Ready for Release Test"