lilith/tldr
1
0
Fork 0
mirror of https://github.com/tldr-pages/tldr.git synced 2025-04-29 23:24:55 +02:00
Code Activity

maintainers-guide.md: reorder content and add section headings

Browse source
This commit is contained in:
Waldir Pimenta 2018-01-17 00:15:17 +00:00
parent fa274ad9f1
commit 1bef2e0a26
1 changed files with 22 additions and 18 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

40
contributing-guides/maintainers-guide.md
View file

@ -3,33 +3,17 @@
The following guidelines are meant to provide a general basis The following guidelines are meant to provide a general basis
for the behavior expected of tldr-pages maintainers: for the behavior expected of tldr-pages maintainers:
## I. Responding to contributions
- When responding to issues or pull requests, - When responding to issues or pull requests,
remember that you're temporarily the face of the tldr-pages project. 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, **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.
- Although push access allows committing directly to the repository,
plase **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**.
- **Every new discussion should receive a response within 3 days (ideally)**. - **Every new discussion 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.
- 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.
- **Know when and how to say no**. - **Know when and how to say no**.
Sometimes requests or contributions need to be declined, Sometimes requests or contributions need to be declined,
at least in their current form. at least in their current form.
@ -46,3 +30,23 @@ for the behavior expected of tldr-pages maintainers:
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 not to take it for granted.
## 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**.