-
Notifications
You must be signed in to change notification settings - Fork 130
Allow work-in-progress and ready status on pull requests #416
Comments
GitLab did it recently. |
Gitlab supports both Documentation still refers to both |
I recently had to move from gitlab to github and I am missing this a ton!! |
Definitely something I would like to see too. |
I am also moving from GitLab to GitHub, I would love to have this feature as well! Super useful! |
Hi! Any updates on this feature? |
I doubt they'll add an actual status, but perhaps blocking the merge via title or tag would be good, like this extension does https://chrome.google.com/webstore/detail/do-not-merge-wip-for-gith/nimelepbpejjlbmoobocpfnjhihnpked |
@bfred-it this puts the requirement on the user though. A better solution would likely be to make a GH integration that responts to events on PRs and uses the status API to set it as "failed" if it has a WIP tag or similar. |
Well, yeah, I was just describing its behavior and offering an alternative for the time being. |
Status = In Progress, Progress = 0% |
@hoangthanh1234 Does not work for me. Even with "in progress", the merge button is still functional. The main aspect of the feature request is to disable the button to prevent errors, like GitLab does. |
@gr2m made this: https://github.com/apps/wip We are trying it out at @markedjs and so far so good. |
https://github.com/apps/wip Mentioned above by @styfle works great! Main requirement for me is something that's built-in to Github--a browser addon is NOT good enough. If you add the WIP app to your project and you already have PR's with "WIP" in the title, you will need to edit and save the title to get it to register with WIP. |
+1 for this feature to be built in. I really miss it from my GitLab days! |
Any update on the feature? |
I was surprised to not see this feature in GitHub after using GitLab, seems like such a no-brainer QoL feature. Hope to see this someday! :) |
FYI, adding a reviewer removes the WIP: from PR titles |
We (GitHub) shipped https://github.blog/2019-02-14-introducing-draft-pull-requests/ the other day! 🎉 It might not solve for all the problems in this thread – but we'd love to know what you think! |
I'm likiing this feature - very useful! Would it be possible to make a non-WIP PR into a WIP PR? |
Yay! I'm so glad to hear it @mattcopas!
We've been hearing more and more of this feedback since launching and are definitely looking to iterate. Can I ask you what your use case(s) would be @mattcopas? |
@lukehefson You thought you were done, you got back feedback about things that needs changing, and it will take some rewriting, so you transition back to WIP, work on it for a while, and then flag it as ready for review again. |
Not so difficult use-case. You are working on something and deem it perfect, so you remove the WIP status. Then you find a showstopper, and you want to restore the WIP status. |
@lukehefson Sure - there are several use cases
For the first case, it's far to say that I could just close/re-create the PR, but once the PR has been commented on at all, it's certainly not desirable to do this |
According to https://github.uint.cloudmunity/t5/How-to-use-Git-and-GitHub/Draft-Pull-Requests-not-available/m-p/19212/highlight/true#M5733 , this is now live!
Specifics @ https://help.github.com/articles/about-pull-requests/#draft-pull-requests If any problems, please comment! |
Further news from https://github.blog/changelog/2019-03-08-expand-ready-for-review-permissions-for-draft-pull-requests/:
|
Hi, everyone! Related: this feature shipped today.. Thank you for all of the feedback. |
@kellyarwine if there are no reviewers, can we still create "draft" PRs? |
@willsmythe ^^ |
I often see [WIP] and [Ready] prefixes in the titles of pull requests, and everyone at my work (including myself) uses this convention as well. It's a good way to begin getting feedback on something that's still under construction.
However, it would be great if this could be integrated a little further into the github UI. For example, a [WIP] status could give a warning when someone's trying to merge the related PR. Or changing to a [Ready] status could send a notification to the repo owner. Stuff like that.
I'd say that it deserves its own place in the UI, since so many people tend to use it. Right now it's just not as integrated as it should be if you ask me (since we're misusing the title tag for it). Curious to hear what others think..
The text was updated successfully, but these errors were encountered: