We have built up detailed documentation of the *settings* and the *engines* over the past few years. However, this documentation was still spread over various chapters and was difficult to navigate in its entirety. This patch rearranges the Settings & Engines documentation for better readability. To review new ordered docs:: make docs.clean docs.live Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
5.3 KiB
How to contribute
Prime directives: Privacy, Hackability
SearXNG has two prime directives, privacy-by-design and hackability . The hackability comes in three levels:
- support of search engines
- plugins to alter search behaviour
- hacking SearXNG itself
Note the lack of "world domination" among the directives. SearXNG has no intention of wide mass-adoption, rounded corners, etc. The prime directive "privacy" deserves a separate chapter, as it's quite uncommon unfortunately.
Privacy-by-design
SearXNG was born out of the need for a privacy-respecting search tool which can be extended easily to maximize both, its search and its privacy protecting capabilities.
A few widely used features work differently or turned off by default or not implemented at all as a consequence of privacy-by-design.
If a feature reduces the privacy preserving aspects of searx, it should be switched off by default or should not implemented at all. There are plenty of search engines already providing such features. If a feature reduces the protection of searx, users must be informed about the effect of choosing to enable it. Features that protect privacy but differ from the expectations of the user should also be explained.
Also, if you think that something works weird with searx, it's might be because of the tool you use is designed in a way to interfere with the privacy respect. Submitting a bugreport to the vendor of the tool that misbehaves might be a good feedback to reconsider the disrespect to its customers (e.g. GET
vs POST
requests in various browsers).
Remember the other prime directive of SearXNG is to be hackable, so if the above privacy concerns do not fancy you, simply fork it.
Happy hacking.
Code
Create good commits!
- Structural split of changes
- Conventional Commits
- Git Commit Good Practice
- some like to use: gitmoji
- not yet active: Semantic PR
In order to submit a patch, please follow the steps below:
Follow coding conventions.
- PEP8 standards apply, except the convention of line length
- Maximum line length is 120 characters
The cardinal rule for creating good commits is to ensure there is only one logical change per commit / read Structural split of changes
Check if your code breaks existing tests. If so, update the tests or fix your code.
If your code can be unit-tested, add unit tests.
Add yourself to the
AUTHORS.rst
file.Choose meaningful commit messages, read Conventional Commits
<type>[optional scope]: <description> [optional body] [optional footer(s)]
Create a pull request.
For more help on getting started with SearXNG development, see devquickstart
.
Translation
Translation currently takes place on weblate <translation>
.
Documentation
The reST sources
has been moved from gh-branch
into master
(docs
).
The documentation is built using Sphinx. So in order to be able to generate the required files, you have to install it on your system. Much easier, use our makefile
.
Here is an example which makes a complete rebuild:
make docs.clean docs.html
$ ...
The HTML pages are in dist/docs.
live build
docs.clean
It is recommended to assert a complete rebuild before deploying (use docs.clean
).
Live build is like WYSIWYG. If you want to edit the documentation, its recommended to use. The Makefile target docs.live
builds the docs, opens URL in your favorite browser and rebuilds every time a reST file has been changed.
make docs.live
$ ...
The HTML pages are in dist/docs.
... Serving on http://0.0.0.0:8000
... Start watching changes
Live builds are implemented by sphinx-autobuild. Use environment $(SPHINXOPTS)
to pass arguments to the sphinx-autobuild command. Except option --host
(which is always set to 0.0.0.0
) you can pass any argument. E.g to find and use a free port, use:
SPHINXOPTS="--port 0" make docs.live
$ ...
... Serving on http://0.0.0.0:50593
...
deploy on github.io
To deploy documentation at github.io <.>
use Makefile target make
docs.gh-pages
, which builds the documentation and runs all the needed git add, commit and push:
make docs.clean docs.gh-pages $