►
From YouTube: EIPIP Meeting 54
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/125
A
Welcome
to
eipip
meeting
54,
I
have
shared
agenda
in
the
chat
for
people
to
refer
to.
The
first
item
that
we
have
for
today
is
co
eips
in
an
executable
spec
world.
So
this
was
proposed
a
few
weeks
ago
by
timbeko.
There
is
a
proposal
and
the
link
is
added
to
the
agenda.
A
A
Hence
I
have
added
it
for
today's
discussion
so
yeah.
If
there
are
any
thoughts.
B
Sure
so
greg
and
I
had
a
discussion
after
I
think
it
was
the
last
eip
ip
meeting
about.
You
know
how
python
fits
into
the
eip
process
and
how
it's
not
really
a
great
fit
for
all
types
of
eips.
B
So
one
thing
we
were
considering-
and
I
don't
want
to
speak
too
much
for
greg
but
is
possibly
allowing
a
diff
against
the
yellow
paper
or
the
python
spec
in
the
eips.
B
That
might
be
one
path
forwards.
I
don't
know
how
anybody
else
feels
about
that,
but
that's
basically
the
only
update.
That's
happened
since
the
last
time
we
spoke
about
this.
A
Right
I
see
there
are
a
few
questions
that
those
are
being
discussed.
One
is
about
the
eip
number.
I
think
there
are
some
certain
suggestions
for
that
and
then
some
improvements
that
could
be
made
with
the
help
of
bot.
So
if
you
can
maybe
summarize
what
is
the
proposal
on
on
like
higher
level
and
the
way
we
are
trying
to
move
forward.
B
Oh
sure
I
mean
at
a
high
level.
I
guess
the
idea
would
be
to
change
the
eip
process
so
that,
instead
of
it
being
an
english
test
text,
description,
you'd,
we
we
would
first
start
by
splitting
the
eip
process
into
two
parts:
core
eips
and
non-core
eips
core
eips
would
live
in
the
execution,
specs
repo.
Well
so
this
this
is
my
proposal.
It's
slightly
different
than
tim's,
but
mostly
the
same.
B
But
in
my
proposal
you
would
split
the
core
eips
and
put
them
into
the
execution
specs
repository
and
then
the
eip
numbering
proposal
I
had.
There
was
basically
that
if
you
have
an
eip
that
spans
multiple,
each
eip
number
would
encode
whether
it's
a
core
eip
or
an
erc
or
a
consensus
layer
eip,
like
so
you'd,
have
some
extra
information
in
the
eip
number
and
then
you
could
use
that
information
to
find
out
where
you
need
to
look
for
the
eip
and
then
the
eips
would
live
either.
B
The
consensus
layer,
specs
repository
the
execution
layer,
specs
repository
or
in
some
erc
specs
repository,
and
the
reason
why
we
want
to
well
I'm
proposing
we
split
it
up
like
that
is
to
keep
the
standards
close
to
the
code
that
defines
them
yeah.
B
C
C
B
B
C
B
All
right
I
mean,
I
guess
the
the
biggest
question
is:
do
we
make
a
diff
to
the
python
spec
a
mandatory
part
of
core
eips,
and
then
everything
else
is
kind
of
secondary
to
that.
C
I
have
no
problem.
I
have
no
problem
with
python
specs.
I
would
like
my
personal
desire
would
be
that
execution,
sex
repo
handles
everything,
and
that
is
both
the
actual
technical
spec
and
the
human
ruble
stuff.
I
liked
the
way
sam
proposed
it
previously,
which
is
just
the
markdown
files
in
there.
A
I
have
one
more
curious
question
here,
so
we
are
talking
about
having
like
execution
specs
for
core
eips
only
so
what
do
you
guys
think
about
having
just
for
core
eips
there
and
for
rest
all
of
the
eips,
including
interface
and
networking
eip
following
the
same
process
as
they
are
doing
right
now,
or
are
we
planning
to
have
networking
and
interface
be
a
part
of
execution
specs.
C
A
I
have
seen
couple
of
interface
proposal,
I
suppose,
for
the
exec
consensus
layer,
specs.
C
This
is
I've.
I've
argued
on
those
issues
I
so
it
is
part
of
the
reason
we
need
to
settle
on.
Something
is
because
the
condensed
player
does
need
a
place
to
do
their.
You
know,
have
their
change
control
process
in
some
way,
and
some
people
want
to
merge
that
with
the
eip
process.
Some
people
want
to
keep
it
separate
and
then
things
get
even
more
complicated
complicated
when
you
have
some
change
set.
C
A
So,
if
I
understand
correct
at
the
moment
for
execution
layer,
specs
interface
proposals
are
already
moved
out
of
the
present
eap
depository.
However,
for
consensus.
C
Yeah
so
other
the
interface
and
theory
includes
other
things,
though
not
much
that
json
rpc
is
the
bulk
of
it.
But
hypothetically
there
are
other
things
that
fall
into
that
category.
A
A
C
I
guess
I
mean
I
don't
so
so.
Yes,
I
mean
that
I
I'm
not
sure
the
eip
process
is
ideal
for
either
of
those.
Just
like
the
execution.
Executable
spec,
I
think,
is
a
better
solution
to
the
problem
of
coming
to
consensus
around
specification.
I
think
the
same
is
true
for
the
networking
stuff.
I
think
the
networking
stuff
would
be
better
off
if
there
was.
You
know
a
canonical
document
that
ideally
was
computer,
readable
similar
to
the
fusion
stack.
C
However,
we
do
not
have
that
today
and
we're
not
there
today,
and
so,
since
the
eap
process
is
basically
the
only
change
control
process
we
have
at
the
moment
everything
is
dumped
into
it,
and
that
includes
networking,
which
I
don't
think
is
good
fit
and
historically
interface,
which
I
also
don't
think
was
a
great
fit
so
yeah
like
it's
one
of
those
things
like
we
have
nothing
better.
It's
not
it's
not
a
great
solution,
but
it's
a
solution
that
exists.
A
C
Process,
yes,
at
the
moment,
we
are
only
working
towards
pulling
out
core
eips
because
with
through
the
execution,
specs
and.
A
All
right:
well,
this
is
good.
At
least
we
are
very
clear
on
this
part
that
we
are
not
going
to
change
the
entire
change
control
process.
The
proposal
is
just
for
limited
to
core
eips.
Only
at
the
moment,
whenever
we
get
chance
to
update
the
networking
and
other
interface,
eips
will
look
into
that.
So
this
is
clear.
This
is
really
good,
and
now
we,
if
we
discussed
about
two
proposals,
I
think
not
two
distinct
proposal,
some
somewhere
overlapping,
so
yeah
in
that
I
mean
like
on
those
two
proposals.
A
I
don't
know,
I'm
not
an
editor,
not
a
nor
in
developer,
but
from
where
I'm
looking
at
it.
It
looks
like
because
we
have
this
yellow
paper
written
only
in
python
spec
right
now
that
is
available
with
us.
It
seems
like
a
fair
compromise
but
yeah,
if
you
guys
have
any
other
thoughts
on
that.
B
D
C
That
is
the
number
of
people
who
can
functionally
read.
The
yellow
paper
is
like
10..
The
number
of
people
who
can
functionally
read
python
is
you
know
millions,
maybe
not
millions.
Hundreds
of
thousands,
this
in
terms
of
notation
and
general
understanding
within
the
developer
community
python
is
just
significantly
higher
than
the
mass
notation
that
the
yellow
paper
uses
like
it's.
Basically,
it's
more
accessible
like
the
python,
is
far
more
accessible
than
mathematics.
C
I
would
be
curious
if
that
is
true.
I
am
not
convinced
like.
If
I
imagine
myself,
rewriting
the
yellow
paper
to
be
more
accessible.
I
would
I
find
myself
ending
a
python
or
something
along
those
lines
like
I
don't
see
a
path,
it
doesn't
take
you
to
just
use
python
or
just
use
typescript
or
whatever.
B
I
I
mean
so,
if
I
were
to
do
it,
you
know
with
infinite
engineering
resources.
I
think
doing
it
in
a
formal
spec
language
would
be
like
ideal
like
something
like
k
or
daphne
or
whatever,
and
that
you
know
you
could
actually
use
that
to
formally
verify
code,
and
that
would
be
the
best
option,
but
no
one
knows
those
languages
and
they're
not
accessible,
so
yeah
right.
So
if.
C
C
I
do
not
think
it
solves
the
accessibility
problem
at
all,
so
yellow
paper
is
either
accessible,
nor
formally
verifiable
and
the
python
spec
is
accessible,
but
not
formally
verifiable,
and
so
I
would
say
that
strictly
better
and
then
there's
a
third
option
which
is
formally
verifiable
but
not
accessible,
and
I
can
see
a
strong
argument
that
that
is
a
path
that
one
would
want
to
take
over
non-verifiable
but
accessible
and
in
a
perfect
theoretical
future,
somewhere
rainbows
unicorns.
We
find
something
that
is
both
accessible
and
formally
verifiable.
B
C
B
C
There
were
two
people
that
you,
let's
say
you
finished
the
actual
spec
and
at
the
same
time,
in
parallel
greg
finished,
the
formerly
verifiable
spec
formally.
C
You
think
so,
okay,
but
I
don't
think
we're
ever
gonna
get
that.
So
if
anyone
out
there
listening
wants
to
devote
a
massive
amount
of
engineering
time
to
write
a
formally
verifiable
specification
for
ethereum,
it's
a
desirable
thing.
Apparently.
B
Yeah
yeah,
and
I
mean
we
have
the
foundations
of
the
evm
and
k
already
somewhere,
so
that
might
be
a
good
place
to
start,
but
there's
a
lot
more
than
that,
but
yeah,
I
don't
think
we're
I'm
sorry,
it's
very
confusing
because
your
zoom
icon
is
pooja's,
zoom
icon
and
I
don't
know
what's
going
on
with
that,
and
it's
funny
really
yeah,
it
doesn't
switch
it
just
he's
pushes
yeah.
So
you
know
if
somebody
wants
to
come
along
and
have
that
ready,
then
I
will
gladly
support
switching
to
it.
B
But
in
the
meantime
the
yellow
paper,
I
think,
is
the
most
useless.
An
idealized
yellow
paper
I'd
be
much
more
supportive
of
using
the
eip
process
and
obviously
I'm
very
supportive
of
using
the
python
spec
in
the
eip
process.
A
So
it
looks
like
we
are
at
a
point
where
we
have
executable
specs
in
python
and
may
be
looking
for
someone
who
can
write
specs
informally,
very,
like
formally
verifiable
specs
can
be
written
with
the
help
of
yellow
paper.
D
C
And
so,
while
I
put
it
out
there,
if
someone
like,
has
a
background
in
this
and
really
wants
to
get
involved
in
ethereum,
this
is
maybe
a
place,
but
this
is
like
a
very
big
death.
This
is
definitely
not
a
small
little
thing
that
hey
we
need
someone
to
help
out
a
little
bit.
This
is
like
we
need
someone
to
dedicate
two
or
three
years
of
their
life
to
build
this
thing.
A
Well,
I
think
this
particular
argument
gives
us
some
flexibility
to
go
ahead
with
whatever
is
available
as
of
now,
because
I
understand
this
execution
table,
spec
is
being
written
for
over
six
months,
and
now
we
are
at
a
place
where
we
are
assuming
that
we
will
be
finishing
up
with
all
the
upgrades
and
we'll
be
reaching
a
point
where
we
can
migrate.
A
It's
unfortunate
that
greg
is
not
here
and
I'm
really
a
little
hesitant
on
like
coming
to
a
a
general
agreement
when
we
know
that
we
have
someone
who
has
a
different
thought.
A
Maybe
we
can
bring
it
up
in
the
next
meeting,
but
from
from
today's
discussion
it
looks
like
moving
in
the
direction
of
python
spec
I
mean
a
diff
to
python.
Spec
is
probably
a
good
approach
at
this
point.
A
Anything
anyone
would
like
to
add
on
or
if
there
is,
I
don't
know
how
do
I
put
it,
like,
maybe
kind
of
call
to
action
that
we
can
do
from
the
community
looking
for
people
who
can
start
working
on
it
or
maybe
voting
kind
of
collecting
some
general
opinion?
What
is
the
preferable?
I
know
we
have
limited
people
on
the
call
and
we
get
to
hear
what
they
think
about,
but
in
general,
if
people
are
looking
for
getting
more
opinions,
we
can
do
that.
The
categories
can
look
into
that
part,
but
yeah.
B
I
mean
all
I
can
say
is
you
know,
I'm
gonna
keep
working
on
the
spec
well,
along
with
the
other
people
who
have
been
volunteering
on
it
and
if
it
becomes
useful
for
the
ap
process,
I
think
we
should
adopt
it,
but.
A
I
think
working
on
this
executable
spec
is
a
very
good
idea,
and
we
should
continue
doing
that.
Thank
you
for
you,
your
team
and
so
many
other
contributors
who
are
working
on
this,
and
maybe
we
can
share
the
recording
of
it
with
some
other
people
and,
if
needed,
collect
some
more
opinion
from
different
editors
and
we'll
also
share
it
with
the
client
teams
if
they
have
any
preferences
and
we'll
try
to
bring
it
up
in
the
next
meeting.
A
Let's
see
if
greg
will
be
able
to
join
in
in
the
next
meeting,
maybe
we
can
have
a
consensus,
then
probably
will
focus
on
which
particular
process
to
be
adopting,
because
I
understand
we
have
almost
two
proposals
here
sounds
good
to
everyone.
A
A
A
I
have
added
the
issue,
so
this
is
collected
from
the
eip
github
repository,
where
we
are
asking
people
to
add
issues
which
can
be
discussed
in
eipip
meeting
brought
in
front
of
eap
editors.
So
sam
has
created
this
issue
and
I
already
see
comments
from
mike
and
sam
going
on,
not
sure
if
there
are
different
opinion.
But
yes,
I'm
if
you
would
like
to
talk
a
bit
more
about
that.
B
Sure,
as
an
eip
editor,
I
find
it
incredibly
annoying
that
the
word
standard
shows
up
in
the
title
of
every
single
standard.
That's
proposed,
so
I'd
like
to
just
add
a
note
that
we
discourage
the
worst
standard
in
eip
titles
and
descriptions.
A
That's
right
yeah,
so
this
is
basically
a
proposal
to
amendment
to
eip1
and
yeah.
This
sounds
like
a
fair
ask:
yeah.
Thank
you,
micah
for
suggesting
solution
here.
A
The
next
item
listed
here
is
eip
bot
issues
and
eipv
issue
updates
and
agreement
on
the
process
to
merge
and
close.
So
now,
ethereum
cathedrals
have
been
looking
into
some
issues
at
eip,
bad
github
repository
and
eipv
repository.
A
We
have
jose
on
the
call
who
has
been
looking
into
these
issues
and
he
has
been
trying
to
close
the
issue,
so
we
are
looking
for
a
proper
process
or
maybe
kind
of
agreement
on.
How
do
we
proceed
in
that
direction?
Earlier?
It
was
alita
and
she
had
the
access
to
maybe
close
and
merge
pull
requests
everything
else,
but
now
it
is
limited.
I
would
pass
it
on
to
jose
for
his
concerns
and
opinion
thoughts,
whatever
he
ever
observed
so
far,.
F
F
F
File-
and
I
haven't
said
that
this
morning-
oh
I
don't
know
this
afternoon
depends
panda
pit
just
comment
that
basically
or
maybe
we
use,
we
just
can
split
this
issue
and
queue,
one
that
includes
the
all
the
actions
already
pretty
much
agree
and
the
other
one
to
open
the
discussion
for
the
pdf
file
great
was
not
liking
the
idea,
but
well.
I
guess
that
if
we
just
create
separate
separate
action,
we
will
be
able
to
talk
about
it
and
to
get
an
agreement
and
the
last
but
not
least,
signs.
The
last
call.
C
I
do
agree
that
it
looks
like
this
enhancements
issue.
Number
55
should
be
split
up
into
multiple,
smaller
issues
that
are
more
targeted,
so
we
can
discuss
them
separately.
B
Yeah,
I
think,
actually
one
per
numbered
item
in
the
comment
that
I
posted
would
probably
be
the
most
appropriate.
C
C
C
B
B
Does
that
work
for
you,
I'm
assuming
jose,
but
I'm
not.
F
Sure,
yeah
yeah
yeah,
that's
fine!
Thank
you.
Please
also
take
a
look
in
the
between
50
a.m
and
53.
They
are
pretty
much
the
same,
so
we
can
just
close
one
and
leave
one
open
as
a
to
take
that
action.
F
D
F
C
D
C
A
So
yeah,
I'm
assuming
like.
C
I'm
just
going
to
use
this
as
a
segue
to
get
into
that's
not
on
the
agenda,
but
before
we
move
into
the
insights
and
differentiation
stuff.
I
am
like
two
weeks
behind
on
eip
editing
I've
got
my
inbox
has
like
200
emails
in
it
that
I
need
to
go
through.
We
could
really
use
a
full-time
editor.
C
Like
matt
has
been
maybe
once
every
couple
of
weeks
and
that's
basically
it
I
think,
and
so,
if
anyone
out
there
wants
to
become
an
eip
editor,
it's
definitely
useful.
I'm
finding
myself
getting
burnt
out
and
so-
and
I
don't
want
to
put
the
eip
editing
situation
back
to
where
it
was
before
I
showed
up,
which
was
that
eaps
would
sit
open
for
like
a
year
with
no
one
touching
them
and
we
had
a
backlog
of
500
or
a
thousand
prs.
D
C
B
Make
a
pr
if,
if
you
want
into
the
eap
one,
I
think
right.
B
Yeah
yeah
that
one
yeah
I
think
daniel
raised
his
hand
too.
E
Yeah
hi
micah
thanks
for
that
call
out,
and
it's
something
that
I'm
thinking
about
I'm
still
very
very
new
and
I'm
something
that
I'm
curious
about
is
the
like.
E
What
is
the
onboarding
process
for
eip
editors,
because
I
see
there's
kind
of
a
note
about
the
responsibilities
of
editors
in
eip1
at
the
bottom,
and
you
know
I've
seen
that
I've
started
coming
to
some
of
these
meetings,
but
I'm
thinking
about
you
know
what
is
the
formal
onboarding
process
like,
because
I
think
that
clarity
will
help
me
figure
out
what
I
need
to
learn
to
get
up
to
speed
and
also
provide
clarity
on
what
it
would
actually
entail.
C
So
it's
a
very
informal
process
basically
show
up
on
eips
and
review
them
for
make
sure
they
follow
the
rules
in
the
ip1
and
follow
the
template.
You
can
see
if
you,
if
you
want
to
go
above
and
beyond,
you
could
go
back
and
look
through
comments
that
I
have
put,
for
example,
on
other
people's
effects
to
get
an
idea
of
the
types
of
things
I
look
for
and
the
types
of
things
that
I
follow,
I'm
same
thing
with
sam
or
light
clients
or
any
other
editors,
just
kind
of.
C
If
you
wanted
to
look
through
see
what
other
people
are
doing,
but
yeah
basically
just
comment
on
people's
pull
requests
and
say:
hey
fix
this
this
this
and
this
these
things
need
to
be
changed
et
cetera,
the
the
job
itself.
C
The
day-to-day
of
the
job
is
basically
just
making
sure
people's
proposals
are.
You
know,
follow
a
general
standardized
format
and
style,
and
so
eips
are
consistent
across
each
other.
The
kind
of
more
philosophical
side
of
it
is-
and
this
is
this
is
maybe
just
me
so
take
this
next
part
of
the
grain
of
salt.
C
Yeah,
that's
true,
so
so
the
the
bare
minimum,
if
you
want
to
be
an
editor,
make
a
pull
request
against
the
boss
file.
That
being
said,
generally,
we
probably
won't
approve
you.
Unless
we've
seen
you
do
some
editing
in
advance
so
step,
one
is
going
to
build
up
a
reputation
within
the
either
community,
which
is
very
small
as
someone
who
is
helpful
and
actually
adds
value
and
then
step
two
is
adding
your
name
to
the
list
and
I'll.
Send
you
a
link,
a
pr
and
add
your
name
to
this.
C
C
As
far
as
like
philosophy,
the
one
thing
that
I'm
a
little
bit
worried
about
and
has
probably
the
number
one
thing
that
has
kept
me
from
stepping
down-
is
that
I
really
want
the
eip
process
to
be
incredibly
neutral,
and
this
is
starting
to
come
up
in
some
of
the
discussions
that
we're
seeing,
but
one
of
the
ways
that
I
worry
and
in
the
past
we
have
lost
this
for
a
period
of
period
of
a
couple
of
years.
C
So
I
want
to
make
sure
that
the
ap
process
remains
as
neutral
as
possible
and
as
open
to
anyone
who
wants
to
contribute
as
possible.
So
that
means
that
someone
comes
in.
They
submit
a
pr
they're
treated
equally,
whether
they're
a
core
dev,
that's
been
around
since
the
beginning
of
ethereum
or
there's
someone
new
into
the
ecosystem
that
just
wants
to
help
contribute,
and
so
that's
the
harder
part
of
the
job
because
it
does
entail.
You
know
telling
some
of
the
old
guard.
No,
you
need
to
follow
the
same
rules
as
everybody.
D
A
A
I
have
shared
the
link
of
a
handbook
that
contains
the
information
that
is
not
available
on
eip1,
but
is
a
kind
of
rough
process
that
is
being
followed
around
eip,
editing
or
documenting
an
eip,
or
even,
if
needed,
for
reviewing
for
the
proposal.
So
you
may
follow
that,
and
there
is
a
section
how
we
can
onboard
an
apprentice
to
be
formally
added.
As
an
eip
editor
there,
you
will
find
the
link
that
micah
has
already
shared
in
the
chat
here.
E
Yeah
appreciate
the
advice
on
on
how
to
get
started
and
kind
of
build
a
trust
in
the
community
and
and
a
profile
of
someone
who,
who
might
be
a
good
editor.
I
see
the
the
the
path
and
and
what
it
entails
more
clearly.
Now
thanks
a
lot.
C
And
to
be
clear,
the
bar
is
really
low
for
building
that
trust
basically
just
show
up
and
be
helpful
and
useful.
You
know
for
a
extended
period
of
time
like
someone
we
want
to
avoid,
as
we've
had
in
the
past,
people
show
up
to
help
out
with
ending
and
they
like
help
out
for
a
week
and
then
they
disappear
in
every
scene
again,
and
so
we
do
want
a
little
bit
of
a
track
record,
just
someone
who
continues
to
show
up
and
doesn't
get
burnt
out
after
a
week.
C
But
beyond
that,
there's
no
really
no
hard
requirements.
It's
just
you
know
if
you're
helpful
and
useful
and
you're
providing
good
feedback,
and
even
you
mistake.
Sometimes
that's
fine,
just
like
as
long
as
you're
showing
you
know,
capacity
to
learn
and
and
whatnot,
the
bar
really
is
pretty
low.
E
Sounds
great
yeah,
I'm
the
the
thing
that
intimidates
me
is
my
technical
capability,
but
it
sounds
like
a
lot
of
the
work
is,
doesn't
even
require
that
much
technical
knowledge.
It's
just
there,
there's
a
lot
of
rules
to
edit
the
ipp
so
that
they're
just
understandable
to
the
community.
C
Yeah,
the
the
technical
knowledge
isn't
it's.
We
generally
want
to
have
someone
on
the
eap
editors
that
is
active
and
has
deep
technical
knowledge,
but
not
everybody
needs
to
have
that.
There
is
significant
value.
Someone
can
add
without
any
technical
knowledge.
Just
like
you
know,
basic
grammar
checking
and
formatting
and
style,
and
you
know
making
sure
the
rules
are
followed.
Things
like
that,
like
things
that
you
really
you
don't
even
like
it's
helpful
to
know
what
ethereum
is,
but
technically
you
don't.
D
C
F
C
C
E
Sounds
great
thanks,
yeah
and
I
appreciate
the
the
encouragement
I
will
give
some
of
this
a
try
hopefully
and
be
be
consistent
about
it.
A
Thanks
to
you,
daniel,
and
thank
you
micah
on
the
same
topic,
I
have
one
question
for
you,
maybe
for
micah
and
other
ap
editors.
I
see
some
of
the
pull
requests
are
open
on
eipv
github,
I'm
wondering
like.
Are
we
waiting
on
something
or
who
needs
to
approve
and
get
it
merged?
C
Oh
so
so
yeah,
so
I
don't
know
who
has
admin
rights?
Is
it
just
ethereum
eipv
right?
I
can
check
to
see
if
I
do.
C
Oh
yeah,
I
appear
to
be
on
some
sort
of
team.
That
being
said,
I
know
nothing
about
rust,
so
I
wouldn't
usefully
be
able
to
merge
anything
or
review
anything.
I
can
click
a
button
to
to
merge,
but
we
should
definitely
have
someone
else
actually
read
code
and
changes.
Not
me.
A
Okay
and
for
the
eip
bot
how
comfortable
you
are
for
merging
pull
request
over
there.
C
Same
thing,
the
one
difference
is
eap
bot
I
actually
see.
I
know
the
language
is
written
in,
but
I
don't
actually
know
anything
about
the
bot
itself.
Ideally
elita
would
approve
and
merge.
I
don't
know
if
she's
still
around,
though,
if
we
don't
have
anybody,
I
can
click
the
button,
but
again
it'd
be
good
to
get
someone
reviewing.
Who
is
actually
understands
it
in
a
perfect
world
for
any
code
base.
C
You
want
at
least
two
people
and
who
get
who
are
both
familiar
with
the
code
base
to
so
that
way,
when
one
person
submits
change,
the
other
person
can
read
it
and
confirm
this
is
valuable.
If
we
don't
have
that,
I
can
click
the
button,
but
I
can't
commit
to
doing
more
than
just
clicking
the
button.
A
No,
I
get
it.
I
was
just
trying
to
figure
out
the
way
how
how
we
can
move
forward
in
absence
of
anyone
being
like
key
person
who
may
or
may
not
be
around.
I
know
alita
is
still
around.
She
sometimes
shows
up
in
one
of
the
meetings,
so
maybe
we
can
take
help
of
her
for
now,
but
I'm
just
trying
to
explore
the
best
way
in
which
we
can
manage
this
without
you
know.
C
Yeah
I
can
handle
these
too.
The
volume
is
small
enough,
but
don't
rely
on
me
for
that
in
the
future.
A
Right,
but
if
okay,
how
do
people
think
about
having
these
issues
and
pull
requests
even
discussed
in
the
eib?
Ip
meeting,
like
you
said
that
number
44
is
waiting
for
general
agreement.
I
don't
know
it's
been
open
since
yeah.
A
A
I
see
a
comment
from
jose.
Sooner
than
later,
bart
would
need
additional
coding
to
be
merged.
That's
right.
We
are
trying
to
figure
out
a
way
how
to
get
these
codes
be
merged.
A
A
There
is
one
small
non-normative
change
to
a
funnel
eip
721
other
than
that
there
is
one
eip
which
is
in
the
last
call,
and
the
last
call
is
ending
on
24th
april.
The
eip
is
eip:
1967
standard
proxy
storage
slots,
so
people,
if
you
are
listening-
and
if
you
have
any
question,
comment-
concern
related
to
this
particular
proposal.
A
Please
reach
out
to
the
authors
or
participate
in
the
discussion
at
discussion
tool
link.
This
proposal
will
be
marked
final
very
soon,
because
its
last
call
is
ending
in
next
four
days
in
this
month
eip
insight,
I
have
added
the
an
additional
chart
to
represent
the
different
categories
of
eips
since
august
2021,
because
that's
when
they
started
collecting
data
individually.
A
So
now
we
can
see
how
many
core
erc
networking
and
interface
eips
are
being
proposed
as
new
eip
and
when
they
are
merged,
I'm
considering
the
data
only
if
it
is
merged,
if
it
is
still
in
the
open,
pull
request,
form
or
the
data
will
not
be
reflected
here.
So
that's
one
new
thing
and
if
people
want
to
have
different
kind
of
data,
if
looking
for
any
other
stats
that
can
be
added,
please
let
us
know
in
either
in
the
agenda
item
comment
or
reach
out
to
me.
A
A
The
last
item
for
discussion
today
is
looking
into
action
items
from
the
previous
meeting.
A
A
A
A
C
A
C
F
F
C
C
C
C
Really,
before
immersion
of
ambiguous
forecast,
I
think
we
already
have
a
issue
out
for
this,
so
that
one
that
doesn't
need
to
be
an
action
item.
It's
basically
just
need
to
wait
for
someone
to
write
the
code
to
do
it.
A
Okay,
maybe
I
will
look
into
it
and
revisit
this
items
next
meeting.
Hopefully
it
will
be
done
closed
by
the
time,
but
yeah
we'll
revisit
it,
and
I
think
that's
all.
That
concludes
the
meeting
for
today.
Anything
else.
Anyone
would
like
to
bring
up
for
today's
discussion.
A
Well,
we
made
quite
good
progress
like,
but
now
we
are
at
some
clarity
with
executable,
specs
and
core
eip
process.
Now
we
are
looking
into
some
general
consensus.
Maybe
we
be
able
to
discuss
it
further
in
the
next
meeting
and
look
into
the
proper
path
for
moving
in
the
direction
of
pulling
out
core
eips
or
leaving
it
in
the
same
repository.
So
maybe
we'll
have
a
decision,
not
decision
general
consensus,
as
I
say
in
the
next
meeting,
so
we
made
quite
a
good
progress
and
yeah.
That's
all.