Fix typos in documentation (#1435)

jwilber · web-flow · commit fbcd380c39dc · 2026-01-26T18:16:35.000Z
Documentation typo fixes (thanks ai). I also fixed the `!!! note` text sections that were missing the leading ` `, which caused inaccurate rendering (see image below): <img width="917" height="115" alt="image" src="https://github.com/user-attachments/assets/a0143254-437b-41fd-b038-12a38bd237a9" /> --------- Signed-off-by: jwilber <jwilber@nvidia.com>
diff --git a/docs/docs/main/about/releasenotes-fw.md b/docs/docs/main/about/releasenotes-fw.md
@@ -40,7 +40,7 @@
 - ESM2 LoRA model inference issue resolved. https://github.com/NVIDIA/bionemo-framework/pull/996
 - Added experimental evo2-mamba model. https://github.com/NVIDIA/bionemo-framework/pull/888
 - Updated base Docker image to [nvidia-pytorch 25.06-py3](https://catalog.ngc.nvidia.com/orgs/nvidia/containers/pytorch/tags)
-- NCCL issue in ESM2 pretraing resolved. https://github.com/NVIDIA/bionemo-framework/issues/970
+- NCCL issue in ESM2 pretraining resolved. https://github.com/NVIDIA/bionemo-framework/issues/970
 
 ### What's Changed
 
@@ -86,7 +86,7 @@
 
 ### Updates & Improvements
 
-- Fixes around ESM2 pretraining and funetuning checkpoints.
+- Fixes around ESM2 pretraining and finetuning checkpoints.
 - Added sanity dataset for AMPLIFY testing.
 - Tested against A100 [brev](https://developer.nvidia.com/brev) instances.
 - Update `tornado` package to `>6.5.0` to fix container CVEs.
diff --git a/docs/docs/main/contributing/code-review.md b/docs/docs/main/contributing/code-review.md
@@ -67,19 +67,19 @@ may collapse to a single review.
 
 ### 4. Coverage Check
 
-Our repository has automated checks to ensure test coverage has not regresed.
+Our repository has automated checks to ensure test coverage has not regressed.
 The coverage check approvers will be the same as the Approval-list users. If
 codeline test coverage regresses, the Approvers must make a judgement call
-whether it is acceptible or not the merge the code. Occaisonally the coverage
+whether it is acceptable or not to merge the code. Occasionally the coverage
 check algorithm has a false positive (i.e. code coverage doesn't regress, yet
-coverage check approval is flagged by gitlab), and in this case Approvers are i
+coverage check approval is flagged by gitlab), and in this case Approvers are
 free to simply approve the false coverage regression.
 
 ## Responsibilities
 
 ### All Commenters (Reviewers, Owners, Approvers, etc.)
 
-If a comment thread is start by anyone, it is expected that **the thread starter
+If a comment thread is started by anyone, it is expected that **the thread starter
 resolves the comment**. Resolving a thread by the original thread starter indicates
 that the person who started the discussion is happy with the outcome.
 
@@ -207,7 +207,7 @@ a fruitful interaction across the team members.
 
 - Follow code styling and rules stated in the project's documents
   (for example, [contributing.md](contributing.md), of which the [Google Python
-  Style Guide](https://google.github.io/styleguide/pyguide.html) is a subet) as these define the
+  Style Guide](https://google.github.io/styleguide/pyguide.html) is a subset) as these define the
   look and feel of the code which defines the most fundamentals of how the code should be
   developed and allows reviewers to focus on the most important aspects of a new piece of code.
   For bash scripting please follow the Google Shell Style Guide [here](https://google.github.io/styleguide/shellguide.html)
@@ -252,7 +252,7 @@ a fruitful interaction across the team members.
   that approves the change must review the entire change holistically
   If you are a code owner of a particular file, it is appropriate to only reviews the files you own.
 
-- If request an PR change their code, you are responsible for giving concrete
+- If you request a PR to change their code, you are responsible for giving concrete
   recommendations for what could be changed to resolve the issue the
   patch addresses. If you feel strongly that a patch should NEVER be
   merged, you are responsible for defending your position and
@@ -461,7 +461,7 @@ a fruitful interaction across the team members.
   production, we put them inside the `bionemo2/contrib` folder. This allows for teams to develop
   faster (less strict reviews) while testing code. When a feature is
   complete and well tested, we move it to `bionemo2/src` or
-  `bionemo2/core` and we complete all the requirements for productroduction.
+  `bionemo2/core` and we complete all the requirements for production.
 
 ## References
 
diff --git a/docs/docs/main/contributing/contributing.md b/docs/docs/main/contributing/contributing.md
@@ -31,7 +31,7 @@ Signed-off-by: Your Name <your@email.com>
 ```
 
 If you would like this to happen automatically to all of your commits, you can modify
-your local `~/.git-config-template.txt` file. You can do this with a command like the
+your local `~/.git-commit-template.txt` file. You can do this with a command like the
 following:
 
 ```
@@ -109,7 +109,7 @@ submitting. Labels can be accessed in the right sidebar of the GitHub user inter
 
 ### CI Pipeline Configuration Controls
 
-CI pipeline behavior can be controlled labels to optimize test execution:
+CI pipeline behavior can be controlled by labels to optimize test execution:
 
 Key behaviors:
 
@@ -181,9 +181,9 @@ For both internal and external developers, the next step is opening a PR:
    [requested](https://help.github.com/en/articles/creating-a-pull-request) to merge the changes from a branch of the
    fork or branch into `main`.
    - Exercise caution when selecting the source and target branches for the PR.
-     Note that versioned releases of TensorRT OSS are posted to `release/` branches of the upstream repo.
-   - Creation of a PR creation kicks off the code review process.
-   - At least one TensorRT engineer will be assigned for the review.
+     Note that versioned releases of BioNeMo are posted to `release/` branches of the upstream repo.
+   - Creation of a PR kicks off the code review process.
+   - At least one BioNeMo engineer will be assigned for the review.
    - While under review, mark your PRs as work-in-progress by prefixing the PR title with [WIP].
 2. Once ready, CI can be started by a developer with permissions when they add a `/build-ci` comment. This must pass
    prior to merging.
diff --git a/docs/docs/main/getting-started/pre-reqs.md b/docs/docs/main/getting-started/pre-reqs.md
@@ -3,7 +3,7 @@
 Before you begin using the BioNeMo Framework, ensure the hardware and software prerequisites outlined below are
 met.
 
-## Hardware Prequisites
+## Hardware Prerequisites
 
 The BioNeMo Framework is compatible with environments that have access to NVIDIA GPUs. `bfloat16` precision requires an
 Ampere generation GPU or higher ([Compute Capability ≥8.0](https://developer.nvidia.com/cuda-gpus)). You may be able
diff --git a/docs/docs/main/getting-started/training-models.md b/docs/docs/main/getting-started/training-models.md
@@ -1,8 +1,7 @@
 # Training Models
 
 !!! note "5D Parallel Training Moved to bionemo-recipes"
-The 5D parallel training implementations for ESM-2 and Geneformer have been migrated to simplified TransformerEngine + FSDP implementations in [bionemo-recipes](https://github.com/NVIDIA/bionemo-framework/tree/main/bionemo-recipes). For training these models, please refer to the recipes in `bionemo-recipes/recipes/` (e.g., `esm2_native_te`, `geneformer_native_te_mfsdp_fp8`). The instructions below work for bi
-onemo-framework container releases \<2.7.1.
+The 5D parallel training implementations for ESM-2 and Geneformer have been migrated to simplified TransformerEngine + FSDP implementations in [bionemo-recipes](https://github.com/NVIDIA/bionemo-framework/tree/main/bionemo-recipes). For training these models, please refer to the recipes in `bionemo-recipes/recipes/` (e.g., `esm2_native_te`, `geneformer_native_te_mfsdp_fp8`). The instructions below work for bionemo-framework container releases \<2.7.1.
 
 ## Pydantic Configuration
 
