Skip to content

Latest commit

 

History

History
61 lines (37 loc) · 2.94 KB

CONTRIBUTING.md

File metadata and controls

61 lines (37 loc) · 2.94 KB

Contributing

The best way to contribute is to help others in the Vapid community. This includes:

  • Reporting new bugs or adding details to existing ones
  • Quick typo fix or documentation improvement Pull Requests
  • Participating in and answering questions in the Vapid forums

After becoming familiar with Vapid and the codebase, likely through using Vapid yourself and making some of the above contributions, you may choose to take on a bigger commitment by:

  • Helping fix bugs
  • Implementing new features
  • Publishing guides, tutorials, and examples

Questions

If you have a question, it is best to ask on the Vapid forums. Vapid maintainers and community members monitor the forums.

Bug Reports

Search through Github Issues to see if the bug has already been reported. If so, please comment with any additional information.

New bug reports must include:

  1. A detailed description of the faulty behavior
  2. Steps for reproduction or failing test case
  3. Expected and actual behaviors
  4. Platforms (OS and browser combination) affected
  5. Version of Vapid

Feature Requests

Search through Github Issues to see if someone has already suggested the feature. If so, please provide support with a reaction and add your use case.

To open a new feature request, please include:

  1. A detailed description of the feature
  2. Background of where and how you are using Vapid
  3. The use case that would be enabled or improved if the feature was implemented

Pull Requests

Please check to make sure your plans fall within Vapid's scope. This often means opening up a discussion.

Non-code Pull Requests such as typo fixes or documentation improvements are highly encouraged and are often accepted immediately.

Pull requests must:

  1. Be forked off the develop branch.
  2. Pass the linter and conform to existing coding styles.
  3. Commits are squashed to minimally coherent units of changes.
  4. Are accompanied by tests covering the new feature or demonstrating the bug for fixes.
  5. Serve a single atomic purpose (add one feature or fix one bug).
  6. Introduce only changes that further the PR's singular goal (ex. do not tweak an unrelated config along with adding your feature).
  7. Not break any existing unit or end to end tests.

Important: By issuing a Pull Request, you agree to allow the project owners to license your work under the terms of the License.