Relations between Issues

Note: this is a transplanted issue from the deprecated feedback.gitlab.com. This does not reflect the opinion of the author.

Original feedback item: http://feedback.gitlab.com/forums/176466-deprecated-feedback-forum/suggestions/7106510-relations-between-issues

Please add option to specify relations between issues. For example like Redmine does.

Idea is very simple: Each issue can have relation to any other issue. Relations are bidirectional. And the relation may be of one of few types.

Types of relations:

• blocks / is blocked by
• follows / precedes
• related to
• duplicate of
• part of (subtask) / composed of

GitLab 8.3 will automatically link all linked issues and MRs. I think we could add that to the API. Specific relations like proposed above seem very rigid to me and add a lot of complexity.

I had to subscribe to this. Looking forward to seeing it.

@dnoe I don't expect we will do this at this point. Can you explain your use case?

I like "blocks #NN" and "part of #NN". Else is bonus. For me this is mainly for consistency and record, and of course, for issue automation (automatic closing).

@JobV I see specific relations in a similar way as labels. If a "label" is a binary relation between a label and an issue, "relation" between issues would be ternary relation between two issues and a label (from different set than ordinary labels).

Question is, whether there is need for anything else than those five types of relations, because relation does not have only a name and a color, like label does. Relation needs two labels, because of its direction ("blocks" vs. "blocked by"). And some of its properties needs to be specified, like whether the relation is transitive, so filtering can include or exclude issues related to related issues. For example when I want to see issues blocked by given issue, a filter needs to calculate transitive closure (recursively expand the relation on related issues until all reachable issues are found). On the other side, issue may be related to a second issue, but not to the third issue to which the second issue is related to.

Purpose of the relations should be to allow advanced analysis, visualization and planning by third-party tools or extensions/plugins, while keeping Gitlab's issues simple and easy to use.

One of the reasons that some projects don't use Gitlab's issues and use an external tracking platform is the lack of issues relations. Without relations issues are just flat, no way to actually track progress of big features. No way to create a "meta" issue that depends on 4 other or create subtasks and so on. The same problem exists on Github too. It would surely make a difference if Gitlab offers a full features tracking issue, instead of just flat issues. Relations is a major first step towards that.

I definitively agree with @comzeradd which expresses precisely why we don't switch so far from Redmine to Gitlab for big project management. May be not all relations should be implemented at first but at least the dependencies between issues (i.e. follow / preceed) would be a good start without compromising I think the simplicity of Gitlab's Issue tracker.

On my side, the other feature I would appreciate to see imported from Redmine would be "task/issue completion bar" such that we could visually see the progress of an issue. I'll open a separate feature proposal for that (Done: see #13487 (moved) ). I still mention it here since part of the completion can be automated from:

• number of sub/dependent issues completed
• number of tasks completed

I'd like to have "DUPLICATE OF" or "INVALID" instead of "CLOSED". Maybe also "BLOCKED BY" instead of "OPEN" makes a sense. This is one of my favorite features in the old-fashion bugzilla.

I completely agree with @svarrette on this. I use Jira to keep track of my issues and I'm not moving to Gitlab purely for the same reason. I'm missing the agile approach here (epics, user stories, etc...) which I can't make happen with the current implementation. Having links between issues would be a first step into the right direction.

same here, sticking with redmine because of not having relation between tickets.

really like the relations redmine defines :

related to - Just adds a link to the other issue.

duplicates - Links issues so that closing one, will close the other (e.g. closing A will close B)
For example, if issue B duplicates A:
- closing B will leave A open
- closing A will automatically close B

duplicated by - Reciprocal of duplicates.
For example, if issue A is duplicated by issue B:
- closing B will leave A open
- closing A will automatically close B

blocks - Links issues so that closing one can be blocked by an issue which is still open
If issue B blocks A,
A can't be closed unless B is.
blocked by - Reciprocal of blocks.

precedes - Links issues to define an "order", where A needs to be completed x days before B can be started on
If B follows A, you can't give B
a starting date equal or less
than the ending date of A.
follows - Reciprocal of precedes.
If issue B follows A (ex A ends the 21/04 and B begins the 22/04)
and you add +2 day at the ending date of A,
the starting and ending dates of B will be +2 too.

copied from - Links issues to identify whether it was copied, and from which issue it was copied from.
copied to - Reciprocal of copied from.

I would love to see what @c33s outlined above within gitlab. I know it's probably far fetched, but I am still following. The feature that was released recently that allows you to "move" an issue helped quite a bit in itself. My problem is duplicate issues, because end users have no idea what project said code might be in (said code could be used in several projects).

This feature will be possible to configurate if it will be possible to create custom fields of issue (#445410) of type 'issue relation'.

Hi, is possible show related subtask in group between task description and comments part ?

maybe

@JobV Hi, is any news about this issue ? :)

Added Product work label

mentioned in issue #15204 (closed)

mentioned in issue #19481 (moved)

mentioned in issue #19624 (closed)

mentioned in issue #4182 (closed)

I think the first approach to be implemented is the issue referencing (or linking) as proposed in this issue because it's the simplest feature of the listed in previous comments as "mentioned in issues" and the must have one for every bug tracking system.

@sh2ka agree, like how the merge request are linked.

I would use 'depends upon/is prerequisite for' instead of 'follows / precedes' for a dependency relation.

I think that single words would be preferable, e.g. depends/blocks

Den 11. aug. 2016 2.58 PM skrev "Mikhail" gitlab@mg.gitlab.com:

blocks and issue dependencies would be much appreciated, my team is reluctant to continue using gitlab for this reason!

we'd like to be able to note for example issue 1 is blocked by issue 2, and when issue 2 is closed, this info is reflected on issue 1's page.

mentioned in issue #21453 (closed)

@JobV I think we can start with only one type of relation: blocked. On issue can be blocked by multiple others. Multiple issues can refer to the same issue as a blocker. This allows all kinds of orderings and Gantt charts. Related issues is something we should maybe solve another way, like we mention related items in merge requests.

@JobV Gantt charts should be EE only. Not sure about relations between issues because of technical impact.

@sytses It does not make much sense to implement just on type of relation. The relation should be a generic tool. Gitlab may understand some of them and treat them in a special manner, like the 'blocked by' relation. Having many special relations will make code too complex and relations hard to use.

I see relations like a label, but with two issues assigned instead of one. This way the relation may be defined just like label -- title, color, but also a meaning, how it should be interpreted by Gitlab. The meaning may be just a simple enum with predefined behaviors/meanings.

The Gantt diagram is useful even for small projects. It should be CE feature for sure. But there are features like export to MS Project to integrate with resource planning. Then the Gantt diagram would be like a teaser for all these project managers.

From my current use of ikiwiki as an issue tracker, I've made the experience that more than one hard-coded "blocks / blocked by" relationship is useful in issue tracking; I've also used "possible duplicate" (a symmetric property) and "trivial after / makes trivial" (which is distinct from blocking when the blocker is costly to implement). In the implementation of relationships (blocks plugin), the issue could conveniently be solved once and for all instead of later-on hacking different meanings into relationships.

I concur with jk that relationships should be label-like, and that some could have predefined static semantics attached.

@sytses I propose just re-using the Closes #123 concept from Merge Requests on Issues as well.

Thanks for the input everyone. It might well be right that we need more types of relations (or no type to start). I do still think Grant charts are more useful if there are more than 100 potential users. With smaller teams they are sometimes needed but less that in large team. I like re-using the Closes #123 idea. Maybe not only merge requests can close issues but issues can close issues as well. This would mean that issues would define what they solve, instead of what they are blocked by, kinda reversing the relation.

@JobV I'm attracted to https://latticehq.com/ to specify our company goals. If we make this detailed there will be duplication between Lattice goals and issues. If we can have a relation between issues (no type needed) we could visualize issues in this way. This would also solve epics https://gitlab.com/gitlab-org/gitlab-ce/issues/20135 Epics would be any issue linked to multiple issues. Or we would make the link hierarchical (parent-child) so it is easier to see what is an epic and how to display everything. /cc @markpundsack

I like re-using the Closes #123 (closed) idea. Maybe not only merge requests can close issues but issues can close issues as well. This would mean that issues would define what they solve, instead of what they are blocked by, kinda reversing the relation.

Is there a use-case for such thing? It could be useful to close meta issues when all related sub-issues are completed. But that is a bit rare thing and I don't think anyone would like to happen this automatically, because someone should always check the meta-issue is really done.

I do still think Grant charts are more useful if there are more than 100 potential users.

Gantt charts are useful even for small teams when there is a lot of issues, because it shows dependencies between the issues, so the developers know where to start and what to do next. It also helps to prioritize tasks on which depends someone else.

Another benefit of gantt charts is that they show progress, so the customer and boss have a picure to watch instead of asking "Are we there yet?" all the time :)

What about to not build complex features, but just focus on making platform for other integrated tools?

On use-case with Gantt diagram in means: allow to save any metadata (fields) on all entities (issues, merge requests, ...) by API and optionally display them in web interface. Other apps can then build around it more sophisticated features like Gantt diagram. Example: Bandcamp and www.gantt-chart.com

Jan Pobořil http://honza.poboril.cz/

smime.p7s

But that is a bit rare thing and I don't think anyone would like to happen this automatically, because someone should always check the meta-issue is really done.

@jk I think its rarity is defined by the group of people using the system and cannot be generally defined for everyone. We use "[Meta]" issues. I think GitLab does, too.

As to whether closing a high-level issue automatically is a Good Thing (tm) is in the eye of the beholder. The same could be said of Merge Requests. We have some cases where an Issue cannot be closed until all related MRs (across more than one project) close and even then, it may not be done until the Quality Assurance testers check it over. But all that doesn't stop us from using the Closes #123feature.

In any case, if people did not want it to close automatically, all they have to do is not use feature.

@janpoboril Exactly. The platform for other apps/features.

We already have a very nice example of such tool and its great use: the Board, where labels are used to store metadata and the Board is built above this storage. Do the same with the relations -- simple metadata storage to build on.

I see here multiple issues mixed together (also a little summary of the long discussion):

1. Simple relations: [Issue A]---(relation R)--->[Issue B], which is a ternary (A, B, R) relation in a database. The R is very similar to current Labels. Such a generic approach will allow the Relations to fit any reasonable workflow, because possible relations are defined by users, just like the Labels are.
2. A generic metadata per-issue key-value storage, the storage which could be used by third-party apps or other components integrated into Gitlab. Gitlab Issues would display the metadata, but would not care about them. Basically, it could be a JSON object.
3. Gantt diagram component, which would display & edit relations between issues and some additional metadata (like time estimates, prices, ...). Enterprise Edition could offer some nice connectors to resource management systems and other business stuff, while Community Edition would provide a sweet tool to create realistic roadmaps.
4. Interpretation of the relations by Gitlab. The R (from the first point) will have semantics defined (nullable enum of implemented semantics). Gitlab then can interpret these semantics on various places, like offering non-blocked issues on the Board first or auto-closing meta issues.

This issue is only about the first point (or at least it was when I posted the original feature request on the old discussion forum). The other three points should be discussed separately in their own issues.

mentioned in issue #21659 (moved)

May I suggest we write up some use cases and problems to solve before focusing on the solution? Perhaps it's obvious for those using other tools that have similar capabilities, but I'm having trouble seeing why you'd want some of these relationships in GitLab.

So far, I've heard Gantt charts and epics. What else are we trying to solve for?

For example, it's true that there are often duplicate issues, but what would you want to happen when you write duplicate of X? Just close the issue? Anything else?

It's better to make resolved and invalid distinct. Issue dependency should also be a good feature.

@markpundsack
Say, you have a team.
You added two issues: A (assigned to developer1) and B (assigned to developer2) with dependencies: A blocks B.
So once you've added them, you don't need to ping developer2 up to start working on B when A is done, he will be notified (or will see by himself) that B is unblocked.
And at the same time you will be sure that developer2 won't waste his time solving issue B until he gets that B is actually blocked by A which hasn't fixed yet.

So when A is done, B would get a system message (and notification) that it’s unblocked? OK, that makes sense. Would B also be hidden from some view until it’s unblocked?

Documentation on issue relations in popular trackers, just to compare:

• JIRA
• Redmine

What else is relevant here?

Would B also be hidden from some view until it’s unblocked?

It would be useful filter to have, also it would be useful to sort issues using topological order on Board and other issue listings, so the unblocked issues would be first.

So when A is done, B would get a system message (and notification) that it’s unblocked? OK, that makes sense. Would B also be hidden from some view until it’s unblocked?

It would be great to have such feature.
I'm not sure it's going to be implemented in the first iteration.

@markpundsack have a look at my post https://gitlab.com/gitlab-org/gitlab-ce/issues/4058#note_4591812 i quoted the redmine definition there.

i also like the clear interface for adding a subtask or a relation, i don't have to edit an issue to add a relation. in gitlab i can only edit an issue to manually add something like "blocked by #34 (closed)" in the description.

having an issue relation management would help to quickly make related issues accessable. try it out by yourself http://demo.redmine.org/

@markpundsack bugzilla has had the concept of one or more ticket(s) blocking another for quite some time. We used that for over ten years before switching to GitLab and it is a feature I miss. A dependency tree between issues enables planning and workflow.

This is can be seen as related to issues boards in that blocked issues should not be able to move ahead until the blockers are at least implemented perhaps reviewed.

@markpundsack: We use GitLab to manage software on interconnected embedded systems. What often comes up is this:

• New functionality on one system changes the protocol in a slightly incompatible way.
• Software on other systems have to be updated to understand the new protocol, take advantage of the new functionality, and stop complaining about the unexpected data.

For this I would create multiple issues:

1. Issues for the new functionality that we need. (Project A)
2. Issue for defining the protocol changes. (Project A)
3. Issue for implementing the protocol changes on the module. (Project A)
4. Issues in related software projects for implementing the changes required to understand the new protocol. (Project B, C, D...)

Then I would add these relationships:

• Issues from 1 -- DEPENDS ON --> Issue 2
• Issue 3 --DEPENDS ON --> Issue 2
• Issue 3 <-- RELATES TO --> Issues from 1
• Issue 3 <-- RELATES TO --> Issues from 4

Currently I can do this by putting links in comments, but that's a manual process, and it is very easy to miss one side of the relationship. It is also harder on anyone looking at an issue because they have to click on the link to actually see what the other issue and its status.

I hope this helps.

Thanks for the examples everyone!

mentioned in issue #19841 (moved)

Mentioned in issue #21453 (closed)

Mentioned in issue #22215 (moved)

Added ~14281 label

Mentioned in issue #22322 (closed)

Added ~874211 label

For the record, Gantt chart for GitLab issues is now a reality, it's free and MIT licensed: https://gitlab.com/clorichel/ganttlab

Mentioned in issue #15305 (closed)

For the record, Gantt chart for GitLab issues is now a reality, it's free and MIT licensed: https://gitlab.com/clorichel/ganttlab

See https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7499. Sadly, until there are relations between issues, there will be no arrows in the Gantt diagram and issues will not be arranged automatically.

Mentioned in merge request !7499 (closed)

Adding a GanttPredecessors: (like the GanttStart:) to the Gantt.vue should be enough to generate an even more advanced Gantt chart like this one: https://gitlab.com/gitlab-org/gitlab-ce/issues/15305#note_14349642.

An issue #N with a GanttPredecessors in its description just has to use the latest due date of all predecessors to "override" this issue #N value for GanttStart, so #N will be disposed automatically on the Gantt chart even without a GanttStart.

@clorichel Unfortunately, such tags in the description are more like an ugly hack than a proper solution. And it would create huge burden on developers later when dealing with the consequences. They already enjoying similar problem with the subscibe feature.

Sure! Please read GanttStart and GanttPredecessors as slash commands

I like the idea :) Another syntax suggestion (in the form of my favorite use case):

/requires \#555 

Means that this issue 'requires' 555 to be closed before it could be closed. In such case 555 will be shown in "BLOCKED BY" GUI section in top of the issue until 555 is either closed or "not required"

So second statement is

/notrequires \#555

Means that this issue doesn't require 555 any more. In this case it is not shown in "BLOCED BY" section in top of the issue, and not listed in the issue list

Issue list GUI should contain all the blockers

\#222    TitleOf222               |  blocked by: \#555 TitleOf555, \#666 TitleOf666

like the idea with the slash commands, i would only remove the backslashes.

/requires #000

mentioned in issue #25237 (moved)

mentioned in issue #14232 (moved)

We're migrating from Redmine and we do miss this feature ...

Our flow is:

The reporter reports an issue, and we developers create sub tasks upon that issue...

in Redmine, we also had a percentage graph that would reach 100% when all sub-tasks were completed, was a great way about checking 1 item without the need to drill down all subtasks.

@balexandre I have the very same problem and would like to move issue management to GitLab.

Off-Topic: Which theme is that? It looks really modern.

mentioned in issue #25904 (closed)

About real life use cases:

Would be cool if it also works cross-project/group, as we usually need the backend to implement a feature before we can use it in the different clients. Example:

Blocks #android/source/123
Blocks #ios/source/456 
Blocks #macos/source/789
Blocks #win/source/88

Or just using this in all the different clients would be sufficient:

Requires #backend/source/777

I agree with @Pe-te about cross-project/group relations.

To be consistent, I would just suggest using the same format used for markdown.

Ideally, relations could point to the following types:

• Issue namespace/project#123 or project#123
• Merge Request namespace/project!123 or project!123
• Milestone namespace/project%123 or project%123

I think it's fairly common to have an issue that has a dependency on one of the above types. Since both merge requests and milestones have a concept of being closed, this seems like it could work fairly easily. The only tricky problem might be if a merge request was abandoned, then the dependency should probably be considered unmet.

Each of the types have the following states:

• Issue
  • Open
  • Closed
• Merge Request
  • Open
  • Merged
  • Closed
• Milestone
  • Open
  • Closed

If there is a dependency on a merge request, then I would suggest either

1. Only considering the dependency met if it is merged
2. Or having a depends-on-merge and a depends-on-close option

I'm not sure which of the above would be more appropriate.

Amazing to see this topic still being discussed. Still following.. ;)

mentioned in merge request !8280 (closed)

mentioned in merge request !8284 (closed)

mentioned in issue #13523 (moved)

mentioned in issue #26372 (closed)

Yes, subtasks would be an amazing feature for us! Particularly if they could be from other projects! Our use case is to have user stories in a design repo, and then link those to work item issues in various project repositories that implement the requirements of that user story. It would be great to be able to see how many of them are done (and even aggregate time estimates in Gitlab EE) to get clearer insight into overall progress, and overall estimates.

Blockers would give better insight into when an issue can be started, and subtasks would give insight into how long it will take! This would be transformational in the scope of what issues can be effectively used for!

mentioned in issue #26838 (moved)

mentioned in issue #27462 (closed)

mentioned in issue #15275 (moved)

We need to manually track what issue depends on what right now and manually cross off completed issue numbers. As you can guess this is a very error prone process. Having issues dependencies tracked and updated automatically would be a huge plus for us too.

Would make much easier also when you have a project made by multiple repositories/services where the non tech team creates general issues that can be detailed in the right repo and make the main issue dependent on these child project related issues

/cc @victorwu This is a super popular feature request. There's so many participants I can't tell if you're already in the list!

mentioned in issue #28068 (closed)

@victorwu, can we add a milestone for this feature request, please?

mentioned in issue #28344 (closed)

Are there any updates to this? When can we see this implemented? This is super important for us to adapt gitlab issue tracking in our organisation (EE user if it matters)

Yeah! When we can see?

I can confirm as EE user that this feature (relation between issues) is the most desired update for our current project. Adding milestone will be a great sign that GitLab team is going to present this feature soon (or at least this will be added into roadmap).

Same. As an EE user this is one of the missing features that might prevent us from moving way from JIRA (blocked relationship for example).

I could really use this feature if it were available

I would like to see this feature for CE also

@rmoreas ,@ben36 etc... The GitLab team judges demand for a feature by the number of upvotes. If you don't have anything meaningful to add to the discussion just upvote and subscribe to it. The added noise in a discussion is undesired behaviour.

This comment itself is meaningless as well but I hope I can prevent more comments of that type this way.

@hedgehog it's just slightly surprising that there's no milestone set and the lack of comments from the gitlab team given that this appears to be the second most wanted feature.

actually, this is the most popular issue...

If this issue is accepted to be implemented, can we start from UX here?

/cc @awhildy, @dimitrieh, @tauriedavis, @victorwu

And if it's Accepting Merge Requests, I'd like to implement this feature proposal.

Introducing relationships between issues will considerably increase the complexity of GitLab. That is not a reason not to do it. But it is a reason for us to be strategic in when we do it, and ensure we have a good design that is scalable and aligns with our other initiatives.

We are currently focused on issue boards as the primary structure for organizing issues, and building features around that. I know that doesn't completely solve the problems listed here. But that is our first area of focus in terms of adding more structure between issues.

We already support lists of tasks in issue descriptions. And many users use that to form parent-child relationships. Again, this isn't as "native" as you may want. But our strategy would be to further build on and expand that functionality first, before doing something more "native" than the relationships described here. With task lists, there is still a lot of flexibility, and is less restrictive. That helps us keep GitLab simple as long as we can. Beyond the user benefit of simplicity, it allows us to move faster when we build new features, since our codebase is simpler and our user-facing components are simpler. We don't have to account for as many existing pieces when building a new feature.

Of course, as we expand on GitLab, we need to make it more powerful, and that necessitates more complexity like the feature described here. But the product strategy is to make small iterations as quickly as we can. And to maximize that ratio of solving as much pain with smallest effort solution. We're not yet at the point where we've exhausted other options and small iterations to make inroads in this problem just yet.

So back to our current strategy in regard to issue management and structure. We are working on issue boards for the broader picture. For relationships between any two issues, we are more closely considering #23177 (moved) as a mechanism to beef up issue task lists so we can make it easier to manage lists, thus having making that implicit parent-child relationship much more usable. #27157 (closed) allows users to essentially bookmark issues for easy access and tighter control. That is another one we are closely managing. And we have just scheduled multiple assignees (#13386 (closed)), which makes it easier to manage issues when several people are working on them at the same time.

I wanted to re-iterate that I recognize these alternatives do not 100% solve all the totally valid problems discussed here. We recognize these are real problems and are painful, so I want to thank you for your feedback. We need it and do appreciate it. We try to participate as often as we can in discussions, and I apologize in advance if we don't get to answer every single comment.

@victorwu I thing you are doing a very subtle mistake which will become fatal in long-term. Your strategy to take small steps that cover as much functionality as possible is reasonable, but it is necessary to be careful, as it leads to a critical state when there is too much little stuff built up without proper structure to support it.

For example, the list of subscriptions to issues (#12697 (moved)). It should be simple to implement, but it got stuck on lack of infrastructure, as the implicit subscriptions were not stored in an obvious way, while the explicit subscriptions were a simple relation between the issue and the subscribed user.

Another example are issue boards. They represent elegant use of a good infrastructure ­— it is all just a smart use of labels. It would be very complex feature without the use of labels.

Issue relations are meant to be the basic infrastructure to build on (at least that is how I meant it when I posted the original feature request). Just like the labels are just a binary relation between a issue and a "label", the relations should be just a ternary relation between two issues and a "label". Then you can build issue task lists on top of the relations like you've built issue boards on top of the labels.

When the relations are implemented in the right way, they will simplify Gitlab, not make it more complex.

@jk Good examples. Another one:

There is also #8988 (closed) about custom fields. It there is some flexible architecture like in Drupal - all entities can have custom fields (and some form widget and some formatter), so building other features what needs to store data is more simple. There also is entity reference field type (with many different widgets and formaters) what can be used to implement e.g. parent-child relation between issues, so there is no need to have this feature in core, but user (admin) can implement it easilly by the configuration.

@janpoboril Few years back, when I was working on proprietary CMS, the custom fields solved most use-cases we encountered. Shortly it had become the most used feature. However, the generic nature of the custom fields introduced great challenges when it come to filtering and searching ­— it was a typical EAV model with all its problems. It is another good example of generic and powerful infrastructure for many little features, but in this particular case I must warn everyone: Stay away from EAV. It is really useful, but hard to deal with. Better use some similar aproach, take advantage of domain-specific features if you can.

added ~19492 label

Just a few thought towards this issue:

• duplicate of seems less of a priority to me.. closing with label "duplicate" seems fitting.. unless we want to track how many duplicates have been made of a certain specific issue
• blocked/blocks and child/epic relation are most important (which also cover subtasks/composed/follows/precedes)

@victorwu @smcgivern as for diplay how about we solve it for https://gitlab.com/gitlab-org/gitlab-ce/issues/15275 as well with (first iteration):

functionality wise we could let this be done with slash commands and system messages and/or buttons within this widget.

thoughts?

this seems to be closely tied with https://gitlab.com/gitlab-org/gitlab-ce/issues/1369 and showing that info on mentioned issues in system messages.

---

As for anyone, please see if this design would fit your usecase or how you would visualise such information!

@dimitrieh that looks nice, but many issues will just be parents or children, so will have relationships on one side only. Won't that look a little unbalanced?

@dimitrieh duplicate of is also quite important, often there are informations/logs/attachments/comments in duplicate issues that a person which is working on the main issue may also want to read. if i only have the option to label a duplicate ticket i have to migrate this to the main issue. this is maybe the best way but in praxis people won't do that often (from my experience)

I think the design i good, but there must be some automatic balancing for leaf/root issues, as the lists will be unbalanced. Is a single column listing too bad?

Also, please replace the heading "Issue relations" with "Related Issues".

We could just make it a single list.. although I tried it this way to save on vertical space. But prob you are right!

@jk Related Issues is already used to describe one of the inner lists for https://gitlab.com/gitlab-org/gitlab-ce/issues/15275

@jk @c33s @smcgivern what about the next iteration:

folded: unfolded:

I will see if i include duplicate at a later stage.. it could prob be done ;) @smcgivern what are your thoughts on that?

assigned to @dimitrieh

Related Issues is already used to describe one of the inner lists for #15275 (moved)

Does not matter. Meaning is the same. Moreover, the "Connections" title is really weird — If I've seen it for the first time, I would have no idea what it is about.

It would be reasonable to later convert related issues in merge requests to issue relations as well. It would allow us to use the same (and more powerful) tools to reference merge requests from issues and from other merge requests. — For example: “Merge this before that.” / “Merge both of these or don't merge anything at all.” / … It may be useful to coordinate MRs spanning multiple projects (libraries, plugins). Of course, this is a matter of the distant future ;)

folded/unfolded

I don't see a reason for collapsing "outbound" relations. The relations are directed, but the direction does not affect relevance nor importance. Once a relation is defined, it should be treated equally in both issues.

If you want to collapse the long list, drop the description and make issue numbers inline:

Blocked by:
#a, #b, #c

Instead of:

Blocked by:
  - #a Aaaaaa
  - #b Bbbbbbbb
  - #c Ccccccc

But keep the button to expand them. It may be useful to expand short lists by default. For example list of parent issues will usualy consist a single item, but children list may be quite long. Also, a list of duplicates may be very long (there is a bug in KWin with >200 duplicates).

Btw, keep in mind that users may define custom relations just like they define custom labels (likely not in early iterations, but it should be possible later). I wrote about that earlier and it is quite easy to implement.

mentioned in issue #29171 (closed)

@dimitrieh I agree with @jk, couldn't we show something similar to what we show on the MR page for this?

Thanks @dimitrieh for the discussions and designs. Just want to set expectations that I don't anticipate these ideas being implemented in the near future, given what I mentioned earlier here: https://gitlab.com/gitlab-org/gitlab-ce/issues/4058#note_24644575.

Nothing stopping us from further discussing though. Thanks!

I actually don't think it's a good idea to allow defining custom relations, because then it's harder to give them special behaviors, and the whole point is to enable special behaviors (right?), such as planning roadmaps or displaying timelines based on child issues, or planning sprints based on blockers, etc.

In the same vein, I don't think the UI for this feature should necessarily show all types of relationships in the same place. An issue will have at most one parent (if such a relationship is decided to be a good idea), so it would make sense to just have a sidebar item, or perhaps something directly under the issue title, linking to the parent. However, it could have several "children" which it would make sense to list as above, and have expanded by default. As for "blocks" and "blocked by" - I would collapse those by default, and put them in a less conspicuous area (possibly under Time Tracking/Due Date in the sidebar) since they relate mainly to planning, and aren't conceptually part of the content of the current issue.

My key point is that "relationships" is an implementation that happens to support an array of useful and requested features, but the implementation shouldn't dictate the way those features are exposed (unless by necessity of the implementation, but in that case we may have the wrong implementation). From a UI perspective, we should be thinking about how each of these features should look and behave independently. (Bonus: if we get lucky, the Gitlab team will take some of those suggestions to heart, even if they don't like the "relationships" implementation)

I would like to see all relations under the task description. Some relations may be detailed, other may be very compact (depending on type of the relation). Also, there should be generic GUI to add and remove relations. I agree that there are going to be various features based on relations and they will need their own GUI, but there should be a generic fallback to deal with some unforseen cases. We are talking about an edit button, so it should not pollute GUI. I would follow ho lables are done.

I actually don't think it's a good idea to allow defining custom relations, because then it's harder to give them special behaviors, and the whole point is to enable special behaviors (right?), such as planning roadmaps or displaying timelines based on child issues, or planning sprints based on blockers, etc.

I was thinking about his some time ago and there is no conflict in this. Each relation will have two titles, color, meaning, and properties defined.

To render a relation, Gitlab will use one of the titles (depending on the direction of the relation from the current point of view) and the color.

The special behavior will depend on the meaning and properties of the relations:

The "meaning" will tell Gitlab how to interpret the relation. For example, a "parent/child" relation will have the meaning set to "one is a part of another", and then user may define a "subtask" and "subcomponent" relations to distinguish two situations, but Gitlab will understand because all three will have the same meaning and it can render a tree with three different kinds of edges.

The properties may define, for example, whether the relation is transitive or not. The parent/child relation is obviously a transitive, but "duplicate of" may be transitive too, but other relations like "related to" may not be transitive. Another interesting property may be symmetry. For example "duplicate of" relation is symmetric, but "parent/child" is not.

The point of the "meainig" and "properties" is to avoid hard-wiring the special behavior to a small set of predefined relations. From implementation point of view, the only difference is that instead of working with a particular relation the algorithm will work with a set of relations of given meaning/property. To deal with the relations there may be few generic algorithms to retireve list of related issues, which will use relations of given meaning and if the relation is transitive, it will recursively include issues related to the related issues.

User-defined relations do not introduce much complexity, they just need to be done right (there is a complex theory in the background). The initial implementation of the relations and the few elementary generic algorithms to work with them will likely cause headache to a programmer (or two), but in return we will get incredibly powerful and quite simple infrastructure to build on.

So if many teams need something quite different and Gitlab team does not want to have features like this, maybe it is better to just build good platform for plugins what can create features like this. Good start is custom fields where plugins can store their data, so it is not needed to deal with external database. Then API for altering UI, so users will not need to install some browser plugin.

Like Basecamp and services like gantt-chart.com or Toggle.

I don't really understand why this is such a huge pain to get it started. This is basically the last missing feature for many of us before we can switch from jira to gitlab - and this would be so nice (simple, integrated, free etc.).

Maybe just start with a "basic" setup like "blocked by" and "parent / child". This would be enough to get a good workflow IMHO.

I perfectly agree with the conclusion of Simon Hardt!

It sounds like it's mostly a matter of implementation details where there is resistance. In order to respect and defer to the Gitlab core development team on implementation decisions, it might be best to elaborate on specific needs in terms of the desired features themselves (if they haven't yet been expressed or addressed by proposed solutions).

• There is a feature proposal for "blocking issues" here: https://gitlab.com/gitlab-org/gitlab-ce/issues/25104
• There is a feature proposal for "sub-tasks" (AKA parent/child relationships) here: https://gitlab.com/gitlab-org/gitlab-ce/issues/21453

I would recommend voting for and adding details (in terms of use cases and process requirements that haven't already been expressed) to those issues, since they more closely align with the features we all need.

@victorwu has already expressed in the first link that he plans to think about them together (as in the relationship model outlined here), but in terms of user input on the features themselves, we should try to focus on defining the desired outcomes rather than the implementation.

(I grant that many of us contribute code to Gitlab, and would also like to participate as members of the development team in guiding the implementations, but clearly the core team has to have the final say in what direction that takes... unless someone wants to create and maintain their own fork of Gitlab ;) )

Thank you all for the detailed feedback. I want to emphasize we value your feedback. We believe it is a huge advantage for us to be able create GitLab transparently here in the community, with your contributions, whether they be ideas and analysis here or in actual code. Thank you for your excitement and passion. I apologize in advance that we cannot answer or address every single comment in detail.

@josephmarty mentioned desired outcomes as a focus. That is great. We encourage all types of feedback. Whether you want to highlight a problem, a desired outcome, have a design or implementation. Whatever you have, we welcome the ideas and encourage ongoing conversation.

In particular, we try to highlight specific problems and pain points that we understand are major. And then we go about analyzing potential solutions (design and code-wise), and balance how it affects our platform short term and long -term, what are the risks of implementation, and a whole host of other considerations. So again, this feedback is extremely helpful and impacts that.

Regarding this specific issue, I have nothing to add at this point, so just linking to my previous comment here: https://gitlab.com/gitlab-org/gitlab-ce/issues/4058#note_24644575

mentioned in issue #29513 (moved)

@florian-monfort Check out Victor's comment here: https://gitlab.com/gitlab-org/gitlab-ce/issues/4058#note_24644575

mentioned in issue #30047 (moved)

EE implementation: https://gitlab.com/gitlab-org/gitlab-ee/issues/2001

@hedgehog We are using this theme: http://www.abacusthemes.com/en/themes/redmine-theme

Just to chime in, I'm a new GitLab customer and I really miss the following features from other issue trackers:

• Closing an issue as a duplicate of another one. This allows easy tracking and sorting of popular feature requests or common crash reports.
• Marking an issue as as a subtask of another. Having task lists in a description is a great start, but it doesn't help (AFAIK) navigating from child back up the chain to parent. Creating umbrella issues is a very common way to track the top-level focus areas for a release. It would be inappropriate to create either labels (too many, not germane across milestones) or milestones (all the top-level focus areas are linked together for a single release).
• Marking an issue as blocking the closure of another. This is critical when several developers are working together, so that everyone is aware when progress on critical issues is blocked, and what needs to be resolved.

WRT the "ternary relation" comments up above, that's not quite correct as I understand things from several previous issue trackers. Setting up any of the above three is actually more like instantiating a diamond diagram: a >>- R --> b >>- R' --> a, where R' is defined as least inverse of R. One can ask "is A blocked by B?" and also "is B blocking A"? It's also common to want to compute the transitive closure of these relations, for instance, in listing all the issues that are, transitively, duped to the current one to hunt for information about how to reproduce them.

I don't think that these are particularly advanced use cases of a bug tracker. They're about breaking down and organizing issues, and linking them together to make sense of them. Using an issue tracker without them is, in my opinion, a little like using an outlining program that only supports two levels of nesting, or like using Wiki software that doesn't have the concept of reverse links. Makes me sad!

Of course, I'm still a relatively new user to GitLab so if I'm wrong about any of these things, please, feel free to direct me to the docs! I'd be overjoyed to learn I'm wrong.

WRT the "ternary relation" comments up above, that's not quite correct as I understand things from several previous issue trackers. Setting up any of the above three is actually more like instantiating a diamond diagram: a >>- R --> b >>- R' --> a, where R' is defined as least inverse of R. One can ask "is A blocked by B?" and also "is B blocking A"? It's also common to want to compute the transitive closure of these relations, for instance, in listing all the issues that are, transitively, duped to the current one to hunt for information about how to reproduce them.

@cbarrett Not really. Don't forget the M:N relations are bidirectional. You just have to ask twice — once for each direction. So the query is something like select * from relation where relation.source = this.id or relation.target = this.id, where relation.source = this.id is your

$R$

and relation.target = this.id is your

$R'$

. (For better use of indices it may be better to perform two queries to avoid or.)

I've implemented relations in some CMS many years ago exactly like this and customer loved it when old referenced article showed backwards references to new stuff automatically :)

Closing since we have:

https://gitlab.com/gitlab-org/gitlab-ee/issues/2001

https://gitlab.com/gitlab-org/gitlab-ee/issues/2035

https://gitlab.com/gitlab-org/gitlab-ee/issues/2036

Nooooooooooooooooooo

@victorwu ahm no: this is the Gitlab-CE tracker. it's rather pointless in closing issues here, just because some feature might be present or not in Gitlab-EE. Similarily you could close a lot of issues, just because GitHub already has them.

I consider my participation in Gitlab-CE issues an active, albeit unpaid, contribution to the development of Gitlab. Should I rather not?

Thank you @umlaeute for your participation in GitLab. As part of our product development, we make decisions during the planning stage of whether features should be in EE or CE. More details here: https://about.gitlab.com/about/#what-features-are-ee-only.

To help in issue tracking and planning, we close issues and merge content to make sure everything is as up to date as possible, on an ongoing basis. Certainly we have too many issues to manage all at once. So we use labels and milestones to track them. And issues that are scheduled for development (have a milestone on them) or that are very close to being scheduled, will reflect more accurate information.

So as part of that process, we will try to close issues if the ideas are unlikely to be implemented. In particular, if a feature is planned for CE, it will be in that issue tracker, and we'll close any EE issues that are duplicates. Similarly, if it is in EE, we will close out CE duplicates (such as this one). GitLab is one product with multiple versions. If a feature is in CE, it will automatically be in EE. But certain features are EE-specific and not available for the CE version.

This feature is a planned EE feature and so it is being tracked there. We currently have no plans for it to be in CE, so that is why this issue is closed. Again, feel free to review the process outlined for further details: https://about.gitlab.com/about/#what-features-are-ee-only. I hope that explains why this issue has been closed. Thank you again for your contributions.

@victorwu This feature definitely seems like something organization with less than 100 members would use.

I run a team of about 5 and was experimenting this feature on zenhub and found immediate value to this. I'm pretty confident a solo-dev to a team less than 100 would find this feature a necessity.

I agree to @zakiaziz - this is a killer-feature which I miss since I switched from Jira to GitLab. I'm using GitLab on a daily basis even in solo-projects and I miss this every day.

Everybody would find value to this when using Issues and realize, that some depend on others (so basically always).

This might be the time to fork this project.

@victorwu If you are worried about loosing a feature which would make people upgrade from CE to EE, then don't. Issue relations are more like a framework rather than a feature. Having them in CE will make development easier for you and still there are plenty of advanced features for EE, like reporting or planning, which project managers will love and desire. Moreover, many other free issue trackers have these relations in basic setup, so you need to catch up anyway.

You definitely mention that everything that is primarily in your scope or vision must be in CE, and I'm sure that issue relations are major and essential part of of your scope (from IDEA to PRODUCTION, mainly in parts idea, tracker and plan(board)). So you are here going against your definition of which features must go in CE and which to EE.

@victorwu Thanks for the detailed explanation. I perfectly understand the need, as a business, to monetize the development of new features.
'm of the opinion however that related issues (and more advanced issue filtering (#32025 (closed))) are essential tools for a product that should manage the planning and workflow of a project, no matter the size of the organization. I'd need those functionalities as a solo developer on my free time, and I'd need them at work for my development team of around 10 people.
My company has unfortunately started to look elsewhere for issue trackers, because other products offer a more robust set of basic tools for the job (while lacking in other areas, where GitLab excel, of course).

We're just a small startup with 4-5 developers and are already in (desperate) need of this feature because we have a backend and multiple client platforms. Since that is a common setup I guess a lot of other startups will need that too if they want to do it right.

This is more or less the only thing i miss from the other issue trackers / PM systems i've been using.

Gitlab excel in so many ways, but this feature will really enable Gitlab to compete with the dinosaurs (apply metaphor of choice here) out there.

I really don't think this is a good place to cut the feature list short.

we really need this feature in the CE. this is too essential to move it to EE and EE is too expensive for small teams.

having jira and redmine as competitor you realy should add this basic feature to the CE.

i really have to say, that i dislike jira but their pricing schema is better for one person companies. i get an selfhosted enterprise server for 10 developers for 10$ one time payment. this is more than affordable. i would even pay 100eur to have more "mini" users, which are only allowed to create and comment issues. having only one or two developer i work with but many one time customers which would clutter me the valuable full users. for me the one time payment is very important. all abo models are often too expensive on the long run (thanks adobe for forcing me to stick with cs6).

Under the current EE pricing these accounts need to pay for a full developer seat. So having a small team of 3 developers and 20 clients we would need to purchase 23 licenses.

We would be happy to pay for the 3 developer licenses and get Gitlab EE Starter should we need to utilize the extra features it provides but the extra 20 licenses is a deal breaker for us.

see https://gitlab.com/gitlab-org/gitlab-ce/issues/18732#note_30938700

This is a feature the GNOME project has also expressed a need for cc/ @victorwu

@victorwu: This feature should not be EE only based on your own promises and guidelines for what features are EE only. This feature is necessary for efficient issue tracking even in a one person team. I would be curious to know how you determined that this features is primarily for large teams.

I also agree with @c33s. The current pricing model is flawed. There are organizations where most of the users of GitLab are occasional users not directly involved in the software development process. They need occasional access to issues and files from repositories, but they will never commit a single line of code. User roles already make a distinction between developers and these users, but the pricing model does not. It's very difficult to justify the cost of EE when 90% of your uses do not use the GitLab daily.

I understand that you need money to continue development of GitLab, but you should work with the users on determining which features should be EE only. Closing down issues and using your what features are EE only page as explanation looks dishonest and sends the wrong message. If you want to convert more users to EE there are things you could try that do not involve crippling GitLab for CE users.

Or, make it a feature that is available on EE 6 months before it is available on CE (but be open about this in order to not annoy users that upgrade to EE to get this feature). That way, users that really must have this feature straight away will upgrade to EE. Some might downgrade once it's released on CE, but at least this funds development of the feature.

I agree with you about the non-git users, though. Perhaps a new class of user, with access to the issue tracker, wiki, and environments page, but not code or commits, and a lower per-user cost to access EE GitLab?

Issue relations (subissues,blocking,related,...) are an essential part even for small open-source projects in the idea to production cycle.

This is essentially a base for a lot of EE Features, but not a EE Feature itself.

What i would consider a EE Feature are things like:

• gantt for project management, maybe with time estimations
• blocking of merge requests, that are created by issues that still have a unresolved blocking relationship
• using it for better burn down charts
• others ...

this is being worked on in different sub issues, unassigning for now

removed assignee

@dimitrieh Does this mean that the feature is being implemented on CE?

@zakiaziz I hope so.

I've been subscribed to this issue for over a year now, glad to read all the discussion taking place.

@zakiaziz @dnoe the first iteration is being implemented for EE: https://gitlab.com/gitlab-org/gitlab-ee/issues/2001

I also really hope this is brought into CE. The demand and relevancy seems clear to me, especially since this is currently the most popular issue in gitlab-ce.

mentioned in merge request gitlab-com/www-gitlab-com!6350 (closed)

I agree that these features would be very helpful for small teams. I hope that you move the feature to CE and don't keep it in EE only.

mentioned in issue #33958 (moved)

mentioned in issue ganttlab/ganttlab-live#37

mentioned in issue #34361 (closed)

mentioned in issue #34366 (closed)

I agree with all members of small teams about the necessity to make this feature available in CE.

We are a team of 15 developers and we do need this kind of feature because we use issue for both registering requirements and induced tasks.

As we need to trace relationship between a requirement and the induced development tasks (both defined as issues), I have developed a python scripts that create links in issue descriptions using tasks in markup, but it would be better to have links in the tool itself.

I precise that we have evaluated other solutions and that these feature is available in Jira. Having it in Gitlab CE could attract people to Gitlab ecosystem, with potential future customers that could swap to commercial versions of Gitlab.

mentioned in issue #35496 (closed)

@victorwu -- that link (what-features-are-ee-only) is broken.

Thank you @wjanssen . The section was moved here: https://about.gitlab.com/stewardship/#what-features-are-ee-only.

Thanks a lot @wjanssen.

mentioned in issue #23206 (moved)

Is there any movement on this?

From the stewardship link there looks to be three options:

1. Close the issue and don't implement the feature in CE
2. Add the feature from EES to CE
3. Someone adds an alternate implementation of related issues

I think 3 can be ruled out entirely though as I doubt that an alternate implementation would ever be merged as epics and gannt charts are going to depend on this feature in EEU.

Also, point 2 of the Promises section:

We won't introduce features into CE with a delay, if a feature is planned to land in both it will be released simultaneously in both

runs counter to the claim from @dimitrieh:

the first iteration is being implemented for EE

Thank you @ljennia for the feedback.

@dimitrieh 's comment regarding

the first iteration is being implemented for EE

is explaining that related issues as a feature (i.e. https://docs.gitlab.com/ee/user/project/issues/related_issues.html), is an EES feature, and it is our "first iteration" into the broader area of linking/associating issues together. Since we currently have no plans to bring this specific feature to CE, it indeed satisfies:

We won't introduce features into CE with a delay, if a feature is planned to land in both it will be released simultaneously in both

That is, related issues (again, this feature one specifically).

Epics are a different way to link issues together. So that's our next iteration in the broad area of linking/associating issues together.

Blocking issues are yet another way to link issues together. But we don't have that currently scheduled yet.

I'll go ahead and close this issue so that there's confusion. So the summary is the following:

• Related issues (Already implemented): https://docs.gitlab.com/ee/user/project/issues/related_issues.html
• Epics (first version in 10.2): https://gitlab.com/gitlab-org/gitlab-ee/issues/3550
• Blocking issues (unscheduled): https://gitlab.com/gitlab-org/gitlab-ee/issues/2035

I assumed that was the case, but wasn't sure. Thanks for the clarification @victorwu

I'm glad you're closing it so that there's confusion. :-) Personally, I've been confused since I first saw this issue. Seems like a no-brainer to add a "blocking" relationship and a "is-part-of" relationship. The apparent resistance to adding this functionality is my main concern about our organization moving from GitHub to GitLab. Bi-directional untyped relationships don't really move the needle, IMO. /Though I can see why you'd start there, to implement the mechanisms.

I agree. This is a big limiting factor for me and one of the reasons I'm considering leaving Gitlab. This feature is missing and the board setup is severely lacking (different issue, but serious enough).

Very disappointing, all this. I can't understand why one would think this is not a community-deserved feature. I'm a student, I sometimes work on larger teams using a central university gitlab (ce) instance. And there is definitely a need for issue relationships.

Sometimes, I work on (non-commercial) projects with less people too. For example, I've got one project with only two developers. We have had about 120 issues in half a year. But we are waiting for that issue relation feature. Even with so little as 120 issues you have duplicates, you have issues that can only be fixed if another one is, you have issues that are part of another one, ...

And I cannot understand why this should be reserved for EE. I completely agree with @voidstarstar's message:

The demand and relevancy seems clear to me, especially since this is currently the most popular issue in gitlab-ce.

And of course, I can only approve of @PhilippHeuer's idea:

This is essentially a base for a lot of EE Features, but not a EE Feature itself.

Edit: For those seeking only an option to mark an issue as duplicate, here's the feature, already implemented into CE using slash commands: #26372 (closed)

mentioned in issue csoriano/testGitLab#1 (closed)

mentioned in issue #38639 (closed)

mentioned in issue #27164 (moved)

mentioned in merge request !14679 (merged)

changed weight to 3

moved to gitlab#4007

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue

mentioned in issue gitlab#5360