Update Documents to Improve Consistency (apache#47341)

* Update "Report Bugs" section to use "GitHub Issues" for consistency

* Fix typos in documentation regarding GitHub references

* Update "Github" to "GitHub" for consistency

Author: choo121600

COMMITTERS.rst

@@ -212,7 +212,7 @@ To be able to merge PRs, committers have to integrate their GitHub ID with Apach
 
 1.  Verify you have a GitHub ID `enabled with 2FA <https://help.github.com/articles/securing-your-account-with-two-factor-authentication-2fa/>`__.
 2.  Merge your Apache and GitHub accounts using `GitBox (Apache Account Linking utility) <https://gitbox.apache.org/setup/>`__. This also asks you to link your
-    Github id to your Apache account. You should see 5 green checks in GitBox.
+    GitHub ID to your Apache account. You should see 5 green checks in GitBox.
 3.  Wait at least 30  minutes for an email inviting you to Apache GitHub Organization and accept invitation.
 4.  After accepting the GitHub Invitation verify that you are a member of the `Airflow committers team on GitHub <https://github.com/orgs/apache/teams/airflow-committers>`__.
 5.  Ask in ``#internal-airflow-ci-cd`` channel to be `configured in self-hosted runners <https://github.com/apache/airflow-ci-infra/blob/main/scripts/list_committers>`_
@@ -221,7 +221,7 @@ To be able to merge PRs, committers have to integrate their GitHub ID with Apach
 
     * ``dev/breeze/src/airflow_breeze/global_constants.py`` (COMMITTERS variable)
     * name and GitHub ID in `project.rst <https://github.com/apache/airflow/blob/main/docs/apache-airflow/project.rst>`__.
-    * If you had been a collaborator role before getting committer, remove your Github ID from ``.asf.yaml``.
+    * If you had been a collaborator role before getting committer, remove your GitHub ID from ``.asf.yaml``.
 7.  Raise a PR to `airflow-site <https://github.com/apache/airflow-site>`_ repository with the following additions:
 
     * List your name(s) in the `committers list <https://github.com/apache/airflow-site/blob/main/landing-pages/site/data/committers.json>`__.

ISSUE_TRIAGE_PROCESS.rst

@@ -129,7 +129,7 @@ There are several actions an issue triager might take:
 Labels
 ''''''
 
-Since Apache Airflow uses "GitHub Issues" and "Github Discussions" as the
+Since Apache Airflow uses "GitHub Issues" and "GitHub Discussions" as the
 issue tracking systems, the use of labels is extensive. Though issue
 labels tend to change over time based on components within the project,
 the majority of the ones listed below should stand the test of time.
@@ -256,7 +256,7 @@ once the issue is accepted (and assigned with relevant kind and area labels). Th
 ask for other members of the community for consultation or ask for further information from the issue author.
 Removing the ``needs-triage`` label means that the issue has been accepted and awaits implementation (no further triage action required),
 as long as the ``needs-triage`` label remains the triage team will keep an eye on the issue and check periodically
-if it needs to be accepted or closed/converted to Github Discussion.
+if it needs to be accepted or closed/converted to GitHub Discussion.
 ``needs-triage`` label may also be applied manually by committers if they think a further action from the triage team is required.
 
 **area Label**

contributing-docs/01_roles_in_airflow_project.rst

@@ -45,7 +45,7 @@ code is maintained.
 The term "committer" and "maintainer" is used interchangeably. The term "committer" is the official term used by the
 Apache Software Foundation, while "maintainer" is more commonly used in the Open Source community and is used
 in context of GitHub in a number of guidelines and documentation, so this document will mostly use "maintainer",
-when speaking about Github, Pull Request, Github Issues and Discussions. On the other hand, "committer" is more
+when speaking about GitHub, Pull Request, GitHub Issues and Discussions. On the other hand, "committer" is more
 often used in devlist discussions, official communications, Airflow website and every time when we formally
 refer to the role.
 

contributing-docs/04_how_to_contribute.rst

@@ -26,7 +26,7 @@ some of those ways that involve creating issues and pull requests on GitHub.
 Report Bugs
 -----------
 
-Report bugs through `GitHub <https://github.com/apache/airflow/issues>`__.
+Report bugs through `GitHub Issues <https://github.com/apache/airflow/issues>`__.
 
 Please report relevant information and preferably code that exhibits the problem.
 

dev/breeze/doc/09_release_management_tasks.rst

@@ -193,7 +193,7 @@ Adding git tags for providers
 """""""""""""""""""""""""""""
 
 This command can be utilized to manage git tags for providers within the airflow remote repository during provider releases.
-Sometimes in cases when there is a connectivity issue to Github, it might be possible that local tags get created and lead to annoying errors.
+Sometimes in cases when there is a connectivity issue to GitHub, it might be possible that local tags get created and lead to annoying errors.
 The default behaviour would be to clean such local tags up.
 
 The flag ``--clean-local-tags`` can be used to delete the local tags.

dev/breeze/doc/adr/0013-get-rid-of-submodules.md

@@ -66,12 +66,12 @@ by definitions should be easy to do, otherwise they are not getting done regular
 ## Decision
 
 The decision is to use the approach suggested by
-[Github Actions Security Hardening](https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions)
+[GitHub Actions Security Hardening](https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions)
 by simply pinning the potentially insecure GitHub Actions via full-length SHA of the commit
 
 The point 2) about submodules should take the following form
 
-2) For security reason for non-GitHub owned actions (which are heavily protected asset of Github Actions
+2) For security reason for non-GitHub owned actions (which are heavily protected asset of GitHub Actions
    and compromising them would mean compromising the whole GitHub Actions infrastructure) we use full-length
    SHA of the action to refer to the action code. We do it after careful review of the action code - with the
    comment explaining version of the action the SHA refers to. When we upgrade the action we update the SHA

dev/breeze/doc/ci/01_ci_environment.md

@@ -62,7 +62,7 @@ To run the tests, we need to ensure that the images are built using the
 latest sources and that the build process is efficient. A full rebuild
 of such an image from scratch might take approximately 15 minutes.
 Therefore, we've implemented optimization techniques that efficiently
-use the cache from Github Actions Artifacts.
+use the cache from GitHub Actions Artifacts.
 
 ## GitHub Registry used as cache
 

dev/breeze/doc/ci/02_images.md

@@ -572,4 +572,4 @@ percent-encoded when you access them via UI (/ = %2F)
 
 ----
 
-Read next about [Github Variables](03_github_variables.md)
+Read next about [GitHub Variables](03_github_variables.md)

dev/breeze/doc/ci/03_github_variables.md

@@ -63,7 +63,7 @@ Example command to build your CI image efficiently in your own CI
 workflow:
 
 ``` bash
-# GITHUB_REPOSITORY is set automatically in Github Actions so we need to override it with flag
+# GITHUB_REPOSITORY is set automatically in GitHub Actions so we need to override it with flag
 #
 breeze ci-image build --github-repository apache/airflow --python 3.10
 docker tag ghcr.io/apache/airflow/main/ci/python3.10 your-image-name:tag

dev/breeze/doc/ci/04_selective_checks.md

@@ -163,7 +163,7 @@ providers.
 The selective check outputs available are described below. In case of `list-as-string` values,
 empty string means `everything`, where lack of the output means `nothing` and list elements are
 separated by spaces. This is to accommodate for the wau how outputs of this kind can be easily used by
-Github Actions to pass the list of parameters to a command to execute
+GitHub Actions to pass the list of parameters to a command to execute
 
 
 | Output                                         | Meaning of the output                                                                                  | Example value                           | List |

dev/breeze/doc/ci/06_debugging.md

@@ -21,11 +21,11 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**  *generated with [DocToc](https://github.com/thlorenz/doctoc)*
 
-- [Debugging CI Jobs in Github Actions and changing their behaviour](#debugging-ci-jobs-in-github-actions-and-changing-their-behaviour)
+- [Debugging CI Jobs in GitHub Actions and changing their behaviour](#debugging-ci-jobs-in-github-actions-and-changing-their-behaviour)
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 
-# Debugging CI Jobs in Github Actions and changing their behaviour
+# Debugging CI Jobs in GitHub Actions and changing their behaviour
 
 The CI jobs are notoriously difficult to test, because you can only
 really see results of it when you run them in CI environment, and the

docs/README.rst

@@ -41,7 +41,7 @@ When you make changes to the docs, it follows roughly the same process as creati
 1. **Decide to edit in GitHub UI or locally** - Depending on the size and type of docs update you want to make, it might be easier to work in the UI or to make your edits in a local fork.
 2. **Find the source files to edit** - While you can access most of the docs source files using the **Suggest a change on this page** button or by searching for a string in the ``/docs/`` file directory, in some cases, the source strings might be located in different provider docs or in the source code itself.
 3. **If editing locally, run spellcheck and the build to identify any blocking errors** - Docs require build, spellcheck, and precommit CI/CD tests to pass before they can merge. This means that if you have a pull request with docs changes, a docs build error can prevent your code merge. Checking the build and spelling locally first can help speed up reviews. If you made formatting changes, checking a local build of your docs allows you to make sure you correctly formatted elements like tables, text styling, and line breaks.
-4. **Make your pull request** - When you make a PR, Github automatically assigns reviewers and runs CI/CD tests.
+4. **Make your pull request** - When you make a PR, GitHub automatically assigns reviewers and runs CI/CD tests.
 5. **Fix any build errors or spelling mistakes** - Your PR can't be merged if there are any spelling or build errors. Check to see which builds are failing and click **Show details**. The output of the tests share the errors, location of the problems, and suggest resolutions. Common Docs failures occur due to incorrect formatting and whitespace.
 
 Editing in GitHub or locally