[Discussion] Convert Plan Objects to Issue Types
Context
As I understand the history of things within GitLab, we created Epics under the premise that the business rule was that Epics would always live at the Group level and Issues would always live at the Project level. There would never be Issues at the Group level and Epics at the Project level. Given this, we created a separate object in Groups that behave much like an issue with the only major difference being that Epics can be nested.
Problem
As we've iterated on Epics and Issues, we've gotten lots of feedback:
- It's confusing that Epics are at the Group level and not Issues.
- It's confusing that Epics are not at the Project level.
- For many organizations, they want to do all of their planning at the Group level.
- There is a desire for better support for first-class support for customizable issue types
- There is a desire for better support for making each level of Epic a specific type. In both these cases, a type refers to the kind of work that needs to be performed or a label to represent the collection of certain kind of child kinds of work items. The kind of work also dictates different kinds of data that needs to be available on the given type of issue. This is the whole premise behind why we added a type column to Issues and used issue types for Incidents and Test Cases.
If we continue down our current iteration path, it will look something along the lines of:
- Add support for customizable issue types.
- Spend a decent amount of time building Epic Boards.
- Add support for Issue templates at the Group level.
- Add support for Epic templates at the Group level.
- Add assignees to Epics.
- Add support for Epic types.
- Allow epics to relate to or block other epics
- Add Issues to the Group level.
- Add Epics to the Project level.
- Add saved filters for roadmaps.
- Add saved filters for boards.
- Add saved filters for lists.
- Add better bulk edit support for epics.
- Make requirements nestable inside of other requirements.
- Make Test Cases nestable inside of Test Sessions.
- Add all the things to Requirements that already exist on an Issue.
- Add custom fields.
- Add the ability to map certain custom fields to certain types of issues.
- Add the ability to map certain custom fields to certain types of Epics.
- Add the ability to map certain custom fields to certain levels of Requirements.
- Fix Epics not showing up on a user's activity on their profile.
- Extract fields from Issues and convert them to Widgets.
- Extract fields from Epics and convert them to Widgets.
- Build Issue subtasks since issues can't have sub-issues.
- Add the ability to view issues on Roadmaps.
Where we end a year from now is basically:
- There is no real difference between an Epic and Issue other than the fact that Epics can be nested.
- You still have to navigate to a different lists / areas of the product to interact with Issues or Epics.
Proposal for an alternative path...
- Let's assume that we move forward with merging Groups and Projects. (Working proposal to iterate towards this outcome: https://gitlab.com/gitlab-org/architecture/tasks/-/issues/7). Groups now have Issues and Epics. Projects now have Issues and Epics.
- Let's assume we've completed adding support for customizable issue types.
- Convert Epics into types of Issues. A common pattern requested by customers is
Epic
>Capability
>Feature
>User Story
, but making it configurable would allow the customer to name the types of issues according to the nomenclature their organization uses. - Convert Requirements into a type of Issue.
- Add the ability for the end user to define the relationship between types of issues. Fibery.io is an up and coming competitor that solves for this nicely [1]
- Extract fields out of Issues / Epics and turn them into widgets. This is also the basis for custom fields. A custom field is just a new widget.
- Add the ability to create Issue templates at the Group level.
- Add the ability to map templates to types.
- Add support for customizable issue status where each type can have one or more of the configured statuses.
- Add the ability to create more complex templates composed of several types of issues.
- No need to recreate a separate kind of Board. Boards (lists) are generalized to just be a way to view a given set of issue data. A board can be scoped to one or more types of issues. The issue relationships determine what kind of swimlanes you can. This basically behaves like a smart pivot table.
- Add a generic saved filters solution that works across all ways to view issues.
- The roadmap becomes a generic way to view issues / relationships across a timeline.
- Introduce a calendar view that is a generic way to view issues on a calendar.
Benefits
- More extensible with less duplication of effort.
- Meets customers needs -- especially medium to larger enterprises that need this level of customization in order to adopt GitLab Plan.
- Easier to reason about.
- Easier to build and maintain. No more epic finders scattered everywhere.
- A more logical separation of concerns.
- A more composable set of small primitives that can be used to solve far more use cases than we can consider or build custom one-off objects to solve.
Competitors that are doing this well and growing rapidly as a result:
- Notion.so
- Fibery.io
- Airtable
Example of using the core primitives to build a "Product Management" experience
Edited by Gabe Weaver