|
| 1 | +.. _contributing: |
| 2 | + |
| 3 | +Support and Contributing |
| 4 | +======================== |
| 5 | + |
| 6 | +Support |
| 7 | +------- |
| 8 | +If you are stuck with a problem using Dedoc, please do get in touch at our `Issues <https://github.com/ispras/dedoc/issues>`_ (recommend) |
| 9 | +or `Dedoc Chat <https://t.me/dedoc_chat>`_. The developers are willing to help. |
| 10 | + |
| 11 | +You can save time by following this procedure when reporting a problem: |
| 12 | + |
| 13 | + * Do try to solve the problem on your own first. Read the documentation, including using the search feature, index and reference documentation. |
| 14 | + |
| 15 | + * Search the issue archives to see if someone else already had the same problem. |
| 16 | + |
| 17 | + * Before writing, try to create a minimal example that reproduces the problem (with the api parameters and files you used). |
| 18 | + You’ll get the fastest response if you can send just a handful of lines of code that show what isn’t working. |
| 19 | + |
| 20 | + |
| 21 | +Contributing Rules |
| 22 | +------------------ |
| 23 | + |
| 24 | + * To add new features to the project repository yourself, you should follow |
| 25 | + the `general contributing rules of github <https://github.com/firstcontributions/first-contributions>`_. |
| 26 | + In your Pull Request, set `develop` as the target branch. |
| 27 | + |
| 28 | + * We recommend using `Pycharm IDE` and `virtualenv` package for development. |
| 29 | + |
| 30 | + * It is strongly recommended to use in development those versions of libraries that are already used in the project. |
| 31 | + Thus, it is necessary to avoid using an excessive number of libraries with the same functionality in the project. |
| 32 | + This leads to the growth of the dedoc library image. |
| 33 | + |
| 34 | + * We strongly recommend using the already used ML library `torch` in development. For example, |
| 35 | + using `tensorflow` library instead of `torch` is justified only in case of extreme necessity. |
| 36 | + |
| 37 | + * If you add new functionality to dedoc, be sure to add python `unitests` to test the added functionality |
| 38 | + (you can add api tests in `tests/api_tests <https://github.com/ispras/dedoc/blob/master/tests/api_tests>`_, |
| 39 | + you can add unit tests in `tests/unit_tests <https://github.com/ispras/dedoc/blob/master/tests/unit_tests>`_). |
| 40 | + These tests are run automatically in the Continuous Integration pipeline. |
| 41 | + |
| 42 | + * Before each commit, check the code style using the automatic checker using the `flake8` library. |
| 43 | + Instructions for using flake8 are provided here :ref:using_flake8`. |
| 44 | + |
| 45 | + * We recommend setting up pre-commit for convenience and speeding up development according to the instructions :ref:`using_precommit` . |
| 46 | + This will run a style check of the changed code with each commit. |
| 47 | + |
| 48 | + * In case of any change in the online documentation of the project (for example, when adding a new api parameter), |
| 49 | + be sure to check locally that the changed documentation is successfully built and looks as expected. |
| 50 | + Building online documentation using `sphinx` is described here :ref:`check_documentation`. |
| 51 | + |
| 52 | +.. toctree:: |
| 53 | + :maxdepth: 1 |
| 54 | + |
| 55 | + using_flake8 |
| 56 | + using_precommit |
| 57 | + check_documentation |
| 58 | + |
| 59 | + |
| 60 | + |
| 61 | + |
0 commit comments