From 1bef2e0a26cab2fe816fbc2bc706cc7398acab9c Mon Sep 17 00:00:00 2001 From: Waldir Pimenta Date: Wed, 17 Jan 2018 00:15:17 +0000 Subject: [PATCH] maintainers-guide.md: reorder content and add section headings --- contributing-guides/maintainers-guide.md | 40 +++++++++++++----------- 1 file changed, 22 insertions(+), 18 deletions(-) diff --git a/contributing-guides/maintainers-guide.md b/contributing-guides/maintainers-guide.md index dd033ea724..fdd0ec8bad 100644 --- a/contributing-guides/maintainers-guide.md +++ b/contributing-guides/maintainers-guide.md @@ -3,33 +3,17 @@ The following guidelines are meant to provide a general basis for the behavior expected of tldr-pages maintainers: +## I. Responding to contributions + - 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. -- 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)**. You can respond yourself 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**. Sometimes requests or contributions need to be declined, 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 by someone who cares about it, 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**.