This page captures how we work on Contour.
When you pick up an issue, assign it to yourself. When you stop working, unassigned yourself. While you hold an issue, you are responsible for giving status reports on it; over communicate, don’t let others speak for you, or worse, guess.
Don’t work on an issue assigned to someone else. If you think they’re overcomitted or stuck, please ask.
Don’t assign an issue to someone else without talking to them directly.
Hoarding issues is not saving for a rainy day, you can only work on one thing at a time, you should avoid holding more than one issue at a time.
Log an issue or it didn’t happen.
When submitting a PR add the appropriate release milestone and also add the appropriate Github “release-note” label if this PR warrants getting called out in the next release.
Everyone is responsible for code reviews. If someone asks you for a review, or they use GitHub for the same, you should aim to review it (timezones permitting) promptly. Your aim is to give feedback, not land the as soon as you are asked to review it.
The smaller the change, the better the PR process works. Everything flows from this statement.
Talk about what you intend to do, then do the thing you talked about. GitHub review tools suck for extended debate, if you find you’re taking past your reviewer, its a sign that more design is needed.
Before you fix a bug, write a test to show you fixed it.
Before you add a feature, write a test so someone else doesn’t break your feature by accident.
You are permitted to refactor as much as you like to achieve these goals. As Kent beck said, “make the change easy, then make the easy change.”
Github issues should be triaged and have their status recorded. Triaging issues and labeling them appropriately makes it easy for the issue submitter and other contributors to see what the state of an issue is at any time. The goal of triaging an issue is to make a decision about what should be done with it. The issue should investigated enough to fully understand and document the problem and then decide whether the issue should be addressed by the project. It may not be necessary to decide how an issue should be addressed during triage, since that could involve substantial research and design.
Label | Description |
---|---|
good first issue | Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. |
help wanted | Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. |
release-note | Denotes a PR that will be considered when it comes time to generate release notes. |
release-note-action-required | Denotes a PR that introduces potentially breaking changes that require user action. |
area/dependency | Issues or PRs related to dependency changes. |
area/deployment | Issues or PRs related to deployment tooling or infrastructure. |
area/documentation | Issues or PRs related to documentation. |
area/httpproxy | Issues or PRs related to the HTTPProxy API. |
area/ingressroute | Issues or PRs related to the IngressRoute API. |
area/ingress | Issues or PRs related to the Ingress API. |
area/service-apis | Issues or PRs related to the Gateway (Service APIs working group) API. |
area/website | Issues or PRs related to the web site. |
area/testing | Issues or PRs related to tests or testing tools. |
area/status | Issues or PRs related to exposing status for APIs. |
area/metrics | Issues or PRs related to exposing time series metrics. |
area/tooling | Issues or PRs related to project tools and automation. |
area/tls | Issues or PRs related to TLS support. |
area/operational | Issues or PRs about making Contour easier to operate as a production service. |
blocked/needs-info | Categorizes the issue or PR as blocked because there is insufficient information to advance it. |
blocked/needs-product | Categorizes the issue or PR as blocked because it needs a decision from product management. |
blocked/needs-design | Categorizes the issue or PR as blocked because it needs a design document. |
blocked/needs-envoy | Categorizes the issue or PR as blocked because it needs changes in Envoy. |
kind/api-change | Categorizes issue or PR as related to adding, removing, or otherwise changing an API |
kind/bug | Categorizes issue or PR as related to a bug. |
kind/cleanup | Categorizes issue or PR as related to cleaning up code, process, or technical debt. |
kind/deprecation | Categorizes issue or PR as related to a feature/enhancement marked for deprecation. |
kind/design | Categorizes issue or PR as related to design. |
kind/failing-test | Categorizes issue or PR as related to a consistently or frequently failing test. |
kind/feature | Categorizes issue or PR as related to a new feature. |
kind/flake | Categorizes issue or PR as related to a flaky test. |
kind/regression | Categorizes issue or PR as related to a regression from a prior release. |
kind/question | Categorizes an issue as a user question. |
lifecycle/needs-triage | Indicates that an issue needs to be triaged by a project contributor. |
lifecycle/frozen | Indicates that an issue or PR should not be auto-closed due to staleness. |
lifecycle/stale | Denotes an issue or PR has remained open with no activity and has become stale. |
lifecycle/investigating | Denotes an issue that is assigned and is being actively investigated by the issue owner. |
lifecycle/accepted | Denotes an issue that has been triaged and determined to be valid. |
priority/awaiting-more-evidence | Lowest priority. Possibly useful, but not yet enough support to actually get it done. |
priority/backlog | Higher priority than priority/awaiting-more-evidence. |
priority/critical-urgent | Highest priority. Must be actively worked on as someone's top priority right now. |
priority/important-soon | Must be staffed and worked on either currently, or very soon, ideally in time for the next release. |
priority/important-longterm | Important over the long term, but may not be staffed and/or may need multiple releases to complete. |
size/L | Denotes a PR that changes 100-499 lines, ignoring generated files. |
size/M | Denotes a PR that changes 30-99 lines, ignoring generated files. |
size/S | Denotes a PR that changes 10-29 lines, ignoring generated files. |
size/XL | Denotes a PR that changes 500-999 lines, ignoring generated files. |
size/XS | Denotes a PR that changes 0-9 lines, ignoring generated files. |
size/XXL | Denotes a PR that changes 1000+ lines, ignoring generated files. |
Hacktoberfest | Denotes an issue ready for any "Hacktoberfest" contributor. |
Read our getting started documentation.