►
From YouTube: EIPIP meeting 35
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/72
A
A
One
is
the
process
that
I'm
proposing
that
can
be
done
to
improve
the
current
process
and
help
push
most
of
the
ercs,
which
are
still
in
draft
status
to
let
them
go
in
in,
like
whatever
is
the
appropriate
status
for
that
proposal,
and
there
is
an
another
proposal
of
a
magician.
It's
a
rework
of
erc
process
that
that
should
be
something
different
from
eips
yeah.
I'm
happy
to
go
through
my
proposal,
yeah.
A
If
that
helps
so
it
just
suggests
that,
like
whatever
erc
are
in
like
stuck
stage
draft
or
maybe
in
any
other
state
for
over
a
a
long
period
of
time,
maybe
over
three
months,
we
should
reach
out
to
them.
I'm
happy
to
engage
catholics
get
that
work
done.
If
that
is
the
way
we
would
want
to
go
ahead
with
reach
out
to
them
identify
what
is
the
current
center?
A
A
That
is
request
for
comment
and
it
does
not
have
to
follow
the
standard
process.
I'm
not
sure
where
we
can
bring
this
topic
up,
so
I
thought
of
bringing
it
to
eipip
meeting
because
of
two
reasons.
One.
We
have
a
lot
of
editors
here.
Another
is
the
process,
improvement
meetings,
so
I'm
opening
the
floor
for
anyone
to
share
their
thoughts.
B
I
think
light
client
did
a
good
job
of
responding
in
the
thread
that
you
linked
in
the
agenda
about
a
net
wanting
to
change
some
pieces
of
the
erc
process,
and
it
highlighted
some
misconceptions:
people
have
with
the
erc
process,
so
I
think
education
above
all
is
going
to
be
helpful
here.
If
people
want
to
come
in
and
you
know
suggest
changes
to
the
process.
That's
perfectly
that's
great.
I
I
think
it
over
like
a
big
overhaul
like
annette
seem
to
be
indicating,
is
probably
a
bit
too
much.
C
A
D
A
Right
with
the
erc
the
the
challenge,
is
it's
not
core
proposal,
so
it
cannot
go
to
like
all
code
of
meetings
and
all
so
it's
difficult
to
get
the
set
of
people
here
on
one
call
I
mean
at
least
on
this
eipip
call
to
you
know,
make
a
call
like
how
they
would
want
to
see.
I
think
that
thread
is
good.
That
net
has
started
and
we
can
continue
discussing
the
future
process
like
that,
but
I
hope
the
calendars
are
still
good
to
go
ahead
and
look
into
the
older
proposals.
A
C
A
Yeah,
I
think
that
would
also
help
us
clean
a
lot
of
eips.ethereum.org
list,
because
I'm
not
sure
if
we
really
have
over
100
ercs,
active
and
usable,
some
of
them
might
have
been
superseded
or
may
not
have
been
moved
for
a
very
very
long
time,
though.
The
requests
are
closed,
so
we
can
reach
out
to
them.
A
A
A
A
Okay,
moving
on
to
the
next
item
is
updating
eip1,
so
I
have
created
this
pull
request
with
the
very
very
small
changes.
I
think
that
it
has
been
approved,
but
I
still
see
here
as
not
much
so
I
try
to
look
into
it.
My
concern
here
is
like
it
requires
approval
of
two
of
the
authors
mentioned
in
the
proposal.
Eip1.
F
F
Personally,
I
like
to
wait
until
we
like
historically,
my
policy
has
been
create
a
pr
for
eip1,
wait
for
other
editors
to
speak
up.
If
no
one
speaks
up
after
like
a
month,
then
I
just
merge.
It
it'd
be
nice
if
we
could
get
more
interaction
from
more
editors,
but
that
doesn't
always
happen.
So
I
just
wait
a
month
and
if
no
one
says
no,
then
I
go
forward.
F
F
F
E
C
Yeah,
I
think
I
just
don't
want
to
have
failures
as
the
like,
like
common
state
I'd.
Rather
things
be
passing
because
then,
if
we
have
to
force
merge
like,
I,
don't
even
have
access
to
force
merge
if
the
bot
fails,
for
instance,
but
also
it's,
I
would
rather
have
passing
ci
show
on
the
master
branch.
F
Yeah,
so
the
problem
is
that
github,
auto
merge
is
just
when
ci
goes
green,
auto
merge,
so
either
you
fail
ci
or
it
merges
automatically,
and
so
we
don't
want
people
just
be
able
to
submit
pr
to
ip1
and
just
have
it
auto
merge
because
there's
no
checks
against
it.
At
the
same
time,
we
don't
want
it
to
be
blocked
by
this
is
where
they
like.
It
requires
engine
notable
engineering
to
work
around
this
like
it's
not
as
simple
as
just
let
it
go.
F
That
is
on
the
to-do
list
that
that
feature
just
in
general,
so
specifically
for
when
we
transition
between
draft
and
review,
rather
than
just
having
the
author
approve
the
pr,
it
would
take
an
author
plus
an
editor
to
approve
the
pr,
and
that
would
let
it
go
through
a
state
transition.
So
from
like
draft
to
review
review
to
last
call
last
call
to
final.
We
could
have
something
in
theory
similar
free
ip1,
where
we
require
editors
to
approve.
That's
that
is
definitely
much
more
within
the
realm
of
possibility.
F
F
E
C
C
E
I
mean
that's
fine,
I'm
going
to
go
ahead
and
investigate
because
I
don't
know
essentially
like
the
way
that
auto
merge
works
is
you're
given
like
a
list
of
required
checks
that
need
to
pass
and
once
they
pass
it
merges,
and
I
don't
know
if
that
considers
like
if
a
check
was
skipped
right
and
then
in
that
case
it
wouldn't
be
failing,
but
it
still
would
not
emerge.
So
I'm
going
to
look
into
that.
But,
more
importantly,
that
sounds
good
I'll
address
that
problem.
F
Thanks,
I
think,
in
my
opinion,
the
ideal
solution
given
constraints
of
the
tooling
available
is
to
have
four
state
transitions
prs.
It
requires
author
plus
editor
review,
and
so
there
will
be
maybe
two
checks
or
one
check
that
does
both
whatever
and
once
that
happens,
and
it
can
it'll,
auto,
merge
and
then
for
eip1.
I
like
the
idea
of
like
two
of
three
or
two
event
editors
approve,
so
once
you
get
to
editor's
approval
on
the
ip1
change,
then
it
will
merge
automatically
that
way
we
get
what's
likely
once,
which
is.
F
D
F
D
C
Ideal
because
then
you
have
people
like
alex,
barry,
saucy
who
comes
in
and
you
know,
you've
maybe
approved
it.
I
haven't
got
around
to
it
peruvian.
He
reads
it
and
he
says
oh,
this
worked.
This
is
good
and
he
approved
and
then
emerges
and
then
he's
just
sitting
his
computer
like
why
the
hell
did
it,
just
that
that's
weird
and
so
he's
not
sure
what
just
happened,
and
then
I
don't
probably
review
it,
because
I
looked
and
I
see
oh,
that
was
merged.
It's
probably
it's
fine,
so
I
think.
F
C
F
C
E
F
A
A
The
first
statement
of
it
suggests
that
for
corey
ip,
given
that
decline,
implementation
to
be
considered
final
eip
process,
now
that
we
have
separated
eip
process
and
the
network
upgrade
process,
my
understanding
is
here:
we
should
have
the
network
upgrade
process,
because
the
eip
process
that
is
pointed
here
below
is
basically
the
eip
statuses.
These
same
seem
like
a
big
changes
for
me
to
do
it
right
away
in
the
pull
request,
so
I
wanted
to
bring
it
up
in
the
meeting
first
before
I
can
create
full
request
for
that.
A
F
A
Yeah
at
this
point,
I
I
also
figured
like,
while
I
was
going
through
this
document
again
and
again,
I
figured
that
at
many
places,
instead
of
writing
just
eips
we
could
have
just
proposes,
and
that
will
cover
all
it's
not
only
for
core.
It's
not
only
for
this
particular
type.
If
we
address
them
as
proposals
or
improvement
proposals,
that
would
have
helped
a
lot.
A
But
for
this
particular
section
I
think
here
because
this
was
like
you
know
before
they
before
we
had
two
separate
processes.
My
understanding
is
for
under
bracket.
It
should
be
network
upgrade
and
when
we
are
talking
about
the
below
that,
that
is
labeled
as
eip
process
should
be.
Actually
the
eip
statuses
like
right.
Obviously
it
is
the
process.
I.
A
F
A
A
F
A
A
A
Fine
moving
on
the
number
three
item
is
new
eip
editors,
onboarding
funding
and
related
processes.
So,
in
the
last
meeting
we
discussed
about
having
a
couple
of
more
resources
as
like
interns,
or
maybe
apprentice
for
eid
editing,
and
for
that
I
just
have
created
a
small
document.
That
is
a
handbook
for
reference
for
new
people,
like
we
have
seen
people
visiting
us
on
discord
and
other
channels
asking
how
to
support.
A
A
Yeah
I'll
do
that
I'll.
Do
that
and
trent.
I
know
you
are
very
much
familiar
with
the
process
and
everything
else,
but
in
case,
if
you
have
any
question
you
can
refer
to
that
document,
but
yes,
that
is
a
good
way
to
start.
I'm
not
sure
tim.
If
you
have
any
further
question
on
that,
like
you
wanted
to
discuss
something.
A
Okay,
as
far
as
onboarding
is
related,
I
think
the
general
process
here
would
be
like
people
start
looking
into
pull,
requests
and
issues
and
start
adding
comments,
and,
as
we
see
more
comments
getting
in
eventually,
it
will
be
easier
for
them
to
put
them
into
full
time,
not
full
time.
Obviously
like
the
eap
editor,
as
we
have
a
few
people
here,.
A
Moving
on
to
the
next
item,
may
it's
the
progress
on
eip
github,
repo
action,
part
yeah,
so
I
was
curious
to
understand.
Like
I
have
been,
my
understanding
have
been
like.
It
is
almost
done
and
it's
about
to
be
finished,
so
just
wanted
to
make
sure
if
we
are
done
with
the
primary
task
of
like
renaming
the
bot,
the
script
has
been
transferred
to
ethereum
github
repository
and
the
part
is
working
as
functional,
and
can
we
mark
this
task
as
complete.
A
E
Oh,
do
you
mean
like,
like
the
actual
like
repo
bot
yeah?
We
just
decided
not
to
rename
it,
because
I
mean
the
eip
bot
is
like
pretty
self-explanatory
in
terms
of
its
purpose.
I
suppose
it
can
be
renamed.
I'm
not.
I
think
the
I
don't
know
what
the
impetus
was
behind
renaming
it
to
begin
with.
I
think
maybe
that
was
more
more
so
in
reference
to
like
moving
it
from.
E
E
A
So
it's
good
to
say
that
the
new
bot
name
is
eat
dashboard,
correct
yeah,
then
we'll
start
using
that
one
instead
of
eip
bot
good
to
know
okay,
then
I
know
that
you
have
created
a
issue.
Could
you
please
mark
it?
I
don't
know
I.
I
saw
some
last
comments
that
were
a
month
old.
If
you
could
just
answer
to
that
and
close
that
issue
would
be
great,
we'll
mark
that
task
as
completed.
A
A
E
Yeah,
so
the
the
json
rpc
is
admittedly
taking
longer
than
I'd
like
it
is
turning
out
to
be
kind
of
like
get
the
github
actions
a
significantly
more
complicated
procedure
than
you
would.
You
might
expect,
but
we
are
kind
of
like
I
mean
it's
a
plan,
there's
a
vision
for
it
and
I
just
recently
onboarded
jared
who
is
on
the
call
right
now
to
basically
help
with
like
producing
things,
because
I
don't
work
full-time.
E
I
work,
like
I
don't
know
like
12
to
16
hours
a
week
on
all
this,
and
so
it's
hard
to
make
a
lot
of
progress,
but
jared
gonna
be
working
full
time
with
me.
I'm
gonna
be
kind
of
project
managing
him
kind
of
training
him
today
and
tomorrow,
to
sort
of
really
hopefully
ramp
up
production
in
terms
of
getting
these
edge
cases
made
and
everything.
E
I
don't
know
if
anybody
was
aware
of
this
promise,
but
I
did
promise
to
have
the
eip1474
kind
of
converted
to
open
rpcs
to
open
our
pc
such
that
we
no
longer
had
to
rely
on
the
ethereum
classic
open
rpc,
which
that
is
not
done.
That
is
being
delayed
because
because
it's
more
important
that
I
onboard
jared
and
kind
of
get
that
production
rolling
so.
E
G
Yeah,
I
think
the
most
important
thing
right
now
still
is
like
the
the
cco
spec.
I
was
talking
about
that
with
lifetime
this
morning,
so
yeah
that
seems
reasonable.
Yeah.
I
think
all
the
1559
stuff
is
either
done
or
you
know
like
it's
not
blocked
like
there's.
No
like
1559
changes
that
are
that
are
needed.
We
might
decide
to
do
more
in
the
future,
but
I
think
people
will
submit
prs
for
those
so
yeah.
I
don't
think
there's
anything
left
for
for
you
to
handle
there.
C
E
G
Yeah
so
basically,
I
think
life
science-
and
I
were
talking
about
that,
but
it
seems
like
the
eth
one
specs
repo
and
the
json
basically
contains
two
things
right:
there's
json
rpc
and
there's
the
consensus
specs.
It
seems
like
those
two
things
are
very
like
they're,
very
tightly
coupled
right
now
and
there's
not
a
ton
of
reason
to
have
that.
G
G
Yeah,
so
I
oh
yeah,
and
I
guess
another
thing
too:
I
feel
I'm
a
terrible
maintainer
for
the
jason
rpc
stuff.
Like
I
just
have
very
little.
I
guess
hands-on
experience
with
it.
I
think
I'm
okay
to
maintain
like
the
specs
repo
but
yeah.
It
would
be
good
to
also
separate
those
concerns
like
right
now.
You
know
it's
not
the
end
of
the
world,
I'm
I'm
happy
doing
it,
but
I
think
yeah
having
two
different
repos
and
yeah.
G
I
I
don't
know
how
urgent
that
is
like
I
I'm
not
sure
I
it's
not
something
I
would
do
before.
London
hits
my
net
for
sure,
because
we've
been
pointing
everybody
towards
a
single
repo,
but
if
it's
something
everyone
kind
of
agrees
to
then
maybe
right
after
london
is
a
is
a
reasonable
time
to
split
this.
E
G
No,
so
I
would
remove
even
the
json
rpc
spectrum-
that's
repo
basically
like
it
just
feels
to
me
like
the
consensus
spec
so
like
the
actual
core
eips
and
the
hard
forks
are
very
different
from
the
json
rpc
specs
and
that's
what
I
would
want
to
split
so
like
everything,
json,
rpc,
related,
would
go
into
the
separate
repo
and
everything
consensus.
Spec
related
would
stay
would
stay
in
the
ethon
specs
repo.
G
So
if
you
look
in
the
issue
I
shared
you
know,
e2
has
exactly
that,
and
one
thing
this
would
allow
us
also
like
aside
from
just
like
a
better
separation
of
concerns.
It
would
allow
us
to
version
the
json
rpc
spec,
much
easier,
so
mica,
and
that
client
both
had
proposals
where,
like
we
could
have
a
master
branch,
which
is,
you
know
like
the
stable
spec.
G
If
we
also
want
to
do
the
same
thing
with
the
consensus
specs
right
like,
I
think
we
want
to
move
to
a
spot
where
if
we
have
full
consensus
specs
for
each
one,
then
we
can
do
yeah,
then
we
then
we
can.
We
can
do
just
you
know
the
similar
thing
where
we
have
a
branch
for
hard,
forks
and
stuff
like
that.
C
G
I
think
yeah
I
would
slightly
prefer
waiting
until
after
london
just
because
everybody's
we've
been
pointing-
and
we
have
like
a
bunch
of
london
documentation
that
kind
of
points
there.
So
it's
not
the
end
of
the
world,
even
if
it's
marked
as
deprecated,
but
it
feels
like
just
having
one
spot
might
reduce
confusion
for
like
the
next
month
or
so.
C
G
G
C
F
F
G
A
F
F
G
F
It's
kind
of
I
agree.
I
agree
that
that
is
the
worst
spot
is
to
have
half
and
half.
My
concern
is
because
there's
different
people
in
charge
of
each
of
those
places
and
human
coordination
is
hard.
Everybody
is
waiting
for
someone
else
to
like
do
it
all
at
once,
and
no
one
actually
is
in
a
position
to
do
it
all
at
once,
because.
F
G
G
F
G
H
G
F
G
F
G
G
A
F
No,
I
still
need
to
deal
with
that,
so
I
don't
know
who
the
admins
of
the
ap
are,
but
there's
someone
who
is
spamming
it
and
normally
I
report
them
to
github
and
get
to
advance
them.
Unfortunately,
this
person
decide
realized
that
hey.
If
I
just
pay
github
five
dollars,
they
will.
Let
me
spam
infinitely
and
will
never
ban
me.
Can.
G
F
A
G
Yeah,
I
I
I
guess
the
the
short
answer
is
it
depends.
The
long
answer
is,
if
there's
a
specific
ask,
that's
easier
like
so.
You
know
like
making
my
client
an
admin
for
the
and
we
just
lost
I
find
but
making
making
him.
Oh,
he
had
to
hop
making
him
an
admin
for
json
rpc,
like
you
know,
that
was
a
pretty
specific
request
and
I
think
we're
able
to
do
it.
I
managed
to
get
some
guy
admin
for
the
yellow
paper
too.
Who's
done
a
bunch
of
pr's
to
it.
G
So,
like
I
think
in
general,
like
if
there's
a
specific
reason
and
a
specific
history
of
contributing
to
the
thing
you
know
with
high
quality,
it's
it's
it's
fine,
but
there's
no,
there's
no
process.
Unfortunately,
it's
you
know.
I
said
that
to
the
devops
people
and
I
write
the
github
ticket
with
you
know,
good
enough
description
of
why
I
think
it
makes
sense
and
if,
if
people
are
are
content
with
that,
it
tends
to
get
approved.
F
F
G
So
yeah
I'm
happy
to
act
as
a
router.
In
those
cases,
jamie
pitts
is
probably
the
best
person
from
the
ef.
If
you
want
to
go
direct,
but
he
he
does
get
a
lot
of
like
random
inbounds.
So
he
you
know
if
he
doesn't
answer
yeah,
it's
kind
of
my
job
to
answer
to
random
inbound,
so
whereas
his
job
is
to
actually
do
devops
stuff,
so
yeah.
G
A
D
A
A
All
right,
so,
according
to
this,
there
were
a
couple
of
action
items
two
for
me:
creating
the
discord
channel
for
new
eip
editors
and
have
the
conversation
of
onboarding
and
whatever
they
need
to
do
or
direction
they
help
help
they
need
can
be
discussed
over
there.
The
channel
is
created
now
it
is
on
ech
discord,
puja
to
create
an
issue
for
eip
bot
to
get
updated
okay.
So
we
have
this
issue
created
anyone
who
is
willing
to
get
more
engaged
and
help
out
with
the
kind
of
development
of
this
new
bot.
A
This
new
script
is
identified
the
proposals
which
needs
to
go
into
the
right
status.
The
issue
is
available
on
eip
ap
github
repository
a
litter
to
work
with
mica
to
close
eib
development
issue,
and
the
stars
seem
to
be
close
now,
so
we
are
all
good.
That's
all
from
the
I
just
listed
on
the
agenda
today.
Anyone
has
to
bring
up
anything.
H
Yeah
I
just
wanted
to
mention-
I
brought
this
up
maybe
a
month
ago
to
jamie,
but
it
looks
like
it's
come
up
again
in
the
characters
about
people
going
into
getter
and
nobody
is
really
there.
So
I'm
gonna
try
and
get
get
those
deprecated
if
we
can
and
just
direct
people
into
the
ethereum
r
d
discord
instead,
but
it's
cool,
it
looks
like
somebody
is
already
finding
where
they're
linked
in
documentation
right.
Does
anybody
have
any
thoughts
on
this.