diff --git a/docs/content/contributing/maintainers.md b/docs/content/contributing/maintainers.md index ac13e8b8d..1c00666a5 100644 --- a/docs/content/contributing/maintainers.md +++ b/docs/content/contributing/maintainers.md @@ -18,68 +18,13 @@ * Mathieu Lonjaret [@mpl](https://github.com/mpl) * Romain Tribotté [@rtribotte](https://github.com/rtribotte) -## Contributions Daily Meeting +## Issue Triage -* 3 Maintainers should attend to a Contributions Daily Meeting where we sort and label new issues ([is:issue label:status/0-needs-triage](https://github.com/traefik/traefik/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Astatus%2F0-needs-triage+)), and review every Pull Requests -* Every pull request should be checked during the Contributions Daily Meeting - * Even if it’s already assigned - * Even PR labelled with `contributor/waiting-for-corrections` or `contributor/waiting-for-feedback` -* Issues labeled with `priority/P0` and `priority/P1` should be assigned. -* Modifying an issue or a pull request (labels, assignees, milestone) is only possible: - * During the Contributions Daily Meeting - * By an assigned maintainer - * In case of emergency, if a change proposal is approved by 2 other maintainers (on Slack, Discord, Discourse, etc) +Issues and PRs are triaged daily and the process for triaging may be found under [triaging issues](https://github.com/traefik/contributors-guide/blob/master/issue_triage.md) in our [contributors guide repository](https://github.com/traefik/contributors-guide). ## PR review process: -* The status `needs-design-review` is only used in complex/heavy/tricky PRs. -* From `1` to `2`: 1 comment that says “design LGTM” (by a senior maintainer). -* From `2` to `3`: 3 LGTM approvals by any maintainer. -* If needed, a specific maintainer familiar with a particular domain can be requested for the review. -* If a PR has been implemented in pair programming, one peer's LGTM goes into the review for free -* Amending someone else's pull request is authorized only in emergency, if a rebase is needed, or if the initial contributor is silent - -We use [PRM](https://github.com/ldez/prm) to manage locally pull requests. - -## Bots - -### [Myrmica Lobicornis](https://github.com/traefik/lobicornis/) - -Update and Merge Pull Request. - -The maintainer giving the final LGTM must add the `status/3-needs-merge` label to trigger the merge bot. - -By default, a squash-rebase merge will be carried out. -To preserve commits, add `bot/merge-method-rebase` before `status/3-needs-merge`. - -The status `status/4-merge-in-progress` is only used by the bot. - -If the bot is not able to perform the merge, the label `bot/need-human-merge` is added. -In such a situation, solve the conflicts/CI/... and then remove the label `bot/need-human-merge`. - -To prevent the bot from automatically merging a PR, add the label `bot/no-merge`. - -The label `bot/light-review` decreases the number of required LGTM from 3 to 1. - -This label is used when: - -* Updating the vendors from previously reviewed PRs -* Merging branches into the master -* Preparing the release - -### [Myrmica Bibikoffi](https://github.com/traefik/bibikoffi/) - -* closes stale issues [cron] - * use some criterion as number of days between creation, last update, labels, ... - -### [Myrmica Aloba](https://github.com/traefik/aloba) - -Manage GitHub labels. - -* Add labels on new PR [GitHub WebHook] -* Add milestone to a new PR based on a branch version (1.4, 1.3, ...) [GitHub WebHook] -* Add and remove `contributor/waiting-for-corrections` label when a review request changes [GitHub WebHook] -* Weekly report of PR status on Slack (CaptainPR) [cron] +The process for reviewing PRs may be found under [review guidelines](https://github.com/traefik/contributors-guide/blob/master/review_guidelines.md) in our contributors guide repository. ## Labels diff --git a/docs/content/contributing/submitting-pull-requests.md b/docs/content/contributing/submitting-pull-requests.md index b388e4fa0..4bec80a78 100644 --- a/docs/content/contributing/submitting-pull-requests.md +++ b/docs/content/contributing/submitting-pull-requests.md @@ -5,41 +5,5 @@ A Quick Guide for Efficient Contributions So you've decided to improve Traefik? Thank You! -Now the last step is to submit your Pull Request in a way that makes sure it gets the attention it deserves. -Let's go through the classic pitfalls to make sure everything is right. - -## Title - -The title must be short and descriptive. (~60 characters) - -## Description - -Follow the [pull request template](https://github.com/traefik/traefik/blob/master/.github/PULL_REQUEST_TEMPLATE.md) as much as possible. - -Explain the conditions which led you to write this PR: give us context. -The context should lead to something, an idea or a problem that you’re facing. - -Remain clear and concise. - -Take time to polish the format of your message so we'll enjoy reading it and working on it. -Help the readers focus on what matters, and help them understand the structure of your message (see the [Github Markdown Syntax](https://help.github.com/articles/github-flavored-markdown)). - -## PR Content - -- Make it small. -- One feature per Pull Request. -- Write useful descriptions and titles. -- Avoid re-formatting code that is not on the path of your PR. -- Make sure the [code builds](building-testing.md). -- Make sure [all tests pass](building-testing.md). -- Add tests. -- Address review comments in terms of additional commits (and don't amend/squash existing ones unless the PR is trivial). - -!!! note "Third-Party Dependencies" - - If a PR involves changes to third-party dependencies, the commits pertaining to the vendor folder and the manifest/lock file(s) should be committed separated. - -!!! tip "10 Tips for Better Pull Requests" - - We enjoyed this article, maybe you will too! [10 tips for better pull requests](https://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/). +Please review the [guidelines on creating PRs](https://github.com/traefik/contributors-guide/blob/master/pr_guidelines.md) for Traefik in our [contributors guide repository](https://github.com/traefik/contributors-guide).