forked from p30928647/excelize
Fix CONTRIBUTING doc typo issues (#1266)
This commit is contained in:
parent
18afc88759
commit
a77d38f040
|
@ -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,13 +103,13 @@ 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
|
||||
are accomplished through the communication of the design goals and subsequent
|
||||
solutions. Oftentimes, it helps to first state the problem before presenting
|
||||
solutions.
|
||||
|
||||
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue