I think people will just end up creating Draft PRs and forgetting about it: they wait for reviews and reviewers wait for “ready” status.

It’s have to come from GitHub so more people are aware of this behavior

I don’t think that’s a good default.

@bfred-it is there a reason not to make it configurable? At my work we use draft PRs heavily, it would be convenient to streamline. Github makes it impossible to go from non-draft to draft status, so creating it the wrong way by accident isn't fixable (except for closing the pr and opening a new one), while creating a draft one when you meant non-draft is fixable with one button

I would love to be able to make "draft" the default state for PRs I open. We have a policy of creating a PR as soon as we start a piece of work so that the work is visible. However, as people frequently miss the opportunity to mark it as a Draft PR, we have no obvious way to distinguish which PRs are ready for review and which are work-in-progress.

I don’t think that’s a good default.

As @Daenyth explained after that comment , it's easy to switch from draft to non-draft but impossible to switch the other way. To my mind, that means draft is the only default that makes sense. It's also completely logical that when a PR is first created, it's likely to be a draft. When it's ready for review, it should then be promoted to that state.

I do see a reasonable case that people may be confused by a change in the default behaviour. Perhaps a good compromise would be enabling a PR to be switched to draft state after it's created, then the default would not matter so much. It might also help make the draft button less forgettable if it was visible when creating a PR, rather than hidden behind a menu.

I think people will just end up creating Draft PRs and forgetting about it

That seems quite unlikely to me, especially if the preference is configurable. I find the visual difference between a draft and non-draft PR pretty obvious when I create them. Also, I would have thought someone submitting a PR would take an interest in how it progresses. Do most people not follow up their PRs if they haven't heard anything for a while? If a PR is hanging around in a draft state, people can always message the author to find out why.

#2473 seems like a good compromise.

Perhaps a good compromise would be enabling a PR to be switched to draft state after it's created,

Unfortunately only Github themselves is able to make this change

That would be a great default for us because we keep asking code owners for code review accidentally and automatically

We won't change the default and #2473 is already here: The "Create draft" button is very visible and I noticed I myself create more drafts thanks to that feature.

I think the title I posted this with is unfortunate.

It would be better as: Create configuration option which allows "create draft" to be displayed as the "Default" button on the "create PR" page. The option can default to "off", which means that the behavior of the plugin as of today wouldn't change - this would be in there only for folks who wanted it. Alternately, default to "on" for new extension installs, but if the extension was updated from an older version, set the config to "off" so as to not confuse existing users

@Daenyth with #2486 the DropDown Button is now I. 2 seperate Buttons. With Stylish you can hide with css the Button you don't like to see

As others have mentioned, you can use custom CSS to hide the default button or move the draft option to the right. RGH supports custom CSS overrides, so no need to add another extension like Stylish.

Please remember, this is an opinionated extension and creating options for a small subset of users is not the goal of the project.

On Wed, Dec 4, 2019, 4:02 PM Adam notifications@github.com wrote:

+1 for adding an admin configuration to change the default behavior of initial PR openings.

Our team tends to use tags like "ready for review" whereas it would be ideal if everyone only used draft prs and upgraded them accordingly.

Unfortunately a user can easily click the very green and friendly COA "Create Pull Request" button and currently there's no way to revert back to a draft so we cannot lean on draft pull request as much as we'd like.

An admin configuration that forced the workflow of:

draft -> open -> merged/closed/etc

would be helpful for us (and perhaps others).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/sindresorhus/refined-github/issues/2238?email_source=notifications&email_token=AAGRMZBVCWYX5ZZFSJ2SVCTQXASI7A5CNFSM4IDY3EDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF6UY6Y#issuecomment-561859707, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGRMZHQPF3M65BZ5E3UGBDQXASI7ANCNFSM4IDY3EDA .

Perhaps a good compromise would be enabling a PR to be switched to draft state after it's created

They did! https://github.blog/changelog/2020-04-08-convert-pull-request-to-draft/

Convert pull request to draft

Any user with write access to the repository can convert a pull request to a draft pull request.

To convert a pull request to a draft, look for the “Convert to draft” link in the Reviewers section on the pull request’s Conversations tab. Clicking the link displays a modal asking you to confirm the change.