fix: corrected typos (#104)

Corrected typos and improved clarity in the forking section.

Author: KittyChiu

tooling/github-configuration.md

@@ -91,7 +91,7 @@ Forking and branching are two alternatives for code development work.
 Forking can be important for enabling quick or one-off InnerSource contributions to public or internally visible repositories as no prior conversations or permissions are required by the owning team to submit a pull request. 
 In an example where a repository holds the code for a web site, someone not associated with the website might see a broken leak to their site and want to submit a fix. If that repository only supports branching development, that user 
 has to find who is the best person to talk to about that repository, email them, wait for a response, probably send a few more emails, get write permissions, start a branch, make one line change, and submit a pull request. 
-This could take a day or 30 days. Many potential small changes will simply never start or die somewhere alnog the process. In constrast with forking, that same user can fork the repository, make the change, and submit a pull request
+This could take a day or 30 days. Many potential small changes will simply never start or die somewhere along the process. In constrast with forking, that same user can fork the repository, make the change, and submit a pull request
 back to the repository. They don't have to wait for a return email or any communication. They can simply do the change and submit it. This type of quick development is not always appropriate and many repositories might 
 perfer to always use branch-based development. However, for some small contributions by someone not on the team that owns the repository, forking is a great enabler of small scale InnerSource. 
 
@@ -101,9 +101,9 @@ perfer to always use branch-based development. However, for some small contribut
 | Enabled | Organizations always allow private and internal repositories to be forked. | Encourage forking of private and internal repositories to promote collaboration and foster a culture of contribution. Forking enables individuals or teams to make modifications and propose changes without directly impacting the original codebase. |
 | Disabled | Organizations never allow private or internal repositories to be forked. | In an InnerSource context, it is recommended to enable forking to encourage collaboration, knowledge sharing, and innovation. Forking allows individuals or teams to experiment, improve, and contribute without directly modifying the original codebase. |
 
-One consideration for whether to enable forking is whether the GitHub instance in question is purely internal or not. A company may want to limit forking of internal code in private repositories of a public-facing GitHub instance to personal user space repository. In this scenario, branch development only may be appriate. In constrast, if the GitHub Enterprise instance is only internal code and all users have company created GitHub identities that can not fork into public repositories, then forking could be enabled into private repositories at much lower risk as those repositories are still under corporate control and not public facing. Additionally, if normal users lack the ability to make repositories public by themselves, there is  less risk. Certain enterprises, organizations, or repositories may need to disable forking partially or entirely for their specific regulatory or compliance requirements.
+One consideration for whether to enable forking is whether the GitHub instance in question is purely internal or not. A company may want to limit forking of internal code in private repositories of a public-facing GitHub instance to personal user space repository. In this scenario, branch development only may be appropriate. In constrast, if the GitHub Enterprise instance is only internal code and all users have company created GitHub identities that can not fork into public repositories, then forking could be enabled into private repositories at much lower risk as those repositories are still under corporate control and not public facing. Additionally, if normal users lack the ability to make repositories public by themselves, there is  less risk. Certain enterprises, organizations, or repositories may need to disable forking partially or entirely for their specific regulatory or compliance requirements.
 
-*Enabling forking is good for InnerSource as it is lower friction way to quickly make small contributions compared to branch-based development. Seek to combine configuration with architecture to enable it as an option without increasing risk of accidental disclosure. When forking is enabled, individual repositories should always have the option to turn it off.*
+*Enabling forking is good for InnerSource as it lowers the friction to quickly make small contributions compared to branch-based development. Seek to combine configuration with architecture to enable it as an option without increasing risk of accidental disclosure. When forking is enabled, individual repositories should always have the option to turn it off.*
 
 ## Organization Setting
 Within each Organization, administrators of that organiation can pick base permissions for all repositories in that organization.