Back to Flutter Inner Source homepage
inner source

Stage 2: Guest Contributions

This page explains the second stage of the inner source pyramid.

The host team retain full accountability for the capability development and encourage and review ‘guest’ contributions from other teams who need to change it either for their own deployments or projects. If the host team deem the guest contribution to be of sufficient quality it will be accepted and the host team will take forward responsibility for it, otherwise it may be rejected or re-worked.

What quality of contribution do you need?

The most important consideration for a host team is reducing the risk and on-going maintenance burden of the external contributions they are being asked to accept and take forward responsibility for. The most important consideration for guest teams is the predictability of whether a contribution they make will be accepted in a timely fashion so they can meet their delivery commitments. All these factors depend on the quality of the contribution.

What is quality?

The “quality” of a contribution is defined as:

Agreeing a quality standard

For an inner source capability that is used by multiple divisions agreeing these contribution standards can be complex: security policies vary across divisions; a range of deployment topologies exist; and different divisional priorities on risk or short vs long-term investment.

For a host team just moving into this stage these standards will be the local standards of the hosting team’s division. As other divisions start to use and contribute these standards will need to be adjusted to also meet their needs. This usually happens by:

How to achieve the desired quality of contribution?

You must enforce your agreed quality standards by reviewing contributions and rejecting those that do not meet the minimum requirements. This is achieved by accepting contributions as pull requests (PR), and using branch protection to ensure the contribution is reviewed by an expert confident and knowledgeable enough to uphold those standards.

This is simple to say, hard to do consistently, but critical for the success of your inner source product.

If you are finding this difficult it is best to put effort into answering the question “How can I improve the quality of contributions” – this makes it easier for contributors to have their changes approved while also reducing the work required to review them.

How do I improve the quality of contributions before review?

As the volume of contributions increase, it is worth putting more effort into improving their quality before they reach a review to save yourself and your contributor’s time. You can do this by:

Writing Contribution Guides

The markdown file in each repository has a semantic meaning by GitHub convention: it is linked from various locations as the repository ‘contributing guide’. The simplest way to improve the quality of contributions is to use this document to help contributors.

The contents of this guide will depend on the purpose of the repository, commonly included is:

See Also: Inner Source Commons: Shared Base Documentation Pattern

Triage and Early Engagement

Our experience at Flutter is that expert advice before a contribution is started (however brief) is extremely valuable in raising the quality of that contribution and avoid significant rework effort. This experience is also reflected in other organisations, e.g. at PayPal:

Contributor teams were encouraged to notify the receiving Trusted Committers by filing an issue as soon as an InnerSource contribution is contemplated. This allowed both sides to maximize resource planning. It also allowed the receiving Trusted Committers to fend off any misguided planned contributions. Once we started doing this with all Inner source projects, we saw a higher throughput of contributed and merged lines of code. From: Adopting Inner Source

Some ideas for an effective triage and early engagement process:

Using Automated PR Feedback

Automated quality checks that run against a PR using GitHub Actions are a significant help in raising the contribution quality.

Common tasks undertaken in such checks:

Stage 1 - Readable Source
← Previous
Stage 3 - Maintainers in Multiple Teams