Contributing to the shop module
This module only moves forward as we each build the features we need. We love pull requests!
Here is a quick list of ways you can contribute:
- Test the latest code. Install it and try it out.
- Code new features and bug fixes. Make sure to check our Trello board for upcoming features. Submit github pull requests. Don't forget to write PHPUnit tests that ensure your code runs. All pull requests are automatically tested via TravisCI.
- Submit issues and ideas. These can be bugs, or ideas. Be descriptive and detailed. Its better to discuss and design ideas before writing code. Please first check the list of existing issues to make sure an identical one doesn't exist already.
- Write documentation. Both the developer and user documentation can have pieces missing. Documentation is stored in the repository under
/shop/docs_user. Documentation gets displayed at http://docs.ss-shop.org
- Provide translations. This will allow people speaking other languages to use the shop module.
- Financial contribution. Giving a donation, or financing the development of some features will help this module go further, faster.
If you would like to contribute code, please fork this project. You can then make changes in feature branches via git, and submit pull requests, which will be reviewed and merged into the code base. If merge is not appropriate, instruction will be given on the best action(s) to take.
We try to match SilverStripe's guidelines as closely as possible. In some ways our approach will differ, but it is a good idea to read their guidelines first.
We are moving toward PSR-2 compliance and as such any new code submitted should be fully compliant if possible.
We use Github Flow which basically means:
- Create your own fork
- Create a feature branch on your fork per feature or unit of work
- Submit a pull request
Our branching scheme follows the one used by SilverStripe.
master will always be the branch for newest development and separate branches will be created for older releases.
Example: If the current development in
master goes towards version 3, there will be a
1 branch for fixes to these older versions. If needed, branches for minor versions can be created as well (eg. a 2.x branch for work on a new minor release).
Releases will be frequent and follow Semantic Versioning. Patches for specific older versions can be made by creating a branch from the appropriate tag.
This project political model used for this project is a Benevolent Dictatorship. This basically means the project owner will have ultimate say in decision making. Discussion is still very much welcomed however, and if agreement can not be found, anyone can fork the project and start their own version.
We are actively moving towards creating a team of core committers and moving away from depending on one maintainer. Expect more news soon and watch this Trello board: https://trello.com/b/85ZyINqI/silvershop-development-planning
Good development practices
- Write a new unit test for a new bugs or features
- Unit tests MUST pass before submitting new contributions
- Maintain backwards compatibility, or provide migration scripts, and help
- Full support of standard SilverStripe framework features
- Prefer SilverStripe core framework features over 3rd-party add-ons
- Make use of design patterns
- Comment code thoroughly
- Write and update documentation along with changes
- Major changes need to be backed up with solid reasoning
- Consult external sources, such as google groups when consensus can't be reached
- Modular code: high cohesion, low coupling
- Keep a record of everything - prices changes, transactions (posting table)
- Allow site owner to change all prices. One-time configurations are done in code.
- Install an EditorConfig plugin for your editor or IDE.
Becoming a maintainer
Want to become part of the SilverShop team?
Our guidelines for new members are:
- people that are already contributing and showing interest in the direction of the project and/or
- people that like the project, and spread the word