internal workflow for handling incoming pull requests

(SB: Übernommen von Luca Bösch aus dem Boost Union Wiki)

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:
• Related documentation:
• 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"