## Background In https://gitlab.com/gitlab-org/ux-research/-/issues/2261 we found that users expect that when lower level items, like tasks, have a weight that that weight is expected to be represented in the parent — users do not expect to see a mismatch between parents and children. We currently show weight in many different places including: * Lists * Boards * Child items (hierarchy) * Iterations * Milestones While we didn't look at each context in our research, it was clear from the research that users expect this to be consistent — "I just need to understand it" was a common theme, and diverging logic based on context will make it harder to understand. ## Proposal ### Rollup logic To align with user expectations we should use **rollup weight** whenever weight is displayed outside of the item detail. Rollup weight is the total lowest-level weight. If an item has no children, or no children as estimated, that item's weight is the lowest level weight. Whether the total weight is more or less than the item weight does not change the behavior, an issue weight 4 with total child weight 8 has a rollup weight of 8; if the issue weight was 12 the rollup would remain 8. <table> <tr> <th> </th> <th>Issue only</th> <th>Task only</th> <th>Issue and task</th> <th>Neither</th> </tr> <tr> <td> **Weight set on items** </td> <td> Issue: 5 Task: null Task: null </td> <td> Issue: null Task: 2 Task: 3 </td> <td> Issue: 3 Task: 2 Task: 3 </td> <td> Issue: null Task: null Task: null </td> </tr> <tr> <td> **Rollup value** </td> <td> Epic: 5 * Issue: 5 * Task: null * Task: null </td> <td> Epic: 5 * Issue: 5 * Task: 2 * Task: 3 </td> <td> Epic: 5 * Issue: 5 * Task: 2 * Task: 3 </td> <td> Epic: 0 * Issue: null * Task: null * Task: null </td> </tr> </table> ### Representation in the UI While some users expected that the rollup would replace the parent value, in most cases users expected both would still exist. Retaining the value set on the item and instead highlighting when this is superceded by the total value means we do not need to introduce more complex logic for managing rollups. | Detail | Child items | |--------|-------------| |  |  | Since we're showing rollups, even **epics which do not have a weight field should now show a "weight" attribute in child items** representing the rollup value (the same value shown at the top of Child items) For issues, the rollup weight should be what's shown in all cases including the **issue list and issue board**. ### Iterations/milestones Because items can be split across timeboxes, weight in timeboxes should be the rollup of items _in that timebox._ <table> <tr> <th>Iteration 1</th> <th>Iteration 2</th> <th>Iteration 3</th> </tr> <tr> <td> Issue A: 5 * Task B: 2 * Task C: 3 </td> <td> Issue A: 2 * Task B: 2 Issue D: 1 * Task E: 1 </td> <td> Issue D: 1 * Task F: 1 </td> </tr> </table> In this example issue A was assigned to Iteration 1, and Task C completed in that iteration. Issue A and Task B then roll over to Iteration 2, where now the weight reflects only Task B (the work remaining). Issue D has tasks E and F which were split into two iterations from the start. In each iteration the tasks define the weight contributed for the issue.