Back to Flutter Inner Source homepage
inner source

Strategic Consensus

Inner sourced capabilities are shared, and sharing requires consensus. Getting several groups to agree can be hard, often requires compromise and consumes time and effort. Where possible it should be avoided for low consequence decisions. However, an effective consensus mechanism is critical to allow divisions or teams to agree and make important decisions promptly. For example:

How to Efficiently Agree

For efficient agreement two factors are important:


Collaborating across divisions also means collaborating across several global timezones with limited overlap. That overlap is already heavily congested by other activity which further restricts the opportunity for fully inclusive synchronous collaboration. This means attempting this synchronously tends in practice to exclude certain timezones e.g. maintainer meetings in CEST make it unlikely our Melbourne-based colleagues will attend.

Good guidence already exists about how to optimise for asynchronous work:

A brief summary:

A beneficial side effect of asynchronous communication is a quality written record of decision reasoning and the ability for a user to ‘catch up’ with a discussion they may only have joined half-way through.


Lazy consensus means that when you are convinced that you know what the community would like to see happen, you can assume that you have consensus in favor of the proposed work and and get on with it. You don’t have to insist people discuss and/or approve your plan, and you certainly don’t need to call a vote to get approval.

Source: Apache Community

Lazy consensus attempts to avoid unnecessary discussion or wasted time by using the following process for agreement:

  1. A written proposal is published to an appropriate audience with deadline for feedback/objections.
  2. Silence is assumed as agreement.
  3. Concerns raised are discussed and addressed; a concern accompanied by an alternative solution is encouraged.
  4. After a suitable discussion period if all concerns are addressed approval is assumed.

This approval process is both asynchronous-friendly and time-efficient. It does however require an engaged audience: missing proposals and raising objections late will cause disruption and upset. A skilled proposer will be able to judge the engagement and mitigate this risk by leaving a longer consult time, or socialise the proposal more explicitly with key stakeholders as necessary.

Example: Significant Change

Planning a significant change is a good example of where using asynchronous written communication and lazy consensus brings many benefits.

A simple but effective convention is simply for the proposer to raise a GitHub issue on the capability repository describing their change, why it is necessary and the alternatives that were considered. An asynchronous written discussion that is accessible to all users can then follow. To ensure the required engagement for lazy consensus, the proposal should be highlighted via a shared community slack channel. GitHub issues allow ‘+1’ type reactions, and the same is available on any Slack message which can be used by the proposer to judge the level of engagement and re-advertise if necessary.

A more advanced approach that has the benefit of producing an edited summary for future reference is to define a request for comment (RFC) process. In this case a proposer will raise a pull request against the capability repository to add a markdown proposal document, usually with a standard template and naming convention. This can be advertised in the same way as a GitHub issue and allows the same asychronous written discussion. However PR review semantics and notifications can also be used, an edited proposal document for future reference is the final result, and the proposal has a clear end point that is either a merge (accepted), or closed (rejected).

For example:

Example: Strategy Planning

Strategy planning for a capability can be treated like significant change, but is often more complex or more expansive and usually deserves a different treatment.

Example: Unpopular Work Assignment

In this example a challenging priority call must be made across the divisions, examples of which are included in the work type analysis. There are a variety of prioritisation mechanisms within the divisions but all will require the measureable benefits, teams impacted, and effort/cost to make a decision. While the priority decision itself is likely to be made synchronously, the document that informs that decision can be created asynchronously.

Divisional Independence
← Previous
Work Type Analysis