-
Notifications
You must be signed in to change notification settings - Fork 9.1k
Define a policy using draft PRs when waiting on specific approvals #3802
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Another option is that we could define a minimum time for non-trivial PRs to remain open. (An examle of a trivial PR would be #3804, although we could use labels if we want to avoid vague heuristics). |
"in draft" and "waiting for specific approval" seem contradictory to me. Is there a specific label that could be used here? Or assign the review to the tsc team? (Is there a merge policy that could be set up to require N reviews from that team before it can be merged, without getting in the way of other PRs that have a different merge policy?) |
I think we have two things here:
Draft is fair enough if the author does not believe that the PR can currently be merged (pending more changes, someone particular to review it, something else). |
HI @lornajane , @handrews , @ralfhandl Did we ever close the loop on this on a prior TDC? |
I think we discussed this, in a TDC call and in Slack:
Not sure whether these rules belong into DEVELOPMENT.md or CONTRIBUTING.md. |
Added notes about reviewers and draft PRs to the contributing file https://github.com/OAI/OpenAPI-Specification/blob/main/CONTRIBUTING.md#pull-requests |
We've had some understandable confusion on when PRs get merged, as we came up with some exceptions to the "2 TSC approvals" rule in TDC calls. But not everyone is at every TDC call, nor can everyone be expected to remember everything that came up. So we should put PRs into draft, even if they are otherwise ready for merging, if we want to wait for a specific approval.
Just filing this b/c I don't have time to try to update DEVELOPMENT.md but we should do that at some point.
The text was updated successfully, but these errors were encountered: