1
0
Fork 0
mirror of https://github.com/kdeldycke/awesome-falsehood.git synced 2024-11-20 11:35:56 -05:00
falsehood/CONTRIBUTING.md
2020-01-18 12:32:07 +01:00

117 lines
3.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Contributing
Your contributions are always welcome! Here are some guidelines.
## Good Candidates
Before contributing, make sure the new link you'd like to add is a good
candidate.
Here is a non-restrictive list of items which are good candidates for inclusion
in this awesome list.
### Falsehood Articles
Articles following the *falsehood* scheme are prime candidates for inclusion in
this awesome list.
These articles starts with the hypothesis that developers have a naive, simple
view of the subject at hand. Then proceed to list a set of candid assumptions
that might be held by the programmers. Each one is intentionally false, and
in their best form illustrated by a counter-example.
A list of falsehood is crafted as a progression that is designed to refine
concepts. Having read the whole list of falsehood, the reader should possess a
global, if not complete, overview of the domain being targeted by the article,
including most, if not all, its pitfalls, edges-cases and inconsistencies.
Sometimes, these kind of articles might provoke an emotional reaction and cause
flipping table. `(╯°□°)╯︵ ┻━┻` Because, the world is messy. Discovering the
complexity of a domain that is simple in appearance will lead to
frustrations. This is the sign of a great candidate for that list!
Articles featuring items that are applicable to one product (or a service) and
one only can't be considered as generic enough and should be avoided.
### Libraries
Programming libraries or modules are good candidates too, if they solve or
reduce the complexities pointed to by the *falsehood* articles above.
That way we can put back tables in place. `┬─┬ ( ゜-゜ノ)`
### Data Structures
Data models and structures generic enough to cover and address most of the
falsehoods are also welcome in this page.
## Pull-Request and Issue
- Search past and current issues and pull-requests for previous suggestions
before making a new one, as yours may be a duplicate or a work in progress.
- Only one list item per commit.
- Only one commit per pull-request. Always squash commits after applying
changes.
- Check your spelling and grammar.
- Remove any trailing whitespaces.
- Use spaces, no tabs, for indention.
- Send a pull-request with the reason why the linked resource is awesome.
## Linting
First and foremost, have your pull-request pass the [official Awesome List's
linter](https://github.com/sindresorhus/awesome-lint). No extra work is
required here as it is [already integrated by the way of GitHub
actions](./.github/workflows/).
To run the linter locally, do:
```
$ npm install --global awesome-lint
$ awesome-lint
```
## Additional rules
Here are some formatting style not enforced by the linter (yet), which are
specific to this awesome list.
- Cut long lines of text after 80 characters. Only exception is to let Markdown
content be properly rendered.
- If one of these rule conflict with the linter, the linter's rule should takes
precedence. Apply it.
## List items
- Link title must be [title-cased](http://titlecapitalization.com), AP style.
- Link title must be stripped out of the "*Programmers believe*" part to keep
it compact (we all know the scheme).
- URL must use HTTPs protocol if available.
- Keep descriptions concise, maximum number of characters is 350.
## Sections
- Sections must be alphabetically sorted.
- Add a section if needed.
- Eventually add a description to the section.