►
From YouTube: Secure 13.4 retro conversation - EMEA and NA
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
so
welcome,
so
this
is
our
sync
session
for
thirteen
four,
our
second
of
two
synchronous
sessions
for
the
thirteen
floors
retrospective.
A
The
way
I
like
to
begin,
these
conversations
is
to
make
sure
that
we're
all
coming
with
the
same
perspective
and
the
and
the
way
that
I've
learned
to
do
this
over
the
years
is
to
make
sure
is,
is
to
recite
what
is
referred
to
as
the
retrospective
prime
directive,
which
states,
regardless
of
what
we
discover.
We
understand
and
truly
believe
that
everyone
did
the
best
job
they
could
given
what
they
knew
at
the
time,
their
skills
and
abilities
the
resources
available
and
the
situation
at
hand
at
the
end
of
a
project.
A
Everyone
knows
so
much
more.
Naturally,
we
will
discover
decisions
and
actions
we
wish
we
could
do
over.
This
is
wisdom
to
be
celebrated,
not
judgment
to
be
used
to
embarrass
so
with
that
shared
understanding
of
what
we're
doing
here
in
this
conversation
and
with
everybody,
with
everyone
being
willing
to
share
their
thoughts,
I'm
going
to
share
my
screen
and
we'll
go
in
vote
order.
Just
like
we've
been
doing
the
past
several
of
these
and
let's
see
where
the
conversation
leads
us.
A
Okay,
our
top
vote
getter
came
from
chan
and
it's
about
who
should
be
our
first
reviewers
and
so
is
chandy.
Did
he
make
it?
A
Oh
okay,
I
will
vocalize
for
him.
So
so
we
use
reviewer
roulette,
particularly
especially,
we
use
reviewer
roulette
a
lot
when
we're
up
in
the
in
the
main
rails
code
base,
and
so
this
was
a
suggestion
that
instead
of
signing
someone
just
blindly
using
that
tool
as
first
reviewer
to
start
with
someone
that
is
within
the
secure
sub
department,
has
a
number
of
benefits
so
like
particularly
that
person
is
going
to
have
some
domain
knowledge
about
the
types
of
features.
We're
trying
to
build.
A
B
Scroll,
I
guess
I'll
start
by
vocalizing
my
comment
that
we
could
consider
if
we're
manually,
picking
to
to
look
at
the
trainee
maintainers
that
are
within
our
stages
as
the
first
go-to.
If
you
don't
have
someone
in.
A
A
C
And
just
to
add
on
that,
because
I
just
discovered
that
this
morning
with
the
channel
because
she's
in
a
maintainer
program
and
the
q
department
improved
their
euro
release
and
now
they
can
have
more
review
being
assigned
to
them
by
adding
a
small
blue
dot
at
the
end
of
their
name
or
and
just
status
on
gitlab.
So
it's
working
better
right
now,
so
they
get
a
lot
more
reviews
assigned
to
them
by
the
roulette.
D
A
Does
this
have
the
collaboration
benefits
that
we
that
we
think
it
would
do
you
think?
Do
you
agree
with
that
assertion?.
C
A
A
Okay,
we're
being
quiet
on
this
one,
so
I'll
I'll
go
ahead
and
close
that
and
I'll
move
on
to
the
next
one.
A
All
right,
vocator
number
two
came
from
zack.
This
was
about
prematurely
resolving
discussions
on
merge
requests
where
we'll
have
some
some
memoirs
that
will
linger
open
for
for
a
while,
and
there
are
questions
that
seem
to
remain
open
for
that
can
remain
open
for
too
long.
A
So
there
are
some
suggestions
on
how
we
can
improve
this.
As
far
as
if
it's
been
open
for
more
than
one
to
two
days,
then
perhaps
paying
the
reviewer,
mr,
maybe
on
slack
and
then
work
to
reassigning
to
someone
else
and
there's
a
fair
amount
of
discussions
already
here.
But
this
is
an
area
marked
where
we
can
improve.
E
That
I
think
one
of
the
takeaways
that
it's
totally
fine
to
picking
someone
on
slack
if
they're
not
responsive
on
in
gitlab
itself,
and
so
in
that
particular
case,
the
story
was
that.
E
Well
more
than
a
couple
actually
and
zack
didn't
get
answers
for
me.
I
was
without
knowing
it.
I
was
blocking
the
the
match
request
and
I
realized
that
when
all
when
notified
about
all
the
discussion
be
being
resolved-
and
this
is
when
I
remember
that
I
was
involved
in
the
discussions,
because
that
was
kind
of
funny-
the
way
I
I
was
notified
after
the
fact-
and
so
that's
that's
interesting,
because
it's
one
particular
story,
but
there
are
other
ways
we
can
get
there.
E
Other
scenarios
and
again
one
one
takeaway
for
me-
is
that
it's
there
there's.
No.
How
should
I
put
that
over
communication
doesn't
exist?
If
there
is
the
the
reviewer
doesn't
respond,
then
I
try
try
to
ping
them
and
ping
them
using
the
add
mention
in
the
in
the
magic
quest.
I'm
I
get
to
do
it
so
it's
it's.
It
makes
for
better
visibility
and
being
on
slack
too,
and
it's
fine
to
do
both
actually
and
then,
if
it's
not
enough,
it's
to
my
opinion.
E
It's
fine
to
to
move
on
to
someone
else,
some
other
reviewer,
but
it
might
in
the
end
it
might
delay
your
your
magic
wise.
So
it's
it's
not
an
idea
solution
either.
So,
yes,
that's
it
all.
For.
E
Me,
oh
yeah,
one
one
thing
about
one
more
thing:
sorry
about
reassigning
to
someone
else
or
with
you:
it's
fine!
If
you
do
that,
if
you
ping
the
initial
reviewer
and
explain
why
you
had
to
do
this,
we
certainly
don't
want
to
do
that
without
notifying
the
initial
reviewer.
That
would
be
that
wouldn't
be
a
great
experience
for
their
viewer,
in
my
opinion,
and
better
to
be
explicit
better
to
ping
and
to
comment
on
what
we.
A
A
I'm
having
a
reaction
to
this
to
this
this
thread
and
I'm
not
talking
about
this
commentary,
but
this
thread
within
the
with
within
the
retro
that
I'm
going
to
share,
which
is
risking
becoming
overly
prescriptive,
and
I
know
it,
and
so
apologies
for
that.
But.
A
The
way
we're
interacting
on
mr
is
that
we're
globally
distributed,
and
it
is,
it
is
hard.
It
is
really
really
hard
to
know
who
is
available
when
and
based
upon,
because
there
there's
no
guarantee
that
anyone
is
working
when
you
are
and
there's
no
way
to
there's
no
easy
way
to
know
how
loaded
that
individual
is
with
merge,
requests
that
they're
currently
reviewing
or
working
upon
either,
but
we're
risking
us
trying
to
optimize
for
individual
preferences
at
the
expense
of
a
standard
that
we're
expecting
our
all
of
our
teammates
to
to
be
beholden.
A
To
at
what
level
do
we
have
expectations
that
are
just
part
of
the
job
versus
having
to
optimize
for
the
individual?
You
are
happen
to
be
interacting
with,
and
apologies,
if
that
is
for
how
poorly
worded
that
is.
F
No,
it
makes
sense
cuz
I
mean
I
have
noticed
it's
very
obvious
that,
like
like,
since
mark
became
a
maintainer
for
our
team,
we've
been
leveraging
that
a
lot
and
it's
been
very
productive
and
efficient,
because
in
is
personally
how
it
works
is
feedback
is
very
detailed.
He
gives
suggestions
in
terms
of
what
should
be
changed.
Patch
requests
and
the
reviews
are
very
quickly
and
I've
leaned
on
that.
F
A
lot
to
get
my
stuff
through,
as
opposed
to
relying
on
other
maintainers
outside
of
the
team,
because
that
review
cycle
is
way
longer,
and
you
know
they
prioritize
other,
mrs,
what
they
get
globally.
My
concern
is
that
we
rely
on
that
too
much.
We
get
kind
of
like
this
tunnel
vision
of
just
getting
accustomed
to
that.
What
happens
when
he
takes
paid
time
off
you
know,
and
then
we
have
to
rely
on
other
maintainers
and
then
our
workflow.
F
Our
estimation
for
complexity,
like
I
factor
in
review
time
right
that
gets
all
thrown
out
of
whack,
because
now
we've
been
relying
on
a
set
workflow.
So
that's
why
I've
been
kind
of
advocating
for
maybe
when
domain
knowledge
is
very
expected
and
you've
been
working
on
a
multi-part
mr
issue
with
multiple,
mrs.
It
makes
sense
to
stay
with
that
maintainer
within
the
team,
but
we
should
really
try
not
to
rely
on
that,
because
we
exactly
what
you
said
thomas.
F
It's
like
we're
kind
to
optimize
for
the
individual
and
not
we're
deviating
a
little
from
the
standard
workflow.
So
it
is
a
balance.
I
don't
know
what
the
correct
determination
of
like
how
we
should
balance
that
out,
but
something
to
keep
in
mind
not
to
get
in
that
habit,
and
you
know
to
be
fair.
I've
been
getting
into
that
habit.
So
that
doesn't
worry
me.
D
I
I
also
think
that
this
is.
This,
brings
up
the
old
discussion
of
standardizing
reviews
and
maintainers
for
the
skier
products,
which
we
still
haven't
done.
So
there's
like
a
lot
of
implicit
understanding
of
what
that
means
within
the
security
products
versus
the
rails
code
base
itself,
and
I
think
that
we
really
need
to
make
things
more
explicit,
explicit
there,
either
with
review.
Roulette
and
code
owners
and
other
things
that
would
align
are
the
repos
that
we
specifically
own
with
the
rest
of.
D
A
A
All
right
we
have
a
tie.
I
want
to
go
with
the
one
that
we
talked
about
last
night,
as
with
with
our
friends
over
in
apac.
A
We
have
one
front-end
team
that
is
a
shared
resource
for
all
of
our
analyzer
groups,
our
analyzer
teams
themselves,
all
the
back-end
teams
and
for
nato,
I'm
speaking
for
you
you're
here.
Do
you
want
to
vocalize
your
appointment,
or
would
you
like
me
to.
F
Yeah,
so
I
guess
to
get
some
context,
so
I've
predominantly
been
working.
Well,
I
guess
I
I
I'd
be
coming
off,
doing
license
compliance
and
move
over
to
sas
and
now
doing
fuzzing
work
and
I
think
the
experience
for
the
most
part
has
been
consistent.
But
there
are
some
pain
points
I
mean
I
guess
I'll
address
the
elephant
in
the
room,
maybe
because
it's
a
newer
team
and
we're
still
kind
of
getting
into
the
workflow
and
all
that
it's
been
a
little
bit
harder.
F
Fuzzing,
mostly
around
everything,
from
like
the
size
of
the
issues,
the
state
that
the
issues
are
when
we
get
them
for
planning
breakdown,
all
the
way
down
to
working
with
other
engineers
and
having
coordinating
front
and
back
end
like
we
coordinating
between
front
and
back
and
has
been
good
synchronous,
wise
doing
meetings,
and
we
all
know
what
we
need
to
do,
but
as
far
as
like
conveying
that
back
to
the
issue
and
keeping
the
issue
up
to
date
with
the
correct
workflow
labels,
implementation
plan
and
breakdown.
F
I
know
that's
a
lot
of
overhead
and
it
took
me
personally
many
months
to
get
into
that.
So
I
think
it's
just
kind
of
working
into
that,
but
I
didn't
want
to
bring
that
up
in
terms
of
that's
been
a
challenge
as
far
as
consistency
between
teams
like
if
it
was
working
with
one
team
and
we
had
a
consistent
way
of
being
inconsistent,
at
least
that's
some
type
of
consistency,
but
jumping
around
from
team
to
team.
F
It
doesn't
make
it
difficult
to
communicate
on
the
status
of
things,
so
I
just
wanna
I'm
willing
to
to
kind
of
work
with
everyone
else,
to
kind
of
standardize
that
or
maybe
educate
or
kind
of
be
like
hey.
F
This
is
what
other
teams
have
been
doing,
but
it
is
a
little
tough
when
you
know
as
an
org
we
have
like
each
team
seems
to
have
you
know
a
product
manager
front
end
and
back
end,
the
front
end,
engineering
manager
back
back
in
engineering
manager,
so
those
things
have
been
a
little
bit
tough
to
get
consistent.
F
Some
teams
are
more
organized
than
others,
so
I
don't
know
what
the
answer
is,
but
I
think
communication
would
help
with
that
and
if
you
want
actual
examples
I
could
I
could
provide
those
if
it
helps
this
data
points
to
kind
of
work
things
out,
but
they
want
to
go
on
a
rant,
but
on
the
bright
side,
when
challenges
have
come
up,
team
members
have
been
more
than
willing
to
accommodate
or
open
to
feedback.
It's
just
like
that
process
of
feedback
is
gonna.
Take
a
while,
I
think
so.
G
So
I
have
something
I
sorry
I
didn't
add
any
notes.
I've
just
been
working
on
a
bunch
of
other
stuff,
so
focus
on
the
retro.
It's
been
my
priority,
but
I
think
the
the
way
I'm
thinking
about
this
is
the
milestone.
Readiness
is
our
best
biggest
impact.
G
Is
it
are
we
set
up
to
effectively
execute
you
know
when
the
milestone
starts,
and
I
think
that's
where
we
realize
these
in
any
inconsistencies
and
any
flavor
that
they
might
be
is
where
it's
very
noticeable
so
yeah
do
we
have
work,
broken
down,
refined,
distributed
and
not
just
before
the
milestone
starts,
but
well
ahead
of
it.
So
we're
able
to
plan
out
capacity
things
like
that,
fernando
you
mentioned
yeah
having
the
ems
and
the
pm
sync
up.
We
do
do
a
lot
of
back
channel
type
of
conversations.
G
Absolutely
I
think
it's
enlightening
that
we
might
be
might
be
want
to
be
more
transparent
there.
So
thank
you
for
raising
that
because
I
think
that's
extremely
important
on
this
note
in
terms
of
milestone.
Readiness
front
end
has
a
goal:
an
okr.
G
This
quarter,
where
we're
striving
to
have
things
handed
off
to
the
team
members
two
weeks
before
the
milestone,
and
then
we
have
a
majority
of
everything,
refined
and
ready
to
go
at
the
start
of
the
milestone
and
that's
definitely
helping,
and
that's
where
that
that
transparency
helps
is
the
sooner.
We
know
about
this
information,
the
more
we
can
adapt
and
react
to
it,
and
that
includes
labeling
and
just
making
sure
everything
is
fit
and
finished
and
ready
to
go
so.
C
Someone
about
something
about
that.
I
just
had
a
comment
about
this.
I've
been
working
on
that
for
the
past
month
and
it's
it's
a
a
long
going
story,
but
advocating
for
a
statewide
workflow
was
practically
mean
to
address
that
kind
of
issues,
because
we
know
the
secret
team
is
shared
between
all
the
different
front
and
back
groups
back
in
teams
or
other
groups.
It's
it's
difficult
for
you
to
switch
from
one
to
another,
so
we
definitely
need
to
work
to
work
more
into
educating.
C
The
current
process
is
mean
to
have
a
quarterly
fixed
workflow,
and
once
we
roll
out
a
new
change,
we
go
through
a
training
so
that
every
team
member
on
the
secret
stage
can
understand
what
is
the
current
workflow
and
what
they
need
to
apply,
and
this
should
stay
like
this
for
the
next
quarter.
So
this
will
really
improve
the
consistency
across
all
groups
and
well.
It
was
supposed
to
be
rolled
out
in
august,
we're
still
waiting
for
first
of
all
little
changes
again.
C
It's
the
usage
of
epics
versus
sub
issues,
and
we
will
be
pretty
ready
for
running
out
the
first
draft
and
I
think
this
would
be
real
for
that
kind
of
problem.
F
D
F
We
tweaked
something
right
and
I'm
in
favor
of
just
kind
of
doing
it
at
the
quarterly
level,
where
we
kind
of
outline
out
a
proposal
like
try
some
things
out
for
the
next
quarter
and
then
refine
on
that
and
then
do
it
at
that
level.
It
seems
a
little
bit
more
sane
because
you
know
I
assume
it's
a
lot
of
overhead
to
do
the
training,
to
get
the
team
all
synced
up
and
to
update
the
docs.
F
So
at
the
quarry
level,
quarterly
level,
I
think,
seems
a
little
bit
more
reasonable,
but
I
think
it
has
been
getting
better
since
I've
gotten
here.
It
just
has
taken
time
to
get
used
to
it
or
whatever
workflow
we
end
up
going.
A
A
F
I
think
so
I
don't
think
I
guess
it's
like
all
right,
so
we
break
down
the
issues
as
you
described
right.
I
still
think
the
workflow
still
encompasses
things
like
the
labels
right,
because
now
you
have
these
issues
broken
down.
Sure
consist,
you
know,
just
broken
down
the
same
way
between
teams,
but
then
it's
like
we
still
need
to
adhere
to
the
processes
for
conveying
hey.
Like
is
this
issue
in
itself.
The
issue
itself
goes
through
a
life
cycle
right.
It's
like
you,
still
need
to
do.
F
Implementation
plan
and
planning
breakdown
is
part
like
in
that
issue
itself
and
the
communicating
isn't
in
development
is
it
being
merged?
And
then
what
about
the
cross-linking
right?
It's
like
is
this
issue
blocking
other
front-end
issues
like
that's
still
part
of
the
workflow
and
even
how
you
communicate.
That
can
be
different
because
we
have
this
habit
of
yeah.
We
have
in
the
ui
that
ui
lets
you
block
or
is
blocked
by,
but
then
also
different
teams
of
different
approaches
to
how
they
cross
link.
F
A
I'm
not
going
to
block
on
this
too
much,
so
I'm
burning
up
some
time,
I'm
gonna!
If
I
would
love
to
dig
into
this
a
little
bit
more,
probably
in
a
coffee
chat,
because
what
you're
describing
to
me
sounds
as,
if
is
not
a
need
for
further
alignment,
but
to
me
it's
supremes
that
were
too
tightly
coupled,
and
so
that's
so
I
my
instincts
are
to
go
the
opposite
direction
than
to
where
everybody
else
is
going.
A
So
I'm
trying
to
figure
out
what
I'm
missing,
and
so
that's
so
I'll
I'll
see
the
floor
with
that,
I'm
not
trying
to
block
it.
I
hear
that
this
is
a
problem,
I'm
just
more
trying
to
understand
why
our
instincts
are
to
go
for
alignment
as
opposed
to
more
loosely.
A
Coupled
but
sorry,
that's
me
and
I
think
I
might
have
just
killed
the
conversation
on
this
particular
area.
Is
there
anything
everybody?
Is
there
anything
else
on
this
topic
folks
would
like
to
vocalize
before
we
go
on
so
try
to
get
talk
about
one
more.
C
I
I
think,
you're
pointing
at
the
very
problem
here,
because
when
issues
are
correctly
broken
down
and
they
go
smoothly
independently,
there
is
no
problem,
the
prime
comes
when
things
are
tightly
coupled
together
and
there
is
needs
there
are
need
for
interactions
between
them
and
then
the
way
of
communicating
might
be
different
because
of
the
different
way
we
use.
The
the
native
features
are
the
convention
that
we
do
manually
because
we
don't
have
the
corresponding
native
feature
in
the
in
in
the
gitlab
project
management
system.
So
yeah.
C
C
A
All
right
I'll
want
to
dig
in
more
I'll
I'll,
look
for
some
time
and
put
something
on
secure
stage,
because
I
want
to
look
at.
I
would
like
to
look
at
this.
This
is
where
this
has
been
a
problem
and
see
if
we
can
as
I've.
I
still
there's
ways.
I
still
see
ways
that
we
can
decouple
things.
I
see
this
is
an
interface
problem,
but
that's
that's
that's
where
this
is.
This
is
my
mental
block,
and
I
know
it
and.
D
A
All
right:
let's
talk
about
one
more
item,
so
there
was
a
tie
at
one,
and
this
came
from
our
resident
multitasker,
mr
mccaslin,
about
the
weekly
sync
stand-ups.
First,
around
sas
config
ui
and
knowing
that
he's
taylor
d,
can
you
speak
to
this
or
are
you
in
the
other
world
yeah.
H
I
can't
so.
This
is
one
where
I
so
for
the
config
ui
project
we've
had
a
slack
channel
going
and
we
have
monday
stand-ups.
It
has
been
particularly
helpful
given
the
complexity
of
this
project.
H
It's
one
where,
every
week
we've
been
talking
about
blockers
the
status
of
the
project
where
we're
at
with
things
where
the
feature
flags
are
at,
and
I
don't
really
think
we
could
have
successfully
done
that
async.
So
this
is
one
where
I
think
I
don't.
I
don't
want
to
encourage
us
to
do
this
with
every
project,
but
when
you
have
something,
that's
really
meaty
that
has
a
lot
of
moving
parts
that
has
a
lot
of
misalignment.
H
B
Think
I
I
very
much
agree
with
what
what
taylor
said
was
very
helpful
and
it
is
you
know,
a
tool.
It's
you
know,
not
everything
is
a
nail,
so
we
don't
need
to
use
it
every
time,
but
it
was.
It
was
used
appropriately
in
this
case.
I
I
It
can
possibly
add
a
difficulty
if
we
with
regards
to
working
with
teammates
in
other
zones-
and
I
know
we've
had
issues
making
it
so
that
it's
hard
for
say,
aipac
to
join
in
the
conversation,
and
so
if,
as
long
as
we,
we
don't
see
everything
as
a
nail
like,
like
roth
just
said,
you
know,
and
we
use
it
for
like
the
really
meaty
things
that
we're
having
struggle
maybe
doing
asynchronously.
I
But
what
what
could
be
interesting
is
if
we
had
a
policy
of
a
sink
first
and
if
that's
true,
proving
difficult
to
nail
down
what
we're
doing
then
yeah.
I
think
that
it
can
be
great
as
a
forcing
function,
but
that's
just
my
perspective,
and
I
also
wasn't
a
part
of
this,
so
maybe
my
idea
would
be
different
or
my
feelings
would
be
different
if
I.
A
I
B
Yeah,
that's
that's
a
very
good
point
about
the
time
zones
because
we
were
able
to
to
come
up
with
a
time
that
worked
for
for
everyone
that
was
working
on
the
project.
Where
that's
you
know
not
always
going
to
be
possible
for
every
project,
but
the
the
slack
channel
was
also
very
helpful
for
for
the
collaboration
too.
B
I
Yeah,
I
really
like
the
pattern
of
more
specific
slack
channels
that
are,
you
know,
say
slightly
ephemeral,
but
a
little
bit
more
long-lived.
I
think
that's
that's
a
really
great
pattern
and
still
inclusive
across
time
zones.
A
F
I'll
I'll
keep
it
short,
so
I
know
I
brought
this
up
at
the
secure
stage
meeting.
I
think
yesterday,
yesterday
all
right
yeah
around
feature
flags.
So
that's
an
ongoing
discussion.
I
have
linkedin
there's
a
if
you
scroll
down,
I
have
a
a
link
to
the
or
is
it
up,
maybe
no
yeah.
There's
the
thumbs
up
thumbs
down.
So
I
guess
there's
this
kind
of
understanding
that
you
know
product
would
ideally
like
us
to
have
gitlab.com
self-managed
ship
in
the
same
milestone.
That
doesn't
always
happen.
F
So
I
think
the
issue,
the
goal
of
the
issue
that
I
linked
there
was
to
kind
of
follow
up
and
maybe
clarify
the
docs
workflow
and
what
should
happen
in
terms
of
communicating
if
that
doesn't
happen,
because
I
think
there
was
some
confusion
on
when
we
say
something's
gonna
be
ready
in
a
milestone.
F
Does
it
mean
for
self-managed
and
dot-com,
or
it
doesn't
mean
it
just
makes
it
into
gitlab.com
and
then
we'll
follow
up
with
self-managed
shortly
after
I
think,
we've
been
a
little
bit
inconsistent
with
that
and
there's
been
a
mismatch
with
what
product
expects
and
what
engineering
actually
delivers
at
least
from
front
end,
or
at
least
maybe
at
least
with
the
stuff
I've
worked
on.
So
I
just
wanted
to
call
that
out
and
that
I
will
follow
up
on,
but
I
just
wanted
to
surface
it
to
the
team.
That's
all
I
got
okay.