zhangyiss/the-littlest-jupyterhub
1
0
Fork 0
mirror of https://github.com/jupyterhub/the-littlest-jupyterhub.git synced 2025-12-18 21:54:05 +08:00
Code Issues Packages Projects Releases Wiki Activity

adopt myst

Browse Source 
run rst2myst, with minimal manual formatting fixes
This commit is contained in:
Min RK
2023-03-27 09:31:02 +02:00
parent a5e72046ab
commit de36cfc116
96 changed files with 4131 additions and 4491 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
docs/contributing/code-review.md Normal file
View File

@@ -0,0 +1,46 @@
(contributing-code-review)=
# Code Review guidelines
This document outlines general guidelines to follow when you are making
or reviewing a Pull Request.
## Have empathy
We recommend reading [On Empathy & Pull Requests](https://slack.engineering/on-empathy-pull-requests-979e4257d158)
and [How about code reviews](https://slack.engineering/how-about-code-reviews-2695fb10d034)
to learn more about being empathetic in code reviews.
## Write documentation
If your pull request touches any code, you must write or update documentation
for it. For this project, documentation is a lot more important than the code.
If a feature is not documented, it does not exist. If a behavior is not documented,
it is a bug.
Do not worry about having perfect documentation! Documentation improves over
time. The requirement is to have documentation before merging a pull request,
not to have _perfect_ documentation before merging a pull request. If you
are new and not sure how to add documentation, other contributors will
be happy to guide you.
See {ref}`contributing/docs` for guidelines on writing documentation.
## Write tests
If your pull request touches any code, you must write unit or integration tests
to exercise it. This helps validate & communicate that your pull request works
the way you think it does. It also makes sure you do not accidentally break
other code, and makes it harder for future pull requests to break the code
added in your pull request.
Since TLJH is a distribution that integrates many JupyterHub components,
integration tests provide more value for effort than unit tests do. Unit
tests are easier to write & faster to run, so if the code being changed
feels exhaustively unit-testable, write unit tests too. When in doubt,
add more tests.
If you are unsure what kind of tests to add for your pull request, other
contributors to the repo will be happy to help guide you!
See {ref}`contributing/tests` for guidelines on writing tests.