Merge pull request #8300

070e41d Change Github to GitHub (Abdullah)

5 files changed, 7 insertions, 7 deletions

diff --git a/README.md b/README.md
index 4fde29050..b3422280d 100644
--- a/README.md
+++ b/README.md
@@ -81,7 +81,7 @@ Monero is a private, secure, untraceable, decentralised digital currency. You ar
 
 This is the core implementation of Monero. It is open source and completely free to use without restrictions, except for those specified in the license agreement below. There are no restrictions on anyone creating an alternative implementation of Monero that uses the protocol and network in a compatible manner.
 
-As with many development projects, the repository on Github is considered to be the "staging" area for the latest changes. Before changes are merged into that branch on the main repository, they are tested by individual developers in their own branches, submitted as a pull request, and then subsequently tested by contributors who focus on testing and code reviews. That having been said, the repository should be carefully considered before using it in a production environment, unless there is a patch in the repository for a particular show-stopping issue you are experiencing. It is generally a better idea to use a tagged release for stability.
+As with many development projects, the repository on GitHub is considered to be the "staging" area for the latest changes. Before changes are merged into that branch on the main repository, they are tested by individual developers in their own branches, submitted as a pull request, and then subsequently tested by contributors who focus on testing and code reviews. That having been said, the repository should be carefully considered before using it in a production environment, unless there is a patch in the repository for a particular show-stopping issue you are experiencing. It is generally a better idea to use a tagged release for stability.
 
 **Anyone is welcome to contribute to Monero's codebase!** If you have a fix or code change, feel free to submit it as a pull request directly to the "master" branch. In cases where the change is relatively small or does not affect other parts of the codebase, it may be merged in immediately by any one of the collaborators. On the other hand, if the change is particularly large or complex, it is expected that it will be discussed at length either well in advance of the pull request being submitted, or even directly on the pull request.
 
@@ -757,7 +757,7 @@ For more detailed information see the ['Pruning' entry in the Moneropedia](https
 
 ## Debugging
 
-This section contains general instructions for debugging failed installs or problems encountered with Monero. First, ensure you are running the latest version built from the Github repo.
+This section contains general instructions for debugging failed installs or problems encountered with Monero. First, ensure you are running the latest version built from the GitHub repo.
 
 ### Obtaining stack traces and core dumps on Unix systems
 
diff --git a/contrib/gitian/DOCKRUN.md b/contrib/gitian/DOCKRUN.md
index 7f44b7914..9a9659473 100644
--- a/contrib/gitian/DOCKRUN.md
+++ b/contrib/gitian/DOCKRUN.md
@@ -70,7 +70,7 @@ The build should run to completion with no errors, and will display the SHA256 c
 of the resulting binaries. You'll be prompted to check if the sums look good, and if so
 then the results will be signed, and the signatures will be pushed to GitHub.
 
-***Note: In order to publish the signed assertions via this script, you need to have your SSH key uploaded to Github beforehand. See https://docs.github.com/articles/generating-an-ssh-key/ for more info.***
+***Note: In order to publish the signed assertions via this script, you need to have your SSH key uploaded to GitHub beforehand. See https://docs.github.com/articles/generating-an-ssh-key/ for more info.***
 
 You can also look in the [gitian.sigs](https://github.com/monero-project/gitian.sigs/) repo and / or [getmonero.org release checksums](https://web.getmonero.org/downloads/hashes.txt) to see if others got the same checksum for the same version tag.  If there is ever a mismatch -- **STOP! Something is wrong**.  Contact others on IRC / GitHub to figure out what is going on.
 
diff --git a/contrib/gitian/README.md b/contrib/gitian/README.md
index c922a2373..27f33831f 100644
--- a/contrib/gitian/README.md
+++ b/contrib/gitian/README.md
@@ -136,7 +136,7 @@ GH_USER=YOUR_GITHUB_USER_NAME
 VERSION=v0.17.2.0
 ```
 
-Where `GH_USER` is your Github user name and `VERSION` is the version tag you want to build. 
+Where `GH_USER` is your GitHub user name and `VERSION` is the version tag you want to build. 
 
 Setup for LXC:
 
diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md
index 14b52a2af..a50114d1a 100644
--- a/docs/CONTRIBUTING.md
+++ b/docs/CONTRIBUTING.md
@@ -12,7 +12,7 @@ of software solid and usable.
 * If modifying code for which Doxygen headers exist, that header must be modified to match.
 * Tests would be nice to have if you're adding functionality.
 
-Patches are preferably to be sent via a Github pull request. If that
+Patches are preferably to be sent via a GitHub pull request. If that
 can't be done, patches in "git format-patch" format can be sent
 (eg, posted to fpaste.org with a long enough timeout and a link
 posted to #monero-dev on irc.libera.chat).
@@ -43,7 +43,7 @@ Commit messages should be sensible. That means a subject line that
 describes the patch, with an optional longer body that gives details,
 documentation, etc.
 
-When submitting a pull request on Github, make sure your branch is
+When submitting a pull request on GitHub, make sure your branch is
 rebased. No merge commits nor stray commits from other people in
 your submitted branch, please. You may be asked to rebase if there
 are conflicts (even trivially resolvable ones).
diff --git a/src/net/zmq.cpp b/src/net/zmq.cpp
index bd7855f21..2b3ca8376 100644
--- a/src/net/zmq.cpp
+++ b/src/net/zmq.cpp
@@ -134,7 +134,7 @@ namespace zmq
         {
             /* ZMQ documentation states that message parts are atomic - either
                all are received or none are. Looking through ZMQ code and
-               Github discussions indicates that after part 1 is returned,
+               GitHub discussions indicates that after part 1 is returned,
                `EAGAIN` cannot be returned to meet these guarantees. Unit tests
                verify (for the `inproc://` case) that this is the behavior. 
                Therefore, read errors after the first part are treated as a