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.


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:

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.


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: