Contributions to the VVV project are more than welcome.
By contributing code to the VVV project, you agree to license your contribution under the MIT License.
Open a GitHub issue for anything. We’ve covered quite a bit of ground through the first year, so it would be helpful to search for related topics first. That said, don’t worry if you find yourself opening something that sounds like it could be obvious. There is no such thing.
Comment on any GitHub issue, open or closed. The only guidelines here are to be friendly and welcoming. If you see that a question has been asked and you think you know the answer, don’t wait!
Submit a pull request at any time, whether an issue has been created or not. It may be helpful to discuss your goals in an issue first, though many things can best be shown with code.
We do ask that the pull request be submitted against the current develop branch, which is the default on the VVV repository. Every effort is made to make the pull request as stable as possible before merging it in.
It may make sense that a feature branch is created so that several contributors can work together. In this case, it is possible that write access to the VVV repository will be given liberally. You may be asked to submit your pull request against a feature branch so that it can be merged and worked on with others before going in to master.
The master branch can be considered stable and a list of stable releases is maintained as we go and can be used by anyone concerned by ongoing development.
Milestones and Labels
Some loose organization has grown around milestones and labels. We’ll often have the next two versions listed for selection as a milestone. Things like bugs, enhancements, docs, etc… are listed as labels.
For any shell scripting that we do in Bash — see
provision.sh — we try to follow the style provided in Google’s Shell Style Guide.
For any PHP, we try to follow the WordPress core code standards.