►
From YouTube: 2020.01.21 - Defend Staff Meeting
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
A
So
a
quick
reminder
we're
trying
to
make
these
put
these
up
on
YouTube,
unfiltered
available
to
the
general
public
for
questions.
Questions
that,
but
you
know
it's
part
of
our
values-
is
transparency.
So
just
don't
mention
candidate
names
if
they
haven't
started
yet
and
don't
mention
customer
names
and
there
may
be
something
else
we
discuss,
we
don't
want
to
make
public,
but
it's
unlikely
other
than
those
two
things
so
we'll
just
decide
at
the
end.
If
we
can
make
this
one
public,
so
that
being
said,
Sam
or
Samuel
I,
do
you
go
by
Senator
Sam?
B
Sam's
fine,
although
I
I'm,
still
trying
to
figure
out
how
we're
gonna
deconflict
the
to
Sam's
I,
might
have
to
go
by
Samuel.
Just
for
that
sake,
you
know
the
sake
of
ease
of
knowing
you
too
yeah,
so
I
just
started.
Yesterday,
I
came
from
force
point
I
was
there
for
just
over
four
years
on
their
insider
threat.
Product
super
excited
to
be
here.
B
B
A
A
Folks,
on
interim
on
loan
to
the
team
that
Jacob
just
Nannette,
England,
Germany,
Switzerland
and
Poland,
some
of
whom
are
not
started
yet,
some
of
whom
are
on
loan
on
some
of
those
countries,
but
pretty
pretty
wide
swath
I
still
have
to
get
used
to
Arthur
and
that
he
is
a
day
ahead
of
me.
So,
like
we'll
see,
updates
on
Sunday
night
my
time
for
his
Monday,
which
always
throws
me,
but
always
entertains
me
too
I'm
sure
you
see
that
you,
you
notice
the
reverse
Arthur
that
everybody
else
seems
to
be
a
day
behind
you.
A
A
We
want
more
folks
helping
this
to
decide
who
we
want
to
hire
so
there's
two
ways:
don't
with
interviews
one
is
to
be
a
technical
interviewer
which
actually,
then
you
get
to
interview
people
across
the
company
on
all
teams,
there's
a
whole
process
for
that,
and
although
people
want
to
do
that,
Lucas
put
in
the
link
there
on
on
how
to
do
that
is
it.
It
is
really
useful.
It's
people
seem
to
learn
a
lot.
A
It
is
a
big
time
commitment,
just
don't
big,
it's
a
moderate
to
big
time
commitment
so
be
aware
that
and
what
I
was
looking
for
as
well
as
folks
up
with
behavioral
interviews.
So
you
know
talking
about
no
asking
star
method,
questions,
situation,
task,
action,
results
and
looking
for
culture
fit
and
do
they
understand
a
jille,
and
things
like
that
so
looks
like
that.
A
Lucas
is
already
volunteered,
and
actually
he
already
gone
through
the
training
for
it,
which
is
great,
so
others
want
to
volunteer
and
help
the
more
we
have
the
more
we
can
spread
that
across
multiple
people
as
well.
So
if
others
are
interested
and
again
thanks,
Lucas,
mother
and
others
are
interested.
Just
ping
me
and
I
will
tell
you
what
you
need
to
do
if
you're
interested
in
either
side
of
the
technical
interviews
or
the
behavioral
interviews.
A
So
that
being
said
so
next
item,
we
and
I
didn't
put
all
the
detail
in
here,
of
course,
but
we
were
really
close
on
the
NBC
for
network
policy
really
really
close
and
I
am
really
proud
of
the
team.
You
know
most
folks
working
on
a
brand
new
to
the
team,
both
in
product
management
and
engineering.
They
were
so
close
and
getting
in
in
the
cut
for
the
previous
release,
but
we
didn't
and
there's
all
sorts
of
reasons.
A
Why,
and
you
know,
we've
got
good
lessons
learned,
so
we
can,
we
can
work
to
avoid
the
you
know
address
those
in
the
future
and
one
of
the
ones
was
so
there's
many
different
reasons.
One
of
the
ones
was
that
in
particular
that
it
isn't
clear
on
this
one,
what
its
close
it
could
be,
what
is
minimal
for
the
MVC
for
network
policies,
so
the
team
and
then
a
paraphrase,
and
sometimes
the
team
was
a
little
bit.
A
Some
of
the
engineers
were
surprised,
like
is
this
thing
in
or
not
it's
not
clear
from
the
issue
and
we
were
running
to
try
to
get
it
in
all
at
the
last
minute,
and
and
people
worked
really
hard
to
make
that
happen.
But
I
guess
Matt.
Can
you
do
another
pass
with
Arthur's
amir,
philippe
and
thomas
on
this,
and
I
guess
actually
include
sam
as
well.
A
We
really
want
to
make
sure
we
understand,
what's
what's
minimal
from
a
product
management
perspective
and
I
think
we're
close
to
being
on
the
same
page
as
a
group,
but
not
100%,
like
one
example,
was,
is
being
able
to
log
but
not
block
part
of
the
MVC
that
what
that
was.
That
was,
that
was
one
of
them.
A
I
think
there
were
others
as
well,
but
I
guess
in
terms
of
kind
of
the
the
ask:
does
that
Thomas
and
Arthur
and
Zamir
did
I
kind
of
summarize
the
engineering
perspective
on
it
and
they
don't
want
to
hear
from
them
from
that
as
well.
But
is
that
a
good
summary
of
kind
of
our
concerns
on
what
is
minimal
to.
F
Let
me
I'm
gonna,
live
dangerously
and
and
add
a
little
bit
of
content
or
context
I
guess
there
is
a
different
there.
Is
it
this?
There
is
a
distinction
between
an
MVC
and
of
reaching
minimal
from
a
feature
category
maturity,
standpoint,
the
direction
that
I
have
seen
us
take
as
an
organization
to
differentiate
those
is
through
epochs,
where
there's
an
epoch,
defining
the
number
of
the
issues
or
child
epochs
necessary
for
a
feature
category
to
get
the
minimal
than
to
get
to
complete
than
to
get
the
viable.
A
One,
this
is
great
Thomas,
so
for
this
for
network
security
from
it
we
want
to
make
sure
we
know
everything
that
that
product,
the
product
management
agrees
that
you
put
helps
us,
put
or
puts
us
together,
and
we
put
it.
We
work
together
on
it
and
make
sure
that
we
have
agreement
on
what
what
really
what
is
minimal
for
each
one
and
your
epics,
broken
down
into
issues
I
think
would
be
great.
So
we
were,
we
were.
G
Yeah
I
think
in
hindsight
on
this
one.
It
is
something
that
could
have
been
split
out
because
it
is
an
NBC,
is
kind
of
the
title
of
the
issue
and
it
talks
about
several
different
parts
of
the
change.
I
guess
I
would
ask,
rather
than
having
me
go
back
and
look
through
for
things
that
are
unclear,
I,
don't
know
what
is
unclear
and
it
sounds
like
there
were
potentially
conversations
that
happened
outside.
G
So
if
there
are
things
that
need
to
be
defined,
let's
track
that
in
the
issue
through
comments
and
tag
me
I
think
that
we
actually
covered
a
lot
of
those
ground.
The
only
thing-
and
this
was
a
change
from
a
few
weeks
ago
when
we
were
trying
to
get
a
little
bit
more
clarity
around
this-
was
the
the
traffic
originally.
The
idea
was
logging
well
cilium
effect
of
influence.
What
we
were
gonna
do
with
logging,
because
it
couldn't
do
just
traffic
logon.
A
Think
there
was
that
was
the
primary
one.
I
don't
know
another
jump
out
at
me,
but
as
a
mirror
or
Arthur
or
comments
or
anybody
else
was
there
any
were
there
any
other
ones
where
we
were
thinking,
one
thing
and
maybe
Matt
was
thinking.
Something
else
was
that
the
primary
work.
H
For
me,
I,
remember
yesterday
or
day
before,
I
saw
a
couple
of
people
having
different
expectations
on
the
NBC
and
then
I
decide
to
give
a
full
read
on
NBC
and
after
giving
a
full
read
from
the
description
to
the
all
the
comments.
There
was
like
two
or
three
points
that
you
might
have
ambiguous
interpretation
on
that.
Maybe
it's
me
because
I
knew
I,
don't
know
like
what
has
priority
over
what,
but
that's
the
feeling
I
got
and
as
people
were,
having
different
expectations.
A
Excellent,
the
great
great
inside
analysis
on
that
so
to
me
at
least
Zamir
and
and
Matt,
you
guys
get
together
and
kind
of
well,
not
here,
but
offline
get
together.
You
know
asynchronously
or
synchronously
if
you
prefer.
So
it's
just
the
two
of
you
at
least
starters
gonna
kind
of
go
over
those
items
to
make
sure
on
the
same
page,
sound
reasonable.
G
G
A
So
metrics
tracking,
so
we
track
in
in
various
different
engineering
teams.
A
number
of
different
metrics
is
number
of
mrs
done
by
team
by
month
and
number
of
engineers
we
have.
We
also
look
at
time
to
merge
and
I
pulled
that
into
with
some
help
from
Lucas
a
separate
page
just
for
us,
which
just
says
those
those
three
graphs
which
you
see
a
link
there
and
I
want
to
make
sure
the
data.
The
queries
are
correct,
which
I've
been.
I
got
interest
rights
recently
and
I've
been
messing
with
those.
A
They
said
it
has
the
right
folks
on
the
team
and
that
the
so
I
want
to
make
sure
it
has
the
right
people
listed.
I
want
to
make
sure
it
has
the
right
bringing
in
mrs
with
the
appropriate
tags
and
then
we're
using
the
appropriate
tags.
We
want
to
go,
get
get
credit
for
the
work
that
we're
doing
an
overall
metric
tracking.
So
there's
lots
of
discussion
on
this.
I
think
net
net.
It's
that
there's
kind
of
two
different
areas.
One
is
looking
at
the
notes.
A
One
is,
is:
are
people
using
the
right
people
have
been
asked
to
or
are
they
aware
and
if
so
are
they
using
the
right
labels
on
their?
Mrs
and
I
think,
basically,
if
you
use
group
threat
management
or
group
:
:
runtime
application
security,
when
you
do
a
change,
no
matter
what
code
base
we're
doing,
also
changes
in
different
different
stages
to
further
the
goals
of
defend,
but
sometimes
it's
not
in
our
own
direct
code
basis
and
other
code
bases
other
parts
of
the
part.
A
A
I
A
Drinks
thanks
as
long
as
you
use,
one
of
those
three
it
should
show
up
in
our
metrics.
Is
that
accurate,
I
think
so,
but
folks
more
familiar
with
the
labels
and
how
periscope
pulls
the
data
etc.
Would
love
to
hear
if
that's
accurate.
F
F
So
so
we're
talking
butter,
kpi's
and
we're
also
talking
about
a
number
of
other
things.
There
is
a
page
for
development
KPIs
that
are
broken
down
by
a
group
by
stage
and
by
a
group
for
those
that
are
interested
and
I,
invite
you
to
google
it
now.
If
you
have
questions
they'll
help,
you
I'm
happy
to
provide
the
link
in
and
black,
if
necessary,
the
there
is
a
distinction
between
the
DevOps.
F
Oh
my
word:
okay,
come
on,
Bob
depend
label
and
scope
label,
DevOps,
defend
label
and
there's
also
group
scoped
labels.
Those
are
separate
and
distinct.
So,
as
we
were
talking
about
in
the
SFM
channel
yesterday,
the
DevOps
scoped
level
talks
about
which
group
to
which
this
issues
to
which
this
issue
belong
or
see
me,
which
stage
to
which
this
issue
belongs
as
a
part
of
a
roadmap.
Yes
and
I,
see
the
finger
of
shame
was
being
wagged
at
me.
Delete
briefly.
The
the
the
group
label
indicates
the
group
that
actually
executed
the
work.
F
The
idea
being
is
that
there
will
be
instances
where
we,
as
the
groups
would
then
defend,
are
going
to
need
to
pull
in
work.
In
other
stages,
roadmaps
like
configure
or
monitor
in
order
to
realize
our
own
product
maturity
goals
or
to
have
them
as
prerequisites
for
features
that
we're
trying
to
track.
So
it
is
so.
We
need
the
group
labels
in
order
for
the
group
to
get
credit
for
the
activities
which
they
are
undertaking.
F
The
the
DevOps
label
comes
into
play,
develops,
defend,
label
comes
into
play
for
the
stage
to
get
credit
has
for
progress
against
its
roadmap,
and
so
it
is
a
bit
confusing
to
have
those
two
concepts
separate
and
yet
distinct.
But
they
are
important
things
to
keep
in
mind
as
we're
working
and
technically
within
a
monolithic
architecture
with
some.
A
So
met
duo,
Thomas
said
and
I'd.
That
is
double
check,
your
mrs,
if
everybody
could
double
check
there,
mrs
they've
done
over
the
last.
Let's
maybe
scope
it
to
two
or
three
months.
Anything
earlier
net.
Don't
bother
make
sure
it
has
the
right
labels
and
that'll.
Allow
us
to
you
know:
quote-unquote,
get
credit
for
the
work
and
so
have
accurate
statistics
that
seem
that
a
reasonable
request,
okay,
seeing
some
thumbs
up
and
that's
not
it's
not
that
people
haven't
been
doing.
A
What
they've
been
asked
to
do
is
we're
figuring
this
out
as
we
go
as
the
team
is
very,
very
new.
So
if
people
could
do
that
over
the
next
couple
days
by
the
end
of
the
week,
that
would
be
awesome
the
so
then
that,
secondarily,
could
we
do
not?
You
know
we
did
it.
We
did
a
number
of
changes
to
the
cilium
code
base,
which,
which
is
awesome,
we're
contributing
back
to
and
the
different
open-source
project.
It
got
us
what
we
need.
You
know
product
management
had
full
buy-in
on
it,
etc.
A
The
only
nitpick
on
just
how
we
track
our
statistics-
and
this
is
we
don't
quote-
go
get
credit
for
it
now.
I,
don't
really
care
that
much
we're
not
gonna,
be
maintaining
cilium
a
lot
over
time.
So
it's
a
handful
of
em
ours.
That
thing
said
if
it's
a
small
amount
of
work
to
make
it
so
it's
we
quote,
unquote,
get
credit
for
that
work.
That
would
be
great.
If
it's
more
than
a
small
amount
of
work,
we
don't
need
to
do
it
or
I
wouldn't
recommend
we
do
it.
A
One
idea
was:
if
we
choose
to
do,
is
we
copy
the
changes
that
we
made
from
the
cilium
code
that
we
made
to
the
same
codebase
in
two
hours,
really
kind
of
have
a
backup
of
them
checking
into
our
our
code
base
in
the
orphan
code?
Right?
It
wouldn't
be
directly
used,
but
we'd
have
a
copy
of
it
and
then
it
would
also
count
as
work.
You
know
work
that
we've
done
because
we'd
merge
it
we've
merged
into
something.
That's
not
used,
but
I
am
firmly
on
the
fence
of
whether
it's
worth
doing
that.
E
Sort
of
vocalize
my
comment
here:
I
think
that
what
I
thought
that
and
more
that
we
made
was
part
of
the
work
to
address
this,
namely
if
all
we
have
to
do
is
where
we
need
an
EMR
that
has
a
and
that
has
the
appropriate
labels.
Then,
if
we
have
a
page
that
has
a
list
of
like
external
contributions-
and
we
have
every
mr
for
adding
an
external
contribution
as
a
separate
line
item,
then
that's
essentially
tracking
the
same
velocity
using
just
documentation.
Maybe.
A
E
Only
thing
is
I'm
not
really
sure
where
this
would
live,
because
I'm
pretty
sure
that
contributions
to
Nicky
Laughlin
group-
okay,
hey
like
the
handbook-
would
not
count
towards
those
dots
I.
Think
it's
just
like
you
lot,
org,
so
I'm
not
sure
we
can
actually
deal
with
handbook.
We
might
have
to
put
it
somewhere
else.
Yeah.
A
H
A
A
E
E
A
F
So
there's
been
a
number
of
conversations
that
have
been
happening:
they're
not
just
here
and
defend.
This
is
all
over
the
place
where
we're
having
challenges
in
the
handoff
between
product
management
and
engineering.
So
there's
something
there's
an
experiment.
We
want
to
try
you'll
note
the
for
those
that
have
been
paying
attention
to
the
defense
stage:
calendar
there's
a
new
entry
on
the
books
for
Thursday
afternoon,
if
you're
on
the
US
East
Coast.
So
what
we
want
to
try
for
those
that
are
that
have
been
here
for
a
little
bit.
F
F
So
there
are
some.
So
that's
me
speaking
to
what
is
in
the
agenda
and
given
up
and
so
given
a
little
bit
of
a
harmony
to
what's
been
listed
here.
So
there's
some
candidate
issues
we
want
to
start
looking
through.
These
are
not
in
priority
order
deliberately.
These
are
more
along
the
lines
of
things
that
we
know
that
are
be
pretty
vague,
that
are
on
a
relative
near-term
roadmap
and
could
use
some
attention
from
us
right
now.
So
so
these
are
some
things
we
want.
A
A
To
summarize,
it's
very
very
likely,
yes,
that
the
ids
rules
and
server
lists
use
cases
are
not
on
our
priorities
yet,
and
we've
got
other
things
that
that
you
know
I'm
worried
about
spreading
ourselves
too
thin
across
too
many
different
things,
because
my
understand
the
priorities
are
first-class
vulnerability,
objects,
laugh
network
policies
and
then
you'ii
be
it
which
we
haven't
even
started.
Really
thinking
about
yet.
D
To
add
to
that,
for
the
list
of
issues
here,
I
think
we
should
not
focus
on
ones
that
are
in
the
backlog,
because,
like
looking
at
that
first
one
I
see
I
made
that
about
two
months
ago
and
it's
just
the
template
in
the
backlog.
I,
don't
think
that's
gonna,
be
a
productive
discussion
to
try
and
dig
into
that
one.
Yet,
since
we
haven't
done
full
problem
definition
requirements
from
our
product
side,
yet.
E
Active
milestones
so
I
think
that
this
is
part
of
point.
If
you
look
at
the
custom
ideas
rules
here,
this
one
is
scheduled
for
12.9
right
now
and
so
and
it's
it
has
no
description,
so
I
think
a
big
problem
with
this
is
that
we
need
to
go
through
this
and
we
need
to.
We
need
to
break
down
what
are
currently
scheduled
for
upcoming
milestones
and.
F
A
Not
convinced
where
we've
got
all
the
right
things,
we
need
four,
twelve
eighteen,
yet
yeah
I
know
so
getting
my
version
numbers
right
for
the
version
for
next
month.
Yeah
for
twelve
eight
I
would
actually
like
us
to
start
with.
Will
they
I,
which
I
think
will
help
us,
make
sure
we're
on
the
right
page
for
what
we're
planning
to
do
twelve
eight
and
then
look
at
twelve,
nine
and
Beyond
in
twelve,
eight,
specifically
first
class?
Perhaps
we
do
this
is
Brooklyn's
will
be
and
the
three
things
we've
got
inflate
right
now.
A
First-Class
vulnerability
objects
laugh
and
network
policies
and
make
sure
we're
in
good
shape
on
those
and
then
expand
past
that
because
we
definitely
don't
want
to
just
work
on.
You
know
just
one
month
plan
out
one
month's
worth
of
stuff,
but
we
have
to
get
the
next
month
right
before
we
work
on
future
months
and
the
reason
why
I
say
is
for
network
policies.
We
had
some
get
some
missa
misunderstandings
between
people
on
what
is
minimal
or
not,
and
some
of
these
are
I
think
those
three
are
all
in
at
least
okay
shape.
A
A
Our
for
this
next
quarter
is
to
get
three
to
minimal,
and
you
know
that
includes
first-class
vulnerability,
objects
and
network
policies,
and
you
know,
we've
got
all
sorts
of
good
reasons
why,
in
the
retrospective
and
in
the
group
discussion,
we
document
those,
we
got
some
good
feedback
on
both
sets
of
information.
That
can
we
start
with.
Can
we
start
with
twelve
eight
and
those
three
priorities?
First
and
then
move
on
to
twelve
nine
and
beyond.
I
A
Sorry
Lindsay,
so
not
one
of
the
other,
but
both
we
do
it.
We
review
what
is
in
the
plan
for
12-8,
make
sure
it's
the
right
things
and
then
also
we
start.
We
start
on
12
9
as
well,
but
you
know
we're
not
planning
to
start
that.
Well,
we
want
to
plan
that
out
for
for
the
month
after,
but
we
reconfirm
12
8
and
then
we
immediately
then
start
on
12
9
or
maybe
a
more
condiment
parallel
and.
I
I
think
for
the
12-week
conversations
there's
already
a
better
idea
of
who's
working
on
what
pieces,
so
that
could
be
a
more
targeted
conversation,
whereas,
if
we're
looking
towards
planning
for
12:9
we're
talking
about
sort
of
a
larger
group,
better
cross
knowledge
sharing,
not
just
the
individuals
who
are
already
sort
of
pre
assigned
to
that
work.
I.
G
In
terms
of
from
a
planning
perspective
ahead
of
time,
we
would
have
been
in
a
little
bit
better
spot
on
some
of
the
clarity,
maybe
even
the
size,
I'm
having
split
a
few
things
out
into
smaller
chunks
for
the
particular
release.
So
this
is
just
kind
of
taking
the
existing
process
a
little
bit
further
and
doing
something
synchronous
proactively
ahead
of
time
and
not
at
the
expense
of
12/8.
E
So
I
think
the
problem
with
12
date
is
that
12a
begins
like
we're
we're
almost
past
the
point
where
we
should
be
planning
for
12-8
and
at
that
point
we're
going
to
be
actively
changing
the
priorities
for
12-8
during
12
8,
so
that
that's
why
we
were
originally
targeting
12
9
is
because
it
seems
a
bit
late
on
in
terms
of
targeting
the
next
milestone,
because
12
8
is
basically
the
current
milestone.
All.
A
I
A
It
sounds
like
any
other
comments
on
it,
so
that
you
know
we're
over
on
time,
of
course,
but
any
other
comments
on
this
I
think
we
need
to
continue
the
conversation
shortly.
F
A
F
The
point
of
this
is
not
to
try
to
plan
out
twelve
nine
in
two
days.
The
point
of
this
was
to
get
feedback
early
as
to
what
might
what
issues
are
candidates
for
future
releases,
starting
with
12:9
and
beyond?
What
might
be
too
big?
How
might
we
get
to
smaller
iterations
within
these
individual
issues?
So
the
idea
here
was
to
get
that
feedback
as
early
as
we
could,
so
that
we
could
so
that
everything
could
be
gotten
into
shape
so
that
we
could
adequately
capacity
plan
for
12:9
and
beyond
right
now.
F
The
biggest
problem
that
we
have
is
that
there
is
no
such
thing
as
a
small
issue
within
this
stage.
We're
trying
to
get
to
that
point,
and
this
was
the
first
step
towards
it.
However,
if
it
is
a
higher
priority
for
visibility
into
what
is
being
committed
in
12-8,
then
we
can
hold
this
particular
conversation
for
looking
ahead
of
it
and
focus
in
and
and
get
everyone
comfortable
with.
What's
going
on
in
the.
A
12-8
its
visibility
and
confirming
it's
the
right
stuff
based
on
product
management
priorities.
If
we
do
that
for
twelve
eight
to
reconvert
to
review
with
product
management
or
planning
for
twelve
eight
and
make
sure
it's
the
right
things
from
their
perspective,
how
much
would
it
delay
us
from
getting
started
on
planning
out
12
nine,
at
least
a
week?
I
feel
like
that's
a
week
that
week
delay
would
be
unfortunate,
but
for
12
nine,
but
would
be
really
beneficial
to
12
eight,
so
I
suggest
we
do
12
eight.
A
Do
a
recon
confirmation
on
what's
going
into
twelve
eight
make
sure
Matt
and
Sam,
as
he
returns,
are
good
with
it
and
then
maybe
a
light
review
of
it,
not
a
detailed
review
and
then
and
then
we
go
into
exactly
what
you
described
for
12,
nine
and
not
believe,
delay
the
twelve
nine
discussions
for
more
than
a
week.
That
seemed
like
a
reasonable
compromise
way
to
go.
D
I'm,
in
terms
of
there
now
I
mean
this
should
be
a
force
ranked
list.
You
know,
with
the
things
at
the
top
being
higher
priority
things
at
the
bottom
being
lower
priority,
I'm
happy
to
review
that
with
Sam
and
Derek
on
the
laughs,
stuff
and
I'm
sure
Matt
would
be
as
well
just
to
give
a
yep
it's
in
the
correct
order
or
not.
Four.