►
From YouTube: PEEPanEIP#55 - EIP editing with Matt Garnett
Description
Topics covered
-----------------------------
0:55 - About the guest
1:30 - Matt introduction
1:47 - Intro to eip editing
2:20 - What’s an eip editor?
04:08 - Responsibilities of an editor
10:04 - Editing flow
15:25 - Editing checklist
21:18 - Core EIP vs. ERC
24:40 - EIP bot
28:32 - Getting started editing
32:10 - Questions
32:34 - How do you explain to the author about the technical specification and these are the missing list?
36:54 - How do you imagine the CL EIP process after the Merge?
39:27 - Vision of EIP process for EL
42:50 - Comments on GitHub coordination mechanism for EIP
44:45 - What do you think would be the right approach to follow the new proposed process?
46:48 - Why or why not ERCs should be in the current repo?
49:37 - Do you think the number of proposals in ERC category is responsible to move the repos?
51:42 - Thoughts on how to move “apprentice EIP editors” to “EIP editors”
54:20 - What do you think is the best part and the pain point of the present EIP process?
Resources
------------------
Slides - https://docs.google.com/presentation/d/1ACc7LPMjo8KL7EUsEbManM7xi9FbXfjkqrpq_EBLhFU/edit
EIP-1 - https://eips.ethereum.org/EIPS/eip-1
EIP GitHub - https://github.com/ethereum/EIPs
PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Follow at Twitter
-----------------------------------------------
Matt Garnett @lightclients | William Schwab @William94029369 | Pooja Ranjan @poojaranjan19
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/EthCatHerders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herde...
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
A
A
B
Thanks
a
lot
puja
yeah,
it's
pretty
cool
that
was
the
first
guest
on
the
peep
and
eap
series
and
it's
been
awesome,
seeing
lots
of
other
really
great
guests
and
really
get
great
great
sessions
yeah.
So
I
guess
I'll
just
jump
into
it.
The
title
of
this
talk,
I
guess,
is
the
secrets
of
eip
editing.
I
ended
up
making
the
title
of
my
intro
to
eap
editing,
because
I
don't
feel
like
there's
that
many
secrets
to
it.
B
B
So,
I
think
of
eip
editors
as
basically
the
custodians
of
the
standards
repository
of
ethereum
and
so
there's
this
eeps
repository,
and
this
is
where
we
try
and
put
all
the
standards
that
either
go
into
the
ethereum
protocol
or
manage
the
application
layer
interfaces
between
smart
contracts
and
other
different
types
of
eeps.
But
the
editor
is
really
the
people
who
are
trying
to
curate
a
a
consistent,
solid
set
of
eips
that
are,
you
know,
readable
that
you
know
anybody
from
around
the
world.
B
Can
it
can
access
and
and
contribute
to
so
the
current
active
eip
editors?
Are
these
three
profiles?
It's
alex
myself
and
micah
and
there's
a
lot
of
old
eip
editors
who
used
to
be
active
at
one
point
or
another
and
you
know
have
kind
of
like
not
been
active
for
the
last
few
months
or
years,
and
I
think
that
that's
something
that's
important
to
note
is
that
this
isn't
like
something
you
just
sign
up
for
for
life.
B
You
don't
have
to
be
an
eip
editor
and
then
you
know
feel
like
you
can't
step
down
at
any
point.
It's
if
you
have
time
to
contribute
and
and
help
the
ethereum
standards
repository.
Then
your
time
is
like
very
welcome
and
your
contributions
will
be
welcome.
But
it's
you
know
it's
a
cool
thing
to
be
a
part
of,
and
then,
whenever
you
run
out
of
time,
then
it's
totally
okay
to
just
step
down
and
move
on
and
contribute
to
other
places
in
the
ethereum
stack.
B
Eip1
is
kind
of
the
canonical
source
of
all
the
information
about
what
how
the
eip
repositories
govern,
what
eips
should
and
should
not
have,
and
so
it's
important
that
we
as
editors,
enforce
all
of
those
requirements
and
we'll
talk
about
it
a
little
in
a
little
bit.
There
are
some
automated
checks
that
help
us.
B
You
know
avoid
simple
things,
simple
errors
that
happen
frequently,
but
it's
still
at
the
end
of
the
day,
the
editor's
job,
to
ensure
that
you
know
everything
that
needs
to
be
done
in
eip
is
done,
and
so
one
of
these
things-
that's
not
automated
too
much
is
it's
checking
for
spelling
and
grammar
errors.
We
do
have
a
spell
checker,
so
that's
that
is
that's
done
in
the
continuous
integration
suite,
but
checking
for
grammar
reading.
For
clarity.
B
And
one
thing
that
is
to
note
about
like
these
grammar
things,
is
that
we
tend
to
try
and
enforce
that
when
people
are
writing
eeps
that
they
avoid
using.
They
avoid
using
analogies
that
are
culturally
significant.
And
so
it
should
be
in,
like
the
most
plain
english,
something
that
you
know:
people
whose
english
is
their
second
or
third
language.
They
can
still
read
these
things
and
not
have
to
understand
the
you
know
the
analogy
that
may
be
like
mostly
american
or
mostly
british
or
something
so
that's
an
important
role
for
us.
B
We
give
feedback
on
the
content
and
to
improve
the
clarity.
Like
I
said,
and
so
that's
kind
of
like
a
secondary
task
beyond
making
sure
that
all
of
the
requirements
are
met
and
giving
feedback
is
and
important,
we
tend
as
the
people
who
are
reading
all
leaps
to
also
give
feedback
on
the
technical
merit
or
the
usefulness
of
the
eep.
This
isn't
necessarily
something
that
I
feel
falls
directly.
B
Another
important
responsibility
is
just
educating
authors
on
the
eip
process.
Yes,
a
lot
of
these
things
are
documented.
Yes,
there
are
videos
by
puja.
Yes,
there
are
videos
by
me
about
how
the
eip
process
works.
Yes,
there's
lots
of
meetings,
but
at
the
end
of
the
day,
when
people
want
to
make
standards
and
contribute
to
the
eip
process,
they
may
not
seek
out
all
these
resources,
and
so
we
still
as
the
editors
need
to
make
sure
that
the
authors
are
educated
and
we
need
to
let
them
know.
B
B
You
know
kind
of
tangentially
related
responsibility
that
doesn't
really
have
to
do
with
actually
editing
eips
is
just
making
sure
that
the
eap
infrastructure
is
maintained
and
when
I
say
eap
infrastructure,
I
mean
everything
from
like
eaps.ethereum.org,
which
is
kind
of
the
front-facing
interface
for
all
eeps,
and
then
the
continuous
integration
suite
that
we
have
running
in
the
repository.
That's
running
all
of
the
the
syntactic
checks
that
the
eaps
are
correctly
formed
and
there's
no
spelling
errors.
There's
a
there's.
B
You
know
a
reasonable
amount
of
software
engineering,
that's
going
into
making
all
of
the
stuff
run
and,
as
the
custodians
of
the
eep's
repository
it
tends
to
fall
on,
the
editors
is
making
sure
that
stuff
is
maintained.
We've
been
fortunate
that
the
ethereum
cat
herders
have
done
an
amazing
job,
helping
with
that
infrastructure
and
we've
had,
like
you,
know,
external
developers
working
on
improving
the
infrastructure
over
the
last
year.
B
So
that's
been
amazing
but
like
at
the
end
of
the
day,
the
ultimate
custodian
of
the
repositories,
the
editors
and
so
if,
for
some
reason,
these
people
were
to
disappear,
the
editors
will
have
to
step
in
and
make
sure
that
this
stuff
continues
working
that
it's
still
accessible
through
the
ethereum.org
portal
and
lately
it
feels
like
we
do
a
lot
of
interpreting
eap
rules
and
working
to
improve
them.
So
again
the
cat
herders
have
been
hosting
this
bi-weekly.
B
Now
I
think
monthly
call
the
eip
ip
call
to
improve
the
eap
process
and,
as
editors
as
you
know,
act
very
active
participants
in
the
eip
process.
It's
important
that
we
are
engaged
in
those
discussions
and
helping
to
interpret
what
some
things
mean
and
working
to
improve
it.
Based
on,
like
our
experience,
it's
you
know
difficult
to
try
and
improve
these
things.
B
B
So
I'll
talk
a
little
bit
about
the
way
that
I
edit
and
it
changes
depending
on
what
stage
the
ipa
is
in,
and
it
also
depends
on
what
what
the
type
of
epa
is,
but
I'll
talk
about
that
after
this.
So
whenever
an
eep
comes
in
for
its
very
first
review,
this
means
that
it's
initial,
it's
the
initial
pr
it's
trying
to
become
a
draft,
then
what
I'll
do
is
I'll.
Do
a
pretty
thorough
review
I'll
make
sure
that
the
formatting
is
correct.
B
B
The
editors
don't
have
to
review
every
single
edit
that
comes
in,
so
we
as
an
editor
only
see
the
eep
again
whenever
they
try
and
move
the
eep
from
the
draft
stage
to
the
review
stage,
and
so
at
that
point
we
again
need
to
review
some
of
the
formatting.
The
continuous
integration
system
does
verify
that
things
like
the
preamble,
the
eip's
header
is
formatted
correctly,
but
we
need
to
go
in
and
make
sure
that
all
the
sections
are
still
correct.
B
They're,
not
using
a
bunch
of
external
links
and
pictures,
and
we
need
to
make
sure
that
some
of
the
suggestions
that
we
gave
originally
on
the
draft
stage
are,
you
know,
have
been
addressed
and
then
maybe
I'll
give
some
more
editing
suggestions,
things
that
they
should
probably
consider
fixing.
But
maybe
it's
like
less
important
than
it
was
the
feedback
that
I
gave
in
the
draft
stage,
and
so
they
should
consider
fixing
that
before
they
move
it
to
last
goal.
B
Moving
it
to
final
and
once
the
eep
is
final,
there's
no
really
no
going
back
and
changing
anything.
So
we
want
to
make
sure
that,
as
we're
moving
into
this
stage,
that
everything
is
being
addressed
so
we'll
again
we'll
do
a
brief
review
of
formatting
make
sure.
That's
still
all
correct
will
now
start
requiring
that
some
of
the
suggestions
that
we
are
making
for
clarity,
you
know,
are
being
implemented
into
the
eap
and
that
may
become
like
some
sort
of
blocker.
B
And
so
at
this
stage
it's
just
good
to
try
and
make
sure
that
you
know.
Is
everybody
on
board
with
how
this
this
type
of
thing
is
going
and
if
they're
not
on
board,
try
and
reach
some
sort
of
resolution?
Sometimes
it's
not
possible
and
the
authors
may
just
say
like
look,
we
don't
agree,
we're
gonna
go
ahead
and
that's
okay,
but
you
wanna
spend
a
little
bit
of
time
and
make
sure
that
those
things
don't
exist.
B
So
then,
whenever
you've
done,
your
last
call
you've
put
in
when
the
review
period
for
last
call
is
supposed
to
end,
and
that
period
comes
and
goes
at
this
point.
It
should
be
a
relatively
straightforward
pr.
There
really
shouldn't
be
any
changes
to
the
eep
itself.
It
should
just
be
changing
the
status
from
last
call
to
final,
and
so
at
that
point
as
an
editor,
you
would
just
make
sure
that
there
are
no
outstanding
issues
or
if
there
were
they.
B
How
I
would
approach
every
different
heap,
then
you
know
occasionally:
you'll
have
prs
for
eeps
that
are
already
finalized
and
as
a
as
a
finalized
e
we're
we're
not
going
to
allow
any
types
of
changes
that
might
modify
the
meaning
of
the
eep,
but
we
will
accept
errata
errata
changes
that
fix
you
know,
spelling
mistakes,
typos
things
like
this
as
long
as
it
doesn't
affect
the
actual
specification
of
the
eep
in
any
way
anybody
who's
already
implemented.
It
will
have
to
change
nothing.
It's
it's
just
you
know
purely
for
better
understanding
vip.
B
Your
eap
number
is
assigned
to
this.
So
go
ahead
and
update
your
heap
with
that
I'll
review
the
title
and
make
sure
that
it's
clear
I'll
make
sure
that
it
doesn't
have
any
kind
of
formatting
in
it.
There's
no
no
hyperlinks
that
they're
trying
to
put
in
it
clearly
describes
what
what
their
you
know.
Their
eep
is
trying
to
convey
or
standardize
and
then
I'll
make
sure
that
their
description
summarizes.
What
they're
trying
to
do
I'll
make
sure
they
have
a
description
this,
because
this
is
another
field.
B
In
order
with
how
eap
one
defines
the
order
to
be
and
I'll
make
sure
that
there's
no
unknown
eip
sections,
because
there's
pretty
common
for
people
to
not
realize
that
you
know
not
only
do
they
have
to
have
the
required
eip
sections,
they
can't
be
creating
other
top
level.
Eip
sections,
and
by
top
level
I
mean
in
markdown.
You
have
two
pound
signs
to
know
like
one
of
these
top-level
eip
sections,
so
there
should
only
be
the
sections
that
are
defined
in
the
ip1.
B
I
think
a
net
is
okay,
yeah
and
then
another
pretty
common
editing
mistake
that
I
see
is
that
the
eap
formatting
is
incorrect,
and
so
I
think,
last
year
it
was
decided
that
eips
would
be
referred
to
this
format.
Eip
hyphen
the
number-
and
I
often
see
people
putting
eip
space
to
number
eap,
no
space,
the
number
and
so
I'll
go
through
and
I'll
just
make
sure
that
that
that's
correct
and
I'll.
Let
them
know
that's
something
that
they
need
to
update.
B
A
very
contentious
point
of
the
eeps
process.
Lately
has
been
external
links
in
eips.
I
tend
to
try
and
have
you
know
minimal
external
links,
but
I
take
the
stance
of
you
know
not
saying
no
to
every
single
external
link.
I
do
tend
to
be
a
lot
more
lenient
for
erc
types
of
eeps
than
I
do
for
core
eaps,
but
generally
we're
just
looking
for.
Are
they
linking
to
things
externally?
Are
those
things
that
make
sense
to
link
to
if
they
are?
Could
we
just
put
them
as
an
asset
in
the
eeps
repository?
B
Those
are
you
know,
the
considerations
that
I
have
for
external
links.
Then
you
know
we'll
look
at
the
spec
and
we'll
make
sure
that
the
spec
is
straightforward.
You
you
want
to
avoid
embellishing
the
spec
too
much
you
want
to
avoid
writing
motivation.
Rationale
in
spec,
the
spec
should
just
very
clearly
define
what
the
eep
wants
to
standardize,
and
then
we
have
the
other
sections
for
explaining
why
that
makes
sense
or
like
why
the
standard
is
needed,
and
so
the
spec
is
the
wrong
place
to
do
that.
B
So
usually
just
read
through
it
make
sure
that
that's
the
case
I'll
look,
sometimes
I'll
I'll.
Try
and
pull
up
the
eap
and
I'll
actually
load
the
rendered
version
of
it,
rather
than
reviewing
the
the
diff
view-
and
this
helps
me
just
see-
is
there
some
sort
of
weird
markdown
issue
that
I
didn't
notice
by
reviewing
the
eep
itself?
This
happens
a
lot
with
tables
where
the
table
may
look
okay
when
you're
reviewing
it,
but
when
you
actually
pull
up
the
rendered
version,
they
have
done
something
they
have.
B
B
B
Yeah
so
there's
like
on
github
there's
I
mean
I
guess
I
could
just
show
why
not
there's
usually
like
a
little
three
dots
thing
at
the
top
right
of
the
eep,
and
so,
if
you're
looking
at
files
changed,
you
can
click
this
little.
Three
dots
and
click
view
file
and
so
that'll
just
be
pull
up
the
rendered
version
of
the
eep.
And
so
then
you
can
check
to
make
sure
okay
yeah.
This
all
looks
how
it
should
look.
B
You
know,
got
it
cool
thanks,
okay,
so
we
talked
about
that's
the
rough
checklist
that
I
go
through,
and
I
also
want
to
take
a
moment
just
to
talk
about
the
difference
between
how
we
think
about
core
reps
and
how
we
review
ercs.
So
core
eeps
are
eaps
that
actually
modify
the
ethereum
protocol.
They're
things
that
typically
would
need
to
go
through
the
hard
fork
process
that
would
need
to
be
brought
before
all
core
devs
and
need
to
be.
B
You
know
accepted
into
an
upgrade
at
some
point
and
then
there's
the
erc,
which
is
the
eep
type.
That
typically
defines
some
sort
of
smart
contract
interface,
and
I
do
a
lot
of
erc,
editing
and
and
micah,
who
is
probably
the
other
most
active
editor
at
the
moment,
has
decided
not
to
do
any
erc,
editing,
there's
a
there's,
a
lot
of
ercs
and
a
lot
of
them.
Don't
necessarily
need
to
be
ercs
and
it
just
becomes
like
a
really
time-consuming
process
to
review
all
of
these
things.
B
So
I
understand,
and
so
for
that
reason
I
tend
to
be
a
lot
more
lenient
on
what
I
would
accept
for
as
an
erc
versus
a
core
eve,
the
core
eaves
there
tend
to
be
a
little
bit
less
of
them.
They're,
often
like
a
little
bit
more
well
specified
and
there's
like
really
usually
not
a
question
of
whether
a
corey
makes
sense
as
a
need,
because,
if
you're
changing
the
protocol,
you
basically
have
to
have
a
query
for
an
erc
oftentimes.
B
It's
you
know,
there's
different
motivations,
maybe
it's
a
marketing
thing.
Maybe
they
think
it
makes
sense
whatever
I
I
I
don't
have
enough
time
to
try
and
you
know
suss
out
the
actual
reasoning
behind
behind
every
erc.
So
I
just
try
to
treat
them
all
as
like,
with
the
best
intentions
do
what
I
can
to
do
to
review,
but
typically,
when
I'm
reviewing
them,
I'm
a
lot
more
lenient
on
the
actual
structure.
B
As
long
as
it's
like
syntactically
correct
per
eip1,
I
tend
to
just
let
it
go
through
and
if
they
want
to
keep
pursuing
it
to
final
that
tends
to
be.
You
know
where
I
I'll
I
just
let
them
go
through.
I
I
don't
want
to
be
a
gatekeeper
and
keep
people
who
think
that
they
have
important
ercs
they
want
to
push
through.
B
That
said,
there
have
been
like
a
handful
of
ercs
that
I've
basically
had
to
close,
because
after
reviewing
a
handful
of
times
and
trying
to
get
it
to
a
place
where
I
felt
that
it
was
like
at
the
acceptable
level
of
understandability,
we
weren't
necessarily
able
to
get
it
to
that
point,
and
so
they
did
end
up
getting
closed.
But
generally
you
know,
if
you
follow
the
process,
the
ercs
will
will
just
go
to
final,
and
I
mean
I
guess
like
the
same.
Is
that
for
the
corey
ap?
It's
just
that!
B
It's
a
lot
more
rigorous,
we're
really
trying
to
make
sure
that
these
are
very
clear
that
they're
very
well
specified
and
the
ercs
it's.
You
know.
I
don't
review
a
lot
of
the
solidity
on
the
ercs
because
I'm
not
really
facilitating
the
developer.
I'm
just
trying
to
make
sure
that
it's
you
know
something
at
the
high
level.
I
can
understand
roughly
what's
going
on,
and
you
know
hopefully,
as
the
author
they're,
making
sure
that,
because
you
know
they
want
people
to
use
the
standard
that
the
actual
interfaces
are
all
correct
and
everything.
B
B
So
yeah,
that's
kind
of
how
I
view
the
two.
I
think,
as
we
scale
up
more
editors,
we
can
be
a
little
bit
more
rigorous
with
ercs,
and
I
think
you
know
william's
done
a
really
great
job
of
helping
added
some
of
these
ercs,
and
I
can
already
see
that
we're
able
to
try
to
give
more
feedback
now
that
it's
sort
of
disper
their
responsibilities
dispersed
a
little
bit,
but
that's
sort
of
the
current
state
of
affairs
regarding
those
two
okay,
let's
talk
about
our
virtual
eip
helpers.
B
We
have
a
couple
bots
that
help
us
we
have
this
epv.
This
is
a
validating
bot
that
I
wrote.
I
guess
two
years
about
two
years
ago,
mostly
what
this
bot
does
is
it
reads
this
like
preamble
at
the
beginning
of
eip,
and
it
makes
sure
that
syntactically
these
things
are
correct.
Like
there's
the
correct
number
of
spaces,
all
the
correct
sections.
Are
there
the
sections
that
have
like
enum
values
that
it's
one
of
the
expected
values?
It's
not
some
random
made
up
one.
You
know
just
these
kinds
of
like
really
simple
validation
checks.
B
It
doesn't
really
understand
the
semantics
of
the
eep's
repository
like
if
you
move
from
draft
to
rev
to
final
it
wouldn't
sort
of
catch
any
of
that
stuff.
The
eep
bot
has
a
lot
more
semantic
information,
and
so
the
e
bot
is
like
the
actual,
auto
merge
bot,
and
so,
if
eat
v
passes,
then
the
e-bot
will
also
review
the
eep,
and
it
will
do
more
of
these
semantic
checks.
Like
has
an
eap
editor
reviewed
this.
If
it's
something
that
multiple
eap
editors
have
reviewed,
have
they
reviewed
it?
Are
they
going
from
draft
to
review?
B
If
so,
it
must
be
reviewed.
If
it's
just
a
draft
update,
then
they'll
go
ahead
and
merge
it
if
the
person
who's
opening
the
pr
is
an
author
on
deep.
So
it
has
a
lot
more
contextual
information
about
what
is
a
valid
merge
and
what
is
not
a
valid
merge,
and
so
maybe
eventually
we
can
just
combine
these
two.
The
functionality
of
these
two-
it's
just
you
know
like
most
things,
it's
just
the
time
consuming
process
of
taking
the
rules
that
are
written
in
this
rust,
v-bot
and
porting
them
into
this
typescript
bot.
B
But
you
know
one
day:
we
can
have
all
those
things.
So
if
we
look
at
a
pr
a
pull
request
that
you
know
has
the
bots
running
then
you'll
see
that
you
have
these
sort
of
four
actions
that
are
that
are
basically
going
on,
and
so
the
main
three
that
we
care.
The
main
two
that
we
care
about
is
this:
this
is
the
epot.
The
this
auto
merge
bot
and
then
we
have
the
travis
ci.
So
the
trappist
ci
is
running
the
ep
validator
and
then
the
auto
emerge
is
the
github
action
running
epibot.
B
And
so,
if
you
know
we
have
to
have
all
of
these
passing
for
nav
to
be
accepted,
this
epibot
will
always
have
a
red
x.
Even
if
it's
past
all
of
the
the
semantic
checks
that
it's
doing
until
an
editor
comes
and
reviews
it.
If
it's
like
waiting
for
an
editor
request,
so
the
main
things
that
you're
usually
looking
for
is
making
sure
that
travis
ci
is
passing
and
if
travis
ci
has
an
x
here,
you
can
just
click
details
and
pull
up
the
travis,
ci
page
and
sort
of
get
an
idea.
B
There'll
be
some
logs
from
running
the
validation
on
the
eep,
and
you
can
usually
see
like
okay.
This
eep
is
invalid
because
it's
missing
a
title
on
it
or
something
like
that
and
then
or
it
has
a
spelling
error,
so
the
spelling
errors,
the
validation
errors,
those
would
all
come
through
on
travis
and
then
the
merge
bot
is
doing
a
lot
of
those
semantic
checks.
So
once
you
know
all
those
go
green,
then
the
bot
will
just
go
ahead
and
merge
that
eep
into
the
repository,
and
that
kind
of
looks
like
that.
B
So
you
know
you
know
previously.
Maybe
this
this
eep
is
like
ready
to
go.
It's
just
waiting
for
an
editor
to
review.
I
review
something
like
that
and
I
just
approve
it
and
then
the
e-bot
can
go
in
and
auto-merge
it
after
I've
approved.
So
that's
basically
how
the
bots
work,
and
hopefully
I
was
able
to
kind
of
explain
some
of
the
different
things
that
the
epods
are
able
to
check
for
us.
B
The
things
that
the
bots
like
can't
check
for
us
yet
that
would
that
you
know
in
the
future
would
be
great,
is
checking
that
all
the
sections
that
are
there
in
the
markdown
and
that
you
know
there
are
no
unknown
sections.
I
think
that
would
be
a
really
helpful
feature,
because
that's
something
that,
as
an
editor,
I
end
up
spending
a
fair
amount
of
time.
Looking
for,
and
if
that
was
automated,
then
I
could
just
focus
more
on
actually
making
sure
the
eep
is
clear.
B
Okay,
so
that's
roughly
like
the
process
that
I
go
through
whenever
I'm
editing.
I
want
to
just
take
a
quick
second
and
talk
about
how
you
could
get
started
editing
there
is
this
apprenticeship
program
editor
program
that
the
cat
hearders
have
been
running
for
the
last
few
months
and
we
try
and
do
it.
B
I
think
two
times
a
month
every
two
weeks
or
so,
and
this
is
a
great
place
where
we
just
kind
of
sit
down
and
I'll
share
my
screen
and
we'll
just
talk
about
editing,
eeps
and
we'll
just
edit
them
together,
and
this
is
just
a
good
way
to
get
a
feel
of.
Like
what
are
what
am
I
looking
for?
What
kinds
of
changes
are
usually
required
and
it's
just
a
good
way
to
just
start
getting
involved
in
that
process.
B
You
know
I'll.
Let
me
just
tell
you
like
how
how
I
got
involved
in
this
process
step
one
I
write
eip1
and
I
try
to
commit
it
to
memory.
Eip1
is
the
like
ultimate
guide
of
how
to
edit
eips.
It
tells
you
everything
that
you
need
to
know
about
what
a
valid
eep
isn't
and
what
it
you
know
what
you
need
to
do,
to
be
able
to
move
from
stage
to
stage
for
the
process
and
a
lot
of
authors
are
not
reading
this
or
at
least
they're,
not
reading
in
depth.
B
So
if
you
just
go
through
and
read
this
and
understand
this,
you
now
have
a
lot
of
information
that
you
can
share
on
eeps
on,
to
help
the
authors
and
to
help
the
editors
avoid
having
to
say
the
exact
same
things.
So
that
was
the
first
thing
I
was
like.
You
know
I'm
kind
of
interested
in
yeah,
editing,
I'll,
just
go
eat
one
and
then
you
know
maybe
I'll
start
commenting
on
things.
B
So
this
is
like,
I
think,
maybe
one
of
the
first
reviews
that
I
left
for
someone-
and
you
know
I
just
try
and
be
like
very,
very
kind
to
the
person,
because
I'm
not
an
editor,
I'm
just
some
random
person
on
the
internet,
who's
leaving
comments.
But
you
know
because
I
write
eip1.
I
have
some
ideas
that
may
help
you
get
your
eip
merge
faster.
So
maybe
you
should
consider
like
this
review
that
I've
given
and
honestly
most
of
the
time
the
authors
don't
even
know
who
the
editors
are.
B
So
if
you're
just
going
there,
reviewing
them
being
polite
and
giving
good
feedback
they're.
Just
like
that's
an
editor
and
I
think
that's
what
happened
to
me.
People
thought
I
was
an
editor
for
a
while
before
I
actually
was
ever.
You
know
truly
considered
an
editor,
and
so
then
you
know
just
just
do
this
for
a
little
just
for
a
few
months,
just
keep
going
in
and
like
giving
feedback.
Try
to
you
know,
be
part
of
the
process
and
help
people
understand
the
process
better,
who
or
not
is
involved
in
the
community
and
yeah.
B
You
know
another
one
just
you
know
this
looks
good
to
me
and
at
this
time
like
I
don't
have
any
kind
of
you
know
weight
in
and
saying
whether
something
can
be
approved
or
not.
But
I
can
just
say
that
you
know
it
looks
good
to
me
and
then
an
editor
can
come
in
and
say
you
know
what
this
light.
Client
guy
he's
been
reviewing
eeps
for
a
little
bit.
He
said
it
looks
good.
B
I
don't
even
have
to
spend
as
much
time
on
it
now
because
they,
you
know,
I
trust
that
you
know
they
have
reviewed
it
and
that
it
looks.
You
know
it
follows
the
it
does,
follow
the
eip1
requirements
as
expected,
and
so
it's
really
about
just
building
that
trust.
You
know
between
the
editors
and
between
the
the
authors,
you
know
and
that's
just
something
that
you
have
to
do
over
and
over
again
it's
not
something
that
you
review
one
e,
but
now
you're
like
a
trusted
editor
or
something
yeah.
B
That's
pretty
much
all
I
have
for
this
presentation.
I
think
there's
some
questions
that
we
probably
want
to
chat
about,
but
yeah,
I
think
becoming
an
eip.
Editor
is
definitely
not
in
a
possible
task
by
any
means
and
it's
something
that
we
could
really
use.
So,
if
you're
interested
please
check
out
the
ap
apprenticeship,
the
ip
editor
apprenticeship
and
you
know
just
contribute
to
reviewing
eeps
there's,
really
nothing,
no
kind
of
blockers.
It's
fully
permissionless
just
hop
in.
A
A
D
D
Now
I
come,
I
have
a
background
in
iot
for
the
past
four
or
five
years,
and
a
lot
of
the
technical
specifications
mentioned
in
in
that
is
not
very.
How
should
I
put
it
not
very
sound
when
I
try
to
read
it,
because
there
are
a
lot
of
missing
details
or
there's
a
lot
of
just
jargon
being
thrown
inside
the
eip.
B
Yeah,
so
I
mean
this
is
yeah.
This
is
kind
of
I
was
trying
to
allude
to
is,
like
you
know,
whenever
we're
talking
about
this
erc
separating
the
difference
between
making
sure
that
the
eap
follows
the
e
process
that
it's
syntactically
correct,
everything
that
needs
to
be
there
is
there
and
then
there's.
You
know
the
actual
technical
discussion
about
the
eap,
and
you
know
you're,
coming
from
this
place,
where
you
really
understand
that
space
and
you're
reading
the
eep
and
you're,
like
you
know
as
an
as
an
expert
in
the
space.
B
This
is
not
making
sense
to
me,
and
so
it's
yeah
there's
like
this
difficulty
there,
because
you
you
know,
generally,
we
don't
have
enough
time
to
go
through
and
actually
do
very
thorough
review.
With
that
background,
because
you
know
you
may
understand
iot
space
really
well,
but
then
someone
will
come
in
with
like
some
metaverse
thing,
that's
fully
different.
B
So,
as
you
know,
having
a
limited
number
of
editors,
it's
very
difficult
to
give
the
same
kind
of
technical
review,
and
so
it
comes
across
that
there
is
this
eep
that
you
have
good
technical
insight
in
then.
I
think
that
it's
like
you
know
very
welcome
for
you
to
try
and
say,
like
look
hey.
This
is
something
that
I
know,
because
you
know
I've
done
it
in
these
places
or
you
know,
for
whatever
reason
that
you
understand
this
this
topic,
then
you
can
go
into
the
discussions
to
link.
B
That's
where
I
think,
like
most
of
the
technical
discussion
should
happen,
not
necessarily
in
the
pr,
because
the
prs
are
more
ephemeral,
and
so
I
would
hop
into
the
discussions
too
and
say:
hey
like
here
are
my
concerns
about
this
eap.
You
know,
if
you're
an
editor,
you
know
yeah,
I'm
an
editor
and
we're
going
to.
Let
you
like
continue
to
pursue
this
eep,
because
you
know
we're
not
really
trying
to
be
a
some
sort
of
gatekeeper,
but
you
know
these
are
like
really.
B
You
know
concerns
that
I
have
and
that's
typically
they'll
typically
respond
like
if
it's
a
if
it's
an
author
who,
like
really
does
care
about
their
ep,
if
they're
having
like
actual
people,
especially
people
who
understand
what
they're
talking
about
coming
in
and
saying,
there's
issues
there's
usually
going
to
be
some
sort
of
good
dialogue
there.
So
I
think
that's
how
I
would
approach
it.
It's
just
like.
D
C
And
I
guess
the
line
that
the
lines
kind
of
blurry-
and
I
mean
here-
you
have
a
concern
that
does
affect
the
way
that
they
would
write
the
eip,
but
I
think
it
gets
to
a
certain
level
of
foundation.
It
needs
to
go
into
the
discussions,
it's
more
about
the
how
than
the
technical
way
they
wrote
it
yeah.
A
A
So,
first
of
all
I
would
like
to
thank
you
and
the
rest
of
the
eip
editors
for
your
work,
and
the
presentation
has
already
covered
some
of
the
key
queries,
but
I
still
have
a
few
questions
for
you
and
the
first
question
is
about
the
consensus
layer,
eip
process
and
for
future
upgrades
that
we
can
see
after
the
merge.
I
have
seen
your
engagement
with
execution,
client
and
the
eip
process,
which
seems
to
be
working
so
far
for
the
network
upgrade
pretty
well.
A
You
did
talk
about
the
core
aips
that
we
are
using
for
network
upgrade,
but
that's
not
the
case
for
the
beacon
chain.
The
altair
upgrade
did
not
engage
in
the
eip
process,
which
is
similar
to
the
pow
chain.
So
I
would
be
interested
to
learn
about
how
do
you
imagine
the
eap
process
for
the
consensus
layer
chain?
Do
you
imagine
it
to
be
similar
or
different
from
the
execution
layer
after
the
merge.
B
Are
these
black
boxes
more
or
less,
and
then
the
execution
clients
are
these
black
box
functions
more
or
less
and
so
changes
to
either
of
those
typically
are
not
interacting
with
you
know
each
other,
and
so
I
think
that
my
understanding
is
that
we're
going
to
continue
with
the
execution
layer
calls
these
all
core
dev
calls
and
then
we're
going
to
continue
with
these
consensus.
Layer
calls,
and
I
don't
know
which
one
will
be.
B
You
know
if
there
happens
to
be
something
that
needs
to
be
discussed
amongst
all
the
groups,
if
there'll
be
a
new
call
for
that
or
if
that
will
just
continue
being
part
of
like
the
all-core
devs
as
it
you
know,
generally
has
been,
but
I
do
so,
I
think,
like
you
know,
concretely
cancer.
I
think
that
there's
going
to
be
more
formalization
around
consensus
layer
changes
will
they
create
heaps.
I
think
that
they
probably
will
have
to
start
creating
eeps
for
changes
to
the
to
the
consensus
layer
after
the
merge.
B
A
You,
you
are
an
active
proposer
and
champion
for
improvement
proposals.
It
would
be
interesting
to
hear
your
vision
of
eip
process
after
the
merge
and
if
you
could
also
talk
about
little
bit
on
the
sam
wilson's
proposal
that
we
had
a
few
meetings
ago.
Please
share
some
thoughts
about
the
new
erp
process.
B
Yeah,
so
I
think
that
I
haven't
I
so
I
haven't
been
really
involved
in
eth2
now
called
the
consensus
layer.
There
were
periods
of
time
where
I
was
more
more
involved,
the
periods
of
time
I've
been
less
involved,
but
I
think
that
you
know
just
being
a
bit
of
an
outside
observer
to
that
process.
I've
been
really
impressed
with
how
they've
been
able
to
be
spec,
driven
so
from
the
almost
from
the
beginning.
They
had
this
markdown
spec
that
defined
what
the
beacon
chain
is
going
to
look
like
and
over
time.
B
If
we
had
this
canonical
place
for
the
execution
layer
as
well
to
describe
all
of
the
you
know,
the
entire
consensus,
the
state
transition
function
that
exists
in
in
the
execution
clients,
and
so
I
think
that
you
know
this-
may
this
probably
isn't
going
to
happen
with
the
merge
per
se.
But
I
think,
like
going
forward.
That's
something.
B
That's
like
very
much
a
focus
for
the
execution
layer
is
to
try
and
become
a
spectre
event
like
they
are
for
the
consensus
layer,
and
so
I
think
that
if
we
both
become
spec
driven,
that's
going
to
allow
us
just
to
have
more
similar
processes
across
each
other,
because
there
is
these.
These
different
scenarios
right
now,
where
they're
very
like
pr
driven
because
a
pr
is
actually
a
change
to
the
specification
of
their
of
their
their
protocol
and
right
now
we
don't
necessarily
have
that
we're
still
very
eap
driven.
B
I
don't
think
that
means
that
eips
go
away
by
any
means.
I
think
you
know.
Eaps
are
here
to
stay
and
I
think
there's
a
lot
of
important
auxiliary
information
that
getting
coded
into
eaps
that
you
can't
and
shouldn't
encode
into
code,
like
the
motivation
of
why
a
change
should
be
made,
the
rationale
things
to
consider
about
the
security
implications.
Those
are
all
things
that
we
still
need
to
document,
and
so
I
think
those
will
continue
to
be
documented
in
vip.
B
It's
just
that
now
we'll
be
able
to.
Rather
than
defining
the
specification
and
pros
or
really
broken,
you
know,
implementations
that
live
in
the
ap.
We
can
have
this
like
living
piece
of
this
living.
You
know,
project
that
actually
executes
the
evm
executes
the
stage
transition
function,
so
I
think
yeah
it.
You
know
going
forward
in
the
future
that
the
execution
layers
are
going
to
become
more
spec
driven
and
that's
just
going
to
help
unify
the
whole
process
of
making
changes
to
both
layers.
C
Eip
process
like
we're
this
many
years
in,
and
I
kind
of
wonder
if
anybody
else
is
trying
to
using
github
as
this
much
of
a
coordination
mechanism
as
ethereum
is
through
the
eips
right
now.
Do
you
think
that,
like
do
you
think,
that's
always
going
to
be
the
future
of
vips?
Just
like
you
know,
eip
numbering
by
pr
and
github,
like
you
know,
github
kind
of
in
terms
of
bringing
standards
to
if
you're
in.
B
I
think
it's
going
to
be
more
challenging
whenever
we
have
to
create
numbers
for
consensus,
layer
changes
and
it's
not
really
clear
exactly
what
that
process
is
going
to
be.
I
think
it's
not
scalable
to
forever
use
pr
numbers
from
github,
but
you
know
there's
just
no
no
plans
to
to
change
that.
At
this
point,
I
think
until
there's
a
reason
to
change
it,
we'll
keep
it.
As
is.
B
C
Algorithm
in
my
mind,
that
for
like
each
hundred
eips
that
get
added
in
there's
a
disproportionate
number
of
other
prs
that
are
not
new
eips
that
happen
in
the
that
happen
in
the
repo
just
because
of
the
surface
of
different
things
that
they
could
be
happening
on
as
time
increases.
So
there
should
be
less
and
less
keto,
like
sort
of
speak,
eips
per
100
numbers
or
whatever,
as
time
goes
by.
A
Yeah
and
I
have
a
follow
up
on
the
process-
part
that
we
are
discussing
for
the
future
standardization
process.
What
do
you
think
will
be
required
to
like
you
know,
push
this
new
proposed
process
as
a
standard,
because
I
understand
devs
currently
are
really
engaged
with
the
march.
Merge
is
the
priority,
but
at
the
same
time
there
should
be
some
efforts
which
may
be
required
on
educating
authors
and
other
users
that
something
is
changing
and
for
that
agreement
is
also
required.
A
B
It's
not
exactly
clear
about
how
to
make
all
these
things
happen.
There's
a
lot
of
breaking
changes
that
could
happen
if
we
do
it
in
these
different
ways.
The
first
way
that
I
said
where
you
have
you
just
do,
each
of
them
separately,
you
know,
has
the
least
minimal
breaking
changes
of
all.
So
that's
probably
where
the
shelling
point
will
land
on,
but
I
think
we're
still
exploring
exactly
how
to
make
that
happen.
A
A
Esc
is
like
on
a
high
level,
is
a
debatable
topic.
We
have
heard
different
opinions
on
editing
and
management
of
the
improvement
proposals
of
this
particular
category
and
yeah,
but
we
did
talk
about
like
their
suggestion
to
move
this
proposal
out
of
the
present
github
repository
and
have
a
separate
process
defined.
A
B
I
think
that
you
know
I'm
kind
of
a
fan
of
splitting
the
ercs
out
to
their
own
repository,
or
you
know
at
minimum
creating
a
different
different
flows
for
the
two,
because
I
think
that
they're
just
very
different
in
what
they're
actually
providing
who
needs
to
review
them.
What
cons
the
considerations
are-
and
it
to
me
just-
is
a
lot
of
noise
to
have
all
that
happening
in
one
single
repository
there
was
kind
of
for
a
while.
B
So
I
think,
like
right
now
we're
in
this
holding
pattern
where
we're
waiting
to
see
what
happens
with
the
executable
spec
and
whether
people
you
know
how
people
want
to
interact
with
the
executable
spec.
If
we
go
with
this
process,
like
I
just
explained
before,
where
people
are
creating
eeps
in
the
apes
repository
and
they're
creating
pr's
in
the
executable
specs
repository,
it
may
be
that
we
still
want
to
remove
ercs
because
the
ears
you
know
the
eip
repository
will
continue
to
be
just
used
for
core
apes.
B
Mainly
it's
also
possible
that
we
do
this
like
pr.
Only
core
eep
flow.
Where
then,
maybe
we'll
just
give
the
eep's
repository
the
ercs
and
they
can
just
continue
having
full
rain
and
then
we'll
have
the
eeps
in
the
executable
specs.
So
I
think
that's
kind
of
why
there
hasn't
been
a
big
push
to
make
a
lot
of
changes
there.
But
it's
clear
that
the
people
involved
in
the
process
are
not
happy
with
exactly
how
it
is
right
now
and
that
we
think
that
there
are
better
ways
of
doing
it.
A
Do
you
think
the
number
of
proposals
that
are
coming
from
a
application
standard
side
is
responsible
for
this
thought
to
move
the
erc
out
of
the
eip
repository?
Because
I
I
understand
the
networking
and
interface
the
eavs
are
also
standard
track
eips
and
they
also
do
not
follow
the
core
eip
process
like
getting
into
network
upgrade
and
not,
but
they
are
low
in
number.
B
B
This
really
complicated
standardization.
You
know
organization
and
you
know,
put
them
into
their
little
niche
subcategories.
The
problem
is,
is
that
sometimes
there
are
networking
eeps
that
don't
necessarily
fall
under
a
devp
protocol
change
or
sometimes
there's
an
interface
but
doesn't
necessarily
fall
under
yeah.
It
doesn't
necessarily.
B
Interface,
so
you
know,
I
think
that
we
might
have
to
broaden
the
scope
of
what
an
erc
is
beyond
you
know,
just
being
an
inter,
you
know,
interface
for
smart
contracts,
and
maybe
it's
just
a
more
generic
application
level
standard.
That's
something
I
think,
that's
like
pretty
reasonable,
but
yeah.
We
we
just
generally,
don't
think
about
them.
A
Well,
that's
quite
acceptable
because
we
have
very
few
eip
editors
and
the
proposals.
Those
are
coming
up
are
really
big
in
number,
so
whatever
works
for
everyone
is
fair
enough.
My
last
question
is
about
the
eip
editors
apprentice
program
that
the
categories
are
running.
We
have
been
running
this
program
for
over
two
months,
so
I
think
more
than
that-
and
we
have
received
a
good
traction
recently
now
we
can
see
some
comments
coming
from
different
contributors,
which
is
absolutely
great.
A
B
I'm
going
to
give
the
micro
response
of
you
know
as
we
start
to
encode
the
exact
you
know,
criteria
that
makes
someone
move
from
one
stage
to
another.
Then
you
like
create
this
baseline.
It's
very
easy
for
people
to
say
you
know,
I'm
gonna
just
do
those
exact
things
and
then
once
I've
done
them
like
I've
met
that
requirement.
B
So
you
know
we
generally
feel
that
that
person
is
contributing.
For
you
know
this
period
of
time,
and
their
contributions
are,
you
know,
tend
to
be
good.
I
think
this
is
just
like
an
informal
conversation
that
the
editors
need
to
have
and
that
the
eip
meeting
can
also
provoke.
Is
that
you
know
this
person
has
been
doing
this
like?
What
do
you
think
like?
B
A
C
B
B
I
think
the
biggest
pain
points
for
the
ap
process
are
number
one.
I
think
just
the
lack
of
editors,
the
fact
that
eaps
can
sit
there
for
weeks
on
end.
You
know
I've
probably
got
50
notifications
right
now
on
the
repository
that
I
need
to
get
into
and
I'm
gonna
get
into
it.
Probably
you
know
this
weekend
because
it's
been
a
you
know
a
lot
of
other
things
to
do
this
week,
and
so
that's
just
like
not
a
great
ux
for
the
authors
who
are
trying
to
make
their
eeps
happen.
B
So
I
think
that
that's
like
a
pretty
big
pain
point.
I
think
another
pain
point
is
that
you
know
we're
giving
people
eip
numbers
and
we're
creating
this
point
where
they
can
coordinate
against
even
without
becoming
final,
and
that
just
allows
them
to
create
a
draft
with
an
eip
number
and
then
say
this
is
an
eap.
Like
I
said
you
know,
I
saw
gnosis
safe
they're
using
the
what
is
it
the
new
format
for
defining
like
multi-network
addresses,
and
I
don't
know
if
that's
final
yeah
is
that
final.
B
B
Yeah,
I
don't
think
so.
It's
like
they're,
like
yeah,
we
implemented
cdip,
but
if
that
eip
is
in
review
status,
it
could
change,
and
so
you
know,
fortunately,
that's
like
an
application
type
of
thing
and
not
like
a
smart
contract.
They
could
update
to
continue
supporting
it.
But
people
do
this
in
smart
contracts
too,
where
they're
like
this
is
the
nfd
standard
and
the
nft
standard
changes,
and
then
they
don't
support
the
nft
standard
anymore.
So
I
think
that's
a
pretty
big
pain.
Point
yeah.
A
A
Having
said
that,
thanks
once
again,
matt
to
share
the
presentation
and
talk
about
the
eip,
editing,
I'm
positive
that
it
will
help
many
new
contributors
on
this
plot.
A
huge
thank
you
to
our
youtube
viewers
for
watching
tipani
and
a
shout
out
to
one
of
the
youtube
viewers,
julie
alexander,
for
encouraging
comments.
They
find
the
easiest
youtube
to
be
the
most
information
rich
youtube
channel.
Thank
you
for
your
comments
and
we
look
forward
to
sharing
more
informative
episodes
of
people
and
other
resources,
the
research
work
which
is
being
done
by
the
ethereum
developers.
A
So
people,
if
you
haven't,
subscribed
to
the
ethereum
cat,
had
this
youtube
channel
already.
Please
hit
the
subscribe
button
now
check
out
the
description
section
for
guests,
detailed
and
related
resources
for
eip
and
editing
we'll
be
back
with
another
interesting
topic
for
you
till
then
keep
watching
keep
sharing
your
love
with
ethereum
cat
hades.