Skip to content

Latest commit

 

History

History
69 lines (50 loc) · 4.01 KB

CONTRIBUTING.md

File metadata and controls

69 lines (50 loc) · 4.01 KB
Raw

How To Contribute

Thanks for reading our contribution guidelines.

The following guidelines for contribution should be followed if you want to submit a pull request.

How To Prepare

  • You need a GitHub account.
  • Before reporting a bug or suggesting an improvement, please check the develop branch to see if it has already been addressed.
  • Duplicate tickets will be closed without hesitation, so please check through existing tickets first to see if someone else has already discussed it.
  • Submit an issue ticket for your issue if there is not one yet.
    • Describe the issue and include steps to reproduce if it's a bug.
    • If the issue is a bug, add any relevant JavaScript or PHP error messages. For PHP error messages, a backtrace is preferred. If you don't know how to get one, please follow these instructions.
    • Include relevant version numbers.
    • Additional screenshots or videos are often helpful.
  • If you are able and want to fix this, fork the repository on GitHub.

Make Changes

We use the git-flow branching model. Before reporting a bug or new feature, please check the develop branch to see if it's already been addressed.

  • In your forked repository, create a topic branch for your upcoming patch. Usually this is based on the develop branch.
    • For enhancements, name the branch according to the feature e.g. feature/auto-activate.
    • For un-reported bug fixes, add a fix- prefix e.g. feature/fix-admin-notices.
    • For code that addresses an existing Issue, add the Issue number as a prefix e.g. feature/123-auto-activate or feature/321-fix-admin-notices.
    • Please avoid working directly on the develop branch.
  • Code should follow the WordPress Coding Standards for PHP.
  • Make commits of logical units and describe them properly.
  • Check for unnecessary whitespace with git diff --check before committing.

Commit Messages

We suggest you follow best practices for commit messages:

  • Separate subject (first line) from body with a blank line.
  • Limit the subject line to 50 characters.
  • Capitalize the subject line.
  • Do not end the subject line with a period.
  • Use the imperative mood in the subject line.
  • Wrap the body at 72 characters.
  • Use the body to explain what and why versus how.
  • Please reference any existing issue in the commit message.

Read this post for more detail.

Submit Changes

  • Push your changes to a topic branch in your fork of the repository.
  • Open a pull request to the original repository and choose the correct original branch (probably develop) you want to patch.
  • Do not close any issue you referenced in your commit message.
  • If you have write access to the repository, do not directly push or merge your own pull-requests. Add the [reviewmerge] label when your branch is considered complete and let another team member review your pull request and approve.

License

All submissions are agreed to be licensed under the same license as present in the repository.

Security

There is no need to sign-off or GPG sign your commits. Tags (from 2.4.1 onwards) will be GPG signed.

Additional Resources