Ability to clone an epic

What: Copy (that is, clone) an epic, including all its children, recursively.

Why? This provides a way to kickstart creating epics. And in particular, it solves the use case of templating. That is, suppose you have a business process (e.g. https://gitlab.com/gitlab-org/gitlab-ee/issues/9243#note_132245383) of creating and managing epics and/or issues. You can have specific epics (and specific issues) that serve as templates, but without actually having to worry about extra UI to manage templates as a native feature. Instead, users will have these epics and issues bookmarked, and they can be changed over time. Every time they need to create a new epic/issue, they will just "clone" one of these objects.

Details: We would likely need to first create a copy feature for individual issues first as a baseline feature that will likely help this feature. See https://gitlab.com/gitlab-org/gitlab-ce/issues/21863. When we copy an epic, we copy the title and description. We also make copies of its children recursively, and re-create the tree structure rooted at this epic. So that may mean making copies of multiple epics and children accordingly, and also cloning their respective titles and descriptions too. We would not copy related issues relationships. Just parent-child epic-epic relationships and parent-child epic-issue relationships.

UI: Can be a simple quick action to start off with.

Comments: Not sure if we should copy comments. If the primary use case is indeed templating, then it doesn't make sense to copy comments. Furthemore, we already have the move issue functionality and the promote issue to epic functionality, which do copy comments over, and serve those specific scenarios.

Attributes: We should probably also copy labels at least if the use is for templating. But should other attributes be copied over?

marked this issue as related to #9243

added Plan [DEPRECATED] epics labels

changed the description

mentioned in issue #9243

@victorwu thanks for starting this! Cloning would be super helpful. Some questions and things to call out:

• Can the epic description also be copied over?
• And also the title? Since we typically have a naming convention which would be helpful to keep consistent.
• Sometimes issues within an epic live in different projects - hopefully this isn't an issue.
• Labels should be cloned over
• Assignees should be cloned over (when there is an assignee - some team members work off of being auto-assigned vs. being assigned once work has begun so it would be great to not have to go back and forth and assign appropriately).
• Can confidentiality also be cloned?

THIS IS GREAT! Thanks so much for your support on this!

cc @aoetama @lblanchard @lbanks @jjcordz

@jgragnola :

• Can the epic description also be copied over?
• And also the title? Since we typically have a naming convention which would be helpful to keep consistent.

Yes, that's what in the description now, so I think that would be part of the first iteration as a minimum.

Sometimes issues within an epic live in different projects - hopefully this isn't an issue.

Suppose there is an epic E in group G, with attached issues I and J that are in projects P and Q respectively. When we clone E, I expect this will happen:

• A new epic F is created in group G, copying the title and description of E.
• A new issue K is created in project P, copying the title and description of I.
• A new issue L is created in project Q, copying the title and description of J.
• K and L are attached to E.

Since epics/issues are copied over in their respective groups/projects, I don't see any problems with attaching the new issues to the new epic, and where they live with respect to projects/groups. As long as the original baseline epic/issues exist and are well-defined, then it should logically "just work".

Labels should be cloned over

Yes I agree this would be helpful/necessary for the feature in general, beyond GitLab marketing's needs, though indeed we should focus on GitLab marketing as the first customer. It probably wouldn't be in the first iteration. But I don't see why it can't be a follow-up.

Assignees should be cloned over (when there is an assignee - some team members work off of being auto-assigned vs. being assigned once work has begun so it would be great to not have to go back and forth and assign appropriately).

Can you explain this a bit more? I don't understand how this helps? Suppose you have a "template" as an issue called Create invitation email. Are you saying (for example), that @jgragnola is always responsible for that task in every instantiation of this, and so therefore, every time we clone this issue, it should have @jgragnola pre-assigned already? I would think it depends on the specific marketing campaign and different marketing folks may be responsible?

Can confidentiality also be cloned?

Yes it can. And I think this again makes sense for the general feature and used by different departments, users. Again, probably another iteration, or maybe this one would be quick. We'll have to find out from engineering.

@annabeldunstone @smcgivern : What do you think about this idea to help out GitLab marketing?

https://gitlab.com/gitlab-org/gitlab-ce/issues/21863 is a popular issue for copying issues. As it stands on its own, I think it's a good issue, maybe not totally necessary since we have the ability move issues and we have description templates in general.

But I think now with more powerful relationships (epics and issues here), I think it makes sense to be able to clone an entire tree structure all at once for the "templating" use case. And I think this would be a much cleaner design instead of trying to create a new mechanism of templating that tree structure itself, separately, which I originally considered in https://gitlab.com/gitlab-org/gitlab-ee/issues/9243.

@victorwu to all comments. Labels are pretty big for our organizing, so if that can be in the initial iteration without increasing the scope considerably, I would request it.

To address the assignee crossing over, yes, there are people on the team who are always responsible for specific tasks. And in some cases, not being assigned to the issue causes risk that the issue is not visible in their board and slides through the cracks.

It's my understanding that in most flows, the assignee would only be added when the issue moves into a WIP status, but in our case, sometimes we need that assignee in place during the PLAN stage or even as a heads-up.

For example, for North America events, I would always be the assignee for "Facilitate tracking" "Create follow up email" issues and JJ would be the assignee for "List clean and upload." For design issues, Luke likes to be assigned so he is aware of expected work. It seems this is a common sentiment for the team, so having this carry over (and lack of assignee carrying over as well in those cases where we don't always have a specific assignee for every single epic) would be of immense help to save admin time.

Here's an example with issues that have labels that we require to put the issue in the correct space on our board: gitlab-com/marketing&57 (closed)

Let me know if you'd like me to elaborate!

Thanks @jgragnola : That makes sense regarding the cloning the assignee along. If users are using cloning in the "regular" case, there won't be an assignee, and so this feature won't impact them. If it does have an assignee already, but it's a "template" issue, it's a bit weird by definition of a "template" in terms of a "work template". But since it's harmless and would help marketing, I think it would be a good iteration.

@victorwu I think this makes sense, although we do need to really scope out what's copied: for instance, do we copy closed issues? If we do, and make them open, that's a bit weird. If we don't, that's also weird because you end up with all these open template issues hanging around.

Nice idea

UI: I agree quick action is a good place to start. In a separate iteration we can think about addressing it with a button, since now we'll have Move, Promote, and Clone. We can look into turning the Move button in the sidebar into a dropdown, but we'll definitely need a link to docs to users understand the difference between these actions.

do we copy closed issues?

If a user decides an issue is no longer needed as part of a template and closes that issue, I don't think the closed issue should be copied over. Not the best example, as you can just delete the issue from the epic.

Just chiming in about closed issues... I would expect that the way we (marketing) would use this is to set up the ideal state template with epics and associated issues, assignees, labels, and naming conventions, but we wouldn't actually use (and therefore, would not close) these issues.

I'm sure that other use cases for clone force you to answer the question of what is best to do with them, but that's the perspective for our use case.

cc @victorwu @smcgivern @annabeldunstone

@jgragnola Thanks for the info! That was my understanding of how you would use these cloned epics, but since issues always have the ability to be closed, we need to decide what to do with those issues in that scenario.

I can't think why a user might want a closed issue as part of an epic template, but for simplicity maybe we should just copy all the issues over, in their current state

@annabeldunstone @smcgivern : I'm wondering if we should do https://gitlab.com/gitlab-org/gitlab-ce/issues/21863 first since it's a building block to cloning epics. But if marketing folks here are not particularly asking for it, can we just jump ahead to cloning epics by themselves. (Child issues would be cloned as part of that, but it wouldn't be a standalone feature yet.) Do you folks have a preference?

Starting with issues as a first step makes more sense to me since cloning epics will end up cloning issues as well. Better idea- can we do them in the same release? If the code is similar/shared, it might be easier to tackle both at once.

The issue you linked seems like something that our currently available Issue Templates would solve (although obviously making it easier than going into the code and creating a new template).

I would say the epic cloning is of very high interest to us since we already use templates for a lot of things and the association is what we crave most at the moment.

I'll leave the prioritization for you to determine, of course! But thought I' share the marketing perspective :)

cc @victorwu @annabeldunstone @smcgivern

marked this issue as related to #9421 (closed)

added to epic &780

changed milestone to %Backlog

@annabeldunstone : I think it'd be safer to do two issues. (We might want them in the same release if possible. But we also have a really long backlog of things we need to get to.) I put this issue and the clone issue issue in an epic. &780.

@jgragnola : I put a start date on the epic to give you a sense of when we want to do this. I know it's not exactly very soon, but the Plan team does have a lot of priorities at the moment. You can see the many things we want to get done, and I'm inserting this pretty much ahead of many big things too for now. https://gitlab.com/groups/gitlab-org/-/roadmap?label_name%5B%5D=devops%3Aplan&layout=QUARTERS&scope=all&sort=start_date_asc&state=opened.

The entire product-development team is ramping up with headcount this year so we are now hiring as fast as we can. So with some luck, that may impact this timeline and bring it up sooner.

Thanks @victorwu for the update on timeline. It's understandable that there are many competing priorities in the backlog and while of course we'd love it asap, it's good for us to be able to level-set on when it would realistically fit into the planning.

@aoetama @lbanks @lblanchard @jjcordz this is slated for sometime in Q2 (May-July), and as Victor mentioned in his comment, there's a possibility that this moves up depending on hiring and resources, but this won't be an immediate turnaround and I wanted to clarify that for our planning and organizing!

added [deprecated] Accepting merge requests label

Thanks @victorwu for the timeline estimate and completely understand that you need to fit this into current priorities within the Plan team. I just wanted to echo @jgragnola's sentiments with regards to the importance of epic cloning to help with marketing's use case.

In any case, we will work around not having this feature in the interim. Even if we cannot have this in FYQ1'20, I think we should still be able to seamlessly introduce the feature into our existing workflow (and immediately realize the time-saving benefits) once available.

changed milestone to %12.1

added internal customer label

added backend label

mentioned in issue #9421 (closed)

We didn't get to the first issue (https://gitlab.com/gitlab-org/gitlab-ee/issues/9421) in 12.0, so we'll move that to 12.1 and this one to 12.2.

@smcgivern I'm marking this one as blocked until https://gitlab.com/gitlab-org/gitlab-ee/issues/9421 has been resolved.

changed milestone to %12.2

changed weight to 3

changed title from Copy epic, recursively copying children to Copy epic

changed title from Copy epic to Ability to copy an epic

added devopsplan label

changed milestone to %12.3

added groupproduct planning label

added typefeature label

added Enterprise Edition label

mentioned in issue #9475 (closed)

marked this issue as related to #9475 (closed)

added workflowblocked label

@smcgivern Do you think I can take over some tasks here as part of my internship?

/cc @cablett

ah, sorry, I believe this issue blooms on @johnhope's turf now

@johnhope Would you be ok with me giving this a try?

@winh Sure thing, but it still seems to be blocked by gitlab-org/gitlab-ee#9421.

Do you have what you need to tackle it?

removed [deprecated] Accepting merge requests label

@johnhope Closing this issue is not possible without https://gitlab.com/gitlab-org/gitlab-ee/issues/9421. However we could do the following:

1. Make /clone only work for epics without child epics or issues.
2. Make /clone work for epics with child epics by recursively applying 1. (depth-first)
3. Make /clone work for all epics by applying https://gitlab.com/gitlab-org/gitlab-ee/issues/9421 recursively to issues.

Each step can be a separate merge request. That way we can work on this issue and https://gitlab.com/gitlab-org/gitlab-ee/issues/9421 in parallel.

Does that make sense to you?

@winh Seems like a nice way to break it down, however should we try and keep the UI consistent with issue cloning as in #9421 (closed)?

@annabeldunstone Do you have any thoughts on /clone vs /copy and are you still happy with the optional argument syntax (https://gitlab.com/gitlab-org/gitlab-ee/issues/9421#note_135146293)?

@gweaver What do you think of this as a way to break down the complexity?

cc @kokeefe

@johnhope / @annabeldunstone I like Clone over Copy.

@winh @gweaver I think that is a great way to split it up into sequential items. To @johnhope's point, we should strive for consistency in the UI where possible. Are there any reasons that is difficult or not possible at the moment?

@gweaver do we have a path forward for #9421 (closed) so it can move in parallel?

we should strive for consistency in the UI where possible

I agree but given that this issue seems to be about introducing a quick action, I don't see how we would cause UI inconsistency.

@winh For my part I was just referring to #9421 (closed), where the issue description mentions /clone but the discussion seems to have settled at /copy.

I know it's (literally) semantics, I just thought whichever we choose it should match for both epics and issues :)

Ah, sorry, I was thinking of the sidebar when reading UI.

I agree; it should be clone. I think we were under that impression all along; I'll update the title

2. Make /clone work for epics with child epics by recursively applying 1. (depth-first)

Should it be possible to the user to specify if they want to clone only current epic or the whole tree? What should happen if user runs clone on an epic in middle of the tree(second level deep) and there are parent and child epics it has ? Is this intended to always copy the whole tree ?

Is this intended to always copy the whole tree ?

@acroitor From the issue description yes (and that makes sense for the use case in https://gitlab.com/gitlab-org/gitlab-ee/issues/9243). For simplicity I would suggest we keep limiting the levels to clone to a follow-up issue.

removed Plan [DEPRECATED] label

cc @kokeefe

changed title from Ability to copy an epic to Ability to clone an epic

assigned to @kokeefe

assigned to @johnhope

unassigned @johnhope and @kokeefe

marked this issue as related to #9215 (closed)

mentioned in issue #32506 (closed)

added missed:12.3 label

changed milestone to %12.4

added 1 deleted label

added documentation label

marked this issue as related to #5163 (closed)

removed the relation with #5163 (closed)

@kokeefe This issue is blocked by #9421 (closed) but that issue has been backlogged.

We could break this down as per @winh's suggestion in #9398 (comment 206418702) and prioritise the first for %12.4 or we can move this out of the milestone for now.

1. Make /clone only work for epics without child epics or issues.
2. Make /clone work for epics with child epics by recursively applying 1. (depth-first)
3. Make /clone work for all epics by applying https://gitlab.com/gitlab-org/gitlab-ee/issues/9421 recursively to issues.

As far as I can see it depends on whether you see the first two stages as providing value on their own. What do you think?

@johnhope I'm of the mind to move it and do it together with #9421 (closed).

@gweaver thoughts on timing?

@kokeefe OK I'll backlog it until #9421 (closed) is prioritised.

Delivering the two together makes it more necessary to break this down, otherwise this will be blocked until #9421 (closed) is fully completed. I'm inclined to go with @winh's breakdown, so I'll create those issues too.

Issues are #33427, #33432 and #33433 so I'll update the description and move this into the backlog.

Ty @johnhope

mentioned in issue #33427

mentioned in issue #33432

mentioned in issue #33433

changed milestone to %Backlog

marked this issue as related to #33427

marked this issue as related to #33432

marked this issue as related to #33433

mentioned in issue #13634

marked this issue as related to #13634

added workflowstart label and removed workflowblocked label

added [deprecated] Accepting merge requests label

added Dogfooding + 1 deleted label

added DogfoodingBuild in GitLab label

@kokeefe this is a large dogfooding ask from various departments across the company. Would you consider prioritizing this in the next release or two?

Tagging @gweaver as well for your thoughts on #9421 (closed) if these two are related.

I don't think this should be considered blocked by #9421 (closed) now. The first iteration was going to be just for epics with no child epics/issues (#33427), the second for child epics (#33432). So really only #33433 is blocked by it.

The breakdown in #9398 (comment 225501331) still applies so we could promote this to an epic and start working through these iterations whenever there's capacity.

@ebrinkman with the focus on Epic Swimlanes and then Epic Boards I can't commit to within the next 2 releases at this time. I'll work with @gweaver, @johnhope , and @donaldcook on possible timelines

mentioned in issue #29115 (closed)

assigned to @kokeefe

changed the description

added workflowvalidation backlog label and removed workflowstart label

added sectiondev label

Commercial customer interested in this https://gitlab.my.salesforce.com/0016100001CXyhe (internal)

added customer label

unassigned @kokeefe

We're a Silver customer interested in this. We discovered we had our epics public, and in order to have private epics and still have a few private repositories, we need to create a private subgroup. However, this means transferring all our epics manually (or via the API), which is a huge PITA and I think we will lose the history/comments if I'm not mistaken, which I'm not sure we're willing to do.

Maybe a better solution for us will come from &2885 (closed) but probably we will still need to migrate at some point.

Despite being in this crappy situation due to Gitlab limitations (combined with misunderstanding of the implications when we started using group-level features), I don't blame you for prioritizing epic boards and swimlanes... those will also be quite useful for us.

mentioned in issue #328660 (closed)

We will get this for free if we transition epics to issue types + work item hierarchies -- #271171 (closed) and #229731 (closed). We're currently exploring this so we have better parity between issues and epics moving forward. This would also help -- #271586.