docs: fix various typos

---
type: pre_commit_static_analysis_report
description: Results of running static analysis checks when committing changes.
report:
  - task: lint_filenames
    status: passed
  - task: lint_editorconfig
    status: passed
  - task: lint_markdown
    status: passed
  - task: lint_package_json
    status: na
  - task: lint_repl_help
    status: na
  - task: lint_javascript_src
    status: na
  - task: lint_javascript_cli
    status: na
  - task: lint_javascript_examples
    status: na
  - task: lint_javascript_tests
    status: na
  - task: lint_javascript_benchmarks
    status: na
  - task: lint_python
    status: na
  - task: lint_r
    status: na
  - task: lint_c_src
    status: na
  - task: lint_c_examples
    status: na
  - task: lint_c_benchmarks
    status: na
  - task: lint_c_tests_fixtures
    status: na
  - task: lint_shell
    status: na
  - task: lint_typescript_declarations
    status: na
  - task: lint_typescript_tests
    status: na
  - task: lint_license_headers
    status: passed
---

Author: Planeshifter

CONTRIBUTING.md

@@ -61,7 +61,7 @@ When filing an [issue][stdlib-issues], provide the following, where possible:
 -   The expected results.
 -   List of affected environments (e.g., browser, browser version, `npm` version, Node.js version, operating system, and stdlib version).
 
-When pasting code blocks or output, use triple backticks to enable proper formatting. Surround inline code with single backticks. For other Markdown formatting tips and trips, see GitHub's [Markdown guide][github-markdown-guide].
+When pasting code blocks or output, use triple backticks to enable proper formatting. Surround inline code with single backticks. For other Markdown formatting tips and tricks, see GitHub's [Markdown guide][github-markdown-guide].
 
 Be aware that the `@` symbol tags users on GitHub, so **always** surround package names with backticks (e.g., `@stdlib/utils/copy`).
 
@@ -87,7 +87,7 @@ If you have found a bug that you would like to fix,
 
 If you want to contribute a new feature or a breaking change to stdlib, be sure to
 
--   consult the [Gitter][stdlib-gitter] channel to discuss ideas and to gather feedback as to whether a feature would be better developed as an external package. Discussing the design upfront helps ensure that we're ready to accept to your work.
+-   consult the [Gitter][stdlib-gitter] channel to discuss ideas and to gather feedback as to whether a feature would be better developed as an external package. Discussing the design upfront helps ensure that we're ready to accept your work.
 -   write an RFC (request for comments) detailing the proposed change and submit as an issue on the project GitHub issue tracker.
 -   wait for RFC approval.
 -   submit a [pull request][stdlib-pull-requests], making sure to adhere to the guidance set forth in the RFC.

README.md

@@ -162,7 +162,7 @@ Thank you for being a part of our community! Your support is invaluable to us!
 
 To accommodate various use cases, stdlib can be used in multiple ways. The preferred method of use depends on your individual use case. We've provided some user stories to help you identify the best approach. 😃
 
-While this project's installation instructions defaults to using [npm][npm] for package management, installation via other package managers, such as [yarn][yarn], should be a matter of simply swapping out [npm][npm] commands with those of the relevant package manager.
+While this project's installation instructions default to using [npm][npm] for package management, installation via other package managers, such as [yarn][yarn], should be a matter of simply swapping out [npm][npm] commands with those of the relevant package manager.
 
 ### User Stories
 

SECURITY.md

@@ -107,7 +107,7 @@ Our disclosure policy is as follows:
 
 -   Depending on the outcome of validation, the primary handler will communicate to the individual who submitted the potential vulnerability one of the following possible responses:
 
-    -   **Acceptance**: what was reported is a considered a new vulnerability.
+    -   **Acceptance**: what was reported is considered a new vulnerability.
     -   **Rejection**: what was reported is not considered a new vulnerability.
     -   **Needs more information**: we need more information in order to evaluate what was reported.
 

docs/contributing/doctest.md

@@ -239,7 +239,7 @@ var o = foo();
 
 #### Deep Approximate Equality
 
-Asserting approximately equality is extended to complex data structures. For example,
+Asserting approximate equality is extended to complex data structures. For example,
 
 <!-- run-disable -->
 
@@ -504,7 +504,7 @@ indicates that `foo()` returns a JavaScript `object` having the properties `a` a
 
 -   Write doctests with care. Avoid the extravagant. Prefer simple test cases.
 -   Avoid obscure test cases, as these typically make for bad documentation.
--   Doctests complement, but are **not** a substitute for, unit testing. While both doctests and unit tests aid in regression testing, one of the principle strengths of doctests is the ability to interleave (in a more natural manner) code and explanatory text. Doctests are **not** the place to exhaustively test, especially with little explanation, complex edge cases involving significant preceding code. As a general rule, use doctests to convey essential aspects as simply and concisely as possible in a literate manner. Use unit tests to thoroughly and exhaustively explore and probe API contracts and expected behavior.
+-   Doctests complement, but are **not** a substitute for, unit testing. While both doctests and unit tests aid in regression testing, one of the principal strengths of doctests is the ability to interleave (in a more natural manner) code and explanatory text. Doctests are **not** the place to exhaustively test, especially with little explanation, complex edge cases involving significant preceding code. As a general rule, use doctests to convey essential aspects as simply and concisely as possible in a literate manner. Use unit tests to thoroughly and exhaustively explore and probe API contracts and expected behavior.
 -   Writing effective doctests is an _art_ in knowing when, how much, and (precisely) what you want to convey to the reader. The more you write and use doctests, the better your intuition will be in recognizing what is truly essential and how each essential aspect should be conveyed.
 
 * * *

docs/contributing/setting_up_a_devcontainer.md

@@ -26,7 +26,7 @@ limitations under the License.
 
 We appreciate your interest in contributing to stdlib! Below, we've provided a step-by-step tutorial on how to set up the project locally on your device using a dev container.
 
-Dev containers, are Docker containers that are specifically configured to provide a fully featured development environment with the right tooling, extensions, linting and formatting. They allow you to open any folder inside (or mounted into) a container and take advantage of Visual Studio Code's full feature set.
+Dev containers are Docker containers that are specifically configured to provide a fully featured development environment with the right tooling, extensions, linting and formatting. They allow you to open any folder inside (or mounted into) a container and take advantage of Visual Studio Code's full feature set.
 
 The stdlib repository includes a preconfigured dev container, making it the easiest way to set up your development environment. It ensures proper linting, EditorConfig, and tooling are configured right from the start.
 

docs/references/README.md

@@ -1,3 +1,23 @@
+<!--
+
+@license Apache-2.0
+
+Copyright (c) 2016 The Stdlib Authors.
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+
+-->
+
 # References
 
 > Reference database.
@@ -39,7 +59,7 @@ The database is a [BibTeX][bibtex] database file, where the file format is a pla
 }
 ```
 
-corresponds to Bay's and Durham's 1976 article "Improving a Poor Random Number Generator" appearing in the journal _ACM Transactions on Mathematical Software_. 
+corresponds to Bays' and Durham's 1976 article "Improving a Poor Random Number Generator" appearing in the journal _ACM Transactions on Mathematical Software_.
 
 </section>