►
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
Welcome
to
our
container
security
group
conversation
thiago:
do
you
want
to
kick
us.
B
C
A
Right
I
mean-
I
think
this
one
I
put
in
here
a
few
days
ago
ago
or
no-go
decision
for
policy
management.
I
think
I
think
we're
gonna
go
exactly
well
decided
on
a
go.
So
that's
a
big
win
right
issues.
Closed
I
mean
talk
about
ethics,
closed
right,
perhaps
an
even
bigger
deal.
B
Yeah
quite
excited
a
few
things
to
polish,
but
the
the
the
bulk
of
it
is
there
your
last
emma
arthur
I've,
been
I've
been
trying
to
shepherd
it
through
the
the
maintainer
said,
he's
happy
with
it,
but
he
ran
out
of
time.
So
hopefully
that
doesn't
put
us
into
a
tight
spot
with
with
merging
it
tomorrow,
but
at
least
the
other
stuff
is
already
live.
B
So
if,
if
this
one
doesn't
go
through
it's
annoying
because
we
don't
get
the
feature
flag
turned
off,
but
it's
it's
enabled
and
gets
locked
in
gitlab.com.
A
B
A
It
should
make
it
probably
we'll
make
it
in,
but
we'll
see
it
sounds
like
yeah
great.
Just
a
note
on
that.
I
did
update
our
priority
today,
just
to
move
some
of
those
bug
fixes
and
up.
I
just
did
a
small
reshuffle
priority
there
to
make
sure
that
we
close
those
out
early
on,
so
we
don't
have
bugs
hanging
out
for
a
long
time.
B
I
noticed
it
think,
thanks
for
that
I
had.
I
did
a
a
a
pre-planning
last
week
so
this
week
I
need
to
just
finish
polish
up
the
the
stacking
anything
that
you
might
have
added,
get
them
refined
and
get
get
it
ready
for
the
for
friday.
I
think,
is
kickoff.
A
Sounds
good
all
right,
so
then,
my
next
question
is
all
about
13.5
and
I
put
in
a
couple
other
notes
there
down
in
the
planning
breakdown
section
as
well
pretty
late.
I
put
those
in
today
right
after
right
before
the
meeting,
but
the
question
is:
what
are
we
confident
in
in
delivering
for
13.5?
Is
there
anything
that
I
should
highlight
in
the
release?
Kickoff
video,
we're
planning
to
record
that
tomorrow.
B
B
Yeah
so
I
I
don't
feel
super
confident
about
calling
alert,
dashboard.
B
The
design
yeah
we
can
probably
we
can
probably
finish-
they're
reorganizing-
that
that's
one
thing
you
you
can
call
out.
I
don't
see,
I
don't
see
a
big
risk
on
that
one,
the
bugs
I
don't
know
if
it's
interesting
to
mention,
but
the
alert
would
have
been
the
big
one,
and
at
this
point
I
I
I
can't
say
for
sure.
A
So
then
I
guess
that
takes
us
down
to
our
planning
breakdown
section.
I
know
we've
already
done
planning
breakdown
on
alert
management,
but
that
was
quite
a
while
ago.
So
just
wanted
to
ask.
Would
it
be
useful
to
take
some
time
to
go
back
and
and
take
another
look
at
that?
Do
you
have
any
questions
for
me?
You
know
anything
we
can
cover
there
or
is
it
crystal
clear.
B
I
don't
know
about
crystal,
but
I
think
it's
plenty
clear.
I
do
expect
zamir
to
have
some
questions.
I've
asked
him
to
refine
that
one.
I
don't
know
if
arthur
has
any
questions,
but
I
wouldn't
expect
arthur.
Do
you.
D
D
A
Okay
and
then
my
last
question:
did
we
decide
which
ux
approach
we
want
to
go
with?
Kyle
gave
us
two
designs.
A
A
D
A
Yeah,
so
it's
not
quite
done,
but
the
response
has
been
very
positive
on
that
kanban
style
layout.
So
almost
certainly
we
do
want
to
do
that
in
the
long
run.
So
again,
I
I
just
don't
know
how
much
throw
away
work
there
is
like.
If
you
tell
me
it's,
you
know
just
to
go
with
extremes
here
for
an
example.
If
you
tell
me
it's
five
minutes
of
throwaway
work
to
do
the
cable
layout,
you
know
then
I'd
say
well.
A
Yeah
just
do
the
table
layout,
we'll
come
back
to
the
kanban
one
layer
later,
but
on
the
other
hand,
if
you
tell
me
well,
you
know
it's
ten
iterations
of
throwaway
work
again
going
with
extremes
right
then
I
would
say:
well,
let's
just
do
the
end
state.
Let's
not
worry
about
the
the
initial
table
view.
So
I'm
just
trying
to
understand
you
know
what
does
that
cost?
The
end
state
is
the
kanban
style
layout
though,
but
we've
gotten
some
really
good
feedback
on
that.
It
seems
like
you.
It
really
is
resonating
well
with
users.
D
Yeah
the
thing
is:
what
monitor
uses
right
now
is
small
standard
for
github.
There
are
reusable
components
for
that
in
github
ui,
so
even
if
you're
not
going
to
reuse
anything
from
the
monitor,
it's
still
much
easier
to
implement,
because
I
can
just
get
components
out
of
the
library
and
put
it
on
the
screen.
There's
the
board
style.
It's
a
bit
tricky,
because
those
components
are
not
reusable.
B
So
arthur
without
without
committing
ourselves
to
to
an
estimate
that
simpler
layout,
do
you
think
that
that
takes
more
than
an
iteration?
Do
you
think
that
fits
in.
D
An
iteration
layout
itself
is
in
table,
like
the
ones
that
monitor
uses
is
pretty
simple.
I
think
at
least
what
I
remember
in
my
head
right
now,
so
it
spreads
it
hard.
It's
definitely
doable
in
one
cycle
again,
it's
just
a
table
with.
B
D
Buttons
I.
B
D
Just
saying
that,
if
the
board
is
end
goal,
there
is
no
point
doing
this
hardest
part,
and
by
that
I
mean
creating
or
extracting
components
for
the
board,
because
the
lanes
like
using
tables
right
now
does
not
bring
you
any
quite
any
step
closer
to
the
boardway.
B
D
B
D
Remove
it
and
then
because
it's
so
drastic
it's
probably
needs,
wouldn't
we
would
need
a
feature
for
echo
and
wasting
not
the
development
one,
so
user
could
just
transition
into
that
stuff.
So
essentially
doing
it.
This
way
from
my
understanding,
like
the
process
inside
github,
is
just
delays.
It
way
more
than
necessary.
That's.
D
A
A
I
I
want
to
point
out
that,
even
though
it
may
not
be
iteration
in
the
engineering
sense
like
it
may
not
get
the
engineering
team
any
closer
to
the
end
state,
the
mvc
would
allow
us
to
deliver
value
to
the
customer
sooner
where
you
know
they
could
be
able
to
at
least
use
it
early
on,
and
so
I
think
that's
kind
of
the
trade-off
that
I'm
weighing
in
my
mind
is:
do
we
get
something
to
the
users
right
away
at
the
expense
of
engineering
work?
Or
does
the
user
have
to
wait?
A
C
C
A
I
think
the
epic
is
not
written
up
for
that
right
now,
so
we'll
have
to
make
some
changes
to
the
the
which
mocks
are
attached
to
the
epic
and
the
requirements
of
the
description,
but
I
would
rather
not
kill
a
whole
iteration
of
engineering
work.
We
only
have
you
know
two
developers
here
so
yeah.
Why
don't
we
go
forward
with
that
kanban
style
for
now,
and
I
will
let
I'll
talk
it
over
with
david
I'll?
Let
you
know
if
that
decision
changes.
B
B
A
Okay,
so
so
for
the
decision,
let's
say
we'll
start
with
the
back
end
work
and
revisit
the
front
end
decision
as
we
get
closer
thanks
for
taking
notes,
but
for
now
plan
on
the
kanban.
A
A
Great
any
other
questions
on,
or
topics
that
we
should
discuss
with
the
group.
A
A
I
think
it's
going
to
lower
the
bar
significantly
for
new
users
who
are
trying
to
write
network
policies
and
it's
going
to
be
a
huge
win
just
through
security
overall,
as
we
start
to
deliver
these
features
and
make
it
easier
for
for
companies
and
individuals
to
start
including
security
in
their
projects
where
they
were
not
necessarily,
you
know
full-on
security
experts
before
or
perhaps
even
kubernetes
experts,
because
there
are
a
lot
of
security
experts
in
the
world,
but
don't
know
very
much
about
kubernetes,
so
I'm
really
excited
for
where
we're
headed
and
look
forward
to
diving
in
on
alert
management.
B
Me
too,
congratulations
well
done
arthur
and
zamir,
and
and
I'm
looking
forward
to
hearing
feedback
from
from
people
using
this.