on master help sign in
Add PR template and contribution guidelines
commitfd80453a3a253e1fb67bd8f4eb76e4fa6c14456e authorNoémi Ványi <sitbackandwait@gmail.com> dateTue 30 Jun 2020, 23:41 (6 years ago) parent754accb
2 files changed+74
CONTRIBUTING.md+49 PULL_REQUEST_TEMPLATE.md+25
CONTRIBUTING.mdnew file+49
@@ -0,0 +1,49 @@
1+# How to contribute
2+
3+## Resources in the documentation
4+
5+* [Development quickstart](http://asciimoo.github.io/searx/dev/contribution_guide.html)
6+* [Contribution guide](http://asciimoo.github.io/searx/dev/contribution_guide.html)
7+
8+## Submitting PRs
9+
10+Please follow the provided PR template when writing a description for your changes.
11+
12+Do not take criticism personally. When you get feedback, it is about your work,
13+not your character, personality, etc. Keep in mind we all want to make the project better.
14+
15+When something is not clear, please ask questions to clear things up.
16+
17+If you would like to introduce a big architectural changes or do a refactoring
18+either in the codebase or the development tools, please open an issue with a proposal
19+first. This way we can think together about the problem and probably come up
20+with a better solution.
21+
22+## Coding conventions and guidelines
23+
24+### Commit messages
25+
26+* Always write descriptive commit messages ("fix bug" is not acceptable).
27+* Use the present tense ("Add feature" not "Added feature").
28+* Use the imperative mood ("Move cursor to..." not "Moves cursor to...").
29+* Limit the first line to 72 characters or less.
30+* Include the number of the issue you are fixing.
31+
32+### Coding guidelines
33+
34+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.
35+
36+Furthermore, follow the Clean code conventions. The most important
37+in this project are the following rules:
38+
39+* Simpler is better. [KISS principle](https://en.wikipedia.org/wiki/KISS_principle)
40+* Be consistent.
41+* Every function must do one thing.
42+* Use descriptive names for functions and variables.
43+* Always look for the root cause.
44+* Keep configurable data high level.
45+* Avoid negative conditionals.
46+* Prefer fewer arguments.
47+* Do not add obvious comment to code.
48+* Do not comment out code, just delete lines.
49+
PULL_REQUEST_TEMPLATE.mdnew file+25
@@ -0,0 +1,25 @@
1+## What does this PR do?
2+
3+<!-- MANDATORY -->
4+
5+<!-- explain the changes in your PR, algorithms, design, architecture -->
6+
7+## Why is this change important?
8+
9+<!-- MANDATORY -->
10+
11+<!-- explain the motivation behind your PR -->
12+
13+## How to test this PR locally?
14+
15+<!-- commands to run the tests or instructions to test the changes-->
16+
17+## Author's checklist
18+
19+<!-- additional notes for reviewiers -->
20+
21+## Related issues
22+
23+<!--
24+Closes #234
25+-->