Replace meta issues with a solution

assigned to @victorwu

I'm not really happy with the ideas above, but I think the current situation is a little silly. We should find a replacement.

changed milestone to %Backlog

tldr:

Link issues together as a data model. Parent-child link. Relative order link.
Create awesome UIs to solve those use cases using that data model.

@JobV :

and 2. don't really solve the problems at all. They are important, but don't really address the problem, and don't think should even be candidates.

I don't like 3., since it you are introducing even more logic inside that free text field, and making people have to remember a lot of magic GitLab syntax. We already have lists, which is magic syntax, and blurs the lines of viewing/editing when you click the checkbox in view mode. Adding more there would introduce more complexity without much inherent benefit in my opinion.

We've talked about another issue type called "feature" or "epic" before. Some systems do this. But I don't like it, because it introduces another attribute to the issues GitLab model, and is restrictive.

Quick thoughts. Need to sleep on it and solicit more discussion:

I am thinking of a variant of the JIRA model with linking issues together with relationships such as parent / child. JIRA has some clunky UI. But the concept I think is fairly flexible and light weight, and doesn't radically change GitLab.

Proposal is to simply define two relationships between any two issues, call them A, or B.

Parent-child relationship. Only four possibilities:
- A and B have no parent-child relation.
- A is the parent of B. But B is not the parent of A.
- B is the parent of A. But A is not the parent of B.
- A is the parent of B. And B is the parent of A.
Order relationship. Only three possibilities:
- A and B have no order relation.
- A comes before B.
- B comes before A.

The two relationships are totally independent. But just with these relationships, you can build powerful UIs and solve the use cases you mentioned. For example, to generate lists, you just create a meta (parent issue), and you link child issues to them (establishing those parent-child relationships). The UI can then let you reorder the issues, and in the background, the ordering relationships automatically are generated.

You might have weird edge cases where in one parent issue, two child issues are ordered in one way, and in another parent issue, the same two child issues you want ordered a different way. This data model would not support it. But I don't think that's an edge case we need to solve if we already have what I outlined above.

added ~874214 label

added ~155959 label

and 2. don't really solve the problems at all.

@victorwu Why not?

I am thinking of a variant of the JIRA model ...

@victorwu Perhaps that's your problem right there! :)

To be fair, I know that Jira has a lot of power and people want/need it, but I also know a lot of people hate it. I'd prefer to approach this from the Trello angle. Trello has been a great planning tool for many teams, and issue boards could certainly fill that role.

FWIW, I think adding parent-child relationships is interesting and valuable, but won't even remotely come close to solving this problem for us. In the last 8.17 planning meta issue, there were several levels of categorization and groups. A single parent-child relationship wouldn't be enough.

@JobV Meta issues are used for lots of different things. Can you clarify which use case you want to kill? It's silly to try to solve all use-cases with the same solution. I suggest that planning issues should be replaced by issue boards (with several required improvements). Epics could be replaced by issues with parent-child relationships. Non-code-related meta discussions could still be regular issues with a Meta label.

@markpundsack : Milestones are designed for grouping a bunch of issues to ship in a common time period, or in a single release. At least how we've been using "meta" issues is to group issues together that share common functionality. So it's less about organizing for shipping, and more for developing coherent features over potentially multiple milestones.

Yes, I know we like to hate on JIRA. And I understand it's problems with complexity and discoverability of features. But that doesn't mean we should dismiss it. In any case, I was emphasizing the parent-child model of JIRA here. Like you said, that essentially allows for epics. A minimal implementation of that will get us 60 to 70% of the way there. I think that's more than enough for now before we really feel the pain again.

The simple MVP is:

Within an issue, you can associate any number of children issues for that issue.
The children issues are displayed as a list (as links) somewhere prominently in the issue page, with meta data like issue title and issue status.
In the system, the relationships are just simple pointers. All issues are the same. No differentiation in type.

MVP+1:

You can re-order the children issues in an issue.

Some of these sound a lot like the JIRA issues macro in Confluence: https://confluence.atlassian.com/doc/jira-issues-macro-139380.html

I think the question that @victorwu asks is a good one - what's the use case you're trying to solve with this as there could be alternative solutions.

For example, if it's specifically for release/milestone planning, could you not add commenting capability to milestones? This way you could also have an on-going discussion about the milestone during development and erode some basic chat use cases from Slack/MM?

I would perhaps also adjust the UI so that the width of the milestone description during creation/editing is wider, making it feel like a better place for content.

As for making issues more powerful and the JIRA comparison, I'd be all in favour of having some parent/child epic/story type of relationship. Knocking JIRA is easy, but having used it for years in a previous life it's a very powerful tool and it makes managing larger initiatives with larger teams a great deal easier than simple solutions like Trello or even Waffle.

@awhildy : I want to push for this here: https://gitlab.com/gitlab-org/gitlab-ee/issues/1592#note_21919769. To me, it's two lightweight issues, that we can get huge bang for buck. Eliminate some major pain just to let us keep going as we ourselves scale up with more folks working on/at GitLab.

What do you think from a UX perspective? We can pull the trigger later to get some UX mockups. But just wanted to your thoughts first before we get too deep in it.

I'm all in favor of improving this process. However, it isn't immediately clear to me what the proposed MVP accomplishes. What benefit does calling it a child relationship really add onto the existing 'pointer' that we have today? I don't think the biggest challenges with the meta issue today are creating the list. It is more manipulating the list as the conversation evolves.

I'm wondering if instead of laying the groundwork for a larger system, we can do some small tactical improvements that help our flow. A lot of ideas actually currently exist that seem related to me around this.

Challenge	Potential solution
Need more information on the issues in the meta to support the discussion	Today, people often add a label, and who is assigned to it, etc. next to the issue to help categorize it. I wonder if we could solve this with Improve handling of issue/MR links in lists https://gitlab.com/gitlab-org/gitlab-ce/issues/17942 The moment you have a list of issues, we can use that opportunity to show more information about each item in the list. For example, we could easily display who is assigned to the issue. And then maybe add a way for you to hover and see the labels applied to this issue. Also related: Add messaging for closed issue references in notes https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5993
Multiple people from different teams need to be assigned to each issue. This can involve some back and forth between the meta and issue as things change, and confusion as you can only really assign one person.	I think implementing Allow multiple assignees for an issue/merge request MR (feature proposal) https://gitlab.com/gitlab-org/gitlab-ce/issues/13386 could really help us in tracking this. Combine this with the above and show who is assigned an issue when it is in a list, and now we don't have to do UX @ someone and FE @ someone any more
Reordering the list as priorities change, etc.	This could just be the prime example for issue boards, and we need to improve those. We could however consider minor improvements such as being able to drag items in the meta description to change their order on the fly
Once decisions have been made, you have to click through to all of these issues to edit labels and milestones	What if you could easily mass edit issues in a list in the meta - and do things such as add 'Stretch' or assign all of them to 8.17. Not quite sure how this would work...but would be interesting.

Basically - just wondering if we can use 'list of issues' as a simpler proxy for 'child issues', and then improve on the ways we interact with these lists.

@awhildy The solutions you proposed above is iterating on task lists, which is exactly what I don't want now, because it pushes us further down that non-native path. The whole point as Job described is to have a native solution. Task lists are not native system wise.

The use cases are much better solved technically with my proposed data model rather than what we have now. So that's the whole point. And any designs that UX comes up with would easily be solved. But the initial use cases are list creation (child association) and re-ordering.

@smcgivern Thoughts from you? I'd like to have something for 9.0 as a big marketable change here. And I expect a db change here, which would be a big deal technically at least to discuss, if not implement?

@victorwu your proposed solution requires https://gitlab.com/gitlab-org/gitlab-ce/issues/4058 (relations between issues), which I think a few of us have been pretty 'meh' on for a while. @dblessing does want it, and has started working on it in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8280, but obviously he doesn't have a lot of time to work on this stuff.

Personally I'd rather be able to do solution 1 or 2 here, and kill meta issues in general, not make them more powerful

Yes, I want issue relationships really badly! Our issue tracker is really missing this feature compared to one of our well-known competitors. Improving issue boards can go a long way toward helping with this, but people will still want meta/epic issues with some sub-tasks, I believe.

One thing to consider is that not all meta issues revolve around a given release. A meta/epic issue could revolve around a multipart issue that goes on over several releases. In this case, an issue board is not the best place.

I'm happy to help continue work on the MRs you mentioned, but after 9.0.

Thanks @smcgivern and @dblessing . Saw what Drew started on helped me think through this more clearly. @awhildy : Let me backtrack my comment regarding task lists. @smcgivern : Let me backtrack my assumption about DB changes. Fell in the classic trap of implementation before high-level use cases. I want achieve the following use cases and only the following:

Use cases

In an issue, be able to see an ordered list of other related issues, some meta data (title, status, assignee, etc.) about them, and navigate to them.
In an issue, be able to manage that list of other issues easily. Add / remove and re-order.

Problem this solves

This just helps with GitLab ourselves right now when we manage hierarchies of issues! And it is a great way to expand GitLab to be more friendly and slowly introduce obvious use cases that other products might have over-engineered / over-designed.

Design and implementation

So I guess it appears that task lists can achieve most of this already! But it needs more work so that the experience is more "native" for issues. Right now I have to write the issue number and copy the issue title, etc. Re-ordering is terrible. The experience is slow. So I am open to whatever design and implementation we choose. It appears that we could iterate on tasks lists. But any other UX design and engineering design should be considered! But what do you think?

Thanks @victorwu - as I was thinking through this, I was trying to understand the value of adding meaning to a relationship vs. the complexity cost of doing so.

From the previous things Drew had started, it looked more like a relationship of x depends on y. I can see what potential value that adds, as some issues are blocked on other issues, and communicating that will help communicate the necessary flow of work. The impact is clear -- y is blocked until you complete x. When you complete x, y is no longer blocked, and thus can be worked on. It adds some value, adds some complexity -- maybe the jury is still out as to if it is enough value.

When you say a is a child of b, it isn't immediately clear to me the value that relationship adds. It could be semantically correct. But with a being a child of b, what does that mean? If b is closed, should a be closed? If a is completed, does that impact what the status of b should be? Maybe b has a progress bar that tracks all of the statuses of it's children, but that seems little different from a milestone -- and don't really feel like it is that much value add for the complexity it adds.

Relationships will add complexity -- and I just want to make sure that the value is clear. Given this, and your thoughts in the last comment, I currently lean towards iterating on task lists. Thanks!

Thanks @awhildy. This is a separate issue to separate out the concerns. In particular, I will leave out the relationship aspect (for now), and just focus on the use cases that at least we GitLab ourselves are using, i.e. meta issues and all the organizing there. This is one of the scenarios, that just inventing a new feature to benefit our own process has a clear ROI itself. Your questions regarding relationships are totally valid. But I want to purposely not consider those right now to simplify the discussion.

https://gitlab.com/gitlab-org/gitlab-ce/issues/27462

I'll be reviewing stuff for 9.0, and likely prioritize this as one of the higher ones. Hoping that UX shouldn't be a huge concern and we would be able to get this in, especially if we end up iterating on or at least re-using task lists UI as a solution?

Thanks @victorwu! Makes sense. I think the UX should be totally solvable.

Closing since we have:

Related issues: https://gitlab.com/gitlab-org/gitlab-ee/issues/2001 Subissues: https://gitlab.com/gitlab-org/gitlab-ee/issues/2036

closed

Replace meta issues with a solution

Description

Proposals

1: Wait for issue boards based on milestones

2: Expand milestones

3: New thing: Dynamic issue tables

Links / references

Designs

Child items ...

Activity

Use cases

Problem this solves

Design and implementation

Admin message

Admin message

Replace meta issues with a solution

Description

Proposals

1: Wait for issue boards based on milestones

2: Expand milestones

3: New thing: Dynamic issue tables

Links / references

Activity

Use cases

Problem this solves

Design and implementation