As a community, Knative values lazy consensus as a decision-making tool. Having discussions about larger changes or contentious issues mainly over synchronous meetings makes it difficult for contributors in differing time zones to participate. Compounding the problem is the fact that there are also Slack conversations on various channels, emails, etc. that make it difficult to decipher what led to various decisions and what alternatives were considered and so forth. We use “lazy consensus” as a mode of operation towards asynchronous communication will help get to a healthier and more inclusive community.

When

Lazy consensus is about decisions of consequence. This is a somewhat fuzzy concept, and we will not attempt to make a specific definition to be followed. Instead, this can be thought of as a judgement call to make.

A decision of consequence is something that as a contributor, you or one of your open source colleagues would feel that they have a stake in. It might be something as specific as a polarizing pull request. It might be the direction a feature track will go in. It might be a plan within a working group for a refactoring. It may or may not have representation in github or a document.

When deciding whether lazy consensus is required, you and your peers must think about the following:

• How would you feel if the decision was made without your input?
• How would your peers not present in the discussion feel if the decision was made without their input?

If you think about these questions and feel like your feelings or your colleagues' feelings would be hurt if you or they were not given a stake in the decision, it’s time to use lazy consensus. If the answer isn’t clear, it’s time to use lazy consensus to err on the side of inclusion.

How

To avoid debates about communication channels, we will have a process where one’s preferences of communication channels don’t matter.

When lazy consensus is used, you should:

• Communicate:
  • Mail the dev list
  • Post a message in slack
  • Post a comment on relevant github issues/PRs
  • The message content should clearly reference via link any PR, issue, or document related to the decision, and let the reader know where to engage in the discussion
  • If you think someone may be particularly interested, sending a message of some kind with a pointer to the public issue discussion may be appropriate. It is not appropriate to hash out all the details in a private discussion.
• Allow time for your colleagues to read and think about the message
  • Please allow an appropriate amount of time, at least 3 business days
  • Give healthy consideration to reasonable objections
  • If consensus cannot be achieved within the discussion, you should attempt to resolve it within the appropriate working group, then engage the TOC or Steering as appropriate if that fails
• Record the decision in writing
  • In increasing order of durability: decision announced in meeting minutes, send a mail to the mailing list, approval in Google Doc by WG lead, GitHub PR (possibly in “docs” directory or the like)