Guide for Maintainers

The published content for IWXXM is maintained within this repository.

• To make a code change, please use a fork of this repository and create a Pull Request from your fork.

• Never commit changes directly to this repository, especially to the 'master' branch.

• To ensure that commit history is clean and clear, please ensure that all new branches are rooted at the upstream/master.

  • to achieve this with a local repository:
    1. ensure that your local repository is up to date with the upstream master git fetch upstream
    2. checkout a new branch, using upstream/master as the root git checkout -b <theNameOfYourBranch> upstream/master
    3. push your changes to your branch git push origin <theNameOfYourBranch>
    4. raise a Pull Request for you branch, targeting the master branch of https://github.com/wmo-im/iwxxm
    • This Pull Request will automatically trigger a run of the validation tests, testing all the examples against the schemas, and provide a report within the Pull Request ticket.
  • To achieve this using the github web interface:
    1. make a set of edits to a file within the https://github.com/wmo-im/iwxxm project, using the github web interface
    2. in the 'commit' pane at the bottom of the edit page, ensure that you have selected the radio button Create a new branch for this commit and start a pull request.
    • this is not the default, it must be selected
    • if you have permission to edit the main repository, you must ensure you do not save changes to the master branch (the default); if you do, a repository maintainer will revert your changes.
    1. you can make further changes by browsing to your personal fork and selecting the branch linked to your pull request from the grey Branch: ... ... selection menu in the upper left area of the main view.

• It is good practice, where appropriate, to separate the functional changes from the changes to the examples, putting these into separate commits within the Pull Request.

  • If the functional changes commit is pushed to the repository first, then this will run all the validation tests using the functional changes, without updating the examples.
    • This can demonstrate, on the ticket, that the previous examples would fail validation based on the new change.
  • The changed examples to match the new validation can then be added as a second commit and uploaded to the Pull Request after the tests have run.
    • This update action will trigger the test cases to re-run.
    • The results can then demonstrate that the updated examples pass the validation tests, completing the Pull Request content.

• The person raising a Pull Request should not be the person who approves and merges the Pull Request.

  • At least one review and a positive acceptance is required prior to merging.
  • Any task team member has a mandate to review and approve or request changes to a Pull Request.
  • Any task team member who has merge rights on the repository has the mandate to merge an approved Pull Request.
  • No Pull Request with a request changes flag shall be merged.
  • If there are different commits for the functional changes and the corresponding test changes, it is preferable to 'create a merge commit' when completing the merge, to preserve this history.