Hello and welcome 🖖! We'd love for you to contribute to our source code and to make WordLift even better 🎉!
Here are the guidelines we'd like you to follow 🙏:
- Question or Problem?
- Issues and Bugs
- Submission Guidelines
- Coding Rules
- Releases and Commit Workflow
- Cross-browsing Tests
- Further Info
If you have questions about how to use WordLift, please direct these to StackOverflow or to GitHub issues. We are also available on Gitter.
If you find a bug in the source code or a mistake in the documentation, you can help us by submitting an issue to our GitHub Repository. Even better you can submit a Pull Request with a fix.
Please see the Submission Guidelines below.
Before you submit your issue search the archive, maybe your question was already answered.
If your issue appears to be a bug, and hasn't been reported, open a new issue. Help us to maximize the effort we can spend fixing issues and adding new features, by not reporting duplicate issues. Providing the following information will increase the chances of your issue being dealt with quickly:
- Overview of the Issue
- Motivation for or Use Case - explain why this is a bug for you
- WordLift Version(s)
- Browsers and Operating System - is this a problem with all browsers or only specific ones?
- Reproduce the Error - provide an unambiguous set of steps to reproduce the error.
- Related Issues - has a similar issue been reported before?
- Suggest a Fix
To ensure consistency throughout the source code, keep these rules in mind as you are working:
- WordLift is a WordPress plugin therefore it abides by WordPress coding standards:
- All features or bug fixes must be tested according to the Testing guidelines:
- a sample test class
- a convenient unit test class
- a convenient ajax test class
- Travis runs automatically all unit tests
- The project structure is based on the WordPress Plugin Boilerplate with some legacy code still floating around (we @deprecate old code that we're going to remove soon)
- If you're using PhpStorm for development, consider setting the WordPress code style
- We use Code Climate and Scrutinizer to monitor the quality of code and code style consistency: check there for issues and fixes (we're aiming to greatly improve our score)
- We believe in DRY and KISS and somewhat in "Don't Reinvent the Wheel"
We use Semantic Versioning and abide by the GitFlow workflow: development happens in feature branches created from the develop branch. Once we're ready for a release, we merge the feature branches to develop and create a release branch which transitions into QA.
Once the released is ready, we merge it to master and push it to wordpress.org.
Fix to bugs are fixed in hotfixes branches created from the master branch to which they're merged back (and then to the develop branch).
We have very precise rules over how our git commit messages can be formatted. This leads to more readable messages that are easy to follow when looking through the project history.
In summary:
- new features are developed in feature branches:
- forked off the develop branch
- the name is feature/xyz_title_of_the_issue
- fixes are developed in hotfix branches
- forked off the master branch
- the name is hotfix/xyz_title_of_the_issue
The commit message rule is very simple: 'see #xyz: small description of the change', where xyz is the issue number, e.g. 'see #1: updated changelog'.
Once work is finished on an issue, don't close issues: label it resolved. Only after the work is published on wordpress.org we close the issue (typically the person that publishes the plugin to wordpress.org will close the issues).
We use SauceLabs to perform cross-browsing tests on the following browsers:
For further info please head to WordLift's web site.