Page History

...

The Besu documentation uses a docs-as-code approach, meaning documentation 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 open contributions, testing, and review.

...

1. Fork the Besu documentation repository.

2. Clone your fork to your computer.

   • git clone <FORKED-REPO>

3. Add an upstream remote.

   • git remote add upstream <ORIGINAL-REPO>

4. 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>

5. Open the Besu documentation repository in a text editor of your choice (for example, VS Code) and and make your changes. Refer Make sure to follow the style guidelines and Markdown guide and the style guide when making documentation changesformat your Markdown correctly. If you delete, rename, or move a documentation file, make sure to add a redirect.

6. Preview your changes locally to check that the changes render correctly.

7. 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

8. 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>

9. 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.

10. 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.

11. Make any required changes to your PR based on reviewer feedback, repeating steps 5-7.

12. 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.

...