2017-12-27 00:47:36 +00:00
|
|
|
# Maintainer's guide
|
|
|
|
|
|
|
|
|
|
The following guidelines are meant to provide a general basis
|
|
|
|
|
for the behavior expected of tldr-pages maintainers:
|
|
|
|
|
|
2018-01-17 00:15:17 +00:00
|
|
|
## I. Responding to contributions
|
|
|
|
|
|
2017-12-27 00:47:36 +00:00
|
|
|
- When responding to issues or pull requests,
|
|
|
|
|
remember that you're temporarily the face of the tldr-pages project.
|
|
|
|
|
**Be welcoming and friendly**, and if you don't know how to answer,
|
|
|
|
|
ping other maintainers who you think might have a say.
|
|
|
|
|
|
2018-01-09 10:42:47 +00:00
|
|
|
- **Every new discussion should receive a response within 3 days (ideally)**.
|
2018-01-09 09:54:19 +00:00
|
|
|
You can respond yourself
|
|
|
|
|
or ask other members to provide their thoughts/opinions.
|
2017-12-27 00:47:36 +00:00
|
|
|
|
|
|
|
|
- **Know when and how to say no**.
|
2018-01-09 09:54:19 +00:00
|
|
|
Sometimes requests or contributions need to be declined,
|
|
|
|
|
at least in their current form.
|
2017-12-27 00:47:36 +00:00
|
|
|
The project has developed multiple guidelines over time to handle edge cases
|
|
|
|
|
— get acquainted with them, and point them out when necessary.
|
2018-01-09 09:54:19 +00:00
|
|
|
Be polite, but firm: it saves everyone's time and patience
|
|
|
|
|
to make expectations clear early.
|
2017-12-27 00:47:36 +00:00
|
|
|
|
|
|
|
|
- Always remember to **thank every contribution**,
|
|
|
|
|
even when it can't be accepted (in fact, especially then).
|
2018-01-09 09:54:19 +00:00
|
|
|
Keep in mind that
|
|
|
|
|
[every form of contribution](https://github.com/kentcdodds/all-contributors)
|
2017-12-27 00:47:36 +00:00
|
|
|
(pull request, feature request, bug report, etc.)
|
2018-01-09 09:54:19 +00:00
|
|
|
is a voluntary gift of time offered to the tldr project
|
|
|
|
|
by someone who cares about it,
|
2017-12-27 00:47:36 +00:00
|
|
|
so make sure not to take it for granted.
|
2018-01-17 00:15:17 +00:00
|
|
|
|
|
|
|
|
## II. Handling PRs
|
|
|
|
|
|
|
|
|
|
- When merging PRs, use the strategy that produces a **clean git history**:
|
|
|
|
|
Use squash if there's a single commit in the PR,
|
|
|
|
|
or if the multiple commits are not independent changes.
|
|
|
|
|
If the PR author took the time to craft individual,
|
|
|
|
|
informative commit messages for each commit,
|
|
|
|
|
use rebase to honor that work and preserve the history of the changes.
|
|
|
|
|
|
|
|
|
|
A simple heuristic to follow is that if there are more "dirty" commits
|
|
|
|
|
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**,
|
|
|
|
|
except the simplest ones (e.g. typo fixes).
|
|
|
|
|
This ensures that the entire process other contributors go through
|
|
|
|
|
is exposed to maintainers,
|
|
|
|
|
who can then identify and address bottlenecks or inconveniences.
|
|
|
|
|
Similarly, **avoid merging your own PRs**.
|
