46ef0dea2f
3 notable places I did not migrate. 1. engine/src/flutter/docs/Engine-disk-footprint.md treemaps and what hash is used for what upload. 1. engine/src/flutter/lib/gpu/pubspec.yaml, I didnt want this pr to update code that could need to be reverted and I didnt know what to do to test that publishing would not break or cause a downstream breakage. 1. engine/src/flutter/build/zip_bundle.gni I wasnt sure how to test my changes. Reviewers: Please let me know if you want a different link or if you would prefer something unmodified. Commits: - **Replace triage links with equivalents, change pull request to generic flutter/flutter, replace code search link with equivalent** - **Change link from flutter/engine to engine folder, modify link text to team** - **replace engine repo link with engine folder, replace text repo with folder** - **replace engine specific security info with flutter generic** - **replace engine roller comment with a skia roller equivalent** - **link to same file in new location** - **Remove comment that some code lives in flutter/flutter and some in flutter/engine** - **Say to bump dart in flutter/flutter without mentioning engine** - **Replace documentation with new locations** - **replace code printed comments with new locations** Partially addresses https://github.com/flutter/flutter/issues/167478 ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [x] I signed the [CLA]. - [x] I listed at least one issue that this PR fixes in the description above. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] I added new tests to check the change I am making, or this PR is [test-exempt]. - [x] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [x] All existing and new tests are passing.
5.5 KiB
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]https://github.com/flutter/flutter/tree/main/engine) and flutter/buildroot; label "engine")
-
Various platform-specific teams including iOS, Android, Windows, Linux, and macOS; labels "platform-android", "platform-ios", etc).
-
Desktop-specific features ("a: desktop")
-
Web (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.)