contribution_guide.rst 4.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154
  1. .. _how to contribute:
  2. =================
  3. How to contribute
  4. =================
  5. Prime directives: Privacy, Hackability
  6. ======================================
  7. Searx has two prime directives, **privacy-by-design and hackability** . The
  8. hackability comes in three levels:
  9. - support of search engines
  10. - plugins to alter search behaviour
  11. - hacking searx itself
  12. Note the lack of "world domination" among the directives. Searx has no
  13. intention of wide mass-adoption, rounded corners, etc. The prime directive
  14. "privacy" deserves a separate chapter, as it's quite uncommon unfortunately.
  15. Privacy-by-design
  16. -----------------
  17. Searx was born out of the need for a **privacy-respecting** search tool which
  18. can be extended easily to maximize both, its search and its privacy protecting
  19. capabilities.
  20. A few widely used features work differently or turned off by default or not
  21. implemented at all **as a consequence of privacy-by-design**.
  22. If a feature reduces the privacy preserving aspects of searx, it should be
  23. switched off by default or should not implemented at all. There are plenty of
  24. search engines already providing such features. If a feature reduces the
  25. protection of searx, users must be informed about the effect of choosing to
  26. enable it. Features that protect privacy but differ from the expectations of
  27. the user should also be explained.
  28. Also, if you think that something works weird with searx, it's might be because
  29. of the tool you use is designed in a way to interfere with the privacy respect.
  30. Submitting a bugreport to the vendor of the tool that misbehaves might be a good
  31. feedback to reconsider the disrespect to its customers (e.g. ``GET`` vs ``POST``
  32. requests in various browsers).
  33. Remember the other prime directive of searx is to be hackable, so if the above
  34. privacy concerns do not fancy you, simply fork it.
  35. *Happy hacking.*
  36. Code
  37. ====
  38. .. _PEP8: https://www.python.org/dev/peps/pep-0008/
  39. In order to submit a patch, please follow the steps below:
  40. - Follow coding conventions.
  41. - PEP8_ standards apply, except the convention of line length
  42. - Maximum line length is 120 characters
  43. - Check if your code breaks existing tests. If so, update the tests or fix your
  44. code.
  45. - If your code can be unit-tested, add unit tests.
  46. - Add yourself to the :origin:`AUTHORS.rst` file.
  47. - Create a pull request.
  48. For more help on getting started with searx development, see :ref:`devquickstart`.
  49. Translation
  50. ===========
  51. Translation currently takes place on :ref:`transifex <translation>`.
  52. .. caution::
  53. Please, do not update translation files in the repo.
  54. .. _contrib docs:
  55. Documentation
  56. =============
  57. .. _Sphinx: http://www.sphinx-doc.org
  58. .. _reST: http://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html
  59. .. sidebar:: The reST sources
  60. has been moved from ``gh-branch`` into ``master`` (:origin:`docs`).
  61. The documentation is built using Sphinx_. So in order to be able to generate
  62. the required files, you have to install it on your system. Much easier, use
  63. our :ref:`makefile`.
  64. Here is an example which makes a complete rebuild:
  65. .. code:: sh
  66. $ make docs-clean docs
  67. ...
  68. The HTML pages are in dist/docs.
  69. .. _make docs-live:
  70. live build
  71. ----------
  72. .. sidebar:: docs-clean
  73. It is recommended to assert a complete rebuild before deploying (use
  74. ``docs-clean``).
  75. Live build is like WYSIWYG. If you want to edit the documentation, its
  76. recommended to use. The Makefile target ``docs-live`` builds the docs, opens
  77. URL in your favorite browser and rebuilds every time a reST file has been
  78. changed.
  79. .. code:: sh
  80. $ make docs-live
  81. ...
  82. The HTML pages are in dist/docs.
  83. ... Serving on http://0.0.0.0:8080
  84. ... Start watching changes
  85. .. _deploy on github.io:
  86. deploy on github.io
  87. -------------------
  88. To deploy documentation at :docs:`github.io <.>` use Makefile target
  89. :ref:`make gh-pages`, which will builds the documentation, clones searx into a sub
  90. folder ``gh-pages``, cleans it, copies the doc build into and runs all the
  91. needed git add, commit and push:
  92. .. code:: sh
  93. $ make docs-clean gh-pages
  94. ...
  95. SPHINX docs --> file://<...>/dist/docs
  96. The HTML pages are in dist/docs.
  97. ...
  98. Cloning into 'gh-pages' ...
  99. ...
  100. cd gh-pages; git checkout gh-pages >/dev/null
  101. Switched to a new branch 'gh-pages'
  102. ...
  103. doc available at --> https://asciimoo.github.io/searx