Contributions are welcome! You can help making this module better by explaining a bug, suggest a change or a new feature. The correct way to do that is to create an issue.
We accept proposed code changes via pull requests.
Tests must pass and new functionality should be extended to cover any new lines of code. See the SilverStripe Unit and Integration Testing documentation.
The code to this module is following the PSR-2 standard
with the exception of SilverStripe spefic variable naming like private static $has_many etc. We will not merge code that doesn't adhere to the standard.
Every push to a PR will run a code quality check via https://scrutinizer-ci.com/ and the results will
show in the Github PR.
It's also possible to use the PHP Coding Standards Fixer to check and fix the code style for you.
Having good commit messages serves multiple purposes:
- To speed up the reviewing process.
- To help us write a good release note.
- To help the future maintainers of this module finding out why a particular change was made to the code or why a specific feature was added.
Structure your commit message like this:
Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together.
Further paragraphs come after blank lines.
Bullet points are okay, too
An asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here
Write the summary line and description of what you have done in the imperative
mode, that is as if you were commanding someone. Start the line with "Fix",
"Add", "Change" instead of "Fixed", "Added", "Changed".
Don't end the summary line with a period - it's a title and titles don't end with a period.
Always leave the second line blank.
If you are having trouble expressing the change in a short subject line, you probably need to make several commits, see below:
Group related commits into one commit. Try finding a set of changes that describes a minmal working chnage and commit them as one change. This might be better descibed with a good and bad example:
Bad
- change variable name to blah
- add check if user is logged in
- clean up whitespace
- reset users password and send email
Good
- add possibility for users to reset passwords
Bad
- fix bug on user password reset and remove old password resets
Good
- fix bug on user password reset
- remove old reset tokens from database