How do you make a change?
Changes are made through pull requests. If you are unfamiliar with pull requests, please review the project’s Github Workflow.
What should go into a change?
For non-trivial changes, the best practice is to have a single PR for each issue you are addressing. The reasons for this are as follows:
* The repo maintainer may want to merge one change but not another for the stability of the build.
* A user may wish to see how to resolve a specific problem in their currently running cart, and wants to change the fewest things possible.
* A small self-contained changeset is easier to evaluate.
Bug Fixes and Formatting
When changing existing files, try not to make large formatting changes. Keeping the existing format allows people to more easily compare versions. See Coding Standards for more details.
How should I document a change?
Documentation starts with the title of the PR. A good title describes succinctly the issue being solved.
Good PR Title
Check value of
foo in account creation submission
(Note that Fix bug in account creation would not be a good PR title.)
In the body of the PR, explain the issue, contrasting the current behavior with the expected behavior.
Good behavior description:
- Current behavior: the person submitting the form can add non-alphanumeric data to the
foofield; this is undesirable, since
foois only alphanumeric.
- Desired behavior: entry of non-alphanumeric data displays an error message and causes the submission to fail.
Show your work! Demonstrate how you tested the change you are submitting.
Good Test Data:
* Set the value of
4323*(!. Observe that the submission fails and an error is shown.
* Set the value of
good entry. Observe that no error is shown and the submission succeeds.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.