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, 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.

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 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.
  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.
  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/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.
Ready to try Contour?

Read our getting started documentation.