fix: update links and improve documentation accuracy

RELEASE.md

@@ -26,7 +26,7 @@ stabilization branches.
 Merging to `master` first also helps ensure that fixes applied to one release
 are present for future releases.  (Sometimes the joy of landing a critical
 release blocker in a branch causes you to forget to propagate back to
-`master`!)"
+`master`!)
 
 Once the bug fix lands on `master` it is cherry-picked into the `vX.Y` branch
 and potentially the `vX.Y-1` branch.  The exception to this rule is when a bug
@@ -76,7 +76,7 @@ There are three release channels that map to branches as follows:
     git push -u origin <branchname>
     ```
 
-Alternatively use the Github UI.
+Alternatively use the GitHub UI.
 
 ### Update master branch to the next release minor version
 
@@ -86,7 +86,7 @@ Alternatively use the Github UI.
      ```
 1. Push all the changed Cargo.toml and Cargo.lock files to the `master` branch with something like:
     ```
-    git co -b version_update
+    git switch -c version_update
     git ls-files -m | xargs git add
     git commit -m 'Bump version to X.Y+1.0'
     git push -u origin version_update
@@ -99,7 +99,7 @@ Alternatively use the Github UI.
 ### Miscellaneous Clean up
 
 1. Update [mergify.yml](https://github.com/solana-labs/solana/blob/master/.mergify.yml) to add backport actions for the new branch and remove actions for the obsolete branch.
-1. Adjust the [Github backport labels](https://github.com/solana-labs/solana/labels) to add the new branch label and remove the label for the obsolete branch.
+1. Adjust the [GitHub backport labels](https://github.com/solana-labs/solana/labels) to add the new branch label and remove the label for the obsolete branch.
 1. Announce on Discord #development that the release branch exists so people know to use the new backport labels.
 
 ## Steps to Create a Release
@@ -130,7 +130,7 @@ Alternatively use the Github UI.
 ### Prepare for the next release
 1.  Go to [GitHub Releases](https://github.com/solana-labs/solana/releases) and create a new draft release for `X.Y.Z+1` with empty release notes.  This allows people to incrementally add new release notes until it's time for the next release
     1. Also, point the branch field to the same branch and mark the release as **"This is a pre-release"**.
-1.  Go to the [Github Milestones](https://github.com/solana-labs/solana/milestones).  Create a new milestone for the `X.Y.Z+1`, move over
+1.  Go to the [GitHub Milestones](https://github.com/solana-labs/solana/milestones).  Create a new milestone for the `X.Y.Z+1`, move over
 unresolved issues still in the `X.Y.Z` milestone, then close the `X.Y.Z` milestone.
 
 ### Verify release automation success

docs/docusaurus.config.js

@@ -167,7 +167,7 @@ module.exports = {
             },
             {
               label: "Twitter »",
-              href: "https://twitter.com/solana",
+              href: "https://x.com/solana",
             },
             {
               label: "Forum »",

geyser-plugin-interface/README.md

@@ -6,7 +6,7 @@
 
 # Solana Geyser Plugin Interface
 
-This crate enables an plugin to be added into the Solana Validator runtime to
+This crate enables a plugin to be added into the Solana Validator runtime to
 take actions at the time of account updates or block and transaction processing;
 for example, saving the account state to an external database. The plugin must
 implement the `GeyserPlugin` trait. Please see the detail of the

metrics/README.md

@@ -4,10 +4,10 @@
 
 ## InfluxDB
 
-In oder to explore validator specific metrics from mainnet-beta, testnet or devnet you can use Chronograf:
+In order to explore validator specific metrics from mainnet-beta, testnet or devnet you can use Chronograf:
 
-* https://metrics.solana.com:8888/ (production enviroment)
-* https://metrics.solana.com:8889/ (testing enviroment)
+* https://metrics.solana.com:8888/ (production environment)
+* https://metrics.solana.com:8889/ (testing environment)
 
 For local cluster deployments you should use:
 
@@ -32,7 +32,7 @@ The cluster telemetry dashboard shows the current state of the cluster:
 
 1. Cluster Stability
 2. Validator Streamer
-3. Tomer Consensus
+3. Tower Consensus
 4. IP Network
 5. Snapshots
 6. RPC Send Transaction Service
@@ -41,10 +41,10 @@ The cluster telemetry dashboard shows the current state of the cluster:
 
 The fee market dashboard shows:
 
-1. Total Priorization Fees
-2. Block Min Priorization Fees
+1. Total Prioritization Fees
+2. Block Min Prioritization Fees
 3. Cost Tracker Stats
 
 ### Ping Results
 
-The ping reults dashboard displays relevant information about the Ping API
+The Ping results dashboard displays relevant information about the Ping API

net/README.md

@@ -5,7 +5,7 @@ intended to be both dev and CD friendly.
 
 ### User Account Prerequisites
 
-GCP, AWS, colo are supported.
+GCP, AWS, colo is supported.
 
 #### GCP
 First authenticate with
@@ -21,8 +21,7 @@ $ aws configure
 More information on AWS CLI configuration can be found [here](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-quick-configuration)
 
 ### Metrics configuration (Optional)
-Ensure that `$(whoami)` is the name of an InfluxDB user account with enough
-access to create a new InfluxDB database.  Ask mvines@ for help if needed.
+Ensure that $(whoami) matches an InfluxDB user account with sufficient access to create a new InfluxDB database.  Ask mvines@ for help if needed.
 
 ## Quick Start
 
@@ -34,7 +33,7 @@ $ cd net/
 $ ./gce.sh create -n 5 -c 1     #<-- Create a GCE testnet with 5 additional nodes (beyond the bootstrap node) and 1 client (billing starts here)
 $ ./init-metrics.sh $(whoami)   #<-- Recreate a metrics database for the testnet and configure credentials
 $ ./net.sh start                #<-- Deploy the network from the local workspace and start processes on all nodes including bench-tps on the client node
-$ ./ssh.sh                      #<-- Show a help to ssh into any testnet node to access logs/etc
+$ ./ssh.sh                      #<-- Show help to ssh into any testnet node to access logs/etc
 $ ./net.sh stop                 #<-- Stop running processes on all nodes
 $ ./gce.sh delete               #<-- Dispose of the network (billing stops here)
 ```
@@ -43,7 +42,7 @@ $ ./gce.sh delete               #<-- Dispose of the network (billing stops here)
 
 ### Running the network over public IP addresses
 By default private IP addresses are used with all instances in the same
-availability zone to avoid GCE network engress charges.  However to run the
+availability zone to avoid GCE network egress charges.  However to run the
 network over public IP addresses:
 ```bash
 $ ./gce.sh create -P ...
@@ -76,7 +75,7 @@ is detected at runtime and the CUDA build is auto selected.
 
 ### Partition testing
 
-To induce the partition `net.sh netem --config-file <config file path>`
+To induce partitioning, run net.sh netem --config-file <config file path>`
 To remove partition `net.sh netem --config-file <config file path> --netem-cmd cleanup`
 The partitioning is also removed if you do `net.sh stop` or `restart`.