Guidelines Update
This commit is contained in:
Gérald Croës
GitHub
parent
3de29433f8
commit
cd326654a7
|
|
@ -47,6 +47,18 @@ Further details of specific enforcement policies may be posted separately.
|
|||
|
||||
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
|
||||
|
||||
When an inapropriate behavior is reported, maintainers will discuss on the Maintainer's Discord before marking the message as "abuse".
|
||||
This conversation beforehand avoids one-sided decisions.
|
||||
|
||||
The first message will be edited and marked as abuse.
|
||||
The second edited message and marked as abuse results in a 7-day ban.
|
||||
The third edited message and marked as abuse results in a permanent ban.
|
||||
|
||||
The content of edited messages is:
|
||||
`Dear user, we want traefik to provide a welcoming and respectful environment. Your [comment/issue/PR] has been reported and marked as abuse according to our [Code of Conduct](./CODE_OF_CONDUCT.md). Thank you.`
|
||||
|
||||
The [report must be resolved](https://docs.github.com/en/communities/moderating-comments-and-conversations/managing-reported-content-in-your-organizations-repository#resolving-a-report) accordingly.
|
||||
|
||||
## Attribution
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
---
|
||||
title: "Traefik Advocation Documentation"
|
||||
description: "There are many ways to contribute to Traefik Proxy. If you're talking about Traefik, let us know and we'll promote your enthusiasm!"
|
||||
description: "There are many ways to contribute to Traefik Proxy. Let us know if you’re talking about Traefik, and we'll promote your enthusiasm!"
|
||||
---
|
||||
|
||||
# Advocating
|
||||
|
||||
Spread the Love & Tell Us about It
|
||||
Spread the Love & Tell Us About It
|
||||
{: .subtitle }
|
||||
|
||||
Traefik Proxy was started by the community for the community.
|
||||
Traefik Proxy was started by the community and for the community.
|
||||
You can contribute to the Traefik community in three main ways:
|
||||
|
||||
**Spread the word!** Guides, videos, blog posts, how-to articles, and showing off your network design all help spread the word about Traefik Proxy
|
||||
|
|
|
|||
|
|
@ -7,89 +7,75 @@ description: "Interested in contributing more to the community and becoming a Tr
|
|||
|
||||
|
||||
|
||||
Note: the document is a work in progress.
|
||||
|
||||
Welcome to the Traefik Community.
|
||||
This document describes how to be part of the core team
|
||||
together with various responsibilities
|
||||
and guidelines for Traefik maintainers.
|
||||
|
||||
We are strongly promoting a philosophy of openness and sharing,
|
||||
and firmly standing against the elitist closed approach.
|
||||
Being part of the core team should be accessible to anyone motivated
|
||||
and wants to be part of that journey!
|
||||
|
||||
## Onboarding Process
|
||||
## Becoming a Maintainer
|
||||
|
||||
If you consider joining our community, please drop us a line using Twitter or leave a note in the issue.
|
||||
We will schedule a quick call to meet you and learn more about your motivation.
|
||||
During the call, the team will discuss the process of becoming a maintainer.
|
||||
We will be happy to answer any questions and explain all your doubts.
|
||||
Before a contributor becomes a maintainer, they should meet the following requirements:
|
||||
|
||||
## Maintainer's Requirements
|
||||
- The contributor enabled [2FA](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication) on their GitHub account
|
||||
|
||||
Note: you do not have to meet all the listed requirements,
|
||||
but must have achieved several.
|
||||
- The contributor showed a consistent pattern of helpful, non-threatening, and friendly behavior towards other community members in the past.
|
||||
|
||||
- The contributor has read and accepted the maintainer's guidelines.
|
||||
|
||||
The contributor should also meet one or several of the following requirements:
|
||||
|
||||
- Enabled [2FA](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication) on your GitHub account
|
||||
- The contributor has opened and successfully run medium to large PR’s in the past 6 months.
|
||||
|
||||
- The contributor has participated in multiple code reviews of other PR’s,
|
||||
including those of other maintainers and contributors.
|
||||
- The contributor showed a consistent pattern of helpful, non-threatening, and friendly behavior towards other community members in the past.
|
||||
|
||||
- The contributor is active on Traefik Community forums
|
||||
or other technical forums/boards such as K8S slack, Reddit, StackOverflow, hacker news.
|
||||
- Have read and accepted the contributor guidelines.
|
||||
|
||||
Any existing active maintainer can create an issue to discuss promoting a contributor to maintainer.
|
||||
Other maintainers can vote on the issue, and if the quorum is reached, the contributor is promoted to maintainer.
|
||||
If the quorum is not reached within one month after the issue is created, it is closed.
|
||||
|
||||
## Maintainer's Responsibilities and Privileges
|
||||
|
||||
There are lots of areas where you can contribute to the project,
|
||||
but we can suggest you start with activities such as:
|
||||
As a maintainer, you are granted a vote for the following:
|
||||
|
||||
- PR reviewing.
|
||||
- According to our guidelines we require you have at least 3 reviewers,
|
||||
thus you can review a PR and leave the relevant comment if it is necessary.
|
||||
- Participating in a daily [issue triage](https://github.com/traefik/contributors-guide/blob/master/issue_triage.md).
|
||||
- The process helps to understand and prioritize the reported issue according to its importance and severity.
|
||||
This is crucial to learn how our users implement Traefik.
|
||||
Each of the issues that are labeled as bug/possible bug/confirmed requires a reproducible use case.
|
||||
You can help in creating a reproducible use case if it has not been added to the issue
|
||||
or use the sample code provided by the reporter.
|
||||
Typically, a simple Docker Compose should be enough to reproduce the issue.
|
||||
- Code contribution.
|
||||
- Documentation contribution.
|
||||
- Technical documentation is one of the most important components of the product.
|
||||
The ability to set up a testing environment in a few minutes,
|
||||
using the official documentation,
|
||||
is a game changer.
|
||||
- You will be listed on our Maintainers GitHub page
|
||||
and on our website in the section [maintainers](maintainers.md).
|
||||
- We will be promoting you on social channels (mostly on Twitter).
|
||||
- [PR review](https://github.com/traefik/contributors-guide/blob/master/pr_guidelines.md).
|
||||
|
||||
## Governance
|
||||
- [Design review](https://github.com/traefik/contributors-guide/blob/master/proposals.md).
|
||||
|
||||
- Roadmap meetings on a regular basis where all maintainers are welcome.
|
||||
- [Proposals](https://github.com/traefik/contributors-guide/blob/master/proposals.md).
|
||||
|
||||
Maintainers are also added to the maintainer's Discord server where happens the [issue triage](https://github.com/traefik/contributors-guide/blob/master/issue_triage.md)
|
||||
and appear on the [Maintainers](maintainers.md) page.
|
||||
|
||||
As a maintainer, you should:
|
||||
|
||||
- Prioritize PR reviews, design reviews, and issue triage above any other task.
|
||||
|
||||
Making sure contributors and community members are listened to and have an impact on the project is essential to keeping the project active and develop a thriving community.
|
||||
|
||||
- Prioritize helping contributors reaching the expecting quality level over rewriting contributions.
|
||||
|
||||
Any triage activity on issues and PRs (e.g. labels, marking messages as off-topic, refusing, marking duplicates) should result from a collective decision to ensure knowledge is shared among maintainers.
|
||||
|
||||
## Communicating
|
||||
|
||||
- All of our maintainers are added to the Traefik Maintainers Discord server that belongs to Traefik labs.
|
||||
Having the team in one place helps us to communicate effectively.
|
||||
You can reach Traefik core developers directly,
|
||||
which offers the possibility to discuss issues, pull requests, enhancements more efficiently
|
||||
Maintainers can discuss issues, pull requests, enhancements more efficiently
|
||||
and get the feedback almost immediately.
|
||||
Fewer blockers mean more fun and engaging work.
|
||||
|
||||
- On a daily basis, we publish a report that includes all the activities performed during the day.
|
||||
You are updated in regard to the workload that has been processed including:
|
||||
working on the new features and enhancements,
|
||||
activities related to the reported issues and PR’s,
|
||||
other important project-related announcements.
|
||||
- Every decision made on the discord server among maintainers is documented so it's visible to the rest of the community.
|
||||
|
||||
- At 2:15pm CET every Monday and Thursday we review all the created issues that have been reported,
|
||||
assign them the appropriate *[labels](maintainers.md#labels)*
|
||||
and prioritize them based on the severity of the problem.
|
||||
The process is called *[issue triaging](https://github.com/traefik/contributors-guide/blob/master/issue_triage.md)*.
|
||||
Each of the maintainers is welcome to join the meeting.
|
||||
For that purpose, we use the Traefik Maintainers Discord server
|
||||
where you are invited once you have become an official maintainer.
|
||||
- Maintainers express their opinions on issues and reviews.
|
||||
It is fine to have different point of views.
|
||||
We encourage active and open conversations which goals are to improve Traefik.
|
||||
|
||||
- When discussing issues and proposals, maintainers should share as much information as possible to help solve the issue.
|
||||
|
||||
## Maintainers Activity
|
||||
|
||||
|
|
@ -97,38 +83,45 @@ In order to keep the core team efficient and dynamic,
|
|||
maintainers' activity and involvement will be reviewed on a regular basis.
|
||||
|
||||
- Has the maintainer engaged with the team and the community by meeting two or more of these benchmarks in the past six months?
|
||||
|
||||
- Has the maintainer participated in at least two or three maintainer meetings?
|
||||
|
||||
- Substantial review of at least one or two PRs from either contributors or maintainers.
|
||||
|
||||
- Opened at least one or two bug fixes or feature request PRs
|
||||
that were eventually merged (or on a trajectory for merge).
|
||||
|
||||
- Substantial participation in the Help Wanted program (answered questions, helped identify issues, applied guidelines from the Help Wanted guide to open issues).
|
||||
|
||||
- Substantial participation with the community in general.
|
||||
|
||||
- Has the maintainer shown a consistent pattern of helpful,
|
||||
non-threatening,
|
||||
and friendly behavior towards other people on the maintainer team and with our community?
|
||||
|
||||
## Additional Comments for (not only) Maintainers
|
||||
## Additional Comments for Maintainers (that should apply to any contributor)
|
||||
|
||||
- Be respectful with other maintainers and other community members.
|
||||
|
||||
- Be open minded when participating in conversations: try to put yourself in others’ shoes.
|
||||
|
||||
- Be able to put yourself in users’ shoes.
|
||||
- Be open-minded and respectful with other maintainers and other community members.
|
||||
- Keep the communication public -
|
||||
if anyone tries to communicate with you directly,
|
||||
ask politely to move the conversation to a public communication channel.
|
||||
|
||||
- Stay away from defensive comments.
|
||||
|
||||
- Please try to express your thoughts clearly enough
|
||||
and note that some of us are not native English speakers.
|
||||
Try to rephrase your sentences, avoiding mental shortcuts;
|
||||
none of us is able to predict your thoughts.
|
||||
- There are a lot of use cases of using Traefik
|
||||
and even more issues that are difficult to reproduce.
|
||||
If the issue can’t be replicated due to a lack of reproducible case (a simple Docker Compose should be enough) -
|
||||
set your time limits while working on the issue
|
||||
and express clearly that you were not able to replicate it.
|
||||
You can come back later to that case.
|
||||
none of us is able to predict anyone's thoughts.
|
||||
|
||||
- Be proactive.
|
||||
|
||||
- Emoji are fine,
|
||||
but if you express yourself clearly enough they are not necessary.
|
||||
They will not replace good communication.
|
||||
- Embrace mentorship.
|
||||
- Keep in mind that we all have the same intent to improve the project.
|
||||
|
||||
- Embrace mentorship: help others grow and match the quality level we strive for.
|
||||
|
||||
- Keep in mind that we all have the same goal: improve the project.
|
||||
|
|
|
|||
|
|
@ -5,18 +5,13 @@ description: "Traefik Proxy is an open source software with a thriving community
|
|||
|
||||
# Maintainers
|
||||
|
||||
## The Team
|
||||
## Active Maintainers
|
||||
|
||||
* Emile Vauge [@emilevauge](https://github.com/emilevauge)
|
||||
* Vincent Demeester [@vdemeester](https://github.com/vdemeester)
|
||||
* Ed Robinson [@errm](https://github.com/errm)
|
||||
* Daniel Tomcej [@dtomcej](https://github.com/dtomcej)
|
||||
* Manuel Zapf [@SantoDE](https://github.com/SantoDE)
|
||||
* Timo Reimann [@timoreimann](https://github.com/timoreimann)
|
||||
* Ludovic Fernandez [@ldez](https://github.com/ldez)
|
||||
* Julien Salleyron [@juliens](https://github.com/juliens)
|
||||
* Nicolas Mengin [@nmengin](https://github.com/nmengin)
|
||||
* Marco Jantke [@mjantke](https://github.com/mjeri)
|
||||
* Michaël Matur [@mmatur](https://github.com/mmatur)
|
||||
* Gérald Croës [@geraldcroes](https://github.com/geraldcroes)
|
||||
* Jean-Baptiste Doumenjou [@jbdoumenjou](https://github.com/jbdoumenjou)
|
||||
|
|
@ -27,108 +22,16 @@ description: "Traefik Proxy is an open source software with a thriving community
|
|||
* Tom Moulard [@tommoulard](https://github.com/tommoulard)
|
||||
* Landry Benguigui [@lbenguigui](https://github.com/lbenguigui)
|
||||
|
||||
## Past Maintainers
|
||||
|
||||
People who have had an incredibly positive impact on the project, and are now focusing on other projects.
|
||||
|
||||
* Vincent Demeester [@vdemeester](https://github.com/vdemeester)
|
||||
* Ed Robinson [@errm](https://github.com/errm)
|
||||
* Daniel Tomcej [@dtomcej](https://github.com/dtomcej)
|
||||
* Timo Reimann [@timoreimann](https://github.com/timoreimann)
|
||||
* Marco Jantke [@mjantke](https://github.com/mjeri)
|
||||
|
||||
## Maintainer's Guidelines
|
||||
|
||||
Please read the [maintainer's guidelines](maintainers-guidelines.md)
|
||||
|
||||
## Issue Triage
|
||||
|
||||
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 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
|
||||
|
||||
A maintainer that looks at an issue/PR must define its `kind/*`, `area/*`, and `status/*`.
|
||||
|
||||
### Status - Workflow
|
||||
|
||||
The `status/*` labels represent the desired state in the workflow.
|
||||
|
||||
* `status/0-needs-triage`: all the new issues and PRs have this status. _[bot only]_
|
||||
* `status/1-needs-design-review`: needs a design review. **(only for PR)**
|
||||
* `status/2-needs-review`: needs a code/documentation review. **(only for PR)**
|
||||
* `status/3-needs-merge`: ready to merge. **(only for PR)**
|
||||
* `status/4-merge-in-progress`: merge is in progress. _[bot only]_
|
||||
|
||||
### Contributor
|
||||
|
||||
* `contributor/need-more-information`: we need more information from the contributor in order to analyze a problem.
|
||||
* `contributor/waiting-for-feedback`: we need the contributor to give us feedback.
|
||||
* `contributor/waiting-for-corrections`: we need the contributor to take actions in order to move forward with a PR. **(only for PR)** _[bot, humans]_
|
||||
* `contributor/needs-resolve-conflicts`: use it only when there is some conflicts (and an automatic rebase is not possible). **(only for PR)** _[bot, humans]_
|
||||
|
||||
### Kind
|
||||
|
||||
* `kind/enhancement`: a new or improved feature.
|
||||
* `kind/question`: a question. **(only for issue)**
|
||||
* `kind/proposal`: a proposal that needs to be discussed.
|
||||
* _Proposal issues_ are design proposals
|
||||
* _Proposal PRs_ are technical prototypes that need to be refined with multiple contributors.
|
||||
|
||||
* `kind/bug/possible`: a possible bug that needs analysis before it is confirmed or fixed. **(only for issues)**
|
||||
* `kind/bug/confirmed`: a confirmed bug (reproducible). **(only for issues)**
|
||||
* `kind/bug/fix`: a bug fix. **(only for PR)**
|
||||
|
||||
### Resolution
|
||||
|
||||
* `resolution/duplicate`: a duplicate issue/PR.
|
||||
* `resolution/declined`: declined (Rule #1 of open-source: no is temporary, yes is forever).
|
||||
* `WIP`: Work In Progress. **(only for PR)**
|
||||
|
||||
### Platform
|
||||
|
||||
* `platform/windows`: Windows related.
|
||||
|
||||
### Area
|
||||
|
||||
* `area/acme`: ACME related.
|
||||
* `area/api`: Traefik API related.
|
||||
* `area/authentication`: Authentication related.
|
||||
* `area/cluster`: Traefik clustering related.
|
||||
* `area/documentation`: Documentation related.
|
||||
* `area/infrastructure`: CI or Traefik building scripts related.
|
||||
* `area/healthcheck`: Health-check related.
|
||||
* `area/logs`: Logs related.
|
||||
* `area/middleware`: Middleware related.
|
||||
* `area/middleware/metrics`: Metrics related. (Prometheus, StatsD, ...)
|
||||
* `area/middleware/tracing`: Tracing related. (Jaeger, Zipkin, ...)
|
||||
* `area/oxy`: Oxy related.
|
||||
* `area/provider`: related to all providers.
|
||||
* `area/provider/boltdb`: Boltd DB related.
|
||||
* `area/provider/consul`: Consul related.
|
||||
* `area/provider/docker`: Docker and Swarm related.
|
||||
* `area/provider/ecs`: ECS related.
|
||||
* `area/provider/etcd`: Etcd related.
|
||||
* `area/provider/eureka`: Eureka related.
|
||||
* `area/provider/file`: file provider related.
|
||||
* `area/provider/k8s`: Kubernetes related.
|
||||
* `area/provider/kv`: KV related.
|
||||
* `area/provider/marathon`: Marathon related.
|
||||
* `area/provider/mesos`: Mesos related.
|
||||
* `area/provider/rancher`: Rancher related.
|
||||
* `area/provider/servicefabric`: Azure service fabric related.
|
||||
* `area/provider/zk`: Zoo Keeper related.
|
||||
* `area/rules`: Rules related.
|
||||
* `area/server`: Server related.
|
||||
* `area/sticky-session`: Sticky session related.
|
||||
* `area/tls`: TLS related.
|
||||
* `area/websocket`: WebSocket related.
|
||||
* `area/webui`: Web UI related.
|
||||
|
||||
### Issues Priority
|
||||
|
||||
* `priority/P0`: needs hot fix.
|
||||
* `priority/P1`: need to be fixed in next release.
|
||||
* `priority/P2`: need to be fixed in the future.
|
||||
* `priority/P3`: maybe.
|
||||
|
||||
### PR Size
|
||||
|
||||
Automatically set by a bot.
|
||||
|
||||
* `size/S`: small PR.
|
||||
* `size/M`: medium PR.
|
||||
* `size/L`: Large PR.
|
||||
Please read the [maintainer's guidelines](maintainers-guidelines.md).
|
||||
|
|
|
|||
|
|
@ -11,8 +11,8 @@ Help Us Help You!
|
|||
Issues are perfect for requesting a feature/enhancement or reporting a suspected bug.
|
||||
We use the [GitHub issue tracker](https://github.com/traefik/traefik/issues) to keep track of issues in Traefik.
|
||||
|
||||
The process of sorting and checking the issues is a daunting task, and requires a lot of work (more than an hour a day ... just for sorting).
|
||||
To help us (and other community members) quickly and effortlessly understand what you need,
|
||||
The process of sorting and checking the issues is a daunting task, and requires a lot of work.
|
||||
To help maintainers (and other community members) quickly and effortlessly understand what you need,
|
||||
be sure to follow the guidelines below.
|
||||
|
||||
!!! important "Getting Help Vs Reporting an Issue"
|
||||
|
|
|
|||
|
|
@ -17,12 +17,9 @@ or the list of [confirmed bugs](https://github.com/traefik/traefik/labels/kind%2
|
|||
|
||||
## How We Prioritize
|
||||
|
||||
We wish we could review every pull request right away.
|
||||
Unfortunately, our team has to prioritize pull requests (PRs) for review
|
||||
(but we are welcoming new [maintainers](https://github.com/traefik/traefik/blob/master/docs/content/contributing/maintainers-guidelines.md) to speed this up,
|
||||
if you are interested, check it out and apply).
|
||||
We wish we could review every pull request right away, but because it's a time consuming operation, it's not always possible.
|
||||
|
||||
The PRs we are able to handle fastest are:
|
||||
The PRs we are able to handle the fastest are:
|
||||
|
||||
* Documentation updates.
|
||||
* Bug fixes.
|
||||
|
|
@ -59,7 +56,7 @@ Merging a PR requires the following steps to be completed before it is merged au
|
|||
* Ensure your PR is not a draft. We do not review drafts, but do answer questions and confer with developers on them as needed.
|
||||
* Pass the validation check.
|
||||
* Pass all tests.
|
||||
* Receive 3 approving reviews maintainers.
|
||||
* Receive 3 approving reviews from maintainers.
|
||||
|
||||
## Pull Request Review Cycle
|
||||
|
||||
|
|
@ -198,7 +195,7 @@ here are some things you can do to move the process along:
|
|||
* If you have fixed all the issues from a review,
|
||||
remember to re-request a review (using the designated button) to let your reviewer know that you are ready.
|
||||
You can choose to comment with the changes you made.
|
||||
* Ping `@tfny` if you have not been assigned to a reviewer.
|
||||
* Kindly comment on the pull request. Doing so will automatically give your PR visibility during the triage process.
|
||||
|
||||
For more information on best practices, try these links:
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ _You_ Made It
|
|||
{: .subtitle}
|
||||
|
||||
Traefik Proxy truly is an [open-source project](https://github.com/traefik/traefik/),
|
||||
and wouldn't have become what it is today without the help of our [many contributors](https://github.com/traefik/traefik/graphs/contributors) (at the time of writing this),
|
||||
and wouldn't have become what it is today without the help of our [many contributors](https://github.com/traefik/traefik/graphs/contributors),
|
||||
not accounting for people having helped with issues, tests, comments, articles, ... or just enjoy using Traefik Proxy and share with others.
|
||||
|
||||
So once again, thank you for your invaluable help in making Traefik such a good product!
|
||||
|
|
@ -17,16 +17,16 @@ So once again, thank you for your invaluable help in making Traefik such a good
|
|||
!!! question "Where to Go Next?"
|
||||
If you want to:
|
||||
|
||||
- Propose and idea, request a feature a report a bug,
|
||||
read the page [Submitting Issues](./submitting-issues.md).
|
||||
- Propose an idea, request a feature, or report a bug,
|
||||
then read [Submitting Issues](./submitting-issues.md).
|
||||
- Discover how to make an efficient contribution,
|
||||
read the page [Submitting Pull Requests](./submitting-pull-requests.md).
|
||||
then read [Submitting Pull Requests](./submitting-pull-requests.md).
|
||||
- Learn how to build and test Traefik,
|
||||
the page [Building and Testing](./building-testing.md) is for you.
|
||||
then the page [Building and Testing](./building-testing.md) is for you.
|
||||
- Contribute to the documentation,
|
||||
read the related page [Documentation](./documentation.md).
|
||||
then read the page about [Documentation](./documentation.md).
|
||||
- Understand how do we learn about Traefik usage,
|
||||
read the [Data Collection](./data-collection.md) page.
|
||||
- Spread the love about Traefik, please check the [Advocating](./advocating.md) page.
|
||||
- Learn about who are the maintainers and how they work on the project,
|
||||
read the [Maintainers](./maintainers.md) page.
|
||||
read the [Maintainers](./maintainers.md) and [Maintainer Guidelines](./maintainers-guidelines.md) pages.
|
||||
|
|
|
|||
Loading…
Reference in a new issue