[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
This commit is contained in:
Kate Lovett
@@ -4,12 +4,12 @@ We grant commit access (which includes full rights to the issue database, such a
|
||||
|
||||
Specifically, if you meet one of the following criteria and you have a sponsor (someone who already has contributor access and agrees that you should be granted access), then please ask your sponsor to propose, on the #server-support [Chat](Chat.md) channel, that you be made a member of the team, and then reply to that message explaining which criteria below you are claiming to meet. The possible criteria are:
|
||||
|
||||
* You have a long history of participating productively, e.g. in our [Chat](Chat.md) channels, helping with [Triage](https://github.com/flutter/flutter/wiki/Triage), helping other contributors track down problems, finding meaningful issues in submitted PRs, helping people in our #help channel, etc, all while demonstrating exemplary behavior that closely aligns with our [code of conduct](https://github.com/flutter/flutter/blob/main/CODE_OF_CONDUCT.md).
|
||||
* You have a long history of participating productively, e.g. in our [Chat](Chat.md) channels, helping with [Triage](../triage/README.md), helping other contributors track down problems, finding meaningful issues in submitted PRs, helping people in our #help channel, etc, all while demonstrating exemplary behavior that closely aligns with our [code of conduct](https://github.com/flutter/flutter/blob/main/CODE_OF_CONDUCT.md).
|
||||
* You have recently submitted several PRs that have landed successfully (received an LGTM, PR was merged, no regressions reported, PR was not reverted), without needing extensive tutoring in the process.
|
||||
* You are employed by a company with a history of contributing to Flutter, for the purpose of yourself regularly contributing to Flutter.
|
||||
* You represent a development team that creates applications, plugins, or packages using Flutter and have a close relationship with our developer relations team, including having a customer label, and have a great need to regularly update labels on issues (see [Issue hygiene, Customers](./issue_hygiene/README.md#customers)). (This is rare.)
|
||||
|
||||
Being granted access means that you will be added to the "flutter-hackers" group on GitHub and the "team" role on Discord. This privilege is granted with some expectation of responsibility: contributors are people who care about Flutter and want to help Flutter along our [roadmap](https://github.com/flutter/flutter/wiki/Roadmap). A contributor is not just someone who can make changes or comment on issues, but someone who has demonstrated their ability to collaborate with the team, get the most knowledgeable people to review code, contribute high-quality code, follow through to fix bugs (in code or tests), and provide meaningful insights on issues.
|
||||
Being granted access means that you will be added to the "flutter-hackers" group on GitHub and the "team" role on Discord. This privilege is granted with some expectation of responsibility: contributors are people who care about Flutter and want to help Flutter along our [roadmap](../roadmap/Roadmap.md). A contributor is not just someone who can make changes or comment on issues, but someone who has demonstrated their ability to collaborate with the team, get the most knowledgeable people to review code, contribute high-quality code, follow through to fix bugs (in code or tests), and provide meaningful insights on issues.
|
||||
|
||||
We grant access optimistically based on a reasonably small volume of evidence of good faith. Correspondingly, we will remove access quickly if we find our trust has been violated. Contributors with commit access must still follow all our processes and policies, and must follow our [code of conduct](https://github.com/flutter/flutter/blob/main/CODE_OF_CONDUCT.md) rigorously. (Please read it, it's stricter than most.)
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@
|
||||
Verify that `adb` is in your [PATH](https://en.wikipedia.org/wiki/PATH_(variable)) (that `which adb` prints sensible output).
|
||||
|
||||
If you're
|
||||
[also working on the Flutter engine](../engine/dev/Setting-up-the-Engine-development-environment.md),
|
||||
[also working on the Flutter engine](../engine/contributing/Setting-up-the-Engine-development-environment.md),
|
||||
you can use the copy of the Android platform tools in
|
||||
`.../engine/src/third_party/android_tools/sdk/platform-tools`.
|
||||
|
||||
@@ -57,8 +57,8 @@
|
||||
|
||||
Next steps:
|
||||
|
||||
* [Running examples](https://github.com/flutter/flutter/wiki/Running-examples), to see if your setup works.
|
||||
* [The flutter tool](https://github.com/flutter/flutter/wiki/The-flutter-tool), to learn about how the `flutter` command line tool works.
|
||||
* [Running examples](../examples/Running-examples.md), to see if your setup works.
|
||||
* [The flutter tool](../tool/README.md), to learn about how the `flutter` command line tool works.
|
||||
* [Style guide for Flutter repo](Style-guide-for-Flutter-repo.md), to learn how to write code for Flutter.
|
||||
* [Tree hygiene](Tree-hygiene.md), to learn about how to submit patches.
|
||||
* [Signing commits](Signing-commits.md), to configure your environment to securely sign your commits.
|
||||
|
||||
@@ -95,10 +95,10 @@ proper fix for a problem rather than just applying a band-aid.
|
||||
When you fix a bug, first write a test that fails, then fix the bug
|
||||
and verify the test passes.
|
||||
|
||||
When you implement a new feature, write tests for it. (See also: https://github.com/flutter/flutter/wiki/Running-and-writing-tests[Running and writing tests], and the section on writing tests below.)
|
||||
When you implement a new feature, write tests for it. (See also: [Running and writing tests](./testing/Running-and-writing-tests.md), and the section on writing tests below.)
|
||||
|
||||
Check the code coverage
|
||||
to make sure every line of your new code is tested. See also: https://github.com/flutter/flutter/wiki/Test-coverage-for-package%3Aflutter[Test coverage for package:flutter].
|
||||
to make sure every line of your new code is tested. See also: [Test coverage for package:flutter](./testing/Test-coverage-for-package-flutter.md).
|
||||
|
||||
If something isn't tested, it is very likely to regress or to get "optimized away".
|
||||
If you want your code to remain in the codebase, you should make sure to test it.
|
||||
@@ -292,9 +292,9 @@ by real developers.
|
||||
|
||||
### Get early feedback when designing new APIs
|
||||
|
||||
If you're designing a new API or a new feature, consider https://github.com/flutter/flutter/wiki/Chat#design-documents[writing a design doc].
|
||||
If you're designing a new API or a new feature, consider [writing a design doc](Design-Documents.md).
|
||||
Then, get feedback from the relevant people, e.g. send it to `flutter-dev` or
|
||||
post it on the https://github.com/flutter/flutter/wiki/Chat#existing-channels[relevant chat channel].
|
||||
post it on the [relevant chat channel](Chat.md#existing-channels).
|
||||
|
||||
|
||||
### Start designing APIs from the closest point to the developer
|
||||
@@ -327,7 +327,7 @@ Put yourself in the shoes of whoever sees that error message. Why did they see i
|
||||
|
||||
### Template values should set developers up for success
|
||||
|
||||
Template defaults should focus on providing the best developer experience. Templates should help developers understand the code, be easy to run now and support in the future. Help developers by picking dependencies that are broadly used and/or broadly supported and by leaving https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#leave-breadcrumbs-in-the-comments[comments that are helpful].
|
||||
Template defaults should focus on providing the best developer experience. Templates should help developers understand the code, be easy to run now and support in the future. Help developers by picking dependencies that are broadly used and/or broadly supported and by leaving [comments that are helpful](#leave-breadcrumbs-in-the-comments).
|
||||
|
||||
See flutter create's templates for an example.
|
||||
|
||||
@@ -376,7 +376,7 @@ All licenses included in this manner must have been reviewed and determined to b
|
||||
|
||||
All such "third party code" must either be a fork for which we take full responsibility, or there must be an automated rolling mechanism that keeps the code up to date when the upstream source changes.
|
||||
|
||||
In general it is _strongly_ recommended that we avoid any such code unless strictly necessary. In particular, we aim for all code in the flutter/flutter repository to be https://github.com/flutter/flutter/wiki/Why-we-have-a-separate-engine-repo#licensing?[single-licensed], which is why it does not contain any "third party code" at all.
|
||||
In general it is _strongly_ recommended that we avoid any such code unless strictly necessary. In particular, we aim for all code in the flutter/flutter repository to be [single-licensed](../about/Why-we-have-a-separate-engine-repo.md#licensing), which is why it does not contain any "third party code" at all.
|
||||
|
||||
|
||||
## Documentation (dartdocs, javadocs, etc)
|
||||
@@ -651,7 +651,7 @@ The first two arguments are the video's width and height. These should be `560`
|
||||
|
||||
### Clearly mark deprecated APIs
|
||||
|
||||
We have conventions around deprecation. See the https://github.com/flutter/flutter/wiki/Tree-hygiene#deprecation[Tree Hygiene] page for more details.
|
||||
We have conventions around deprecation. See the [Tree Hygiene](Tree-hygiene.md#deprecations) page for more details.
|
||||
|
||||
|
||||
### Use `///` for public-quality private documentation
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
## tl;dr
|
||||
|
||||
- Regressions should be [reverted first](https://github.com/flutter/flutter/wiki/Landing-Changes-With-Autosubmit) and questions asked later. Bringing the tree to green is higher priority.
|
||||
- Regressions should be [reverted first](../infra/Landing-Changes-With-Autosubmit.md) and questions asked later. Bringing the tree to green is higher priority.
|
||||
- A breaking change is one that breaks the tests in the flutter/tests repo, and those need a migration guide.
|
||||
- Expect that a new patch will be reviewed within two weeks, unless it is fixing a P0 bug in which case it should be reviewed the same day. If it has not been reviewed in that timeframe, reach out on [Chat](Chat.md). Remember that reviewers are human beings with additional professional and personal responsibilities.
|
||||
|
||||
@@ -111,7 +111,7 @@ Feel free to update the bot's logic to catch more cases that should be automatic
|
||||
## Using git
|
||||
|
||||
Assuming your environment has been configured according to the instructions in
|
||||
[Setting up the Engine development environment](../engine/dev/Setting-up-the-Engine-development-environment.md),
|
||||
[Setting up the Engine development environment](../engine/contributing/Setting-up-the-Engine-development-environment.md),
|
||||
[Setting up the Framework development environment](Setting-up-the-Framework-development-environment.md), or
|
||||
[Setting up the Packages development environment](../ecosystem/contributing/Setting-up-the-Packages-development-environment.md),
|
||||
follow these steps to start working on a patch:
|
||||
@@ -187,7 +187,7 @@ saying what your patch does and providing a link.
|
||||
|
||||
### Who
|
||||
|
||||
PRs are assigned reviewers weekly. The precise process varies by team but tends to be combined with issue [triage](https://github.com/flutter/flutter/wiki/Triage).
|
||||
PRs are assigned reviewers weekly. The precise process varies by team but tends to be combined with issue [triage](../triage/README.md).
|
||||
|
||||
Code should be reviewed by the owner (tech lead) of the area(s) of the codebase that you are changing,
|
||||
or someone to whom they have delegated that authority.
|
||||
@@ -283,7 +283,7 @@ revert (roll back) the check-in (even if it isn't yours). Do not attempt to forw
|
||||
|
||||
There is no shame in making mistakes! Reverts happen all the time and are a normal part of engineering.
|
||||
|
||||
To revert a PR, just add the `revert` label to it. _For more details, see [Landing Changes With Autosubmit](https://github.com/flutter/flutter/wiki/Landing-Changes-With-Autosubmit)._
|
||||
To revert a PR, just add the `revert` label to it. _For more details, see [Landing Changes With Autosubmit](../infra/Landing-Changes-With-Autosubmit.md)._
|
||||
|
||||
|
||||
### Avoid "Revert "Revert "Revert "Revert "Fix foo"""" commit messages
|
||||
@@ -334,7 +334,7 @@ way or have determined it is an acceptable trade-off).
|
||||
### Performance regressions caused by auto-roller commits
|
||||
|
||||
Although reverting a normal commit that caused performance regressions is the default
|
||||
behavior, reverting an [auto-roller](https://github.com/flutter/flutter/wiki/Autorollers)
|
||||
behavior, reverting an [auto-roller](../infra/Autorollers.md)
|
||||
(e.g., an engine-roller commit like https://github.com/flutter/flutter/commit/fdcb57b69eff2162e9aead6dec0f8058788e7608)
|
||||
commit could cause some complications:
|
||||
|
||||
@@ -383,7 +383,7 @@ Implement the change you wish to see and run the existing tests against your new
|
||||
The "contributed tests" are:
|
||||
|
||||
* Those in the [`customer_testing`](https://github.com/flutter/tests) shard on `flutter/flutter` PRs.
|
||||
* Additional test suites that we have been allowed to run but that are not public. (Notably, Google allows us to run several tens of thousands of [proprietary tests](https://github.com/flutter/flutter/wiki/Understanding-Google-Testing) on each commit.)
|
||||
* Additional test suites that we have been allowed to run but that are not public. (Notably, Google allows us to run several tens of thousands of [proprietary tests](../infra/Understanding-Google-Testing.md) on each commit.)
|
||||
|
||||
There are no exemptions to this policy, because these tests run in our CI and breaking them will close the tree.
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ This page attempts to be a one-stop shop for figuring out what the most importan
|
||||
1. Performance regressions. Check the [dashboard](https://flutter-dashboard.appspot.com/benchmarks.html) for new unreported regressions and see GitHub for the list of [reported performance regressions](https://github.com/flutter/flutter/issues?utf8=%E2%9C%93&q=is%3Aopen+label%3A%22c%3A+performance%22+label%3A%22c%3A+regression%22+).
|
||||
1. [Other regressions](https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+label%3A%22c%3A+regression%22).
|
||||
1. Reducing technical debt. (For example, increasing [our test coverage](./testing/Test-coverage-for-package-flutter.md) by [writing new tests](./testing/Running-and-writing-tests.md), or fixing TODOs.)
|
||||
1. [P2 issues](https://github.com/flutter/flutter/labels/P1), which correspond to the remaining areas of our [roadmap](https://github.com/flutter/flutter/wiki/Roadmap), such as:
|
||||
1. [P2 issues](https://github.com/flutter/flutter/labels/P1), which correspond to the remaining areas of our [roadmap](../roadmap/Roadmap.md), such as:
|
||||
* Bugs marked as [annoyances](https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+label%3A%22a%3A+annoyance%22+sort%3Areactions-%2B1-desc).
|
||||
* Bugs labeled as issues of [quality](https://github.com/flutter/flutter/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3A%22a%3A+quality%22+sort%3Areactions-%2B1-desc+).
|
||||
* Bugs with the [crash](https://github.com/flutter/flutter/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3A%22c%3A+crash%22+sort%3Areactions-%2B1-desc+) label.
|
||||
@@ -18,7 +18,7 @@ This page attempts to be a one-stop shop for figuring out what the most importan
|
||||
|
||||
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](https://github.com/flutter/flutter/wiki/Triage), bugs should be prioritized according to the [P0-P3 labels](./issue_hygiene/README.md#priorities) so as to fit the order described above.
|
||||
During [triage](../triage/README.md), bugs should be prioritized according to the [P0-P3 labels](./issue_hygiene/README.md#priorities) 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.
|
||||
|
||||
|
||||
@@ -250,7 +250,7 @@ and senior leads want resolved to the attention of the appropriate engineering
|
||||
team.
|
||||
|
||||
The `customer: crowd` label is used to represent bugs that are affecting large
|
||||
numbers of people; during initial [Triage](https://github.com/flutter/flutter/wiki/Triage), high-profile bugs get labeled in
|
||||
numbers of people; during initial [Triage](../../triage/README.md), high-profile bugs get labeled in
|
||||
this way to bring them to the attention of the engineering team. "Large numbers"
|
||||
is a judgement call. If dozens of people independently run into the same issue
|
||||
and file a bug and we end up realizing that they're all duplicates of each other,
|
||||
@@ -336,7 +336,7 @@ If you have an idea that you would like to land, the recommended process is:
|
||||
|
||||
Avoid filing issues that are on vague topics without a clear problem description.
|
||||
|
||||
Please close issues that are not actionable. See [Triage](https://github.com/flutter/flutter/wiki/Triage) for more details.
|
||||
Please close issues that are not actionable. See [Triage](../../triage/README.md) for more details.
|
||||
|
||||
#### Issues should have clear steps to reproduce
|
||||
|
||||
@@ -349,12 +349,12 @@ If an issue is lacking this information, request it from the commenter and close
|
||||
An issue should be closed if:
|
||||
|
||||
* it is fixed!
|
||||
* it is a [duplicate](https://github.com/flutter/flutter/wiki/Triage#duplicates).
|
||||
* it is a [duplicate](../../triage/README.md#duplicates).
|
||||
* it makes multiple requests which could be addressed independently. Encourage people to file separate bugs for each independent item.
|
||||
* it is describing a _solution_ rather than a _problem_. For example, it has no use cases, and the use cases are not obvious, or might have other solutions.
|
||||
* it is not [actionable](https://github.com/flutter/flutter/wiki/Triage#what-makes-an-issue-actionable) and does not [have unusual symptoms](https://github.com/flutter/flutter/wiki/Triage#unactionable-bugs-with-unusual-symptoms). This covers a wide variety of cases, such as invalid bugs, bugs without steps to reproduce, bugs that have become irrelevant, or bugs that are unclear and which the reporter has not offered more details for. It also includes non-catastrophic bugs that cannot be reproduced by anyone but the original reporter. For this latter case, encourage the reporter to attempt to debug the issue themselves, potentially giving suggestions for places where they could instrument the code to find the issue, and invite them to join the Discord for help; then add the `waiting for customer response` label. The issue will get automatically closed after a few weeks if they don't respond.
|
||||
* it is not [actionable](../../triage/README.md#what-makes-an-issue-actionable) and does not [have unusual symptoms](../../triage/README.md#unactionable-bugs-with-unusual-symptoms). This covers a wide variety of cases, such as invalid bugs, bugs without steps to reproduce, bugs that have become irrelevant, or bugs that are unclear and which the reporter has not offered more details for. It also includes non-catastrophic bugs that cannot be reproduced by anyone but the original reporter. For this latter case, encourage the reporter to attempt to debug the issue themselves, potentially giving suggestions for places where they could instrument the code to find the issue, and invite them to join the Discord for help; then add the `waiting for customer response` label. The issue will get automatically closed after a few weeks if they don't respond.
|
||||
* it is a feature request that we are unlikely to ever address, and if we did address it, it would not be part of the core SDK (e.g. it would be in a package). (For example, anything in the [`would be a good package` `P3`](https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+label%3A%22would+be+a+good+package%22+label%3AP3) list is a good candidate for closing without fixing.)
|
||||
* we would not accept a fix even if one were to be offered ([e.g. support for platforms at level of support 4](https://github.com/flutter/flutter/wiki/Values#levels-of-support)).
|
||||
* we would not accept a fix even if one were to be offered ([e.g. support for platforms at level of support 4](../../about/Values.md#levels-of-support)).
|
||||
* it is an issue regarding internal processes, tooling, or infrastructure (i.e. something that our users are not affected by), that we have no plans to get to (e.g. that would be marked P3). (For example, anything in the [`c: tech-debt` `P3`](https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+label%3A%22c%3A+tech-debt%22+label%3AP3) list is a good candidate for closing.)
|
||||
* it is tracking technical debt but the suggested improvements are marginal at best or would require significant research to be evaluated. Prefer having folks who work in the relevant part of the code make improvements based on their judgment.
|
||||
|
||||
@@ -384,4 +384,4 @@ If you need to track some work item, you can file a bug and assign it to yoursel
|
||||
|
||||
When a test flakes, a P0 bug is automatically filed with the label [`team: flakes`](https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+label%3A%22team%3A+flakes%22+sort%3Aupdated-asc). This issue should be investigated with all due haste, and a priority level should then be assigned to the issue. At any particular time, the most flaky tests should remain P0. However, flakes that are hard to pin down may be downgraded in priority (e.g. to P1). Please do not ignore the issue entirely, however, and make sure to close bugs once they are resolved, even if it's by magic.
|
||||
|
||||
_See also: [Reducing test flakiness](https://github.com/flutter/flutter/wiki/Reducing-Test-Flakiness)_
|
||||
_See also: [Reducing test flakiness](../../infra/Reducing-Test-Flakiness.md)_
|
||||
@@ -45,7 +45,7 @@ before the test runs.
|
||||
To run analysis and all the tests for the entire Flutter repository, the same way that Cirrus
|
||||
runs them, run `dart dev/bots/test.dart` and `dart --enable-asserts dev/bots/analyze.dart`.
|
||||
|
||||
If you've built your own flutter engine (see [Setting up the Engine development environment](../../engine/dev/Setting-up-the-Engine-development-environment.md)), you
|
||||
If you've built your own flutter engine (see [Setting up the Engine development environment](../../engine/contributing/Setting-up-the-Engine-development-environment.md)), you
|
||||
can pass `--local-engine` to change what flutter shell `flutter test` uses. For example,
|
||||
if you built an engine in the `out/host_debug_unopt` directory, you can use:
|
||||
|
||||
@@ -118,7 +118,7 @@ The following is an example of what running the local engine command might look
|
||||
|
||||
The above command would use the local Flutter engine located at `/Users/myname/flutter/engine` to execute the `external_ui_integration_test` test on an Android emulator, which is why the `android_debug_unopt_x86` version of the engine is used.
|
||||
|
||||
Note that some tests may require `profile` mode instead of `debug` mode when running with local engine. Make sure to pass in the correct local engine. See [Compiling the engine](../../engine/dev/Compiling-the-engine.md) for more details.
|
||||
Note that some tests may require `profile` mode instead of `debug` mode when running with local engine. Make sure to pass in the correct local engine. See [Compiling the engine](../../engine/contributing/Compiling-the-engine.md) for more details.
|
||||
|
||||
## For the engine
|
||||
|
||||
|
||||
Reference in New Issue
Block a user