►
From YouTube: 2019.06.24 - Secure Section - 12.0 retrospective
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
A
We
will
we'll
also
need
to
repeat
this
at
a
time
that
is,
that
is
where
they
can
attend,
so
that
will
be
late
afternoon.
So
we'll
try
to
repeat
so
that'll
be
about
10
12
hours
later,
so
we'll
do
this
twice
in
future:
iterations,
exact
timing
to
be
to
be
considered
or
to
be
determined,
that's
the
appropriate
way
of
phrasing
it!
Okay!
A
Just
like
last
time,
we
did
this
asynchronously
through
an
issue.
Hopefully
everyone
had
a
chance
to
look
through
it
at
least
and
see
what
we
did
and
there's
in
the
items
that
were
determined
to
have
slipped,
and
I
know
we
had
some
commentary
as
far
as
what
went
well,
what
didn't
go
well
and
where
we
can
improve
before
diving
in
deeper.
On
that,
I
want
to
add
in
one
one
more
thought-
and
this
is
my
fault
for
not
being
ready.
A
A
No
okay-
I
will
add
this
to
I
I
will
I
I
will
make
sure
to
broadcast
this
in
another
time
in
another
forum,
but
the
retrospective
prime
directive
states
that,
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.
Everyone
knows
much
more.
Naturally,
we
will
discover
decisions
and
actions
we
wish
we
could
do
over.
A
A
I
do
let's
go
through,
who
is
here
as
far
as
what
went
well,
we
have
three
items
that
are
here,
none
of
which
were
by
people
that
are
on
this
call.
So
what
went
well
no
hard
feature
freeze
on
the
seventh
forming
a
working
group
to
take
proactive
steps
toward
extendable
architecture
for
customer
security
scans
and
can
contribute
to
get
lab
ui
much
faster
by
learning
how
to
set
it
up
locally
for
development
and
how
to
write
storybook
docs
with
live
and
live
examples.
A
B
I
guess
it's
helpful,
but
my
emergency
quests
were
merged
way
before
the
date.
That
would
would
be
feature
freeze
before
the
seventh.
So
I
personally
me,
I
didn't
feel
the
pressure
this
time,
but
I
believe
that
it's
convenient
and
cuts
off
much
pressure
from
people
that
opened
their.
Mrs,
like
the
last
week.
B
C
A
If
we're
keeping
more
of
a
kanban
rolling
weekly
priority
list,
we
just
keep
working
the
top
of
the
list
and
we
as
we
groom
items.
If
we
find
that
they're
going
to
take
if
they're
going
to
take
longer
than
a
week,
then
we
don't
worry
about
what
the
feature
freeze
is
it's
just.
We
just
keep
we
just
we
we
just
keep
working
week
by
week
and
we
just
keep
growing
from
the
racket
back
from
the
top
of
the
queue.
That's
probably
where
we're
headed.
Are
we
there?
Yet?
No
is
it
where
we're
going?
A
It
looks
that
way.
I'll
elaborate,
more
and
you'll,
see
more
in
slack,
and
I
see
iep
added.
Another
item
is
what
went
well
as
soon
as
the
house
didn't
burn
down.
While
he
was
on
vacation.
I
too
celebrate
houses
not
burning
down,
so
I'm
going
to
call
out
that.
Well,
since
I
see
ip
working
here
as
well.
A
D
A
A
E
I
guess
just
for
me
echoing
what
paul
said
like
a
lot
of
times.
It
was
very
difficult
to
get
like
a
merch
request
ready
for
maintainer
review.
I
feel
really
weird
about
assigning
merge
requests
for
maintaining
review
until
the
pipeline
is
like
at
least
passing.
You
know
whether
that
means
all
green
or
like
allowed
to
fail.
C
E
You
know
I
I
just
add
on
to
that,
like
I
I
can't
say
for
sure.
Either
I've
been
here
since
november,
but
since
november
it
seemed
it
kind
of
did.
There
was
an
uptick
in
how
often
it
was
broken
for
at
least
two
last
releases,
but
I
mean,
as
of
the
last
two
weeks,
it
seems
like
it's
been
better,
so
I
can't
again,
I
don't
have
enough
data
points
to
save
its
consistent
problem.
Maybe
we
just
had
it
happen
for
whatever
reason
more
recently.
E
B
B
C
E
I
I
think
the
closest
thing
to
that
we
had
we
used
to
have
like
the
release
retrospective
so
like
for
the
given
release.
They
would
have
a
release
retro
and
then
there,
if
you
had
issues
with
what
happened,
that
release
you
bring
it
up,
I
think,
was
the
closest,
like
appropriate
form,
for
that,
at
least
my
understanding.
A
Okay,
those
still
exist,
at
least
for
the
development
organization,
that
we
all
report
up
to
so
so
part
of
what
we're
doing
here
is
an
input
into
that.
So
I'm
going
to
filter
this
down
to
one
or
two
items
that
went
well,
that
didn't
go
so
well
and
where
we
can
improve,
and
that's
where
that
is
this
stage's
contribution
to
that
retrospective.
E
E
If
your
merge
request
is
failing,
I
mean
maybe
it's
more
complicated
like
that.
Maybe
they're
changing
jobs
and,
like
you
know
at
that
point,
if
you're
changing
a
job,
then
you
know
that's
different
than
saying:
hey
your
pipeline's
red,
don't
merge
it
in.
I
don't
know
if
that's
how
enforced
that
is.
A
My
understanding
is
that
there
might
be
ways
that
people
are
gaming,
the
process
to
make
it
look
like
it
is
passing,
and
it
is
a
green
merge
when,
in
fact
it
is
not
the-
and
I
remember
there
being
a
conversation
about
that
in
the
in
the
near
past.
I
will
I'll
have
to
go.
Look
it
up,
and
I
will,
when
I
find
it
I'll,
add
it
as
a
comment
on
this
particular
issue.
C
I
think
yeah,
and
I
think
it's
you
know
worthy
of
someone
diving
into
when
we,
when
it
bubbles
up
to
the
to
the
other
issue
like.
Why
are
some
of
these
happening?
I
think
some
of
it
can
also
be
like
you
get
your
specific
pipeline
green,
but
hundreds
of
other
changes
have
been
merged
into
master
since
then,
so
when,
when
everything
gets
it's
merged
in
together,
that
can
cause
conflicts
as
well,
which.
E
E
Yeah,
I
mean
the
only
thing-
and
I
had
talked
to
lucas
about
this
on
our
101s,
and
this
is
probably
I've
been
working
on
him
with
resolve
mediating.
Mr,
like
just
maintainers,
I
realize
at
least
for
the
front
of
maintainers
everyone's
a
little
different
communication
style.
Some
people
prefer
pings.
E
Some
people
prefer
that
you
reassign
the
shoe
back
to
them
and
I'm
not
I'm
talking
about
more
of
like
intermediate
conversations.
So,
like
you
get
a
bunch
of
feedback
and
you
have
questions
follow-up
questions
about
the
feedback
that
they
left.
So
you
could
obviously
make
the
changes
that
you
want.
So
my
experience
has
been
what
some
developers
would
prefer,
like.
E
Don't
reassign
it
back
to
me
until
it's
ready
for
a
natural
code
review,
if
you
need
further
discussion
and
clarifications
to
ping
me
and
for
some
developer
maintainers
that
doesn't
work
because
they
don't
check
their
to-do,
so
they
have
hundreds
on
there.
So,
for
me,
this,
my
work
around
was
basically
memorizing
working
with
individual
maintainers,
what
they
prefer.
E
It's
okay,
like
I
got
around
it,
but
for
newer
developers,
something
to
think
about
with
onboarding
that
that
might
cause
some
turn,
because
I
had
mrs
kind
of
sitting
there
and
I
had
to
kind
of
trial
and
error
to
see
what
why
it
was
like
sitting
there,
whether
they
were
initially,
I
thought
as
if
they
were
overworked
or
busy.
But
in
some
cases
it
was
just
that
they
did
not
see.
A
C
That
it
sounds,
sounds
frustrating,
and
I
I
don't
know
I
don't
know
like
if
we
can
dictate
that
everybody
does
it
the
same
way
or
anything,
but
at
a
minimum.
Maybe
we
could
require
maintainers
to
have
like
the
like
they're
working
with
me.
Read
me
thing.
I
I've
seen
some
folks
have
that
on
their
their
gitlab
profile
or
whatever,
where
it
says
hey,
I
prefer
you
know
pings
or
I
prefer
you
know
at
mentions,
or
whatever
just
a
thought,
yeah
it's.
C
B
B
Excuse
me
I've
mixed
issues
and
merge
requests,
and
maybe
we
have
guidelines
about
issues,
but
we
don't
have
guidelines
about
merge
requests
for
what
I
remember,
because
in
issues
it's
prescribed
by
handbook
that
if
you
want
someone's
feedback,
you
just
pin
him.
You
do
not
add
this
person
to
the
list,
if
I
say
assamese,
and
maybe
we
should
update
the
handbook
on
merge
requests
in
similar
fashion,
because
currently
it
seems
to
me
that
assignment
ping
pong
for
merge
requests
is
just
a
tribal
knowledge.
It's
not
documented
anywhere.
C
E
I
think
the
victor's
point
yeah.
Maybe
the
follow-up-
would
be
to
create
a
gitlab
issue
to
have
further
discussion,
because
it's
it's
really
once
we
allowed
for
multiple
assignees
for
a
merge
request.
Like
I
just
what
worked
for
me,
I
noticed
that
I
got
more.
It
was
more
explicit
that
the
mayor's
request
was
ready
for
review
when
I
unassigned
myself
and
assigned
the
maintainer
in
ping
pong,
because
it
seems
like
that's
what
we
were
most
used
to
here.
E
Even
though
gitlab
lets
you
do
either
or
it
it
empowers
you
to
choose
which
approach
you
want
for
your
process,
but
I
think
the
process
traditionally
here
has
been
most
people
are
used
to
having
it
explicitly
assigned.
So
that's
what
I
do,
because
if
I
end
up
assigning
myself
and
then
the
maintainer
they
know
they're
assigned,
but
they
really
won't
look
at
it
again
until
they
casually
like
passively
look
at
it,
at
least
if
I
unassign
it
to
myself,
they
get
a
ping
and
they
get
an
email.
E
A
B
A
It
allows
us
to
add
it
to
to
prioritize
it
against
everything
else
that
we're
trying
to
deal
with
in
that
next
iteration
and
three.
It
moves
the
work
back
closer
to
those
who
are
most
familiar
with
those
code,
but
for
with
the
with
those
code
bases
like
for
analyzer
updates
as
an
example,
so
we're
going
to
be
ch.
Yes,
we
need
to
change
how
we
do
release
management.
Is
it
how
we're
going
to
do
it?
A
How
we,
how
we,
if
we
reins,
if
we
take
someone
out
of
the
pool
to
do
work
or,
if
we're
going
to
make
it
an
e,
predominantly
an
em
task,
with
issues
that
are
spawned
out
of
that
for
for
engineers
to
work.
But
I'm
not
entirely
sure.
I
will
make
sure
to
link
that
discussion
into
this
retrospective
issue
and
I
will
throw
it
up
on
slack
so
that
we
can
increase
communicate.
A
A
A
E
Yeah,
I
had
a
quick
question.
Maybe
I'll
ask
the
team
in
general
for
some
feedback,
so
I
guess
one
of
the
items
I
had
listed.
There
is
like
what
didn't
go
so
well,
I'm
kind
of
struggling
to
how
to
like
prioritize
the
following
stuff.
I
had
so
I
worked
on
license
management
right.
I
ended
up
creating
a
component
that
went
into
git
lab
ui.
So
originally
I
I
was
thinking
like
all
right,
minimal,
viable
change
right.
E
The
idea
is
that
least,
amount
of
effort
to
get
this
feature
done,
and
I
got
pushed
back
in
the
maintainer
saying:
hey
we
could
you
know,
let's
make
this
a
generic
component
get
into
get
lab
ui,
it's
the
right.
You
know
what
we
should
be
doing
and,
as
a
result,
I
ended
up
with
like
six
additional
merch
requests.
I
don't
mind
doing
the
work,
that's
not
the
issue.
E
At
least
the
initial
issue,
by
like
two
releases,
you
got
just
all
this
additional
work
had
to
be
done.
Do
you
have
any
suggestions
for,
like
I
mean
in
that
case,
should
I
just
refer
to
the
handbook
and
be
like
look?
You
know?
I
I
don't
know
I
guess
like
I
I
feel
like
as
a
result
of
not
pushing
back
on
the
maintainer
suggestion.
E
You
know
things
were
missed
at
least
two
releases
and
all
this
additional
work
was
done
when
we
easily
could
have
landed
it
to
begin
with
and
then
just
followed
up
with
the
technical
debt
issue,
we
would
have
done
the
same
amount
of
work.
The
difference
would
have
been
that
we
wouldn't
have
blocked
the
original.
E
D
Yeah,
by
the
way
this
week,
I'm
going
to
have
it
off
all
the
time,
because
it's
going
to
be
really
hot
here
and
I
don't
need
to
see
you
to
see
me
all
the
time
sweating
anyway
yeah.
I
think
I
think
that
mr
is
like
symptomatic,
or
these,
mrs
is
symptomatic,
and
it's
also
something
that
I'm
a
bit
concerned
about.
You
know
not
only
about
you
know,
working
with
maintainers
in
front
end,
but
in
general
on
issues.
D
We
should
do
it
in
a
better
planning
phase,
and
this
is
this:
is
you
know
where
I'm
just
urging
everybody
once
you
start
seeing
issues
that
are
just
too
big
scope
them
down,
and
even
if
your
ex
is
not
happy
because
hey
in
one
release
cycle,
we
might
release
something?
That's
not
your
ex
perfect.
Yes,
because
it's
mvc,
you
need
to
scope
things
down
and
maybe
on
the
next
time,
I'm
also
now
smarter.
When
it
comes
to
these
issues,
you
should
push
back
harder
and
say:
hey.
D
We,
we
should
merge
because
we're
going
to
iterate
on
it
and
not
postpone
postponed,
postpone
so
every
time
you're
seeing
that-
and
this
goes
out
to
everybody-
please,
you
know,
make
us
a
stage
aware
or
make
your
managers
aware
or
make
your
have
like
the
the
eighth
eye.
Looking
onto
it,
we
should
scope
things
down.
E
A
D
A
B
B
Initially,
at
the
beginning
of
the
of
the
this
cycle
of
this
issue,
it
was
significant
scope,
expansion
done,
it
was
an
outcome
of
reviewer's
suggestion,
and
actually
it
was
a
good
candidate
to
say
hey.
We
agree
that
you
are
proposing
a
more
consistent,
behavior,
more
well-designed
behavior,
but
we
should
split
it
up
and
maybe
due
to
lack
of
experience,
it
was
not
done.
It
was
not
localized
by
me,
but
it
was
surely
a
good
candidate.
B
A
The
what's
behind
my
question
is
that
there's
some
there's
some
candidate
areas
that
I
think
we
could.
We
could
anticipate
some
push
pushback
on
another
one,
an
example
being
and
I'm
not
trying
to
pick
on
anybody
or
any
part
of
the
workload
is
when
we
intentionally
decide
not
to
create
a
new
reusable
component
within
a
component
library
in
the
in
the
ui,
because
we
need
to
ship
fast
and
then
we're
going
to
follow
up
by
by
by
by
genericizing
the
component
itself.
That's
an
example.
A
So
what
is?
Would
it
be
possible
for
us
to
bypass
anticipated
maintainer
feedback
or
pushback
by
making
those
choices
explicit
during
earlier
stages
of
an
issue,
life
cycle
when
we're
planning
it
as
an
example
and
going
ahead
and
creating
those
related
issues
that
we're
gonna
so
that
when
we
do
need
to
make
something
in
generic
use
case,
we
go
ahead
and
do
it
we
create
the
issue
first
implement
fast,
and
then
that
way
we
can
refer
to.
This
is
deferred
work.
This
is
deferred
work.
A
D
I
mean
the
problem
is
that
the
maintainer
just
might
not
care
what
your
issue
says
right
so
because,
if
you
do
the
implementation
plan
and
the
maintainer
disagrees
with
your
implementation
plan,
like
you
know
doing
it
the
other
way
around
and
if
the
maintainers
of
the
opinion
know
it
should
be
a
component
first,
then
it
should
be
a
component
first.
How
do
you
argue
with
that?
Even
if
the
plan
is
like,
let's
do
it,
because
we
actually
had
the
plan.
We
actually
created
the
issue.
D
Hey,
you
know,
let's
defer
this
discussion,
pull
it
out
into
a
new,
maybe
even
it's
a
good
starting
issue
for
someone
on
boarding
or
something
like
this
right.
So
this
is
just,
I
think,
when
a
lot
of
communication-
and
I
don't
want
to
sing
out
the
maintainer
or
something
it's
just
where
a
lot
of
communication
needs
to
happen,
where
we
also
can
define
that
we
need
to
define
things
better,
and
maybe
it's
also
just
our
fault
for
not
on
boarding
the
maintainer
into
the
discussion
earlier
to
bring
them
into
the
thing.
D
C
I
guess
sorry,
I
mean
I
see
a
couple
problems
with
that.
One
is
like
you,
don't
know
what
the
maintainer
is
going
to
be,
who
the
maintainer
is
going
to
be
assigned
to
you
when
you
open
an
issue
for
work
and
I've
lost
track
of
what
the
second
thing
was.
Oh
yes,
no
like
like.
Maybe
maybe
you
didn't
have
enough
foresight
to
realize
that
that
would
be
a
good
candidate
for
a
ui
component
when
you
started
the
issue,
so
you
can't
preemptively
create
a
creative
technical
debt
issue.
E
That's
that's
pretty
yeah.
I
don't
want
to
go
over
the
time,
but
that's
pretty
much
exactly
what
happened.
It
started
out
as
like
hey
this
is
you
know
a
specific
feature
for
secure
for
license
management
and
I
was
like
hey.
You
know
it
doesn't
want
to
take
too
much
effort
to
maybe
make
this
a
reasonable
component,
but
then
it
turned
out
to
be
a
lot
more
effort.
So
then,
when
the
maintainer
came
by,
you
said
well,
it
should
be
a
component.
I
agreed
and
I
linked
them.
It's
like.
E
Well,
you
know,
are
you,
okay,
here's
a
follow-up
issue,
we'll
take
care
of
that
and
there
was
push
back
on
that
so
really
the
real
question.
This
is
probably
outside
the
scope
of
this
team,
but,
like
the
real
question
might
be,
how
do
we
escalate
or
do
we
even
have
an
option
for
getting
do
I
you
know
maybe
ping
a
different
maintainer
and
see
if
they
agree,
and
sometimes
you
may
pull
in
an
alert,
maintainer
or
two?
Even
they
may
disagree
so
like
where?
Where
is
the
decision
making
done
like
do?
E
Does
the
maintainer
have
final
say,
or
can
you
know
the
priorities
of
a
team
ever
override
a
maintainer?
Like
you
know,
I
don't
think
that's
kind
of
a
gray
area,
because
you
know
we
have
priorities
within
our
team
and
normally,
if
we
didn't
have
a
maintainer,
you
know,
then
you
know
pm
could
prioritize
something
and
say
hey.
This
is
an
exception,
but
we
have
like
another
reporting
structure
for
maintainers
in
terms
of
gatekeepers
of
the
code.
E
So
I
think
those
are
just
challenges
we
have
to
address
in
general
and
maybe
we
would
have
to
communicate
with
maintainers
and
try
to
bring
that
up
as
issues
with
them
and
see
if
they
have
any
ideas
for
resolving
those
type
of
conflicts
and
I've
been
talking
to
them.
So
I've
been
talking
to
a
lot
of
maintainers
back
and
forth,
but
it's
it's
not
a
clear-cut
thing,
because
they're
always
edge
cases
so.
A
Restating
and
expanding
your
scope,
but
I
know
we're
over
time.
Thank
you.
Everybody
for
sticking
around,
I
would
is
what
it
sounds
like
you
are
articulating,
as
well
as
others
articulating
within.
This
call.
Is
that
how
it
is
inconsistent
in
one,
how
we
engage
with
maintainers
themselves
to
get
their
attention
when
things
are
changing
and
two
it
is
inconsistent
on
what
is
being
enforced
during
maintainer
review
depending
and
it
is
all
based
upon
who
you
are
interacting
with.
E
Yeah
and
as
a
follow-up,
they
are
aware
of
that
and
they're
trying.
They
have,
I
believe,
like
a
like
a
weekly
maintainer
conversation,
but
our
meeting
I
have
to
you
could
ask
all
right.
We
could
ask
and
follow
up
with
you,
but
they
are
aware
of
it.
So
it's
not
like
people
don't
know
about
it.
It's
a
challenge
to
you
know
everyone's
aware
of
the
problem:
we're
they're
trying
to
figure
out
solutions,
it's
just
very
difficult.
So,
okay.
A
Minimally,
I
would
argue
we
should
create
if
it
doesn't
exist,
then
documentation
on
what
maintainers
are
to
be
looking
for
or
looking
at
and
how
we
engage
with
them
should
be
created
or
extended
or
highlighted
so
that
if
we
having
issues
engaging
with
someone
or
about
the
feedback
that
we
are
receiving,
we
can
point
back
to
handbook
hey.
This
is
something
I'm
I'm
hearing
a
problem
and
I'm
trying
to
figure
out
a
way
to
nip
it
in
the
bud.
A
Okay,
alrighty
with
that
being
said,
we'll
go
ahead
and
close
this
out.
Thank
you,
everybody
for
participating.
I
appreciate
the
ques.
I
very
much
appreciate
the
conversation.
This
helps
highlight
what
we've
done.
What's
I
mean
these
are
very
important
items
that
are
brought
up
in
the
retrospective
document,
but
it
also
kind
of
helps
me
distill,
where
our,
where
we
think
we
did
well
as
a
stage
where
we
think
we
can
improve
and
what
really
was
an
issue.
A
So
that's
going
to
help
me
articulate
things
up
as
up
and
be
a
better
advocate
for
us
as
well
with
it
as
a
stage
and
also
as
a
team.
So
thank
you
for
your
time.
Thank
you
for
just
station
have
a
good
rest
of
your
day,
whether
it
is
midday
beginning
of
your
day
or
it's
it's
time
for
you
to
go,
have
dinner
and
sign
off
for
the
night
so
anyway,
thank
you
have
a
good
rest,
your
time
and
we'll
talk
soon.