Back to Flutter Inner Source homepage
inner source

Divisional Independence

One of the challenges of operating a capability at stage 3 of the inner source pyramid is how to maximise the independence of each contributing team. This is especially important if your reason for operating at stage 3 is the need for a high rate of change: even a small collaboration overhead between teams will add up.

To promote divisional independence:

Maintainers in Contributing Teams

Maintainers are the technical experts in how the capability is built and deployed: knowledge which allows the contributing team they are a member of to be more independent. In stage 3, the maintainers are distributed across many delivery teams and represent their team when the maintainers come together to work as a group themselves.

Maintainers from different teams

Triage

The objective of triage is to:

This supports divisional independence through the critical task of clarifying which changes can progress independently, and which require up-front collaboration and agreement.

Triage process outcome flowchart

An effective triage process is usually a simple one as it must be transparent, well known and consistently used (i.e. no short-cuts for ‘special’ maintainers!). For example a common process is:

  1. Local maintainer will triage their team’s backlog and highlight items that they are unsure of, or definitely require collaboration.
  2. GitHub issue raised for technical discussion wrt each highlighted item, advertised via community Slack channel and tracked in a GitHub project board.
  3. GitHub issue gathers feedback/advice from maintainers and a decision on whether the change can immediately progress (i.e. ‘this discussion was enough’), or whether more rigorous consensus is required (i.e. RFC).
  4. Regular maintainer meetings run by the capability owner use the GitHub project board to sweep up any unresolved issues that are in danger of becoming stale.

Such a process can be documented in a CONTRIBUTING.md; is both transparent and inclusive for all capability users; and is simple enough to be easily remembered and used consistently.

Pull Request

Changes that are triaged as ‘simple’ can be progressed independently:

Complex changes require up-front consensus (covered separately), but once that consensus is reached follow a similar pattern:

Merge & Release

Usually a division will own and run it’s own capability deployment using it’s preferred local deployment topology which integrates with local service management, operational support and incident management tools and teams. This provides full independence of the release deployment and support process; but from a set of approved PRs collaboration is required to agree release milestones and any development author support. This remains unsolved at present within Flutter, with capabilities in stage 3 that have a high rate of change often suffering release contention between divisions and wasteful duplicated release QA. So the guidance that can be provided is limited to the following observations:

Capability Owners
← Previous
Strategic Consensus