If you add a new feature, demonstrate its awesomeness under `usage.rst`!įirst create a (). If you start a new section, add two blank lines before and one blank lineĪfter the header, except if two headers follow immediately after each other: `CONTRIBUTING.md`) is written in Markdown, as GitHub doesn't support `.rst`įiles for some of their features (e.g. GitHub-related project documentation (e.g. Project-related documentation is written in Write your asserts as `expected = actual` to line them up nicely: Similar to ()īut uses static analysis more, and we follow the # But for function, method and module, there should be no blank lines # separate following codes (according to PEP257). # After closing class docstring, there should be one blank line to These are written in doctest format, and should illustrate how to math:: X(e^Īnd even use a Greek symbol like :math:`\omega` inline. Notes about the implementation algorithm (if needed). ``(N,) ndarray`` or ``array_like``.Ĭhoices in brackets, default first when optional.Įxplanation of anonymous return value of type ``type``.Įxplanation of return value named `describe`. ``int``), or describe the type of the variable in moreĭetail, e.g.
The type above can either refer to an actual Python type Refer toĪrray_like means all those objects - lists, nested lists, etc. Several sentences providing an extended description. We have a summary line starting the `"""` block:ĭef foo(var1, var2, *args, long_var_name='hi', **kwargs): Avoid breaking backwards compatibility. Once you've addressed review feedback, make sure to bump the pull request with Won't get any feedback until it's green unless you ask for it. Missing tests or documentation will not be merged. _Always_ add tests and docs for your code. Whether you prefer to rebase on master or merge master into yourīranch, do whatever is more comfortable for you.
Since we squash on merge, it's up to you how you handle updates to the masterīranch. Try to limit each pull request to **_one_** change only. No contribution is too small! Please submit as many fixes for typos and Don't be afraid to open half-finished PRs, and ask This document intends to make contribution more accessible by codifying tribal Like _you_ who make it such a great tool for everyone. First off, thank you for considering contributing to `drf-user`! It's people
0 kommentar(er)
