►
From YouTube: GitLab Retrospective 12.1
Description
GitLab Retrospective 12.1
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
Good
morning,
gitlab
good
afternoon
and
good
evening
for
all
the
folks
who
are
in
different
time
zones,
this
is
the
12:1
retrospective.
We
are
going
to
quickly
cover
the
first
three
sections
and
then
leave
as
much
time
as
we
can
for
the
fourth
section,
where
we
talk
about
improvements
for
those
who
are
new
to
this
process.
You'll
hear
me
talk
very
quickly
for
through
the
first
parts,
and
then
we
will
have
a
discussion
for
the
last
fourth
section,
previous
retrospective
improvement
tasks.
Just
at
a
high
level.
A
Those
are
basically
around
two
things
from
the
last
retrospective
that
we
want
to
focus
on
the
first
one
was
improving.
Our
access
requests
essentially
were
stalled
in
getting
a
both
Devon
staging
for
new
developers
in
place.
We
talked
with
the
IT
ops
team.
They
determined
that
they
were
short
on
staff
and,
as
such,
asked
the
security
team
basically
to
come
back
in
and
help
with
those
access
requests
so
that
we
can
get
them
resolved
more
quickly.
That
is
true
is
effectively
closed.
A
This
I
will
have
to
look
into
whether
we
actually
start
tracking
those
at
the
dashboard
level,
which
I
think
would
probably
be
a
good
idea
from
that
aspect
of
it
today,
I
assigned
it
to
create
guns,
essentially
one
of
our
engineering
managers
here
in
the
development
team,
to
look
into
actually
getting
some
folks
signed
up
so
that
we
can
have
some
additional
DB
maintainer
Xandra
viewers
in
place
moving
forward.
That's
the
update
on
action
items
moving
to
where
things
have
gone
well.
A
This
month
really
is
seeing
some
really
good
collaboration
across
several
teams
as
showing
the
de
aspect
that
we
were
expanding
out,
but
we
seem
to
be
still
working
effectively
around
various
teams,
especially
across
functionally
as
well,
which
is
recognized
by
our
quality
team.
We've
had
good
success
with
our
rails.
Upgrade
really
excited
about
that
to
see
us
getting
to
the
latest
version
of
rails
and
obviously
six
six
o
will
be
out
soon.
A
So
getting
us
on
a
regular
cadence
associate
that
is
super
important
as
well,
also
on
communication,
lots
of
blog
posts
from
the
US
Department.
Thank
you
for
all
those
and
the
Secours
team
is
actually
starting
to
do
development
logs,
which
is
kind
of
a
neat
feature
in
regards
to
the
fact
of
being
able
to
get
the
most
up-to-date
status
on.
What's
going
on
on
a
given
issue
in
the
area
forming
a
memory
team
just
formed
in
the
last
month
and
a
half
and
it's
good
to
see
them
making
good
progress.
A
This
is
their
first
full
milestone.
So
you
see
some
good
feedback
about
learnings
based
on
that
and
then
also
sitting
high
standards
within
that
team
itself.
And
then,
last
but
not
least,
we've
had
an
influx
of
lots
of
new
talent.
It's
exciting
and
invigorating
we're
seeing
the
new
members
actually
contribute
and
a
couple
teams
have
kind
of
pointed
that
out
how
they've
been
able
to
get
them
up
to
speed
and
moving
to
contribute.
A
What
went
wrong
this
month
could
call
out
around
technical
debt.
Basically,
we
have
a
number
of
issues
around
technical
data
where
it
seems
like
we've
got
some
crusty
parts
of
the
code
that
we
need
to
go
basically
address
trying
to
determine
how
best
to
address
this
from
an
issue
perspective.
So
if
anybody
has
any
suggestions
around
this
I
think
it's
good
to
kind
of
go
back
here
and
kind
of
look
at
those
aspects
associated
with
it.
A
There
is
a
theme
that
appears
with
customer
assistance,
I
think
this
one
and
then
also
I,
think
it
was
later
said.
It
lead
in
the
planning
where
we're
seeing
a
little
bit
of
changing
in
priority.
Obviously,
a
customers
are
important
to
us
and
we
need
to
keep
moving
forward
with
customers.
So
it's
it's
a
part
of
the
job,
but
you
know
death
definitely
needs
that
we're
having
to
shift
priorities
kind
of
at
the
last
minute
and
that
was
causing
some
frustration
with.
A
A
Basically,
two
members
of
the
memory
team
obviously
have
mostly
new
members,
had
some
challenges
with
getting
their
laptops
on
time.
I
know
that
onboarding
team
is
working
on
addressing
this,
but
it's
appears
that
we
still
have
a
few
folks
that
are
still
still
being
delayed
and
getting
their
laptops
up
either.
A
Starting
from
there
and
I
impressed
myself
I
only
five
minutes
ago,
what
I
thought
was
going
to
take
10,
so
I'm
talking
super
fast,
we've
gone
to
the
areas
where
we
have
how
we
can
improve
when
we
move
into
the
area
where
actually
you're
from
other
folks
in
the
organization
so
Shawn,
it's
grown.
The
call
I'd
love
for
you
to
talk
about
planning,
yeah.
B
We
tend
to
have
things
in
progress,
so
this
this
sort
of
feeds
into
a
couple
of
things
it
feeds
into
cycle
time,
but
also
we
emphasize
last
year,
predictability.
So,
like
you
know
some
issues
might
take
longer
because
of
that,
because
of
like
getting
bumped
down
a
priority
list
or
because,
like
you
know,
they
take
a
long
time
in
review
or
whatever
and
with
the
database
reviews
that
we
mentioned
earlier.
But
what
this
means
is
because
the
plan
team
at
the
moment
is
just
one
team
and
it's
ten
people.
B
There
is
like
a
huge
amount
of
work
that
is
in
flight,
a
one
time
which
makes
it
quite
hard
to
figure
out
like
where
we
are
in
terms
of
like
once
we
get
your
boundary
of
a
milestone,
so
I
had
a
hem.
This
applies
not
just
to
me,
but
also
I,
think
to
Donald.
So
Donald
speak
up.
If
you
want
to
add
anything
here
on
the
front
cent
side,
I
think
at
the
moment.
B
The
main
thing
we
are
thinking
about
is
just
like
how
we,
how
we
categorize
this
and
how
we
manage
this,
like
it's
often
not
with
issues
where
the
scope
is
particularly
big.
It's
just
often
with
the
cycle
time
and
with
having
it
cut
off.
Ideally,
for
me
personally,
like
the
more
we
can
get
towards
a
Kanban
style.
Like
you
know,
list
of
work,
we
pick
things
off
the
top
the
less
these
boundaries
matter
as
well
and
the
less
we
have
to
care
about
those
and
the
more.
B
We
can
care
about
sort
of
overall
cycle
time
without
having
to
look
at
things
as
a
snapshot
necessarily
but
yeah
it
was
it
was.
It
was
challenging
trying
to
figure
out
like
how
much
of
this
work
that
is
in
flight
is
going
to
how
much
work
does
this
represent
in
the
next
milestone.
So
how
much
does
that
impact?
The
new
work
that
we
take
on
in
the
milestone
essentially
was
the
problem.
There
sorry
I
took
quite
a
long
time
there,
because
you
went
through
the
first
part
so
quickly,
but
yeah.
That's
basically
it.
B
So
yeah,
the
other
thing
is
that
we
haven't
had
that
full
time,
product
manager
on
plan-
and
we
do
now
and
hopefully
we'll
have
more
than
one
soon
as
well.
I
think
so.
That's
gonna
help
a
lot
as
well,
because
you
know
that
we
can
sort
of
distribute
that
work
better
and
we
can
do.
We
can
keep
track
of
things
better
as
they
happen,
rather
than
sort
of
like
you
know,
suddenly
find
them
at
the
time.
So
from
the
comments
they
you
know,
I
see.
Elliott
also
mention
this
four
verify
for
context.
B
Switching
but
yeah
for
plan
I'm,
mostly
treating
it
as
a
thing
that
we
are
gonna
like
work
on
actively
improving
like
as
a
group
at
first
and
then,
if
other
people
have
similar
issues
like
I've
already
taught
some
people
in
the
dev
section
about
this.
We
can
see
if
there's
some
commonalities
but
I'm
not
at
the
stage
yet
where
I've
got
any
idea,
what
what
a
specific
solution
would
be
for
us
right
now.
A
A
C
Yeah,
we
noticed
a
small
problem
while
working
on
issue
related
to
uploads,
and
we
note
said
that
we
didn't
really
pass
really
well
on
object,
storage
and
that's
something
that
we
we
support
on
get
lad.
So
we
quickly
fix
at
that
and
then
afterwards
it
we
saw
like
a
error
in
area
of
improvement
that
we
could
send
a
request
to
documentation
so
that
we
can
document
things
to
think
about
when
it
cannot
change
to
get
lab.
C
So
it's
very
common
should
send
a
change,
and
sometimes
you
just
forget
about
some
integration
or
some
related
feature,
and
sometimes
you
actually
don't
know
and
the
reviewer
just
forgets
about
it
and
the
maintainer
as
well.
So
that's
kind
of
a
problem,
and
it
would
be
interesting
to
have
like
a
separate
guide
for
developers
to
to
read
through
and
understand
a
little
bit
better
integrations
that
they
might
be
affecting.
So
we
have
a
section
on
that
today.
A
D
Basically,
we
have
some
documentation
on
how
to
set
up
the
reporter
and
the
especially
the
new
engineers
have
been
improving
that
with
this
time,
but
I
still
not
great,
especially
for
maybe
not
non-techie
people
and
the
world
in
special
needs,
updating
and
in
the
future
as
well.
We
may
need
to
set
up
something
similar
to
DD
carriers
and
makes
it
easier
to
actually
set
up
the
whole
app
because
there's
quite
a
few
steps
basically
involved
in
the
in
the
process
so
yeah.
We
have
that
issue
to
track,
and
then
we
have
another.
F
Yeah
so
I
mean
the
memory
teams.
A
bit
of
a
unicorn
right
I
mean
we're
a
newly
formed
team.
We
didn't
have,
we
don't
have
a
dedicated
product
manager.
At
the
moment
we
didn't
really
have
a
roadmap
to
pick
up
the
release,
schedule
change.
While
we
were
forming
as
a
team
so
we're
you
know,
there's
a
lot
going
on
and
we're
trying
to
I
guess
codify
our
own
process
and
we
have
borrowed
documentation
from
a
bunch
of
other
teams.
F
Distribution,
create
plans,
so
appreciate
all
the
existing
documentation
out
there
and
we
are
coming
together
as
a
team
and
just
continuing
to
iterate
and
improve
on
our
planning
process.
I
mean
12-2
was
better
than
12
1
and
12.
3
will
be
even
better
and
I'm
really
keen
to
hear
about
how
some
of
the
Kanban
experiments
are
going
on
with
other
teams
internally.
So
that's
our
goal.
G
Just
quickly
similar
to
some
other
teams
we're
in
the
configure
stage,
we
experimenting
with
using
workflow
based
boards
to
have
better
visibility
and
prioritization
of
our
issues.
We
are
actually
also
considering
adding
in
the
planning
Feder
phase
to
the
quarters
well
to
conform
to
the
product
development
workflow.
We
were
busy
discussing
it.
We've
had
about
one
or
two
team
discussions
about
it
and
most
people
on
board.
If
it's
likely
going
to
try
it
out
for
12.2
and
and
refine
as
we
go.
A
Excellent,
it
looks
like
monitors
doing
the
same
thing:
that's
great
to
Z
teams
dogfooding
the
product
by
using
this,
because
it's
a
great
way
to
track
work
and
could
understand
the
state
of
affairs
in
a
given
a
given
area
the
product
so
really
appreciate
y'all
spending
time.
Looking
at
those
types
of
improvements,
excellent
mech,
you.
H
Want
to
talk
to
the
end
and
test
cats.
Sure
thank
you.
So
we
have
in
this
is
in
line
with
prioritization
and
visibility
as
well
and
the
history
of
hit
lab.
We
used
to
have
a
lot
of
issues
in
every
projects
in
regards
to
end-to-end
test
gaps,
and
it's
been
hard
for
us
to
visualize
the
whole
picture
and
then
prioritize.
So
we
have
started
to
migrate
everything
over
to
one
single
repo
and
docked
with
our
product
as
a
test
case
managed
system
as
we
go
forward
and
going
for.
H
A
Thanks
I'll
go
Henry,
the
next
one
darvis
is
not
present,
but
it
looks
like
create,
is
looking
at
improving
by
using
a
shirt,
calendar
or
schedule
around
their
sprint
planning.
So
they
can
better
coordinate,
associate
with
the
teams
and
I'll
follow
up
with
our
afterwards
to
see
how
we
best
track
that
or
if
that's
fast
enough,
that
we
don't
even
need
to
add
a
tracking
associated
with
that
and
then
a
drill
to
want
to
update
us
for
work.
Whoa,
yeah.
I
So
we've
had
a
desire
to
kind
of
iterate
on
our
UX
artifacts.
The
biggest
desire
that
came
out
of
our
retro
was
to
see
more
visibility
into
the
UX
design
process
as
a
whole.
First,
we're
gonna
discuss
kind
of
promoting
velocity
through
lo-fi
designs,
but
through
conversations
with
the
UX
team,
it
turns
out
that
has
really
less
of
an
impact
on
velocity
and
the
fidelity
of
mock-ups
doesn't
really
impact
that
as
much
as
you
know,
fidelity
is
more
a
tool
to
use
when
you
know
things
are
unclear
uncertain.
I
So
we
discussed
instead
just
posting
mock-up
stations
more
frequently
throughout
the
design
process,
so
that
we
can
have
more
feedback
and
collaboration
throughout,
even
if
the
design
is
not
yet
fully
complete.
We've
also
had
some
conversations
around
marking
issues
ready
for
development
when
we
have
about
seventy
percent
confidence
or
so
that
we're
where
we
want
to
be
design
wise,
so
we're
iterating
on
that
process
and
that
we
I'm
sure
more
to
come
as
we
as
we
test
it
out
and.
E
A
J
The
what
that
is,
that
feedback
has
been
heard.
One
of
the
things
we
started
experimenting
with
this
week
is
a
section
wide
weekly
call
in
order
to
do
announcements
that
are
of
importance
for
everyone,
as
opposed
to
just
on
one
individual
team
and
then
treating
our
weekly
team
calls
as
breakout
sessions
from
that
where
we
can
get
specific
to
what
is
the
subject
areas
of
that
individual
teams
themselves?
This
has
been
the
first
agent.
J
The
first
iteration
of
this
has
been
good
in
that
it's
led
to
people
feeling
like
they're
having
spend
less
time
in
meetings,
and
it's
allowed
us
to
really
focus
our
conversation
according
to
the
people
that
are
most
impacted
by
these
by
the
subjects
at
hand.
So
it's
a.
It
was
a
good
first
iteration
on
it
and
it
was.
It
was
good
feedback
to
get
so
that
we
can
make
be.
B
Thomas
I'm
excited
to
hear,
what's
working
well
and
what's
not
working
though
well
there,
so
we're
going
through
the
same
thing
next
month,
basically
in
plan
that
the
intent
that
we
had
was
to
not
split
the
meetings
initially,
but
split
them
if
we
felt
like
so
like
start
from
the
opposite
ends,
like
start
with
just
keeping
the
meeting
across
plan
and
then
split
when
we
feel
like
we
should
split
and
see
how
that
goes.
Do
you
think
that
would
have
you
know
based
on
your
experience?
B
J
It
allows
us
to
give
specific
and
the
subject
areas
that
were
having
to
cover
for
us
like
static
analysis.
We
can
get
into
that
and
that's
not
as
a
reward
of
the
software
in
the
software
composition,
analysis,
team
and
they
can
get
specific
in
their
subject
areas
as
well
and
have
broader
conversations
about
the
issues
they're
trying
to
tackle.
So
honestly,
I
think
the
split
is
important,
but
as
a
breakout
from
the
section
wide
call,
so
that
that's
I
think
that
I
think
we
I
think
we
found
the
right
cadence
with
this
cool.
B
J
A
Thanks
Sean,
if
you
find
it
using
that
strategy
as
effective,
we
should
probably
update
our
documentation
around
best
practice
and
team
splits
to
reflect
that.
But
what
to
review
the
documentation
there
as
well
in
the
process
cool
next
one
I
have
in
the
list
is
Luke.
He
worked
on
a
number
of
issues
that
represent
both
front
and
back-end
work.
These
issues
really
important
in
order
to
catch
all
there's
the
discussion.
A
It
means
I
can't
independently
track
the
backend
progress
on
the
issue
board,
so
he's
a
recognizing
that
there's
some
challenges
there
associated
with
that
aspect
and
not
to
follow
up
with
the
create
team
to
see.
If
there's
any
way,
we
can
better
track
that
associated
a
bit
of
feedback,
and
then
Elliot
also
is
not
present.
He
was
talking
about
the
fact
that
the
current
workflow
for
taking
over
a
community
contribution
was
actually
pretty
cumbersome.
A
H
Thank
you,
sir.
So
we
need
to
migrate.
The
teams
to
the
new
labels
ASAP
because
it
will
be
blocking
traj,
will
close
and
will
affect
our
metrics
flowing
up
to
the
dashboards.
So
the
progress
is
going
right
now
and
everybody
should
be
notified
via
email
and
we
can
review
it
slack
as
well
going
towards
the
next
one.
We
have
it
in
fact,
few
key
items
regarding
reducing
the
CI
pipeline
jobs
and
review
apps.
A
Thanks
Beck,
so
key
improvements
for
the
next
release
or
subsequent
to
the
next
release.
I'll
say
these
are
the
ones
that
I
felt
like
from
reviewing
the
retrospective
notes
kind
of
jumped
out
at
me,
the
first
one
was
around
just
improving
our
installation
of
the
customer
polar
portal.
The
second
one
was
adopting
the
community
contribution,
making
it
less
cumbersome.
So
that's
the
basically
the
community
contribution
the
title.
A
Merge
request
from
a
fork
from
that
perspective
and
then
improving
our
review,
app
success
rate
and
then
rollout
of
the
new
plan
of
labeling,
so
that
we
can
appropriately
keep
our
metrics,
measured
and
responsive
and
the
last
one
is
just
a
follow-up
from
last
last
month
to
basically
revisit
whether
we're
increasing
our
PV
maintainer
stand
signed
Craig,
so
that
we
can
try
that
effectively
and
Thank
You
Craig
for
taking
that
on.
Are
there
any
other
issues
that
we
should
track
at
a
high
level?
Farmers
perspective.