►
From YouTube: EIPIP meeting 40
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/83
A
Welcome
to
eipip
meeting
forty,
I
have
shared
agenda
in
the
chat.
A
A
I
just
added
this
item
to
feel
like
how
do
people
think
about
adding
information
of
execution
clients
at
the
execution
specs
like
I'm,
not
aware
of
any
particular
placeholder
where
we
can
get
all
these
information
like
website,
github
link
or
latest
version
listed
there
for
a
new
user
to
refer
to.
So
what
do
people
think
generally
on
this
proposal.
A
A
Cool
right,
so
I
suppose
this
small
crowd
do
not
think
that
there's
an
issue
with
that.
So
let's
keep
it
positive.
I
don't
see
tim
on
the
call
today.
A
Right
yeah
I
mean
it
is
for
clients,
information,
so
clients
should
be
usually
okay
and
that's
right.
Okay
sounds
good,
so
yeah
I
I
can
look
into
adding
primary
information
of
the
clients.
A
Moving
on
to
the
next
item.
It
is
update
eip
editors.
I
have
referred
an
issue
there,
which
I
found
on
the
eips
github
repositories.
So
at
the
moment
they
present
eip1
shows
10,
eap.
Editors,
though
we
do
not
have
all
of
them
being
very
active.
So
I
was
looking
into
the
history
and
particularly
three.
A
I
found
a
name
that
I
have
not
seen
at
least
for
a
year
number
two
number
five
and
number
six,
so
I
was
wondering
like
do
we
need
to
have
these
people
here
listed
and
like
get
them
pinged
every
time,
though
they
are
not
actively
involved,
or
is
it
the
right
time
to
update
the
eip1.
D
C
Yeah,
I'm
conflicted
so
it'd
definitely
be
nice.
C
If
we
had
a
list
of
vip
editors
that
was
actually
like,
accurate
and
active
like,
for
example,
if
you
were
to
ping
casey
detrio
about
something
ap
related,
you
would
not
get
any
help
right
and
so
having
a
list
of
editors
that
were
like
if
a
user
is
new,
they're
going
to
start
from
the
top
of
the
list
and
start
paying
people
until
they
get
an
answer,
and
they
won't
actually
get
an
answer
until
they
get
very
far
down
the
list,
because
the
active
editors
are
the
ones
at
the
bottom.
C
That
being
said,
like
that,
list
of
people
is
basically
a
list
of
people
who
have
merge
rights
and
have
a
voice,
and
so
while
I
would
like
to
pair
that
down
to
the
people
who
are
actively
participating
at
the
same
time,
I
don't
want
to
like
forcibly
kick
anybody
out,
and
so
that's
why
I'm
conflicted,
because
I
would
like
that
list
to
accurately
represent
who
the
editors
are,
and
I
would
like
the
editors
to
be
the
set
of
people
who
are
actively
involved
in
editing
and
at
the
moment,
that's
like
two
and
a
half
of
the
people
on
this
list
meet
that.
C
I'm
I'm
generally
not
a
fan
of
just
like,
especially
since
you
know
I
I'm
one
of
those
two
and
a
half
people,
I'm
really
not
a
fan
of
like
using
that
power
and
saying:
okay,
I'm
kicking
out
everybody
else
who
could
challenge
me?
And
now
it's
just
me
in
charge.
C
That's
why
I'm
conflicted
like
if
I
was
a
external
third
party,
I
would
say
kick
out
everybody,
but
michael
matt
and
alex
because
everybody
else
hasn't
shown
up
to
a
meeting.
Have
it
hasn't
contributed
significantly
to
the
editing
process
or
decision
making
or
actively
editing
for
like
a
year,
but
because
I'm
in
the
process,
I
am
very
hesitant
to
actually
make
that
recommendation,
because
it
might
be
just
my
biases
seeking
to
secretly
gain
power.
E
Happy
to
say
it's
not
just
you,
I
think
it
makes
a
lot
of
sense
to
split
the
list
like
I
don't
think
we
should
delete
them,
but
just
have
like
a
section
saying:
they're,
inactive
or
emeritus
is
the
fancy
word
for
that?
I
guess.
B
It
it
doesn't
really
feel
like
we
need
to
do
anything
like.
I
don't
think
people
are
realistically
pinging
casey
to
merge
things,
so
it
kind
of
feels
like
we're.
Just
like
yes
on
the
face,
it
seems
like
a
nice
thing,
because
we
are
in
the
process
and
we
know
who's
involved
and
we
look
at
eip1,
but
in
reality
no
one
else
looks
at
eip.
One
or
the
list
of
editors.
C
A
Yeah
right,
I
just
picked
it
up
from
the
issues
section
where
someone
has
actually
requested
to
get
it
updated
and
like
on
occasions,
I
have
seen
people
listing
all
of
those
people
like
listed
on
the
eip
editors,
and
I
think
I,
like
both
the
idea
of
having
it
like
you
know,
I'm
most
active
people
on
the
top
and
like
then
go
downwards,
and
people
who
are
not
actively
involved.
A
I
I'm
not
sure
if
their
ids
are
even
like,
you
know
valid,
or
they
should
be
pinged,
so
we
can
update
if
if,
if
no
one
has
strong
objection
at
least
three
names,
I
can
see
here
number
two
number
five
and
number
six
which
I
have
not
seen
for
over
a
year.
We
can
do
that
and
I
I
don't
think
I
mean
it
should
be.
It
should
be
personal
to
anyone,
because
I'm
not
an
eip
editor.
A
I
think
I
can
speak
for
it,
like
micah
said
that
he
wants
to
secretly
gain
all
the
power.
So
if
there
is
no
general,
like
you
know,
strong
opposition
on
that,
we
can
probably
update
the
list.
F
A
Okay:
okay,
I
think
we
are
good
and
we'll
try
to
go
ahead
and
clean
up
this
eip
one,
and
that
would
be
good
because
we
are
making
a
lot
of
changes.
This
would
be
one
of
those,
and
I
I
think,
having
this
sorted
out
will
help
many
new
people
who
are
trying
to
enter
the
process
and
document
some
of
the
proposals
to
be
a
standard
for
ethereum.
A
Moving
on
to
the
item
number
three,
so
I'm
happy
to
share
that
a
number
of
open
pull
requests
are
now
below
25
like
it
was
like
big
number
earlier,
but
having
it
below
25
is
very
good
progress.
I
can
say
now
we
have
more
eip
additives
actively
involved
like
we
have
at
least
half
more.
We
are
making
good
progress
in
this
direction
and
I
am
a
little
concerned
about
the
open
issues
because,
as
of
today,
the
number
shows
485
open
issues
like
which
is
significantly
high.
A
C
C
C
Right
now,
our
policy
is
to
say
either
create
a
magician's
thread
or
create
a
github
issue
for
discussions
too.
As
long
as
we
have
that
policy
there
will
always
be,
I
think,
a
large
number
of
open
issues.
C
Also,
we
tell
people
to
start
the
eip
process
by
creating
an
issue
to
discuss
it,
and
so
I
think,
as
long
as
those
two
things
are
present,
we're
never
gonna
get
the
issues
down
to
close
to
zero,
like
it'll
always
be
a
big
number,
and
so
my
strategy
has
thus
far
been
just
ignore
that
number
and
just.
C
Issues
in
general,
I'm
not
against
changing
that,
though,
there's
some
caveats
there
like
we
don't
necessarily
want
to
force
everybody
to
create
accounts
at
other
services
like
they
already
had
to
create
a
github
account.
We
don't
want
to
necessarily
make
them
go,
create
an
account
somewhere
else
just
to
create
an
eip,
which
is
why
we
allow
them
to
do
github
issues.
C
A
Yes,
that
was
on
my
list
like
the
how
to
address
issues
like
number
one
is
like
discussion
tooling.
A
I
I
think
we
have
made
some
changes
to
reflect,
that
discussion
to
link
should
be
the
fellowship
of
ethereum
magician,
because
that
is
the
place
where
most
of
the
devs
are
hanging
out
to
discuss
any
of
the
issue,
and
sooner
or
later,
if
we
have
like
central
place
for
discussion,
I
think
is
going
to
be
good,
not
only
to
get
discuss
that
particular
proposal,
but
to
look
into
other
issues
which
are
like
you
know,
being
discussed
in
the
ecosystem,
and
the
number
two
would
be
address
and
close
open
issues
like
p
issues
that
those
are
not
like.
A
A
I
hear
micah
on
on
thought
of,
like
not
forcing
people
to
have
another
account
to
create
a
discussion
to
link.
But
as
much
as
I.
B
A
C
So
when
we
institute
that
policy
github
discussions
did
not
exist,
you
know
discussions
now
exist.
Does
it
make
sense
to
keep
discussion
two
links
in
github
discussions
and
just
stop
recommending
people
go
to
ethereum
magicians?
Absolutely
so
we'd
achieve
the
goal
of
a
single
central
place.
It's
just
that
central
place
would
be
github
discussions,
not
github
issues
not
to
ethereum.
E
It's
a
new
feature
like
what,
if
they
can
it
in
three
months,
because
it's
not
a
good
feature,
I
would
what's
the
reason
we
don't
send
people
just
to
eat
magicians.
C
C
E
I'm
not
sure
I
can
try
to
log
out
and
log
back
in
see
if
it
gives
me
a
prompt
or
something
it
won't
give
you.
C
Yeah
I'd
say:
let's
find
that
out.
If
we
can
remove
the
email
address
requirement,
then
I
see
absolutely
no
problem
with
email
address.
Request
requirement
like
I
can
see
the
argument
for
why
do
I
have
to
give
my
email
address
to
some
service
that
I
may
not
trust
github
is
you
know
well
established
ethereum
magicians,
not
so
much,
and
so
you
know
the
few
other
people
you
have
to
give
your
email
address
out
to
the
better.
In
theory,
if
you're
trying
to
remain
kind
of
anonymous.
C
Now
that's
the
general
argument.
I
mean
this.
It's
it's
not
a
super
strong
argument,
but
I
can
appreciate
it
like.
There
are
people
in
this
space
who
prefer
anonymity
and
yet
they
also
contribute
like
it's
not
like.
We
just
want
to
do
it.
For
the
sake
of
doing
it,
there
are
people
who
I've
seen,
contribute
meaningfully
that
don't
like
giving
out
their
email
address
or
their
picture
or
whatever.
A
On
that,
my
personal
thought
is
like
there
are
only
a
few
proposals
which
actually
needs
like
a
detailed
discussion
and
most
of
the
proposals.
They
are
good
with,
like
the
pull
request,
github
discussion.
Only,
although
I
I
prefer
that
it
is
always
good
to
have
central
place
for
discussion,
let's
see
what
what
it
goes
with
the
fellowship
of
ethereum
magician,
but
people
at
at
the
moment
they
they
do,
provide
a
email
address
to
github
and
like
they
have
one
like.
You
know
one
place
where
we
are
discussing
it.
A
So
if,
if
there
is
like
no
strong
opposition
by
any
particular
author
like
we
want
to
have
it
on
the
github
issue
to
be
discussed,
I
think
it
makes
sense
to
either
continue
discussion
in
fellowship
of
ethereum
magician
or
if
there
is
like
small
discussion
needed
and
addressing
just
concern
that
needs
to
be
fixed
before
the
proposal
can
be
moved
to
different
status.
That
can
be
addressed
in
the
pull
request.
Section
too.
C
C
C
A
To
be
fair,
like
I
see
like
very
small
number
of
people
who
may
have
like
not
created
an
account
with
fellowship
of
ethereum
magician,
but
even
if
there
is
one
user
we
should
respect
their
privacy.
I'm
not
saying
that
we
should
force
them
to
do
that,
but
I
think
in
general
recommending
making
it
a
strong
recommendation
going
for
fellowship
of
ethereum
magician.
May
you
know
in
future
help
us
people
adopt
this
as
a
part
of
process
and
like
they'll,
be
fine
with
that.
A
Okay,
so
I
had
listed
here
quite
a
few
issues
which
I
found
that
like
either
may
not
be
relevant
to
the
present
date,
or
maybe
something
that
you
know.
A
We
need
to
take
a
decision,
whether
it
should
be
there
or
should
be
close.
So
my
my
question
here
is
for
eip
editors,
of
course
like
at
what
point.
We
think
that
these
issues
are
not
relevant
and
should
be
closed,
because
we
have
like
limited
number
of
people
actually
looking
into
it
and
leaving
comments.
So.
C
I
think
my
gut
reaction
is:
we
just
follow
the
same
strategy
for
stagnant.
So
if,
if
there's
six
months
with
no
discussion
on
an
issue
like
this,
where
the
user
is
proposing
some
new
idea,
then
we
close
it
separately.
There
are,
if
it's
a
discussion,
two
for
an
eip
that
has
gone
stagnant
or
has
gone
final.
We
close
it.
C
Sure
so
I
guess
from
a
policy
standpoint,
I
I
think
what
I
described
as
defined
policy.
I
I
have
no
intention
of
actually
upholding
that
policy,
but
if
someone
wanted
to
like,
if
pooja
was
browsing
noticed
one,
I
would
have
no
problem
with
implementing
that
someone
implementing
that
policy
does
that
make
sense.
A
Yeah
right
yeah,
I
was
more
looking
towards
what
policy
should
be
and
these
both
look
like
very
good
suggestion,
the
one
that
we
are
using
for
a
stagnant
on
the
pull
request.
The
same
can
be
applied
on
that.
I
don't
know
if
if
it
is
technically
feasible
or
not,
but
I
know
alita,
you
had
implemented
some
bot
for
the
pull
request
section.
I
would
be
curious
to
know
your
thought
if
the
same
logic
can
be
applied
here
to
reduce
this
number.
A
Oh
sorry,
alita
has
a
mic
issue
she
mentioned
earlier
in
the
call,
so
maybe
we'll
get
back
to
it
later,
but
in
general
policy
was
do
people
have
like
you
know,
different
thought.
I
think
in
chat.
She
just
mentioned
that.
Yes,
it
is
possible
and
it
can
be
applied.
Probably.
A
So
yeah
the
two
points
that
micah
mentioned
was:
if
eip
idea
is
six
months
with
no
discussion
close
as
a
stagnant.
If
eip
discussion
to
issue,
then
we
have
to
close
it
and
if
eip
is
a
stagnant,
withdrawn
or
final
right.
I
think
this
will
significantly
lower
down
the
number,
because
there
are
many
proposals
which
are
actually
closed.
They
are
in
final
status
and
their
issue
is
still
less
there.
C
A
Yeah,
I
think
the
first
step
here
would
be
like
if
the
bot
leaves
a
comment
that
if
there
is
no
further
action,
it
will
be
closed
within
a
week
time
or
so.
I
am
assuming
that
an
author
may
respond
if
they
are
really
interested
into
that.
However,
manually
whatever
can
be
done
for
the
issues
which
which,
like
you
know,
which
are
new,
but
they
may
not
be
the
right
fit
for
this
particular
place.
So
I'll
try
to
leave
a
comment
on
that
and,
like
you
know,
we
have
people.
A
We
can
do
that
and
for
like
in
general
response
to
bot.
I
think
we'll
get
some
response
and
that
would
be
helpful.
A
So
there
is
this
one
issue
which
is
a
number
3604.
I
am
curious
to
know
if
there
is
any
update
on
that.
I
know
it
was
brought
into
community's
attention
a
while
ago.
It's
about
update
mobile
layout
to
wrap
versus
overflow.
A
C
C
Unfortunately,
safari
is
very
non-standard.
They
are
the
for
those
of
you
that
have
been
around
the
web
for
a
while
they're
the
equivalent
of
ie6
no
like
they
don't
implement
things
right
and
they're
very
slow
to
implement
things,
and
these
cause
problems
anyway,
this
person
said
they're
having
some
rendering
problems,
which
you
know
is
a
reasonable
complaint,
but
I
don't
have
a
ios
device
to
reproduce,
so
I'm
unable
to
verify
what
they're
claiming,
which
also
makes
it
hard
to
troubleshoot
and
fix
so
so
yes,
this
is
potentially
an
engineering
problem.
C
C
So
yes,
there's
definitely
a
technical
problem.
Just
basically
a
incompatibility
in
the
ui
with
safari
is
my
guess.
It
could
be
something
else,
but
the
person's
screenshot
indicates
that
it's
safari,
the
rendering
is
definitely
wrong
like
that
is
not
what
it's
supposed
to
look
like
so
yeah,
so
I
just
need
to
reproduce
it
step.
One
verify
the
cause
of
the
problem
and
then
fix.
C
I
mean
part
of
the
reason
I
haven't
done.
It
is
because
I
hate
safari
and
I
refuse
to
support
anybody
who
uses
that
terrible
browser.
G
C
Yeah
check
out
eip
721,
that's
the
one
the
user
reported
was
the
problem.
D
A
Okay,
okay,
so
yeah.
I
think
we'll
we'll
try
to
leave
a
comment
I
mean
like
if,
if
any
other
user
do
not
face
the
same
problem,
even
I
will
try
to
check
it
on
my
cell
phone
and
then
leave
a
comment
in
case.
It
is
like
individuals
problem.
Then,
then,
maybe
this
issue
can
be
closed
so
similar
to
that
like
that
is
the
one
like
we
don't
know
what's
going
on
like?
Should
it
be
open
or
not
I
mean,
should
it
be
closed?
A
There
is
another
issue,
I'm
sharing
the
link.
The
number
is
three
five,
four
eight,
which
I
think
was
related
to
one
five,
five,
nine,
the
proposal.
Now
that
this
is
final,
and
this
thing
this
issue
seems
to
be
old.
C
So
this
is
one
of
the
examples
where
it's.
Basically,
someone
has
an
idea
for
an
eip
and
they're
following
the
proper
instructions,
which
is
to
start
from
an
issue
and
get
feedback,
and
so
this
is
where
I'd
say,
follow
the
process
we
described
above
so
six
months,
no
comments
close
it
as
stagnant
and
that
will
be
in
like
october
november
or
something.
A
C
I'd
say:
let's
start
by
just
following
the
procedure
we
described
and
I'm
totally
fine
with
someone
else
just
taking
that
up
and
making
a
call
on
them.
The
key
is
there's.
Most
issues
will
fall
into
one
of
two
categories:
it's
an
eip
idea
and
those
in
those
cases
it's
someone
who
has
an
idea
and
they're,
proposing
it
to
the
broader
ethereum
community
for
discussion.
C
So
they're
just
saying:
hey,
here's
an
idea:
let's
talk,
sometimes
people
format
this
like
in
the
eip,
so
it
kind
of
like
it's
an
issue,
but
it's
like
got
the
iep
sections
the
same
same
thing,
so
these
are
just
people
with
ideas
for
eips
that
are
not
yet
draft
eips,
they're,
just
good
ideas
for
those
cases.
C
Just
if
it's
been
six
months,
when
no
one's
commented,
we'll
close
that
stagnant
and
again
I'm
totally
okay
with
whoever
takes
this
task
on
just
handling
that
themselves,
I
don't
think
we
need
to
get
like
unanimous
decision
worst
case
scenario.
Someone
closes.
What's
the
name
correctly,
we
just
reopen
it.
The
other
issue
to
look
for
is
ones
that
are
the
discussion
too.
C
So
if
usually,
someone
will
say
in
like
the
link
title
in
the
title
or
something
I'll
say,
discussion
two
for
eip,
one,
two,
three
four
or
something
along
those
lines
and
those
ones
are
usually
pretty
obvious.
They
usually
have
a
link
to
the
eip
and
it
says
somewhere
in
there.
This
is
a
discussion
to
link
and
for
those
ones.
C
We
just
would
have
to
check
the
eip
that
they're,
referring
to
if
it
is
in
one
of
the
the
kind
of
terminalis
states
so
such
as
final
withdrawn
or
stagnant
or
bannon,
would
abandon
whatever
we
called
it.
Then
we
would
close,
and
if
it's
not
we'd,
leave
it
open
and
again
same
thing,
the
first
one,
whoever
handles
this
task,
I'm
totally
fine
with
them
just
taking
ownership
and
dealing
with
it
all.
I
don't
think
we
need
to
run
it
by
the
whole
group.
A
That
makes
sense,
I
think
there
is.
I
mean
like
if
this
is
a
different
category
here
I
I
have
just
shared
the
number.
Pr
number
is
3636,
so
they
just
write
it
like
will
that
be
and
just
idea
category,
and
we
can
do
the
same
thing,
because
it's
difficult
to
actually
get
what
they
actually
want
to
do
with
this
like
do
they
want
to
create
an.
C
A
C
And
you
can
usually
tell
us
an
idea
just
like,
if
someone's
just
describing
like
a
some
solution
to
a
thing.
Those
are
just
all,
in
my
opinion,
fall
into
the
category
of
ideas
that
people
have
people
format
them
differently.
There's
all
sorts
of,
like
some
people
form
it
like
this,
so
you'll
format
it
like
an
eip.
Some
people,
just
like
it's
just
a
couple
of
paragraphs,
so
the
format
differs,
but
they
all
generally
have
the
same
theme
of
someone
is
describing
a
solution
to
a
problem.
A
Right
that
makes
sense
cool,
so
I'll
look
into
some
of
those,
and
I
don't
know
we
can
check
on
the
feasibility
of
getting
it
done
with
the
help
of
bot
and
yeah.
We'll
come
back
on
this
again.
A
Okay,
so
the
next
one
is
eip.
Erc
editors
in
training,
progress.
We
had
this
meeting
yesterday.
There
were
over
a
dozen
of
proposals
which
were
like
reviewed
and
light
client
and
william
left
some
comments
on
that
one
particular
pull
request
that
I
want
to
bring
it
here
is
number
three
five,
five
one.
I
just
have
shared
the
link
here,
so
the
question
that
we
were
trying
to
discuss
there
was
like
this
proposal
is
actually
proposed
as
an
informational
eip,
but
editors
think
that
it
could
be
an
erc.
A
A
Yeah,
actually,
this
is
like
a
kind
of
proposal,
because
I
have
seen
this
type
of
issue
coming
like
twice
in
like
recent
days.
I
understand
that
earlier
it
we
discussed
that
it
should
be
author's
choice
and
like
whatever
category
they
want
to
put
in
either
erc
or
informational
or
any
other
category
of
eip
should
be
fine.
A
C
Or
not
sure
of
so
for
eip
for
core
eips,
it
should
be
very
clear
like
if
it
changes
the
consensus
rules
between
the
core
clients
and
the
core
eip.
If
it
doesn't,
then
it's
not
a
core
ap
for
erc.
If
I
remember
correctly,
I
mean
I've
been
while
I
looked
at
eip1,
but
I
think
for
core
eips
or
sorry
erc's.
C
For
interface,
it's
usually
things
like
you're,
defining
a
an
interface
for
lack
of
a
better
word
between
two
disparate
systems
like
you've
got
two
clients
or
two
a
client,
a
server
that
are
talking
to
each
other,
and
you
need
a
standardized
interface
between
them,
because
you
have
many
many
relationship.
So
if
you've
got
like
the
simple
example
is
like
web
browsers
and
web
pages,
you
have
many
web
browsers.
You
have
many
web
pages,
you
want
all
the
web
pages.
C
People
talk
to
all
the
web
browsers,
and
so
you
need
to
have
a
standard
interface
that
they
can
communicate
across
that
boundary
and
so
that
standard
interface
would
be
like.
Maybe
the
javascript
ap
standard,
javascript
api
for
the
browser,
and
that
would
you
know
that's
similar
in
the
ethereum
ecosystem
to
the
json
rpc
api,
where
you
have
many
clients,
and
then
you
have
applications
that
many
applications
that
all
want
to
talk
to
those
clients.
C
And
so
again
you
have
a
many-to-many
relationship
and
you
are
trying
to
define
the
communication
protocol
between
things
on
one
side
of
that
relationship
and
things
on
the
other
side
of
that
relationship.
Erc.
On
the
other
hand,
is
more,
I
don't
know
years
he's
weird.
Your
c
is
basically
like
functionally
it's
basically
standard
contracts
like
which,
arguably
are
usually
interfaces,
but
if
it's
a
contract
in
the
evm,
then
it
usually
goes
into
erc
category.
A
Yeah
right,
of
course,
it
helps
so
yeah
we
are
just
trying
to
you
know.
Let
people
know
that
you
can
refer
to
eip1,
but
there
are
some
corner
cases
where
they
get
confused
and
they
come
for
help.
This
eip3551
is
one
of
those,
although
it's
just
a
pull
request.
As
of
now
it
hasn't
been
merged.
So
the
author
is
trying
to
make
it
as
informational,
and
it
seems
like
more
of
an
erc.
A
Right
yeah,
so
we
are
just
waiting
on.
You
know
the
author's
response.
I
suppose
william
left
a
comment
and
so
did
lifeline
and
we're
waiting
for
his
response
and,
if
he's
like
strong
into
getting
it
informational,
I'm
not
sure
if
there
is
other
way.
A
A
I
know
you
have
some
mic
issue,
so
I'm
just
reading
out
her
comment
on
the
chat.
Jason
rpc
is
the
hidden
berg
at
the
moment.
I'm
hopeful
I'll
be
off
the
project
soon
more
time
for
bots
okay.
So
there
are
some
changes
going
on
in
the
process
and
like
the
status
of
this
project
is
in
question
and
we
are
looking
forward
to
understand
what
what
is
the
amount
of
work
left
to
be
done
on
this?
It's
not
very
clear
at
the
moment.
We
hope
to
see
some
responses
from
different
team
involved
in
this.
A
Okay,
that's
all
from
the
agenda,
and
the
last
item
on
the
agenda
is
from
the
previous
meeting.
Let's
go
quickly
check
if
there
is
something
that
we
need
to
do,
revisit
the
topic
of
version,
release,
process
and
documentation
in
three
weeks.
A
Number
two
was
put
the
limit
account
non-eip
on
the
next
all
core
dave
agenda:
yeah
it
was
there
and
the
good
thing
is.
The
decision
was
quick.
One
went
into
the
last
call
and
the
other
one
was
withdrawn,
so
that
was
a
good
progress.
There.
C
A
A
C
A
Yeah
so
then,
the
last
decision
here
is
document
in
eip1
and
in
the
eip
template
not
to
have
authors,
put
the
eip
number
in
the
title
that
was
related
to
erc
proposals,
and
the
good
thing
is
yes
that
has
been
updated.
The
eip1
template
readme
file.
All
these
places
have
been
updated
with
that,
and
there
is
another
change
which
we
discussed
in
the
last
meeting.
A
That
was
about
the
description
section.
So
there
is
this
change
in
adding
the
description
and
that
will
be
in
the
template
itself.
Exec
has
made
the
changes
like
on
eip1
and
the
template
itself.
So
that's
another
information
for
people
who
are
looking
into
documenting
proposals
as
a
fresh
like
new
proposals.
F
A
So
I
had
this
one
question
that
I'm
curious
to
understand:
what
do
people
generally
think
about
this
meeting
in
sense
like?
Should
we
continue
it
bi-weekly
and
discuss
these
issues
and
like
even
if
it
is
not
too
full?
It's
fine,
it's
pretty
late.
It's
fine!
We
can
go
early
or
do
we
want
to
have
like
a
list
of
things
to
be
discussed
and
have
one
meeting
once
a
month
that
could
be
like
90
minutes
or
so.
C
Not
as
long
as
people
are
active
in
the
ap
editors
channel,
I'm
totally
fine
with
using
like
discord,
async
communication.
In
fact
I
slightly
prefer
it
they.
The
problem
always
is
getting
people
to
engage.
So
if
people
are
engaging
regularly
in
the
editor's
channel,
then
I'm
totally
fine
with
just
using
that
even
or
just
having
these
just
supplementary
or
once
every
month
or
whatever,.
E
Okay,
yeah,
I
think,
once
a
month
we
can
schedule
that
for
90
minutes
and
worst
case
cut,
it
short.
Does
anyone
disagree
with
that.
C
Is
is
everybody
who
shows
up
these
calls
regularly
in
both
the
cat,
herders
eip
room
and
the
r
d
eaps
room.
C
G
H
H
A
So
yeah
that
was
there
when
we
didn't
have
this
discard
channel
in
place
and
like
ever
since
we
have
this
rnd
discard
that
most
of
the
thing
is
mostly
discussed
in
eip
editing
channel.
However,
we
also
have
a
channel
on
ech
discord
like
eip
editors,
where
we
sometimes
discuss
some
topics
with
like
which
do
not
require
like
bigger
audiences.
So
these
are
the
two
places
where
eip,
editing
or
anything
related
to
eip
is
being
discussed
mostly.
A
So
yeah,
I
think
I
I
mean
I'm
also
fine
either
way.
I
was
also
good
with
like
having
twice
a
month
but
like
30
minutes
and
like
if
it
is
90
minutes
or
like
have
a
bigger
one
is
fine.
I
feel
like.
We
have
made
good
progress
in
like
past
20
months
when
we
started,
we
had
a
lot
of
issues,
a
lot
of
like
challenges
now
that
we
are
getting
clarity
on
that
and
some
of
the
issues
are
even
brought
up
to
the
all
core
dev
meeting.
A
C
A
On
a
similar
note,
I
I'll
be
also
curious
about
understanding
how
much
engineering
work
is
needed
for,
like
you
know,
eip
editing
side.
Do
we
see
good
amount
of
work
that
that
we
have
done
so
far
or
what
is
the
frequency
that
we
could
see.
C
Like
I
could,
I
could
keep
an
engineer
busy
forever.
Basically,
so
I
think
the
bigger
question
is
like
what
is
the
budget.
A
C
I
mean
we
can
take
whatever
help
we
can
get,
I
think
is,
is
valuable.
The
a
slightly
more
interesting
question
might
be,
you
know,
do
we
should
the
ethereum
foundation
or
whoever
is
funding?
This
allocate
resources
to
improving
the
ap
process
versus
other
things
in
the
ecosystem
that
need
help,
and
that's
that's
where
things
become
a
little
more
questionable.
I
do
think
there's
some
high
value
items
in
terms
just
eip
management
that
we
could
benefit
from
and
most
of
those
I
think,
are
already
in
elite
to-do
list
like
for
the
bot.
C
One
thing
to
keep
in
mind
is
that
if
matt
is
successful
in
achieving
his
goals,
we'll,
hopefully
be
kind
of
not
entirely
moving
off
the
eap
system,
but
we'll
be
changing
it
significantly,
like
whatever
our
processes
will
change
significantly,
and
so
we
probably
want
to
be
careful
about
sinking
too
much
engineering
time
into
a
process
that,
hopefully
is
going
away
at
some
point
in
the
future.
I
know
there's
a
lot
of
vagueness
in
those
statements.
A
C
I
do
think
I
do
think
there
is
at
least
value,
regardless
of
what
happens
in
at
least
handling
a
few
of
the
kind
of
top
items
on
elita
spot
improvement
list
things
like
making
it
so
when
an
editor
approves
the
ip
it
will
get
merged
and
making
it.
So
when
an
editor
authors
an
ip,
they
need
another
editor
to
approve
little
things
like
that.
That,
hopefully,
will
be
relatively
small
tasks,
but
pretty
significant
quality
of
life
improvements
for
us.
I
think.
A
C
A
Yeah
right,
ethereum,
slash
eip
dash
part.
I
think
we
can
make
good
use
of
the
issues
section
there
and
like
keep
on
adding.
If
there
is
any
issue-
and
you
know,
people
want
it
to
be
fixed
so
from
this,
is
it
safe
to
assume
that
whatever
time
is
being
allocated
for
engineering
work
like
40
hours
a
month
is
okay,
and
we
can
continue
doing
that
for
another
three
to
six
months
and
if
there
is
no
significant
change.
A
A
A
All
right,
thank
you,
everyone
for
joining
us
today,
I'm
going
to
reschedule
this
meeting
like
on
four
weeks
from
now
and
we'll
update
the
invite
accordingly.