Canonical Link: flutter.dev/to/team-infra.
This doc details how to triage and work on issues marked team-infra.
The infrastructure sub-team works a bit differently than our externally facing product, as it is producing (and maintaining) infrastructure for Flutter, which includes tools and services that are open source but are not supported for external use.
As a result, our process differs from the general issue hygiene and issue triage:
This process allows us to have a more organized handle on the number of open issues potentially affecting the team's velocity, including critical components like release health.
Table of contents:
Links:
The infra sub-team owns general infrastructure that is often shared or used across the Flutter project, but not all testing and or tooling infrastructure; that is, unless the tool is mentioned below, we may decline or direct you at another sub-team:
dev/**Our prioritization is similar to team-wide priorities, but with a few more specifics. Unless you work on the infra team, we ask you do not add or change priority labels.
An emergency that needs to be addressed ASAP as there is no reasonable workaround.
P0s are worked on actively, with an update shared with the core team at least once a week, and supercede all other priorities (i.e. are a “stop work” order on other issues).
Examples might include:
An important change that would significantly improve productivity for the team, or significantly improve reliability of the infrastructure (causing less P0 and P1 issues).
If an issue has not been pre-aligned with the team, or does not have a sponsor from another team that will be immediately responsible for a feature or bug fix, then P1 is not suitable.
Examples might include:
A change we agree with, but do not have bandwidth for.
An individual could meaningfully make progress on this issue, and we would review it. If there are no volunteers, it may never be completed.
See also: contributing.
A change we agree with, but would require significant maintenance.
While an individual could meaningfully make progress on this issue, we would not review and accept it, as the cost of maintaining it is beyond what we can currently sustain.
Our own team's discretion is used for what P3 issues are left open, and which are closed as not planned.
See also: contributions.
Unlike the external Flutter product, we do not accept contributions on all issues, and run the team-infra label more like an operations team; that is, if an issue is unlikely to be addressed or does not meet the priorities criteria above, we often will close the issue as not planned.
An issue closed as not planned does not mean the issue does not have validity, or that a subsequent more fleshed out issue or request would get more attention, it just represents the limited bandwidth and capability of the team responsible.
We encourage you/your team to manage your own “wishlist” of items, which could be in the format of a github issue (but not tagged team-infra), a gist, a github project, a Google doc, or another format, and to share it with us.
See also: contributing.
This sub-team has a more limited contributions policy than other parts of the project, as we build and support tools that are not supported as part of the Flutter product, including internal CI/CD and tooling.
In general, P2 issues are a great way to contribute, as they have already been actively vetted as “this is important to us” and “we would accept a PR or PRs that address this bug or feature request”.
For other issues, if you are part of the core Flutter team, please contact us.
The team primarily uses GitHub and internal Google chat for communication, which is unavailable to non-Google employees. For issues that are important to the broader community, we use Discord and flutter-announce@ as needed.
If you work at Google, see go/flutter-infra-team.
Otherwise, see #hackers-infra on Discord. Note responses may be infrequent.