Conversation
In practice, the review response rate for these auto-assignments is generally quite low. The result is that we frequently have PRs with reviewers assigned but who never actually review; this makes following up on PR status in PR triage more difficult, and can create confusion for new contributors (who believe their PR has a review when, functionally, it doesn't).
|
@bparrishMines @ditman @cyanglaz @LHLL @gaaclarke This is a proposal, we don't necessarily need to do the full removal. However, I would like anyone in this file to commit to actively monitoring their auto-assigned review requests. That means that when auto-assigned you should always either:
If there are packages for which you want to commit to that, please comment here to let me know what those are. (E.g., @cyanglaz maybe you'd want to narrow your assignments to iOS implementations of some package?) Not commenting will be assumed to mean you aren't actively monitoring PRs here, in which case I'll remove you from the file 🙂 |
stuartmorgan-g
requested review from
LHLL,
bparrishMines,
cyanglaz,
ditman and
gaaclarke
ditman
left a comment
ditman
left a comment
There was a problem hiding this comment.
Not opposed to this removing the file, also not opposed to adding myself as:
**/*_web/** @ditman(not sure if those glob patterns would work, basically monitor anything that ends up in _web)
bparrishMines
left a comment
bparrishMines
left a comment
There was a problem hiding this comment.
LGTM
I would also be fine with committing to webview_flutter PRs since I've been working across the entire plugin for the last couple months.
|
I've updated this to leave the file in place with just the commitments mentioned above. We'll see how that goes! |
stuartmorgan-g
added
the
waiting for tree to go green
6 participants
In practice, the review response rate for these auto-assignments is generally quite low. The result is that we frequently have PRs with reviewers assigned but who never actually review; this makes following up on PR status in PR triage more difficult, and can create confusion for new contributors (who believe their PR has a review when, functionally, it doesn't).
Pre-launch Checklist
dart format.)[shared_preferences]pubspec.yamlwith an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.CHANGELOG.mdto add a description of the change, following repository CHANGELOG style.///).