Skip to content

Latest commit

 

History

History
117 lines (89 loc) · 5.39 KB

contributing.md

File metadata and controls

117 lines (89 loc) · 5.39 KB

contributor guide

before contributing

code of conduct

Contributions of all kinds are welcome - this project aims to be inclusive and open. Please read the Code of Conduct before making any contributions.

check current status

Try to search the issue tracker before opening a new one - it's possible your issue has already been noted, fixed, or otherwise handled.

code style

JavaScript Style Guide

When making changes, do your best to match the existing code style. This project uses standard. The most common rules are listed here.

pull requests

  1. Fork the project on GitHub
  2. Clone the project locally ( git clone https://github.com/{YOUR_USERNAME}/{PROJECT_NAME}.git )
  3. Create a new branch with a relevant name ( git checkout -b feat-make-better )
  4. Run npm install to get any necessary dependencies
  5. Make your changes and run npm run build
  6. Run npm test to make sure all tests continue to pass, and it never hurts to have more tests
  7. Push your changes ( git push )
  8. Go to your fork on GitHub to submit a pull request 🎉

notes

  • New features aren't guaranteed to be merged - it'll be up to you and the community to make a convincing case
  • It's generally expected that new features come with tests and documentation, so do your best to add both of those with your pull request

issues

You should always include as much information as possible about the problem - help maintainers and contributors help you back:

  • relevant error messages ( including stack traces )
  • any uncommon or "abnormal" environment configurations
  • link to a minimal reproducible case, ie. a GitHub repo ( this is the fastest way to a solution! )

labels

This set of labels is used in the project and will be added by project maintainers:

name description
breaking Breaking change is necessary to close the issue
discussion Fixes, APIs, or changes need feedback
duplicate An earlier issue already exists on the topic
external Depends on a third-party library or service
good first PR Probably good for a user's first contribution
greenkeeper Opened by the Greenkeeper service
invalid Issue doesn't apply to the project
meta Relates to the repo or project structure
status: accepted Change is accepted and is open to community PRs
status: declined The change is not currently under consideration
status: in progress Work has started toward closing the issue
status: investigating Considering resolutions or looking for fixes
status: need response Waiting for more information from issue opener
status: pending release Issue is resolved but waiting to be released
type: bug Relates to an unexpected bug in the project
type: chore General maintenance or upkeep of the project
type: ci Relates to CI maintenance
type: documentation Applies only to project documentation
type: feature Request for a new feature or enhancement
type: performance Relates to a performance problem in the project
type: question Not a true issue, usually a question on usage

type labels

For the most part, the type labels correspond to the commit types from the Angular commit guidelines used here, though not all of them are represented. So if an issue is labeled with type: performance, it'll probably be closed by a commit like perf(someMethod): optimize some particular method.

status labels

A status label is a progress indicator on an issue - whether it's being worked on, waiting for release, being investigated, etc.

An issue marked with status: accepted is one that's been given the green light but isn't being worked on - so a pull request would be welcome and accepted.

On the other hand, one marked with status: declined is a change that isn't desired or one that might be revisited in the future.

tag labels

Most labels without a prefix like status: or type: are general tags that can be applied to any issue, commonly combined with a type or status such as type: feature + breaking, type: bug + good first PR, or status: in progress + discussion.

Some tag labels are just indicators that won't be used with status or type labels. invalid is usually used alone to indicate that an issue isn't an actual issue with the project. meta is generally used for issues relating to the repository itself on GitHub, for example relating to this contributor guide.