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-17 00:19:01 +00:00
|
|
|
- **Help keep the project responsive**.
|
|
|
|
New discussion threads (issues or pull requests)
|
|
|
|
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,
|
2018-01-17 00:19:01 +00:00
|
|
|
so make sure it's clear that that we don't take it for granted.
|
2018-01-17 00:15:17 +00:00
|
|
|
|
|
|
|
## II. Handling PRs
|
|
|
|
|
2018-01-17 00:19:01 +00:00
|
|
|
- When merging PRs, use the **merge strategy that produces a clean git history**:
|
|
|
|
If there's a single commit in the PR,
|
|
|
|
or if the multiple commits are not semantically independent changes,
|
|
|
|
use the `Squash and merge` method.
|
|
|
|
If the PR author took the time to craft
|
|
|
|
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.
|
|
|
|
|
|
|
|
- Although having push access allows committing directly to the repository,
|
2018-01-17 00:15:17 +00:00
|
|
|
please **create pull requests for all of your changes**,
|
|
|
|
except the simplest ones (e.g. typo fixes).
|
2018-01-17 00:19:01 +00:00
|
|
|
This ensures that the entire process that regular contributors go through
|
|
|
|
is also exposed to maintainers,
|
2018-01-17 00:15:17 +00:00
|
|
|
who can then identify and address bottlenecks or inconveniences.
|
2018-01-17 00:19:01 +00:00
|
|
|
Similarly, **avoid merging your own PRs** unless approved by other maintainers.
|