mirror of https://github.com/searx/searx
2 changed files with 74 additions and 0 deletions
@ -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. |
|||
|
@ -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 |
|||
--> |
Loading…
Reference in new issue