Support a shorthand approach to cross-link issues between projects, possibly by IID

Problem to solve

We commonly track issues for multiple repositories in a single, distinct repository whose purpose is only to manage issues.

We would like a convenient way to refer to issues in the "issue tracking" repository from all "development" repositories so that:

  • we have an instance unique issue ID that we can refer to
    • we might have more than one "issue tracking" repo
    • yes the IID would work here
  • we would like to be able to use this convenient method of reference to perform tasks like close the issue in a merge request and so on

Intended users

Really any role that spends a lot of time using issues as part of their workflow. For example:

User experience goal

Anywhere a user wishes to reference an issue either as a cross-link, or to trigger some action, as they do today, it should be possible to use this approach.

Proposal

A minimal solution would probably be to:

  • support a specific syntax for referencing issues like:

    • #iNNNN where i means instance and NNN is the instance ID
    • #group/path/project/NNN where NNN is the project issue ID
    • iid:NNN where NNN is the instance ID

  • if the Instance ID is used (this has other benefits) then that Instance ID would need to be exposed in the user interface.

    • we would probably prefer to use instance IDs instead of repo local IDs as we simply treat issue IDs as identifiers, the number itself is meaningless
    • given the above exposing the Instance ID could become a system wide preference meaning that only the Instance ID is shown in any location where you would usually see a project issue ID

Further details

Centralising issue management has many benefits in terms of simplifying project management and tracking and that's why we use it. It allows us to have one project and a set of boards that represent the work being carried out across multiple repos without having to piecemeal manage and merge the information that they represent.

Permissions and Security

As they exist today for anything related to linking or referencing issues (no change anticipated).

Documentation

  • Updates to issue cross-linking required.
  • Other changes needed depending on the solution.

Availability & Testing

What does success look like, and how can we measure that?

Main success criteria:

  • It is possible to refer to an issue in another repository in a short-form way and achieve the same results as if that issue was in the local project.

What is the type of buyer?

We are self hosting Gitlab.

Is this a cross-stage feature?

This feature would enable better integration between repos and make integrations more consistent as issues would not be artificially constrained to project boundaries.

Links / references

Edited by ja11sop