►
From YouTube: Technical Oversight Committee 2021/06/21
Description
Istio's Technical Oversight Committee for June 21st, 2021.
Topics:
- Prioritization of Documentation Testing
A
So
last
year
we
got
a
great
guidance
from
the
toc
members
on
that
one
pager
office
deal
strategy
for
2021,
but
we
started
very
late.
So
it
was
a
rush
rush,
which
was
also
helped
for
the
kubecon,
which
will
also
help
to
set
up
the
roadmap
for
the
individual
working
group
leads.
But
I
would
like
to
start
now
that
the
july
is
starting.
A
A
C
A
So
that's
a
great
question
if
we
start
like
since
the
july
started
right,
if
we
get
that
done
by
end
of
august,
that
will
be
a
great
time
ahead,
for
the
working
group
needs
to
start
their
yearly
roadmap.
So
it's
not
in
the
middle
of
the
release
right
and
they
are
done
by
october
end
of
november,
so
that
we
are
ready
for
the
next
year.
B
E
B
E
B
C
D
A
The
late
november
nina
is
late
for
the
virginia
pleats,
because
that's
the
time
of
our
release
too,
we
normally
releases
the
first
week
of
december,
so
they're
not
and
then
last
two
weeks
are
holidays,
so
the
working
completes
are
never
able
to
complete
by
the
end
of
the
year.
Ideally
the
things
from
the
toc
and
the
working
lease
should
be
completed
in
in
december
right.
So
we
are
ready
for
q1.
G
C
E
B
I've
had
one
release
worth
of
feedback
on
it.
1.1
releases
worth
of
feedback
on
our
progress
so
yeah
I
tend
to
agree.
Obviously
it's
not
something
we
can
start
now.
So
I
guess
we'll
have
a
third
release.
In
august
we
would
had
two
in
a
bit
releases
worth
of
a
bit
worth.
It
release
a
little
feedback
if
we
can
deliver
roadmap
at
a
mid
to
late
october,.
D
A
C
So
trautin
I
was
creating
this
year's
roadmap
right.
I
am
mostly
with
help
from
other
plc
members.
For
me,
the
ux
working
group
feedback
and
in
general,
some
survey
feedback
and
doing
the
empathy
session.
It
was
clear
that
day
two
operations
was
a
problem
right,
so
all
of
that
fit
nicely
into
the
day
two
operations
theme
of
the
year.
C
A
So
then,
there
are
two
things
here
right:
one
is
the
straw.
Man
bullet
point
sheet
right,
two:
what
kind
of
service
we
need
right,
because
we
still
have
enough
time
to
collect
the
user
feedback.
Then
we
should
start
thinking.
Okay.
What
do
I
need
to
make
sure
that
I
have
enough
information
to
create
this.
C
C
G
G
G
E
G
Sorry
about
that,
we
we
do
have
the
first
question
on
the
survey
is
basically
how
much
upgrading
to
110
have
you
and
the
options
are
some
non-production
or
test
meshes
some
production
meshes
or
all
of
our
meshes.
So
that
should
give
some
signal
into
whether
it's
sort
of
an
evaluative
use
case
or
actually
in
production.
B
B
G
B
C
B
C
B
E
B
E
E
B
F
B
J
A
J
B
Right
I
mean,
I
think,
that
the
last
time
we
had
feedback
right,
it
was
significantly
bifurcated
right.
There
were
people
who
used
helm
in
part
because
it
was
the
standard
within
their
organization,
so
they
had
to
use
it.
They
felt
like
they
wanted
to
use
it,
and
then
there
were
people
who
weren't
in
that
boat
and
they
were
yeah.
K
B
J
B
J
H
I
I'm
not
entirely
sure
that
that
stopping
boat
is
is
necessarily
a
good
idea.
I
mean
easter
cattle
is
really
hermione
stewart
with
her
on
top
of
it.
Our
problem
is
not
that
we
have
issue
capital,
I
mean
operator.
Api
is
probably
the
problem.
The
fact
that
we
have
two
apis
and
it's
difficult
to
configure,
but
if
we
trim
down
the
the
you
know,
differences
in
the
api
surface
which
are
trying
to
do
then
helm
is
helm,
and
this
geocatal
is
a
wrapper
around
him.
C
C
E
B
E
C
But
recording
one
time,
that's
where
I
was
going,
I
think
for
those
new
apis,
I
mean
it's
great
you're,
releasing
them
but
expecting
a
hard
end
user
to
start
using
it.
It's
very
difficult
for
them
right.
If
they're
using
eastern
production
for
a
few
releases,
they
won't
just
go
and
configure
these
alpha
apis.
B
F
F
F
So
for
the
past
couple
of
releases,
I'd
say
back
back
since
I
don't
know
one
five
we've
tried
to
get
the
docs
working
group
and
the
work
group
leads
on
board
us
to
how
to
prioritize
doc.
There
are
testing
of
docs
for
different
releases,
what's
p0,
p1,
p2,
etc,
and
it's
always
a
challenge
to
get
everybody
on
board.
So
this
attempts
to
codify
that
in
a
in
a
way
that
we
can
automate
it
and
just
give
things
a
score.
So
eric
and
I
discussed
what
we
felt
was
important.
F
F
The
things
that
we
thought
were
important
are
what
areas
of
the
documentation
have
changed
and
how
much
greater
changes
in
documentation
are
more
likely
to
need
more
testing.
We
can
do
it.
What
areas
of
the
code
that
are
being
touched
by
this
documentation
have
changed
and
how
much
go
testing
has
a
trace
command.
I
haven't
tested
it,
but
that
might
give
us
some
sort
of
an
idea
there
does
the
document
already
have
automated
tests?
G
F
B
F
I'm
not
sure
I
understood
the
question
but
I'll
answer
what
I
thought
I
understood
for
that.
So,
for
instance,
the
what
areas
of
the
documentation
have
changed
would
receive
16
stars
the
what
areas
of
the
code
have
changed
would
receive
12
stars
based
on
a
number
of
lines
for
both
of
those
and
then
eight
for
the
next
one.
If
it
doesn't
have
any
testing,
then
it
receives
the
full
eight
stars
and
four
for
the
next
one
divided
by
paychecks,
and
then
these
would
all
be
added
together.
F
J
F
F
K
F
B
I
B
F
F
J
E
E
The
other
thing
I
want
to
say,
I
think
I
agree
with
niraj,
so
those
are
the
two
most
important
thing
is
whether
the
page
is
tested
and
also
you
know
how
popular
they
are,
and
we
think
whether
the
page
are
tested.
Brian
to
your
point,
early
on
some
of
our
tests
may
not
exactly
actually
test
us
through
what
the
user
would
tell
users
to
do.
E
It
would
be
nice
to
highlight
a
little
bit
on
that,
because
some
are
done
on
purpose,
and
I
knew
that
because
I
wrote
some
of
those
tests
and
we
had
to
test
a
slightly
different
them
because
of
a
tested
infrastructure
doesn't
have
like
real
key
hosts
and
search.
So
what
we
tell
user
is
actually
slightly
different
on
purpose
than
what's
been
tested,
so
that
might
be
used
for
information
to
highlight
forward
user.
C
Okay,
thanks
so
brian
just
just
to
you
know,
make
sure
I
give
my
feedback
correctly.
I
think
we
can
go
towards
something
more
smarter
and
like
rank
stacked
with
some
good
algorithm
in
it,
but
I
would
recommend
we
start
something
simpler,
see
how
it
goes
for
a
release
then
tweak
it
going.
The
other
way
is
very
difficult.
B
E
F
E
Yeah,
I
think
the
variant
to
indicate
with
tests
a
little
bit
different,
that
that's
valuable
to
the
user.
You
you
know
when
they
find
out
their
stuff,
doesn't
work
and
we
tell
them
that
we
did
test
a
little
bit
different
and
maybe
even
can
link
to
point
a
link
to
them.
This
is
what
we
test.
I
think
that
could
be
valuable.
F
E
F
K
E
E
Well,
user
would
be
helpful
yeah
when
they
look
at
issued
io.
They
can
see.
You
know
whether
the
test
is,
if
the
page
they
follow
through
and
find
a
problem,
they
can
at
least
tell
you
know,
wait.
This
is
not
fully
automated.
Okay,
I
see
there's
a
difference
of
what's
being
automated.
What's
what
I'm
achieving.
B
F
E
C
I
think
we
are
parsing
this
little
bit
from
a
developer
point
of
view
and
from
a
user
point
of
view,
so
right
so
we
are
trying
to
say
to
a
user.
We
have
tested
it
or
not
internally,
right
now,
the
whether
we
have
tested
it
or
not
is
the
indication
only
means
automated
testing,
that's
fine,
but
as
a
user,
if
you
tell
me
hey,
you
have
a
doc
and
it's
not
tested
it's
just
bad
right.
F
C
Agree
so
there
are
pages
that
don't
receive
any
testing.
There
are
pages
that
receive
some
manual
testing
and
the
pages
which
you've
achieved
automated
testing.
I
think
trying
to
pass
these
three
things
for
a
user
is
enough.
There's
enough
noise
there.
If
we
make
further
classifications
within
automated
testing,
I
think
it's
too
much.
C
E
B
E
E
F
F
F
B
J
Yeah
yeah,
I
saw
it.
I
just
I
just
wanted
to
say
that
there
are
a
bunch
of
apis
and
their
implementations
being
dropped
into
111
and
having
the
api,
prs,
sort
of
reviewed
and
ready
to
go
earlier
in
the
release
cycle
is
nicer,
so
the
psa
is
that
yeah,
if
you,
if
you
see
kind
of
yourself,
tagged
or
anything
like
that
on
an
api
pr,
please
try
to
help
move
it
along.
H
And
if
I
can
make
an
extra
psa,
please,
it
will
be
very
useful
to
have
you
know
a
doc
with
alternative
implementation,
what
other
people
are
doing
comparison
with
other
products,
because
it's
it's
always
difficult
to
to
understand
how
we
relate
with
other
types
of
complexity.
We
also
support
the
support.