►
From YouTube: Policies and Telemetry WG - 2020-11-18
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
Prison
listening
for
the
yeah.
We
only
want
to
discuss
about
this
workload.
A
Dashboard
so
like
for
for
this,
like
a
a
reporter
for
the
promises,
queries
which
has
reporter
field,
we
want
to
discuss
with
the
community
that,
in
the
workload
dashboard
currently
in
the
general
and
inbound
workload
section
other
queries
is
reporter
request
destination
so,
which
means
like
we
calculate
those
cards
from
the
perspective
of
the
of
the
service
work
service
destination,
and
I
want
to
ask
like
if
you
want
to
like
a
reporter
in
court
source,
which
will
include
those
like
a
failure
request
on
the
una,
unsexual
unsuccessful,
like
a
request
yeah.
A
So
I'm
not
sure.
What's
your
guys
opinion
on
this,
if
you
want
to
when
you
look
at
the
like
the
general
section,
like
incoming
request
volumes,
and
I
want
to
see
that
the
incoming
calculated
by
the
by
by
myself
or
like
it's
a
reporter,
it
course
source,
which,
like
also
includes
those
failure,
requests.
A
C
D
D
We
actually
let
you
toggle
between
the
two
views
right,
so
you
you
can
either
take
the
source,
reporting
or
the
destination
reporting,
because
both
will
give
you
different
things
like
so
as,
as
you
said,
carolyn,
if
you,
if
you
don't
use
source
reporting,
you
won't
ever
see
the
failed
requests
that
never
made
it
to
a
workload.
D
So
that's
a
big
deal
and
then,
as
I
think,
mandar
was
saying,
you
know,
there's
also
the
stuff
that
comes
in
from
unknown,
which
is
a
different
beast
altogether.
I
think
the
solution
is
and
doug
already
knows.
This
is
to
get
rid
of
those
different
reporters
and
at
the
in
the
future,
and
work
very
hard
to
just
have
one
request
represented
with
one
reporting
which,
whether
it
comes
mostly
from
source
and
is
complemented
by
some
destination
reporting
or
the
other
way
around,
doesn't
really
matter.
C
B
I
mean
I,
I
think
that
if
we
were
to
add
it,
we
need
to
have
good
text
about
what
that
means
and,
like
essentially,
a
summary
of
the
discussion
that
we
had
should
go
somewhere
in
help
and
otherwise
just
adding
one
more.
I
for
someone
who's
not
like
fully
attuned
to
this
discussion,
is
just
gonna.
Think,
okay,
another
drop
down
that
I
don't
really
understand.
A
B
It's
it's.
What
doug
was
suggesting
with
another
drop
down
just.
E
D
E
I
like
seeing
the
the
inbound
from
the
server,
but
it's
super
important
when
the
client
fails.
Can
we
just
have
I
mean
I
know
it's
twice
as
much
telemetry,
but
if,
if
the
client
sends
its
information-
and
we
have
the
servers,
can
we
can
we
show
the
difference
so
so
that
if
things
are
dropped,
it
just
appears
on
the
same
thing,
but
only
the
difference
will
be
like
a
zero
line.
If
there
is
nothing
being
dropped.
E
It's
huge
sometimes
sometimes
the
server
reports,
an
error
and
it
gets
lost
by
the
network
or
sometimes
there's
just
too
much
traffic
gets
thrown
away.
That's
that's
a
big
deal,
that's
much
bigger
than
just
the
client's
view
or
just
the
server's
view.
If
you
can
correlate
them,
it's
twice
as
much
work,
but.
B
And
and
ed
you
you've
seen
this
like
to
what
extent
have
you
seen
this
kind
of
big
enough
to
show
show
up
in
like
so
there?
So
there
are
some
catastrophic
errors
where
there
is
a
bug
and
routing
is
just
not
working
and
the
client
side
is
just
doing
like
all
404s
or
something
like
that.
But
I'm
I'm
wondering
how
much
how
much
gradia
is
there
in
the
in
the
middle
that
that.
E
You've
seen
I
never
see
it
because
I
only
run
test
workloads.
I
don't
get
customers
complaining
about
this.
Sometimes
people
will
say
that
they
had
problems
with
dropped
requests,
but
they
solved
them
six
months
ago,
so
I've
never
actually
been
involved
in
solving
one.
For
me,
it's
always
been
just
catastrophic.
F
C
I
think
the
as
I
understood
it,
the
the
question
is:
how
do
we
best
represent
the
traffic
in
the
mesh
to
the
user
and
with
only
showing
server
side,
we
aren't
like
that's
saying
we
aren't
showing
traffic
that
fails
and
we're
not
we're
not
exposing
that
anywhere
in
these
dashboards,
particularly
at
that
to
the
mesh
level.
So
what
are
you
trying
to
figure
out
what
the
right
way
to
surface
that
traffic.
C
A
B
Okay,
so
just
so
that
we
make
progress
the
the
alternatives
right
now
are
we
switch
to
client
side,
we
stay
with
server
side
or
we
add
a
drop
down
that
lets.
People
choose
client
side
when
that
is
important
to
them.
B
B
So
we
can
either
just
put
that
on
the
in
the
notes
and
like
people
can
just
add
more
stuff
there
or
if
we
can
come
to
a
consensus
within
like
a
minute
or
so
then
I
think
that
that
would
be
would
be
good.
B
B
C
A
Yeah
like,
if
we
add
a
drop
down,
which
will
like
only
apply,
should
be
only
applied
to
the
workload
general
and
the
inbound
workload
section,
which
should
not
apply
to
the
outbound
workloads
because
which
should
be
reporter
from
destination.
B
Yeah,
I
think
I
think
that
that
makes
sense
and
then.
A
A
C
Okay,
ed
did
you
want
to
talk
about
this
issue.
E
E
E
B
Okay,
so
since
since
again
quad
was
already
involved,
I
would.
I
would
think
that
he
he's
probably
the
person
to
do
it.
E
B
H
I
don't
own
the
keys
so,
like
I
I
mean
I
can
take
over,
but
I'm
gonna
be
sitting
on
it.
The
same
way
as
that
does
need
to
bug
the
maintainers.
B
H
H
C
C
Okay,
is
that,
and
it
seems
like
we
need
a.
I
feel,
like
that's
the
second
or
third
thing,
I've
seen
related
to
the
extensions
where
there's
been
complaint
about.
B
Yeah,
I
I
agree
doc,
so
I
mean
the
first
person
that
we
are
going
to
talk
to
I'm
going
to
talk
to
is
pewter.
G
B
And
and
if
it
is
a
if
it
is
a
low
risk
change,
but
I
mean
I
understand
what
you're
saying
quite
so,
but
but
still
this
is
more
than
two
months.
Is
it
yeah
it
is?
It
is
more
than
two
months.
C
C
Okay,
well
thanks
for
thanks
for
raising
that
ad,
and
I
guess
we
will
try
and
track
that
down
offline
and
see
what
we
can
do.
C
Does
anyone
else
have
anything
else
they
want
to
add
to
the
agenda
before
we
go
into
a
release,
planning
discussion
that
could
take
up
the
rest
of
the
time.
C
Okay,
well
then,
let's
talk,
there
was
a
during
the
working
group
leads
meeting
this
week.
C
The
guidance
that
was
coming
down
from
the
toc
to
everyone
was
that,
for
one
night
in
particular,
were
probably
all
releases
moving
forward.
They
want
to
shift
to
focusing
on
making
sure
we're,
moving
and
fully
developing
features
or
getting
rid
of
features
that
aren't
going
to
be
fully
developed
and
really
focus
on
what
it
means
to
flesh
out
and
fully
support
features
in
terms
of
upgrades
and
supportive,
long-term
supportability.
C
So
with
that,
they've
asked
us
to
take
again
a
re-look
at
the
things,
we're
planning
for
one
nine
and
beyond,
and
try
and
focus
on
developing
and
prioritizing
the
features
that
we
want
and
and
are
already
there
versus.
Adding
new
features
is
that
is
that
a
fair
characterization
of
the
guidance
from
from
the
tsp?
I.
C
So,
with
that
background
in
mind,
I
wanted
to
take
a
look
at
some
of
the
brainstorming
we
had
done
a
couple
weeks
ago
about
what
we
want
to
do
for
the
one
nine
road
map
and
see
if
we
can
develop
it
into
three
or
four
items
to
work
on
so
I've
copied
over
the
the
notes
from
our
brainstorming
and
just
wanted
to
go
through
them,
hear
and
try
and
prioritize
things
appropriately.
C
I
feel
like
some
of
this
stuff
probably
goes
away
like
maybe
config.
Annotation
is
something
that
we
postpone,
whereas
some
other
things
like
fixing
dashboards
and
developing
beta
promotion
plan
for
wasm
become
the
priority,
but
I
was
I'm
sort
of
interested
in
what
everyone
else
is
thinking
and
if,
if
we
think
there
are
still
other
things
that
aren't
on
here
that
are
features
in
alpha
or
experimental
state
that
we
need
to,
we
need
to
start
looking
at
in
terms
of
removal
or
promotion.
B
So
one
one
thing
to
just
just
add
there
quickly
is
the
remaining
work
on
request
classification,
even
though
we
we
finished
the
work
to
take
it
forward,
as
is
there
is
like
there
is
istio
cuttle
related
work
remaining
among
a
few
other
things
on
request
classification,
so
do.
C
B
B
We,
we
need
the
full
front
end
here
that
that's
the
which
is
which
is
consuming
open
api
spec
and
producing
those
producing
that
config
and
again
in
the
in
the
epic.
There
are
many
other
things,
but
this
is
the
main
thing
that
remains.
B
B
Yeah,
that's
so
it
is.
It
is
a
feature
which
some
people
already
use
right.
I
think
kali
has
started
using.
D
That's
right,
yeah.
We
already
support
it
and
it's
been
working,
so
I
mean
I'm
all
for
this
kind
of
a
thing
where
you're
making
the
feature
robust,
complete
documented
completely.
D
I
mean
I
think
you
could
take
a
whole
release
and
just
answer
questions
in
slack
and
in
discuss
and
and
finish
up
some
things
that
have
already
been
started.
I
mean
I'm
in
general
all
for
like
increasing
robustness,
supportability
and
upgradeability.
D
I
I
really
like
those
directives
from
the
toc
there's
so
many
features
already,
and
I
think
it's
really
more
about
making
this
product
usable
and
trustable.
C
D
F
Can
I
suggest
doug
yeah
putting
the
telemetry
api
implementation,
making
sure
that
the
emphasis
is
on
deprecating
the
current
experimental
support
by
providing
a
first
class
api
right?
That's
how
we
should
wrap
this
and
that
will
include
tooling
documentation
and
if
both
things
exist
we
are,
the
user
is
sure
about.
What's
gonna
happen
in
the
cluster
right,
so
that
fits
the
theme.
If
we
propose
we
are
just
creating
a
brand
new
api,
it
might
not
fit
the
thing
so.
F
And
I
think
you
have
already
started
with
taking
tracing
as
the
first
example,
which
makes
sense
because
we
never
promoted
the
tracing
configurability
beyond
experimental
or
alpha.
I
don't
know
one
of
those
things.
C
F
Yeah
and
like
just
knowing
the
v1
and
v2
trans
migration
phase
for
telemetry,
where
we
could
have
done
improvements.
Obviously
that
is
looking
back,
so
we
should
make
sure
you
know
we
don't
leave
our
users
in
the
same
state.
So
it's
we
can
start
documenting
saying
these
are
the
things
which
won't
be
covered.
For
example,
when
you
migrate
and
the
users
can
choose,
I'm
going
to
stick
with
the
old
one,
for
example,
I
I
think
it
will
be
more
richer.
C
Okay,
for
is
for
bts,
do
do
we
feel
like
we're,
going
to
take
out
any
work
here
or
do
anything.
B
So
yeah,
so
it's
like,
I
think
well
from
last
time.
What
we
heard
from
louis-
and
I
think
kitchen
is
that
in
one
line
bts
is
going
to
be
available
in
in
some
way.
B
So
so
the
work
that
we
have
to
do
here
is
is
one
of
alignment
and
to
actually
like
sort
of
co-design
how
metadata
exchange
is
going
to
work
and
all
our
requirements
are
satisfied.
So
I,
like
the
only
deliverable
I
expect
for
this
work-
is
that
is
the
design
of
how
exactly
is
metadata
exchange
going
to
work
in
the
new
world
and
making
sure
that
it
it
satisfies
all
our
requirements.
F
So
I
mean
from
prioritization
point
of
view,
this
is
basically
mention
the
product
secure,
so
not
the
product
security.
The
extensions
working
group
leads
in
the
docs
so
that
you
can
collaborate
right,
which
is
what
they
should
always
do
right.
Whatever
eugene
is
designing
in
those
in
that
rfc
or
design
docs.
He
should
be
mentioning
you
and
doug
and
few
others
from
this
working
group,
because
there's
nothing
else,
that's
going
to
happen
in
one
night.
B
Is
okay?
I
I
don't.
I
don't
quite
understand
what
what
you
said
but
like
this,
this
affects
telemetry
and
we
should
keep
it
here
as
like
a
top
line
item,
but
maybe
maybe
the
mechanics
of
it
are.
Yes,
you
just
like
we
just
collaborate
on
on
the
design
dock,
but
but
I
think
like
regardless
this.
B
F
I
F
B
H
C
F
F
H
F
F
H
C
H
A
H
H
F
Yeah,
that's
where
I
was
going
when
when
that
was
asking
the
questions
right.
So
in
one
night,
probably
this
working
group
works
with
chain
and
whoever
else
is
in
the
design
docs
to
make
sure
the
architecture
is
correct.
B
And
we
are
also
committed
to
concurrently
supporting
the
old
way
and
the
new
way,
at
least
for
several
releases.
F
1.9
from
the
project
point
of
view.
H
F
Nothing
concrete:
we
have
been
trying
to
get
a
prototype
working
for,
I
think
around
nine.
F
Yeah,
sorry,
I
was
being
generous
and
we
haven't
made
much
progress,
so
my
bar
is,
I
would
like
to
see
a
prototype
before
I
commit
to
anything
changing
in
the
core.
Whatever.
I
F
J
Got
it,
and
so
it's
more
so
I
had
my
camera
off
but
like
in
terms
of
like
when
we
say
initial
support
is
coming
in
1.9.
We're
not
really
saying
that
you
can
just
switch
a
flag
and
no.
C
For
out
of
mesh
telemetry,
I
think
adding
metadata
discovery
source
is
not
something
we
want
to
take
on
in
one
nine.
No,
no
is
there.
How
do
I
straight
through?
I
don't
know,
so
I
can
do
that
for
you
yeah.
Okay,
do
we
do
do?
We
have
other
work
related
to
the
work
that
was
done
in
one
eight
for
this,
do
we
need
more
documentation,
or
do
we
feel
that
our
testing
and
docs
are
efficient
here,
the
computer?
I.
I
It
is
not
a
feature
right
in
mostly
improvement
for
telemetry
too,
like
yeah.
I
think
people
expect
it
to
work
right.
It's
just
it
doesn't
work
before
like.
If
my
request
fails,
it
doesn't
reach
server.
I
should
at
least
have
some
labels
indicate
the
destination
workload
so
and
that.
B
F
I
mean
it
can
have
a
minor
upgrade
burden
since
the
telemetry
storage
and
the
amount
will
increase,
but
this
is
for
the
good.
I
don't
think
anybody
is
going
to
complain
about
getting
more
metrics
about
failures.
B
So
the
the
api
right
sort
of
yeah,
like
I
mean
daniel,
has
already
done
quite
a
bit
work
there.
So
something
that's
based
on
that
or
aligned
with
that,
and
we
can
actually
present
it
in
a
similar
way
that
we
are
going
to
do
with
the
telemetry
api
that
this
is
just
a
more
supportable
and
easier
way
of
getting
extension
functions.
B
So
so,
okay,
I
I
think
I
think
we
we
need
to
have.
We
need
to
have
kind
of
more
discussion
on
that,
because
we
we
may
or
may
not
just
bring
the
code,
as
is
right,
like
we
may
have
other
easier
ways
of
serving
blobs
solo
has
like
another
way
of
serving
blobs.
So
I
I
guess
your
question,
though,
is:
if
our
solution
entails
using
some
other
component,
then
how?
How
do
we
do
it
is
that.
H
H
B
So
if
we
are
going
to
add,
if,
if,
if
you
are
going
to
have
an
istio
api
to
to
configure
extensions
and
if
such
a
thing
is
required
to
kind
of
materialize
that
api,
then
I
think
it
does
belong
in
this
too
right,
I
I
don't
know
what
other
people
think
like
doug
john
niraj,
like
getting
new,
I
mean
blob
server,
doesn't
seem
to
me
like
a
like
a
particularly
like
challenging
or
a
problematic
thing.
F
D
F
Struggling
between
this,
so
in
when
telemetry
v1
was
supported,
we
had
lots
of
other
functionality
that
were
implemented
through
at
through
adapters
or
attributes.
Are
we
saying?
Are
we
going
to
implement
some
equivalent
steer
adapters,
or
this
is
a
generic
api
for
users
to
load
their
own
extensions,
because
the
first
one
is
a
feature
loss
that
we
should
fill
and
that
should
be
the
higher
priority.
F
B
F
B
Yes,
I
think
I
I
think
that
that
that
analysis
was
done
and
we
have
waited
kind
of
since
the
deprecation
to
hear
more
loudly
from
users
right
saying
that,
oh
there
is
this
one
particular
adapter,
which
we
absolutely
must
have
and
it's
going
away,
and
I
don't
think
we
have
heard
that.
B
F
So
maybe
we
should
document
and
emphasize
how
that
alternative
works
with
telemetry
v2.
F
F
E
E
I
I
I
would
love
to
see
such
an
example.
A
little
do.
We
still
want
to
put
that
on
the
one
nine
plan.
I
Yeah
yeah
I'm
working
on
it
and
hopefully
the
blog
post
will
come
up
shortly
after
one
day.
Excellent
and.
B
And-
and
there
is
a
there
is
a
rate
limiting
extension
that
nopur
wrote
is,
it
is,
is
it
already
checked
in
to
eco
ecosystem?
No,
not.
I
B
F
D
F
C
F
H
E
G
E
F
Gonna
migrate,
try.
I
was
trying
to
prioritize
those
things,
so
I'm
glad
ed
you
brought
this
up
and,
and-
and
you
know
you-
the
telemetry
extensions
working
group
can
own
it
and
take
help
from
ux
working
group,
because
it's
quite
difficult
otherwise
for
a
ux
working
group
to
get
expertise
in
this
right.
E
E
I
B
Right,
so
so,
so,
basically
here
is,
and
actually
that
is
exactly
why
we
have
been
using
onward
filter
till
today,
right.
That
is
exactly,
and
that
is
exactly
the
reason
why
we
have
been
using
onward
filter
even
for
telemetry
v2
until
today,
because
it
does
not
stop
function
like
function
is
still
there.
B
B
What
they
value
is
the
stability
of
runtime,
and
they
they
also
do
value
upgradability,
but
they
they
do
their
own
testing
for
for
upgradability.
So
so
the
api
is
somewhat
lower
on
that
scale.
For
those
users,
however,
when
we
are
trying
to
grow
the
community
and
like
convince
people
that
hey
this
is
easy
to
use,
that's
when
this
sort
of
api
is
useful,
but
I
I
do.
I
do
agree
that
it's
not
related
stability
right.
I
mean.
F
F
It
might
be
a
better
result
for
the
users
and
for
the
community,
so
you
can
have
directional
agreements
and
if
you
already
have
it
for
the
wasm
apis,
but
we
can
keep
that
as
a
target
for
one
nine
and
one
time
you
can
keep
the
target
of
okay.
Let's
start
the
implementation
and
make
them
alpha
and
expose
it
to
the
users.
C
F
C
So
one
thing
I
want
to
be
careful
about
that
you
said
earlier
in
mirage-
is
that
no
one
has
complained,
but
mixer
didn't
go
away
to
one
eight
which
hasn't
been
released.
So
we
don't
actually
know
right.
There's
a
large
number
of
users
on
one
six,
one,
seven
one
five,
even
using
it
adapters
and
we
haven't
heard
that
they
haven't
gone
through
so.
F
C
Okay,
I
think
I
know
now
how
to
phrase
all
that
the
the
dashboards
this
is.
You
know,
following
on
some
of
the
work,
the
good
work
that
carolyn's
been
doing.
We
had
some
new
metrics
that
were
introduced
in
one
eight
and
for
grpc
streaming,
but
we
don't
have
any
way
to
expose
those
in
our.
In
our
example
dashboards.
C
We
don't
have
anything
that
really
focuses
on
service
to
service
traffic
based
on
the
canonical
service
stuff
that
we
added
two
releases
ago
and
we
don't
have
any
sort
of
ingress
or
gateway
specific
dashboards,
and
that
has
been
requested.
C
I
don't
know
where
we
how
we
want
to
prioritize
that
work,
but
it
feels
like
exposing
that
is
useful
and
could
be
used
by
different
different
customers,
but
I
don't
know
how
that
rates
in
terms
of
in
terms
of
the
other
priorities.
So
I
wanted
to
get
feedback
about
about
that
work
as
well.
C
Well,
I
I
mean
we
could
break
it
down
by
each
of
these
or
or
take
dashboards
in
general.
I
think
we
have
a
service
dashboard
that
is
kubernetes
service,
and
doesn't
you
know
we
can
make
it
better?
C
I
think,
with
switching
that
to
the
economical
service,
it's
probably
a
small
amount
of
work
to
add
that
dashboard,
but
it
is
real
work,
the
the
metrics,
the
grpg
streaming
metrics,
and
we
have
to
figure
out
how
we're
going
to
put
that
on
each
of
the
existing
dashboards
right,
because
they're
sort
of
http
request
based
or
tcp
connection
based.
C
So
this
would
be
a
third,
a
third
dimension
that
might
show
up,
but
you
know
I
I
don't
know
how
to
prioritize
that
work.
I
guess
is.
C
F
All
right,
because
I'm
looking
at
the
prelim
preliminary
view
of
sd
of
standard
metrics
and
they
don't
show
up
so
I
was
confused
if
this
is
net
new
or
this
is
improvement.
C
F
Yeah
one
more
thing
about
new
labels
that
we
have
added,
have
we
released,
noted
them
or
put
it
in
the
upgrade
notice,
saying
there
will
be
increased
dimensionality.
C
Well,
these
are
strictly
new
metrics,
so
I
don't
think
that
they
have
increased
dimensionality.
G
B
F
B
C
B
Right
or
well,
we
could
we
could.
We
could
document
right
like
there
is,
especially
if,
if
I
go
to
eastern
standard
metrics-
and
I
see
a
list,
then
I'm
going
to
think
that
they're
all
standard
and
they're
all
stable,
and
since
this
is
new,
we
should
probably
leave
ourselves
some
room
to
say:
okay,
we
are
going
to
change
dimension
and
whatever
and
and
then
call
that
metric
kind
of
experimental
subject
to
change.
Unless
we
are
sure
that
it's
fine
and
we
can
just
go
on.
H
F
Can
we
do
that?
I
mean
it's
cutting
close
to
the
release,
but
if
we
can
document
it
clearly,
it
will
really
help
us
and
convey
to
the
users
that
hey.
This
is
a
new
thing
that
is
coming
up,
but
I
want
to
come
back
to
the
increased
overall
metrics,
also
that
users
will
get
now.
There
are
quite
a
few
users
who
do
grpc,
which
is
good
that
a
new
metric
will
show
up,
but
is
there
a
way
to
disable
this
or
we
don't
have
any
environment
variables
or
anything
that
can
be
used.
H
C
B
C
Okay,
we're
almost
out
of
time,
so
I
think
is
it
fair
to
say
that
all
of
config
annotation
is
something
that
is
not
a
priority
for
one
nine
and
that's
that
would
be
new
work,
involve
adding
a
bunch
of
new
new
flags,
and
data
everywhere.
Is
that
is
that
fair
to
say
that,
given
that
guidance,
that's
something
that
can
be
pushed
to
110.
C
H
I
I
So,
like
some
user
have
more
clothes
that
spin
up
and
tear
down
frequently
and
that
could
contribute
to
the
carnality
yeah.
I
mean
it's
definitely
something
that
good
to
have,
but
not,
I
don't
think
it's
attracting
majority
of
the
user.
B
So
so
so
what
one
of
the
specific
cases
was
was
cron
jobs,
and
I
think
that
part
we
have
already
fixed
yeah
right.
I.
I
So
that's
why
I'm
thinking?
Maybe
this
does
not
worth
the
the
footwork
to
introduce
metrics
battery.
F
I
Yeah
yeah:
this
is
from
looking
through
those
seizures.
I
think
about
it,
but
recently
I
think
I
mean
because
metric
transformation
customization
could
help
in
some
cases
yeah
I
can.
I
can
write
up
something
make
sure
we'll
see
you
next
meeting.
B
F
This
is
looking
good.
If
you
can
document
this,
I
think
we
might
be
able
to
save
some
development
efforts
for
one
night.
Then.
B
F
C
Okay,
we're
over
time
so
I
want
to.
I
don't
want
to
take
up
people's
days,
and
I
know
everyone
else
has
probably
a
bunch
of
meetings
and
work
to
do
so.
I
will
try
and
condense
this
into
some
sort
of
cleaner
roadmap
representation
and
add
here.
I
expect
that
we
probably
won't
be
a
group
that
shares
on
friday,
so
it'll
probably
be
two
three
weeks
before
we
share
this
with
the
toc.
C
But
just
if
you
watch
this
document
there
will
be
changes
here
and
I'll
I'll
I'll
get
it
into
some
sort
of
shareable
state.
So
that's
my
action.