Development Process ‐ Questionnaire (draft)

Developers

Developers are users who provide new features, improvements and bug fixes to the questionnaire module.
Approved developers will be given “write” access in the questionnaire Github repository.
Developers create a Github issue for each element they are working on. The issue describes the element fully, and provides a place for discussion during development.
Each issue has a branch created in the questionnaire repository, from the Moodle stable branch(es) it applies to. The branch is named by the Github issue number and the stable branch is applies to. For example, if the Github issue number is 340, then a branch named GHI340_402 is created for a fix to the MOODLE_402_STABLE branch. Creating it in the questionnaire repository will mean remote forks do not have to be maintained.
When code is ready for review, a pull request should be created against the appropriate Moodle stable branch.
Pull requests can contain more than one commit, but commits should be squashed to meaningful commits. Each commit comment should begin with the issue tag (e.g. “GHI340 New slider question type.”)
Note that the MOODLE_*_STABLE branches are protected from being pushed to by “Developers”.

Integrators can review and approve pull requests. Further, the can perform merges to the Moodle stable branches.
Approved integrators will be given “maintain” access in the questionnaire Github repository.
An integrator can merge and push to the Moodle stable branches after status checks have passed and reviews have been approved.
When merging a pull request, the “Squash and merge” option should be used.

Pull requests must pass the Moodle CI checks.
The code changes must be described in the Github issue, and be specific to the changes being described in that issue. If code is changed for other reasons, it should be in a separate issue / pull request.
If a review has pointed out issues or requested changes, the changes should be in a separate commit on that branch. Don’t squash them.

Ensure CI checks have passed.
Ensure that all code changes match up with the issue described, and are understandable.
Unit tests and / or Behat tests should be provided / modified to verify the changes.
Code must comply with the Moodle coding standards.
Reviews are conducted within the Github review mechanisms.
Once a review has been completed and approved, integrators can “squash merge” the PR to the appropriate branch.