►
From YouTube: EIPIP meeting 31
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/65
A
Welcome
to
eipip
meeting
31,
this
is
pujaranjan
and
the
first
item
on
the
agenda
is
splitting
out
eip
reports
into
eips
and
ercs.
A
So
in
the
last
meeting
we
were
discussing
about
how
we
should
focus
on
the
numbering
of
the
eips
and
ercs.
There
were
some
suggestions,
I'm
wondering
if
people
have
further
thought
on
it,
because
earlier
we
were
planning
to
kind
of
create
some
bot
or
something
like
that,
but
it
seems
that
there
is
another
way
of
customizing
the
notification
so
yeah
any
thoughts.
B
Oh
sorry,
I
was
muted.
Can
you
elaborate
on
the
custom
notifications
a
little
bit?
Is
it?
Oh?
Okay,
you
put
a
screenshot
okay.
I
can
read
this
never
mind.
A
So
yeah
the
my
proposal
here
was
like
we
should
keep
the
process.
The
current
process
for
eip
numbering
same
for
the
erc
numbering.
The
only
difference
that
I'm
proposing
here
is
even
if
we
create
a
separate
repository
for
ercs,
the
authors
of
ercs
may
have
to
go
one
additional
step
to
get
the
erc
number
and
that
step
would
be
to
create
an
issue
in
the
current
eip
repository
requesting
for
erc
number
and
whatever
is
the
issue.
Number
will
be
the
erc
number
for
that
proposal.
This
way
we
will
never
have
clash.
A
No
new
process
would
be
needed
for
numbering
eips
and
ercs,
and
we
do
not
have
to
go
back
and
fix
whatever
has
been
done
in
the
past,
for
eips
and
ercs,
and
for
people
who
are
looking
for
only
notification
of
eips,
not
erc's,
they
can
opt
out
for
issues
section,
because
there
are
options.
You
know
we
can
select
what
all
notification
we
want.
A
So
by
manual
you
mean
the
process,
the
current
process
or
yeah.
B
So
how
yeah
like
how
it's
done
today
pretty
much,
and
we
just
do
it
across
both
for
assigning
it
as
far
as
where
to
start
with
the
numbering,
I've
loosened
my
opinion
on
that,
a
little
bit
to
where
I
might
just
defer
to
other
people
how
they
want
to
do
it.
C
So
I
don't
know
what
happens
as
far
as
the
bot
is
concerned,
if
it's
just
like
looking
at
the
files
file
names
on
both
repos
and
like
making
sure
that
there's
no
conflicts
or
anything
like
that's,
not
very
challenging
to
do
so.
D
E
For
manual
processes,
I,
like
puja's
recommendation
of
just
ercs,
will
grab
we'll
go
over
to
the
eip
repo
grab.
A
number
editors
can
do
that
it's
effectively
the
same
as
a
spreadsheet,
but
it
allows
the
ap
process
to
stay
as
it
is,
and
it
means
we
don't
have
to
introduce
another
tool,
such
as
a
shared
spreadsheet,
like
we
just
have
one
tool
and
when
it
comes,
the
next
step,
of
course,
will
be
automating,
and
once
we
do
automate,
then
I'm
totally
down
with
dropping
all
that.
D
Yeah
I
mean
I'm
not
really
opposed
to
doing
that
either,
but
I
would
say,
like
my
only
hesitation
on
it,
is
that
it
doesn't
really
it's
not
going
to
benefit
us
so
much
in
terms
of
notifications.
If
people
still
have
to
open
issues
on
the
eeps
repo
for
ercs,
I
think
it'll
be
better
for
sure.
But
it's
not
you
know
the
full
extent,
whereas
I
I
feel
like
the
spreadsheet
is
very
minimal
overhead.
A
I
guess
a
couple
of
more
questions
that
would
be
you
know
helpful
to
decide
on
this
part
would
be
when
we
are
talking
about
having
a
separate
repository
for
erc.
So
the
number
one
question
will
be
like
who
is
going
to
like
you
know,
create
the
erc
repo
and
where
it
will
be
all
these
things,
and
if
we
can
have
a
poc
for
this
repository
and
then
everything
that
it
can
be
maintained
where
excel
sheet.
That
is
also
a
way.
The
proposal
I
had
for
issue
was
a
temporary
one.
A
A
E
E
It's
up
to
opponents
after
that
to
make
a
change
to
the
process
after
it's
been
started.
I
really.
B
B
A
Because
eip
issues
and
pr
so
they
keep
on
increasing
the
number,
even
if
a
person
create
an
issue
or
a
pr
number
will
be
changed
every
time
for
one
repository,
it's
like
adding.
D
D
E
I
missed
it.
The
issues
that
people
created
in
the
eips
repo
would
just
be
like
a
tight
one-line
title
erc
number
request
and
that's
it
and
then
they
would
immediately
be
closed.
Like
they're.
B
D
B
A
I
think
maybe
hudson,
if
you
can
introduce
them
to
the
editors
here
like
micah
and
light
line,
would
be
helpful
for
future.
You
know
because
this,
the
number
one
road
blocker
here
is
the
erc
repo
and
once
it
is
created,
we
can
actually
like.
A
B
I
can
definitely
make
an
intro
to
the
admins
to
micah
and
like
hi,
just
I'll
get
the
eip
editors
to
intro,
to
the
admins
for
the
ethereum
github.
A
That
would
be
very
helpful.
Thank
you,
okay.
So,
coming
back
to
the
question
now,
assuming
that
we
we
have
this
erc
repo
open
this
week
or
maybe
before
the
next
meeting,
we
can
start
transitioning
stuff
and
to
begin
with,
are
we
fine
with
the
proposed
method
of
just
creating
one
line
issue
on
eips.
B
A
Okay
sounds
good,
that
that
can
be
a
good
start,
and
how
do
we
want
to
share
this
information?
That's
announcing
it
on
the
all
core,
dev
meeting
make
sense,
or
do
we
want
some
kind
of
blog
or
how
do
we
want
to
let
people
who
are
not
directly
related
to
core
proposals?
Obviously
they
are
preparing
an
erc
so
not
related
to
court
proposals.
How
how
would
they
get
to
know
about
it
do
do
we
have
any
thoughts.
B
These
things
micah,
you
cut
out
for
me.
So
can
you
repeat
that
whole
thing
again.
E
Sure,
sorry
about
that,
I
would
say
the
all-core
devs
call
is
the
wrong
place,
because
no
one
like
we're
taking
away
the
thing
that
people
on
that
call,
presumably
don't
care
about,
and
so
telling
them
we're
taking
away.
This
thing
you
don't
care
about
is
something
they
probably
also
don't
care
about.
D
Okay,
we
can
hear
you
now,
so
what
I'm
saying
is
I
hear
that
there
is
an
all
core
devs
call
coming.
D
But
it's
you
know
it's
tough,
because
it's
not
sure
when
that's
happening,
and
you
know
there
are
a
lot
of
developers
who
probably
don't
go
to
that
stuff
anyways.
So
I'm
guessing
that
we
try
and
push
out
through
some
public
channels,
and
we
just
have
to
tell
people
who
open
ercs
that
they
have
to
do
on
this
other
repo.
A
Okay,
any
more
thing
on
this
topic.
F
Yeah
that
we
all,
we
still
have
to
worry
about
what
to
do
with
eips.ethereum.org,
because
there's
the
erc
tab
on
that,
and
so
it
sounds
like
there's
probably
going
to
be.
Some
programming
need
to
be.
Do
we
still
want
the
erc
tab
to
point
to
the
eips
over
in
this
new
repository,
which
of
course
will
take
some
new
jekyll
programs.
F
So
we
would
still
have
the
erc
tab
in
eips.ethereum.org,
but
we
just
need
to
find
someone
to
do
the
additional
programming
to
somehow
merge
that
or
something
like
that.
But
yeah
yeah
we're
working
on
we're,
trying
to
get
that
set
up
and
working
on
our
system
and
we
might
be
able
to
find
some
bandwidth
to
do
some
development
along
those
lines.
But
I
can't
guarantee
that
yet.
A
I
think
that
is
next
question
that
we
would
be
looking
for
to
be
answered,
but
for
now,
let's
start
with
this
github
repository
and
once
that
is
active
and
functional,
and
if
we
see
that
that
eips.ethereum.org
is
not
being
updated
with
the
new
erc's,
probably
then
we
have
to
reach
out
to
somebody
to
fix
the
bot
or,
however,
it
is
added
there.
F
Sounds
good
yeah
we're
work
like
I
said,
we're
still
working
on
getting
that
set
up
and
learning
how
to
deal
with
all
that
and
I'm
trying
to
get
in
and
learn
the
programming
and
stuff
like
that.
We
might
be
able
to
get
to
a
point
where
we
can
help
with
some
of
that,
I'm
kind
of
hoping
with
that.
But
right
now
I
have
been
able
to
spend
a
lot
of
time
on
that.
But
what
go
ahead?
F
What
bot
are
you
working
on
the
check
if
you
go
to
eips.ethereum.org,
there's,
there's
a
pretty
printed,
there's
a
jekyll
script
that
goes
out
to
the
repository
and
makes
a
pretty
printed
version
of
all
the
eips,
and
you
have
tabs
where
you
can
see
all
of
them,
the
core
ones,
the
networking
one,
the
erc
ones,
and
it
displays
those
in
a
kind
of
a
pretty
printed
format,
and
so
it's
the
jekyll
script.
That
runs
all.
That
is
my
understanding.
F
E
D
D
E
Editing
the
template,
file
and
eips
repo-
I
don't
know
exactly
where
it's
at.
F
A
Sounds
good,
thank
you
for
that.
So
is
there
anything
else,
people
would
like
to
bring
up
or
we
can
move
on
to
the
next
one.
E
I
think
I'm
gonna
paste
in
the
zoom
chat
here
if
you
brand,
if
you
look
at
that,
those
two
lines,
I
think,
are
the
ones
you
want
to
edit
to
make
that
point
somewhere
else.
I
believe.
A
Okay,
so
the
next
item
on
the
agenda
is
progress
on
json
rpc,
api
spec
in
eth1
dot
or
repository
recently.
I
I
saw
some
issues
and
peers
coming
from
melitta.
If
you
have
any
update
on
that
or
you
if
you
would
like
to
talk
about
it.
C
Sure
so
it's
actually
still
not
perfectly
clear
if
I'm
gonna
be
working
on
that
I'm
kind
of
not
super
experienced.
So
like
I
don't
know,
I
mean
I'm
making
progress
for
sure,
but
I
think
tom
thomas
hasn't
decided
fully.
Yet
if
I
will
be
working
on
that
completely
but
anyways,
I'm
working
on
eth
call
right
now
and
I
submitted
the
eth
block
number
spec
and
then
so
essentially
like
I.
C
I
expect
to
have
eth
call
at
least
the
first
iteration
of
it
out
this
week
and
then,
hopefully,
things
will
ramp
up
from
there,
because
I've
been
kind
of
spending.
The
past
week
like
getting
acquainted
with
all
the
technologies
and
getting
my
json
rpc
like
system
setup,
but
anyway.
A
Right
so
I
had
a
word
with
mass
in
between
and
between
these
two
meetings,
and
I
proposed
like
having
an
issue
to
create
a
list
of
what
is
needed
actually
and
the
task
and
the
bounty
etc.
If,
if
that
can
be
done,
that
would
be
helpful.
I
think,
from
the
tracking
purpose,
if,
if
we
want
to
like
the
cat,
editors
want
to
be
involved
with
this
specification
being
added
to
each
one.or
spec
repo.
A
A
C
Yeah
I
gave
a
a
bit
of
an
update
on
my
progress
with
each
call
and
on
the
block
number,
as
well
as
just
kind
of
referencing.
The
fact
that,
like
it's,
not
super
clear
if
I'll
be
moving
forward
with
it
yet
so
I
intend
on
having
each
call
specification
ready
this
week
and
then
hopefully
we'll
have
a
better
idea
of
my
involvement
in
the
future.
From
there.
H
H
So
if
we
have
the
full
spec
for
if
call
and
we
analyzing
there
are
lots
of
edge
cases,
so
I
think
I
have
a
few
example,
maybe
like
10,
maybe
15,
and
we
need
to
find
the
clarity
around
them
because
not
not
all
of
them
were
immediately
obvious
and
then,
when
this,
if
call
is
finished,
then
we
make
decisions.
Probably
on
the
this.
H
This
will
give
us
a
good
estimate
of
the
amount
of
effort
for
every
of
those
specifications,
because
I
think
I
underestimated
them
a
bit
before
and
and
then
I
I
think
that
was
suggested
by
puja
to
actually
make
it
a
bit
more
open
after
that.
So
just
post
it
as
the
as
some
kind
of
git,
git
bounty,
git
coin
bounty
with
the
details
and
and
then
I
guess,
elita
will
be
already
in
the
place
to
to
be
the
best
person
to
follow
up.
But
we
also
make
this
part
much
more
open.
H
So
if
other
people
want
to
participate
either
as
as
more
of
people
to
make
it
move
faster
or
just
to
like
compete
for
the
spot,
then
it
might
be
the
way
to
go,
but
so
far
I
think
aletta
is
doing
a
a
great
job,
approaching
it
very
technically
and
analyzing
it
in
detail.
So
we
have
lots
of
setup.
If
I
can
get
running
the
all,
the
ether
is
web,
free
and
so
on,
and
we
we
see
now
how
much
work
it
is.
A
H
So
my
feel
is
that
after
friday,
so
elite
already
opened
a
special
json,
rpc
discord
channel,
that's
been
quite
active
there
and
I
think
there's
mike
there's
eric
and
there
are
a
few
other
people
and
then
the
reviewers
should
be
probably
from
client
team
developers
and
for
now
I
can
give
this
early
feedback.
I
don't
want
to
involve
too
many
people,
because
it's
still
a
bit
rough.
It
would
be
too
early
to
just
use
everyone's
time.
H
H
A
Yeah
merging
should
not
be
a
problem,
but
as
for
my
understanding,
we
may
not
be
technical
enough
to
understand
that
it
is
done
or
not.
So
we,
the
decision,
could
be
made
based
on
the
comments
provided
on
the
pull
request.
That
would
be
super
helpful.
If
there
is
some,
if
something
is
ready
to
be
merged,
just
a
liner
mentioning
there,
it
is
ready
and
it
has
been
reviewed
and
something
else
that
that
will
be
helpful.
H
That
was
the
plan
to
do
almost
something
like
checkboxes
for
the
client
developers
so
see.
If
they
can
comment
and
mark
the
checkboxes,
as
this
client
confirms,
I
don't
think
they
need
to
participate
in
the
actual
formal
code
review
process
or
maybe
like
we'll
see
after
this
is
finished,
which
one
will
be
more
efficient
because
for
code
review,
I'm
not
sure
if
you
can
have
external
people
to
do.
The
code
review
like
outside
of
the
repository.
A
Yeah
sounds
good,
so
I
think
I'm
good,
and
I
have
answers
to
many
questions
that
I
was
looking
for
I'll
try
to
get
in
touch
with
lita
and
you
too,
to
if,
if
I
come
across
any
more
questions,
but
do
people
have
anything
else
that
you
would
want
to
mention
on
this
topic.
A
I
think
I
have
one
last
question
that
may
not
be
directly
related
to
the
task
that
we
are
doing
here
for
this
about
the
the
information
sharing.
Are
we
planning
to
share
it
with
their
discord
group
or
mentioning
it
in
the
algorithm
meeting
that
people
looking
for
the
spec
they
can
visit
this
repository?
How
do
you
plan
to
let
community
know
about
this
placeholder,
the
new
placeholder.
H
I
think
we'll
be
on
the
all
core
devs
channel
when
we
have
the
first
full
specs
and
anything
that
is
in
progress.
This
will
be
on
the
on
the
special
channels
that
delete
us
set
up.
This
should
work
and
I
don't
think
we
need
to
raise
it
on
the
call.
H
Maybe
after
a
few
of
those,
we
can
once
mention
it
in
the
all
car
deaths
call
to
just
reach
out
to
wider
community
audience,
because
that's
what
people
may
be
listening
to,
but
I
think
just
the
mailing
list
from
the
series
of
oasis
calls
that
we
were
organizing
would
be
enough
to
to
start
a
bit
more
cooperation
on
this.
A
Moving
on
the
next
item
on
the
agenda
is
progress
on
eip
github
repo
action
part.
There
is
an
issue
added.
A
In
the
item
itself,
so
I
was
wondering
on
the
status
of
the
first
set
of
tasks
like
I
see.
The
last
comment
is
five
days
ago.
So
was
wondering
if
it
is
completed
or
can
be
closed
or
what
is
the
status
on
it.
C
Very
tedious,
but
we
are
we're
making
progress,
I
would
say
almost
like
the
major
problems
are
almost
fixed,
so
I
don't
know
I
would
say
this
week,
it'll
be
done
depending
on
micah's,
like
ability
or
availability
to
review,
but
generally
speaking,
it's
kind
of
one
would
look
after
the
next,
so
we're
kind
of
tweaking
it
as
we
go
so
but
we're
almost
there.
You
can
feel
it.
E
As
with
all
engineering
projects,
it
went
far
less
smoothly
than
expected.
E
Yeah,
there's
just
one
thing
after
another
that
I
didn't
think
about,
and
we
originally
talked
about
this.
Like
things
get,
how
cannot
do
things?
I
should
have
realized
that
I
can't
do
but
thought
it
could
for
some
reason
so
hacks
and
hacks
and
hacks,
and
it's
starting
to
get
close
to
functional.
C
The
hats,
though,
thankfully,
are
like
somewhat
dependable-
I
mean
they're,
they
are
hats,
they're,
not
terrible
they're.
Not,
I
would
say
it's
a
lot
better
than
the
the
bot
that
exists
right
now
as
far
as
hacks
are
concerned.
So,
generally
speaking,
the
final
result,
I
strongly
believe,
is
going
to
be
much
more
reliable
and
much
more
readable.
So.
A
Good
to
know
that
so
yeah
I
mean
like
from
management
point
of
view,
so
I'm
always
keen
to
see
all
the
issues
getting
closed
and
the
work
is
done
because
we
have
to
provide
status
so
as
and
when
you
feel
that
this
is
done,
and
this
can
be
marked
clues.
That
would
be
great.
I
hope,
to
see
that
coming
soon.
B
Yeah,
just
continuous
shout
outs
to
mike
and
aleta
for
doing
that.
A
Yeah,
I
do
that
I
mean
yeah.
This
is
a
great
work.
I
have
seen
the
numbers
of
open
pull,
requests
and
issue
in
the
eips
github
repository
then,
and
now
shout
out
to
elite
and
mica
and
like
client
for
closing
them
all
together.
C
A
Cool
moving
on
the
next
item
on
the
agenda
is
progress
on
canonical
source
for
eips.
F
Yeah
we
we're
still
working
on
that
we're
having
troubles
getting
carving
out
time
to
get
a
lot
done,
but-
and
I
think
we've
already
talked
about
this-
pretty
much
we're
hoping
once
we
learn
the
system
we'll
have
some
results
to
show,
but
it's
not
not
much
yet
so
just
progress
is
slow,
but
we
are
making
progress.
A
So
now
yeah
great,
we
are
almost
on
the
last
item
of
the
agenda.
That's
a
review
from
the
previous
meeting
action
items,
30.1,
split
eip
and
erc
0s.
A
I
think
we
made
good
progress
on
that
will
will
soon
see
the
erc
repo
and
then
I
think
we
can
start
with
the
process
of
having
new
erc
is
in
this
new
repository
number
two
json
rpc
spec
shall
be
documented
under
eat.
One
or
spec
json
rpc
alita
is
already
working
on
it.
Thanks.
So
much
for
providing
update,
number
three
remove
testing
green
light
from
eip
process
yeah.
We
have
updated
it
in
the
e100
spec
repository
as
well
as
the
ethereum
ethereum
cathedral's,
medium
blog.
The
new
process
has
been
updated.
A
A
30.2
spread
the
word
and
find
an
entry-level
resource
to
contribute
to
json
rbc.
I'm
sure
we
have
a
plan
for
that.
The
mass
briefly
mentioned
mentioned
about
bounty
and
talking
about
more
tasks.
A
Thirty
point
three
tembico
will
bring
up
the
agreed
changes
to
eip
process
in
the
all
core
dem
meetings.
Unfortunately,
we
did
not
get
chance
to
mention
about
it.
Let's
see,
maybe
in
the
next
meeting,
we'll
try
to
mention
about
this
minor
change
of
the
process
in
the
upgrade
process.
A
A
I
had
one
thing
in
mind:
I
am
I'm
wanting
to
bring
it
up.
I
don't
know
if
this
is
the
right
place,
but
again
we
we
are
considering
to
get
eip
editors
and
erc
editors
funded.
So
I'm
I'm
curious
to
know
on
two
parts
like
commitments
and
maybe
if,
if
there
is
anything
in
anyone's,
can
suggest
on
what
could
be
the
you
know
dollars
per
hour
or
something
like
that.
That
would
be
super
helpful
for
us
to
reach
out
to
maybe
dow
or
places
from
where
we
can
get
funding.
It's
fine.
B
Yeah,
estimating
for
how
much
something
should
be
worth
is
difficult,
but
this
is
a
niche
skill
set,
so
yeah
it'll
also
depend
on
how
much
funding
we
get
to
do.
That
will
be,
but
at
least
if
we
get
a
number
from
some
people,
I
think
that
would
be
very
helpful
to
get
a
number
and
have
some
kind
of
estimate
for
at
least
the
average
or
high
end
even.
A
Right
so
the
blog
that
that
was
published
initially,
where
we
were
kind
of
trying
to
list
out
how
how
much
effort
would
be
needed.
According
to
that
blog,
it
says
that
zero
to
five
hours
per
week,
but
I
don't
know
if
we
are
considering
for
an
individual,
let's
say
15
hours
per
month
or
something
like
that.
But
I
don't
know
I'm
not
one
of
the
editors
so
having
some
word
from
editors
would
be
great.
E
B
Oh,
I
think
I
think
I
hear
static
from
pooja.
I
don't
know
if
they're
talking,
but
we
were
asking
about
any
estimate
for
hourly
pay
rate
for
an
eip
or
erc
editor,
so
that
once
we
do
get
funding
because
we're
in
the
process
of
looking
for
funding,
we
can
have
better
estimates.
E
Oh
like
what
what
is
a
reasonable
pay
to
attract
the
appropriate
person
for
this
type
of
work,
yeah
for
a
part-time
position
to
start,
at
least?
E
Sure
so,
the
in
that
case
you
can
set
a
like
having
hired
hired
internationally
passed.
What
happens
is
like
the
rate
you
set
will
determine
where
you
get
candidates
from
if
you
set
a
rate
that
you,
for
example,
is
below
what
u.s
people
want,
then
you're
going
to
get
candidates
from
ukraine
and
philippines
and
indonesia
and
india,
whereas
you
set
a
very
high
rate,
you
get
candidates
from
everywhere.
That's
why
I
asked
like
what
kind
of
where
your
target
demographic
is.
E
Do
you
want
to
attract
people
from
everywhere,
or
you
just
want
to
attract
people
from
like
the
less
expensive
locations.
B
I
think
we
just
want
to
know
data
for
both
so
that
when
we
know
how
much
money
we
get
from,
whoever
gives
us
money
for
this
stuff,
then
we
will
be
able
to
apply
that
and
then
make
decisions
based
on
that.
E
E
Full-Time
would
be
measured
in
hundreds
of
thousands
of
dollars
a
year,
whereas,
if
you're
looking
for
someone
who
just
knows
how
to
do
editorial
work,.
B
E
So
the
if
you're
looking
for
someone
who
is
just
doing
more
editorial
work-
and
it's
like
making
sure
the
formatting
is
good
making
sure
like
the
grammar
and
the
spelling
is
good
making
sure
the
wording
is
okay,
but
they
don't
necessarily
understand
the
content.
Then
that
will
be.
You
know,
notably
cheaper,
because
you're
pulling
it
pulling
from
a
very
different
pool
of
people,
but
of
course,
you're
gonna
get
very
different
level
of
editorial
feedback.
So,
instead
of
getting
feedback
on
you
know
here
are
some
things
you
can
improve.
E
B
G
A
So
at
the
moment
we
have
very
few
active
editors,
so
that
is
one,
but
now
we
are
planning
to
have
an
additional
repository
erc.
So
mostly
we
would
be
looking
for
erc
editors
as
well
right,
so
the
immediate,
if
we
say
that
the
requirement
would
be
for
erc
editor,
but
obviously
the
present
editors
we
are
planning
to.
It
cannot
be
a
decent
salary,
as
I
see
it,
but
obviously
it's
kind
of
a
stipend
may
not
be
a
good
word
yeah,
but
yeah.
A
I
mean
like
at
least
something
for
the
the
work
that
they
are
doing
here.
Obviously
this
is
a
very,
very
high
high
end
job
and
very
important
for
the
ethereum
chain,
so
yeah.
B
I
think
it
should
be
both,
I
think,
to
answer
your
question:
trent,
the
current
editor
should
get
paid,
and
so
should
the
new
ones.
G
Yeah
definitely
every
everyone
everyone
should
everyone
should
be
paid.
I
just
wasn't
sure
what
the
intent
was
like
to
attract
new
ones
or
just
pay,
the
ones
who
are
doing
existing
work.
I
mean
who
else
is
doing
this
besides
micah
a
light?
Client,
okay?
Well,
maybe
they
offline.
They
should
prepare
like
what
they
think
would
be
a
fair
hourly
rate,
but
I
mean
I
know
I
think
I
was
gonna
say
lifeline.
D
Yeah
I
mean,
I
think,
that
it's,
I
definitely
consider
it
part
of
my
primary
job
already,
and
you
know
a
little
bit
of
money
is
always
great,
but
I
don't
really
think
that
you
know
receiving
funding
for
me
is
going
to
change
the
amount
of
time
or
effort
like
I
put
into
each
repository
just
because
there's
a
lot
of
other
important
projects
that
I'm
trying
to
help
with-
and
this
is
all
this
is
very
important.
But
you
know
what
I'm
contributing
right
now
is
like.
D
Usually
the
max
like
what
I'm
able
to
contribute
and,
I
would
venture
to
say
that's
probably
similar
for
other
educators.
It's
not
really
an
issue
of
funding,
it's
an
issue
of
time,
and
so
you
know.
I
definitely
think
that
there
is
the
desire
to
have
some
people
who
maybe
aren't
don't
have
as
much
understanding
of
the
protocol,
but
can't
do
the
editorial
tasks,
and
I
don't
know
if
that's
a
different
title
or
like
how
that
specifically
works.
B
D
And
I
to
me
I
see
that's
kind
of
like
you
know,
there's
the
editorial
task,
which
is
just
you
know,
purely
editing
the
standards,
but
there's
also
this
committee
task,
and
you
know
if
we
just
want
people
editing
the
standards.
I
don't
think
that
it's
important
to
have
like
really
deep
protocol
knowledge,
but
in
terms
of
like
leading
a
committee
and
helping
shape
proposals,
but
I
think
maybe
that's
just
different.
D
Yeah,
well
I
mean,
I
think,
there's
a
you
know,
a
handful
of
editors,
you
know,
micah
is
very
active.
I'm
somewhat
active,
alex
barrett's
aussie
is
occasionally
active,
so
there's
definitely
people
there
who
can
help
out
in
those
instances,
but
I
think,
like
the
work
is
just
you
know,
reviewing
things
and
you
know
just
trying
to
help
out
and
do
those
grammar
fixes
make
sure
that
everything
is
accounted
for,
and
maybe
that's
something
that
you
know
that
doesn't
require
such
a
high
hourly
rate.
D
D
Yeah
I
will
too,
I
was
gonna
say
I
think
it's
still
like
a
good
way
of
finding
people,
because
to
me,
like
the
the
people
who
will
be
doing
this
job,
where
the
funding
that
really
matters
is
the
people
who
maybe
don't
have
some
sort
of
full-time
job
already,
and
they
are
part
of
the
community,
but
maybe
they're.
You
know
a
freelancer
open
source
developer
to
me.
A
So
while
we
are
here
discussing
this
thing,
I
mean,
if
there
are
any
recommendation
for
erc
editors
to
whom
we
can
approach
to
like
talking
about
these
things,
that
we
are
looking
for.
A
Any
anyone,
if,
if
you
guys,
have
any
doubt
in
mind
that
who
could
be
playing
this
role
or
maybe
interested
in
contributing.
G
A
We
are
moving
towards
having
a
separate
repository
for
eips
and
ercs
and
because
of
time
constant
or
the
current
eip
editors.
They
choose
to
do
the
eips
only
and
may
not
give
enough
time
for
erc
so
they're.
Looking
for
more
user
data.
G
E
G
E
Well
so
I
mean
that's
part
of
why
I
decided
to
drop
them
is
because
I
was
reviewing
everything,
but
I
don't
have
time
so
I
had
to
pick
what
to
drop
and
ercs
are
less
important
than
eips,
even
just
like.
So
when
I
say
review,
I
would
review
give
feedback,
but
ultimately
it's
up
to
the
author
to
push
through,
even
if
I
tell
them
this
is
a
terrible
idea.
I
mean
I'll
merge
it.
F
E
If
it's
valid,
but
the
timezone
part
is
just
getting
them
valid
for
some
reason,
ercs
tend
to
be
incredibly
long-winded
and
wordy
compared
to
eips
compared
to
corey
ips
core
ips
very
often
are
like
less
than
a
page
like
it's
very
terse,
very
to
the
point,
whereas
ercs
can
be.
You
know
it's
like
a
50-page
document
and
just
getting
that
like
in
up
to
editorial
standards,
it's
time
consuming,
ignoring
like
making
it
good
and
useful
like
just
getting
it.
E
E
A
Okay,
I
mean
it
seems
that
there
are
a
few
more
things
that
we
might
want
to
look
into,
and
I
don't
know
maybe,
on
the
funding
part
I'll,
try
to
reach
people
offline
and
get
some
estimate
on
that.
I
I'm
having
a
thought
of
you
know
kind
of
having
one
as
a
lightline
was
suggesting,
maybe
one
person
with
technical
knowledge
to
actually
understand
what
eips
and
ercs
are
and
look
into
the
like
important
sections
of
it
and
the
for
grammatical,
and
you
know,
spelling
mistakes.
A
I
am
not
sure,
like
you
know
that,
though,
for
that
we
should
have
separate,
eips
or
erc
editors,
that
that
can
be
a
part
of
it
or
maybe
it
can
be
done
on
a
voluntary
basis,
like
people
generally
seem
to
create
a
pull
request,
suggesting
some
type
of
I'm
not
sure
what
I'm
talking
about
here
right
now.
But
I
think
this
is
something
that
we
should
be
thinking
more
through
it,
and
maybe
we
can
come
up
with
some.
Some
estimate
that
we
can
reach
out
to
people
for
fun
for
this
task.
A
Okay,
thank
you,
everyone,
and
I
see
you
guys
all
in
two
weeks.
Thanks
for
joining
the
call
today
have
a
good
one.