Flutter is awesome, but there are definitely bugs that lie unfixed for an uncomfortable period of time. This is not unique to Flutter ... with any open source project there's a lag between bug reports and bug fixes.
The thing I worry about is that its going to be really hard to get a large number of PR reviewers up to speed for this fork, while also maintaining reasonable quality.
I think it's going to be difficult to maintain a separate fork without diverging from Flutter, because over time, the fork will accumulate bug fixes and features that the Google version will not accept (by definition, since the proposal is to be more accepting of PRs). How are we supposed to go back to the Google version of Flutter as the fork diverges more and more from the original?
Or is the proposal that we should stick with the fork, and the fork will over time pull in the new features and PRs from the Google version? But how will that work after say 12 to 24 months of divergence? There's going to be a hodgepodge of new features and bug fixes on the fork, and then Google will release a new version of Flutter with a whole set of new capabilities ... and we'll be stuck having to choose. Or we'll have to do a really hairy merge between the Fork and the new version from Google.
This just seems scary to me. Especially since for any given team, there's usually one ... or maybe two things we want to patch into the Flutter tree. Its easier for us to just apply those fixes onto a new version of Google's flutter tree than it would be to patch a whole community's worth of bug fixes and features onto the new Google tree.
I think the preferable course of action is that the community should work with Google to see if there's a way to improve the speed of PR reviews.
I'm worried about the chaos that forking could cause in this community that doesn't really have a huge number of contributors yet.