Provide first class support for Issue Task Lists and Tasks [10]

This issue has been closed due to the problem being addressed in &7103

Problem to solve

1. When cross-functional areas collaborate on a single issue, they each add weights and manually update the single Issue Weight field, so there is no clarity around which functional areas has how much weight per issue, making capacity planning difficult and inaccurate.
2. There is currently no way, other than manually creating issues and relating them, to manage cross-functional requirements and tasks on a single issues.

Adding tasks or a similar solution to Issues is a precursor for solving these follow on problems:

1. If a single issue has multiple contributors responsible for implementation, its impossible to get an understanding of where an issue is and who it's waiting on without opening the issue and digging through the comments. This makes it hard for both the Engineering Manager and assigned Engineer to quickly understand where they need to focus their efforts when they down in the morning to work.

Job Stories:

When I'm trying to understand my team's capacity vs. allocation, I want to see an accurate total allocated weight/count per engineer, so that I can make sure they aren't over or under allocated.

When managing my assigned work, I want to easily see what I'm responsible for on each issue, so that i can prioritize my time most effectively and perform ongoing triage efficiently as I context switch between Issues.

When planning an issue, we need a way for each functional part of the team to contribute to the overall issue weight while maintaining the individual weight parts, so that we account for the total work that needs to be done and have an accurate representation of the total complexity of a given issue.

When planning an issue, we need a way to quickly capture and break down technical requirements / steps necessary to complete a given issue, so that we derisk the issue and provide a more accurate issue weight in light of a given issue's completion criteria.

See more context around these on this comment: #2036 (comment 207022369)

Intended users

• Parker (Product Manager)
• Delaney (Development Team Lead)
• Sasha (Software Developer)
• Presley (Product Designer)
• Devon (DevOps Engineer)
• Sidney (Systems Administrator)
• Sam (Security Analyst)
• Dana (Data Analyst)

Further details

• Introducing Issue level tasks decreases issue management load, increasing efficiency. It also enables a team to collaborate more effectively on a single issue, is more inclusive to our wider community (or that of our customers) as it provides a more universal "single source of truth", and increases transparency as it is easy to track work in flight.
• Issue level tasks also pave the way for introducing more customizable workflows on the individual user level (a.k.a. fixing ToDos, notifications, etc.) -- a key goal for groupproject management over the next year.
• This will also provide the ability to create more accurate capacity and allocation features in the near future.
• Lastly, this will provide teams with the ability to more granularly articulate implementation responsibility, which if done well, will build greater trust among the broader team and stakeholders.

RICE

Item	Value	Narrative
Reach	10.0	Anyone who uses Issues would find this valuable. Feature usage indicates 139m Issues in the month of July
Impact	3.0	The above points and the entirety of this issue largely speak to this. A solution is also highly requested.
Confidence	100%	This paint point is widely felt internally and externally. We've received support requests for this, and it is a widely adopted feature in some form or fashion in nearly every competing product.
Effort	3	PM, FE, BE, Designer @ .75 months = 3
------	------	------
Score	10	10 x 3 x 1 / 3

Proposal

Add first class support for Task Lists and Tasks on Issues.

Tasks would have the following attributes:

• Short description (required)
• Time Estimate
• Assignee
• Due Date
• Label(s)

GitLab Starter:

• Weight

Behavior:

• Tasks can be re-ordered within their task list.
• If a task list exists and there are 1 or more assignees across multiple tasks, then the assignees on the Issue are automatically set based on the tasks. If a task is completed and it is the only task assigned to a given user, that user is automatically removed as an assignee on the issue.
• If a task list exists and there are 1 or more tasks with a weight assigned to them, the issue weight is automatically set by the sum of all of the task weights.
• When viewing lists by Assignee on the issue board, the sum weight for the list only takes into account the weight assigned to the Assignee.
• Any add/edit/delete change to Issue Tasks are stored as a system note

Permissions and Security

• They should be in line with current Issue permissions.

Documentation

• Documentation changes will be required, most likely to this area: https://docs.gitlab.com/ee/user/project/issues/#parts-of-an-issue

Testing

• Issues currently contain markdown task lists nested within an Issue Description. We will need to reconcile the behavior given we don't want "duplicate" task list features on an Issue.

What does success look like, and how can we measure that?

Success Metrics

• Count of tasks created over a given period.
• Count of tasks completed over a given period.
• Positive qualitative feedback from the wider community.

Completion Criteria

• An issue can have multiple task lists, each with tasks.
• Tasks can have the attributes outlined in the proposal.
• The behavior of tasks is generally in line with the proposal.
• Telemetry is implemented such that the quantitative test metrics can be measured.
• Documentation is updated.
• The data is implemented via GraphQL.
• The interface is implemented via GitLab-UI.

What is the type of buyer?

• As tasks in some form are already available to the wider community and considering our stewardship values (https://about.gitlab.com/company/stewardship/), this would be considered generally available except for those parts of task or task lists that are already associated to paid tiers such as Issue Weight be associated to the GitLab Starter tier.
• As of now, there is a high degree of certainty that follow on features built on top of data that tasks provide will be part of paid tiers. Examples include better capacity and allocation information, enhanced burndown charts, etc. Those features will be tracked in separate issues.

Links / references

Original proposal based on sub-issues:

- Subissues, similar to related issues #2001 (closed). - A given issue can have any number of children subissues. - A given issue can have at most one parent issue. - A given issue can have at most one parent epic. - Besides indicating the tree structure in an issue below the description (see mockup), there is automatic closing functionality: - When all the immediate children of a given issue is closed, the given issue is automatically closed. - So a cascading up event can happen.

*This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*