github/flutter
7
0
Fork 0
mirror of https://github.com/flutter/flutter.git synced 2025-06-03 00:51:18 +00:00
Code Issues Packages Projects Releases Wiki Activity
b653e4f661
flutter/docs/contributing/What-should-I-work-on.md
Kate Lovett 1fbcbb73a0
[wiki migration] Leftover wiki pages and links (#148989) 
This is waiting on 
- https://github.com/flutter/flutter/pull/148777
- https://github.com/flutter/flutter/pull/148790

After this PR lands, there will likely be 1-2 more clean up PRs, after which the migration will be done!

---

This moves the remaining wiki pages as planned in [flutter.dev/go/migrate-flutter-wiki-spreadsheet](https://docs.google.com/spreadsheets/d/1x65189ZBdNiLRygpUYoU08pwvXD4M-Z157c6pm8deGI/edit?usp=sharing) 

It also adds the team labels to the label bot for future PRs.

Changes to the content were only updating cross links, or links to refer to the main branch rather than master.
Remaining links to the wiki will be updated once all other pages have finished moving, they still work in the meantime.

Part of https://github.com/flutter/flutter/issues/145009
2024-05-28 15:12:10 +00:00

3.1 KiB
Raw Blame History

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.

  1. Build breakage. Check the dashboard.
  2. P0 issues (e.g. serious regressions).
  3. Mentoring promising new contributors.
  4. Code review of open PRs.
  5. P1 issues, including:
    1. Flaky tests.
    2. Performance regressions. Check the dashboard for new unreported regressions and see GitHub for the list of reported performance regressions.
    3. Other regressions.
    4. Reducing technical debt. (For example, increasing our test coverage by writing new tests, or fixing TODOs.)
  6. P2 issues, which correspond to the remaining areas of our roadmap, such as:
  7. Issues sorted by thumbs-up. Focus on bugs in existing code and avoid adding new code.
  8. Everything else. Consider this advice when prioritizing bugs.

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-P3 labels so as to fit the order described above.

Sometimes, items in the list above escalate. For example, a bug might get filed as a P2 issue, then be recognized as a critical regression and upgraded to P0.

See also: