-
Notifications
You must be signed in to change notification settings - Fork 1
What should I work on?
This page attempts to be a one-stop shop for figuring out what the most important thing to work on is, so that team members (contributors) can determine the more effective way to improve Flutter.
- Build breakage. Check the dashboard.
- P0 issues (e.g. serious regressions).
- P1 issues (e.g. customer blockers).
- Mentoring promising new contributors.
- Flaky tests.
- Performance regressions. Check the dashboard for new unreported regressions and see GitHub for the list of reported performance regressions.
- Other regressions.
- Code review of open PRs.
- Reducing technical debt. (For example, increasing our test coverage by writing new tests, or fixing TODOs.)
- The priorities described on our roadmap, which may include:
- P2 issues.
- Bugs marked as annoyances.
- Bugs labeled as issues of quality.
- Bugs with the crash label.
- Issues sorted by thumbs-up. Focus on bugs in existing code and avoid adding new code.
- Everything else.
Bugs in other bug systems should be tracked with bugs in GitHub. OKRs should be reflected in the items listed above. For example, OKRs should reflect what the roadmap covers, expected customer blockers, and so forth. Work that is unique to a particular quarter would be represented by a filed bug with a milestone and assignee.
During triage, bugs should be prioritized according to the P0-P6 labels so as to fit the order described above.
Sometimes, items in the list above escalate. For example, a performance regression might get filed as a P0 bug and thus start trumping a P1 issue.
See also:
- Issue Hygiene, in particular the section on prioritization.
- Home of the Wiki
- Roadmap
- API Reference (stable)
- API Reference (master)
- Glossary
- Contributor Guide
- Chat on Discord
- Code of Conduct
- Issue triage reports
- Our Values
- Tree hygiene
- Issue hygiene and Triage
- Style guide for Flutter repo
- Project teams
- Contributor access
- What should I work on?
- Running and writing tests
- Release process
- Rolling Dart
- Manual Engine Roll with Breaking Commits
- Updating Material Design Fonts & Icons
- Postmortems
- Setting up the Framework development environment
- The Framework architecture
- The flutter tool
- 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
- 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
- Engine disk footprint
- Comparing AOT Snapshot Sizes
- Custom Flutter engine embedders
- Custom Flutter Engine Embedding in AOT Mode
- Flutter engine operation in AOT Mode
- Engine-specific Service Protocol extensions
- Crashes
- Supporting legacy platforms
- Metal on iOS FAQ
- Engine Clang Tidy Linter
- Why we have a separate engine repo
- Reduce Flutter engine size with MLGO
- Setting up the Plugins development environment
- Setting up the Packages development environment
- Plugins and Packages repository structure
- Plugin Tests
- Contributing to Plugins and Packages
- Releasing a Plugin or Package
- Unexpected Plugins and Packages failures