Work in progress pull requests

[drdanz]

It's happening more and more frequently that people (myself included) open pull requests for work in progress branches, for different reasons (testing if something breaks some build, requesting early feedback, etc).
I think this is a good thing, but sometimes it is not easy to spot whether a pull request is a real one, or a work in progress.

I suggest to follow this workflow in gitlab, i.e. add WIP: or [WIP] at the beginning of the title of a "work in progress pull request" and remove it when the pull request is ready to be merged.
Even if this feature is not supported by github (in gitlab the merge button is disabled for this kind of merge requests), it will avoid accidental merges.

What do you think?

[pattacini]

I fully agree.
Nice suggestion.

[lornat75]

+1

[barbalberto]

We could also define WIP as a label to make it more visible

[drdanz]

@barbalberto We already have a "Status: In Progress" label, we can use that, I think...

[pattacini]

We could put this info in Yarp here: CONTRIBUTING.md.

[vtikha]

Excellent!

Sent from my phone

On 17 Jun 2016, at 13:56, Daniele E. Domenichelli <[email protected]mailto:[email protected]> wrote:

It's happening more and more frequently that people (myself included) open pull requests for work in progress branches, for different reasons (testing if something breaks some build, requesting early feedback, etc).
I think this is a good thing, but sometimes it is not easy to spot whether a pull request is a real one, or a work in progress.

I suggest to follow this workflow in gitlabhttp://docs.gitlab.com/ce/workflow/wip_merge_requests.html, i.e. add WIP: or [WIP] at the beginning of the title of a "work in progress pull request" and remove it when the pull request is ready to be merged.
Even if this feature is not supported by github (in gitlab the merge button is disabled for this kind of merge requests), it will avoid accidental merges.

What do you think?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/121, or mute the threadhttps://github.com/notifications/unsubscribe/AEU-gwOg_N_MzjV8kg_6f8yPF8Bkq1IVks5qMn1HgaJpZM4I4P7t.

[randaz81]

+1

[PeterBowman]

As you probably know, GitHub has introduced draft pull requests: blog, docs.

When you create a pull request, you can choose to create a pull request that is ready for review or a draft pull request. Draft pull requests cannot be merged, and code owners are not automatically requested to review draft pull requests. (...)

When you're ready to get feedback on your pull request, you can mark your draft pull request as ready for review. Marking a pull request as ready for review will request reviews from any code owners. You can convert a pull request to a draft at any time. (...)

Changing between ready-for-review and draft PRs back and forth is described here.

For future reference, YARP used to implement a GitHub app that prevented from merging PRs that had been described as "WIP" in their title. I believe it was this one. I haven't seen it for a while, so I presume official GH draft PRs are the preferred method by now.