In order to have a dedicate chat room for tree issues with a high signal to noise ratio, we've separated out a new `tree-gardener` channel from the `tree-status` channel on Discord. This updates the gardener docs to reference the new human-centric tree-gardener chat.
I've removed the line suggesting that people avoid spamming the room with requests for "when will this be resolved?" and "can I get an update?" since the doc is aimed mostly at the gardener themself and and not likely being read by those on chat asking "when will the tree be fixed?" Recently this hasn't been a source of noise.
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue. An issue is not required if the PR fixes something trivial like a typo.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
- [] I listed at least one issue that this PR fixes in the description above.
- [] I added new tests to check the change I am making, or this PR is [test-exempt].
- [] I followed the [breaking change policy] and added [Data Driven Fixes] where supported.
- [] All existing and new tests are passing.
## Detail
The correct parameter is --web-port, not --webport
Combine iOS and macOS triage links since it's completed in the same meeting.
1. Remove `no:assignee` from both incoming issue links, as these should still be triaged.
2. Combine P0 issue and packages PR links. Other links are harder to combine. For example, macOS PRs looks for `"affects: desktop"` but iOS PRs do not.
Title and initial timeline addition for flutter android 14 platform view
issues.
Internal to google version of this doc.
[go/flutter-android-14-postmortem](http://goto.google.com/flutter-android-14-postmortem)
- [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].
- [ ] I listed at least one issue that this PR fixes in the description
above.
- [ ] I updated/added relevant documentation (doc comments with `///`).
- [ ] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [ ] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue. An issue is not required if the PR fixes something trivial like a typo.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
This pull request updates the style guide for improved internal consistency and to match current linter rules.
I'll make comments for each change here!
Noticed the framework triage was doing this, adopting it for design languages as well!
Critical triage follows up on these draft PRs if they sit for long without an update. Having draft PRs allows folks to discuss changes without getting nudged constantly to make progress on it. This feels like a really positive change.
Includes the following updates:
- Spacing and capitalization fixes for readability
- Corrects instructions on updating AVD dependencies
- Links to engine docs to reduce redundancy
**TLDR:** Move the changelog, currently called ["hotfixes to the stable
channel"](https://github.com/flutter/flutter/blob/master/docs/releases/Hotfixes-to-the-Stable-Channel.md),
to the root directory of Flutter/Flutter and rename it to CHANGELOG.md
before the Q3 release cutoff.
This PR accomplishes the following:
1. Renames 'Hotfixes-to-the-stable-channel' to CHANGELOG.md
2. Moves CHANGELOG.md to Flutter/Flutter root.
3. Update references to 'Hotfixes-to-the-stable-channel' to
CHANGELOG.md.
---
#### Background
Flutter has historically kept documentation on wiki pages in the Flutter
repository. Recently, we executed a large-scale migration of our wiki
into a `docs` folder within flutter/flutter.
#### Proposal
I propose relocating the current changelog, which is called ["hotfixes
to the stable
channel"](https://github.com/flutter/flutter/blob/master/docs/releases/Hotfixes-to-the-Stable-Channel.md),
to the root directory of the Flutter/Flutter repository and renaming it
to CHANGELOG.md. This change aims to improve the visibility,
accessibility, and consistency of our documentation processes.
#### Benefits
1. **Unify Dart and Flutter Processes:** This move aligns Flutter’s
changelog management with Dart's practices. As the release manager for
both Dart and Flutter, this unification will streamline the processes
and ensure consistency across projects.
#### Timeline
I would like this proposal **approved or denied before the Q3 release
cutoff** so it may be available within the stable branch.
---
> [!NOTE]
> This proposal aims to improve our workflow and documentation
standards. I am open to feedback and further discussion on how we can
best implement this change.
Make it more clear that every design doc has a corresponding github tracking issue with appropriate label.
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue. An issue is not required if the PR fixes something trivial like a typo.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
Update style guide to include anti pattern of mentioning someone in a comment and the flurry of notifications that result.
Came up in a google contributor roundtable discussion.
We are pausing our cadence of removing deprecated API from the framework until we can create a new policy.
The last couple of cycles we noticed customers having more difficult migrations, and it being harder to remove the APIs in the scheduled time period. So we need to reevaluate the policy and update it.
This is the policy working as intended. Signals like flutter/tests provide feedback on how we are affecting users - so that for folks that contributed!
Related to https://github.com/flutter/website/pull/10839
This is intended to replace the currently internal-only document for flutter/packages gardeners. It is a hybrid of the existing document and the Flutter-Framework-Gardener-Rotation.md document (in order to try to improve consistency relative to just moving the existing doc as-is).
We have fiddled with this a bunch, and there is definitively no way to reliably include this, so I am removing it.
Since CI does not cover all possible values, we can't consistently look up images for local testing. We thought removing it from the look up would work fine, and it did for most tests, but there were still some that could not find an image without it.
A brief history on the abi key
- added in https://github.com/flutter/flutter/pull/143621
- disabled in https://github.com/flutter/flutter/pull/148023
- added back in https://github.com/flutter/flutter/pull/148072
- we thought there was only an issue with alphabetizing keys
- removed from local image look up in https://github.com/flutter/flutter/pull/149696
I updated the docs page to also discuss what makes a good key and what does not based on what we learned here.
Currently the ecosystem team triages all PRs in the packages repository, but the platform teams also triage all PRs with their platform label. Due to the way PRs in packages work, however, it's relatively common for a PR to not be relevant to all the teams' triages at all times. Common examples:
- One platform team may LGTM a multi-platform PR for their platform's portion, while another platform goes through review for several more weeks.
- A cross-platform PR may not have high-level design approval from the ecosystem owner, at which point platform implementation review is premature.
To avoid PRs showing up repeatedly in a platform team's triage when it's not relevant, this adjusts the triage structure:
- Queries for PRs in platform teams query `triage-<platform name>` rather than `platform-<platform name>`
- Ecosystem triage will add the `triage-<platform name>` label during triage when a PR is ready for that platform team's consideration.
- Platform teams can remove the label when it's not relevant to them (e..g, after it's been LGTM'd for that platform).
This also adds a desktop PR query, since there wasn't one, covering the separate platforms. They are separated to allow for more triage flexibility in the future.
