Navigation updates to Contributor Guide (#564)

* Navigation updates to Contributor Guide

* Minor update to CI topic

contributor-guide/modules/ROOT/nav.adoc

@@ -30,10 +30,6 @@ Official repository: https://github.com/boostorg/website-v2-docs
 ** xref:best-practices.adoc[]
 ** xref:debug-visualisers.adoc[]
 
-* Build Systems
-** xref:build-systems/cmake.adoc[]
-** xref:build-systems/b2.adoc[]
-
 * Testing
 ** xref:testing/intro.adoc[]
 ** xref:testing/test-policy.adoc[]

contributor-guide/modules/ROOT/pages/contributor-community-introduction.adoc

@@ -12,6 +12,11 @@ Official repository: https://github.com/boostorg/website-v2-docs
 The Boost Contributors Community is a dedicated group of developers and enthusiasts committed to advancing the Boost libraries.
 There are many different ways of xref:getting-involved.adoc[] with this community.
 
+* <<Communications>>
+* <<Documentation Style>>
+* <<Governance>>
+* <<See Also>>
+
 == Communications
 
 The https://lists.boost.org/mailman/listinfo.cgi/boost[Boost Developers Mailing List] is focused on the development and maintenance of the libraries.

contributor-guide/modules/ROOT/pages/oversight-committee.adoc

@@ -13,6 +13,11 @@ The _Fiscal Sponsorship Committee_ plays a custodial and oversight role rather t
 
 Boost operates with a decentralized and community-driven development model, where individual contributors and maintainers have the autonomy to drive their libraries' progress. The committee supports this by ensuring the ecosystem remains healthy and sustainable for current and future contributors.
 
+* <<Boost Assets>>
+* <<Contact Information>>
+* <<See Also>>
+
+
 == Boost Assets
 
 When referring to Boost "assets", these assets fall into five broad categories:

contributor-guide/modules/ROOT/pages/release-notes.adoc

@@ -154,4 +154,6 @@ The rule of thumb here is to *keep the number of bullet points to ten or less*,
 
 * https://github.com/boostorg/website/tree/master/feed/history[Boostorg History]
 * xref:release-process.adoc[]
-* xref:version-control.adoc[]
+* xref:version-control.adoc[]
+
+

contributor-guide/modules/ROOT/pages/release-process.adoc

@@ -18,6 +18,12 @@ The Boost libraries are released publicly three times per year:
 
 Each release will contain updates to existing libraries, and some releases will contain new libraries. The release is built from the *master* branch of Boost's GitHub site: https://github.com/boostorg/boost.
 
+* <<Preparing for a Boost Release>>
+* <<Boost Regression Testing>>
+* <<Milestones in the Release Cycle>>
+* <<See Also>>
+
+
 == Preparing for a Boost Release
 
 The release managers set the release timeline, which involves planning deadlines for library submissions, reviews, and incorporation into the repository.

contributor-guide/modules/ROOT/pages/site-docs-style-guide.adoc

@@ -11,6 +11,12 @@ Official repository: https://github.com/boostorg/website-v2-docs
 
 This document outlines the style guidelines for the site-docs. Adhering to these guidelines will help ensure consistency and cohesion across all pages of the website.
 
+* <<Color Guidelines>>
+* <<Wording Guidelines>>
+* <<URL Display>>
+* <<Image Display>>
+* <<See Also>>
+
 == Color Guidelines
 
 * Boost Mustard

contributor-guide/modules/ROOT/pages/testing/boost-test-matrix.adoc

@@ -9,6 +9,15 @@ Official repository: https://github.com/boostorg/website-v2-docs
 = Test Matrix
 :navtitle: Test Matrix
 
+* <<Introduction>>
+* <<Regression Dashboard>>
+* <<Handling Test Failures>>
+* <<Boost Build>>
+* <<Test Process Feedback>>
+* <<See Also>>
+
+== Introduction
+
 The Boost Test Matrix is an automated testing system that runs tests on Boost libraries across a wide range of platforms, compiler versions, and configurations. Its primary purpose is to ensure that the libraries work correctly under various conditions and to identify any compatibility issues.
 
 The Test Matrix includes tests run on different operating systems (Windows, Linux, macOS) and with various compilers (such as GCC, Clang, MSVC). This diversity helps in catching issues that might only appear in specific environments.

contributor-guide/modules/ROOT/pages/testing/continuous-integration.adoc

@@ -7,7 +7,24 @@ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
 Official repository: https://github.com/boostorg/website-v2-docs
 ////
 = Continuous Integration
+:toc: macro
+:toclevels: 1
 
+* <<Introduction>>
+* <<New Library CI Framework>>
+* <<GitHub Actions>>
+* <<Drone>>
+* <<Travis CI>>
+* <<AppVeyor>>
+* <<CircleCI>>
+* <<Azure Pipelines>>
+* <<Coverage>>
+* <<Test with Popular Compilers>>
+* <<Docker Containers>>
+* <<See Also>>
+
+
+== Introduction
 
 The Boost project uses Continuous Integration(CI) to ensure the quality and integrity of its code. CI is the practice of merging all developers' working copies into a shared mainline several times a day. The main aim is to prevent integration issues, which can be identified and addressed as early as possible.
 

contributor-guide/modules/ROOT/pages/testing/fuzzing.adoc

@@ -9,6 +9,18 @@ Official repository: https://github.com/boostorg/website-v2-docs
 = Fuzz Testing
 :navtitle: Fuzzing
 
+* <<Introduction>>
+* <<LibFuzzer Basics>>
+* <<Corpus>>
+* <<Verifying the Effectiveness of your Fuzzer>>
+* <<Corpus Minimization>>
+* <<Handling Crashes>>
+* <<Running the Fuzzer in CIs>>
+* <<Best Practices for Writing Fuzzers>>
+* <<See Also>>
+
+== Introduction
+
 *What is fuzz testing?* Fuzzing is a testing technique that injects random pieces of data to a software function to uncover crashes and vulnerabilities. It helps improving code security and reliability, since it can trigger edge cases that went unnoticed during unit testing.
 
 *How does it work?* Fuzz testing relies on a fuzzing engine, a library that runs your code in a loop, injecting different inputs at each iteration. The fuzzing engine will instrument your code to measure coverage, and use this information to drive the generation of samples. Most of the samples will contain malformed input, and will test your code's tolerance to ill-formed inputs.

contributor-guide/modules/ROOT/pages/testing/intro.adoc

@@ -21,6 +21,12 @@ The new library developer needs to consider all three, however the initial focus
 
 "_How did software get so reliable without proof?_"
 
+* <<Define a Test Matrix>>
+* <<Use Predefined Macros from Boost.Config>>
+* <<Regression Testing>>
+* <<Next Steps>>
+* <<See Also>>
+
 == Define a Test Matrix
 
 When you're looking to submit a library to the Boost collection, it's essential to ensure broad compatibility with various compilers, platforms, and configurations. Create a test matrix of what you intend to support, and document what you do not intend to support, and consider:

contributor-guide/modules/ROOT/pages/testing/regression-tests.adoc

@@ -13,6 +13,11 @@ This section describes how to run regression tests on your local machine, by dow
 
 For information on the regression tests run on all libraries, refer to xref:testing/boost-test-matrix.adoc[].
 
+* <<Running Regression Tests Locally>>
+* <<The Run.py Tool>>
+* <<Feedback>>
+* <<See Also>>
+
 == Running Regression Tests Locally
 
 It's easy to run regression tests on your Boost clone.

contributor-guide/modules/ROOT/pages/testing/sanitizers.adoc

@@ -13,6 +13,10 @@ Consider using a code sanitizer to check for some of the more mundane, but never
 
 All the tools listed have different strengths and are useful in different scenarios, so you might want to use several of them in combination.
 
+* <<AddressSanitizer>>
+* <<Valgrind>>
+* <<See Also>>
+
 == AddressSanitizer
 
 https://clang.llvm.org/docs/AddressSanitizer.html[Clang AddressSanitizer (ASan)] is a fast memory error detector built into LLVM/Clang, gcc and other compilers. As such, it works on Windows, Linux, and MacOS. It can detect out-of-bounds accesses to heap, stack, and globals, use-after-free and use-after-return bugs, and other memory-related errors. AddressSanitizer is generally faster than <<Valgrind>> and can be used in continuous integration without significantly slowing down the test suite.
@@ -30,7 +34,7 @@ The sanitizer suite also includes:
 * *ThreadSanitizer* (TSan) detects data races. It's available in Clang and gcc. Set `-fsanitize=thread` in Clang, or `thread-sanitizer=on` in B2. Refer to https://clang.llvm.org/docs/ThreadSanitizer.html[Clang ThreadSanitizer].
 
 
-=== Valgrind
+== Valgrind
 
 For Linux based systems, https://valgrind.org/docs/manual/quick-start.html[Valgrind] is an open-source software tool suite that helps in debugging memory management and threading bugs, and profiling programs. It is often used to detect memory leaks and uninitialised memory blocks in pass:[C++] programs, among other things.
 

contributor-guide/modules/ROOT/pages/testing/test-policy.adoc

@@ -11,6 +11,12 @@ Official repository: https://github.com/boostorg/website-v2-docs
 
 There are required and optional (though highly recommended) tests for libraries.
 
+* <<Required>>
+* <<Optional>>
+* <<Protocol for Fixing Bugs or Adding Features>>
+* <<Snapshots>>
+* <<See Also>>
+
 == Required
 
 Boost uses an automatic regression test suite which generates HTML compiler status tables. Boost also uses xref:testing/continuous-integration.adoc[] to ensure these tests are regularly run. Ensure your library testing includes the following:

contributor-guide/modules/ROOT/pages/testing/writing-tests.adoc

@@ -9,6 +9,13 @@ Official repository: https://github.com/boostorg/website-v2-docs
 = Writing Tests
 :navtitle: Writing Tests
 
+* <<Guidelines for Contributors>>
+* <<Unit Tests>>
+* <<Test Edge Cases>>
+* <<Testing Features of Boost.Core>>
+* <<Descriptive Test Names>>
+* <<See Also>>
+
 == Guidelines for Contributors
 
 By following these guidelines and examples, contributors can write effective and maintainable unit tests that ensure the robustness and reliability of their Boost library contributions.

contributor-guide/modules/ROOT/pages/tweeting.adoc

@@ -14,7 +14,14 @@ The collection is represented on social media by the https://twitter.com/boostli
 X (formerly Twitter) account, where news and information about our libraries in particular and C++ in general are shared
 with the community.
 
-== What gets posted
+* <<What gets Posted>>
+* <<Topics of Interest>>
+* <<Post Structure>>
+* <<Post Submission>>
+* <<See Also>>
+
+
+== What gets Posted
 
 The account publishes two types of posts:
 
@@ -25,7 +32,7 @@ Official posts have a Boost brand imagery with watermark, and are produced by vo
 the former. Anyone from the community can propose a non-official post for publication; if you're interested in
 doing so, follow these simple guidelines:
 
-== Topics of interest
+== Topics of Interest
 
 * Upcoming C++ events, meetups, conferences, etc.
 * Talks about some particular library, or where such library is put to good effect.
@@ -35,7 +42,7 @@ doing so, follow these simple guidelines:
 The list is not exhaustive: if in doubt, just go with your submission or ask
 for guidance using the same submission channel.
 
-== Post structure
+== Post Structure
 
 image::tweet_structure.jpg[Structure of an X post]
 
@@ -72,7 +79,7 @@ Making the perfect post is not trivial: if you need inspiration,
 go to https://twitter.com/boostlibraries[@BoostLibraries,role=resource,window=_blank] for actual
 post examples.
 
-== Post submission
+== Post Submission
 
 Log into the https://cpplang.slack.com/[C++ Language Slack Workspace,role=resource,window=_blank]
 (or https://cppalliance.org/slack/[join it,role=resource,window=_blank] if you're not a member yet)
@@ -91,3 +98,8 @@ Also, they will schedule the publication date and time for
 maximum impact (typically, on weekday mornings with an eye to
 catching readers both sides of the Atlantic, but this may be adjusted
 for events specific to some country or geographical area).
+
+== See Also
+
+* xref:user-guide:ROOT:discussion-policy.adoc[]
+