docs: fix documentation broken links and enhance readability

README.md

@@ -1,10 +1,9 @@
 Bitcoin Core integration/staging tree
 =====================================
 
-https://bitcoincore.org
+Visit the [Bitcoin Core website](https://bitcoincore.org) for more information.
 
-For an immediately usable, binary version of the Bitcoin Core software, see
-https://bitcoincore.org/en/download/.
+For a ready-to-use binary version of the Bitcoin Core software, please visit [Bitcoin Core Downloads](https://bitcoincore.org/en/download/).
 
 What is Bitcoin Core?
 ---------------------
@@ -18,8 +17,8 @@ Further information about Bitcoin Core is available in the [doc folder](/doc).
 License
 -------
 
-Bitcoin Core is released under the terms of the MIT license. See [COPYING](COPYING) for more
-information or see https://opensource.org/licenses/MIT.
+Bitcoin Core is released under the terms of the MIT license. For more information,
+see the [COPYING](COPYING) file or visit the [MIT License page](https://opensource.org/licenses/MIT).
 
 Development Process
 -------------------
@@ -28,18 +27,18 @@ The `master` branch is regularly built (see `doc/build-*.md` for instructions) a
 completely stable. [Tags](https://github.com/bitcoin/bitcoin/tags) are created
 regularly from release branches to indicate new official, stable release versions of Bitcoin Core.
 
-The https://github.com/bitcoin-core/gui repository is used exclusively for the
-development of the GUI. Its master branch is identical in all monotree
-repositories. Release branches and tags do not exist, so please do not fork
-that repository unless it is for development reasons.
+The [Bitcoin Core GUI repository](https://github.com/bitcoin-core/gui) is used exclusively for
+GUI development.Its master branch is identical across all monotree repositories.
+Release branches and tags do not exist, so please do not fork that repository
+unless it is for development purposes.
 
 The contribution workflow is described in [CONTRIBUTING.md](CONTRIBUTING.md)
 and useful hints for developers can be found in [doc/developer-notes.md](doc/developer-notes.md).
 
 Testing
 -------
 
-Testing and code review is the bottleneck for development; we get more pull
+Testing and code review are critical bottlenecks in development; we receive more pull
 requests than we can review and test on short notice. Please be patient and help out by testing
 other people's pull requests, and remember this is a security-critical project where any mistake might cost people
 lots of money.
@@ -51,8 +50,7 @@ submit new unit tests for old code. Unit tests can be compiled and run
 (assuming they weren't disabled in configure) with: `make check`. Further details on running
 and extending unit tests can be found in [/src/test/README.md](/src/test/README.md).
 
-There are also [regression and integration tests](/test), written
-in Python.
+There are also [regression and integration tests](/test), written in Python.
 These tests can be run (if the [test dependencies](/test) are installed) with: `test/functional/test_runner.py`
 
 The CI (Continuous Integration) systems make sure that every pull request is built for Windows, Linux, and macOS,

doc/design/multiprocess.md

@@ -32,13 +32,13 @@ BITCOIND=bitcoin-node test/functional/test_runner.py
 
 The configure script will pick up settings and library locations from the depends directory, so there is no need to pass `--enable-multiprocess` as a separate flag when using the depends system (it's controlled by the `MULTIPROCESS=1` option).
 
-Alternately, you can install [Cap'n Proto](https://capnproto.org/) and [libmultiprocess](https://github.com/chaincodelabs/libmultiprocess) packages on your system, and just run `./configure --enable-multiprocess` without using the depends system. The configure script will be able to locate the installed packages via [pkg-config](https://www.freedesktop.org/wiki/Software/pkg-config/). See [Installation](https://github.com/chaincodelabs/libmultiprocess#installation) section of the libmultiprocess readme for install steps. See [build-unix.md](build-unix.md) and [build-osx.md](build-osx.md) for information about installing dependencies in general.
+Alternately, you can install [Cap'n Proto](https://capnproto.org/) and [libmultiprocess](https://github.com/chaincodelabs/libmultiprocess) packages on your system, and just run `./configure --enable-multiprocess` without using the depends system. The configure script will be able to locate the installed packages via [pkg-config](https://www.freedesktop.org/wiki/Software/pkg-config/). See [Installation](https://github.com/chaincodelabs/libmultiprocess#installation) section of the libmultiprocess readme for install steps. See [build-unix.md](../build-unix.md) and [build-osx.md](../build-osx.md) for information about installing dependencies in general.
 
 ## IPC implementation details
 
 Cross process Node, Wallet, and Chain interfaces are defined in
-[`src/interfaces/`](../src/interfaces/). These are C++ classes which follow
-[conventions](developer-notes.md#internal-interface-guidelines), like passing
+[`src/interfaces/`](../../src/interfaces/). These are C++ classes which follow
+[conventions](../developer-notes.md#internal-interface-guidelines), like passing
 serializable arguments so they can be called from different processes, and
 making methods pure virtual so they can have proxy implementations that forward
 calls between processes.
@@ -58,7 +58,7 @@ actual serialization and socket communication.
 As much as possible, calls between processes are meant to work the same as
 calls within a single process without adding limitations or requiring extra
 implementation effort. Processes communicate with each other by calling regular
-[C++ interface methods](../src/interfaces/README.md). Method arguments and
+[C++ interface methods](../../src/interfaces/README.md). Method arguments and
 return values are automatically serialized and sent between processes. Object
 references and `std::function` arguments are automatically tracked and mapped
 to allow invoked code to call back into invoking code at any time, and there is

doc/developer-notes.md

@@ -325,7 +325,7 @@ Recommendations:
 - Avoid linking to external documentation; links can break.
 
 - Javadoc and all valid Doxygen comments are stripped from Doxygen source code
-  previews (`STRIP_CODE_COMMENTS = YES` in [Doxyfile.in](doc/Doxyfile.in)). If
+  previews (`STRIP_CODE_COMMENTS = YES` in [Doxyfile.in](./Doxyfile.in)). If
   you want a comment to be preserved, it must instead use `//` or `/* */`.
 
 ### Generating Documentation
@@ -847,7 +847,7 @@ Strings and formatting
   - *Rationale*: These functions do overflow checking and avoid pesky locale issues.
 
 - Avoid using locale dependent functions if possible. You can use the provided
-  [`lint-locale-dependence.sh`](/test/lint/lint-locale-dependence.sh)
+  [`lint-locale-dependence.py`](/test/lint/lint-locale-dependence.py)
   to check for accidental use of locale dependent functions.
 
   - *Rationale*: Unnecessary locale dependence can cause bugs that are very tricky to isolate and fix.

src/test/README.md

@@ -1,4 +1,4 @@
-# Unit tests
+# Unit Tests
 
 The sources in this directory are unit test cases. Boost includes a
 unit testing framework, and since Bitcoin Core already uses Boost, it makes
@@ -10,7 +10,7 @@ The build system is set up to compile an executable called `test_bitcoin`
 that runs all of the unit tests. The main source file for the test library is found in
 `util/setup_common.cpp`.
 
-### Compiling/running unit tests
+## Compiling/Running Unit Tests
 
 Unit tests will be automatically compiled if dependencies were met in `./configure`
 and tests weren't explicitly disabled.
@@ -26,12 +26,12 @@ To add more unit tests, add `BOOST_AUTO_TEST_CASE` functions to the existing
 .cpp files in the `test/` directory or add new .cpp files that
 implement new `BOOST_AUTO_TEST_SUITE` sections.
 
-To run the GUI unit tests manually, launch `src/qt/test/test_bitcoin-qt`
+To run the GUI unit tests manually, launch `src/qt/test/test_bitcoin-qt`.
 
 To add more GUI unit tests, add them to the `src/qt/test/` directory and
 the `src/qt/test/test_main.cpp` file.
 
-### Running individual tests
+## Running Individual Tests
 
 `test_bitcoin` accepts the command line arguments from the boost framework.
 For example, to run just the `getarg_tests` suite of tests:
@@ -61,7 +61,7 @@ test_bitcoin --run_test=getarg_tests/doubledash
 
 Run `test_bitcoin --help` for the full list.
 
-### Adding test cases
+## Adding Test Cases
 
 To add a new unit test file to our test suite you need
 to add the file to `src/Makefile.test.include`. The pattern is to create
@@ -71,7 +71,7 @@ and such files should wrap their tests in a test suite
 called `<source_filename>_tests`. For an example of this pattern,
 see `uint256_tests.cpp`.
 
-### Logging and debugging in unit tests
+## Logging and Debugging in Unit Tests
 
 `make check` will write to a log file `foo_tests.cpp.log` and display this file
 on failure. For running individual tests verbosely, refer to the section
@@ -87,7 +87,7 @@ start debugging, just like you would with any other program:
 gdb src/test/test_bitcoin
 ```
 
-#### Segmentation faults
+### Segmentation Faults
 
 If you hit a segmentation fault during a test run, you can diagnose where the fault
 is happening by running `gdb ./src/test/test_bitcoin` and then using the `bt` command
@@ -106,9 +106,10 @@ Running the tests and hitting a segmentation fault should now produce a file cal
 (on Linux platforms, the file name will likely depend on the contents of
 `/proc/sys/kernel/core_pattern`).
 
-You can then explore the core dump using
+You can then explore the core dump using:
+
 ```bash
 gdb src/test/test_bitcoin core
 
-(gbd) bt  # produce a backtrace for where a segfault occurred
+(gdb) bt # produce a backtrace for where a segfault occurred
 ```