Contributions are welcome, and they are greatly appreciated! Every little bit helps, and credit will always be given.
Nothing easier!
Fork and clone the repository, then:
cd mkdocstrings
make setupThat's it!
You now have the dependencies installed.
Run make help to see all the available actions!
As usual:
- create a new branch:
git checkout -b feature-or-bugfix-name - edit the code and/or the documentation
If you updated the documentation or the project dependencies:
- run
make docs-regen - run
make docs-serve, go to http://localhost:8000 and check that everything looks good
Before committing:
- run
make formatto auto-format the code - run
make checkto check everything (fix any warning) - run
make testto run the tests (fix any issue) - follow our commit message convention
If you are unsure about how to fix or ignore a warning, just let the continuous integration fail, and we will help you during review.
Don't bother updating the changelog, we will take care of this.
Commits messages must follow the Angular style:
<type>[(scope)]: Subject
[Body]
Scope and body are optional. Type can be:
build: About packaging, building wheels, etc.chore: About packaging or repo/files management.ci: About Continuous Integration.docs: About documentation.feat: New feature.fix: Bug fix.perf: About performance.refactor: Changes which are not features nor bug fixes.style: A change in code style/format.tests: About tests.
Subject (and body) must be valid Markdown. If you write a body, please add issues references at the end:
Body.
References: #10, #11.
Fixes #15.
Link to any related issue in the Pull Request message.
During review, we recommend using fixups:
# SHA is the SHA of the commit you want to fix
git commit --fixup=SHAOnce all the changes are approved, you can squash your commits:
git rebase -i --autosquash masterAnd force-push:
git push -fIf this seems all too complicated, you can push or force-push each new commit, and we will squash them ourselves if needed, before merging.