add links to contributors guide
This commit is contained in:
Kevin Crawley
GitHub
parent
6ad79dcd45
commit
582d2540af
2 changed files with 4 additions and 95 deletions
|
|
@ -18,68 +18,13 @@
|
||||||
* Mathieu Lonjaret [@mpl](https://github.com/mpl)
|
* Mathieu Lonjaret [@mpl](https://github.com/mpl)
|
||||||
* Romain Tribotté [@rtribotte](https://github.com/rtribotte)
|
* 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
|
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).
|
||||||
* 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)
|
|
||||||
|
|
||||||
## PR review process:
|
## PR review process:
|
||||||
|
|
||||||
* The status `needs-design-review` is only used in complex/heavy/tricky PRs.
|
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.
|
||||||
* 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]
|
|
||||||
|
|
||||||
## Labels
|
## Labels
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -5,41 +5,5 @@ A Quick Guide for Efficient Contributions
|
||||||
|
|
||||||
So you've decided to improve Traefik?
|
So you've decided to improve Traefik?
|
||||||
Thank You!
|
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.
|
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).
|
||||||
|
|
||||||
## 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/).
|
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue