Skip to content
This repository was archived by the owner on Nov 18, 2021. It is now read-only.
This repository was archived by the owner on Nov 18, 2021. It is now read-only.

Allow work-in-progress and ready status on pull requests #416

Closed
Closed
Allow work-in-progress and ready status on pull requests#416
Labels
WIPimplementedlabelsparityFeatures that GitHub is missing, but competitors implement; also, see [Migration]project managementpm / agile related conceptspull-requestssaved / draft

Description

@ghost
ghost
opened on Jul 4, 2015

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..

Activity

  1. cirosantilli commented on Jul 12, 2015

    @cirosantilli
    cirosantilli
    on Jul 12, 2015
    Collaborator

    GitLab did it recently.

  2. dagwieers commented on Mar 31, 2016

    @dagwieers
    dagwieers
    on Mar 31, 2016

    Gitlab supports both WIP: as well as [WIP], however it now promotes using WIP: only.

    Documentation still refers to both WIP: as well as [WIP], see: http://doc.gitlab.com/ce/workflow/wip_merge_requests.html, however the newer Gitlab releases promote Work-In-Progress using the message: "Start the title with WIP: to prevent a Work In Progress merge request from being merged before it's ready." for more consistency. So preferably only promote the use of WIP:.

  3. kingmaiku commented on Apr 11, 2016

    @kingmaiku
    kingmaiku
    on Apr 11, 2016

    I recently had to move from gitlab to github and I am missing this a ton!!
    we still use the wip labels in the title of the pull request but the human error factor makes me nervous.

  4. danielkcz commented on May 31, 2016

    @danielkcz
    danielkcz
    on May 31, 2016

    Definitely something I would like to see too.

  5. yzhong52 commented on Sep 16, 2016

    @yzhong52
    yzhong52
    on Sep 16, 2016

    I am also moving from GitLab to GitHub, I would love to have this feature as well! Super useful!

  6. Gaket commented on Feb 16, 2018

    @Gaket
    Gaket
    on Feb 16, 2018

    Hi! Any updates on this feature?

  7. fregante commented on Feb 20, 2018

    @fregante
    fregante
    on Feb 20, 2018

    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

  8. Alxandr commented on Feb 20, 2018

    @Alxandr
    Alxandr
    on Feb 20, 2018

    @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.

  9. fregante commented on Feb 20, 2018

    @fregante
    fregante
    on Feb 20, 2018

    Well, yeah, I was just describing its behavior and offering an alternative for the time being.

  10. thanhtw commented on Mar 8, 2018

    @thanhtw
    thanhtw
    on Mar 8, 2018

    Status = In Progress, Progress = 0%

  11. TheReincarnator commented on Mar 28, 2018

    @TheReincarnator
    TheReincarnator
    on Mar 28, 2018

    @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.

  12. styfle commented on Apr 6, 2018

    @styfle
    styfle
    on Apr 6, 2018

    @gr2m made this: https://github.com/apps/wip

    We are trying it out at @markedjs and so far so good.

  13. AuthorOfTheSurf commented on May 22, 2018

    @AuthorOfTheSurf
    AuthorOfTheSurf
    on May 22, 2018

    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.

  14. mattcopas commented on Jun 28, 2018

    @mattcopas
    mattcopas
    on Jun 28, 2018

    +1 for this feature to be built in. I really miss it from my GitLab days!

  15. RoxaneM commented on Oct 23, 2018

    @RoxaneM
    RoxaneM
    on Oct 23, 2018

    Any update on the feature?
    Same story here: migrated from GitLab and was really disappointed when didn't find this feature on GitHub :(

  16. 6 remaining items

  17. dagwieers commented on Feb 26, 2019

    @dagwieers
    dagwieers
    on Feb 26, 2019

    Would it be possible to make a non-WIP PR into a WIP PR?

    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?

    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.

  18. mattcopas commented on Feb 26, 2019

    @mattcopas
    mattcopas
    on Feb 26, 2019

    @lukehefson Sure - there are several use cases

    • If I simply forget to create the PR as a WIP
    • I need to make more, non-trivial, changes to my PR after it has been reviewed
    • A PR gets reviewed, but I'm out of office for a few days, but don't want a PR merged until I return
    • A PR gets reviewed, but I don't want it merged yet for other reasons (dependent on other work, waiting to merge after a release, etc etc)

    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

  19. TPS
    added
    pull-requests
    labels
    parityFeatures that GitHub is missing, but competitors implement; also, see [Migration]
    project managementpm / agile related concepts
    WIP
    on Feb 26, 2019

  20. TPS commented on Mar 8, 2019

    @TPS
    TPS
    on Mar 8, 2019
    Collaborator

    According to https://miit.dev.tcmunity/t5/How-to-use-Git-and-GitHub/Draft-Pull-Requests-not-available/m-p/19212/highlight/true#M5733 , this is now live!

    If you are not seeing this feature, it is probably because the repository that you're working in does not meet that criteria. If you believe that your repository does meet these criteria and you're still not seeing the feature, please contact GitHub Support directly so that we can investigate.

    Specifics @ https://help.github.com/articles/about-pull-requests/#draft-pull-requests

    If any problems, please comment!

  21. TPS
    closed this as completedon Mar 8, 2019
  22. TPS
    added
    implemented
    on Mar 8, 2019

  23. TPS commented on Mar 9, 2019

    @TPS
    TPS
    on Mar 9, 2019
    Collaborator

    Further news from https://github.blog/changelog/2019-03-08-expand-ready-for-review-permissions-for-draft-pull-requests/:

    The GitHub Blog
    March 8, 2019

    Expand ready for review permissions for draft pull requests

    Any user with repository write permissions will now be able to click the Ready for review button on a draft pull request in order to enable mergeability.

  24. TPS
    added
    saved / draft
    on Apr 21, 2019

  25. kellyarwine commented on Apr 8, 2020

    @kellyarwine
    kellyarwine
    on Apr 8, 2020

    Hi, everyone! Related: this feature shipped today.. Thank you for all of the feedback.

  26. sysarcher commented on Jul 19, 2021

    @sysarcher
    sysarcher
    on Jul 19, 2021

    @kellyarwine if there are no reviewers, can we still create "draft" PRs?

  27. kellyarwine commented on Jul 19, 2021

    @kellyarwine
    kellyarwine
    on Jul 19, 2021

    @willsmythe ^^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    WIPimplementedlabelsparityFeatures that GitHub is missing, but competitors implement; also, see [Migration]project managementpm / agile related conceptspull-requestssaved / draft

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions