The Flutter project has many teams, including, but not limited to:

• Design languages, covering:

  • The material library (flutter/flutter packages/flutter/lib/src/material; label "f: material design")

  • The cupertino library (flutter/flutter packages/flutter/lib/src/cupertino; label "f: cupertino")

• The Flutter framework (code in flutter/flutter packages/flutter/lib/src/widgets, ...rendering/, ...painting/, etc; label "framework")

• The Flutter command line tool (flutter/flutter packages/flutter_tools, label "tool")

• Ecosystem (flutter/plugins, flutter/packages, the plugin infrastructure in flutter/flutter; labels "plugins", and "packages")

• The Engine (flutter/engine and flutter/buildroot; label "engine")

• Various platform-specific teams including iOS, Android, Windows, Linux, and macOS (some code in flutter/flutter and flutter/engine); labels "platform-android", "platform-ios", etc).

• Desktop-specific features (some code in flutter/flutter and flutter/engine, "a: desktop")

• Web (some code in flutter/flutter and flutter/engine, label "platform-web")

• Developer experience (e.g. the devtools package)

• User Experience Research

• Developer Relations (e.g. the samples repo, docs.flutter.dev)

• Infrastructure (mainly flutter/cocoon and flutter/flutter dev/devicelab, label "team: infra")

There are also specific cross-cutting areas of work that may have their own subteam and that affect multiple subteams (e.g. accessibility, performance, etc).

We also work closely with other projects, such as Dart and Skia, and with many customers.

Responsibilities ​

Subteams are responsible for reviewing PRs in their area, triaging issues, and scheduling work. How subteams organize themselves is not defined by this document. This document does not attempt to impose a process, merely a set of responsibilities.

See the Roadmap and What should I work on? pages for details on how to prioritize work.

Reviewing PRs ​

Please review PRs in your area (based on label and/or repositories). The goal is to have a prompt (less than one week) turnaround for all PRs. Please have goals around handling of PRs with the relevant label and/or in the relevant repository. Please don't leave lingering stale PRs open. All PRs should be actively being worked on. If nobody has the time to work on a PR, it should be closed; the relevant issue can have the "has partial patch" label applied.

Triage ​

Please triage issues with your label on a regular basis. You may do this in whatever manner you prefer (on your phone while in line for lunch, as a team exercise in a dedicated meeting room, by having some sort of team rotation, whatever).

You must cover these bug lists in particular.

• Assign bugs that you are working on or that you have committed to work on.

• Unassign bugs you are not working on and have no specific scheduled plans to work on.

• Make sure that assigned bugs have a month-based milestone (see section below).

See our page on managing issues.

Keep an eye out for bugs that should block releases, update the bad builds page accordingly.

Be conservative when scheduling ​

Customers always assume things will be done sooner than you promise, and there are always going to be emergencies, so you need slack in your schedule.

You will be more effective, more popular, and your morale will be higher, if you focus on a small set of things and really knock those out of the park, than if you try to do a large number of things and only do a little bit for each, so aim to underpromise and overdeliver.

This may mean your OKRs are more optimistic than what you report as your scheduled timeline. With OKRs we generally try to hit 67% of the plan. With the roadmap we want to hit 150%.

(OKRs are how some team members plan their work, notably it is used by Google engineers.)