Hi...I’m another Plan PM and would love to jump in. Thanks for being patient…and even more so for contributing your perspective to help make GitLab better for t

Hi...I’m another Plan PM and would love to jump in. Thanks for being patient…and even more so for contributing your perspective to help make GitLab better for the wider community. I agree with you that we need to do a lot of improvement around the UX of Group/Project navigation — especially when something is in one and not the other. Here’s a bit of additional background context on Epics... We noticed that a lot of folks have been trying to use Milestones for Epics. I think a main reason for this was due to the fact that up until yesterday when 12.8 was released, Epics were restricted to Ultimate (https://about.gitlab.com/releases/2020/02/22/gitlab-12-8-released/#single-level-epics-now-available-in-premium https://about.gitlab.com/releases/2020/02/22/gitlab-12-8-rel...). We made this change because we believe Epics and Milestones serve two distinct purposes and are applicable to Directors as the buyer — and even arguably Managers — within our pricing model (https://about.gitlab.com/handbook/ceo/pricing/ https://about.gitlab.com/handbook/ceo/pricing/) . The goal of Milestones is to group issues by time horizon, whereas an Epic is used to group issues by subject matter. This also typically maps to different key personas within an org and how they measure progress. Within GitLab, Issues are the key object that links Milestones to Epics. By looking at an Epic’s issues, we dynamically derive delivery dates of an Epic based on when the underlying children issues have been scheduled for implementation. We designed it this way so delivery teams didn’t have to constantly answer the question “when is this coming and are we on track,” instead surfacing that information automatically on the roadmap to keep stakeholders across the business updated. We also did this because we believe the timeline should reflect the reality of the teams that are responsible for delivering and not a forced, untenable schedule that will leave teams burnt out. While this is the inverse approach you suggested with Milestones inheriting due dates from Epics, we think this will ultimately result in a healthier relationship / scope trade-off discussions between delivery teams and their stakeholders. As for surfacing Epics within Boards, we plan to tackle that with via horizontal swimlanes (https://gitlab.com/groups/gitlab-org/-/epics/328 https://gitlab.com/groups/gitlab-org/-/epics/328). Additionally, we aren’t planning on making Boards within Milestones, but we are planning on extending Boards to make grooming, managing a sprint, and doing capacity planning a much more delightful experience. I really appreciate your input and would love for you to jump into some of these issues or open new ones in gitlab-org with your feature requests! Lastly, I understand what you mean when you say things feel a bit "weird". Iterating quickly doesn't always produce the most polished experience while big features are being developed, but it does yield the best long term outcomes as a result of more frequent and timely feedback like this ;)