...
When you’ve identified an issue you want to work on, assign it to yourself, or message us on the Besu Discord and we’ll assign it to you.
Contribution workflow
The Besu documentation uses a docs-as-code approach, meaning documentation contribution workflow consists of forking repositories and submitting is created using the same tools as code. The contribution workflow involves proposing changes to the docs by creating forks and pull requests (PRs) on the documentation GitHub repository. This facilitates social contributionopen contributions, easy testing, and peer review.
To contribute changes:
Fork the Besu documentation repository in which you want to make a change.
Clone your fork to your computer.
git clone [--recursive]<FORKED-REPO>
git remote add upstream <ORIGINAL-REPO>
Create and checkout a topic branch, naming it appropriately. We recommend using the issue number and short description, which is a reminder to fix only one issue in a PR. For example,
183-doc-cli-option
.git checkout -b <ISSUE-NUM>-<ISSUE-DESC>
Open the Besu documentation repository in a text editor of your choice , (for example IntelliJ, and , VS Code) and make your changes. Refer to the MkDocs and Markdown guide and the documentation style guide when making documentation changes.
Preview your changes with MkDocslocally to check that the changes render correctly.
Add and commit your changes, using a clear commit message. Make sure to add a DCO message to each commit. Push your changes to your remote fork (usually named
origin
).git add *
git commit -m "<COMMIT-MESSAGE>"
git push origin
Navigate to the original Besu documentation repository, and you’ll see a banner prompting you to create a PR with your recent changes. Create a PR, filling out the description according to the template. Remember to link the issue that the PR fixes in the description.
fixes #<ISSUE-NUM>
The bottom of the PR page displays a list of checks that verify links, Markdown syntax, and more. If you have any errors, make any required changes to your PR, repeating steps 5-7. If you want to include a new word that causes a spell check error, you can add that word to the
project-words.txt
file.In the right sidebar of your PR, select the reviewer(s) who should review your PR (typically the original issue raiser). If you don’t know who to choose or can’t because you’re not a maintainer yet, select the reviewers listed by GitHub or keep the default value.
Make any required changes to your PR based on reviewer feedback, repeating steps 5-7.
After your PR is validated, all checks have passed, and your branch has no conflicts with the target branch, you can merge your PR. You can delete the topic branch after merging your PR.
...