Making the flow and status of work visible is important for all engineering teams and inner source is no exception. At Flutter we use GitHub for inner source work: work is captured in pull requests or issues, and can be visualised using GitHub project boards. So far, so normal!
But our inner source work uses conventions not natively supported by GitHub:
- A capability is a group of GitHub repositories.
- Each capability has a team of expert maintainers.
- Each maintainer is part of a business division.
GitHub has no knowledge of these concepts as they are configured via codebase governor. GitHub does however provide “labels” as a generic way to associate data with issues or pull requests. GitHub labels are shown alongside issue or PR titles in lists and boards so are a good way to make these concepts visible.
Flutter’s Global Betting Platform (gbp) makes use of labels and boards to increase the visibility of these inner source concepts.
Divisional Approval Labels
Pull requests for gbp service repositories require approval from a maintainer from each division that uses the service. Divisional labels are added when a maintainer approves the PR, which allows clear visibility of which PRs still need attention from which divisions.
This can be configured via codebase governor for any repository in Flutter-Global. The automation will add a divisional approval label whenever a maintainer approves the PR.
Divisional Discussion Labels
GitHub issues are used within gbp for cross-divisional technical discussion and alignment. Each of these issues is led by a division, and gbp use divisional labels to show which division is driving which topics.
This can be configured via codebase governor for any repository in Flutter-Global. The automation uses the fact that the author of the issue is usually a member of the division leading it. So the issue is labelled based on the author’s division.
Type & Impact Labels
The “impact” or significance of a pull request is also an important visual signal for inner source. Major changes require more reviews and attention (usually from maintainers of all divisions), vs a minor change that is lower risk and typically requires a review from a single maintainer from any division. The type of a pull request is also useful: is this a fix for a bug or a new feature?
This classification cannot be automated – it is a judgement made by the contributor. But humans tend to forget! So a friendly reminder can be configured via codebase governor to nudge the user to add impact and type labels if these appear to have been forgotten.
Automated Labels
Some simple usage of GitHub labels to show divisional collaboration and work size and type can provide helpful visual signals when looking at the activity in a capability or product.
The PRs and Issues labelling automation helps you by:
- Automatically adding the division label of a maintainer approval to a pull-request;
- Warning a pull-request author whenever work size and type labels have not been applied;
- Automatically adding the division label of an issue author.
Read more about how to enable and configure the PR and Issue in the Docs >
by: Nuno Crisóstomo
in:
tags: WoW Pull Requests
category: Changelog