Merge pull request #2038 from kvch/contributing-to-searx

Add PR template and contribution guidelines
This commit is contained in:
Adam Tauber 2020-07-10 23:42:55 +02:00 committed by GitHub
commit 5165962fdc
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 74 additions and 0 deletions

49
CONTRIBUTING.md Normal file
View File

@ -0,0 +1,49 @@
# How to contribute
## Resources in the documentation
* [Development quickstart](http://asciimoo.github.io/searx/dev/contribution_guide.html)
* [Contribution guide](http://asciimoo.github.io/searx/dev/contribution_guide.html)
## Submitting PRs
Please follow the provided PR template when writing a description for your changes.
Do not take criticism personally. When you get feedback, it is about your work,
not your character, personality, etc. Keep in mind we all want to make the project better.
When something is not clear, please ask questions to clear things up.
If you would like to introduce a big architectural changes or do a refactoring
either in the codebase or the development tools, please open an issue with a proposal
first. This way we can think together about the problem and probably come up
with a better solution.
## Coding conventions and guidelines
### Commit messages
* Always write descriptive commit messages ("fix bug" is not acceptable).
* Use the present tense ("Add feature" not "Added feature").
* Use the imperative mood ("Move cursor to..." not "Moves cursor to...").
* Limit the first line to 72 characters or less.
* Include the number of the issue you are fixing.
### Coding guidelines
As a Python project, we must follow [PEP 8](https://www.python.org/dev/peps/pep-0008/) and [PEP 20](https://www.python.org/dev/peps/pep-0020/) guidelines.
Furthermore, follow the Clean code conventions. The most important
in this project are the following rules:
* Simpler is better. [KISS principle](https://en.wikipedia.org/wiki/KISS_principle)
* Be consistent.
* Every function must do one thing.
* Use descriptive names for functions and variables.
* Always look for the root cause.
* Keep configurable data high level.
* Avoid negative conditionals.
* Prefer fewer arguments.
* Do not add obvious comment to code.
* Do not comment out code, just delete lines.

25
PULL_REQUEST_TEMPLATE.md Normal file
View File

@ -0,0 +1,25 @@
## What does this PR do?
<!-- MANDATORY -->
<!-- explain the changes in your PR, algorithms, design, architecture -->
## Why is this change important?
<!-- MANDATORY -->
<!-- explain the motivation behind your PR -->
## How to test this PR locally?
<!-- commands to run the tests or instructions to test the changes-->
## Author's checklist
<!-- additional notes for reviewiers -->
## Related issues
<!--
Closes #234
-->