p30928647
/
excelize
1
0
Fork 1
Code Issues Pull Requests Projects Releases 23 Wiki Activity

Fix CONTRIBUTING doc typo issues (#1266)

This commit is contained in:
yeshu 2022-07-02 00:38:24 +08:00 committed by GitHub
parent 18afc88759
commit a77d38f040
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
CONTRIBUTING.md
View File

@ -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 Please **DO NOT** file a public issue, instead send your report privately to
[xuri.me](https://xuri.me). [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 We currently do not offer a paid security bounty program, but are not
ruling it out in the future. 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 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. 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. to be successful.
While pull requests are the methodology for submitting changes to code, changes 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 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 engineering work. While we don't define this explicitly, most of these goals
are accomplished through communication of the design goals and subsequent are accomplished through the communication of the design goals and subsequent
solutions. Often times, it helps to first state the problem before presenting solutions. Oftentimes, it helps to first state the problem before presenting
solutions. solutions.
Typically, the best methods of accomplishing this are to submit an issue, 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. text which is separated from the summary by an empty line.
Commit messages should follow best practices, including explaining the context 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 required. They should tell the story of the change and provide readers
understanding of what led to it. 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 will have time to make yourself available. You don't have to be a
maintainer to make a difference on the project! 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 ## 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 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 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 given lower case, single-word names; there should be no need for
underscores or mixedCaps. Err on the side of brevity, since everyone underscores or mixedCaps. Err on the side of brevity, since everyone
using your package will be typing that name. And don't worry about using your package will be typing that name. And don't worry about