Simplify Groups & Projects - Solution Validation
Identify solution for these problems and mitigate risks:
- Business viability: Does the solution work for our business?
- Technical feasibility: Can we build it?
- Usability: Can the user figure out how to use it and is it better received than our current approach to Groups and Projects?
- Value: Will this drive an increase in key business metrics such as SpU, SPAN, SMAU, and AMAU?
Real Customer Use Cases To Solve
Problem Set 1: Interacting with Objects across top level groups / sibling hierarchies
#8668) [Problem 1]
Priority 1. View an Issue Board that contains Issues from 2 or more top level / sibling Groups (
- We have 3 top-level-groups: Libs, Products, Customer-Related
- There are issues I am assigned to in subgroups->subprojects in each of those top-level-groups
- My manager wants to see my workload in a board (and those of the colleagues, of course :) )
Related:
Pull up a board – that has every Developer in my Team across ALL Groups – not just Top-Level Group they align to
#205155 (closed))
Priority 3. Assign Issue from Namespace A to Epic in Namespace B (Epics can have issues assigned from a different group
Priority 4. Remove the need to duplicate labels across top level Namespaces [Problem 1]
We have same labels across all Groups – Aggregate all the Labels across all Groups and accessible in Issue Boards.
Related but yet to be prioritized problems:
- Need to Track Multiple Milestones across Multiple Epics that may or may not be related and may or may not be in the same top-level Group
- Customer proposed solution: If I could have an Epic Board – that shows all Epics / Sub-epics Milestones on the Gantt Chart along with %Complete (or how much has been accomplished) and ability to drill down into Issues tied to the Milestone(s)
- Ability to have others see the same information who may not be Developers (ie – Non-Technical Project Managers)
- Customer proposed solution: The only thing it really did was allow you to organize / label things differently than TFS did at the time. The issues / data were consistent but Urban Turtle had its own data layer separate from TFS specifically for organizing around Agile Scrum.
- Cross group Milestones - However on a bigger scale you run several groups (hardware, software, front-end, back-end, drivers, firmware, ... ) that are organized separately, but have a same goal - milestone. (#119081)
- Epics can have issues assigned from a different group (#205155 (closed))
- 1 Epic tied to 2 upcoming releases(Rls X & Y)
- 2 Features across 2 Application Domains(A&B) for Rls X. Each app has its own Gitlab instances/projects
- 1st feature for App A
- 1 story for App A in project A1
- 1 story for App A in project A2
- 2nd feature for App B
- 1 story for App B in project B1
- 1 story for App B in project B2
- 1st feature for App A
- 1 Feature in Application Domain(C) for Rls Y.
- 3rd feature for App C
- 1 story for App C in project C1
- 1 story for App C in project C2
- 3rd feature for App C
- 2 Features across 2 Application Domains(A&B) for Rls X. Each app has its own Gitlab instances/projects
Working Proposal
Ideal End State: Interacting with Objects across top level groups / sibling hierarchies
This is really rough but:
- Resources can be created within a Space. Ownership is determined by the Space in which the resource was created.
- Members can be added to Spaces. Spaces can be added to other Spaces.
- If Space 2 is a Member of Space B, resources from Space B can be assigned to Space 2 and would show up in both Space 2 and Space B.
Important considerations:
- Should a space be able to sync itself to resources from another Space? For example, Let's say Products is the desired canonical location for label management. For other Spaces that are Members of Products, could they opt into deferring label management to be derived from the Products Space?
- If we share resources across Spaces, how do we deal with configuration conflicts? Would it always be set based on the Space that owns the resource?
Edited by Gabe Weaver