►
From YouTube: Secure 13.4 retro conversation - APAC
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
welcome
to
13
4
retrospective
conversation,
so
I,
as
I
typically
start,
these
type
of
conversations
off
something
that
I
have
learned
long
ago
is
that
we
should
always
come
in
with
the
same
set
of
expectations,
and
I've
learned
this
through
the
what
is
called
the
retrospective
prime
directive,
which
states,
regardless
of
what
we
discover.
A
We
understand
and
truly
believe
that
everyone
did
the
best
job
they
could
given
what
they
knew
at
the
time,
their
skills
and
abilities
their
resources
available
and
the
situation
at
hand
at
the
end
of
a
project.
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
used
to
embarrass.
B
A
So
he
is
noting
an
area
of
improvement
of
so
if
we
rely
on
reviewer
roulette
we're
going
to
get
some
we're
going
to
get
a
reviewer
randomly
within
gitlab,
particularly
if
we're
up
in
the
in
the
ruby
monolithic
project,
so
he's
making
a
suggestion
that
the
first
reviewer
that
we
assign
always
come
from
within
the
secure
stage
itself,
knowing
that
we've
got
that
it's
quicker
to
brief
them
in
on
domain,
not
with
because
they
have
the
main
knowledge
they
they've
they're,
probably
more
familiar
with
what
we're
working
on
and
it
can
increase
collaboration
between
different
parts
of
of
the
of
the
group
or
within
this
within
the
sub
department
itself.
B
I
I
strongly
agree
with
this.
I
think
that's
something
that
the
das
team
do
already
and
generally
especially
when
we're
working
on
the
python
code,
but
also,
I
tend
to
send
stuff
say,
I'm
working
on
the
graphql
endpoint
I'll,
send
it
to
another
dust
developer.
I'm
wondering
if
I
should
extend
what
I'm
doing,
because
I
normally
just
send
things
to
other
desks
other
people
in
death,
but
maybe
I
should
send
my
things
to
people
insecure,
not
just
when
I'm
working
on
when
I.
A
A
Trying
to
catch
up
with
notes
is
what
you're.
A
A
Out
of
sheer
curiosity
craig
and
to
put
you
on
the
spot,
apologies
for
that
is
the
stuff
you're
working
on.
Is
it
typically.
B
Not
necessarily
so
recently
I've
been
working
on
graphql
endpoints
for
on-demand
scan,
which
is
that
specific.
But
I
get
your
point
if
I
work
on
something
that's
more
generic,
it's
probably
useful
for
more
people
to
see
it.
B
C
It
just
makes
me
realize
that
there's
an
implicit
assumption
that
we
all
keep
up
to
date
with
the
rails
code
base
right.
C
C
Yeah
yeah,
but
so
yeah.
There
is
another
implicit
assumption
there
that
you're
understanding
what
we're
actually
the
features
that
we're
building
yeah
and
I
think
at
the
moment
that's
probably
possible
that
you
can
at
least
read
an
issue
even
if
you've
never
seen
it
before
and
understand
what
it
means,
but
it
may
get
harder
as
secure
gets
bigger
and
our
code
gets
bigger
and
a
product
becomes
more
complicated.
B
C
C
So
maybe
maybe
this
will
push
me
to
spend
more
time
investing
in
understanding
what
rails
is
up
to.
D
I
I
look
at
the
rails
code
base,
you
know
every
now
and
then
and
it
changes
quickly
so
many
times
I
write
notes
about
you
know
operations
and
how
to
get
something
working
and
then
I'll
go
and
try
and
do
it
two
weeks
later
and
it's
all
changed.
So
it
takes
a
lot
of
effort
to
you
know,
stay
up
to
date
because
yeah
it
changes
fast.
C
A
A
All
right
I'll
move
on
to
the
next
one.
Thank
you
for
your
commentary,
appreciate
it
next,
one
that
we
had
here
was
from
zach
on
another
area
for
potential
improvement,
where,
as
an
author
of
an
mrf,
that
we
have
the
ability
to
resolve
threats
or
resolve
to
resolve
discussions
within
the
mars
we're
putting
up
and.
A
He's
he's
experienced
the
situation
where,
with
the
where
the
mr,
that
he
was
working
on
where
discussion
threads
were
closed
prematurely
and
this
and
it's
and
it
would
and
it
was-
and
it
came
when
response
to
some
of
his
comments
and
discussions
were
where
was,
did
not
get.
A
Did
not
get
responded
to
quickly
and
so
he's
got
a
link
to
the
mr
questions.
Would
you
want
what
should
you
want
to
follow,
along
with
the
exact
specifics
of
this
of
this
item?
It's
the
way
that
this
was
handled
where
discussions
were
closed
prematurely,
they
were
and
they
were
closed
without.
B
A
Could
have
been
done,
it
could
have
been
done
better,
even
though
it
was
towards
the
end
of
the
milestone
and
he's
suggesting
that
we
put
a
cap
on
the
amount
of
time
that
we
wait.
Maybe
it's
one
to
two
days
and
then
also
at
that
time,
work
to
ping
the
reviewer
and
if
they
can't,
if
they're
still
not
responsive,
then
work
to
reassign
to
someone
else
of
the
same
backing
team,
if
possible,
and
so.
D
I
think
that
works
well,
I
mean
this
recently
came
up
where
fabian
was
asking
for
a
review,
but
it
was
you
know
friday
evening
for
me,
so
I
said
that
he
pinged
me
on
slack
first,
and
I
said
I
wasn't
gonna
be
able
to
do
that
until
monday,
and
then
he
reassigned
the
issues
to
to
mo,
because
mo
was
in
a
better
time
zone
to
take
care
of
it.
So
that
seemed
to
work
pretty
well.
C
I
mean
I
feel,
like
I've,
been
on
both
sides
of
this
situation,
where
I've
had
people
resolve
comments
that
I
didn't
think
were
resolved
and
I've
probably
done
the
same
to
other
people.
C
I
now
that
slo
we
have
two
days
is,
I
feel
like
it
depends
on
how
valuable
or
how
important
the
piece
of
work
you're
looking
at
is
like.
If
we
go
back
to
the
secure
glossary
that
thing
took
like
I
don't
know
three
months
or
something
there
was
no
way
those
issues
were
gonna
get
resolved
in
two
days
and
like
for
some
for
such
a
contentious
change.
C
A
I
struggle
with
a
dual
role:
if
I'm
cheering
it,
then
I
think
I'm
the
facilitator
rather
than
a
participant.
That's
why
I'm
asking
for
permission
if
y'all
are
not
comfortable
with
it?
I
am
happy
to
to
hold
my
my
remarks.
A
To
me,
this
speaks
to
a
both
a
limitation
and
a
saturation
of
a
push-based
workflow,
especially
in
a
geogra
and
a
worldwide
geographically
distributed
team.
When
we're
pushing
things
to
folks,
there
is
no
way
to
gauge
how
saturated
that
person
is
both
within
their
own
work
and
the
amount
of
merge
requests.
They
have
been
asked
to
review.
A
C
I
think
that
would
be
a
really
interesting
experiment
to
run
and
I'm
sure,
with
the
right
incentives.
People
would
pick
up
reviews.
I
don't
know
if
that
would
be
a
silver
bullet
bullet
to
this
problem,
though,.
A
It's
not
it's,
not
the
where
I
think
it's
more
applicable,
isn't
for
the
rails.
Maintainer.
B
A
I
would
argue
that
a
rails
maintainer
is
a
scarce
resource.
Sorry
management's
folks
management,
g's
flip
here
scarce
resource.
That
is
a
congested
resource
because
there's
a
lot
of
people
trying
to
get
changes
through
a
very
small
group
of
people,
and
you
can't
solve
a
congestion
problem
with
randomness
and
that's
what
reviewer
roulette
represents.
A
A
I
think
so
I
think
everybody
is
a
maintainer
today
would
be
grand
person
and
I'm
sorry,
I'm
trying
to
figure
out
the
gender
neutral
term
instead
of
grandfathered
the,
but
it
would
be
a
change
for
net
new
folks
that
are
coming
in
to
me.
It's
a
risk,
particularly
if
you
have
a
very
mature
feature
that
folks
are
coming
on
board
and
seeing
for
the
very
first
time
to
give
them
merge
rights
on
day,
one
or
day
six,
which
is
what
our
current
onboarding
process
does.
A
A
So
yeah
yeah,
why
bring
that
up,
even
though
we're
not
doing
any
hiring
right
now
is
that
we
do
need
to
have
something
in
place
for
the
next
before
when
hiring
does
open
back
up
anyway,
I
talked
over
someone,
and
I.
E
E
E
I'm
seeing
another
catalyst
here
on
that
specific
issue,
which
is
the
catalyst
for
a
tons
of
other
problem
and
the
way
that
we
still
haven't
found
a
good
solution
to
at
least
working
and
implementing
the
solution.
For
that
it's
a
cut
freeze,
as
mentioned
we
were
reaching
the
end
of
the
milestone,
and
people
are
eager
to
get
their
magic
quest
closed
and
merged
because
they
want
to
shoot
the
future
within
the
milestone.
E
If
you
are
the
worst
streamlined
process
where
one
more
days
or
two
more
days
won't
mean
you
have
to
wait
for
next
month,
it
will
be
less
of
an
issue,
but
I
mean
this
is
just
a
a
non
problem
that
we've
seen
some
initiative
to
to
move
to
the
cd
approach.
But
well
we
still
have
this
monthly
cadence
when
it
comes
to
reading
things
publicly,
we've
discussed
already
the
feature
flag
running
out,
and
that
is
that
probably
needs
to
be
matched
between
self-managed
instances
and
dot
com.
E
So
we
still
want
this,
this
kind
of
consistency
and
then
the
cut
free
still
exists
in
when
it
comes
to
publicly
releasing
features.
So
it
creates
those
situations
of
tensions
and
and
russian
scenes,
and
then,
if
we
favor
that
the
drawback
is
probably
just
quality
and
more
great,
more
works
or
less
availability
for
our
product,
which
is
supposed
to
be
better
more
more
important
than
velocity.
E
E
Answered
won't
reach
the
quality,
because
it's
not
always
true,
but
I
mean
that
is
not
fully
resolved
and.
B
Something
else
that
I
tend
to
do
is
if
I'm
waiting
for
maybe
I'm
working
on
something,
that's
a
bit
contentious
and
I'm
waiting
for
feedback
or
to
to
resolve
something
and
I'm
waiting
too
long,
often
I'll
just
jump
on
slack
with
just
that
person
and
it's,
I
find
it
much
easier
to
resolve
it.
In
a
quick
conversation,
it's
like
a
slack
or
a
bus
or
or
a
video
call.
E
So
it's
killing
by
going
to
a
slight
conversation,
a
zoom
call
or
even
bringing
more
people
some
time
can
help,
because
I
don't
mean
you
know
going
through
manager
and
thing
like
that
unless
there
is
a
very
strong
discussion
and
and
and
we
need
someone
to,
I
mean
to
take
a
decision
there,
but
anyway
the
gri
should
be
taking
decision
making
decision
anyway,
but
yeah
and
bringing
more
more
people
into
that
bring
that
into
the
weekly
and
meetings
definitely
can
help
moving
faster.
A
A
From
fernando
about
multiple
front
end
being
of
resource
for
multiple
back-end
teams,
but
processes
differ
we're
all
back
in
engineers
here,
if
you
allow
me
to
include
myself
as
manager
as
an
engineer.
A
C
C
C
B
It's
it's
generally
good
and
I've
not
come
across
any
of
these
issues,
but
it
it
might
be
the
front-end
team
who
are
having
the
the
issue
and
not
the
back-end
team.
B
Yeah,
I
do
a
lot
of
talking
to
the
front-end
developers
on
slack
as
well.
So
it's
real
time,
but
now
I've
not
had
any
of
these.
D
E
I
want
to
say
that
I
can
speak
a
bit
about
the
serbia
convention,
because
this
is
something
that
is
painful.
To
be
honest,
it's
it's
useful
when
followed
consistently
and
the
problem
is
there
it's,
because
it's
not
applied
consistently
and
sometimes
hard
to
deal
with,
particularly
when
plants
is
changing.
E
It
makes
things
really
confusing
for
people
trying
to
find
their
way,
because
it's
not
like
using
native
features
like
like
a
child,
epic
with
paralympic
or
issues
attached
to
an
epic,
because
this
is
native.
These
are
native
feature
integrated
into
the
ui.
So
it's
really
easy
to
navigate
between
those
current
issues.
Sub
issue
convention
is
just
made
of
specific
titles.
The
way
you
write
the
description
and
the
label
which
is
sub
issue.
E
So
it's
a
convention
that
you
need
to
learn
and
apply
and
as
any
other
workflow
labeling
stuff
people
just
can't
handle
everything,
and
sometimes
they
just
don't
follow
it
carefully,
which
makes
it
super
difficult
for
people
to
understand
how
things
are
organized.
So
this
is
why
there
were
ongoing
discussion
about
dropping
that
approach
and
having
issues
and
apics
instead.
So
I
can
feel
the
pain
of
the
frontend
team,
because
they're
actually
yeah
working
with
several
groups
and
each
group
has
their
own
way
to
work
and
with
the
different
implementation
of
their
workflow.
E
And
this
is
why
I
wasn't
at
looking
for
a
stage-wide
workflow,
because
it
would
make
the
changes
seamless
for
those
front-ending
resources,
because
they
can
work
on
multiple
groups
depending
on
the
load.
So,
but
I
assume
that
it's
too
complicated
today
and
we
need
to
go
back
to
something
simpler,
so
that
it's
easier
to
share
and
be
consistent
as
a
stage
level.
C
C
I
I
know
at
some
point
that
some
of
the
issues
we
were
working
on
at
dusk.
They
were
trying
three
different
ways.
E
Officially,
the
ceviche
convention
is
part
of
our
citroen
book,
even
if
it's
not
written
there,
but
in
in
a
issue
description
as
a
convention,
but
not
every
groups
are
playing
them
because
some
of
them
don't
need
it.
To
be
honest,
there
was
some
try
to
follow
what
the
defend
I
mean.
The
threat
management
sub
department
is
doing
by
using
native
apex
and
child
issues
instead,
but
this
comes
with
its
own
throwback,
so
it
wasn't
settled
yet
and
we
were
waiting
for
the
workshop,
which
happened
last
week.
A
C
Yeah,
so
that's
a
fairly
new
one,
there's
some
new
ones
in
dust,
so
dust
now
is
split
into
three
zap
brazil
and
there's
another
there's
another
one.
There
they're
just
some
of
the
recent
ones
that
I've
been
looking
at.
C
So
the
severity
and
priority
have
changed
recently,
although
I
can
follow
what
that
one
is.
We
still
use
workflow,
but
I
don't
know
if
they're
important,
because
I
don't
think
anyone
uses
them
at
least
in
dust
there's
a
category
coal
and
dast,
and
I
have
no
idea
if
anyone
uses
it
or
if
I
should
be
applying
it
or
not,
that
kind
of
stuff,
I'm
just
not
I'm
just
not
sure.
C
E
This
is
probably
also
in
our
documentation
yeah.
This
is
the
gitlab
dock
in
the
contributing
part
I'll
try
to
add
link.
So
this
is
studying
what
are
the
different
kind
of
labels,
what
they
are
made
for
and
which
one
you
should
have,
and
you
already
know
probably
that
if
you
forget
to
add
some
of
the
labels
well,
the
bot
will
remind
you
that
you
need
to
add
this
one
and
this
one.
E
Also,
it
helps
for
metrics
from
measuring
the
cycle
time,
for
example,
and
it
helps
on
the
merger
quest
to
count
the
the
throughput
matrix
for
for
every
group,
for
example,
so
that
the
different
usages
that
you
can
have
behind
using
labels-
I
admit,
there's
a
ton
of
them
and
what
I
use
is
a
snippet.
I
have
a
tool
on
my
mac,
which
is
I've
read
and
with
two
shortcuts.
I
can
just
paste
all
the
labels.
I
need
on
the
dependency
scanning
issue
or
the
container
container
scanning
issue
and
I'm
good
to
go.
E
E
It
was
happening
a
lot
for
us
because
of
the
integration
between
all
the
categories
of
secure,
it's
less
of
an
issue
for
other
teams,
maybe
but
yeah
it
looks
really
redundant
to
have
I
mean
you
could
have
a
label
for
companies,
g
cloud
for
example,
so
you
will
have
all
the
different
levels
or
engineering
departments,
but
yeah,
sometimes
it
looks
a
bit
redundant.
I
agree.
A
So,
as
I
mean,
I
could
easily
see
as
an
example
that
we're
not
dealing
with
tightly
today,
but
I
could
see
coming
in
the
future
where
we
will,
if
we
stay
within
the
constraints
of
operating
within
a
runner
or
within
a
review
application
that
we're
going
to
have
to
move
those
particular
features
forward.
In
order
to
fully
realize
everything
we
need
to
do
with
insecure.
A
So
it
it
won't
be
our
feature,
but
we
will
implement
it,
and
so
that's
where
you'll
see
some
of
section
in
devops
and
group
disagree
when
we
get
into
those
use
cases.
C
A
A
There
is
a
plan
that
we're
going
to
give
it
away
to
everyone,
and,
yes,
it
is
in
core,
but
it
only
operates
in
core.
If
you
include
the
vendor
template
we're
talking
about
it's
on,
it
is
on
always,
and
you
have
to
turn
it
off
flip
the
script
beyond
that
there
is
some
work
that
you've
probably
seen
happening
to
like
ci
minutes
and
what
you
get
at
the
various
licensing
tiers.
A
A
C
It's
useful
good
to
know
and,
like
I
said,
happy
to
write
happy
to
have
all
the
labels.
There
are
just
what
they
are
and
where
to
find
them.
Okay,.
A
A
As
a
minimal
iterative
improvement,
I
would
like
to
ask:
would
it
be
useful
for
it
since
we
now
not
only
do
we
have
the
secure
sub-department
section
of
the
handbook,
but
we
also
have
individual
sections
for
individual
groups
and
teams?
A
C
A
True,
okay,
okay,
all
right!
That's
that!
That's
that's
something!
In
fact,
I
was
just
I
was
hearing
something
here,
and
so
I
just
wanted
to
tease
it
a
little
bit.
Okay,
thank
you.
We're
a
bit
over
time!
Is
there
another
item
here
that
y'all
would
like
to
discuss
or
is
on
this
issue
or
is
there
there's
a
retrospective
issue
that
you'd
like
to
discuss
or
is
there
another
item
that
has
not
been
recorded,
you'd
like
to
bring
up.