Skip to content

Investigation - Migrating Issues to Namespaces

We need to investigate the work needed to transition issues feature to be tied to a namespace instead of a project. This means that issues should be available at the project and group level with minimal customization. The end result of the investigation will be a list of considerations, a backlog of issues and a high-level estimate of effort.

Acceptance

  • Iteration plan for moving Issue to Namespace.
  • Improved performance for querying issues owned by Namespace and inclusive of issues owned by children Namespaces. (set benchmark and goals before implementation)
  • Inclusive of WIP for Work Items. (&6033)

Maturity roadmap

Available:
  • A Namespace.Group and Namespace.User can create an Issue.
  • Issue is visible in Namespace.* List and Board.
  • Issue detail routes are mapped to the Namespace.* where the issue was created.
  • Issues from child Namespace.* are also visible in Namespace.
  • A Namespace.* issue can still be closed/reference by an MR in a child Namespace.Project
Viable:
  • Option to create a new Issue from Group + button in global header. See [1] (frontend)
  • Ability to select child Namespace.Project when creating a merge request from a Namespace.Group issue. See [2]. (frontend required)
  • Namespace.Group analytics include issues from self in addition to children issues.
    • VSA
    • Insights
    • Issue analytics
  • Namespace.Groupstatistics include issues from self. Verify other issue counters return issues from self and all children Namespace.* See [3]

[1]:

Screen_Shot_2021-08-23_at_11.17.28_AM

[2]:

Screen_Shot_2021-08-23_at_11.33.30_AM

[3]:

Screen_Shot_2021-08-23_at_12.41.04_PM

Screen_Shot_2021-08-23_at_12.42.03_PM

Screen_Shot_2021-08-23_at_12.42.26_PM

Complete
  • The Namespace.* is the default target for creating a new Issue. See [1] (frontend)
  • Ability to disable Issues in Group > Settings. There probably should be a separate epic tracking parity of Settings and Navigation in Namespace.* (UX / frontend required)

[1]:

Instead of requiring a selection first, default the pickers to the current Namespace:

Screen_Shot_2021-08-23_at_11.15.53_AM

Screen_Shot_2021-08-23_at_11.16.45_AM

Loveable
  • Ability to filter views by Namespace and/or the ability to show all issues from child Namespaces or only issues from current Namespace. (UX / frontend input required)
  • Make it more efficient to select the most probable Namespace.Project or Namespace.Group when creating new issues or MRs from an issue so a user doesn't have to paginate through a list of hundreds of Namespaces to find the ones they use most frequently. (UX / frontend input required)

Considerations based on the future ideal state

  • Epics and Requirements will be migrated to a Work Item (Discussion: #332566 (closed))
  • Promoting an Issue to Epic will cease to exist in the future as you will be able to just switch the type of Work Item
  • A work item can have multiple parent work items.
  • A work item can belong to multiple Namespaces(#296668) or an equivalent technically feasible solution that allows for work items to roll up to parent work items in adjacent Namespaces and be visible within those Namespace views (Boards, List, and so on).

FAQ

Q. How do issues flow in the hierarchy? Is an issue created at a group level visible in child groups/projects or does it only flow up the hierarchy?

A final decision has not been reached yet, but If we had to make one today, it would work like this:

  1. Worked items flow up a hierarchy just like Issues and Epics do today. In the future, we will figure out the ideal solution for rolling them horizontally across one or more Namespaces.
  2. A child Namespaces can assign issues to parent work items (and in parent groups) that are non-confidential.
  3. If a work item is marked as Confidential, it will follow the same permissions rules are Issues and Epics currently follow in terms of visibility.
Edited by Nick Post