typo corrections

CHANGELOG.md

@@ -22,7 +22,7 @@ Release channels have their own copy of this changelog:
     * removed the unreleased `redelegate` instruction processor and CLI commands (#2213)
 * Changes
   * SDK: removed the `respan` macro. This was marked as "internal use only" and was no longer used internally.
-  * `agave-validator`: Update PoH speed check to compare against current hash rate from a Bank (#2447)
+  * `agave-validator`: Update PoH speed check to compare against the current hash rate from a Bank (#2447)
   * `solana-test-validator`: Add `--clone-feature-set` flag to mimic features from a target cluster (#2480)
 
 ## [2.0.0]
@@ -47,7 +47,7 @@ Release channels have their own copy of this changelog:
     * `--incremental-snapshots` (#2148)
     * `--halt-on-known-validators-accounts-hash-mismatch` (#2157)
 * Changes
-  * `central-scheduler` as default option for `--block-production-method` (#34891)
+  * `central-scheduler` as the default option for `--block-production-method` (#34891)
   * `solana-rpc-client-api`: `RpcFilterError` depends on `base64` version 0.22, so users may need to upgrade to `base64` version 0.22
   * Changed default value for `--health-check-slot-distance` from 150 to 128
   * CLI: Can specify `--with-compute-unit-price`, `--max-sign-attempts`, and `--use-rpc` during program deployment
@@ -57,8 +57,8 @@ Release channels have their own copy of this changelog:
   * CLI: Can specify `--full-snapshot-archive-path` (#1631)
   * transaction-status: The SPL Token `amountToUiAmount` instruction parses the amount into a string instead of a number (#1737)
   * Implemented partitioned epoch rewards as per [SIMD-0118](https://github.com/solana-foundation/solana-improvement-documents/blob/fae25d5a950f43bd787f1f5d75897ef1fdd425a7/proposals/0118-partitioned-epoch-reward-distribution.md). Feature gate: #426. Specific changes include:
-    * EpochRewards sysvar expanded and made persistent (#428, #572)
-    * Stake Program credits now allowed during distribution (#631)
+    * EpochRewards sys var expanded and made persistent (#428, #572)
+    * Stake Program credits are now allowed during distribution (#631)
     * Updated type in Bank::epoch_rewards_status (#1277)
     * Partitions are recalculated on boot from snapshot (#1159)
     * `epoch_rewards_status` removed from snapshot (#1274)
@@ -126,13 +126,13 @@ makes the feature code complete.
     * dapp or client developers to make changes.
 * Link to any relevant feature gate issues or SIMDs.
 * If you add entries on multiple branches use the same wording if possible.
-This simplifies the process of diffing between versions of the log.
+This simplifies the process of differentiating between versions of the log.
 
 ## Maintaining This Changelog
 ### When creating a new release branch:
 * Commit to master updating the changelog:
   * Update the edge, beta, and stable links
-  * Create new section: `vx.y+1.0 - Unreleased`
+  * Create a new section: `vx.y+1.0 - Unreleased`
   * Remove `Unreleased` annotation from vx.y.0 section.
 * Create vx.y branch starting at that commit
 * Tag that commit as vx.y.0

CONTRIBUTING.md

@@ -4,7 +4,7 @@ The goal of these guidelines is to improve developer productivity by allowing
 developers to jump into any file in the codebase and not need to adapt to
 inconsistencies in how the code is written. The codebase should appear as if it
 had been authored by a single developer. If you don't agree with a convention,
-submit a PR patching this document and let's discuss! Once the PR is accepted,
+submit a PR patching this document, and let's discuss! Once the PR is accepted,
 *all* code should be updated as soon as possible to reflect the new
 conventions.
 
@@ -45,7 +45,7 @@ $ git pull --rebase upstream master
 
 If there are no functional changes, PRs can be very large and that's no
 problem. If, however, your changes are making meaningful changes or additions,
-then about 1,000 lines of changes is about the most you should ask a Solana
+then about 1,000 lines of changes are about the most you should ask a Solana
 maintainer to review.
 
 ### Should I send small PRs as I develop large, new components?
@@ -59,7 +59,7 @@ may be pulled in with a package manager.
 ## Getting Pull Requests Merged
 
 There is no single person assigned to watching GitHub PR queue and ushering you
-through the process. Typically, you will ask the person that wrote a component
+through the process. Typically, you will ask the person who wrote a component
 to review changes to it. You can find the author using `git blame` or asking on
 Discord.  When working to get your PR merged, it's most important to understand
 that changing the code is your priority and not necessarily a priority of the
@@ -74,7 +74,7 @@ minutes to execute. Use that time to write a detailed problem description. Once
 the description is written and CI succeeds, click the "Ready to Review" button
 and add reviewers. Adding reviewers before CI succeeds is a fast path to losing
 reviewer engagement. Not only will they be notified and see the PR is not yet
-ready for them, they will also be bombarded with additional notifications
+ready for them, but they will also be bombarded with additional notifications
 each time you push a commit to get past CI or until they "mute" the PR. Once
 muted, you'll need to reach out over some other medium, such as Discord, to
 request they have another look. When you use draft PRs, no notifications are
@@ -99,7 +99,7 @@ more important than competing issues, don't expect the reviewer to read on.
 
 Next, the reviewer will read the proposed changes. At this point, the reviewer
 needs to be convinced the proposed changes are a *good* solution to the problem
-described above.  If the proposed changes, not the code changes, generates
+described above.  If the proposed changes, not the code changes, generate
 discussion, consider closing the PR and returning with a design proposal
 instead.
 
@@ -148,7 +148,7 @@ matches the logical flow in your PR description.
 
 ### The PR / Issue Labels
 
-Labels make it easier to manage and track PRs / issues.  Below some common labels
+Labels make it easier to manage and track PRs / issues.  Below are some common labels
 that we use in Solana.  For the complete list of labels, please refer to the
 [label page](https://github.com/solana-labs/solana/issues/labels):
 
@@ -158,11 +158,11 @@ New feature gates should also always have a corresponding tracking issue
 (go to "New Issue" -> "Feature Gate Tracker [Get Started](https://github.com/solana-labs/solana/issues/new?assignees=&labels=feature-gate&template=1-feature-gate.yml&title=Feature+Gate%3A+)")
 and should be updated each time the feature is activated on a cluster.
 
-* "automerge": When a PR is labelled with "automerge", the PR will be
+* "auto-merge": When a PR is labeled with "auto-merge", the PR will be
 automatically merged once CI passes.  In general, this label should only
-be used for small hot-fix (fewer than 100 lines) or automatic generated
+be used for small hot-fix (fewer than 100 lines) or automatically generated
 PRs.  If you're uncertain, it's usually the case that the PR is not
-qualified as "automerge".
+qualified as "auto-merge".
 
 * "good first issue": If you happen to find an issue that is non-urgent and
 self-contained with moderate scope, you might want to consider attaching
@@ -180,7 +180,7 @@ closed automatically 7 days later.
 ### How to manage review feedback?
 
 After a reviewer provides feedback, you can quickly say "acknowledged, will
-fix" using a thumb's up emoji. If you're confident your fix is exactly as
+fix" using a thumb 's-up emoji. If you're confident your fix is exactly as
 prescribed, add a reply "Fixed in COMMIT\_HASH" and mark the comment as
 resolved. If you're not sure, reply "Is this what you had in mind?
 COMMIT\_HASH" and if so, the reviewer will reply and mark the conversation as
@@ -203,7 +203,7 @@ your PR easy to say "yes" to.
 Non-exhaustive list of things that make it *harder* to review:
 
 * Additional changes that are orthogonal to the problem statement and proposed
-  changes. Instead move those changes to a different PR.
+  changes. Instead, move those changes to a different PR.
 * Renaming variables/functions/types unnecessarily and/or without explanation.
 * Not following established conventions in the function/module/crate/repo.
 * Changing whitespace: moving code and/or reformatting code. Make such changes
@@ -282,7 +282,7 @@ edition = "2021"
   installed, it will be updated automatically when you update the compiler with
 `rustup`.
 
-* All Rust code is linted with Clippy. If you'd prefer to ignore its advice, do
+* All Rust code is linked with Clippy. If you'd prefer to ignore its advice, do
   so explicitly:
 
   ```rust
@@ -299,7 +299,7 @@ has multiple instances of the same type, qualify each with a prefix and
 underscore (i.e. alice\_keypair) or a numeric suffix (i.e. tx0).
 
 * For function and method names, use `<verb>_<subject>`. For unit tests, that
-  verb should always be `test` and for benchmarks the verb should always be
+  verb should always be `test` and for benchmarks, the verb should always be
 `bench`. Avoid namespacing function names with some arbitrary word. Avoid
 abbreviating words in function names.
 

README.md

@@ -11,7 +11,7 @@
 
 # Building
 
-## **1. Install rustc, cargo and rustfmt.**
+## **1. Install rustc, cargo, and rustfmt.**
 
 ```bash
 $ curl https://sh.rustup.rs -sSf | sh
@@ -31,7 +31,7 @@ $ rustup install VERSION
 ```
 Note that if this is not the latest rust version on your machine, cargo commands may require an [override](https://rust-lang.github.io/rustup/overrides.html) in order to use the correct version.
 
-On Linux systems you may need to install libssl-dev, pkg-config, zlib1g-dev, protobuf etc.
+On Linux systems, you may need to install libssl-dev, pkg-config, zlib1g-dev, protobuf, etc.
 
 On Ubuntu:
 ```bash
@@ -107,7 +107,7 @@ productivity metric. When a developer makes a change to the codebase, presumably
 some problem.  Our unit-test suite is how we encode the set of *problems* the codebase solves. Running
 the test suite should indicate that your change didn't *infringe* on anyone else's solutions. Adding a
 test *protects* your solution from future changes. Say you don't understand why a line of code exists,
-try deleting it and running the unit-tests. The nearest test failure should tell you what problem
+try deleting it and running the unit tests. The nearest test failure should tell you what problem
 was solved by that code. If no test fails, go ahead and submit a Pull Request that asks, "what
 problem is solved by this code?" On the other hand, if a test does fail and you can think of a
 better way to solve the same problem, a Pull Request with your solution would most certainly be

RELEASE.md

@@ -81,7 +81,7 @@ for at least one full minor version before removal.
     git push -u origin <branchname>
     ```
 
-Alternatively use the Github UI.
+Alternatively, use the Github UI.
 
 ### Update master branch to the next release minor version
 
@@ -101,7 +101,7 @@ Alternatively use the Github UI.
     ci/channel-info.sh
     ```
 
-### Miscellaneous Clean up
+### Miscellaneous Clean-up
 
 1. Pin the spl-token-cli version in the newly promoted stable branch by setting `splTokenCliVersion` in scripts/spl-token-cli-version.sh to the latest release that depends on the stable branch (usually this will be the latest spl-token-cli release).
 1. Update [mergify.yml](https://github.com/anza-xyz/agave/blob/master/.mergify.yml) to add backport actions for the new branch and remove actions for the obsolete branch.
@@ -126,10 +126,10 @@ Alternatively use the Github UI.
 1. Ensure all desired commits (usually backports) are landed on the branch by now.
 1. Ensure the release is marked **"This is a pre-release"**.  This flag will need to be removed manually after confirming the Linux binary artifacts appear at a later step.
 1. Go back into edit the release and click "Publish release" while being marked as a pre-release.
-1. Confirm there is new git tag with intended version number at the intended revision after running `git fetch` locally.
+1. Confirm there is a new git tag with the intended version number at the intended revision after running `git fetch` locally.
 
 
-### Update release branch with the next patch version
+### Update the release branch with the next patch version
 
 [This action](https://github.com/anza-xyz/agave/blob/master/.github/workflows/increment-cargo-version-on-release.yml) ensures that publishing a release will trigger the creation of a PR to update the Cargo.toml files on **release branch** to the next semantic version (e.g. 0.9.0 -> 0.9.1). Ensure that the created PR makes it through CI and gets submitted.
 
@@ -148,7 +148,7 @@ appearing.  To check for progress:
 * The `agave-secondary` Buildkite pipeline handles creating the Linux and macOS release artifacts and updated crates.  Look for a job under the tag name of the release: https://buildkite.com/anza-xyz/agave-secondary.
 * The Windows release artifacts are produced by GitHub Actions.  Look for a job under the tag name of the release: https://github.com/anza-xyz/agave/actions.
 
-[Crates.io agave-validator](https://crates.io/crates/agave-validator) should have an updated agave-validator version.  This can take 2-3 hours, and sometimes fails in the `agave-secondary` job.
+[Crates.io agave-validator](https://crates.io/crates/agave-validator) should have an updated agave-validator version.  This can take 2-3 hours and sometimes fails in the `agave-secondary` job.
 If this happens and the error is non-fatal, click "Retry" on the "publish crate" job
 
 ### Update software on testnet.solana.com

SECURITY.md

@@ -26,7 +26,7 @@ Expect a response as fast as possible in the advisory, typically within 72 hours
 
 If you do not receive a response in the advisory, send an email to
 security@solana.com with the full URL of the advisory you have created.  DO NOT
-include attachments or provide detail sufficient for exploitation regarding the
+include attachments or provide details sufficient for exploitation regarding the
 security issue in this email. **Only provide such details in the advisory**.
 
 If you do not receive a response from security@solana.com please followup with
@@ -38,10 +38,10 @@ role in the channel and referencing the fact that you submitted a security probl
 ## Incident Response Process
 
 In case an incident is discovered or reported, the following process will be
-followed to contain, respond and remediate:
+followed to contain, respond, and remediate:
 
 ### 1. Accept the new report
-In response a newly reported security problem, a member of the
+In response to a newly reported security problem, a member of the
 `anza-xyz/admins` group will accept the report to turn it into a draft
 advisory.  The `anza-xyz/security-incident-response` group should be added to
 the draft security advisory, and create a private fork of the repository (grey
@@ -57,7 +57,7 @@ Within the draft security advisory, discuss and determine the severity of the is
 If it is determined that this is not a critical network issue then the advisory should be closed and if more follow-up is required a normal Solana public github issue should be created.
 
 ### 3. Prepare Fixes
-For the affected branches, typically all three (edge, beta and stable), prepare a fix for the issue and push them to the corresponding branch in the private repository associated with the draft security advisory.
+For the affected branches, typically all three (edge, beta, and stable), prepare a fix for the issue and push it to the corresponding branch in the private repository associated with the draft security advisory.
 There is no CI available in the private repository so you must build from source and manually verify fixes.
 Code review from the reporter is ideal, as well as from multiple members of the core development team.
 

docs/src/proposals.md

@@ -20,7 +20,7 @@ Each proposal may be implemented as described, implemented differently as issues
 
 These architectural proposals have been accepted and implemented by the Solana team.
 
-Any designs that may be subject to future change are noted in their specific proposal page.
+Any designs that may be subject to future change are noted on their specific proposal page.
 
 ## Submit a Design Proposal