Merge pull request #16789 from mjstapp/doc_dev_update

doc: add some text about using git forks

doc/developer/bgpd.rst

@@ -9,3 +9,4 @@ BGPD
 
    next-hop-tracking
    bgp-typecodes
+   bmp

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:
 

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

doc/developer/topotests.rst

@@ -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
+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
+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

doc/developer/workflow.rst

@@ -6,9 +6,10 @@ Process & Workflow
 
 .. highlight:: none
 
-FRR is a large project developed by many different groups. This section
+FRR is a large project developed by many different groups. This
-documents standards for code style & quality, commit messages, pull requests
+section documents standards for code style & quality, commit messages,
-and best practices that all contributors are asked to follow.
+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.
+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
+The base branch for new contributions and non-critical bug fixes
-``master``. Please ensure your pull request is based on this branch when you
+should be ``master``. Please ensure your pull request targets this
-submit it.
+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