►
From YouTube: Octant Community Meeting - May 12th, 2021
Description
Octant community meeting is held weekly. We discuss and talk about the current state and future of Octant, demo upcoming features and releases, and preview new ideas we are considering for Octant.
Meeting agenda: https://hackmd.io/CzaPxtmXT_SW8nEpdwvGzw?view
A
All
right
and
we're
live
hello,
everyone
and
welcome
to
the
auction
community
meeting
on
may
12
2021.
This
is
the
oda
20
edition.
We've
got
a
release
yesterday
and
now
we
are
currently
going
to
talk
a
little
bit
about.
What's
next,
what's
going
on
in
0.20,
let
me
fix
that
typo
and
we
are
going
to.
I
think.
We've
got
three
things
in
the
agenda
today,
we're
just
going
to
go
through
some
of
the
work
on
the
21
board.
We
can
talk
a
little
bit
about
improving
the
workflow.
A
I'm
sure
milan
was,
did
you
add
this
one?
Yes,
yes,
okay,
cool,
we'll,
add
some
we're
talking
about
some
process
related
things
so
we'll
take
notes
and
then
we
could
also
talk
about
a
pr
that
form
is
working
on.
I
don't
know
if
he's
on
the
call,
but
is
what
is
going
to
be
about
the
addition
of
standard
alerts,
and
this
is
a
cool
pattern
that
will
be
introduced
pretty
soon.
So,
let's
get
started.
A
Make
this
a
little
bigger
cool,
so
we
can
talk
about
the
odot
ii
on
board.
Pretty
briefly
here.
A
So
this
the
next
release-
that's
coming
up
is
going
to
be
focused
towards
two
things.
I
think
the
first
one
being
a
bunch
of
resource
viewer
improvements.
This
is
going
to
be
a
work
in
progress,
that's
spanning
multiple
releases
and
spearheaded
by
milan,
and
we're
going
to
continue
doing
that.
A
So
we
are
essentially
just
going
to
talk
about
that
going
to
continue
fixing
the
different
views
related
to
the
resource
viewer
as
as
needed
did
I
miss
anything
about
the
resource
for
your
part.
B
No,
no,
I
I
think
you
mentioned
everything
the
this
one
you're
highlighting
I
just
actually
submitted
pr
this
morning,
so
excited
to
that.
We
are
moving
forward
with
this
and
it's
all
about
adding
more
context
and
using
more
ability
to
to
zoom
in
and
out
and
collapse,
expand
nodes
to
things
like
that.
Expanding
the
amount
of
details
we
show
in
detail
spain
and
things
like
that.
So
it's
it's!
It's
pretty
exciting.
B
A
Cool
yeah,
thank
you,
the
other
big
one,
and
this
one
I
mentioned
privately
within
our
team,
but
I
can
also
talk
about
in
the
community.
Beginning
is
this
particular
issue
is
getting
blank
context,
contents,
an
overview
page
for
a
cluster
with
restricted
rmac,
and
this
one
has
been
around
for
a
while,
but
I
think
we
need
to
address
this
fairly
soon
and
by
soon.
I
think
this
needs
to
be
an
oda21
simply
because
this
is
used
in
a
lot
of
vmware's
internal.
A
A
If
you
are
doing
any
of
the
vmware
tanzu
labs
that
are
often
related,
you
might
notice
that
it's
not
using
the
latest
octane,
and
it's
simply
because
of
this
particular
issue
where
at
some
point
when
we
updated
our
implementation
of
the
dash
client
and
the
object
hash,
what
ended
up
happening
was
that
if
you
do
not
have
access
to
crds,
the
entire
watcher
would
fail
and
then
octet
would
just
not
show
anything.
A
And
so
we
want
to
do
better
than
that
and
definitely
have
this
fixed
up
so
that
we
can
have
our
labs
use.
The
latest
version
often
and
we've
got
a
couple
more
interesting
ones.
I
think
this
one
also
done
by
milan
is
the
file
uploader.
A
This
is
a
super
interesting
component
simply
because
we
see
a
couple
of
places
where
it
could
already
be
relevant,
like
the
apply
yellow
page,
the
cube
config
page
and
historically,
this
is
difficult
to
do,
because
if
we
just
run
octant
as
an
angular
application,
it
doesn't
really
have
access
to
any
of
the
file
system.
Libraries,
so
we
can
start
experimenting
with
electron
as
well,
and
we
can
even
do
things
like
reading
like
essentially
not
even
sending
a
file
over
the
wire,
but
when
we're
uploading,
it
really
is
just.
A
I
want
a
file
and
I'm
sending
it
locally
back
docked
in
itself,
so
it
seems
kind
of
strange
initially
when
thinking
about
it
on
how
the
flow
of
the
file
actually
works.
But
I
think
overall
this
isn't
this
is
this
is
something
that
we
definitely
could
use
in
a
ton
of
places
and
we're
going
to
yeah.
I
think
milan
already
has
this,
so
it's
under
review
right
now,
so
keep
an
eye
out
for
this
as
we
keep
going.
A
And
finally,
the
last
piece
that
we're
working
on
is
a
bunch
of
the
form
refactors
we've
got
stuff
like
horizontal
stacking
of
fields,
and
I
think
we've
got
the
stepper
on
here,
so
we're
going
to
create
a
bunch
of
new
work
regarding
how
to
change
the
forms,
as,
in
particular
the
form
says
in
their
layouts
for
each
field,
and
we
also
want
to
start
thinking
about
dynamic
forms.
A
So
each
stepper,
each
step
of
a
stepper,
can
influence
the
content
of
the
next
step
and
being
able
to
go
through
and
create
forms
dynamically
rather
than
right
now,
where
they
just
kind
of
have
to
be
entirely
static.
So
that's,
oh
no,
two
in
a
nutshell:
we
have
some
other
things
on
here.
That's
called
to
do.
A
I
think
what
ended
up
happening,
because
since
coda
20
came
out
as
a
slower
release,
we
could
still
definitely
try
to
aim
the
target
target
release
date,
probably
at
the
end
of
may
so.
Certainly,
this
one
might
be
a
shorter
release
just
because
of
how
the
cycle
works
out,
but
I
think
it's
okay,
we
can
adjust
our
workloads
accordingly
and
anything
that
needs
to
be
pushed.
We
can
just
do
another,
not
release
any
questions
about
product21
or
even
the
release
that
came
out
yesterday.
B
Oh
all,
right
cool,
oh
good!
Sorry!
I
I
just
wanted
to
say
you
know
kind
of
I
mean
invite
the
community
to
participate
in
this
too.
So,
if
there's
anything
anybody
watching
this,
if
there's
anything
you'd
like
to
see
in
zero
21,
that's
not
there.
Please
raise
your
voice.
The
best
thing
to
do
that
this
should
get
had
issues.
We
monitor
those
all
the
time.
So
if
there
are
any
issues
that
you
feel
it
should
be
there,
please
let
us
know
we'll
definitely
listen.
A
Yeah,
absolutely,
and
thanks
for
bringing
it
up
that
that
is
very
true.
I
think
at
the
core
of
what
octet
is
supposed
to
be.
We
are
our
essentially,
our
work
is
guided
by
community
decisions.
So,
if
you're
working
on
anything
even
with
core
opted
plugins
just
ping
us-
and
we
will
definitely
take
a
look.
A
Oh
all,
right
next
item
improving
the
workflow.
Would
you
like
to
talk
about
that.
B
Sure
I
can
kind
of
set
the
stage.
We
briefly
discussed
this
yesterday
on
ll,
but
I
I
thought
we
should
probably
try
to.
You
know
discuss
this
further
in
in
in
this
environment.
B
Basically,
we
were
wondering
what
can
we
do
to
kind
of
improve
the
workflow
to
make
us
a
little
more
efficient
and
ultimately,
the
conclusion
yesterday
was:
you
know
if
at
least
the
hope
is
that
if
he
can
make
some
really
small
tweaks
in
the
way
we
work
that
will
make
us
be
a
little
more
productive,
improve
the
team
velocity
and
ultimately
help
us
release
poster.
So
so
I
just
wanted
to
you
know
open
up
for
discussion.
B
What
do
you
all
feel
are
some
things
we
can
do
in
order
to
you
know,
make
things
move
a
little
faster
and
make
it
turn
around,
and
you
know
when
you
finish
your
feature
moment
from
when
you
finish
the
future
until
it
actually
ends
up,
you
know
in
a
build
and
it
actually
hits
the
actual
end.
Users
make
a
little
shorter.
A
Yeah,
I
have
some
thoughts
around
this,
so
there
are
a
few
things
that
come
up
when
we
get
to
the
point
where
someone
is
pushing
code.
I
think
that
first
piece
here
is
time
to
review
and
certainly
we've
had.
A
You
know
I
think,
for
the
last
release,
it's
kind
of
an
anomaly,
because
we
have
some
engineers
who
are
in
colombia
and
they've
got
like
political
things
going
on,
and
then
we've
also
got
government
related
outages
so
like
people
are
in
and
out,
but
I
think
one
of
the
things
that
ended
up
becoming
pretend
what's
going
on
here:
start
freezing,
okay,
yeah,
one
of
the
things
that
we
can
potentially
start
looking
into
is
the
concept
of
owners
right.
A
So,
for
example,
here
let's
give
an
example
right
we
have
say
your
select
file
component
right.
This
was
opened
five
days
ago
right
and
it's
not
clear
at
the
moment
how
many
people
have
taken
an
initial
pass
or
how
many
people
have
ran
that
code,
and
I
think
part
of
this
is
my
fault.
A
We
can
implement
this
like
a
fair
number
of
ways,
but
I
think
like
I
would
eventually
like
to
get
to
the
state
where-
and
these
two
different
people
are
looking
at
a
newer,
your
bit
of
push
code,
and
I
think
we
implemented
a
policy
saying
like.
Oh,
we
wanted
to
have
a
quick
turnaround.
We
wanted
to
come
back
people's
comments
within,
like
I
think
what
like
48
or
17
to
two
hours,
and
we
really
want
to
uphold
that.
I
certainly
think
we
have
enough
people
to
do
that.
A
Another
piece
that
comes
up
to
me.
This
is
yeah.
Another
piece
that
comes
up
for
developer
velocity
is
also
writing
out
better
issues.
I
think
we've
gotten
slightly
better
at
doing
this,
but
we're
still
not
great
all
right,
like
the
idea
here,
is
that
even
to
us,
people
who
work
in
you
know
us,
as
in
people
who
work
at
vmware.
A
Sometimes
a
lot
of
these
issues
aren't
really
accessible
to
us,
like
people
like,
even
we
don't
know
necessarily
what
they
need,
or
why
they're
there
much
less
someone
who's
in
the
community
and
so
writing
out
these
issues
in
a
much
more
detailed
manner
and
actually
explaining
the
context
for
why
and
how
at
least
you
know
on
a
very
basic
level
is
something
that
overall
can
help
us
a
lot
right,
because
then
the
person,
the
person
who's
pulling
down
the
issue
would
kind
of
be
more
clear
on
what's
needing
to
be
built,
but
also
like
that's
the
part
of
building
a
healthy,
open
source
community
where
everybody
can
contribute
and
they're
yeah
and
I'm
not
gonna
click
into
specific
issues.
A
Examples,
but
certainly
we
can
there's
more
than
a
dozen
of
them
where
we
can
do
better
at
so.
Those
are
my
two
thoughts
on
this
matter,
pretty
sure
there.
You
can
certainly
talk
about
their
more
processed
things,
but
does
anyone
have
thoughts?
I
have.
C
A
question:
well,
I
don't
use
the
flag
flax
on
on
my
pr's,
so
I
was
wondering
if
you
guys
do
like.
Sometimes
I
just
put
that
like
a
draft,
but
I
don't
use
like
a
flag
to
say
that
it's
ready
for
review
so
yeah.
C
I
I
just
want
to
make
sure
that
if
I'm
gonna
review
something
it's
really
ready
for
review,
I'm
not
just
somebody
just
making
sure
that
the
pr
is
just
probably
running
tests
or
making
sure
they
don't
want
to
run
the
test
on
their
machines
and
they're
just
using
actions
to
to
run
the
test
for
them
or
something
like
that.
I
just
want
to
make
sure
I
would
like
to
have
a
consensus
about
it.
This
is
like
if
we
have
the
pr
there
it
it's
ready
for.
B
A
A
Yeah,
so
I've
contributed
to
several
open
source
products,
and
my
understanding
is
that
when
you
open
up
pull
requests,
it's
ready,
barring
a
failing
test
right
and
typically
those
scenarios
are
like
the
tests
work
locally.
But
I
you
know
like,
like
it's
generally
bad
form,
to
push
something
to
ci
just
to
see
if
the
tests
run
right,
like
you
want
to
run
your
tests
locally.
A
So,
but
generally
speaking,
right
like
if
you
push
your
code
out
there,
you're
saying
it's
ready
and
github
yeah,
and
this
was
even
before
github
had
the
draft
feature
right
so
like
before
people
would
do
stuff
like
do
not
merge
or,
like
you
know,
weird
stuff
in
the
titles
but
like
we
now
have
the
right
buttons
to
not
do
that.
So
I
I
I
think,
like
the
question
I
would
ask
back
is
like:
when
do
you
push
something?
A
That's
not
a
draft
and
it's
not
ready
for
review
right,
and
I
really
don't
see
right
like
if
we
ask
the
question
of
the
negative
like
I
don't
really
see:
scenarios
where
you'd
want
to
push
your
code
and
not
have
it
reviewed,
because
otherwise
you
just
push
it
to
a
fork
and
you
just
let
someone
see
your
branch
right.
You
don't
have
to
hit
the
pull
request
button
to
share
code.
A
Yeah,
okay,
cool
yeah,
so
I
think
well
I
mean
it's
like
a
consensus
of
like
the
folks
on
this
call,
I
think,
or
at
the
very
least,
but
I
think,
here's
the
thing
it's
the
processes
are
subject
to
change.
I
think,
generally
speaking,
generally
speaking,
if
it's
really
more
like,
if
you're
reviewing
something
just
feel
free
to
call
it
out
or
just
say,
like
hey,
I'm
gonna
go.
Take
a
look
at
this
bit
of
code.
A
I
think
writing
like
reading
other
people's
code
is
equally
as
important
as
writing
code,
and
so
one
is
the
best
way
to
learn
about
other
parts
of
the
code
base,
but
also
just
becoming
a
better
engineer
in
general.
So
definitely
like
read
other
people's
code
and
just
take
them
as
learning
opportunities.
I
think
that's
probably
the
best
part
about
doing
code
reviews
is
that
you
can
see
how
other
someone
else
might
solve
a
particular
problem.
That
might
not
be
your
particular
solution
but
would
still
be
equally
valid.
B
Oh
yeah
absolutely,
and
I
I
kind
of
feel
that
maybe
we
need
to
always
kind
of
internally
prioritize
doing
that
compared
to
I
mean
we
all
want
to
write
the
code
right
and
that's
like
the
the
best
part
of
our
job,
but
in
the
same
time,
as
sam
said,
you
know,
understanding
other
parts
of
the
code
and
how
everything's
fit
together,
even
if
you're
not
active
in
a
certain
area
of
project,
it's
really
important.
So
I
think
maybe
we
need
to
prioritize
that
and
and
and
a
couple
other
notes.
B
I
I
think
I
like
what
you
said
about
sam
about
the
ownership
and
owning
the
parts
that
might
help
us
too.
Another
thing
I
was
I
was
considering
is
it
might
be
also
a
good
idea
that
when
we
submit
a
pr,
if
we,
if
we
explicitly
state
in
a
pr
who
we
want
that
to
be
reviewed
by
so
that
shows
up
in
a
you
know,
everybody's
workflow-
maybe
maybe
that
will
help
as
well
just
just
ideas.
B
I
I'm
not
leaning
towards
any
one
of
those,
but
I
just
want
to
throw
them
out
some
things
you
can
do.
D
That,
oh
they're,
just
cramping,
sorry,
okay,
something
I
I
think
about
doing
when
I'm
making
vr
is
you
know
to
just
like
push
like
a
demo
code
that
you
can
just
like
switch
to.
D
You
know,
for
example
like
if
I
have
a
pr
branch
I
could
like
make
an
additional
commit
on
my
branch
and
call
it
something
else
and
push
it.
So
people
could,
you
know,
just
bring
it
down
and
just
have
like
a
demo
to
play
with
based
on
whatever
pr
is
about
because
there
are
times
like,
but
I
review
a
pr,
but
I
just
like
I
don't
go
ahead
and,
like
you
know,
implement
the
changes
that
are
not
part
of
the
main
flip
base
or
yeah.
D
That
is,
for
example,
like
there's
a
new
component,
but
it's
not
used
by
any
other
existing
component
that
gets
printed
so
right,
it'd
be
useful
to
have
there's
some
kind
of
a
demo
code
that
I
can
look
at
and
play
with
just
to
check
the
correctness
myself.
D
D
I
find
like
if
I
provide
it
with
my
prs,
for
example,
with
alerts.
I
could
just
like
have
a
separate
branch
where
you
know
all
the
components
that
contain
alerts,
and
I
show
them
why
I
plug
in
or
something
and
people
can
just
you
know
just
play
with
it.
Instead
of
implementing
their
own
alerts
to
check
the
correctness.
A
Yeah
thanks
for
sharing
that
and
that's
the
thing
we
do.
I
think
for
your
particular
case
with
the
alerts,
I
would
say
something
amongst
the
lines
of
that's
what
the
storybook
is
for
for
a
lot
of
us.
A
lot
of
our
component
related
work.
You
don't
need
to
have
an
opt-in
and
a
plug-in
system
set
up
to
view
how
those
components
work
and
generally,
I
know,
we've
been
doing
a
lot
of
component
related
work
lately.
A
So
that's
generally,
what
we
want
to
encourage
alongside
those
pr's,
that
update
new
components
or
create
a
new
component
pattern,
is
to
have
some
of
that
documentation.
So
then
they
end
up
on
reference.dev,
simply
because
one
you
want
to
think
about
it
in
terms
of
whether
or
not
this
component
makes
sense
from
a
ui
perspective,
but
then
also
like
eventually,
we
also
want
to
jump
back
from
like
the
programmatic
approach.
Right,
like
you,
do,
want,
to,
you
implicitly,
add
a
code
snippet
into
the
storybook.
A
B
B
Yeah
and
to
extend
that,
I
I
think,
even
if
you're
not
creating
component
like
if
you
look
at
the
very
bottom
of
the
storybook
there's
a
bunch
of
stories
that
are
not
components
related,
there's
some
resources,
we'll
run,
there's
like
one
talking
about
the.
I
forgot
how
we
called
it
that
bottom
panel
right.
B
That's
not
a
good
example,
but
you
know
things
like
this,
so
so
you
know
this
is
a
good
place
to
add.
Even
if,
if
you
have,
if
you
let's
say
you
want
to
show
how
components
work
together,
you
can
create
a
simple
story
and
just
add
it
here.
At
some
point,
we
we
are
planning
to
add
tests
around
all
those
stories.
So
if
nothing
else,
hopefully
one
day,
we'll
have
a
snapshots
for
those
stories
and
make
sure
that
they're
used
that
way.
As
well,.
B
B
But
for
the
components,
this
is
pretty
much
required
to
be
here,
like
you
know,
code,
examples
and
different
illustrating
different
usages
illustrating
how
parameters
are
used
for
each
component.
Things
like.
B
A
Cool
yeah
and
yeah,
so
it's
generally
like-
and
I
think
like
this-
is
for
components
in
general
right
if
we're
talking
about
something
a
bit
more
abstract.
Certainly,
that
would
just
involve
running
often
right
and
really
that's
what
we
also
want
to
encourage
right,
like
probably
for
us
in
particular,
we
need.
We
want
to
be
dog
fooding,
our
own,
our
own
work.
A
We
need
to
be
running
often
ourselves
and
we're
doing
things
on
kubernetes
and
the
general
key
indicator
is
that
if
we
don't
want
to
use
it
or
if
we're
not
using
it,
then
we
probably
haven't
done
a
great
job
of
whatever
it.
Is
that
we're
implementing?
I
feel
like
the
biggest
one
here,
is
like
the
electron
bill
right
like
currently
right
now,
like
even
with
demos
and
stuff.
A
Like
a
lot
of
times,
I
catch
myself
still
running
the
binary
because
it's
convenient,
even
though
the
electron
build
is
what
we
are
going
to
ship
in
the
future.
And
we
have
already
decided
that.
So
I
should
only
be
showing
the
electron
build.
But
I
don't
because
there
isn't
really
much
in
the
electron
build
at
the
moment
that
the
web
binary
doesn't
offer.
And
so
what
we
want
to
do
is
to
move
to
those
places
and
continually
dock
food
and
be
able
to
show
what
value
is
being
added
by
our.
A
Cool
all
right.
Well,
I
think
we've
got
some
really
good
stuff,
and
this
is
an
awesome
conversation
and
I
think
when
we
can,
I
think
the
some
of
the
actions
that
we
want
to
come
back
to,
I
think
is
this
is
an
interesting
one,
adding
owners.
I
think
we've
talked
about
this
in
the
past
historically,
and
this
might
revolve
some
longer
term
discussion
around
whether
or
not
this
is
something
we
want
to
implement
now
or
later.
A
A
So
like
someone
who
might
be
subject
matter
expert
in
one
particular
area
of
the
code
base,
they
someone
else
can
review,
but
we
would
also
have
like
a
final
pass,
someone
who
can
sign
it
off,
and
I
think
this
workflow
has
been
done
with
upstream
kubernetes
a
lot,
so
we
can
model
our
process
after
that.
A
Cool
anything
else
about
improving
workflow
and
how
we
can
get
more
developer,
velocity
and
open
source
in
general.
I
think
that's
probably
the
coolest
part
here
right
is
that
our
developer
velocity
is
dependent
on
an
external
variable.
B
Right
now,
I
think
this
is
a
great
discussion.
Thank
you
and
I
you
know,
I'm
not
expecting
we're.
Gonna
get
all
the
answers
right
here
right
now,
but
as
as
long
as
we
iterate
on
this
and
and
try
to
find
the
best
ways
and
consciously
think
about
it,
you
know,
as
as
we
do,
our
day-to-day
work,
I
think
we're
gonna
end
up.
You
know
improving
and
getting
good
benefits
out
of
it.
A
Cool
all
right-
and
yes,
without
further
ado,
let's
jump
to
the
last
item
of
the
agenda,
so
this
one
is
very
briefly
addition
of
standard
alerts,
it's
something
that
vikram
has
been
working
on,
and
I
wanted
to
highlight
it
because
it's
pretty
cool
it's
this
notion
that
you
have
standard
so
clarity.
They
created
a
new
style
of
alerts
and
clarity,
core
and
whoa.
My
computer
is
really
flagging
today,
probably
way
too
many
chrome
tabs
open.
A
So
one
of
the
cool
things
about
the
new
clarity,
core
components
is
that
they
have
an
alert
and
they
have
this
concept
of
a
standard
alert
and
they
also
have
app
level
alerts,
and
so
they
have
this
global
alert
and
they've
got
a
pattern
where
you
can
add
some
action
item
into
the
alert,
and
you
also
have
these
standard
alerts
which
are
softer
they're
in
this
pastel
color
and
they
can
belong
inside
certain
components.
Like
I
think,
like
a
placement,
I
think
like
throw
this
inside
a
modal.
A
We,
I
think
octet
already
has
scenarios
where
they
throw
this
inside
of
a
card.
In
a
summary-
and
so
this
is
pretty.
This
is
a
pretty
cool
pattern
that
we
want
to
start
introducing,
because
we
totally
see
a
lot
of
people
using
this
and
even
internally,
where
we
can
show
warnings
and
errors
in
a
much
more.
You
know
a
much
more
cleaner
way.
A
Interestingly
enough,
they
also
have
this
idea
of
a
lightweight
alert
which
is
effectively
an
icon
component
and
a
text
component,
at
least
in
ogden
land,
of
what
what
this
is
supposed
to
be,
and
so
I
think
we
might
not
implement
this.
I
don't
think
we
will
to
be
honest,
but
this
is
just
kind
of
kind
of
a
cool
thing
to
do,
or
we
might
even
implement
this
anyways.
I
think,
having
multiple
ways
to
achieve
the
same
thing
is
you
know
not
it's
not
it's
not
infeasible.
A
We
probably
have
to
come
up
with
a
good
reason
why
but
yeah
this.
This
is
gonna,
hopefully
land
soon.
I
think
it's
just
seeing
one
or
two
things
before
it's
good
to
go.
A
Any
questions
comments
about
alerts.
A
This
one's
gonna
yeah
this
one's
gonna
be
fun,
something
I'm
really
excited
about,
is
being
able
to
have
these
actionable
alerts
inside
of
a
particular
component.
It'll
it'll
give
us
a
really,
I
guess,
like
a
better
way
to
expose
user
actions
as
opposed
to
just
plain
old
buttons.
So,
anyway,
that's
that's
the
standard
alerts.
B
Yeah,
plus
one
on
that,
that's
really
cool.
I
can't
wait
to
see
that
in
octant.
You
know
just
to
improve
the
interactivity,
gives
you
feedback
right
there,
where
it
should
be
so,
and
I
I
really
like
how
they
did
it
too.
They
decided
to
preserve
up
level
alerts
and
add
those
you
know.
So
I
think
that's
a
it's
really
good
to
have
to
level
kind
of
to
tongue
approach
to
that.
If
you
will
so
yeah,
it
should
be
cool
to
see
it
in
auction.
A
Cool
all
right:
no,
there
are
no
more
questions
about
standards
alerts,
so
we
can
go
to
open
q.
A
I
don't
think
anyone
says
added
anything
to
the
agenda,
but
anyone
have
any
general
questions.