Docs: Improve release-process.md formatting #17981

This PR will improve release-process.md formatting by:

1. Updating Markdown syntax to the latest one
2. Adding syntax highlighting to all code blocks
3. Aligning the text up to 80 column guideline (before it was following different guidelines, sometime 80, sometime 90, etc.)
4. Small grammar improvements here and there

The Lint job of Travis CI just failed with this issue:

test/lint/lint-shell.sh:44: desriptor  ==> descriptor
^ Warning: codespell identified likely spelling errors. Any false positives? Add them to the list of ignored words in test/lint/lint-spelling.ignore-words.txt
This diff appears to have added new lines with trailing whitespace.
The following changes were suspected:
diff --git a/doc/release-process.md b/doc/release-process.md
@@ -13,3 +11,4 @@ Release Process
+* Update [`bips.md`](bips.md) to account for changes since the last release
+* Update version in [`configure.ac`](/configure.ac)
@@ -30,13 +27,25 @@ Release Process
+and `m_assumed_chain_state_size` with the current size plus some overhead
@@ -354,2 +401,5 @@ bitcoin.org (see below for bitcoin.org update instructions).
+        - Click "Request builds" for every new release on this branch
^---- failure generated from test/lint/lint-whitespace.sh

It's a false positive? This PR just changes a .md file, how could this be possibile?

This diff appears to have added new lines with trailing whitespace. @giulio92 From the log. The problem is the trailing whitespace you've introduced.

This diff appears to have added new lines with trailing whitespace.

@giulio92 From the log. The problem is the trailing whitespace you've introduced.

I understand.

Those trailing whitespace represent a line break in Markdown syntax (reference) and I placed them to place the "Note:" section below the text it is referred to

Before: Some text Note: some note

After: Some text Note: some note

In my opinion it looks better, should I remove the two trailing whitespaces?

@hebasto regarding comments: one and two I aligned the text up to 80 column guideline to make it look more readable while editing the .md file

@hebasto regarding comments: one and two I aligned the text up to 80 column guideline to make it look more readable while editing the .md file

Our project style guideline does not have such requirements. Though, it seems good be able not using horizontal scrolling on the GitHub while (re)viewing the code and diffs. It implies the maximum of line length about 118 characters.

I don't think these style changes warrant the review effort for an internal process document.

Agree with @jonatack. To ease review, consider splitting it up into narrowly-constructed commits or separate pull requests. E.g. the syntax highlighting changes which would be trivial to review, particularly if you limited your changes to the bounds around the code.

While already knowing that this document is something internal, I also think that, being Bitcoin an open source project, everyone should be able to read and understand how things works (even out of curiosity), and the changes of this PR goes in the direction of improving the formatting of the description of the release process so that everyone and not just who is the "release master" understands.

If we think that merging this changes is not useful I would prefer to close the PR now instead of starting a process of splitting the changes in separate commits and PRs

@giulio92, FWIW here are several in-depth articles that you might find useful for contributing. This is only my opinion, but review time is valuable and scarce and more value is added by testing/reviewing important PRs and issues, or handling good first issues where help is actively requested. Cheers :)

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #18125 (doc: remove PPA note from release-process.md by fanquake)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

Closing this as it seems it does not bring any value

Thanks @giulio92, as Bitcoin is currently review-constrained, I encourage you to contribute but with attention to how you might reduce the review burden of your contributions, e.g. by making them more narrowly tailored.