5 files changed, 25 insertions, 17 deletions
diff --git a/doc/developer/bgpd.rst b/doc/developer/bgpd.rst
index a35fa614f4..f5263ff31d 100644
--- a/doc/developer/bgpd.rst
+++ b/doc/developer/bgpd.rst
@@ -9,3 +9,4 @@ BGPD
 
    next-hop-tracking
    bgp-typecodes
+   bmp
diff --git a/doc/developer/mgmtd-dev.rst b/doc/developer/mgmtd-dev.rst
index b979af06fa..4c56cadb28 100644
--- a/doc/developer/mgmtd-dev.rst
+++ b/doc/developer/mgmtd-dev.rst
@@ -147,7 +147,7 @@ Front-End Interface:
     - change route_map_init() to route_map_init_new(false) and remove from
       VTYSH_ROUTE_MAP_CONFIG (leave in VTYSH_ROUTE_MAP_SHOW).
     - remove vrf_cmd_init(NULL)  => remove from VTYSH_INTERFACE_SUBSET
-    ...
+
 
 Back-End Interface:
 
diff --git a/doc/developer/northbound/yang-tools.rst b/doc/developer/northbound/yang-tools.rst
index fb5a287245..91a767dce7 100644
--- a/doc/developer/northbound/yang-tools.rst
+++ b/doc/developer/northbound/yang-tools.rst
@@ -87,7 +87,7 @@ Generate skeleton instance data:
 
 * XML:
 
-   .. code:: sh
+.. code:: sh
 
    $ pyang -p <yang-search-path> \
        -f sample-xml-skeleton --sample-xml-skeleton-defaults \
@@ -95,7 +95,7 @@ Generate skeleton instance data:
 
 *  JSON:
 
-   .. code:: sh
+.. code:: sh
 
    $ pyang -p <yang-search-path> \
        -f jsonxsl module.yang -o module.xsl
diff --git a/doc/developer/topotests.rst b/doc/developer/topotests.rst
index 72de7b3bc9..6209749636 100644
--- a/doc/developer/topotests.rst
+++ b/doc/developer/topotests.rst
@@ -37,7 +37,7 @@ Installing Topotest Requirements
        tshark \
        valgrind
    python3 -m pip install wheel
-   python3 -m pip install 'pytest>=6.2.4' 'pytest-xdist>=2.3.0'
+   python3 -m pip install 'pytest>=8.3.2' 'pytest-asyncio>=0.24.0' 'pytest-xdist>=3.6.1'
    python3 -m pip install 'scapy>=2.4.5'
    python3 -m pip install xmltodict
    python3 -m pip install git+https://github.com/Exa-Networks/exabgp@0659057837cd6c6351579e9f0fa47e9fb7de7311
@@ -731,8 +731,8 @@ packages.
 
 Code coverage can automatically be gathered for any topotest run. To support
 this FRR must first be compiled with the ``--enable-gcov`` configure option.
-This will cause *.gnco files to be created during the build. When topotests are
-run the statistics are generated and stored in *.gcda files. Topotest
+This will cause \*.gnco files to be created during the build. When topotests are
+run the statistics are generated and stored in \*.gcda files. Topotest
 infrastructure will gather these files, capture the information into a
 ``coverage.info`` ``lcov`` file and also report the coverage summary.
 
@@ -741,7 +741,7 @@ If you build your FRR in a directory outside of the FRR source directory you
 will also need to pass the ``--cov-frr-build-dir`` argument specifying the build
 directory location.
 
-During the topotest run the *.gcda files are generated into a ``gcda``
+During the topotest run the \*.gcda files are generated into a ``gcda``
 sub-directory of the top-level run directory (i.e., normally
 ``/tmp/topotests/gcda``). These files will then be copied at the end of the
 topotest run into the FRR build directory where the ``gcov`` and ``lcov``
@@ -756,7 +756,7 @@ The ``coverage.info`` file can then be used to generate coverage reports or file
 markup (e.g., using the ``genhtml`` utility) or enable markup within your
 IDE/editor if supported (e.g., the emacs ``cov-mode`` package)
 
-NOTE: the *.gcda files in ``/tmp/topotests/gcda`` are cumulative so if you do
+NOTE: the \*.gcda files in ``/tmp/topotests/gcda`` are cumulative so if you do
 not remove them they will aggregate data across multiple topotest runs.
 
 How to reproduce failed Tests
diff --git a/doc/developer/workflow.rst b/doc/developer/workflow.rst
index 50bcb2976e..5e22c4cb72 100644
--- a/doc/developer/workflow.rst
+++ b/doc/developer/workflow.rst
@@ -6,9 +6,10 @@ Process & Workflow
 
 .. highlight:: none
 
-FRR is a large project developed by many different groups. This section
-documents standards for code style & quality, commit messages, pull requests
-and best practices that all contributors are asked to follow.
+FRR is a large project developed by many different groups. This
+section documents standards for code style & quality, commit messages,
+pull requests (PRs) and best practices that all contributors are asked
+to follow.
 
 This chapter is "descriptive/post-factual" in that it documents pratices that
 are in use; it is not "definitive/pre-factual" in prescribing practices. This
@@ -241,7 +242,7 @@ discontinued.
 The LTS branch duties are the following ones:
 
 - organise meetings on a (bi-)weekly or monthly basis, the handling of issues
-  and pull requested relative to that branch. When time permits, this may be done
+  and pull requests relative to that branch. When time permits, this may be done
   during the regularly scheduled FRR meeting.
 
 - ensure the stability of the branch, by using and eventually adapting the
@@ -324,11 +325,17 @@ relevant to your work.
 Submitting Patches and Enhancements
 ===================================
 
-FRR accepts patches using GitHub pull requests.
-
-The base branch for new contributions and non-critical bug fixes should be
-``master``. Please ensure your pull request is based on this branch when you
-submit it.
+FRR accepts patches using GitHub pull requests (PRs). The typical FRR
+developer will maintain a fork of the FRR project in GitHub; see the
+GitHub documentation for help setting up an account and creating a
+fork repository. Keep the ``master`` branch of your fork up-to-date
+with the FRR version. Create a dev branch in your fork and commit your
+work there. When ready, create a pull-request between your dev branch
+in your fork and the main FRR repository in GitHub.
+
+The base branch for new contributions and non-critical bug fixes
+should be ``master``. Please ensure your pull request targets this
+branch when you submit it.
 
 Code submitted by pull request will be automatically tested by one or more CI
 systems. Once the automated tests succeed, other developers will review your