►
From YouTube: GitLab 13.5 Team Retrospective Summary
Description
Please join us for the Retrospective Discussion on Thursday November 4th, 2020 at 4PM UTC (9AM PT)
A
A
What
went
well
this
milestone,
what
did
not
go
well
and
what
can
we
improve
on
in
the
future,
starting
out
with
what
went
well
under
the
value
of
collaboration?
Neil
mccarson
from
the
secure
stage
said
that
their
emphasis
on
praise
for
13.5
was
overwhelmingly
positive.
They
had
praised
items
coming
from
engineers,
pm
and
ux.
It
was
really
fun
seeing
sharing
these
in
their
sync
sessions.
A
In
the
area
of
results,
valerie
carnes
from
the
ux
team
said
that
really
good
progress
was
made
on
improving
gitlab
performance
quality
and
velocity
by
making
the
get
lab
by
making
gitlab
development
pajamas.
First
about
30
of
the
view
component
migration
was
completed
as
part
of
the
q3
okr
product
designers
and
tech
writers
all
contributed
to
this
effort.
A
Positive
gains
in
the
area
of
efficiency
were
reported
by
john
hope,
who
said:
there's
been
less
back
and
forth
on
reviews
in
13.5
brett
from
the
project
management
team
noted
that
he
was
able
to
keep
mrs
unblocked
when
reviewing
by
approving.
If
the
request
change,
requested
change
was
small.
This
allowed
authors
to
make
the
change
and
press
on
with
the
review
process
and
in
diversity
and
inclusion
and
belonging
shenzhen
from
the
global
search
team
said.
It's
been
awesome
to
see
their
team
help
out.
Folks
who
ask
questions
in
their
team
channel.
A
It
creates
a
welcoming
atmosphere
and
encourages
others
to
feel
comfortable,
asking
questions
moving
on
to
the
feedback
about
what
did
not
go
as
well.
In
thirteen
five
under
the
area
of
results,
craig
gomes
said
from
the
database
team.
They
missed
an
edge
case
with
re-indexing,
which
caused
a
production
incident.
They
have
an
incident
review
coming
up
next
week
to
discuss
further
and
detailed
prevention
measures
going
forward.
A
It
sounds
like
they've
gotten
better,
however,
at
these
timing,
documentation
updates
great
moving
forward
feedback
and
efficiency
received
by
jean
from
the
create
static
site.
Editor
group
that,
during
the
last
milestone
a
team
member
attempted
to
slice
an
mr
vertically
but
and
it
ended
up
taking
a
very
long
time
to
get
through
all
of
the
reviews.
Apart
from
the
total
time
duration,
it
also
caused
the
team
member
to
have
to
constantly
switch
when
new
comments
were
received.
A
And
neil
mccarson
from
the
secure
stage
said
that
the
new
release
post
process
has
its
merits,
such
as
better
alignment
to
the
work
being
done,
but
it
is
also
created.
Overhead
they've
had
parallel
discussions,
making
it
difficult
to
know
the
single
source
of
truth
and
finally,
focusing
on
areas
where
we
want
to
make
improvements
going
forward
under
the
value
of
collaboration.
Craig's
known
craig
gnomes
from
the
memory
stage
said
that
the
memory
team
is
discussing
ways
to
make
retros
more
meaningful
and
actionable
instead
of
it
feeling
like
we're
failing
out
and
forgetting
about
it.
A
In
the
area
of
efficiency,
ricky
from
verified
testing
said
that
the
verified
testing
team
has
run
into
some
issues
around
not
having
documentation
expectations
marked
clearly
in
the
issue
ahead
of
time.
They're
resolving
to
be
more
attentive
to
that
section
in
the
issue
template
and
to
make
sure
that
if
an
issue
will
require
a
documentation,
update
that
it
is
marked
in
the
issue
description
clearly.
A
Cheryl
lee
from
verify
ci
said
that
a
ci
engineer
learned
that
it's
best
to
start
on
a
security,
mr
as
soon
as
possible
to
ensure
that
it
gets
released
on
time
after
realizing
that
some
back
ports
required
more
work
than
expected
and
also
did
not
know
the
exact
date
for
the
code.
Freezes
as
the
wording
around
that
saying.
All
mrs
associated
with
the
release
should
be
ready,
48
hours
before
the
security
release.
A
This
can
vary
depending
on
whether
it's
weekend
or
holiday
on
that
month
and
finally,
under
iteration,
shang
zen
from
global
search
said
that
they
have
done
a
lot
of
work
on
performance
improvements
of
search
and
have
started
to
work
on
more
ui
ux
performance.
But
they
will
still
be
keeping
an
eye
on
the
performance
issues
going
forward.
A
That
is
the
end
of
our
summary.
I
invite
you
to
participate
in
our
discussion,
which
is
thursday
november
4th
at
9
00
a.m.
Pacific
time
internal
git
lab
members
can
join
the
internal
zoom
link.
Everyone
else
can
follow
along
on
the
youtube
live
stream.
If
they'd,
like
we've,
got
two
items
to
discuss
during
that
call,
both
of
which
come
from
items
in
the
retrospective
document.
A
The
first
comes
from
craig
gnomes
from
the
memory
database
team,
who
is
interested
in
learning
from
attendees,
both
internal
to
get
lab
and
external,
if
possible,
if
they
find
this
retrospective
valuable
and
why
he's
gotten
feedback
that
sometimes
this
just
feels
like
a
checkbox
and
that
we
need
to
fill
it
out
monthly
that
sometimes
he
feels
that
way
himself.
Craig
is
curious
if
there
are
people
who
find
this
valuable,
and
why
are
there
people
who
do
not
find
this
valuable,
and
why
and
our
attendee's
only
doing
this,
because
it's
the
way
we've
always
done
it.
A
The
second
discussion
item
that
we'll
be
covering
during
the
call
is
coming
from
thomas
woodham
from
the
secure
stage
who
would
like
to
know
people's
input
on
how
we
can
ensure
that
differences
and
process
don't
make
it
more
difficult
to
collaborate
across
teams.
Secure
has
one
front-end
team
which
works
against
four
back-end
teams.
While
each
team
follows
the
product
development
workflow,
each
team's
interpretation
of
it
is
unique
enough
to
make
it
really
hard
for
team
members
who
have
assignments
spanning
multiple
teams
in
one
iteration.
A
These
are
both
great
topics
and
I
very
much
look
forward
to
hearing
people's
inputs
on
it.
If
you'd
like
to
contribute
to
the
discussion,
please
add
items
to
each
talking
each
topic
in
the
retrospective
document
and
you
can
verbalize
them
on
the
call.
Thank
you
very
much
for
your
time
and
we
will
talk
to
you
during
the
call
on
november
4th.