ctome
/
tldr
mirror of https://github.com/CrimsonTome/tldr.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

maintainers-guide.md: reword some passages for improved clarity

coverage
Waldir Pimenta 2018-01-17 00:19:01 +00:00
parent 1bef2e0a26
commit 19c6d9b6bf
1 changed files with 19 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
contributing-guides/maintainers-guide.md
View File

@ -10,7 +10,9 @@ for the behavior expected of tldr-pages maintainers:
**Be welcoming and friendly**, and if you don't know how to answer, **Be welcoming and friendly**, and if you don't know how to answer,
ping other maintainers who you think might have a say. ping other maintainers who you think might have a say.
- **Every new discussion should receive a response within 3 days (ideally)**. - **Help keep the project responsive**.
New discussion threads (issues or pull requests)
should receive a response within 3 days, ideally.
You can respond yourself You can respond yourself
or ask other members to provide their thoughts/opinions. or ask other members to provide their thoughts/opinions.
@ -29,24 +31,26 @@ for the behavior expected of tldr-pages maintainers:
(pull request, feature request, bug report, etc.) (pull request, feature request, bug report, etc.)
is a voluntary gift of time offered to the tldr project is a voluntary gift of time offered to the tldr project
by someone who cares about it, by someone who cares about it,
so make sure not to take it for granted. so make sure it's clear that that we don't take it for granted.
## II. Handling PRs ## II. Handling PRs
- When merging PRs, use the strategy that produces a **clean git history**: - When merging PRs, use the **merge strategy that produces a clean git history**:
Use squash if there's a single commit in the PR, If there's a single commit in the PR,
or if the multiple commits are not independent changes. or if the multiple commits are not semantically independent changes,
If the PR author took the time to craft individual, use the `Squash and merge` method.
informative commit messages for each commit, If the PR author took the time to craft
use rebase to honor that work and preserve the history of the changes. individual, informative messages for each commit,
use the `Rebase and merge` method,
to honor that work and preserve the history of the changes.
For less clear-cut cases, a simple heuristic you can follow
is that if there are more "dirty" commits than "clean" commits,
then prefer squash, else do a rebase.
A simple heuristic to follow is that if there are more "dirty" commits - Although having push access allows committing directly to the repository,
than "clean" commits, then prefer squash, else do a rebase.
- Although push access allows committing directly to the repository,
please **create pull requests for all of your changes**, please **create pull requests for all of your changes**,
except the simplest ones (e.g. typo fixes). except the simplest ones (e.g. typo fixes).
This ensures that the entire process other contributors go through This ensures that the entire process that regular contributors go through
is exposed to maintainers, is also exposed to maintainers,
who can then identify and address bottlenecks or inconveniences. who can then identify and address bottlenecks or inconveniences.
Similarly, **avoid merging your own PRs**. Similarly, **avoid merging your own PRs** unless approved by other maintainers.