►
From YouTube: 20191022 Kubernetes SIG Usability
Description
[Himanshu] New Kubectl events command to replace kubectl get events KEP
[Tasha] Jobs to be done proposal! https://docs.google.com/document/d/1lkPQdBEw-Xb5GEZ48WnpBgQdZ01EmTBhjcxJBlu5qJs/edit#heading=h.xsg4f6e6yk0p
A
Fix
a
sodding
order
for
the
events,
command
and
I
discussed
it
in
the
60
li
meeting
and
there
it
came
up.
They
fear
our
existing
issues
with
the
events
because
of
the
dependency
under
the
get
so
proposal
was
made
to
move
the
events
come
on
under
the
get
and
make
a
separate
events
come
on
all
together,
so
it
will
not
be
dependent
on
to
the
gap
so
for
that
I
have
created
this
gap,
which
is
I'm
still
trying
to
improve
it.
But
it
has
couple
of
issues
noted
in
the
cap.
A
One
is
with
the
events,
come
on
and
one
one
more
with
the
watch
options.
I
forgot
work.
What
exactly
was
it,
but
there
are
two
issues
that
I
mentioned
there.
So
with
that
said,
the
6cl
I
mentioned
to
include
the
usability
so
I
want
to
discuss
what
will
be
our
approach
like
from
Sig
usability,
point
of
view
for
this
new
change.
A
B
B
A
So
here
is
the
cap,
so
in
reassembly
is
like,
as
mentioned
cube,
cereal
get
even
has
some
limitations,
so
I
included
like
what
are
the
current
limitations
and
why
it
can
be
moved
to
a
separate,
keep
cereal
event
come
on
so
which
agree
one
of
the
existing
watch
functionality
which
needs
to
be
extended,
and
one
is
for,
like
the
one
one
of
that
is
like
default.
Sorting
order
of
the
events
so
under
motivation
I
have
put
some
use
cases
for
the
existing.
A
What
she
linked
amount
that
are
proposed
in
one
of
the
separate
issue,
so,
for
example,
use
I
would
like
to
see
a
stream
of
create
or
update
events,
building
out
dates
or
any
other
event
type
or
let's
say
you
would
use.
I
would
like
to
see
a
time
of
events
so
and
based
on
this
motivation.
I
have
put
couple
of
examples
here.
So,
let's
say
like
propose
cube
serial
events
come
and
would
look
something
like
this.
A
It
will
present
everything,
but
in
the
sorting
or
a
based
on
last
time
stamp
or
let's
say
user-
want
to
see,
watch
the
events
for
the
delete
action,
so
it
will
be
used
something
like
this
and
then
some
of
the
commands.
These
are
the
pretty
standard
commands
that
I
copied
from
get
which
can
be
changed
later
on.
But
for
now
these
are
the
ones
that
that
I
thought
would
be
good
to
start
with,
and
then
in
that
cap
I
have
discuss
some
of
the
long
standing
issues
regarding
this
one.
A
Oh,
this
is
already
mentioned
here,
could
see
real
events
sorting
order
and
there
is
improved.
The
watch
behavior
for
the
events
and
the
third
one
is
like
give
the
timeline
of
the
events,
and
so
here's
a
short
goal.
It
says
that
I
had
an
experimental,
sub-command,
critical
events
up
come
on
and
with
the
queue
peril
to
me,
move
them
existing
events
from
clips.
A
A
Then
there
are
some
implementation.
Details
like
trying
to
roll
out
in
in
two
phases.
First
is
like
introduce
a
new
command,
and
once
there
is
a
proper
adoption
of
the
new
command
and
the
the
old
instrument
can
be
removed
and
based
on
that
there's
a
graduation
criteria.
So
I
can
one
like
target
for
1.18.
We
can
use
a
new
command
and
then
it
can
be
removed
once
it's
jail,
the
whole
command
can
be
removed.
So
with
that
said,
that's
all
the
cap.
I
have.
B
A
B
You
know
or
due
to
the
constrictions
around
get
events,
so
I
think
you've
done
a
great
job
from
that
perspective
and
then
what
we
could
do
is
just
kind
of
share
your
cap
with,
like
some
notes
around
about
it
in
the
slack
channel
and
on
the
end
on
our
you
know,
agenda
and
then
see
if
we
can
get
more
feedback.
Okay,.
A
So
I
have
one
question:
the
dark
side.
I
did
mention
that
we
can,
you
know,
see
how
successfully
the
command
is
adopted.
So
this
is
new
to
me.
Actually,
so
is
right
now
in
communities
whenever
we
are
adding
a
new
command
or
introducing
a
new
feature,
how
we
are
measuring
that,
against
the
you
know,
adoption
of
the
users.
B
So
the
only
other
thing
that
I
had
to
share
is,
after
our
meeting
a
couple
weeks,
our
regular
Mike
meeting
a
couple
weeks
ago.
I
did
meet
with
people
who
said
that
they
were
interested
in
discussing
putting
together
jobs
to
be
done
proposal,
and
so
we
put
that
together
and
the
link
was
shared
in
the
chat.
So
I
will
just
quickly
with
everybody,
so
you
can
see
it,
but
basically
what
we
were
looking
at
is
jobs
to
be
done.
B
Just
kind
of
understanding
better
who
are,
who
are
the
main
users
of
kubernetes,
so
sometimes
I
think
we
all
are
a
little
worried
from
the
upstream
perspective
that
we
are
all
creators
of
kubernetes,
but
when
that
may
not
be
reflective
of
your
more
generic
users
and
so
really
making
sure
that
we
understand
who
are
the
users
of
kubernetes,
what
jobs
are
they
trying
to
get
done
with
kubernetes,
and
are
we
meeting
that,
both
through
the
user
experience
and
the
documentation,
experience
and
the
getting
started
experience
right
like?
So?
B
B
An
initial
proposal
on
what
a
jobs
to
be
done
study
is
what
it
looks
like
what
we
would
like
to
get
out
of
it,
and
so
the
first
thing
is
sort
of
just
starting
to
think
about
what
our
users
and
what
their
core,
what
the
core
functional
jobs
of
those
users,
would
be
breaking
that
down
into
steps
and
then
uncovering
desired
outcomes.
So
we
think
that
that
could
be
interesting.
B
We
also
think
that
this
might
end
up
being
something
that
we
could
start
kicking
off
like
in
a
very
holistic,
like
not
super
data-driven
way
at
coop
con,
because
it
is
an
end
user
conference
at
the
end
of
the
day,
and
so
it
might
be
a
really
great
spot
for
us
to
just
kind
of
post
up
and
be
like
hey.
You
know
what
are
you
trying
to
do
with
kubernetes
and
like
ask
a
bunch
of
people,
so
this
was
kind
of
our
initial
past
edit?
B
B
B
Con
coming
up
is
actually
a
great
potential
source
of
information
for
us
as
a
cig,
so
putting
together
some
sort
of
plan
about
how
we
could
get
people
to
you
know
tell
us
more
about
why
they're
interested
in
kubernetes
and
then
make
sure
that
we
kind
of
understand
as
an
upstream
community
like
who
are
user
end-users
and
like
what
do
they
need
and
kind
of
formalizing
that
a
little
bit
so
I
think
that's
it
for
me.
Yes,
alistair,
I
will
send
you
the
link.
C
Briefly,
I
wanted
to
get
some
opinions
on
the
content
for
the
deep
dive.
I
have
a
bunch
of
content
written
up
on
the
subject
of
doing
more
security
faults
around
things
like
network
policy
and
so
on,
but
I
wanted
to
see
if
folks
had
basically
other
content
they
wanted
to
see
represented.
So
I
don't
just
kind
of
go
into
a
rabbit
hole
there.
C
B
D
C
B
C
B
B
Yeah,
so
yes,
so
obviously
like
for
the
intro,
what
I'm
basically
gonna
be
doing
is
just
like
here's.
What
we're
doing
like
here's,
how
you
get
involved
in
the
intro
sessions
and
my
experience
are
people
who've,
never
interacted
with
the
open-source
community
at
all?
So
it's
very
much
like
this
is
where
github
is
like.
This
is
how
you
get
started
so
I.
Think
then
diving
into
these
things
will
be
perfect
for,
like
the
more
like
the
deep
dives
tend
to
attract
like
the
more
like
involved.