Stream: t-release/triage

Topic: Marking PRs as draft

view this post on Zulip Vadim Petrochenkov (Sep 07 2020 at 09:45):

I noticed that one of the PRs assigned to me ( was converted to draft by triage team.

Why was it done?
Draft status is redundant when we already have waiting-on labels, and is not useful neither to reviewer nor to author.
It also confuses automation (or at least it did in the past).

view this post on Zulip Vadim Petrochenkov (Sep 07 2020 at 09:47):

Large portion of PRs actually arrive in draft status and need significant rework, without being marked as draft.
This is a usual matter of communication between the author and reviewer, and switching between waiting-on-author and waiting-on-review is enough to facilitate it.

view this post on Zulip XAMPPRocky (Sep 07 2020 at 11:04):

@Vadim Petrochenkov Not related to your specific PR, but it’s worth noting that GitHub is planning on making the draft state of PRs more meaningful with pull request revisions.

view this post on Zulip DPC (Sep 07 2020 at 15:16):

not sure why this one was marked as draft (it doesn't have to) but normally it's done for experiments or to signify that it is work in progress (waiting-on-author would suffice but it's also used for other things such as when there are changes requested or conflicts, so draft is a more specific case)

view this post on Zulip Charles Lew (Sep 08 2020 at 02:49):

I did the conversion, because it seems the PR is not quite ready for review(needs investigation and maybe large portions of changes)? Since the PR authored by rust-lang member, we cannot ping that member, instead we'll need to bump the labels again and again if it's in S-waiting-for-author state but not as a draft PR (if it's in draft PR state we as triagers can just skip it).

Last updated: Jan 26 2022 at 14:20 UTC