Project teams
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.
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.
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.
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: https://github.com/flutter/flutter/wiki/Triage#area-focused-triage
-
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: https://github.com/flutter/flutter/wiki/Issue-hygiene
Keep an eye out for bugs that should block releases, update the bad builds page accordingly: https://github.com/flutter/flutter/wiki/Bad-Builds
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.)
- Home of the Wiki
- Roadmap
- API Reference (stable)
- API Reference (main)
- Glossary
- Contributor Guide
- Chat on Discord
- Design documents
- Code of Conduct
- Issue triage reports (latest)
- Our Values
- Tree hygiene
- Issue hygiene and Triage
- Style guide for Flutter repo
- Project teams
- Contributor access
- What should I work on?
- Popular issues
- Running and writing tests
- Release process
- Flutter Framework Gardener Rotation
- Rolling Dart
- Manual Engine Roll with Breaking Commits
- Updating Material Design Fonts & Icons
- Postmortems and Retrospectives
- Hotfix Documentation Best Practices
- In case of emergency
- Landing Changes With Autosubmit
- Setting up the Framework development environment
- The Framework architecture
- API Docs code block generation
- Running examples
- Using the Dart analyzer
- The flutter run variants
- Test coverage for package:flutter
- Writing a golden-file test for package:flutter
- Managing template image assets
- Setting up the Engine development environment
- Compiling the engine
- Debugging the engine
- Using Sanitizers with the Flutter Engine
- Testing the engine
- The Engine architecture
- Flutter's modes
- Crashes
- more...
- Setting up the Packages development environment
- Plugins and Packages repository structure
- Contributing to Plugins and Packages
- Understanding Packages tests
- Plugin Tests
- Releasing a Plugin or Package
- more...