How We Work
This page captures how we work on Contour.
Github Issue Management
When you pick up an issue, assign it to yourself. When you stop working, unassign 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 over committed 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.
Code reviews
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.
Coding Practices
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 Labels
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 be 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.
- To be considered triaged, an issue must have the “lifecycle/accepted” label.
- If you are in the process of investigating an issue, assign it to yourself and apply the “lifecycle/investigating” label.
- In almost all cases, triaged issues should have kind and area labels.
- The priority and size labels are informative. Contributors should apply them at their discretion.
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. |
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. |
area/service-mesh | Issues or PRs about making Contour interoperate with service meshes. Contour is not a service mesh. |
area/sticky-session | Issues or PRs about Contour's support for sticky sessions. |
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. |
blocked/needs-gateway-api | Categorizes the issue or PR as blocked because it needs changes in Gateway API. |
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/decision | Categorizes issue as a decision to be voted on. |
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. |
doc-impact | Indicates that an issue or PR needs attention from a technical writer or a docs update. |
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. |
release-note/major | A major change that needs more than a paragraph of explanation in the release notes. |
release-note/minor | A minor change that needs about a paragraph of explanation in the release notes. |
release-note/small | A small change that needs one line of explanation in the release notes. |
release-note/docs | A documentation change for the release notes. |
release-note/infra | An infrastructure update for the release notes. |
release-note/deprecation | A deprecation or removal that needs about a paragraph of explanation in the release notes. |
release-note/none-required | Marks a PR as not requiring a release note. Should only be used for very small changes. |