gabeweaver

What specifically about line breaks is a headache? Would you prefer that pressing "Enter" automatically inserted a line break?

As for edit history, I'm assuming you are talking about the description edit history. If so, we had an open conversation (https://gitlab.com/gitlab-org/gitlab/-/issues/10103#note_206...) about why we placed the feature in Starter and above. If you'd like to continue the convo, please open a new issue with your proposal. If you are talking about a different edit history, please clarify so I can better understand your perspective. Thank you for the feedback!

This is great feedback. Going fast is a core part of our strategy, as is focusing on breadth over depth (https://about.gitlab.com/company/strategy/#breadth-over-dept...). Not only does this provide an easier path to collaborate and contribute for the wider community, it allows us to shorten the feedback loop with everyone that uses GitLab so that we can invest our time and effort in the areas that matter most to the wider community.

That said, I completely agree that we need to get better how we iterate and improve the quality and performance of existing features. We've more than doubled the number of Product Managers, Engineers, and UX Designers over the last 12 months to work alongside the wider community to help transition "barely usable" features into lovable features. Please ping me (@gweaver) on any long standing issues that are important to you and i'll do my best to route it to the directly responsible PM.

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-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/) . 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). 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 ;)

Hi. GitLab PM here. I'm really sorry that this is your experience. Can you point me to this policy? I would like to propose a change to it given that's not reflective of how most teams do planning and prioritization.

We care very much about support issues, regularly prioritize a large portion of each release to addressing them, and can not do it effectively without ongoing involvement and feedback from the wider community.

I will say that it is sometimes hard to separate the signal from the noise, given my team currently has 3k+ open issues. Please ping me (@gweaver) on issues that are relevant to you and I'll do my best to provide a status update / more information or bring in the relevant PM who can.

Hi! I'm one of the product managers at GitLab that will be contributing to the development of requirements management. I don't believe we've decided that it will only be an Ultimate level feature. The label was added to the epic (https://gitlab.com/groups/gitlab-org/-/epics/707) before any conversation had taken place...or even before there were concrete requirements to build requirements management ;)

We do our best to align features with the likely buyer according to our pricing model (https://about.gitlab.com/handbook/ceo/pricing/). Sometimes we don't get it right and need to fix our mistake after a feature is launched based on feedback from our wider community (example: https://gitlab.com/gitlab-org/gitlab-ee/issues/13856). We have been and will always be transparent about our pricing model and our mistakes in aligning new features with it.

If you're interested in collaborating with us as we build out requirements management, we would love that. It will help us build the right features for the right likely buyer. Please leave some additional thoughts on the epic discussion if you have them!