Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
38 lines (28 loc) · 2.38 KB

CONTRIBUTING.md

File metadata and controls

38 lines (28 loc) · 2.38 KB

Contribution Guidelines

These guidelines are referenced from awesome-quantified-self's contributing guidelines.

Please note that this project is released with a Contributor Code of Conduct, and is licensed by CC0 1.0 Universal.

By participating in this project you agree to abide by its terms.

Adding an item to the awesome list

To add something to the list, create a PR that adheres to the following guidelines:

New item guidelines

  • Search previous suggestions before making a new one, as yours may be a duplicate.
  • For suggested packages, they should be tested and documented.
  • Toy/ BATA (Build and throw away) projects are not allowed.
  • Side projects are ok to be added if they help users to achieve a use case (they should be under Community Tools).
  • Community Tools / DX Tools submissions must include a link to the open-source project repository.
  • Community Tools / DX Tools submissions must include testimonial links from real users (X/LinkedIn/Reddit, etc.) who are not the project creator. There needs to be users advocating for the use of your project; otherwise, it does not make sense why it should be on the awesome list.
  • Community Tools / DX Tools submissions that are not open-source will be closed.
  • For items, use the following format: [resource](link) - Description.
  • Use title-casing (AP style).
  • New categories, or improvements to the existing categorization are welcome.
  • Additions should be added to the bottom of the relevant category.
  • Link to the GitHub repo, not npmjs.com.
  • Keep descriptions short and simple, but descriptive.
  • Start the description with a capital and end with a full stop/period.

PR guidelines

  • Before you create the PR, please run npx awesome-lint on your changes. This is a plugin created by the father of all awesome-lists. If your changes introduces new error(s) — please fix those before creating the PR. This helps the maintainer to reduce menial work.
  • The pull request should have a meaningful title and include a link to the package / resource and why it's awesome.
  • For Community Tools / DX Tools pull requests, include:
    • Open-source project repository link.
    • Testimonial links from users (not the creator) on X/LinkedIn/Reddit (or similar).

Thank you for your suggestions!