►
From YouTube: Coffee Chat about the Protect Stage Development Process
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
So
we
actually
do
this
a
little
bit
different
from
all
of
the
rest
of
kit
lab
for
better
or
for
worse,
but
the
process
has
actually
worked
really
well
for
us,
so
we've
stuck
with
it
now
for
more
than
a
year,
essentially
as
a
product
manager,
I'm
in
charge
of
priorities.
First
and
foremost,
I
mean
that's
one
of
the
most
core
responsibilities
for
my
job
so
to
manage
those
I've
actually
created
a
priorities
board
or
priorities,
issue
that
stays
open.
You
can
see
this
is
created
more
than
a
year
ago.
A
We've
left
it
open
that
entire
time,
and
for
my
group
in
particular,
we
are
a
little
bit
unique
in
that
we
have
some
pretty
specific
guidance
and
how
we
should
be
allocating
our
time
between
our
different
categories.
So
we
have
a
security,
orchestration,
category
container,
scanning
category
container,
host
security,
and
you
can
see
here
the
target
allocation
and
how
many
engineers
we
currently
have
working
on
each
of
these
categories.
A
So
you
can
always
come
in
here
and
see
how
that
maps
to
each
of
these,
in
fact,
we're
down
one
engineer:
we
just
hired
another
one
so
probably
bump.
One
of
these
up
by
one
either
container
scanning
will
go
from
one
to
two
or
we'll
allocate
someone
to
container
host
security
here
in
the
near
term.
A
So
these
are
kind
of
the
core
priorities.
Not
all
of
these
epics
require
front-end
work,
though
so
at
the
bottom.
We
also
have
a
front-end
priorities
table,
and
these
are
just
repeats
of
the
things
that
are
in
the
other
categories,
but
specific
to
things
that
require
front-end
work.
So
that
way
the
back-end
team
can
come
in
and
they
can
allocate
their
resource
resources
accordingly.
A
They
can
start
them
on
the
top
priority
items
and
have
them
work
down,
and
the
same
is
true
for
the
front
end
team,
where
they
have
their
priorities
and
they
can
pick
things
off
the
top
and
work
their
way
down.
So
at
a
really
high
level.
This
priorities
issue
is
where
everything
starts
if
it's
related
to
new
feature,
work
and
I'll
talk
about
like
bugs
and
tech
debt
here
in
a
minute,
because
those
are
handled
a
little
bit
differently.
But
if
it's
new
feature
work,
it
always
starts
from
these
priority
issues.
A
A
This
is
always,
of
course,
subject
to
change,
but
you
know
a
rough
estimate
when
we
think
we
can
have
that
completed
and
released
to
customers,
and
we
actually
broke
that
one
into
two
pieces,
this
one's
a
little
bit
unique,
but
for
iteration
purposes
we
broke
it
into
two
pieces
for
the
front
end
team
priorities,
one
a
and
one
b
and
at
the
moment
we
only
have
one
front
end
engineer.
So
the
dri
is
the
same
for
all
of
them.
It
makes
it
a
little
bit.
A
You
know,
makes
it
simple,
but
we
just
work
our
way
down
all
of
these,
and
so
we
do
actually
follow
the
workflow
process
of
the
rest
of
gitlab.
So
if
I
come
into
cluster
image,
scanning
may
not
be
the
best
one,
but
let
me
see
if
there's
a
good.
A
A
Well,
let's
look
at
this
cluster
image
scanning
anyway,
and
we'll
take
a
look
at
how
we
did
this,
so
we
actually
create
these
high-level
priority
items
as
an
epic,
because
that
allows
us
to
spread
the
word
between
front
end
and
back
end.
It
allows
us
to
group
everything
together.
We
can
keep
our
design
issue
in
here
as
well.
So
this
is
where
we
differ
from
a
lot
of
the
rest
of
git
lab,
where
they
typically
have
an
issue
to
track
the
work
we
found
that
just
became
overly
hard
to
keep
track
of
everything.
A
So
we
put
all
the
requirements
up
in
the
epic
you'll
see
the
designs
here
once
the
design
work
is
completed
and
finalized,
we
actually
close
out
our
design
issue,
and
then
we
copy
the
designs
up
to
the
description
of
the
parent
epic.
So
that
way,
we
always
have
one
place
to
go
for
product
management
requirements
as
well
as
ux
designs
and
then
for
iteration
purposes.
We
can
break
this
down
as
much
as
we
want
into
sub
epics
or
individual
implementation
issues
that
can
be
assigned
out
to
the
front
end
and
back
end.
A
A
It
then
moves
into
ready
for
design,
at
which
point
we
create
a
design
issue,
and
you
can
see
the
design
issues
here,
they're
easily
noticeable,
because
they've
got
that
little
icon
and
prefixed
with
the
design
label.
And
if
we
come
into
any
of
these,
you
can
see
we've
designed
out,
for
example,
some
of
the
policy
error
states.
A
This
is
going
to
be
assigned
out
to
the
ux
designer
they're,
going
to
iterate
on
the
mocks
in
here
and
then
only
once
the
blocks
are
finalized
and
they've
decided
that
this
is
what
we're
going
with
then
they'll
close
out
this
issue,
they'll
copy
these
designs
and
they'll,
put
them
up
on
the
parent,
epic
and
then,
once
all
of
that
design,
work
is
complete,
so
typically
like
a
new
epic,
for
this
won't
have
all
of
these
sub
issues
in
it.
A
Because
that's
just
really
overwhelming
and
we're
not
even
ready
to
work
on
it,
so
normally
this
actually
will
be
really
blank.
We'll
just
have
the
parent,
epic
and
then
we'll
just
create
the
design
issue.
In
fact,
I
can
show
you
an
example
of
another
one.
That's
kind
of
in
that
state
right
now,
where
here
we're
looking
out
at
the
option
of
giving
the
ability
to
approve,
merge,
request
approval
rules
individually.
So
right
now,
there's
an
approve
button
that
just
approves
everything
that
you're
eligible
to
approve
we're
talking
about
potentially
breaking
this
out.
A
So
you
can
approve
these
things
separately,
one
by
one.
So
we've
got
our
parent
epic.
Here
we've
linked
some
of
the
user
research
that
led
to
this.
We
have
a
design
issue.
That's
created
specific
to
work
out
the
designs,
but
you'll
notice,
there's
actually
no
front-end
issues
or
back-end
issues
in
here
we're
not
trying
to
work
out
the
implementation
details
yet
because
we're
not
ready
for
it.
So
there
just
isn't
work.
A
You
know
we
don't
get
those
those
don't
show
up
on
the
boards
planning
boards
for
the
front
end
team,
because
we're
not
ready
for
them
to
do
that
work.
Yet
so
those
don't
even
exist
at
all.
All
the
product
requirements
and
discussion
is
happening
at
the
epic
level
and
then
again,
once
this
finishes
out
once
we
finish
the
design
we'll
move
this
from
this
actually
should
be
workflow
ready
for
design,
because
I
think
we've
had
enough
validation
at
this
point
and
once
that
goes
through
design,
then
we'll
move
it
into
workflow
planning
breakdown.
A
When
we
do
that,
we'll
discuss
in
our
weekly
team
meeting
and
have
all
of
the
engineers
review
it
just
to
make
sure
that
they
don't
have
any
questions
or
concerns
or
things
that
need
to
be
clarified
that
they
that
we
didn't
think
about
when
we
did
the
designs
or
the
requirements,
assuming
that
it's
all
clear
and
they
understand
what
needs
to
be
done,
and
why
then
we
move
it
into
workflow
refinement
and
when
it
goes
into
workflow
refinement,
then
it
gets
assigned
out
to
an
individual
front-end
and
an
individual
back-end
engineer
to
do
that,
refinement.
A
We
actually
can't
assign
out
epics
right
now,
which
is
unfortunate
so
right
now
we
just
handle
that
by
putting
a
message,
just
adding
a
comment
saying
this
is
ready
for
refinement
and
we
tag
the
appropriate.
You
know
all
tag
the
em
and
the
em
will
assign
that
out
by
tagging,
one
of
their
individual
engineers
to
do
that
refinement.
A
As
part
of
that
refinement.
The
engineer
is
responsible
for
fleshing
out
all
of
the
implementation
steps.
So
that's
really
the
point
where
they
start
to
create
all
of
those
other
issues
that
are
nested
inside
of
this
epic
and
usually
at
that
point
it's
getting
pretty
close
to
being
ready
for
development.
B
No,
no
thanks
for
the
overview,
I
think
so
a
follow-up
question
for
you.
If,
if
you
are
kind
of
finished
going
through
the
process,
this
is
very
insightful.
I
think
it's.
So
how
do
you
guys
even
have
a
backlog?
Because
I
mean
I
think
the
the
problem
is
that
we
start
a
lot
of
the
times
with
an
issue
and
then,
if
the
issue
is
large
enough,
we
promote
to
an
epic
because
sometimes
we're
getting
issues
created
by
you
know.
We
have
legacy
issues
either
created
by
engineers
or
engineer.
B
I
guess
like
product
managers
of
like
hey.
These
are
ideas
you
want
to
explore
and
then
an
issue
gets
created.
It's
not
really
flushed
out,
but
they
want
to
track
that,
like
maybe
we
got
feedback
from,
I
guess
cut.
You
know
customer
support,
but
this
is
a
feature
that
a
customer
is
asking
for
and
they
just
create
an
issue
to
kind
of
track
it
and
it
just
gets
dumped
in
the
backlog.
B
If
you
don't
mind,
if
I
can
share
my
screen
or
yeah
like
the
view
that
we're
looking
at
that
was
kind
of
concerning
was
so
we
have
this.
Let
me
see,
I
think,
it's
add,
milestone.
B
B
B
It
was
just
kind
of
something
that
was
like
you
know
along
felipe
is
this
is
a
security
engineer.
B
So
I
guess
that's
where
things
were
a
little
bit
ambiguous
like
what
we
were
gonna
do
as
a
theme
process,
because
you
know
we
have
right
now.
I
guess
does
not
account
up
here
for
the
number
of
open
issues,
but
there
are
pages
and
pages
and
pages
of
things
that
are
over
three
years
old.
So
what
we
had
was
an
automation
script
that
one
of
the
engineers
in
our
team
created
to
like
bulk,
close
anything
older
than
three
years.
B
The
idea
would
be
if
anyone
disagreed
with
closing
that
issue,
that
they
could
reopen
it
if
they
still
think
it's
still
valid
or
hey.
We
definitely
need
to
do
this,
but
then,
at
the
same
time,
if
it
was
a
high
priority
would
have
already
been
looked
at
in
that
three
years.
Still
so
my
concern
was
that
okay,
we
bought
close
fees,
they
were
still
how
do
we
ever
get
back
to
it?
If
it's
something
that's
interesting,
you
know
something.
B
You
eventually
want
to
do
right,
but
you
know
we
it's
still
recorded
in
history,
because
it's
still
an
issue,
but
it's
closed
now.
So
do
we
close
them,
but
then
apply
label
like
vintage
or
like
still
desirable,
but
not
you
know
high
priority.
You
know
some
label
to
convey
that
meaning.
So
in
that
process
I
kind
of
ran
into
the
was
it
this
milestone
awaiting
further
demand,
which
has
a
bunch
of
issues
in
it.
I
just
don't
understand
the
workflow,
for
this
is
that
are
these
issues
that
are
currently
open?
B
Don't
belong
in
the
backlog,
but
we
can,
you
know,
still
need
more
demand.
So
to
me
it
seems
this
is
like
the
like:
a
deep
backlog.
If
you
want
to
say
that,
because
it
here
the
definition,
the
description
is
indicates
that
an
issue
has
been
triaged
but
not
yet
on
the
backlog.
B
So
that's
why
I
was
saying
like
if
we
have
a
bunch
of
stuff
in
the
backlog
that
may
be
desirable,
but
it's
not
a
high
priority.
We
can
push
it
back
into
waiting
for
for
the
demand
to
clear
up
that
backlog,
but
you
know,
and
then
the
other
thing
is
if
we
were
going
to
try
to
we're
trying
to
clean
it
up
so
like
we,
even
if
we
adopt
the
process
that
protect
has
going
forward.
What
do
we
do
of
all
the
other
ones
that
are
legacy?
B
And
that's
that's
the
the
kind
of
part
that's
a
bit
ambiguous
for
us.
B
So
we've
experimented
with
the
idea
of
auto
closing
ones
that
are
older
than
a
year
or
two
and
then
applying
like
an
auto
closed
label,
and
then
then
the
archive,
I
think
archive
label
to
indicate
that
they
were
archived
and
then
the
idea
being
that
if
you
wanted
to
search
for
issues
that
were
probably
still
desirable
but
no
we're
near
in
the
radar,
if
they're
very
old,
you
could
search
closed
issues
by
archive
you
know,
but
then
you
know
these
are
the
process,
things
that
are
not
standard
at
gitlab
right
now.
B
So
then
you
know
my
concern
is
closing
them
out
and
then
not
having
everyone
on
board
on
a
standard
approach
to
do
that.
So
the
real
question
comes
down
to
this
is:
what
do
we
do
with
issues
that
are
very,
very
stale?
Do
we
close
them?
Do
we
leave
them
open
and
apply
certain
labels?
We
leave
them
open
and
move
them
to
a
different
milestone.
B
We
close
them
and
move
them
to
a
different
milestone
and
that's
what
I've
been
trying
to
kind
of
reach
out
and
get
a
feel
for
from
different
product
managers,
because
I
feel
like
things
like
that
are
in
the
backlog
you
know,
are
accessed
by
developers,
engineer
managers
and
product
management,
so
I
didn't
know
an
ideal
approach
and
especially
since
that
backlog
that
I
was
showing
you
before
is
for
the
all
secure-
and
this
is
the
the
issue
right.
B
A
Relevant
yeah,
if,
if
this
you
know
like
that
issue
that
you
showed
you
know,
add
support
for
us.
For
example,
if
that
was
a
thing
on
the
protect
side,
I
can
tell
you
what
we
would
do
with
those
chocolate.
That's
used
sure
you
know.
Obviously,
you're
gonna
have
to
figure
out
what
works
best
for
for
you
and
for
your
group
and
for
your
stage,
but
for
us
the
approach
that
we
would
take
is,
first
of
all,
that
would
be
promoted
to
an
epic,
because
that's
a
new
feature
request.
A
A
A
And
if
it
does,
then
we
actually
end
up
adding
it
in,
and
I
think
the
the
secure
stage
uses
this
as
well,
just
perhaps
not
in
the
same
way.
But
let
me
share
my
screen
again
here
for
a
second.
A
Let
me
pull
up
one
of
these,
like
more
granular
vulnerability
checks,
so
this
ends
up
getting
nested
in
an
epic,
a
structure
of
epics
where
at
the
high
level,
we
have
our
vision
for
all
of
container
security
for
the
entire
container
security
group.
And
then
you
can
see
a
different
epic
in
here
for
each
of
the
categories
that
we
own
and
then
each
of
these
get
broken
down.
A
You
know
here's
what
we
needed
to
do
to
take
security
orchestration
from
plan
to
minimal
it
was
what
we
need
to
do
to
go
from
minimal,
viable,
viable
to
complete,
complete
to
lovable,
and
so
that
epic,
assuming
it
is
part
of
our
long-term
vision
and
strategy,
it
would
get
nested
within
one
of
these
and
that
alone,
just
by
nesting
that
that
automatically
gives
some
semblance
of
priority.
Because
if
we're
at
minimal
today-
and
it's
in
the
complete
to
lovable
category,
then
we're
not
getting
to
that
for
a
really
long
time.
A
A
That
way
they
don't
show
up
on
the
issue
boards.
You
know,
so
they
don't
muddy
the
waters
for
like
milestone
planning
for
development.
They
also
would
get
bucketed
correctly
up
here,
like
complete
to
lovable
epics.
Actually,
don't
have
milestones,
so
we
don't
even
have
the
problem
of
putting
it
in
the
backlog
versus
not
it's
just
kind
of
self-apparent
by
where
it
falls
here
and
then
just
by
default.
Everything
is
kind
of
on
the
back
really
long
back
burner
unless
it's
almost
priorities
issue
you
know.
A
So
this
priorities
issue
is
our
near-term
backlog
and
as
these
things
come
through,
so
I'm
going
to
evaluate
that
that
item
you
know
adding
support
for
rust.
For
example,
I'm
going
to
ask
myself:
does
that
fall?
You
know
which
bucket
does
that
fall
in
first
of
all,
is
that
in
my
vision
and
then,
which
bucket
do
I
want
to
put
it
in,
you
know,
is
that
something
that's
needed
to
get
the
lovable
or
complete
or
viable?
If
it's
needed
to
get
diviable,
then
I
would
say:
okay,
you
know
we're
working
on
that
right
now.
A
A
But
you
know
this
list
really
is
just
representative
of
more
the
next
12
months,
we'll
say
of
what
we've
got
in
vision
and
everything
else
would
just
sit
there
as
an
epic,
but
there
would
not
actually
be
an
issue
associated
with
that
until
it
got
to
the
refinement
phase,
which
you
know
out
of
all
of
these,
the
only
ones
that
have
gone
through
refinement
are
really
like.
You
know
items
one
and
two
for
example,
so
it's
not
like
we
have
all
of
these
refined.
B
I
guess
what
I
can
do
is
share
this
recording
and
basically,
if
we
were
going
to
adopt
that
approach,
I
mean
we
need
buy-in
from
a
lot
of
different
people
on
that
we
work
with
in
our
group,
but
if
they
did
theoretically,
then
we
would
have
to
basically
go
through
all
those
issues
in
that
backlog
and
make
sure
that
we
have
like
the
breakdown
of
the
epics
and
stuff
epics,
see
if
they
fit
in
any
of
those
buckets
and
for
the
ones
that
don't
and
aren't
aligned
with
priorities.
B
You
can
just
close
them
out
if,
if
we
were
adopting
that
approach
I'll
I'll
take
the
info
that
you've
given
this
is
very
enlightening,
so
I'll
share
it.
If
you're,
okay,
with
that
I'll
stop
the
recording.
Now,
if
there
was.
A
There's
a
little
bit
more
worth
noting
in
here
just
real
quick,
so
I
I
just
want
to
call
out
that
it
seems
overwhelming
like
oh
now,
we
have
to
go
through
300
issues
and
either
promote
them
to
an
epic
get
rid
of
them.
You
know
you
can
actually
do
that
in
an
iterative
fashion,
which
is
what
we've
done,
because
we
switched
over
to
this
about
a
year
ago.
We
still
have
issues
plus
you
know,
container
scanning
moved
from
secure
over
to
protect
and
all
of
those
issues
came
over
with
it.
A
So
we
actually
have
a
lot
of
issues
that
are
still
out
there
in
the
backlog,
including
one.
I
think
that
you
found
and
I'm
like.
Oh
you
know
that
should
actually
be
promoted
to
an
epic
right,
so
we
still
have
cleanup
work
to
do
on
our
site
as
well,
but
it's
possible
to
do
that
in
an
iterative
fashion.
It's
not
like
you
have
to
go
through
all
300
to
switch
over
to
this
process.
You
can
do
that
slowly
over
time.
A
B
That
makes
sense
so,
okay,
I'll
take
all
this
feedback
and
just
I'll
try
to
share
it
with.
I
guess:
neil
who's,
the
engineer
manager
on
our
team
and
reach
out
to
the
other
product
managers
on
our
team
to
kind
of
see
a
feel
for
it.
I
I
think
in
the
near
future,
though,
for
what,
because
we're
trying
to
just
prune
that
backlog
right
now,
I'll
we'll
probably
have
to
come
up
with
some
other
alternative
intermediary
process.
A
A
It's
also
worth
noting
too
separate
from
that
that
we
do
leave
bugs
and
tech
debt
items
as
issues
and
that's
because
they
don't
they're
not
like
strategic
items.
They
don't
fall
into
that
long-term
vision
and
they
also
typically
don't
need
to
be
broken
down
into
smaller
things,
so
keeping
it
just
as
one
single
issue
usually
works
really
well
for
us.
B
Okay,
awesome:
I
appreciate
you
taking
time
out
of
your
day
to
kind
of
reach
out
and
cover
it.
Yeah
appreciate
all
the
effort
you
put
into
it
too.
So
I'll
I'll
share
the
video
and
hopefully
we'll
you
know,
be
able
to
adapt
some
of
that
processes
from
based
on
what
I've
seen
it
seems
very
practical
and
efficient.
So.