From a77d38f04059d4febd2aba8b5656a826af51d9e7 Mon Sep 17 00:00:00 2001
From: yeshu <673643706@qq.com>
Date: Sat, 2 Jul 2022 00:38:24 +0800
Subject: [PATCH] Fix CONTRIBUTING doc typo issues (#1266)

---
 CONTRIBUTING.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 847e3ac..0c966e4 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -21,7 +21,7 @@ issue, please bring it to their attention right away!
 Please **DO NOT** file a public issue, instead send your report privately to
 [xuri.me](https://xuri.me).
 
-Security reports are greatly appreciated and we will publicly thank you for it.
+Security reports are greatly appreciated and we will publicly thank you for them.
 We currently do not offer a paid security bounty program, but are not
 ruling it out in the future.
 
@@ -103,14 +103,14 @@ Before contributing large or high impact changes, make the effort to coordinate
 with the maintainers of the project before submitting a pull request. This
 prevents you from doing extra work that may or may not be merged.
 
-Large PRs that are just submitted without any prior communication are unlikely
+Large PRs that are just submitted without any prior communication is unlikely
 to be successful.
 
 While pull requests are the methodology for submitting changes to code, changes
 are much more likely to be accepted if they are accompanied by additional
 engineering work. While we don't define this explicitly, most of these goals
-are accomplished through communication of the design goals and subsequent
-solutions. Often times, it helps to first state the problem before presenting
+are accomplished through the communication of the design goals and subsequent
+solutions. Oftentimes, it helps to first state the problem before presenting
 solutions.
 
 Typically, the best methods of accomplishing this are to submit an issue,
@@ -130,7 +130,7 @@ written in the imperative, followed by an optional, more detailed explanatory
 text which is separated from the summary by an empty line.
 
 Commit messages should follow best practices, including explaining the context
-of the problem and how it was solved, including in caveats or follow up changes
+of the problem and how it was solved, including in caveats or follow-up changes
 required. They should tell the story of the change and provide readers
 understanding of what led to it.
 
@@ -260,7 +260,7 @@ Don't forget: being a maintainer is a time investment. Make sure you
 will have time to make yourself available. You don't have to be a
 maintainer to make a difference on the project!
 
-If you want to become a meintainer, contact [xuri.me](https://xuri.me) and given a introduction of you.
+If you want to become a maintainer, contact [xuri.me](https://xuri.me) and given an introduction of you.
 
 ## Community guidelines
 
@@ -414,7 +414,7 @@ The first sentence should be a one-sentence summary that starts with the name be
 
 It's helpful if everyone using the package can use the same name
 to refer to its contents, which implies that the package name should
-be good: short, concise, evocative. By convention, packages are
+be good: short, concise, and evocative. By convention, packages are
 given lower case, single-word names; there should be no need for
 underscores or mixedCaps. Err on the side of brevity, since everyone
 using your package will be typing that name. And don't worry about