Work item discussions: Add remaining actions

@gweaver Do you know why we skipped our process here? If we had assigned a designer during workflowdesign, we would have been able to review the impacts of these UI changes and realize that the drawer in the report abuse flow would break the modal layout design.

cc @nickleonard @donaldcook

@jackib Hrm...I'm not sure 🤔 If I were to hypothesize, I think we all missed thinking more deeply through the implications of the comment controls while working through the design phase of this epic (#378955 (closed)). Lesson learned.

From a process standpoint, this issue wasn't linked to the parent epic when it was split from #389968 (closed), so it wasn't on my radar. @donaldcook, do you have any ideas for ensuring we surface things like this (design constraints and so on) before getting along in the build track?

From a macro interaction model standpoint, this is a similar problem we are facing when in a modal/drawer and action menu items require more user input to complete the action when clicked (ex: clone, move, delete, ...). I wonder if there is an opportunity to have a consistent pattern to follow in these cases.

All three tasks here had questions for Nick L. Can we move this back to workflowdesign?

From a process standpoint, this issue wasn't linked to the parent epic when it was split from #389968 (closed), so it wasn't on my radar. @donaldcook, do you have any ideas for ensuring we surface things like this (design constraints and so on) before getting along in the build track?

@gweaver @nickleonard @jackib That's on me. The iteration plan was in #389968 (closed) and we wanted to focus that one on the first iteration so I created a related issue and used /copy_metadata, not realizing that the epic wasn't attached as part of it.

All three tasks here had questions for Nick L. Can we move this back to workflowdesign?

That's fine. @deepika.guliani please pause any MR that hasn't gone through UX review already, and we'll revisit this after UX has gotten more of a chance to review.

Let's continue discussing the root cause of the process breakdown in our retro (I'll start a thread later today).

@donaldcook Thank you! Looking forward to the retro thread as I'm still getting to know how the team works and curious how we decide which issues need to go through the workflowdesign and workflowsolution validation steps.

@jackib In talking through the MRs for this a bit more with @deepika.guliani, it looks like 2/3 of the tasks have been through UX review (#391995 (closed) is on production already). Are you okay with us spinning off a new issue to work on the Report Abuse workflow within work item modals?

@donaldcook Sure thing!

@gweaver @nickleonard This has me thinking about workflows. In this case we have an issue with three tasks. When we moved the issue back to a previous workflow state, the tasks didn't move with it, which doesn't seem ideal. Now, we're creating a new issue out of one task that was incomplete. This is pretty messy and error prone, as well as making tracking back to original issue/epic really challenging. Should tasks even be workflow items, or should they be more like checklists within an issue?

Should tasks even be workflow items, or should they be more like checklists within an issue?

@jackib I think it's fine for them to be workflow items, but the issue they belong to should have the necessary designs to implement all of the tasks. Tasks will be more valuable as a workflow item once they are integrated into Boards -- which we'll be able to start thinking about once we enable iterations and milestones FF for tasks. As far as how workflow states should behave with parent/children work items, I think we can explore this a bit more as part of finalizing the solution for #368290 (closed).

@gweaver

the issue they belong to should have the necessary designs to implement all of the tasks

That makes sense for our process. For customers, I think they'll be confused about when to use an issue, when to use a task, and when to use a checklist.

@jackib We haven't gotten any feedback around "confusion" thus far, and we're seeing strong adoption of tasks. We need to make many improvements to tasks, but generally, folks using checklist items are now transitioning to using Tasks as they support more first-class planning use cases (assignees, weight, ...) in line with the JTBD I outlined here -- &9972 (comment 1309746724).

When we moved the issue back to a previous workflow state, the tasks didn't move with it, which doesn't seem ideal.

@jackib One of the values of tasks is that it gives users the ability to track each step separately with more richness than checklists provide. Borrowing an example from a customer, you might have a task for BE, a task for FE, and a task for QA. When the task for QA is in process, you might want the issue to be "workflow::in QA", but you would want the FE task to remain "workflow::complete". Similarly if QA found issues and workflow went back to In Dev, you wouldn't want your completed tasks to show up as "In dev" when they aren't being worked on. The original FE and BE task are likely still complete, and you may have a new task to solve the QA finding which will have to flow through its own workflow.

That's one example, and there are certainly others where you would want sync, but by not syncing we avoid making changes users didn't intend. This could be something that workflow automation enables users to do on their terms, e.g. <trigger: issue + label added> <action: issue child items > add label>.

Borrowing an example from a customer, you might have a task for BE, a task for FE, and a task for QA.

@nickleonard @gweaver We've been using issues this way, where issues represent the different team tasks. Epics don't go through workflows in this case, they stay open while there are open issues.

Do you see issues becoming less relevant for workflows? Or customer managing issue workflow differently from task workflow?

@jackib I've talked to 10 (non-gitlab) users in research interviews over the last two weeks and one of the specific questions I ask it to walk me through their work breakdown processes.

In nearly every case, the user explained the same model for how their teams work (green highlight is the GitLab equivalent record for their terminology):

Initiative (one) => Parent Epic
- Feature(s) (one or many) => Child Epic(s)
  - Story(s) (typically many) => Grandchild Issues
    - Task(s) (typically many) => Great-grandchild Tasks

Where:

An Initiative typically aligns with larger objectives and has well defined value to customers or the business.
Features are vertical slices of the initiative which deliver value independently.
Stories/issues are work product that together achieve the vertical slice outlined in the feature.
Tasks are the checklist of things the owner of the issue needs to accomplish to ship that user story.

All of this to say, I'm hearing that there is distinct value provided by issues and tasks with different jobs to be done.

@nickleonard @nickbrandt Can you make sure you reflect on this thread and incorporate your perspectives on the desired experience (the how, not the what)? You don't have to reply in this thread, it can become part of the work items KR.

Specifically:

How do users want to interact with planning objects during different planning workflows (planning, performing, protecting)?
How do the types of planning objects relate to workflows and related planning tools like roadmaps, lists and boards? The example that led to this thread is about task workflow states vs issue workflow states and how they can get out of sync.

@amandarueda Was there anything in your interviews that could shed some light on these questions for the product designers?

@jackib I definitely have some context on these questions from the interviews. I'll share the readout and such when complete!

@jackib @amandarueda This is consistent with the feedback in the recent hierarchies research study. It's also what our data shows https://app.periscopedata.com/app/gitlab/775807/Plan-xMAU-(monthly)?widget=15054404&udv=0 .

It's also what our data shows

@mushakov I'm not sure I understand yet what that dashboard shows. Does "Epic depth" mean the number of child epics, or does it also include child issues and tasks?

@mvanremmerden This chart is for epics only, and it shows the level at which an epic is nested (only as relative to other epics). Please keep in mind that only Ultimate has multi-level epics, so the fairest comparison would be to filter to that level only.

@mushakov That's already helpful. Is there any reason why 0 was filtered out as depth?

@mvanremmerden The usage ping counter returns the count per depth. 0 means that there were no epics in the instance, so I filtered it out to remove noise.

@mushakov I'm probably still just confused, so I'm going to summarize what the different bars mean to me, and you can tell me if I'm right or if I'm misinterpreting, that might be easier than asking more questions:

0: Instances with no epics
1: The number of epics with 1 child epic
2: The number of epics with 2 child epics
3: The number of epics with 3 child epics
4: The number of epics with 4 child epics
5: The number of epics with 5 child epics

Is that overview correct?

@mvanremmerden This counter parses through all the epics and returns a single number for the instance. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_all/20210216181212_epics_deepest_relationship_level.yml .

cc: @kushalpandya to confirm that my understanding is correct 🙈

@mushakov Ah, so to update my summary, it would actually be this:

0: Instances with no epics
1: Instances where the epic with the most child epics contains 1 child epic
2: Instances where the epic with the most child epics contains 2 child epics
3: Instances where the epic with the most child epics contains 3 child epics
4: Instances where the epic with the most child epics contains 4 child epics
5: Instances where the epic with the most child epics contains 5 child epics

Yes that's correct @mvanremmerden

@mushakov Does that then also mean that there is no way for us right now to get the following data:

Instances where the epic with the most child epics contains 0 child epics

@mvanremmerden There's not a great way to derive this using this identifier alone. It would be possible if we intersected this data with the instances where the count of epics >0. I don't think my SQLfoo is strong enough to do that quickly though 😬