►
From YouTube: Node Operator Roundtable - Dec 14th, 2022
Description
This week the EOS Node Operator Roundtable updates the community on software development and focuses on the issues with WAX network congestion and how to solve this issue.
00:00:00 Start
00:00:02 Recap from last week
00:10:19 Software Development
00:14:10 WAX network congestion
00:17:28 Proposed changes to Leap
00:29:46 Advice for WAX node operators
00:55:29 End
The EOS Network Foundation coordinates financial and non-financial support to encourage the growth and development of the EOS Network. We’re harnessing the power of decentralization to chart a coordinated future for the EOS Network as a force for positive global change.
// EOS Network Foundation //
https://www.eosnetwork.com
https://twitter.com/EosNFoundation
https://www.linkedin.com/company/eos-network-foundation
https://t.me/EOSNetworkFoundation
https://discord.gg/eos-network
info@eosnetwork.com
#EOS #Web3
A
All
right
welcome
everybody.
It
is
December
14th.
This
is
the
12th
week
since
EOS
Independence
and
the
last
round
table
for
the
year
we're
going
to
take
a
short
break
for
the
holidays,
so
for
anyone
watching
the
recording,
merry
Christmas,
happy,
New,
Year,
happy
holidays,
whatever
you
celebrate,
enjoy
the
time
with
your
family
and
friends,
and
sit
back
and
relax
and
have
one
more
peek
into
the
world
of
the
node
operator.
A
Last
week
we
talked
about.
It
was
a
part
two
of
the
Prometheus
exporter
stats
conversation
we
had.
We
went
through
an
old
Matthew
request,
an
old
GitHub
issue
that
Matthew
had
submitted
a
bunch
of
wishlists.
We
can
call
it
things
we'd
like
to
see
data
from
Prometheus
and
we
identified
what
we
thought
could
be
the
low-hanging
fruit
that
can
happen
at
the
node
level
versus
perhaps
more
long-term
needs
to
happen
at
the
chain
level.
A
I,
don't
know.
If
there's
anything
left,
we
want
to
wrap
up
on
that
conversation
before
we
move
on
to
the
next
topic.
I
know
Matthew
mentioned,
maybe
there's
some,
maybe
there's
some
value
in
having
a
quick
peek
over
it,
but
I
think
the
main
topic
for
today
will
be
we
had.
We
had
talked
about
talking
about
the
antelope
resource
model.
A
B
C
All
right,
no
we're
kind
of
finalizing
the
framework.
If
you
will
and
then
adding
in
some
of
these
reporting,
you
know
we're
trying
to
do
the
trade-off
between
performance
and
granularity
of
of
reporting.
So
a
number
of
these
things
we
we
discussed
internally,
decided
that
we
should
do
it
like
on
every
block,
as
opposed
to
like
every
time.
It's
updated.
For
example,
the
unapplied
transaction.
D
C
D
C
It
is,
but
even
without
having
a
separate
thread
there
are,
you
know,
you've
gotta
you've
got
a
contention
of
updating
those
values.
So
you
know
what
you
might
think.
Well,
it's
just
an
addition.
It's
not
that
much,
but
it's
it's
an
atomic
Edition,
which
is
a
memory
barrier,
so
you
know
we
want
to
be
mindful
of
any
import
performance
impact
there.
So
that's
the
sort
of
thing
we're
kind
of
like
thinking
through
and
going
to
begin
testing
soon
as
well,
just
in
terms
of
seeing
making
sure
there's.
D
C
D
E
A
E
I
mean
I
guess.
My
comment
is
I'd
like
to
hear
from
Brian
what
he
actually
captured
from
last
week.
I
guess
there's
some
meeting
notes
somewhere,
but
you
know,
when
he's
back
sure,
yeah
the
GitHub
issue
list
with
the
the
takeaways.
So
we
can
review
because
one
one
thing
I'd
like
to
add,
which
wasn't
discussed
last
week,
is
had
block
drift,
which
is
current
time
minus
block
time,
which
gives
you
a
nice
easy
way
to
calculate
whether
the
the
node
is
on
time
or
not.
F
E
E
F
F
D
F
F
A
A
B
There
there's
not
a
lot
of
meaningful
changes
between
this
and
the
previous
RC
we're
pretty
much
just
going
final,
so
that
we'll
be
targeting
to
release
that,
probably
in
the
afternoon
today,
just
trying
to
get
everybody
lined
up,
but
that's
what
we're
shooting
for
don't
have
a
clear
timeline
on
undoing
just
yet,
but
that
that's
just
not
something
that
we're
handling
as
urgent
or
critical,
just
in
the
time
that
we're
entering
for
the
season.
But
we
are
working
on
getting
that
polished
up.
B
We
may
be
able
to
even
release
that
today,
depending
upon,
if
there's
any
additional
commentary
there,
we
just
haven't
crossed
that
bridge
just
yet
and
regarding
a
3.2.1
patch
release,
we're
presently
not
planning
a
patch
release.
At
this
time,
however,
there's
been
some
discussion
about
basically
I
think
Kevin,
helping
support
a
potential
patch
release
for
wax,
given
that
they're,
the
ones
that
are
being
impacted
by
the
one
issue.
B
That
was
kind
of
helping,
perhaps
justify
a
patch
release,
we're
working
on
trying
to
figure
out
just
kind
of
what
the
scope
of
work
is
for
a
more
elegant
solution
to
that
to
work
into
a
future
release.
But
we
don't
have
a
timeline
for
when
we
would
actually
want
to
get
that
fix
in
and
released
through.
Our
primary
repo
Fleet.
B
We
expressed
the
willingness
to
support
wax
in
performing
a
release,
given
that
the
the
it
seems
like
that's,
where
the
focus
needs
to
be,
and
we're
not
focused
on
getting
this
release
out
for
Antelope
proper.
If
you
will
just
because
I
think
that
we
would
like
to
have
a
more
comprehensive
solution
in
place
than
what
we
would
do
as
a
patch
per
se,.
B
B
That's
like
the
real
blocker
around
it,
since
it
still
has
that
version
dependency,
we're
working
on
getting
rid
of
that
we
just
haven't
yet
so
that's
kind
of
the
the
Blocker
on
that
front,
but
I
don't
think
that
there's
a
lot
of
additional
work,
that's
going
into
Dune
right
now
that
needs
to
get
out
or
anything.
It's
just
waiting
for
this
to
go
final.
B
I
I
know
that
Lynn
had
made
some
one
of
our
teammates
Lynn
and
made
some
progress
on
this.
Let
me
tap
him
on
the
shoulder
as
well
he's
going
to
be
helping
with
the
tagging
of
this
release
and
I
I,
don't
know
if
he
finalized
all
the
documentation
there,
but
we'll
make
sure
to
share
it
out
once
we
do
have
it
I
think
that
it's
close
I
don't
know
that
it
is
finalized,
but
I
will
provide
an
update
in
the
channel
the
telegram
channel
for
this.
B
A
E
E
This
charges
causes
a
lot
of
congestion
in
the
fact
that
lots
of
failed
transactions
or
things
get
in
the
queue
things
pile
up
and
node
us
the
busy
processing
all
these
transactions
and
doesn't
you
know,
blocks,
don't
get
propagated
quickly
or
the
valid
transactions
don't
get
propagated?
Then
you
know
that
we
end
up
with
blocks
with
you
know
not
very
many
transactions
in
it.
E
So
there's
a
few
different
things
that
are,
you
know
as
outcome,
so
I
guess
blocks
get
missed,
which
causes
more
Forks
blocks
are
empty
and
it
gets
into
this
like
kind
of
tailspin,
because
the
more
things
that
don't
get
in
blocks
then
the
more
things
pile
up.
So
then
the
more
things
that
don't
get
involved.
You
know
whatever
so.
E
Yeah,
so
so
yeah,
so
we
it
nodex
performs
well
and
then
the
transaction
goes
up,
it's
still
fine,
and
then
it
gets
to
some
like
Tipping
Point,
and
then
everything
falls
apart
and
the
the
current
solution
is
well
either.
We
can
have
that
resource
model.
Discussion
which
we're
not
having
here
or
you
know,
really
it's
a
it
seems
to
be
tuning.
Some
smart
contracts
on
the
Chain
helps
improve
the
the
list
of
transactions
that
fail
so
that
the
problem
has
to
go
away,
which
is
the
current
situation
right
now.
E
F
F
E
E
E
F
Yeah
but
I
mean
I
thought.
The
bigger
problem
was
the
zero
blocks.
It
was
just,
it
would
spend
all
of
its
time
wasted
and
then
say:
Oh
deadline
for
the
block
exceeded
out
went
a
zero
or
a
one
transaction
block
more
so
than
when
they
got
heavy
and
they
forked
out
I
mean
that
was
kind
of
the
natural
result
for
producer.
A
didn't.
Do
it
so
producer
B
started
getting
thousand
transaction
blocks
trying
to
smash
through
it.
E
So
I
think
that's
why
I
was
trying
to
list
all
the
potential
you
know
I
think
we
came
up
with
four
that
would
you
know
partially
or
fully
address
the
problem.
I,
don't
know
if
this
fully
addresses
the
problem,
I'm
not
sure
we've
actually
seen
the
the
full
extent
of
it,
but
yeah
Michael.
As
you
mentioned,
you
know,
we've
seen
these
sorts
of
problems
going
back
to
more
than
two
years
ago.
F
Yeah,
what
will
happen
is
we're
doing
this.
People
will
flood
out
in
some
way
or
another
kind
of
trying
to
front
run.
So
to
say
you
know
what
Transit
it's
not
true
front
running,
but
trying
to
manipulate
how
they
get
processed
when
they
get
processed
and
even
finding
ways
to
daisy
chain,
almost
like
a
coin,
on
a
string
where
they
can
send
it
down
the
pipe,
but
then
snatch
it
back
out
of
the
vending
machine
and
still
cause
problems
right.
You
know,
and
it
really
kind
of
left
us
with
very
little
insight
into
it.
E
A
E
D
C
C
You
know
I
think
we'd,
look
at
it
introducing
a
logging
framework
that
would
do
that
on
a
separate
thread.
You
know
currently,
that's
all
on
the
main
thread,
all
loggings
on
the
main
thread,
gel
vlogging
and
all
of
it's
on
the
main
thread.
So
it's
pretty
expensive
when
you
start
logging
every
single
transaction
it
it
adds
up.
B
B
C
Just
move
to
a
different
login
framework
that
already
has
that
capability
as
part
of
part
of
it,
so
the
the
second
one
there
the
apply
three
strike
rule
that
that's
actually
in
3.2:
it's
not
in
3.1.
So
that's
a
distinction
between
three
one
and
three
two,
and
so
you
know
we
know,
one
of
the
things
is
to
encourage
everybody,
to
move
to
3.2
in
the
wax
environment,
specifically
to
to
to
help
that
the
first
option
in
in
evaluating
passing
the
blocks
along
quicker.
C
C
That
would
actually
not
help
I,
don't
think,
because
the
that
still
requires
accessing
the
main
thread
and
the
main
thread
is
is
busy
during
this
time
frame
so
that
you
wouldn't
actually
get
access
to
it
to
pass
that
along
that
block
along
any
quicker
than
it
currently
is.
It'd
still
be
a
little
bit
quicker,
but
it'd
still
be
delayed
by
a
hundreds
of
microseconds,
and
so
we're
currently
working
on
a
fix
for
that
right
now.
C
That
would
either
way,
even
without
the
the
pass
along
the
blocks
quicker
to
actually
interrupt
the
main
thread
during
this
processing
so
that
we
can
then
process
the
block
So.
Currently
what
happens
during
speculative
block
execution
today
when
a
block
is
extremely
busy
and
it
has
a
lot
of
queued
up
transactions
is,
it
starts
to
block,
and
it
doesn't
give
up
that
that
main
thread
until
it
gets
out
of
that
start
block,
which
can
be
depending
on
your
your
configuration
for
your
CPU
effort.
C
It
can
be
400,
milliseconds
or
even
full
500,
milliseconds,
typically
400,
milliseconds
of
time
that
that
that
node
is
not
available
to
propagate
blocks
along,
and
so
it
has
to
get
out
of
that
time
frame
to
then
propagate
the
next
block,
and
so
there's
that
delay
there
and
that's
at
every
node
and
so
as
a
block
as
as
the
environment
gets
very
busy.
A
block
start
not
propagating
as
quickly
as
they
should.
C
And
so
then
you
know
that
that
aggregate
14,
which
then
of
course
aggravates
the
whole
thing
again
so
we're
working
on
a
fix
for
that.
We're
hoping
to
get
that
out
into
a
released
soon
and
I.
Think
that
will
have
actually
a
very
big
impact
on
the
the
situations
you're.
Seeing
in
terms
of
like
the
additional
forking
and
the
and
the
in
the
in
and.
E
A
D
E
B
C
D
C
That's
correct:
now
it
is
configurable.
You
know
the
the
three
strike
rule.
We
call
it
three
strike
rule
because
it
needs
to
be
hard-coded.
It's
now
configurable,
even
in
three
one,
it's
configurable,
but
in
three
two,
it's
applied
respectable
blocks
as
well,
but
you
can.
You
can
increase
three
to
a
larger
number
or
a
smaller.
D
C
C
Itself
under
high
load-
and
so
we
just
didn't
ever
realize
that
that
was
happening
so
so
yeah
I
think
that'll
help.
You
know
the
the
other
issue
which
Michael
was
talking
about
about
was
the
fact
that
you
know
people
are
targeting
block
production
time
for
transactions
and
and
they're
failing
there,
which
was
what
the
original
Three
right
three
strike
rule
was
put
in
into
place.
For
you
know,
they're
they're
now
that's
happening
across
many
many
accounts,
so
the
the
the
the
the
subjective
billing
will
kick
in
there.
It's
just
that.
C
C
F
F
It's
not
it's
a
lot
more
go
after
the
tools
to
be
able
to
you
know
as
operators
manage.
It
obviously
mitigate
it.
If
we
can,
but
you
know,
I
mean
yeah,
you
get
enough
CPU,
you
can
just
start
smashing
through
any
barriers
or
billing
levels.
To
the
point
where
you
know
things
have
to
kind
of
have
certain
thresholds
anyway,
yeah.
C
Anyway,
so
some
of
that
you
can,
you
know
you,
we
could
talk
about
blacklisting
or
alternative
three-strike
rule
implementations.
You
know,
I
know
some
of
some
of
you
guys.
Turning
these
big
hits
we're
playing
around
with
you
know,
blacklistings
and
stuff
to
just
allow
some
other
transactions
to
make
it
in
you
know
like
currently,
the
true
strike
rule
is
according
to
account.
You
know
you
could
look
at
a
three-strike
rule
that
is
according
to
contract
and
action
or
something
along
those
lines.
C
You
know,
in
terms
of
when
you
discover
that
hey
this
particular
action
on
this
particular
contract
is
failing.
Like
always
during
this
block
production,
maybe
I
should
just
quit.
Trying
those
you
know,
but
you
know
that's,
obviously,
that's
not
great
I
mean
even
the
three
strike
rule
is
not
great
in
terms
of
like
you
know,
fairness,
if
you
will
so
I,
don't
know,
but
those
are
things
we
we
could
discuss
and
talk
about
as
well.
C
True,
but
you
get
if
you
have
subjective
billing,
the
way
that
works
on
a
relay
node
is
you're
subjectively,
billed
for
transaction
as
it
flows
through
relay
node,
and
you
and
that's
not
credited
back
to
you
until
you
see
it
into
a
block.
So
if
a
transaction
flows
through
relay
mode,
you
get
subjectively
built
for
it.
If
it
fails
on
the
Block
producer,
it
will
never
come
into
a
block
and
so
you've
you've
built
for
it
on
a
relay
node.
C
D
G
C
F
F
F
50
failures
in
a
round,
therefore
optionally,
a
node
operator
can
say
if
you
start
detecting
that
stop
processing
those
to
allow
other
potential,
non-spam
contracts
or
500
failures
or
whatever
it
is
I
mean
you
would
pick
off
those
dexes.
Those
would
get
pretty
hard.
Pretty
quick,
but
I'm
trying
to
wrap
my
head
around
is
that
what
you
were
saying
is
looking
at.
C
So
currently,
the
three
work
strike
rule
works
like
this.
So
right
you
start
a
block
and
you
start
processing
transactions
and
if
you
and
you
look
at
the
authorizer
or
the
first
authorizer
on
a
transaction
and
if
that
by
default's
three,
if
if
that
authorizer
has
three
failed
transactions
in
a
block
as
you're
processing
blocking
State,
oh
okay,
it
failed
three
times
in
this
block.
C
Then
what
happens
is
the
three
right
three
strike
rule
kicks
in,
and
so,
if
that
authorizer
is
seen
again
during
that
block,
this
is
all
during
a
single
block
production
during
that
block
production.
If
you
see
that
authorizer
again,
you
say
you
know
what
you've
failed.
Three
transactions
in
this
block,
I'm
not
going
to
give
you
another
chance,
so
I'll
I
immediately
fail
that
transaction,
and
then
you
go
on
to
the
next
one
and
if
it,
if
it's
that
authorizer
again,
will
you
immediately
fail
it?
Okay,.
F
Than
every
one
of
those
Bots,
as
opposed
to
a
lot
of
them,
were
all
calling
the
same
route
malicious
contract.
If
you
look
at
it
and
subjected
it
from
the
action
side
that
might
give
you,
because
otherwise
you're
just
whack-a-mole
I
mean
that's.
Why
my
logs
are
so
slam
full
is
500
bot
accounts
all
tried
the
same.
You.
C
Right
right,
so
the
the
what
I
suggested
as
an
alternative
potential
alternative
there
is
that
you
could,
you
know,
start
processing
the
block
and
say
you
know
what
I'm
seeing
a
lot
of
of
asserts
and
it's
the
same
contract.
It's
the
same
action.
You
know
it's
different
for
thought.
Authorizers
in
this
case,
but
I
say:
hey.
You
know
what
this
action
on
this
contract.
It
seems
to
be
failing.
You
know
maybe
every
time
or
certainly
many
times,
and
at
some
point
you
could
say.
C
G
C
Make
some
determination
about
hey
this
particular
action?
This
particular
account
I
have
determined,
is
failing
too
much
right
now.
Now
the
question
would
be.
What
do
you
do?
The
the
for
first
authorizer?
What
we
do
is
we
immediately
start
are
dropping
those
transactions.
They
don't
give
them
a
chance.
You
could
you
could
do
that
right.
You
could
say.
Well,
you
know
what
we're
done
with
this
contract
in
action
anymore,
I
see
on
there
I'm,
just
gonna
I,
just
don't
immediately
failing
and
not
do
anymore.
D
C
E
C
A
F
C
F
That's
why
I
try
to
wrap
my
head
around
I
like
the
idea,
because
you're
not
whacking
the
moles,
you
can
more
yeah,
make
it
more
expensive
of
picking
up
the
contracts
and
not
just
a
fleet
of
accounts.
But
yes,
I
mean
there
is
a
danger,
I
mean
maybe
a
whitelisting
ability.
You
know
to
at
least
be
like
look.
We
know
that
this
account
is
getting
exploited.
Stop
you
know,
building
it
at
the
the
Action
level,
so
to
say,
but
I
don't
know
if
I
was
kind
of
trying
to
think
about
it.
F
E
F
Well,
that's
only
because
we
can't
stop
them.
I
think
the
contracts
are
more
expensive
than
the
accounts.
That's
why
I
say
is.
If
you
can
start,
maybe
targeting
those
those
contract
accounts
underneath
or
stop
chasing
the
the
moles
and
try
to
pick
up
the
pattern.
I
don't
know
I
I.
Yes,
it's
got
pros
and
cons,
I,
don't
know,
but
it's
an
optional.
F
At
least
it
gives
you
the
ability
to
be
like
all
right,
all
hell's
break
and
lose
start
getting
mad
at
people
asserting
you
know,
I
mean
start
start
blocking
the
the
contracts
that
are
just
blatantly
getting
abused
to
at
least
allow
99
of
the
rest
of
the
network
to
operate
through
that
relay
node.
It
doesn't
it
across
the
board.
I.
C
F
G
Happening
yeah,
all
of
them
a
suggestion
for
the
subjective
billing
I
mean
I,
think
like
most
blockchains,
they
just
they
put
the
transactions
in
a
MIM
pool.
If
the
transaction
fails,
the
user
still
has
to
pay
the
transaction
fee
for
that
failed
transaction
which
goes
on
chain
so
like
it
seems
like.
We
don't
want
to
do
that,
so
we're
going
to
have
this
off
chain
subjective
billing
solution
as
an
alternative.
G
G
So
this
leads
to
like
a
very
bad
user
experience
like,
for
example,
like
the
EOS
power-up
contract.
Sometimes
I
need
to
go
in
and
manually
make
some
transfers
and
you'd
be
surprised
about
50
of
the
time
I
can't,
even
if
the
contract
has
CPU,
because
whatever
particular
node
I'm
talking
to
behind
a
proxy
has
subjectively
blocked
it,
because
there's
just
so
many
actions
that
happen
on.
F
Farther
than
that,
maybe
we've
got
our
relay
nodes
behind
them,
so
you
may
bounce
in
through
different
apis
and
get
one
and
not
the
other,
but
then
they
both
feed
into
a
central
relay
node
and
it's
obviously
counting
everything.
But
you
didn't
get
a
failure.
It
just
didn't,
go
all
the
way
down
the
pike
so
yeah,
that's
exactly
what
you're
describing
exactly.
F
G
So
like,
for
example
like
in
ethereum
like
if
you
push
a
transaction,
you
can
sit
there
and
watch
it
in
the
mempool
until
someone
picks
it
and
puts
it
in
a
block,
so
you
don't
care
like
whatever
node
you
originally
sent
it
to.
It,
doesn't
really
matter
because,
as
long
as
you
can
see
it
in
the
mem
pole,
that
means
many
nodes
on
the
network,
see
it
in
our
TR.
You
know
speculatively
going
to
include
it
in
the
next
block.
G
You
know
whatever
the
miner
decides
to
do
right,
but
there's
no
visibility
for
us,
because
we
don't
have
this
kind
of
cash
or
you
know
secondary
service
where
the
transactions
live.
That
and,
and
also
like
I,
some
ability
for
the
user
to
see
what
is
the
subjective
billing
status
of
my
account
like
when
sending
maybe
that
was
added
and
I
missed
that,
but
is
there
some
way
for
me
to
see
the
the
status
of
my
subjective
billing?
You
know
status
on
a
particular
node,
so
that
I
know
what's
happening
an.
G
Okay,
cool
got
it
so,
but
yeah
I,
really
what
I
really
think
if
we're
gonna
have
this
subjective
billing
thing
we
need
to,
it
needs
to
be
its
own
process,
and
these
it
needs
to
be
broken
out
from
inside
notius,
where
we
have
this,
like
very
it's
like.
We
have
this
very
rudimentary
solution,
or
something
which
is
extremely
important
and
really
like
needs
to
have
a
lot
of
options
and
a
lot
of
customers.
Customizability.
C
E
Yeah
and
and
so
John
I
would
start
go
back
to
your
first
comment,
which
is
since
we
don't
bill
for
failed
transactions.
Well,
maybe
we
should
maybe
we
should
build
transaction,
which
is
part
of
that
resource
model.
Discussion,
I
think
so.
I
think
that,
should
that
discussion
about
going
for
film
Productions
should
be
on
the
table.
We
just
don't
have
the
right
people
in
this
meeting
right
now
to
discuss
it
so
we'll
discuss
it
at
some
meaning
in
really
nice.
Here.
G
Yeah
and
I
and
I
just
wanted
to
add
to
that
the
the
idea
that
you
could
even
bill
for
failed
transactions
on
a
per
node
basis-
subjectively,
for
example,
I
deposit,
some
transaction
fees
into
Michael's,
EOS,
USA
transaction
pool
and
if
I
send
failed
transaction
to
Michael.
He
takes
some
bit
from
that
pool
and
obviously
you
have
to
trust
the
node
operator
in
this
instance.
G
But
if
you
trust
the
node
operator
and
you're
a
good
actor,
it's
basically
you're
putting
up
a
a
bond
so
to
say
that
then
so
that
you
can
get
reliable
transactions
post
through.
And
if
you
don't
put
up
that
Bond,
then
his
node
can
just
safely
ignore
any
transactions
that
you
push
through,
and
this
could
be
done.
You
know,
by
projects
on
behalf
of
their
users
also.
A
C
F
Say
yeah
when
you're
having
problems,
unless
you
know
you
have
to
like
I,
can
tell
you.
This
I
have
to
run
some
of
my
nodes
without
subjective
billing
on
because
the
services
are
designed
to
to
Pepper
and
that's
what
I'm
trying
to
think
you
know
I
mean
as
I
start
to
mix
and
match
all
the
nodes
together.
I
mean
I,
try
to
keep
them
from
being
able
to
bleed
their
way
around.
C
F
A
B
H
A
lot
of
it
is
also
Gathering
our
thoughts
prior
to
doing
a
it's,
not
a
really
a
public
discussion,
type
of
thought
process
like
so
everybody
who
would
be
invited
as
a
sort
of
key
opinion
leader.
You
know,
write
down
things
started
with
a
document
start
with.
You
know
a
written
form
so
that
way
kind
of
the
ideas
can
kind
of
be
written
down
on
paper
and
not
just
discuss
verbally.
You
know,
brainstorming
so,
but
once
we
get
to
that,
you
know
those
written
down
ideas
and
we've
kind
of
really
fleshed
it
out.
H
Then
we
can
have
the
sort
of
public
debate
on
a
few
little
topics
that
are
more.
You
know
harder
to
discuss,
but
a
lot
of
prep
needs
to
happen
before
we
just
jump
into
a
meeting,
because
then
we'll
just
be
running
around
in
circles,
so
I
think
Oregon
could
probably
take
that
lead.
If,
if
he's
up
for
it,
if
he
has
good
capacity
and
then
we
can
kind
of
flesh
out
some
of
the
additional
ideas
around
it.
H
H
H
H
A
H
Or
a
bunch
of
proposals,
a
proposal,
B
proposal,
C
option,
one
two:
three:
that
could
be
a
lot
of
paths
and
a
lot
of
avenues
we
can.
We
can
take
what
are
the
pros
and
cons
and
you
know
so
I
would
see
a
lot
of
different
routes
we
can
take.
So
this
would
need
to
be
kind
of
drafted
prior
to
even
having
a
public
discussion.
A
B
So
a
quick
thought
from
my
end,
I
I'm,
very
conscious
of
the
fact
that
our
egg,
quite
frankly,
is
one
of
the
more
over
subscribed
people
right
now,
just
in
terms
of
his
capacity
and
I,
absolutely
don't
feel
comfortable
volunt
telling
him
that
we
gave
him
this
on
a
call.
He
couldn't
make
it
to
so
yeah.
One.
B
B
Okay,
but
let
me
actually
insert
my
influence
from
that
product
Direction
and
say
that
I
think
a
more
productive
discussion.
We
could
have
the
Dozen
lean
so
heavily
on
our
egg
and
kind
of
makes
it
this
more
natural
discourse
between
you
know
the
enf
and
all
of
these
stakeholders
is
having
a
broader
discussion
to
aggregate
all
of
these
problems
that
people
are
facing
right.
B
H
Yeah
and
I
think
the
right
on
Brian
from
enf
is
taking
on
that
lead
of
kind
of
getting
the
questions
getting
the
feedback
from
the
community.
So
maybe
again
you
want
to
put
in
like
Brian
as
the
sort
of
data
aggregator
from
the
community
feedback,
and
then
we
can
kind
of
like
help,
support
all
the
community
feedback
ideas.
So
I've,
given
my
two
cents
to
Brian
whether
that
goes
in
fine
but
I,
think
Brian
is
taking
the
lead
on
doing
that.
Aggregation
so
Brian
from.
D
B
I
think
in
this
scenario,
since
Brian
is
actively
working
on
this,
that
it
may
be
less
problematic.
I
know
this
is
being
reported,
but
I
I
I'll,
maybe
I,
can
chat
with
Brian
and
talk
to
him
about
where
he's
at
I
think
he's
sick
as
a
dog
right
now,
I'm
like
not
getting
responses
from
so
I
feel
bad
for
the
guy,
but
I
think
that
Dani
is
correct,
that
he
has
been
working
on
this
to
some
extent.
B
A
Hope
he
feels
better,
so
yeah
we
got
a
couple
weeks
off.
Hopefully
he's
that's
enough
time
for
for
him
to
recover,
and
we
can
check
in
in
the
new
year
see
how
that's
going
I'm
happy
to
let
him
leave
that
discussion.
I
think
he's
probably
better
positioned
to
to
do
an
effective
job,
leading
that
discussion
so
I'm
happy
to
take
a
back
seat,
get
the
zoom
up
and
running
participate
as
much
as
I
can,
but
make
more
of
a
back
seat
on
that.
B
Yeah,
so
it
sounds
like
the
action
item
really
is
that
we?
Maybe
the
action
item
can
be
Daniel
you
Brian
and
I,
when
he's
back
in
good
health
can
coordinate
and
identify
when
best
to
schedule
this
meeting
so
that
we
can
set
the
context
and
make
sure
everybody's
aligned
about
when
it's
happening,
and
we
can
just
commit
on
a
date.
B
That's
realistic
when
we
can
announce
this,
but
you
know
we
we
can
do
the
facilitation
and
organization,
and
then
the
people
who
have
these
needs
and
problems
can
show
up
and
communicate
them,
and
maybe
we
can
even
request
that
they
document
some
of
that
more
comprehensively.
As
was
mentioned
in
the
meeting
earlier
in
advance,.