mirror of
https://github.com/sindresorhus/awesome.git
synced 2024-12-29 12:25:26 +00:00
3.6 KiB
3.6 KiB
[Insert URL to the list here]
[Explain what this list is about and why it should be included here]
By submitting this pull request I confirm I've read and complied with the below requirements.
Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.
- I have read and understood the contribution guidelines and the instructions for creating a list.
- This pull request has a descriptive title.
For example,Add Name of List
, notUpdate readme.md
orAdd awesome list
. - The entry in the Awesome list should:
- Include a short description about the project/theme of the list. It should not describe the list itself.
Example:- [Fish](…) - User-friendly shell.
, not- [Fish](…) - Resources for Fish.
. - Be added at the bottom of the appropriate category.
- Include a short description about the project/theme of the list. It should not describe the list itself.
- The list I'm submitting complies with these requirements:
- Has been around for at least 30 days.
That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent. - It's the result of hard work and the best I could possibly produce.
- Non-generated Markdown file in a GitHub repo.
- Includes a succinct description of the project/theme at the top of the readme. (Example)
- The repo should have
awesome-list
&awesome
as GitHub topics. I encourage you to add more relevant topics. - Not a duplicate.
- Only has awesome items. Awesome lists are curations of the best, not everything.
- Includes a project logo/illustration whenever possible.
- Either fullwidth or placed at the top-right of the readme. (Example)
- The image should link to the project website or any relevant website.
- The image should be high-DPI. Set it to maximum half the width of the original image.
- Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
- Includes the Awesome badge.
- Should be placed on the right side of the readme heading.
- Should link back to this list.
- Has a Table of Contents section.
- Should be named
Contents
, notTable of Contents
. - Should be the first section in the list.
- Should only have one level of sub-lists, preferably none.
- Should be named
- Has an appropriate license.
- That means something like CC0, not a code licence like MIT, BSD, Apache, etc.
- If you use a license badge, it should be SVG, not PNG.
- Has contribution guidelines.
- The file should be named
contributing.md
. Casing is up to you.
- The file should be named
- Has consistent formatting and proper spelling/grammar.
- The link and description are separated by a dash.
Example:- [AVA](…) - JavaScript test runner.
- The description starts with an uppercase character and ends with a period.
- Drop all the
A
/An
prefixes in the descriptions. - Consistent and correct naming. For example,
Node.js
, notNodeJS
ornode.js
.
- The link and description are separated by a dash.
- Doesn't include a Travis badge.
You can still use Travis for list linting, but the badge has no value in the readme.
- Has been around for at least 30 days.
- Go to the top and read it again.