To get rolled-up metadata for a work item, there are two strategies to consider:
cache these metadata for each parent in hierarchy - this approach was used for cache epic cache counts/weights. Pros is that then it's very cheap to get these rolled-up values for each item, cons is that it may be tricky to assure data consistency. For epics this there were many edge cases which had to be addressed (#378907 (closed))
implement mechanism similar to namespace traversal_ids for work items hierarchy (so for each item we would cache all its parents). This should allow us to get rolled-up data in a performant way on the fly in most situations (though not all of them). Pros: it would be easier to assure data consistency. Cons: Although it should be possible to get aggregated data for set of items, it would be still expensive to get aggregated data separately for multiple items (IOW for each subepic, we want to show rolled-up data) - in that case we would have N+1 query problem as we would need to query each of subepic separately.
@mcelicalderonG Hey Have you started working on the backend for this ? What are you thinking in terms of the work item schema ? I was thinking of starting an implementation with mocks
Are we thinking on the same terms as epic query childItems response with keys being similar to descendantCounts , healthStatus and descendantWeightSum ?
Also this information will only be available in HEIRARCHY widget right now, LinkedItems will have a separate issue , right ?
@deepika.guliani@mcelicalderonG While we can keep the structure of response similar to existing API, I feel we shouldn't include any info on the type name itself, as these counts do not require to be coupled with the actual Work Item Type, i.e. we don't have to say it is "Epics" count, instead, we can use workItemType IDs and show counts against it and then let frontend decide what type is identified by on UI, this will allow Hierarchy Widget (and Linked Items Widget) be context-free where it can morph the UI to bifurcate type names based on whether it is showing OKRs or Epics, or any future type where these widgets are present.
@deepika.guliani I haven't started looking into this yet, but I agree with @kushalpandya in that we should not fetch count by types. For the first iteration we might not even need weight rollup to be separated by state (openend/closed)? We can start with the basics and if necessary we can add new fields to group this information
@mcelicalderonG@deepika.guliani@kushalpandya I wonder if this is something that should be in the relationship widget, or if we should "hook" into the other widgets to get that data. With weight for example, we're going to show this data in the weight widget, but we should only show the weight rollup in the relationship widget if the work item type has the weight widget. Does that make sense?
@deepika.guliani@mcelicalderonG I added an agenda item to the 2023-10-26 epic migration working group meeting to talk through this and how we want to communicate between widgets. I'll jot down my thoughts there and we can update this with any action items that come from it.
@donaldcook after our original discussion I was thinking that maybe this information does belong in the appropriate widget and we should not add dependencies between widgets. So at least for now, I think this can be resolved with something like this @deepika.guliani
UPDATE: In fields like childrenCountByStatus we could add something to the docs like "this field will be null if the work item type doesn't have a hierarchy widget". The same on the weight widget. After writing this I realize how my proposal still creates dependencies between widgets so we should definitively discuss in the next call
An alternative could be to have separate widgets for these @donaldcook. Something like weightHierarchyRollUpWidget. And one thing we can do in the backend is add validations to work item types, so in the future with custom work item types we could let users know that you cannot add this widget without also adding the weight and hierarchy widgets
@mcelicalderonG How do we determine what are the number of Issues and Epics in childrenCount( and the same which are open/close) in the above response structure ?
Like for example there are 2 epics and 1 Issue when the childrenCount is 3. Same would be the case for childrenCountByStatus ? I think We would need something like directChildren children for child epics and children for issues.
How do we determine what are the number of Issues and Epics in childrenCount( and the same which are open/close) in the above response structure ?
@deepika.guliani I thought from the current designs we don't need to have a children count by state (open/closed) nor counts grouped by type. Did that change? #424517 (comment 1607866294)
AFAIK we should be able to create any level of epics with work items structure as well like with legacy epics , right ?
@mcelicalderonG one thing I am wondering from a design/architecture perspective how do we implement this so that we can extend the roll-up to other widgets if/when we need it.
IMHO having the inherited/roll-up details on the widget itself makes most sense The calculation would have to rely on the hierarchy widget, but storing/caching the rollup/inherited values should be on the widget itself, WDYT ?
So then if we need to implement this on any other widget we'd basically extend the widget with the given set of columns and computation functionality vs having to add extra fields to the hierarchy widget itself?
Yes @acroitor, that's a good idea. I think that even children count could be a special case of the roll-up logic, so we could already implement both weight and children count using the same mechanism I think. I had a chat with @amandarueda recently and we are still waiting on more information about how we want this to behave before it can be implemented
IMHO having the inherited/roll-up details on the widget itself makes most sense The calculation would have to rely on the hierarchy widget, but storing/caching the rollup/inherited values should be on the widget itself, WDYT ? So then if we need to implement this on any other widget we'd basically extend the widget with the given set of columns and computation functionality vs having to add extra fields to the hierarchy widget itself?
Not sure I fully understand this part, @acroitor. The two alternatives we have discussed about the location of roll-up data in the widget interface is in the widget itself (weight for example) or creating a new widget that by definition relies on the hierarchy widget (maybe something like roll-up weight). THis way we can validate on creation that this widget cannot be added unless you add the hierarchy widget too. The down side of the alternative (having the roll-up data on the weight widget itself) is that we would need to return null or something like that in the roll-up field of the weight widget if it doesn't have the hierarchy widget?
but storing/caching the rollup/inherited values should be on the widget itself, WDYT ?
Yes, I think that how/when we calculate this data will need to happen in the background and whenever the hierarchy is updated via the hierarchy widget, and there's a lot we can do there like checking the widgets a given work item type has before actually updating/caching these values.
Let's use this issue for both the FE and BE. @nickleonard@nickbrandt do you mind reviewing the designs from #424516 (closed) and adding them here if they're good to go?
@deepika.guliani We need to do some work to get the hierarchy widget generic enough to work with work item types other than objectives (starting with #383544 (closed)). I don't think it makes too much sense to start on the frontend of this until we can show the widget in epics or other types. I'm going to unassign this from you for now and we'll pick it back up later.
@mcelicalderonG as discussed, the logic on the backend is generic enough, so we can continue working there. If you have any questions about API expectations continue reaching out to @deepika.guliani.
@deepika.guliani I marked this as blocked by #423981 (closed), but ideally some work can be done in parallel, and we'll just need to hold on merging until that issue is resolved.
@donaldcook Sure ! But like you mentioned in this comment , but I am not sure if I can start the mocking apollo client work till we have decided where are we going to get the rollup numbers ? A separate rollup widget or have we decided to get the same in the hierarchy widget ?
@amandarueda@donaldcook from #424517 (closed) I think it's clear how we want to calculate weight rollups, but for the hierarchy widget that actually fetches children and children count should we follow the same rules? Keep in mind that we already have hierarchy restrictions implemented, so for example only issues an epics can be children of epics. I just want to make sure we are not talking about some additional here. I mean, I should always fetch all children and count all children as long as they are allowed to be created as children via the hierarchy restriction setting. Or should for example an epic child count exclude the tasks that might be associated to one of it's child issues?
@mcelicalderonG A task cannot be a direct child of a epic, as documented here. Further, we will not display tasks in the epic hierarchy widget, as documented here.
Because of this, we do not want to rollup the weight of tasks into the total weight which is displayed on the epic hierarchy widget (example below). Please lmk if that clarifies things!
Further, we will not display tasks in the epic hierarchy widget, as documented here.
@mcelicalderonG@amandarueda Apologies, I missed this description update. Is there any flexibility in the requirement to not show issue children (tasks) from the hierarchy widget in epics? I don't think we've determined a technical solution to hide certain WI types, but I do think it offers a decent amount more complexity, and should bump this up beyond a 3. Mario, please correct me if you think otherwise.
@gweaver Just a heads up that with the hiding conditional logic, this work may go well into %16.7 and we may need to trade off some other (primarily backend) work to account for this.
Is there any flexibility in the requirement to not show issue children (tasks) from the hierarchy widget in epics?
@donaldcook Viewing tasks on the epic hierarchy widget may be desirable for engineering personas due to the nature of the JTBD while viewing the information, however for the product manager persona, these additional layers can create noise in an already "crowded" display of information. I wouldn't feel comfortable displaying the task at this level without validation with users.
@amandarueda they aren't displayed by default, though. You have to intentionally unfurl the item to see its children. If it's easier to not hide the tasks AND this is a two-way door decision from which we can iterate, I tend to lean toward the path of least resistance.
@gweaver yep, I was just thinking this through and landed on that point as well.
Here's what I'm currently thinking:
Displaying Tasks Pro
I have confidence that the engineering personas would want this information shown.
I now know that the majority user of epics are developers, not PMs. So the impact to non-devs is lower than I once thought.
For users who don't want to see tasks, they are collapsed by default so they won't take up real estate unless they intentionally display them.
Displaying them is the least technically complex option.
Displaying Tasks Risk
I do not know if the PM persona wants to see tasks.
I've received feedback (albeit from a handful of internal PMs) that when the epic hierarchy is heavily nested it becomes difficult to find what you're looking for.
Total summarized weight on the widget could be difficult to understand given the lack of relationship between the issue and task weight.
@nickbrandt I'd love your insights. Given the majority user is developer and the fact that they will be collapsed, I'm leaning towards allowing displaying of tasks since the technical cost of hiding them is large and the risk is low. WDYT?
My only remaining concern is how rollup weight on the epic hierarchy widget will be handled. Since there is no relationship between task and issue weight on the issue, and we do not give users an understanding of how the weights are handled there, I do not want to introduce further confusion by including task weight on the epic widget until we've determined the ideal path forward.
I'm good with that. Are we good, for the first iteration and to not block the epic migration work, with just not showing any counts within the hierarchy widget? Or should we just hold off on weight? What about health status?
Are we good, for the first iteration and to not block the epic migration work, with just not showing any counts within the hierarchy widget? Or should we just hold off on weight? What about health status?
@donaldcook we can't put customers on work item epics until the rollup is there, but I'm happy to move forward by shipping the other rollups (counts and health) + an empty (FE) weight widget until the logic is agreed upon. Is that doable?
an empty (FE) weight widget until the logic is agreed upon.
Although now that I write that, I can see that would be a problem for tasks in production, right? In this case, we can just ship the counts and the health status until weight logic is complete.
Thank you everyone for discussing this. So just to confirm @amandarueda, for now I can focus on the hierarchy count without any filters on the types, correct? So the child count will always count ALL the children down the hierarchy
@nickbrandt we'll need a task icon for counts on the epic hierarchy widget, is this available somewhere else? Unless you'd like to genericize the count to all children?
we'll need a task icon for counts on the epic hierarchy widget, is this available somewhere else?
@amandarueda that would just be the same task icon we use in the listings and header.
Unless you'd like to genericize the count to all children?
I do think this is getting to be a bit much for the widget header, especially when all the things are present (types, weight, health status) and at smaller screen sizes. I put together a few comps showing what it would be like to include Tasks in the widget.
We could move to just a combined count, like seen here. If we wanted to maintain the ability to see a breakdown, we could include that in a popover – though discoverability wouldn't be great. I don't have a great understanding of how valuable that is to users today, vs just caring more about things like the total weight.
I do think this is getting to be a bit much for the widget header, especially when all the things are present (types, weight, health status) and at smaller screen sizes.
@nickbrandt interestingly, @nickleonard isn't providing a count of subepics or tasks in his mockups here, just issues, even though in two of the cases (top-down, max value) the task weight is included. @nickleonard was this intentional? Do you think we do not need a count of tasks if tasks are displayed?
I do think this is getting to be a bit much for the widget header, especially when all the things are present (types, weight, health status) and at smaller screen sizes. I put together a few comps showing what it would be like to include Tasks in the widget.
We could move to just a combined count, like seen here. If we wanted to maintain the ability to see a breakdown, we could include that in a popover – though discoverability wouldn't be great. I don't have a great understanding of how valuable that is to users today, vs just caring more about things like the total weight.
@nickbrandt I agree that showing counts for each of the types of children is getting a bit much, it's even tough to read (thank you for the visual!). I'm leaning towards simplification, but want to hear what Nick L's thoughts were when he created the linked mockup for the research project.
was this intentional? Do you think we do not need a count of tasks if tasks are displayed?
@amandarueda Without knowing exactly where this would land, I wanted to keep this simple as just-issues to reflect what we have today (ignoring subepics as we aren't using them in this test), which also reflects the items that are a hierarchy level below epics (in this example, all are directly children of the epic, though in practice they could also be children of subepics but still at the same level in terms of type hierarchy e.g. epic>issue>task).
While not the primary focus of this particular validation effort, I expect we'll hear users identify the counts as we ask them to describe the work, and potentially relate the counts to the weights and identify any mental model disconnects.
Since there's a proposed direction here that is a bit different I'd rather test on that, so we can get closer to what we think might be shown; we're testing the concept so it's fine that it's not totally final design. @nbrandt I'm planning on just pulling in the aggregated badge design we reviewed earlier, but let me know if you'd prefer using something else for the tests.
Note: we're also stripping out other data in these test artifacts since our focus isn't on the design itself but the data, this isn't a design suggestion just a means of managing test focus.
@nickbrandt@nickleonard@amandarueda My $.02, I don't think people care about count by type. I've heard from multiple folks, including the customer I'm visiting with today, that what they care about most is a dead-simple way to understand the overall progress of the epic, similar to the x% we show for each epic on the roadmap.
Thanks @gweaver, I heard similar from our large financial customer today as well. That said, I'd hate to introduce inconsistency and display counts for one thing and not another. Chatting with Nick today, I think this is nicely solved by a general count of all children with detail on the hover. I also really like the # complete / # available and weight complete / total weight pattern, this gives a decent sense (though not totally comprehensive) of progress.
@egrieff&10514 is slightly different. That's a new feature which would create an actual Health Status widget on the epic record which could be manually set at the epic, or inherit its value from its child records (like dates). That work will be something we schedule post migration.
@amandarueda@egrieff there was some discussion around making this only about the hierarchy widget in favor of separate tasks issues for the other 2 (weight, health status rollups) in #424517 (comment 1610877921)
The title was updates, but not sure if the other two issues were created, @donaldcook. I don't see them on the epic this issue belongs to
The title was updates, but not sure if the other two issues were created, @donaldcook. I don't see them on the epic this issue belongs to
@mcelicalderonG@amandarueda@egrieff No they were not. I said I would create them but forgot to through the conversation of whether or not we're including specific work item types. I added a couple tasks for counts and health status just now.
Did we determine how we are going to get roll-ups? Better question: where are we getting rollup numbers? I recall deciding on a separate "rollup" widget. If that's the case, we should probably create another issue/task to implement that.
I guess we never discussed it in the sync meeting, @donaldcook. I think it's safe to assume that children count can be added to the existing hierarchy widget, but we probably still need to discuss if it makes sense to have dependent widgets as described in #424517 (comment 1615530354) for the other 2 (weight and health status rollups). I'll start a new thread here for that one so we can discuss on the sync meeting
@mcelicalderonG@donaldcook Sure , since I have to mock the data for the UI to complete the task, I will use the structure mentioned in this comment for now and we can change that in any changes occur after the discussion
@mcelicalderonG Hey We also need to consider the permissions of allow_sub_epics and show_health_status to show the rollup data in work item epics as shown in the screen
I think we can take this into consideration like we do currently from injected template properties. Just FYI.
@deepika.guliani Are those permissions already available within the hierarchy widget? Let's think through what the equivalent would be within the work items framework. @gweaver@amandarueda Have we defined the tier strategy for hierarchy? Will sub-epics still be an ultimate only feature?
@deepika.guliani@donaldcook For show_health_status we could filter out the entire widget if not available for the license of the parent. We do the same for fetching health status data on workItem.widgets. We would need to do the same in the new interface for create new work item
For allow_sub_epics we should definitively find an equivalent that is not tied to the type as @gweaver said, but from the linked thread I think we will need to tie licensing to the type at least as the first MVC.
Also, where would you need this information, @deepika.guliani? When creating a new epic that would be a child of a specified parent? If creating an epic at the root level of the group, I guess you don't need this check? I could add a temporary field while we transition into not doing this license check at the type level
For show_health_status we could filter out the entire widget if not available for the license of the parent. We do the same for fetching health status data on workItem.widgets
Awesome Then in the current implementation if the parent does not have a license we will not be able to get the WorkItemHealthStatusWidget and hence no rollup health status. the frontend does not need to put any additional checks in this case
If creating an epic at the root level of the group, I guess you don't need this check?
At the new work item create epic view , we do not have the capability to create a sub-epic. But when we can fetch this permission in the hierarchy widget only for epics , WDYT ?
At the new work item create epic view , we do not have the capability to create a sub-epic. But when we can fetch this permission in the hierarchy widget only for epics , WDYT ?
Yes, I think this would be appropriate in the hierarchy widget. What would be the generic way to call this field that is not associated with the actual work item type name? Perhaps something like allowsCreatingChildren? In the future, this same field will work for other work item types, so I'm still not sure I understand what does the frontend use this conditional for
@gitlab-org/plan-stage/backend-engineers could I please get your input on something? In #424517 (comment 1615530354) we started discussing the proper location for roll-up values. So there are 3 separate roll-ups we need to calculate:
1. Children count (all children down the hierarchy)
This one could be added as a new field on the existing hierarchy widget
2. Weight roll-up count
Should we add this information to the existing weight widget? In a way, this new field would depend on the hierarchy widget, since we are counting weights down the hierarchy. So we have some alternatives:
Return null if the hierarchy widget doesn't exist on the work item type
Create a new widget for weight roll-ups, leaving the other one simply for fixed weights. If we introduce a new widget, we could start adding validations for widget dependencies as we started discussing in #429654 (comment 1622222930) (eg: hierarchy widget is mandatory if you are adding the weight roll-up widget)
3. Health status roll-up counts
Same as with weight, should the new field exist in the existing health status widget? Or should we create a new widget for health status roll-up counts
cc @deepika.guliani as you are waiting on a potential structure for the response
I think it will make more sense to put all the roll up data in one place or a widget rather than being scattered across widgets. I believe the backend team would have a more informed perspective on this matter
@mcelicalderonG@deepika.guliani I remember this was briefly discussed on sync-up call a while ago (according to notes October 26th), and overall preference on the call was to rather use a separate widget. Though TBH when thinking about it further, I think the first option (putting this information to the existing weight widget, or health status widget in case of health status) might work too, we wouldn't also have to add a new widget anytime we want to roll-up some attribute.
Do we expect scenarios when roll-up weight is used separately/independently on weight itself?
A separate widget would allow scenarios when children weight should be rolled-up in the hierarchy through items for which we don't want to allow weight. E.g. if we had Epic->Feature->Issue hierarchy and user would want to show roll-up weights on Epics, but not allow to set weight on "Feature" type (only on Issue type), then it would be a reason to use separate widgets. But I doubt we plan something like this?
Having it as part of Weight widget might be easier to use/configure once we allow customization of work item types.
I agree that keeping weight and health status roll-ups within the same widget should work for the scenarios we have discussed.
Do we expect scenarios when roll-up weight is used separately/independently on weight itself?
I believe one reason to keep widgets separate was to make it a licensed feature but this is already the case for weight and health status, so I don't think it applies here.
We'd have to confirm if we could need a Type that has weight (and children with weights) but doesn't support roll-up, otherwise, the combined approach seems more straightforward.
I remember this was briefly discussed on sync-up call a while ago (according to notes)
Thank you, @jprovaznik I had forgotten about that. Another reason to keep them separate would be as @johnhope said that we could have both fixed and rolled up weights. Have we discussed exactly how we want weight roll-ups to behave yet? I think this could also determine what the best path forward is. I mean things like, are we counting fixed weight values from children? Are we counting their rolled-up value if no fixed value exists? I know OKRs currently overwrite it's ancestor's weight even if they had a fixed value set, but I think that's probably not what we want.
One thing I don't like about having rolled-up values in the existing widgets, is that the widgets now depends on the existence of another widget in order to perform "some" of its functions. In the alternative, the new widget, by definition, depends on the hierarchy widget. And, we can enforce this with validations such as "cannot add weight roll-ups widget if hierarchy widget is not added too".
I believe one reason to keep widgets separate was to make it a licensed feature but this is already the case for weight and health status, so I don't think it applies here.
@egrieff that's a good point, a downside of re-using existing weight widget would be that we would mix/present licensed fields together with not-licensed fields. A separate widget would be cleaner from this POV.
Have we discussed exactly how we want weight roll-ups to behave yet? I think this could also determine what the best path forward is. I mean things like, are we counting fixed weight values from children? Are we counting their rolled-up value if no fixed value exists?
I thought we would just sum up both item's roll-up weight (of children) with its fixed weight (if set on an item). But you are right that if a weight is set on an item it may mean weight of the item including all its descendants. @amandarueda from what value(s) should be rolled-up weight counted?
One thing I don't like about having rolled-up values in the existing widgets, is that the widgets now depends on the existence of another widget in order to perform "some" of its functions. In the alternative, the new widget, by definition, depends on the hierarchy widget. And, we can enforce this with validations such as "cannot add weight roll-ups widget if hierarchy widget is not added too".
I agree. It allows us to keep this logic/functionality separate instead of mixing it with weight.
A potential downside is that users would have to add every roll-up widget to custom types when they want to see the roll-up info there, but on the other side it's more flexible (roll-up weight can be used only for specific types if user prefers).
I thought we would just sum up both item's roll-up weight (of children) with its fixed weight (if set on an item). But you are right that if a weight is set on an item it may mean weight of the item including all its descendants. @amandarueda from what value(s) should be rolled-up weight counted?
@mcelicalderonG@jprovaznik There is an active research project led by @nickleonard to determine how we should handle weight rollups. You can find possible scenarios explained here. @nickleonard when do you expect to have findings for this behavior?
@mcelicalderonG@jprovaznik My apologies on the delay on having the logic, it was my intention to ignore tasks and implement the same behavior for weight rollup that we have today on legacy epics. But we've since changed direction and are now including tasks so we really need to complete the research in order to not rework this in the near future.
@amandarueda We should be able to complete the initial research in 16.7, but depending on what we find there may not be a simple outcome; e.g. one of the things we're looking at is whether there is a consistently expected behavior, or whether this is something teams diverge on. Especially if we find teams are not aligned (we see a lot of different expectations) we will need further design and validation on how to best meet the most teams expectations and easily support any other teams adapting to our process.
Interesting, thank you @nickleonard! I realize this is a terrible question, but I think we need to be able to establish expectations and make some decisions on how to move forward - if the results tell us that we need a divergent experience, how many cycles (milestones) would be needed for design/research to obtain an outcome? If you could provide the best case and worst case estimates that would be helpful!
@amandarueda I wouldn't think more than 1-2 milestones to design and validate a solution that would work across diverging expectations, and ideally we can even more quickly identify a more immediate MVC on the iteration path, but I can't say for sure how small that MVC could be (or if it would need more validation, etc) until we have more insights from the research.
@deepika.guliani answering your question here as I had to refresh my memory on this topic. I think that the research outcome doesn't change a lot what we have discussed here. So my take from this thread is what @egrieff and @jprovaznik discussed before. I think the only good reason now to have a separate roll-up weight widget is that making the roll-up widget require a different license that the existing weight widget. @amandarueda do you see this as a possibility? Or you think both weight and roll-up weight will always belong to the same tier?
So to conclude, do you all think keeping the new roll-up weight in the same widget is the best way to go? I don't think we even need to care about dependencies with the hierarchy widget, because simply, if no hierarchy widget is present, then we shouldn't have children. So roll-up weight should be null (and that's something we can implement, "always return null roll-up if no hierarchy widget present")
I think the only good reason now to have a separate roll-up weight widget is that making the roll-up widget require a different license that the existing weight widget. @amandarueda do you see this as a possibility? Or you think both weight and roll-up weight will always belong to the same tier?
Thanks for asking @mcelicalderonG! Similar to what Gabe was saying in the migration call today, I expect that in the future, our license tiers will be based on behaviors of features, not necessarily the feature itself. So as an example, yes, I can see the rolled up weight value on the epic record being a feature of Ultimate, whereas let's say if we were to include the regular weight widget on the epic for manual entry, that would be available for Premium. @gweaver does that jive with your thinking?
Thank you, @amandarueda! So given that the implementation can go both ways, I think we should probably go with separate widgets simply to better support the separation of these behaviors. Right now issue_weights is a starter feature, are we changing that? Also what should be the tier for weight roll-ups?
Or you think both weight and roll-up weight will always belong to the same tier?
@amandarueda to align most closely with the existing behavior, I think that anytime a license has weight (ex: GitLab Premium), then we should support weight rollups in the appropriate locations (ex: weight rollup in the hierarchy widget, weight rollup in board lists, ...) -- otherwise, the value and usefulness of the weight widget diminishes greatly. So in this particular case, both issue_weights and weight roll-ups would be GitLab Premium. WDYT?
I understand the need to ensure weight as a feature is viable at the Premium level, but the story to move to Ultimate should be portfolio/cross functional level planning tools. Rollups and summarization at the epic level seem to fit this use case. On the other hand, we offer single level epics at Premium which would require weight rollup of children, so I do see the use case there as well. I'm on the fence.
@mushakov can you provide your opinion on this one? TLDR, we need to determine if weight rollups at the epic level should be Premium (as it is today) or Ultimate. I was heading in the direction of Ultimate for further differentiation of portfolio/cross functional level planning tools, but can see how that will hurt the Premium epic workflows. WDYT?
@amandarueda I think rollups fit a single-team planning workflow. Think of a team decomposing a large effort and then trying to divide it into MVCs. A weight rollup would be helpful in that workflow. I think that without some capacity to see an aggregate of weights, it's really hard to complete this process.
I think the behaviour should be the same as of now with epics having issues maybe the user does not have access to. Unless that is explicitly mentioned
@amandarueda Do we want to include the work items that the user does not have access to in the rollup count ?
@deepika.guliani I'd like to remain consistent with the legacy behavior. So in this case, the count should ignore user permissions per Jan's comment. Thank you for checking!