From 19c6d9b6bfa0206bd46b457b892a22662fd86fe4 Mon Sep 17 00:00:00 2001 From: Waldir Pimenta Date: Wed, 17 Jan 2018 00:19:01 +0000 Subject: [PATCH] maintainers-guide.md: reword some passages for improved clarity --- contributing-guides/maintainers-guide.md | 34 +++++++++++++----------- 1 file changed, 19 insertions(+), 15 deletions(-) diff --git a/contributing-guides/maintainers-guide.md b/contributing-guides/maintainers-guide.md index fdd0ec8ba..0869a7eb2 100644 --- a/contributing-guides/maintainers-guide.md +++ b/contributing-guides/maintainers-guide.md @@ -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, 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 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.) 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. + so make sure it's clear that that we don't 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. +- 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. - 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, +- Although having 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, + This ensures that the entire process that regular contributors go through + is also exposed to maintainers, 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.