►
From YouTube: GitLab Release 11.4 Retrospective
Description
GitLab 11.4 Kickoff
Learn about what we're working on in GitLab 11.4! Follow along in our kickoff doc: https://docs.google.com/document/d/1E...
Read more about our product vision: http://bit.ly/2IyXDOX
Learn about FOSS & GitLab: http://bit.ly/2KegFjx
Get in touch with Sales: http://bit.ly/2IygR7z
A
Eric
asked
me,
after
the
11.3
retrospective
to
essentially
do
a
reboot
with
an
engineering
driven,
more
Bottoms
Up
approach,
we're
trying
to
pull
out
of
the
individual
team
retrospectives
we're
going
to
obviously
continue
to
iterate
over
this
over
the
next
few
months.
The
first
blush
looking
over
the
agenda
that
we
have
today.
A
Five
retro
moving
forward
and
I'll
wrap
up
before
I
hand,
things
over
to
Mario
and
just
say:
I've
already
received
a
few
great
suggestions
for
how
we
can
continue
to
improve
here
and
want
to
open
the
floor
and
welcome
others
as
we
get
ready
for
11-foot
five
and
beyond.
But
with
that
Mario
asked
you
to
kick
off,
but
when
will
this
month
thanks.
B
C
So
portfolio
management,
as
it
is
stated
in
the
document
like
we
have
been
doing,
he
calls
every
Tuesday
with
Victor
and
Pedro
from
the
UX
yarc
up
on
the
backend
and
itself
from
the
content.
It
has
been
really
helpful,
like
we
have
been
uploading.
Those
calls
in
the
YouTube
and
when
receiving
a
lot
of
feedback
regarding
how
we
can
move
forward
so
for
11.4
major
features
that
made
it
to
true
were
closing
and
reopening
ethics.
C
So
it
is
similar
to
what
we
have
for
issues
and
Amar's
where
you
can
close
an
epoch,
and
you
can
also
reopen
an
epoch
which
is
already
closed,
so
it
basically
puts
epochs
on
par
with
issues
and
remarks,
and
we
also
added
support
for
completing
slash
commands.
So
now,
if
you
go
to
comment
field
within
epics
and
you
I
can
slash,
you
would
see
all
the
slash
marks.
So
those
were
the
major
two
highlights
11.4
next,
just
sleepy.
D
Yeah,
a
fillip
is
not
available,
so
I'll
jump
in
for
him
there
so
about
secure
team.
We
were
happy
to
be
able
to
Schmidt
a
small
marriage
request
and
it
helps
to
reduce
occurred
and
move
forward
step
by
step.
And
another
point
was
that
in
crimson
tradition
we
had
some
issues
and
discovered
edge
cases
and
gasps
when
I'm
trying
to
understand
the
features.
And
this
time
we
had
synchronous,
kickoff
meetings
for
our
Ledger's
features
and
it
had
Percy
defines
expectation
all
of
the
team
and
avoid
those
issues
that
we
previously
encountered.
E
Thanks
so
I
wasn't
here
for
most
of
the
release,
but
while
I
was
out,
Breton
down
in
particular,
did
a
great
job
of
helping
us
adjust
to
some
security
issues
that
were
reported
and
get
those
fixed
without
too
much
interruption
to
the
rest
of
our
work,
which
was
really
great.
Nick
had
a
similar
point
he's
not
here
so
I'll.
Take
that
as
well,
which
the
create
team
had
a
similar
situation.
F
It's
John
speaking
from
the
quality
team,
so
the
team
feels
that
we
doing
a
better
job
shipping
features
and
tests
together
in
11
the
board
and
Illumina
3,
and
we
are
planning
to
close
out
that
this
gaps
even
faster
in
11:05.
The
next
point
is
the
trash
product
package
have
been
proven
to
offload
the
trash.
What
will
in
our
team-
and
we
looking
to
expand
this
as
well
on
to
you
Rachel
or
Mike-
to
cover
yeah
yeah?
This
is
Mike.
G
For
the
Geo
team,
we
categorized
all
the
issues
in
our
backlog,
every
single
one
and
closed
a
lot
of
them
also,
so
this
helped
a
lot
for
prioritizing
what
we
need
to
do
and
the
team
also
found
it
useful
to
refresh
themselves
on
me
issues
that
we
haven't
seen
for
a
long
time
get
lab
bought
also
was
very
helpful
here.
The
next
point
was
Gabriel
wrote
a
great
blog
post
on
how
geo
was
built.
G
H
Cool
things
like
and
so
of
me
manage
side
and
I.
Think
a
big
positive
City
over
the
last
month
was
a
much
more
improved
involvement
from
the
whole
team
when
it
comes
to
prioritization
and
I
think
specifically
categorization
of
different
issues,
and
so
all
of
the
engineer
has
been
working
quite
hard.
Thinking
about
what
digital
priority
around
technical
debt
items
are,
and
so
I
think
we
have
really
clear
visibility
and,
however,
what's
feature
work.
I
I
J
Dylan
so
yeah
for
the
monitor
team.
This
release,
one
of
the
things
that
went
really
well,
was
the
coordination
between
the
backend
and
front-end
teams.
Our
back
an
engineer
was
going
to
be
on
vacation
for
about
a
week,
so
we
started
by
mocking
out
the
whole
API,
so
the
front-end
could
continue
to
work
while
the
backend
engineer
was
out
and
that
went
well
and
with
that
also
the
the
deccan
engineer
was.
J
The
front-end
team
also
waited
until
the
initial
review
is
complete
before
writing
tests,
which
really
helps
help
them
not
have
to
then
go
back
and
rewrite
all
the
tests
had
they
written
them
in
the
beginning,
and
we
were
over
the
ship,
the
shoulder
thresholds
on
the
dashboard,
which
had
originally
slated
for
11.3,
but
we
were
thankfully
able
to
ship
at
this
time
so
on
Andre
cover
for
Phil.
Oh.
K
K
Maintainer
is
get
a
little
bit
of
like
swamped
with
reviews,
and
he
felt
a
significant
improvement
there,
where
he
felt
not
only
that
he
left
he
got
less
last
minute
reviews,
but
the
ones
that
got
him
at
that
time
had
been
put
in
a
much
better
shape
than
previously.
So
this
also
means
that,
probably
that
the
process
of
getting
work
by
to
maintainer
by
the
first
the
month
is
working
better
something
for
us
to
keep
track
of
for
the
next
releases,
and
that's
it
Sarah
over
to
you.
L
Thanks
and
the
UX
team
is
embedded
in
all
of
these
different
teams,
so
we
did
a
department
retrospective
as
well
just
to
make
sure
that
anything,
that's
going
well,
not
going
well
gets
bubbled
up
and
we
can
address
it
also
at
a
department
level.
So
what
went
well
for
us
is
that
we
have
really
good
collaboration
on
a
UX
research
effort
for
the
manage
team.
Everyone
was
involved
and
stayed
focused
on
what
we
were
trying
to
achieve,
so
we
got
really
good
results
there.
L
The
scheduling
and
collaboration
between
UX
engineering
and
PM's
I
think
overall
has
improved
in
every
group.
We
continue
to
see
that
get
better.
We
were
able
to
ship
many
improvements
to
our
design
system
and
that
was
added
by
everyone
in
the
department
contributing
on
a
milestone
by
milestone
basis,
and
as
we
mentioned
earlier,
we've
been
able
to
deliver
batch
comments
on
merge
request,
which
is
a
height
of
the
question
feature
as
well
as
a
design
for
the
group
level.
M
Thanks
Sarah
first
item:
this
goes
all
the
way
back
to
our
c1,
and
it's
just
a
case
where
it's
a
new
thing.
We
have
to
keep
in
mind.
As
most
people
know,
we
have
a
canary
environment,
but
one
thing
we've
changed
recently
is
that
we've
started
to
put
production
traffic
on
it
and
it
really
helps
if
we
can
ensure
that
if
we
take
advantage
of
new
giddily
features
that
those
features
sits
behind
a
feature
flag-
and
this
is
something
that
is
becoming
more
important
now,
because
of
production
traffic
and
the
canary
environment.
D
D
Our
team
really
was
torn
apart
because
between
the
u.s.,
our
shipping
and
the
code
quality
part
of
this
issue.
As
that
reviews
took
a
lot
of
time,
we
have
to
sink
a
lot
with
chamomile
and
the
DB
team
from
any
mesh
request.
It
was
really
hard
to
get
some
attention,
but
hopefully,
as
we
had
come
in,
which
was
who
was
dedicated
to
follow
the
delivery
of
that
particular
bigger
feature.
D
Another
thing
that
was
bringing
pressure
to
the
team
was
that
we
knew
from
the
beginning
of
the
curation
that
it
will
be
really
hard
to
deliver
the
dashboard,
and
yet
it
was
still
publicly
announced
in
triple
time
and
despite
the
recommendation
made
by
philippe-
and
this
is
something
that
we
really
struggle
with,
because
it
put
a
lot
of
pressure
on
us
to
try
to
deliver
and
we
finally
fail
to
do
it.
And
this
was
really
a
bad
situation
for
for
the
situation
next
to
young
our
oceans.
D
N
For
about,
we
postponed
this
game
and
it
was
post
on
postponed
a
few
times
ago.
This
is
this,
which
is
a
big
big
task,
and
postponing
this
any
further
causes
issues
in
each
cycle,
because
we
have
to
keep
fixing
a
menu
incompatibilities
which
are
brought
into
the
code,
but
it
was
postponed
for
valid
reason
for
making
sure
that
it
works
and
it's
tested
by
QA
team
and
I
hope
that
we
will
be
able
to
switch
in
at
the
beginning
of
hundred
Alonso
six
and
next
one
is
smack.
Thank.
F
You
from
the
quality
inside
so
the
upstage
area
needs
help.
We
don't
have
anybody
there
currently
and
I'm,
considering
assigning
somebody
from
from
the
dev
stage
team
to
help
align,
but
the
team
is
frettin,
so
we
also
ramping
up
on
hi
there
as
well.
The
next
thing
on
my
list
is:
we
have
we
had
a
really
long
amar
to
swap
out
all
the
UI
interactions
that
doesn't
need
to
be
UI
and
bacon
API
capabilities
in
the
framework.
F
It
was
a
really
big
amar
and
we
couldn't
pull
it
down
any
further
and
then
because
we
also
try
to
hand
this
off
to
another
owner
when
the
first
initial
implementer
was
on
vacation
that
backfired
as
well.
So
lessons
learned
on
us
there
other
improvements
that
we
are
planning
at
capture
down
below
on
to
you,
Rachel.
G
Yeah,
that's
Mike
here
again
for
the
Geo
team.
We
just
had
one
point
from
our
retrospective
on
what
went
wrong
this
month
and
it
was
that
there
were
a
lot
of
QA
failures
in
11.4
and
it
actually
blocked
a
few,
a
Mars
from
the
milestone,
and
we
know
that
there
are
a
number
of
improvements
coming
on
that
front
from
the
quality
team.
So
but
that
was
just
our
only
point
and
Liam
is
next.
I
You
yeah,
so
one
of
the
challenges
we've
had
this
month
last
month
is
really
around
capacity.
Our
team
has
lots
of
important
things
we
want
to
do
and
we're
constantly
trading
off
doing
the
things
that
our
users
are
asking
for
or
like
these
little
fixes,
just
the
user
experience
of
certain
things
we
do
and
balancing
that
with
some
of
the
vision
items
for
the
team,
so
the
massive
backlog
our
team
has
combined
with
be
incredibly
small
capacity,
has
been
one
of
our
biggest
challenges.
J
Well,
one
reason
for
that
was
that
the
reviews
took
a
lot
more
time
than
then
we
expected
and
and
sort
of
maintained,
reviews
and
DB
reviews,
and
all
of
that,
so
there
are
things
that
you
know,
ideas
that
we
have
for
how
to
improve
that
again.
I'll
talk
about
that
in
the
next
section.
The
other
note
I
have
in
here
is
the
nginx
ingress
metrics,
which
we're
supposed
to
go
into.
J
11.4
also
did
not
make
that
cutoff,
and
that
is
partially
because
the
settings
for
these
for
doing
this
were
moved
into
the
DB
and
they
used
to
be
just
any
mo
file,
and
that
makes
it
harder
to
work
with,
and
there
was
also
a
front-end
bug
that
ended
up
being
harder
to
fix
them
than
it
should
have
been
so
Shaun
onto
you.
Yes,.
L
Ask
some
things
so
a
few
things
went
less
than
well.
So
an
issue
is
added
after
the
kickoff,
which
caused
some
confusion.
We
were
able
to
ship
the
feature
in
the
end,
but
there
was
a
lot
of
noise
and
a
lot
of
back-and-forth
as
we
tried
to
reshuffle
some
things,
so
that
was
disruptive
and
the
configure
team.
You
were
a
lot
of
discussions
going
on
in
slack,
which
made
it
kind
of
difficult
for
you
Xers
to
follow
and
make
sure
that
they
were
up
on
everything
that
was
happening
so
that
made
that
difficult.
L
Some
product
discovery
issue
participation,
still
not
optimal.
You
xers
are
reaching
out
early
to
try
to
get
feedback
from
engineers
and
PM's,
but
the
participation
is
falling
off
mid
milestone
as
things
heat
up
and
mrs
are
being
put
in.
So
we
need
to
figure
out
a
way
to
make
that
better
many
design
system
merge
requests
came
in
at
the
last
minute
which
burden
Tori
is
kind
of
the
sole
reviewer.
L
So
we
have
some
some
ideas
in
the
next
section
on
how
to
improve
that,
and
there
was
a
need
for
vision,
mock-ups
for
the
September
20th
livestream
that
got
asked
for
very
close
to
the
deadline.
So
we
had
a
very
short
amount
of
time
and
we
hadn't
pre
planned
so
that
caused
some
of
our
UX
efforts
to
slip
as
we
tried
to
get
all
the
necessary
mock-ups
and
still
make
sure
that
we
did
our
deliverables
for
each
individual
team.
We'll
talk
more
about
that
in
the
next
section
on
to
Philip,
I
believe.
O
He
suggests
a
key
point:
are
we
did
the
refactoring,
the
truck
show
page
and
that
cost
some
progressions
that
were
only
caught
in
production?
So
we
open
the
retrospective
issue
and
basically
what
we
discovered.
That
is
that,
even
though
we
added
we
noticed
that
there
were
some
tests
missing
during
the
refactor,
the
test
we
added
were
not
enough
to
cover
for
everything.
So
what
we've
learned
is
that
before
we
start
any
new
refactoring,
we
need
to
look
into
the
tests
and
make
sure
that
everything
has
coverage
before
doing
your
refactor.
O
E
I'm
gonna
try
and
move
quickly
because
we're
at
2/3
of
the
way
through
the
call
and
2/3
the
way
through
the
agenda,
but
we'd
only
spend
the
longest
part
in
this
part.
So
andreas
Brundle
had
way
too
much
to
review
close
to
the
freeze.
He
was
the
only
database
maintainer
at
that
point.
He's
created
an
issue
to
get
that.
E
First
s
scaled
up
so
hopefully
were
already
doing
the
thing
we
need
to
do,
but
that
was
bad
because
we
were
burdening
him
with
too
much
stuff
clearly
to
close
the
freeze,
but
also
because
it's
too
much
stuff
one
person
to
do
anyway
and
I
see
Eric's,
adding
a
comment
that
we
have
another
DB
reliability
engineer
starting
in
November,
which
will
help
a
lot
as
well.
So
thanks,
Eric
Olivier
back
to
you,
yeah.
D
First
point
is
related
to
the
wrong
about
communicating
feature
about
features
instead
of
using
a
precise
date
to
communicate
the
delivery.
We
should
use
more
vague
word
like
coming
soon
or
q4.
Things
like
that.
There
is
an
open
issue
to
discuss
this.
The
second
point
was,
we
said
we
need
a
maintainer
in
the
secure
team,
but
actually
mate,
you
know,
is
not
the
correct
world,
and
this
has
been
a
bit
debated
below
and
I
won't
go
into
details,
but
there
is
also
a
follow-up
issue
about
that,
so
feel
free
to
jump
in
and
discuss.
D
This
I
would
just
assume
app
that
we
we
actually
need
more
to
create
crew
like
it
has
been
designed
and
what
it's
described
in
the
end
book.
So
because
the
main
goal
is
to
a
dedicated
domain
experts
available
in
the
iteration
to
spend
some
time
with
us
to
quickly
and
correctly
define
design
the
feature
that
impact
its
domain
his
domain
and
the
next
one
was.
D
Maybe
we
should
try
to
avoid
at
all
the
knitting
comments
in
in
code
review,
because
it
makes
us
losing
time
both
for
the
reviewer
for
the
maintainer
and
the
developer,
and
maybe
just
consider
that
if
the
linter
doesn't
catch,
it
just
forget
about
it.
And
if
this
is
really
important
for
the
team,
then
updates
are
inter
to
add
these
rules
and
but
just
skip
everything
else
and
speed
up.
The
reduce
next
make.
D
F
You
so
we
are
to
improvement
items
on
our
team
and
we
have
this
undocumented
way
of
taking
over
somebody's
in
Mars
when
somebody's
on
vacation.
We
got
rid
of
that
because
that's
it's
proven
to
be
expensive
for
context
switching,
so
we
made
a
update
to
our
handbook
on
how
we
assign
and
takeover
work
so
no
more
context.
F
Switching
the
next
thing
is
we
also
our
bottleneck
in
review
as
well
and
I've,
create
an
issue
to
request
need
to
request
more
key
way:
maintenance,
because
the
quality
team
owns
the
knowledgebase
on
page
objects,
API,
client,
selenium
and
having
those
reviewed
by
other
teams
has
proven
to
slow
us
down,
and
also
we
do
have
enough
maintenance
on
our
team.
So
I'm
looking
forward
to
increase
the
QA
maintainer
on
our
side.
Honor,
you
Mike,
Corinne,
Rachel,
yeah,.
G
G
G
H
Cool,
so
just
in
in
response,
I
guess
to
some
of
the
prior
sort
of
capacity
challenges
we
faced
and
too
many
high-priority
items
being
assigned
to
a
single
engineer.
We've
reconsidered
how
we
work
on
prioritization
in
the
team
as
you'll
see
in
a
document
there's
a
link
to
the
prioritization
board
that
we're
now
using,
and
it's
very
much
a
case
of
kind
of
taking
the
the
highest
priority
issue.
H
Where
there's
a
couple
of
engineers,
you
have
five
plus
she's
still
assigned
to
learn,
and
hopefully
we
could
start
to
whittle
those
down
either
over
the
next
few
milestones
and
but
it'll
be
good
to
get
feedback
from
the
team
as
to
how
that
works
and
also
feedback
from
the
rest
actually
of
the
organization
and
community.
In
terms
of
what
that
board
looks
like
and
if
there's
any
ways
we
can
improve
that
and
a
specific
shout
out
and
a
thank
you
to
Jeremy
on
the
product
side,
who's
led
love,
the
effort
Ava
to
Dylan.
I
Yes,
so
one
of
the
things
we
want
to
improve
on
our
team
going
forward
is
being
able
to
have
metrics
into
usage
of
some
of
our
features.
I
mean
some
of
the
stuff.
It
looks
like
we
already
have
usage
data
on
some
of
the
important
things
that
might
affect
decisions
we
make.
We
don't
have
usage
on
it,
someone
hard
to
track,
but
which
is
ideally
understanding
when
and
why
people
are
not
using
our
DevOps
template
versus
taking
our
word
and
their
works,
template
and
forking
it
into
their
repo
and
editing
it
themselves.
I
J
All
right,
thank
you,
so
for
the
monitor
team,
the
two
sort
of
major
things
that
we
identified,
which
are
related,
is
that
we
really
do
need
to
work
on
having
smaller,
more
frequent,
mr,
so
that
we
don't
end
up
with
our
entire
deliverable
being
sort
of
all
or
nothing
at
the
very
end
of
the
cycle,
so
that
is
already
in
okay,
our
effort
for
our
team
and
so
that
you
know
we're
good
work
on
improving
that.
The
other
point
is
just
working
on
improving
our
process
for
working
with
maintainer
x'
reviewers.
J
E
I
did
actually
have
a
question
on
that
because
you
said
it
might
be
better
to
have
one
reviewer
and
one
maintainer
go
through
all
of
it,
rather
than
passing
it
off
to
multiple
maintain
yes
and
I'm,
not
sure
if
you
men,
multiple
back-end,
maintainer
Zoar,
like
multiple
maintain,
is
in
the
sense
that
there's
a
front-end,
maintainer
vacuum
maintained
or
database
maintained
or
whatever
I
would
say
the
second
one.
Then
the
idea
is
just
split
the
MS
up,
so
a
back-end
and
front-end
maintainer.
Don't
both
need
to
look
at
the
same
Emma
I'm,
not
sure.
J
E
J
E
So
again
for
friend,
arrow
and
James
Ramsey,
this
is
this
is
basically
the
same
thing
as
before.
It's
got
the
same
issue
as
before,
but
the
concrete
recommendation
here
is
to
involve
at
least
two
people
from
another
team.
So
if
plan
are
doing
something
that
involves
managed,
we
should
involve
at
least
two
people
from
managed
in
the
discussion
to
make
sure
that
we
don't
accidentally
just
like
ask
one
person
in
manage
who
thinks
something.
E
L
Thanks,
so
one
thing
we
know
we
need
to
do
is
start
breaking
down
product
discovery
issues
more
aggressively.
They
can
and
should
take
a
while.
They
tend
to
look
at
a
big
area
and
break
down
it,
the
first
step
into
an
MVC.
So
we,
if
we
don't
want
to
rush
things
by
trying
to
do
too
much
so
iteration
is
key
here.
L
We
really
need
to
reach
out
to
each
other
more
actively
for
feedback
and
ideas
on
things
who
are
working
on
so
we've
already
talked
about
this
in
our
weekly
UX
call
make
sure
that
we're
doing
it
in
slack
in
meetings
and
even
in
our
call,
as
maybe
more
formalized
design
reviews
and
along
with
that,
we
need
to
make
sure
that
we're
prioritizing
our
design
system
issues
alongside
group
deliverables.
So
each
UX
R
is
responsible
for
at
least
one
design
system
issue
per
milestone,
and
we
want
to
make
sure
that
they
maintain
that.
A
So
this
is
typically
the
point
in
the
poll
where
what
we
have
been
doing
is
identifying
issues
to
work
on
at
champions
to
make
that
happen
for
the
next
retrospective.
In
this
case,
given
the
nature
of
the
team
retrospective,
most
of
these
items
already
have
issues
that
are
actively
being
worked.
So
what
I'm
going
to
do
is
collect
those
all
with
either
a
label
or
an
epic.
A
Suspected
and
as
I
mentioned
at
the
start
of
the
call
I'm
going
to
work
with
the
engineering
managers
to
figure
out
how
we
can
better
collect
our
various
team
retrospective
notes
into
this
broader
gitlab
retrospective,
in
a
way
that
is
not
going
to
have
us
pressed
right
up
to
the
end
of
the
30
minutes
that
is
scheduled,
but
we
made
it.
I
want
to
thank
everybody
for
contributing
I.
Think
there's
a
lot
of
great
stuff
here.
I'm
excited
to
see
the
output
of
a
lot
of
these
issues
and
yeah
we'll
see
everybody
again
after
11.5.