9 ms·

We upgraded to Silver because I liked some of the upcoming features for planning which would alleviate some of the problems we discussed in our teams, and I rea

We upgraded to Silver because I liked some of the upcoming features for planning which would alleviate some of the problems we discussed in our teams, and I really pushed for that upgrade. Now, some of theme were post-poned to 12.9, and I can wait, but GitLab really feels like it's in a weird state. For example, I can create boards that filter by milestone, but I can't create boards that filter by epic. I can't even add epics to milestones. So all in all, with the upcoming feature of assigning issues to multiple milestones, milestones seem like a much better way to group issues than epics. In addition, with the upcoming feature "Show milestones in roadmap", I barely see any need for Epics, since they integrate so badly with the rest of the planning tools gitlab provides, and I wonder why epics are a thing at all (and why gitlab doesn't just drop epics in favor of a milestone-type called 'epic') Another feature which I sorely miss, which are admittedly difficult to implement, are swimlanes/rows in issue boards. They would provide an entirely new dimension of possibilities. Relevant Epic in gitlab org: https://gitlab.com/groups/gitlab-org/-/epics/328 https://gitlab.com/groups/gitlab-org/-/epics/328 All in all, I love using Gitlab, but it also frustrates me greatly, since my main use is for its VCS and planning capabilites, and the latter is in a weird state, which leaves me with no choice but to wait.

PlanPortflioGL 7y ago
A Plan Product Manager from GitLab here! Thanks for this feedback. Our vision is that Milestones are the best way to group issues over a spans of time, while Epics work best for organizing related work that may span multiple milestones/longer development timelines. The Portfolio Management group is actively pushing to expand the functionalities of Epics across the board to better serve planning processes. Epics are young compared to our Issues and Milestones, and I agree we have many areas that need enhancement so the three can compliment each other. I also agree Epics should have the option to have milestones assigned to them (https://gitlab.com/groups/gitlab-org/-/epics/329 https://gitlab.com/groups/gitlab-org/-/epics/329) to better support planning over all. Any thoughts or additional feedback on that issue would be extremely helpful for the team as we map out the best MVC. Internally we have been discussing Swimlanes in boards (https://gitlab.com/groups/gitlab-org/-/epics/328 https://gitlab.com/groups/gitlab-org/-/epics/328) quite a bit and they would be a valuable add to our Boards. I'll share this thread with the other Plan team members and work to drive the conversation forward in that epic. Again, thank for this feedback, please continue to provide it so we can provide the right features to alleviate any frustration.
- cuddlecake 7y ago
  Hi, thanks for the reply. As I mentioned, I use milestones the way that you envision epics right now. I group all issues that somehow belong together, for which I want to track progress (and burndown/up over time) in a milestone. The milestone detail view is perfect for this. It has a description, a timeline, start and end date, unstarted, ongoing and finished issues, etc. All they lack to be even more "epic-ish-ly" for me would be a comment thread (as issues and epics have). Essentially, we use milestones as a well-integrade epic-surrogate, while compromising our ability to perfectly track progress on the current sprint (which will probably be resolved soon, with multiple milestone types and multi-assignment). Also, a way to drag issues into a sprint milestone would be great. (Unless the issue list reflects the priority sorting that is established in the open column of unfiltered boards by dragging issues up and down, then a multi-edit would suffice). For disclosure, we are a team of ~10 developers working mainly on a single project within a single group. So, switching between the 'group' and 'project' views is not something we do often, since we plan mainly for the project that we work on. So, we barely have visibility of the 'Epics' view in the first place (in fact, when we upgraded to Silver, I didn't even know where to find Epics). I think that I'm also lacking something that screams "CLICK ME TO GET TO THE GROUP THIS PROJECT YOU ARE VIEWING BELONGS TO" other than the breadcrumbs. At least I am _always_ looking at the sidebar first, then using the top navbar (completely ignoring the breadcrumbs, every time) Anyway, integrating epics with milestones seems difficult. I think a first great step would be to be able to assign a milestone to an epic (i.e. epics belonging to milestones). That could have two immediate effects: The milestone inherits due and start time from epics, and the epics and sub-epics automatically inherit assignment to that milestone. This presumes my view that milestones progress when epics belonging to that milestone progress, and epics progress when sub-epics or issues belonging to that epic progress. This, combined with the ability to have boards for epics, as I have boards for milestones right now, would probably suffice for me to feel comfortable with using epics at all. But, I doubt that, even if the aforementioned is implemented, I will get to see the features since I assume they will have Gold-level pressure on infrastructure (they are similar to some of the features that multi-level epics currently implement, and those are gold-level, too). Since I'm already in the flow: A really funky feature would be boards that are scoped to Milestones. I.e. not boards filtered by Milestones, but boards that belong to a milestone and not to the project. Currently, I have a board for every milestone (our pseudo epics) with our column workflows, and the ritual of creating that could be avoided and made predictable. In any case, I'm waiting patiently, and observing the gitlab-org epics.

PlanPortflioGL 7y ago

A Plan Product Manager from GitLab here! Thanks for this feedback. Our vision is that Milestones are the best way to group issues over a spans of time, while Epics work best for organizing related work that may span multiple milestones/longer development timelines. The Portfolio Management group is actively pushing to expand the functionalities of Epics across the board to better serve planning processes. Epics are young compared to our Issues and Milestones, and I agree we have many areas that need enhancement so the three can compliment each other. I also agree Epics should have the option to have milestones assigned to them (https://gitlab.com/groups/gitlab-org/-/epics/329 https://gitlab.com/groups/gitlab-org/-/epics/329) to better support planning over all. Any thoughts or additional feedback on that issue would be extremely helpful for the team as we map out the best MVC. Internally we have been discussing Swimlanes in boards (https://gitlab.com/groups/gitlab-org/-/epics/328 https://gitlab.com/groups/gitlab-org/-/epics/328) quite a bit and they would be a valuable add to our Boards. I'll share this thread with the other Plan team members and work to drive the conversation forward in that epic. Again, thank for this feedback, please continue to provide it so we can provide the right features to alleviate any frustration.

cuddlecake 7y ago
Hi, thanks for the reply. As I mentioned, I use milestones the way that you envision epics right now. I group all issues that somehow belong together, for which I want to track progress (and burndown/up over time) in a milestone. The milestone detail view is perfect for this. It has a description, a timeline, start and end date, unstarted, ongoing and finished issues, etc. All they lack to be even more "epic-ish-ly" for me would be a comment thread (as issues and epics have). Essentially, we use milestones as a well-integrade epic-surrogate, while compromising our ability to perfectly track progress on the current sprint (which will probably be resolved soon, with multiple milestone types and multi-assignment). Also, a way to drag issues into a sprint milestone would be great. (Unless the issue list reflects the priority sorting that is established in the open column of unfiltered boards by dragging issues up and down, then a multi-edit would suffice). For disclosure, we are a team of ~10 developers working mainly on a single project within a single group. So, switching between the 'group' and 'project' views is not something we do often, since we plan mainly for the project that we work on. So, we barely have visibility of the 'Epics' view in the first place (in fact, when we upgraded to Silver, I didn't even know where to find Epics). I think that I'm also lacking something that screams "CLICK ME TO GET TO THE GROUP THIS PROJECT YOU ARE VIEWING BELONGS TO" other than the breadcrumbs. At least I am _always_ looking at the sidebar first, then using the top navbar (completely ignoring the breadcrumbs, every time) Anyway, integrating epics with milestones seems difficult. I think a first great step would be to be able to assign a milestone to an epic (i.e. epics belonging to milestones). That could have two immediate effects: The milestone inherits due and start time from epics, and the epics and sub-epics automatically inherit assignment to that milestone. This presumes my view that milestones progress when epics belonging to that milestone progress, and epics progress when sub-epics or issues belonging to that epic progress. This, combined with the ability to have boards for epics, as I have boards for milestones right now, would probably suffice for me to feel comfortable with using epics at all. But, I doubt that, even if the aforementioned is implemented, I will get to see the features since I assume they will have Gold-level pressure on infrastructure (they are similar to some of the features that multi-level epics currently implement, and those are gold-level, too). Since I'm already in the flow: A really funky feature would be boards that are scoped to Milestones. I.e. not boards filtered by Milestones, but boards that belong to a milestone and not to the project. Currently, I have a board for every milestone (our pseudo epics) with our column workflows, and the ritual of creating that could be avoided and made predictable. In any case, I'm waiting patiently, and observing the gitlab-org epics.