Changes should either be made on a separate fork of the repository, and integrated via pull request, or on a feature branch within the main repository (prefix branch name with “feature-” or “issue-n-“, where “n” is the issue number relating to the proposed update). Any change that results in a functional change to an existing test suite must be included by consensus of this group, and the related comments group of the associated working group, and should have two implementations which pass the tests. Once consensus is reached, a pull request including this feature branch may be integrated into the main (gh-pages) branch.
Note that naming conventions for tests often make conflicting overlaps inevitable, so consider this when naming new tests and formatting the test manifests.
Some updates, e.g. more extensive updates to the SPARQL test suite, may require branching off of, and merging back into, a separate feature branch, so that a set of changes can be staged before updating the gh-pages branch.
After a changes to a given test suite become stable, a “release” branch can be created to record the state of the test suite at that time.