Enjoying BloodHound Community Edition and found an opportunity to improve our documentation or fix a pesky typo? We'd love your help!
Here are some recommendations to help get you started.
- Peruse the issue tracker on GitHub. This can be a great place to get started as it doesn't require much insider knowledge. Here's a few ideas that could help here.
- Open a bug or feature request
- Help others
- Enhance documentation
- Fix errors or inconsistencies
- Add documents for undocumented capabilities
First, thank you so much for considering a contribution to BloodHound Community Edition. We're very appreciative of anyone who offers to give back to a tool they find useful. It helps make BloodHound better for everyone.
The following are some general guidelines to follow while writing and submitting your PRs. Following these should make merging the PR faster and easier.
Check out our Contributing to Docs article for specifics!
If a Pull Request is being planned, please ensure a GitHub issue has been opened first. The reasons for this are:
- Clear tracking of work related to specific issues
- The change may already be in progress internally
- Validation is needed to ensure the contribution fits the needs and scope of our documentation
Once we have reviewed the issue internally, we will reach out to let you know everything is good to go. In some cases we may also provide feedback or suggest changes to the proposal as needed.
If you have any further questions about opening a Pull Request, please reach out to us in our community slack!
All PR submissions will need to come from a separate branch from main. We recommend creating a personal fork of the BloodHound repo and creating the branch from there. This will allow you more control over your local environment.
Also, please ensure that you are branching off of the latest version of main from the SpecterOps/bloodHound-docs repo. This will ensure everything is built on top of the latest code and also help reduce merge conflicts.
Lastly, we ask that you use brief, but detailed, commit messages when writing your code.
Commit messages should be in conventional commit style as described in the Conventional Commits Guide RFC. Please take some time to review the guidelines in order to format your commits accordingly so that the work passes the associated pull request check.
Adding well formatted and detailed commit messages will help with the review process as it will be easier to see the reasoning and details included in a particular change. Another habit that will help the PR reviewer is authoring smaller, frequent commits as opposed to a giant single commit containing all of your changes.
If you are participating in the review of a PR then you should add yourself to the Reviewers list. It sends appropriate notifications to all reviewers when the PR author requests an additional review after making changes, so be sure to use that button within GitHub when you are ready for an additional look.
It should be noted that the presence of a reviewer on a PR should not dissuade others from also reviewing the PR. The more eyes the better.
If you will no longer be reviewing a PR for some reason, then please try to remember to remove yourself as a Reviewer.