►
From YouTube: Webinar - Plan - How GitLab Does Product Management
Description
Webinar for Commercial customers interested in using GitLab Plan for product or project management. Hosted by Gabe Weaver (PM for Plan) and Carlos Bazan (Commercial TAM), this webinar covers key plan stage capabilities as adopted by GitLab PMs to plan monthly iterations.
A
Hello,
everyone
and
welcome
to
today's
webinar
how
gitlab
does
product
management
the
webinar
will
consist
of
a
pre-recorded
video
and
a
panel
of
gitlab
team
members.
Answering
your
questions
live
via
the
q,
a
chat
section,
a
recorded
version
of
the
webinar
will
be
available
after
the
presentation.
Now,
let's
go
ahead
and
get
started.
A
This
is
going
to
be
a
high
level
discussion,
a
101
if
you
will-
and
we
encourage
you
to
ask
questions
and
provide
feedback
on
where
you
want
clarity,
we
will
review
how
git
lab
teams
are
organized
our
product
development
flow
planning,
our
monthly
releases,
collaborating
on
delivery
plans
and
a
bonus
item
of
how
you
can
automate
parts
of
the
issue
management
process
and
the
end
to
start
how
the
gitlab
teams
are
organized
and
so
to
understand
how
gitlab
has
divided
the
product
work.
It's
essential
to
know
our
mission
and
strategy
at
a
high
level.
A
Gitlab
believes
everyone
can
contribute
we're
building
open
source
software
to
enable
this
contribution,
and
our
goal
is
to
be
the
leading,
complete
devops
platform
within
a
single
application.
So
the
way
that
we
organize
our
product
teams
is
around
the
devops
software
delivery
life
cycle,
which
you
see
here.
The
hierarchy
begins
at
the
top
with
sections
which
is
going
to
be
our
dev,
our
sec
and
our
op
sections
within
each
section.
A
We
further
classify
by
stages,
for
example,
within
the
development
stage,
is
the
plan
create
verify
and
package
stage
and
then
we
further
classify
within
these
stages
by
groups.
So,
for
example,
engage
group
is
the
rather
game
stage.
Is
the
plan
stage
and
within
that
stage,
is
the
project
management
group,
the
product
planning
group,
as
well
as
the
certified
group?
Now
gabe
you
manage
that
plan
stage.
Does
that
mean
you're
the
product
manager
for
each
of
the
groups
within
that
stage
as
well.
A
B
B
I
think
every
organization
is
unique
and
has
different
constraints.
We
use
scope
labels
to
denote
the
hierarchy
as
most
of
the
product
teams
work
out
of
a
single
repository,
because
gitlab
is
a
modern
repo,
a
monolithic
ruby
on
rails
application.
For
the
most
part,
we
also
use
groups
and
subgroups
for
notifications
only
so
we
can
take
our
hierarchy
and
break
it
up
into
groups
and
subgroups
so
that
we
can
easily
notify
different
teams
with
a
single
app
mentioned
within
the
college.
B
I
generally
recommend
that
organizations
do
they
can
to
restructure
their
groups
and
projects
around
their
various
value
streams
that
enables
seamless
reporting
from
the
lower
level
product
teams
all
the
way
to
the
executive
roadmap
view.
This
is
the
basic
behavior
of
groups
and
projects.
So
if
you
are
able
to
reorganize,
I
would
suggest
doing
that
and
if
you're
not,
there
are
a
couple
workarounds
like
sharing
groups
into
other
groups
for
kind
of
permissions
access
and
then
we're
also
working
on
doing
a
better
job
of
allowing
work
to
roll
across
different
hierarchies.
A
Thanks
for
that,
now
that
we
know
how
the
product
teams
are
structured,
let's
go
over
gitlab's
product
development
flow,
so
this
image
illustrates
the
build
process
for
our
teams.
Gitlab
follows
this
defined
and
repeatable
flow.
We
have
two
two
tracks
here:
the
validation
track
and
the
build
track
at
the
start
of
the
validation
track.
We
collect
ideas
into
a
background
via
issues
the
backlog
acts
as
a
single
source
of
truth
for
stakeholders
to
engage
with
the
product
group
and
for
this
reason
the
issue
description.
A
The
discussion,
as
well
as
the
metadata
within
that
issue
are
vital
pieces
to
keep
stakeholders
up
to
date.
We
moved
then
into
problem
validation,
to
understand
the
problem.
We
want
to
make
sure
that
we're
providing
the
right
solutions
whenever
we
do
deliver
them.
So
the
team
validates
the
problem
through
in-depth
interviews
with
potential
users,
user-friendly
mapping,
among
other
forms
of
validation,
and
if
the
problem
is
minor
enough
and
well
understood,
for
example,
let's
say
a
bug,
it
may
be
possible
to
move
quickly
through
this
phase
by
documenting
the
known
data
about
the
problem.
A
A
And
to
in
this
stage
we
want
to
ensure
that
the
idea
that
we
have,
I
ideated
them
is
going
to
actually
provide
value
for
our
customers.
So
we
do
some
more
interviews
with
our
customers
to
make
sure
that
we're
capturing
everything
and
not
missing
anything.
As
far
as
that
solution
that
we
ideated
on
do
note
that
the
validation
prac
runs
in
parallel
to
the
build
track.
So
we
work
to
have
our
product
team
works
to
have
at
least
two
months
of
well-validated
solutions.
A
A
So,
following
the
final
stage
within
the
validation
track,
the
features
should
already
be
broken
down
into
the
quickest
change
possible
and
be
ready
for
a
more
detailed
review
by
engineering
and
during
this
phase,
product
managers
are
able
to
prioritize
issues
for
a
milestone,
so
gabe
during
this
build
planning.
How
are
you
typically
communicating
with
the
engineering.
B
B
Similarly,
when
someone
on
my
team
needs
my
input,
they
simply
mention
me
in
a
comment
and
I'll
have
to
do
waiting
for
me
to
follow
up
when
I'm
available.
We
also
hold
synchronous
planning
meetings
once
a
week
to
touch
base
on
the
more
complicated
topics
that
are
better
suited
for
face-to-face
communication.
A
Got
it
the
next
phase
is
development
and
test,
and
the
development
and
test
phase
is
where
we
build
the
features
address
any
bugs
technical
debts
and
test
those
solutions
before
launching
them.
So
the
engineering
manager
will
assign
an
issue
to
an
engineer
who
is
going
to
be
responsible
for
building
the
feature.
An
engineer
can
also
self-service
and
pick
the
next
priority
order
issue
from
the
ready
or
development
queue.
When
the
work
is
done,
we
merge
the
changes
into
production
and
close
off
the
issue.
A
B
I
would
love
to,
I
think
now
that
you
have
a
high
level
understanding
of
our
product
development
flow.
Let's
talk
about
how
we
manage
that
process
in
gitlab,
while
we
continuously
deliver
improvements
to
gitlab.com
our
planning,
cadence
centers,
around
our
monthly
release
to
our
self-managed
customers
and
we've
shipped
a
new
release
gitlab
on
the
22nd
of
every
month.
For
the
past
119
consecutive
months,
I
put
together
a
small
demo
so
that
I
don't
have
to
dirty
our
actual
issues
and
epics
that
we
use
to
manage
our
product
so
that
I
can
illustrate
various
tasks.
B
I
do
each
month
without
worrying
about
that.
So
in
this
example,
I've
set
it
up
according
to
value
streams.
As
I
mentioned
earlier,
we
have
an
awesome
co
within
austin
co.
We
have
a
consumer
products
division
and
we
have
a
services
division
within
the
consumer
products,
there's
a
mobile
app,
there's
a
web
app
and
then
within
the
services
division.
B
I've
also
set
up
some
basic
labels
to
help
us
track
work,
as
it
goes
through
each
stage
of
the
product
development
flow.
It
also
helps
us
categorize
issues
by
the
type
of
work
they
represent,
so
we
have
different
tracks
for
build
track
and
validate
track.
We
have
different
types:
we're
using
scope,
labels
here,
which
are
mutually
exclusive,
key
value
pairs
on
an
issue
to
denote
the
issue
type,
and
then
we
also
have
a
scope
label
set
to
represent
our
overall
workflow
through
our
product
development
flow.
A
Yeah
issues
are
essential
at
lab.
A
lot
of
my
customers
are
using
issues
to
be
able
to
show,
which
is
sorry,
labels
to
show
which
issues
are
on
hold,
which
are
high
priority,
even
which
issues
that
they're
working
on
that
are
funded
versus,
not
funded.
So
a
lot
of
use
cases
there
for
for
labels
exactly.
B
In
gate
lab,
we
use
milestones
to
act
as
a
release
playing
time
box
in
our
iterations
as
shorter
term
time
boxes,
so
our
releases
run
for
a
month
and
our
iterations
typically
are
two
weeks.
So
within
a
given
release,
we
have
two
iterations,
and
this
helps
us
take
high-level
kind
of
themes
and
break
demand
down
into
smaller
deliverable
units
during
each
iteration.
A
B
B
I
typically
organize
my
roadmap
into
these
sort
of
different
high-level
themes,
so
that
my
team
will
need
to
work
on
the
upcoming
releases.
Epics
are
great
because
they
can
be
nested
up
to
seven
levels
deep,
so
you
can
break
something
down
all
the
way
from
like
a
strategic
initiative
down
to
a
user
story.
B
The
epic
view
is
also
helpful
for
easily
organizing
sub
epics
and
issues
into
different
themes
from
within
the
view
you
can
create
new
issues.
You
can
add
existing
issues,
you
can
create
new
epics,
you
know
existing
epics
and
you
can
also
drag
and
drop
these
around
to
change
the
parenting
and
the
order.
So
you
can
easily
build
out
a
whole
business
scope
worth
of
release
within
a
single
epic
view.
B
See
now
that
we
have,
we
can
kind
of
understand
how
we
have
our
epic
setup
and
issues
created.
We
can
use
boards
to
visualize
our
life
cycle.
There
are
several
different
board
configurations
that
I
leveraged
throughout
a
given
release
cycle
and
I've
created
a
board
to
represent
our
validation
track.
Not
every
issue
has
to
go
through
every
stage,
but
we
generally
have
a
rule
that
all
of
them
stop
a
plane
breakdown
in
order
for
final
input
from
engineering
on
implementation,
details
and
then
once
issues
have
been
waited,
we
mark
them
as
ready.
B
So
in
this
board
I
have
an
initial
drop
link
for
issues
that
need
to
be
triaged,
I'm
also
grouping
by
epic.
So
I
can
see
things
that
are
part
of
themes
that
I
have
already
defined
and
where
they
are
in
their
lifecycle,
and
so
I
have
a
validation
backlog
for
the
settings.
Discovery
for
the
mobile
app
there's
an
issue
in
problem
validation
for
the
user
settings,
and
then
I
also
have
when
I'm
ready
and
these
these
kind
of
move
forward.
B
I
just
need
to
drag
them
and
drop
them
in
different
stages
and
then,
as
they
are
ready
for
engineering
to
look
at,
I
will
put
them
in
a
plane
breakdown
and
then
it's
we
kind
of
go
through
process
asynchronously.
Where
we
wait
for
issues
the
engineers
will
do
that
and
then,
as
soon
as
they
do,
we
can
move
it
into
ready.
B
I
think,
once
you
have
things
that
are
kind
of
this
is
like
carlos
said
earlier.
This
is
running
parallel
to
our
build
track
when
things
are
in
ready,
we
can
go
over
to
what
I
use
is
a
milestone
board,
and
this
is
where
I
have
my
different
releases,
which
are
the
milestones
that
I
kind
of
showed
earlier.
I've
created
a
list
for
each
of
those,
and
then
what
I
can
do
here
is
if
I
need
to
go
in
and
filter
things
that
haven't
been
scheduled.
B
Yet
we
can
kind
of
see
like
I
generally,
if
this
isn't
problem
validation,
it's
not
ready
yet.
So
what
I
do
is
I
filter
this
by
label
and
I'll
go.
Workflow
is
ready,
and
that
will
enable
me
to
see
all
the
issues
across
all
the
epics
or
parent
themes
that
are
ready,
and
I
can
sequence
that
work
out
across
different
releases.
B
B
You
can
create
label
lists,
assigning
lists,
you
can
create
iteration,
milestone,
lists
and
they're
all
good
for
different
use
cases,
and
so,
when
I'm
going
into
trying
to
sequence
some
of
this
workout
across
the
communications,
I
can
see
how
much
weight
is
in
each
iteration.
Based
on
my
team's
velocity
and
I
can
kind
of
calculate
my
team
usually
gets
around
10
done.
I
probably
have
too
many
here
and
I
might
want
to
move
this
out
into
the
next
one.
B
This
is
still
overweight,
so
I
might
move
this
out
into
the
next
one,
a
little
bit
and
kind
of
try
to
shift
some
of
these
until
we
kind
of
balance
out
what
our
weight
should
be
and
again.
The
group
by
epic
is
a
great
feature
to
use
here,
because
you
can
kind
of
see
everything
in
context
of
the
the
parent
epic
that
it
belongs
to.
So
you
can
kind
of
make
trade-offs
across
your
different
themes
when
you're
doing
your
kind
of
iteration
planning
into
the
future.
B
And
then
for
the
current
iteration,
I
have
a
board
that
is
scoped
to
the
current
iteration
and
edit
board
settings.
We
see
it
scope
to
the
current
iteration
and
I
have
my
workflow
labels
that
are
part
of
the
build
track.
So
I
can
see
things
that
are
marked
as
ready.
I
can,
whenever
an
engineer
wants
to
pick
them
up,
they'll
just
grab
it,
they
will
assign
themselves
they'll,
drag
it
into
progress
when
they're
done.
They'll
drag
me
into
review.
B
Once
the
merge
requests
have
emerged,
it
usually
gets
pushed
up
to
canary
for
production.
We
verify
the
behavior
there.
We
make
sure
that
all
the
tests
are
passing
all
the
acceptance
tests,
the
in
the
end
test
and
then
once
it's
been
verified,
we
move
it
into
close
and
then
the
issue
is
done
because
it
is
on
production,
our
customers,
hands.
A
B
Yeah
we
use
geekbot
and
slack
for
daily
asynchronous
stand-ups.
I
also
use-
and
I
can
show
you
very
quick-
a
team
board
similar
to
this,
but
has
everyone
for
my
team
on
it
with
list
for
each
assignee
on
my
team.
With
with
these
boards,
I
can
get
a
nice
view
and
context
switch
or
just
switch
between
context
during
the
release
cycle.
Whether
I
want
to
see
what
my
team
is
working
on,
what
each
person
is
working
on,
if
we're
on
what
what
is
happening
in
our
current
iteration.
B
B
Thank
you.
I
think
now
that
you
can
see
how
we
planned
out
a
few
of
our
upcoming
releases
and
iterations.
Let's
take
a
look
at
our
roadmap,
so
when
you
assign
issues
to
milestones
and
to
iterations
it,
and
then
you
estimate
your
issues,
you're
able
to
view
your
epics
within
a
roadmap
view,
it
has
the
timeline
for
when
the
the
epic
and
all
of
his
children
have
been
scheduled
out
into
the
future.
So
you
can
see
here
I've
kind
of
broken
up.
B
They
can
quickly
go
to
this
roadmap
view
and
they
can
drill
down
and
they
can
see
exactly
what's
on
track
and
what's
not-
and
I
think
lastly,
I'd
love
to
explore
some
other
helpful
aspects
for
using
gitlab
to
manage
and
track
your
work.
One
of
the
things
that
we
use
extensively
in
gitlab
is
templates
and
they
allow
you
to
sort
of,
like
ever
effortlessly
predefined,
markdown
templates,
quick
actions
for
when
creating
or
editing
an
issue.
So,
for
example,
this
is.
These
are
git
labs,
actual
issue
templates.
We
have
one
for
acceptance,
testing.
B
We
have
one
for
audit
event
pro
tool.
We
have
a
bug
template.
We
have
one
for
facilitating
design
response
for
improving
documentation
for
running
experiments
during
the
validation
process
for
managing
feature
flags,
for
example
all
the
way
down
to
problem
validation.
So
for
each
of
these
different
steps,
we
have
templates
that
represent
them
and
they
sort
of
outline
the
different
steps
and
the
different
things
that
we
need
to
do
so
in
this
problem.
Validation,
template,
for
example.
B
B
So
this
is
from
our
actual
git
lab
team
that
and
all
the
issues
we
use
assembler
workflow,
that
I've
just
described
in
the
demo,
where
we
have
validation,
backlog,
problem,
validation,
design
and
so
on
and
so
forth,
and
so
what
I'm
able
to
see
here
is
an
overall
overview
of
our
lead
time
from
when
issues
created
to
close
this
14.4
days.
Our
cycle
time
from
when
an
emergency
request
gets
associated
to
an
issue
when
the
issue
gets
closed
is
27
days.
B
You
can
see
during
this
time
period
of
april
23rd
through
may
22nd,
we've
had
7131
new
issues
open
and
we've
deployed
about
16
times
a
day
across
our
different
environments,
and
what
I
can
do
within
this
view
as
well,
is
quickly
go
through
these
different
steps
of
my
process
and
identify
which
one
is
the
slowest
so
from
just
quickly.
Looking
at
this
solution,
validation
is
actually
going
to
take
a
little
bit
longer
because
it's
not
part
of
you
know
our
delivery,
work
stream
necessarily
or
if
like,
what's
going
to
go
into
a
specific
release.
B
I
care
the
most
about
things
that
are
in
the
build
track,
and
so
right
here
we
have
playing
breakdown
which,
across
the
52
items
that
went
through
this
stage
recently,
you
know
the
the
median
time
was
about
three
days.
Ready
for
development
was
about
five
days.
So
when
I
look
at
this,
I
kind
of
want
to
jump
down
to
this
and
understand
what
what
are
some
of
the
things
in
this
that
maybe
took
a
long
time.
And
why
so?
B
I
can
kind
of
see
each
of
the
issues
that
pass
through
the
stage
I
can
drill
down
and
I
can
click
on
it,
and
I
can
look
into
this
issue
if
I
want
to
communicate
with
the
engineers
that
were
on
it
and
ask
them
what
some
of
the
challenges
were,
and
it
sort
of
is
a
really
helpful
gauge
to
understand
where
your
slowest
process
is
in
your
workflow
and
as
long
as
you
set
up
your
labels
correctly
or.
However,
you
want
to
customize
your
labels.
B
Attention
so
one
of
the
things
I
regularly
do
is
check
the
iteration
of
mouse
and
burn
up
or
turn
down
charts.
So,
for
example,
here
is
the
from
our
demo.
The
current
iteration
that's
happening.
Where
we
have
some
issues
assigned
to
it.
I
can
see
the
things
that
are
open.
I
can
see
things
that
are
in
progress,
who's
assigned
to
them,
and
then
I
also
have
a
burn
down
chart
which
shows
me.
Are
we
burning
down
along
the
grid
line?
Clearly
we're
not.
B
This
is
the
demo,
but
it's
helpful
for
understanding
our
burning
down
effectively,
but
equally
important
is
understanding.
How
much
is
our
scope
change
during
the
iteration
right?
So
the
more
scope?
You
add,
it's
not
going
to
necessarily
move
this
burn
down
line,
so
you
could
be
completing
issues
while
also
adding
new
ones
to
the
iteration,
and
so
the
chart's
helpful
for
understanding.
Are
we
adding
new
scope,
and
so,
as
you
can
see,
the
iteration
started,
we
had
one
issue
over
the
course
of
the
iteration.
B
We
went
all
the
way
up
to
six
issues
and
then
we
removed
some
scope
down
to
four
issues.
We've
only
completed
one.
So
this
these
same
charts
are
available
on
the
milestone
report
view,
and
then
you
can
kind
of
get
some
high
level
views
up
here.
You
can
also
toggle,
if
you
prefer,
between
issues
and
issue,
issue,
count
and
issue
weight,
so
you
can
see
progress
in
those
two
different
dimensions.
B
The
other
thing
that
I
do
quite
often
is,
let
me
go
find
that
epic
I
was
at
as
you
can
see
these
indicators
right
here
are
health
status
that
can
be
said
on
individual
issues,
those
health
statuses,
roll
up
in
aggregate
from
all
the
child
issues
and
to
sub
epics
into
the
parent
ethics.
So,
at
a
very
high
level
you
can
see
right
here.
I
have
two
issues
on
track.
I
have
one
at
risk.
I
have
one
that
needs
attention
from
these
accounts.
I
can
see
exactly
where
the
one
that
needs
attention
is.
B
A
B
Than
traditional
companies,
I
would
think
we
we
value
our
customers,
privacy
a
whole
lot
and
we
don't
use
any
third-party
tracking
tools
or
software,
and
so
we
don't
do
event
collection
like
typical
product
teams
or
product
organizations
might
instead,
we
use
something
called
the
usage
ping
which
has
database
counters
together.
Anonymize
counts,
basically
the
frequency
and
the
uniqueness
of
who,
like
interactions
with
features.
So,
for
example,
I
can
show
you
this
is.
This
is
mine.
B
When
we
implement
a
new
feature
saying
we
want
to
see
how
many
people
create
an
issue,
I
have
no
idea
who
they
are,
because
it's
literally
just
an
integer,
but
it
does
show
us
that
the
total
count
across
all
of
our
instances
that
are
using
have
created
an
issue
in
may.
For
example,
I've
been
working
on
iterations
and
and
making
that
a
better
feature.
So
since
I
launched
it
in
september,
we're
kind
of
trapped
the
up
north
and
we're
going
to
start
to
see
adoption
of
the
feature
over
time.
B
I
think,
as
long
as
you
define
what
success
looks
like
for
each
thing:
you're
shipping
or
how
you're
going
to
measure
it,
it
doesn't
really
matter
what
what
tool
you
use
to
to
track
usage,
there's
dozens
of
them
out
there.
Every
company
uses
a
different
one.
Everyone
has
different
preferences,
but
as
long
as
when
you're
going
through
the
validation
process,
clearly
defining
what
success
looks
like
like.
How
are
you
going
to
measure
it
and
that's
something
that
we
do
during
the
validation
process?
Is
we
define
how
we're
going
to
measure
it?
B
So
that
way
we
know
when
we
go
into
the
build
track,
we
release
it
and
we
implement
whatever
usage
accounts
that
we
need
to
implement
and
we
start
collecting
that
data.
We
can
then
reflect
back
and
tie
it
back
to
a
specific
issue
or
epic
or
theme
that
we
delivered
and
seeing,
if
that
had
the
outcomes
that
we
hadn't
anticipated
and
if
not,
we
learn
from
it,
which
is
very
often
the
case.
B
A
Yeah,
so,
let's
so
anytime
that
you're
managing
issues
and
and
labels
to
manage
your
day-to-day
work
defining
a
specific
process,
it
could
be
difficult
to
keep
these
labels
in
the
correct
stack.
So
the
solution
that
gitlab
has
come
up
with
is
the
gitlab
triage
bot,
which
is
an
open
source
project
that
makes
it
possible
to
automate
the
hygiene
tasks
on
issues
and
merge
requests.
A
B
I
do
I'd
love
to
show
that
so,
if
you
remember
sort
of
like
the
workflow
we
set
up
where
we
had
a
different
workflow
labels,
what
I've
done
is
I
created
a
triage
policies,
yaml
file
in
my
ops
project
that
I
kind
of
talked
about
earlier,
and
I've
just
created
two
simple
roles
here.
The
first
would
be
marking
estimated
issues
is
ready
for
development.
So
not
all
issues
have
to
go
through
the
validation
track.
B
B
You
can
mention
any
user
who's,
a
member
of
the
project
or
the
group
I'm
going
to
mention
it's
going
to
mention
me
and
it's
going
to
automatically
apply
the
workflow
triage
label.
So
when
you
go
back
to
like
kind
of
looking
at
your
boards,
we
have
a
listing
here
for
triage
and
we'll
go
ahead
and
pop
that
issue
into
this.
So
when
I'm
looking
at
this
board,
I
can
quickly
triage
things,
especially
like
things
that
are
not
part
of
an
epic
that
I'm
kind
of
working
on
or
that
I
plan
for.
B
I
can
easily
see
that
new
issue
and
I
can
put
it
into
a
different
step,
whether
I
need
to
put
it
directly
into
the
build
track
or
I
need
to
put
in
the
validation,
backlog
and
kind
of
work
on
prioritizing
that
first
for
an
upcoming
kind
of
work
for
the
designer
or
the
engineering
loop.
So
it's
a
quick
example
of
how
how
you
can
use
gitlab
triage.
B
A
And
if
you're
interested
in
learning
more
about
it,
I
highly
recommend
synthesis.
This
body
is
completely
open
source
available
to
you
highly
recommend,
taking
a
look
at
this
article
from
our
strategic
marketing
team,
titled
issue,
automation,
keeping
your
issues
squeaky
clean.
This
is
going
to
give
you
some
more
overview
as
well
as
some
other
examples
that
you
can
do
and
how
to
actually
set
up
the
triage
bot
for
yourself.
A
C
C
D
C
D
C
D
C
F
Get
the
correct
link
added
but
yeah
we'll
we'll
promote
that
and
then
also,
I
think
we
do
offer
paid
professional
services
training.
So
if
your
organization
needs
training
in
this
reach
out
to
your
account
manager
or
technical
account
manager,
and
they
can
give
you
an
overview
of
those
options,
we
we
do
that
so
that
we
can
customize
the
training
to
your
particular
agile
workflow,
so
that
we
can
teach
how
to
do
it
in
your
organization,
there's
also
potentially
git
lab
university
and
yeah
the
gitlab
learn
site.
C
C
Area
various
videos
and
various
trainings
that
it
sounds
like
a
lot:
what
you're
you're
describing
just
a
little
further
details
and
further
training.
And
of
course
we
want
to
hear
your
feedback
to
understand
if
there's
something
within
these
videos
that
you're
not
finding
something.
You
want
additional
training
on.
We
do
plan
on
continuing
these
webinars
and
we
want
to
hear
from
the
audience
of
what
is
it
that
they're
interested
in
learning
more
about.
G
Yes,
hello.
Thank
you
guys
for
the
nice
presentation
question
I
have
having
some
bad
experiences
in
the
past,
with
tools
like
gyro,
etc,
where
you
can
configure
everything,
but
if
you
do
it
wrong
and
start
working
with
it
and
want
to
adjust
stuff
later
on
you
wind
up
having
a
hard
time,
how
difficult
or
easy
is
it
to
do
with
gitlab
to
play
around
a
bit
with
configuring,
your
particular
processes
and
maybe
wanting
to
to
alter
a
bit
later
on.
B
That
one
sure
it's
it's
fairly
painless,
I
mean
you
can
move
groups
and
projects
around.
You
can
there's
really
not
much
configuration
required
that
other
than
figuring
out
your
label
hierarchy
and,
and
so
like
it's
it's
pretty
flexible.
I
think
at
least
so
yeah.
It's!
It's
not
really!
Anything
like
like
jira
from
that
that
level
of
configuration
you
just
don't
need
to
do
it
for
the
planned
side,
there's
a
little
bit
more.
B
G
B
I
think
if
you
have
general
experience,
you'll
be
fine.
If
you
have
a
little
bit
of
technical
experience,
it
will
help
with
the
the
repository
and
the
ci
cd
and
that
kind
of
side
of
the
product
as
well.
But
it's
it's
fairly.
We
have
really
really
really
good
documentation.
It
always
could
be
better,
but
it
pretty
much
can
answer
most
of
what
you
need
in
terms
of
figuring
out
how
to
how
to
use
gitlab.
So
I
would
check
that
out
and
play
around
with
it.
B
C
C
H
Great,
so
we've
been
using
gitlab
for
a
few
years
at
the
company,
I'm
at
we're
really
trying
to
hone
in
our
process
more
and
a
lot
of
that
deals
with
agile,
which
I
just
saw
in
the
in
the
learning
section.
You
had
some
videos
on
that
which
I'll
review
afterwards,
but
I
wanted
to
get
into
when
you're,
using
the
agile
methodology.
Are
you
and
you're
creating
issues?
H
One
are
you?
Are
you
typically
doing
two-week
sprints
for
these
and
then
each
issue?
Do
you
break
them
down
into
like
different
points
and
are
they
you
know?
What
is
that
system
that
you
use
for
that,
because
we
were
reviewing
kind
of
different
ways
that
we
were
doing
that
internally
and
I
wanted
to
see
what
you
thought
your
best
practice
was
on
that.
B
Yeah,
I
can
take
that
there's
some
teams
that
are
using
iterations
in
gitlab
there's
other
teams
that
are
using
more
workflow
based
system
with
kanban,
and
we
support
both
in
terms
of
what
my
team
does.
We
sort
of
do
a
mix,
but
in
terms
of
how
we
break
issues
down,
we
usually
start
with
the
epic
which
is
like
will
contain
lots
of
different
issues.
Your
tasks
need
to
be
done
or
vertical
feature
slices.
B
That's
sort
of
like
how
I
like
to
coach
my
team
to
break
things
up,
so
it's
something
that
requires
both
front
end
and
back
end
and
and
sort
of
even
some
design
to
complete
one
little
thing
that
an
user
can
do
with
your
feature
or
whatever
it
is
you're
building.
Then
that
gets
weighted
on
the
scale.
Usually
the
fibonacci
sequence
is
what
we
use
to
wait.
B
Apart
into
smaller
things
that
can
be
shipped
independently
or
smaller
vertical
feature
slices,
and
so
that
sort
of
happens
in
a
kind
of
a
continuous
process,
we
have
like
a
planning
breakdown
lane
on
our
board
and
then,
whenever
something
drops
there,
we
usually
get
the
engineers
involved
and
we
have
a
conversation
on
the
issue
about
how
to
tackle
it
or
on
the
epic,
and
then
we
kind
of
split
things
up
that
way.
So
I
suggest
doing
one
week
iterations
if
you're,
just
starting,
because
you
get
more
feedback.
B
Some
teams
can't
do
that.
It's
like
just
too
much,
and
so
too
would
be
fine.
But
the
sort
of
the
purpose
of
using
iterations
is
to
have
feedback
loops
to
make
sure
that
like,
if
you
do
have
extra
problems,
you're
mitigating
that
risk,
instead
of
letting
it
go
on
for
an
additional
week
and
then
once
the
team
is
sort
of
fluent
and
being
able
to
do
that,
and
it's
for
frictionless,
then
you
can
think
about
extending
out
to
two
weeks
is
what
I
would
recommend.
B
H
I
Okay,
one
quick
question:
we're
just
starting
using
gitlab
and
my
biggest
fear
as
a
project
manager.
Here
is
the
fact
that
will
be
using
labels,
and
I
really
do
not
want
to
have
clutter
regarding
regarding
this.
Do
you
have
any
advice-
and
I
don't
know
how
to
get
around
this
or
any
any
other
any
other
things
regarding
this.
B
We
are
working
on
making
some
better
kind
of
first
class
fields
on
issues
and
epics
like
status
for
one
and
then
type
so
we'll
have
issue
type
soon,
and
I
think,
with
that,
you
can
safely
manage
most
things
in
terms
of
clutter
like
on
boards.
You
can
disable
like
you
basically
turn
off
the
labels
on
the
on
the
issue
card,
so
you
don't
have
to
see
them.
B
If
you
don't
want,
I
I
do
think
that
they're
sort
of
play
an
important
role
in
kind
of
collecting
some
metadata
around
the
issue
itself
in
a
flexible
way
that
could
be
mapped
to
the
business.
Do
you
have
any
specifics
that
you
are
like
specific
ideas
or
things
that
you
would
like
to
avoid
in
terms
of
clutter
or
examples
that
you
can
provide
that?
I
could
maybe
speak
to.
I
B
If
you
want
to
restrict
access
to
that
parent
group,
then
only
those
people
who
have
access
can
manage
those
labels.
In
that
way,
you
can
have
some
consistency
coming
down
from
the
top
sure
subgroups
and
projects
might
be
able
to
create
their
own
labels
and
do
whatever,
but
from
a
reporting
standpoint
like
it's,
not
gonna
impact,
you
too
much.
B
I
think
that's
also
where
we
have
a
handbook
and
like
when
we
make
changes
like
this,
like
we
open
a
merge
request
and
have
a
conversation
about
it,
and
so
everyone
on
the
team
sort
of
understands
things,
but
it
is.
It
is
interesting
to
balance
like
the
the
allowing
team
to
be
autonomous
and
pick
their
own
processes,
but
also
trying
to
make
sure
you
have
some
consistency
from
a
organizational
standpoint.
So
it's
a
challenge,
but
there
are
some
ways
to
work
around
it.
I
guess.
G
J
B
So
you
don't
need
to
do
any
configuration
out
of
the
gate.
You
have
your
issues
that
live
in
the
project
and
your
merge
request.
Your
repository
is
also
in
a
project
and
simply
like,
if
you
open
a
merger
or
open
an
issue,
there's
a
button
on
there
to
create
a
merge
request,
and
so
what
that
will
do
is
when
you
click
that
button,
it
will
automatically
spin
up
a
branch
for
you.
B
It
will
automatically
create
the
merge
requests
and
it
will
automatically
associate
the
merge
questions
to
the
issue,
and
so
that
way
it
will
show
up
in
the
issue
view
and
then
it
will
set
the
merge
request
to
basically
automatically
close
the
issue
when
it
gets
merged.
You
can
turn
that
off.
If
you
don't
want
it,
if
you're
working
on
a
merge,
merge
request
in
one
project
that
needs
a
reference,
an
issue
in
another.
B
B
C
E
I
have
one
question
regarding
the
difference:
iterations
and
milestones
we
choose
because
we're
at
the
beginning
with
gitlab.
We
choose
to
use
milestones
for
sprints,
just
from
the
reason
that
it
gives
you
more
details
regarding
the
burn
up
then
burn
down
charge,
and
you
have
that
section
with
merge
requests
which
issues
are
open,
are
assigned
or
closed.
It
gives
you
more
details
at
that
level
in
each
way
it
will
impact,
as
on
the
long
term,
using
milestones
instead
of
using
iterations.
B
B
Will
re
create
your
recurring
iterations
for
you
automatically
automatically
rolling
issues
from
one
iteration
into
the
next,
so
there's
going
to
be
more
and
more
features
that
we're
going
to
be
adding
into
iterations
to
kind
of
act
more
like
that
kind
of
team
planning,
time
box.
So
I
think
you'd
be
fine
for
now
to
use
milestones,
but
eventually
you're
going
to
want
to
move
to
iterations,
where
I
would
recommend
it.
E
Yeah,
thank
you,
but
what
I've
noticed
that
on
milestone?
You
can
use
the
roadmap
and
you
can
see
on
a
guns
chart
how
they
are
displayed,
and
you
can,
I
don't
know,
see
your
epics
on
a
long
period,
how
they
overlap
with
your
sprints.
I
think
that's
why
we
picked
to
use
milestone
instead
of
iteration,
because
for
iteration
we
didn't
had
these
options.
It's
really
important
for
us
to
see
for
a
big
epic,
for
example,
to
see
on
how
many
sprints
we
can
use
to
fulfill
that
epic
to
launch
it
to
release
it.
B
Yeah,
that's
great
feedback
and
we
we
need
to
support
iterations
kind
of
rolling
up
into
epics
as
well
and
most
of
our
customers.
The
way
that
they
use
the
two
in
conjunction
is
they'll
use
like
if
they're
doing
quarterly
planning
or
pi
planning
or
something
that's
like
a
couple
months
long
that
time
period,
they'll
use
the
milestone
to
represent
that,
and
then
they
use
the
iterations
as
a
smaller
planning
period.
B
B
You
know
six
weeks
from
now,
you
can
use
a
milestone
for
that,
and
then
you
can
also
assign
that
same
issue
to
an
iteration
for
the
smaller
sprint
planning
but
great
feedback,
and
I
think
you'll
start
to
see
more
parity
between
those
two
in
terms
of
how
they
impact
roll-ups
and
gantts
and
roadmaps
and
stuff.
Like
that.