
Gitlab 12.8 Released with Log Explorer, NuGet, and Compliance - munchor
https://about.gitlab.com/releases/2020/02/22/gitlab-12-8-released/
======
cuddlecake
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
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
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.

~~~
gabeweaver
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...](https://about.gitlab.com/releases/2020/02/22/gitlab-12-8-released/#single-
level-epics-now-available-in-premium)). 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 ;)

------
sschueller
I wish the full jira implementation wasn't only available in the most
expensive plan. We would rather use gitlab but the cost would be more than
double of what we pay for bit bucket.

~~~
PlanPortflioGL
sschueller, could you help me understand what you mean by "full jira
implementation"? We are working to align our plan features to the right tiers
([https://gitlab.com/groups/gitlab-
org/-/epics/1887](https://gitlab.com/groups/gitlab-org/-/epics/1887)) and it'd
be helpful to understand what specifically your are looking for.

Thanks in advance!

~~~
sschueller
Thanks for the reply. I am referring to
[https://docs.gitlab.com/ee/integration/jira_development_pane...](https://docs.gitlab.com/ee/integration/jira_development_panel.html)
which is only available in the Premium version.

~~~
PlanPortflioGL
Ok thanks for the clarification, I'll add this to the list of topics to
discuss with the other Plan PMs.

