question in the topic
I think it must have made sense to the people at GitLab who made the change, @c33s . Do you have a use case you can share on why this is less preferable? Or maybe you were simply just curious? 
it’s just because for me “Draft” is simply wrong in my workflow.
- create an issue
- create a new branch for that ticket
- push the new branch (which currently has no changes) to the gitlab server
- create a merge request via api/pushcommands
- start working on the features
- commit and push
- discuss & comment the MR on gitlab
- repeat work/commit/push/discuss until finished
- remove work in progress flag
- merge
so a MR is really work in progress and not a Draft
of course i simply can ignore the new word and still see it as Wip but i also was curious and just wanted to know why this change happend (had quite an impact for me).
the change broke my automated workflow because gitlabs api has no toggle/set wip/draft flag but only a “update title” which is not that handy.
my workflow broke because i had to fetch the title and strip the WIP: from the title and then save it back. after gitlab changed the wording not enough chars are stripped from the title. so i asked myself what is the benefit of this change? can it justify that peoples workflows/api calls break?
sidenote: the whole thing of having the WIP/Draft flag in the title is suboptimal. a title should be a string field and a wip/draft flag should be a bool flag. why the mixup?
while you were at touching the wip handling you could have done it right and better implemented a bool flag instead of string juggling 
but well. i changed my workflow scripts and will write a small greasemonkey script to change the Draft: back to WIP: on my computer
1 Like
This is SUCH great information, @c33s! Thank you for writing all this out!
And, do you feel like sharing that nifty greasemonkey script with us here? Other people might be interested, you know? 
I was curious about this too, so I did a little reading. It seems they are introducing the concept of “WIP limits” those who’ve used Kanban might be familiar with to their issue boards. They seemed concerned that this caused the term “WIP” to mean 2 different things. I suspect since GitHub already used the term “Draft”, it made sense to go with that. See https://gitlab.com/gitlab-org/gitlab/-/issues/32692.
At the moment, the filter still shows WIP
And you can type in “WIP” just as you used to before (even though the link that used to add/remove “WIP” now adds/removes “DRAFT”.
But this is something they are deprecating and removing I believe (see https://gitlab.com/gitlab-org/gitlab/-/issues/228685). When that happens, that userscript won’t be work (in that GL will probably stop preventing MRs with “WIP” from being merged).
For my part, my team has a similar workflow as @c33s, but I don’t think draft is a terrible name. Here’s why (from the perspective of how my team uses the flag). Other team members are welcome to comment on a MR that’s in progress, but it’s still in progress, the implementation might change as the engineer makes more progress and has to adjust his/her implementation. But it is a good time to comment if the direction is wildly off-base. We don’t expect comments for more minor things (style, DRYing up the implementation, cleaning up structure of files/classes, naming conventions, etc) until the flag is removed, indicating it is ready for final review. In this sense, what’s out there is a draft, it’s not the final version. Think of it as the issue/card/story as what’s in progress, not the MR.
Additionally, we use the WIP flag for another purpose, which is for marking a MR as “here’s an incompletely implemented idea I had, what do people think?” And in that context, draft makes a lot more sense than WIP.
On the title string thing, I’m of the same opinion as @c33s. I would rather have seen this done with a separate attribute. I was kinda surprised it wasn’t originally implemented with a label if you were looking for a quick and dirty implementation. But now that the implementation has to be re-worked anyway, it might be a good opportunity to move it to a new attribute.
the userscript does not exist yet and it would be just cosmetic for myself. so if i edit a MR it will still say draft but in the MR listing or in the detail view i simply replace draft with wip. so no magic here.
Additionally, we use the WIP flag for another purpose, which is for marking a MR as “here’s an incompletely implemented idea I had, what do people think?
what you describe here would be a pefect candiate for draft for me.
Other team members are welcome to comment on a MR that’s in progress, but it’s still in progress , the implementation might change as the engineer makes more progress and has to adjust his/her implementation.
that is a wip for me.
thats the reason i would even would like to have both options.
Well, when it comes to naming things, as they say
There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.
I can understand why the GL team would want to avoid that complexity, but I actually intuitively expected a choice of options (for whatever that feedback is worth). I actually went looking in the settings for an option controlling what string to use for marking an MR as a draft, but didn’t find it, of course. And that’s what started me down the path of finding out why the string was changed.
At the very least, it probably would have been useful to have a notification pop-up or something describing what changed, why, and what the migration plan is. The way it rolled out was kinda confusing. Doubly so by the fact it’s only partially implemented (e.g. still wip in the MR filter). And I have no idea when “wip” will cease to work (assuming that’s the plan).
Actually, I realized this morning, using the wip filter doesn’t filter drafts. There’s an issue for that (https://gitlab.com/gitlab-org/gitlab/-/issues/231299).
All WIPs are drafts, but not all drafts are WIPs.
Good change. All Drafts Matter.