►
From YouTube: EIPIP meeting #19
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/36
A
Hello,
everyone-
this
is
eipip
meeting
19.
the
agenda,
I'm
going
to
share
in
the
chat.
So
the
first
item.
B
On
the
agenda
today
is
onboarding
eip
editors.
This
was
to
set
the
expectation
and
guidelines
for
the
editors
that
we
are
planning
to
onboard.
We
have
limited
number
of
additives,
and
the
numbers
of
open
pull
requests
are
way
too
many
for
few
editors
to
handle.
So
edson
conducted
some
survey.
So
what
do
you
want
to
go
ahead
and
take
it
away?.
C
Who
is
already
reviewing
eips
someone
who
understands
what
a
standard
is
and
understands
what
content
should
be
left
out
of
what
a
standard
is
and
someone
who
understands
ethereum
to
an
intermediate
level
and
is
a
good
mediator
for
contentious
conversation.
C
B
B
My
bad
so
yeah
and
we've
been
hoping
to
you
know,
get
these
things
the
expectations
and
the
responsibilities.
Would
it
be
possible
to
get
it
documented
somewhere
or
maybe
have
complete
file,
or
how
do
you
want
to
see
it?
B
C
C
C
F
B
Okay,
I
do
not
have
any
strong
feeling
that
where
it
should
go
but
yeah,
I
agree
like
as
long
as
information
is
available
and
people
are
able
to
access
it.
It's
fine,
but
you
know
the
reach.
Would
I
mean
like
it's,
my
personal
thought
again,
which
is
like
the
reach
would
increase.
If
we
have
it
mentioned,
even
the
link
of
the
article
that
you
are
writing
mention
it
somewhere,
which
is
easily
accessible
to
community
and
that
somewhere
most
of
the
time
comes.
B
C
C
So
it's
a
very
small
amount
of
people,
so
at
the
moment
they
become
an
editor.
We
can
just
send
them
like
personally
that
link
to
that
repository
article.
B
C
So
these
were
brought
up
in
the
survey
there
weren't
things
that
I
thought
of
but
different
suggestions
that
people
had
for
the
aps
themselves,
and,
let
me
open
it
up,
it
was,
should
a
reference
implementation
be
made
as
a
requirement
should
there
be
a
tagging
system
should,
should
the
ap
include
use
cases
should
the
eap
include
pros
and
cons?
So
these
are
a
small
selection
of
suggestions.
C
B
E
I
think
the
idea
with
that
is
that,
like
already
you
can
include
those
things
in
motivation
that
is
the
appropriate
place
to
include
use
cases,
and
we
have
advised
people
on
that
at
the
moment.
In
eip
one
users,
it's
not
clear
enough
to
users
what
the
different
sections
mean
and
what
is
appropriate
for
them,
and
so
we
often
as
editors
end
up
having
to
kind
of
walk
people
through
okay.
This
is
what
goes
in
the
abstract.
This
is
what
goes
the
motivation,
etc.
E
So
anything
we
can
do
to
give
to
help
users
get
it
right,
the
first
time,
without
an
editor
having
to
jump
in
and
tell
them
how
to
do.
It
is
valuable
whether
this
is
valuable
enough.
I'm
fine
with
it
like.
I
don't
have
a
problem
with
with
adding
it.
I
think
in
general,
though,
we
do
need
to
get
better
descriptions
in
the
eip1,
because
as
they're
written
right
now,
users
are
not
understanding
it
and
like
people
who
read
eip1,
walk
away,
not
really
understanding
what
goes
in
each
section.
So
this
would
help
with.
E
B
Right
so
like
it's
a
would,
you
want
to
take
a
stab
on
it
like
open,
a
full
request
with
specifying
these
things
I
mean
these
are
already
there,
but
in
the
specific
categories,
maybe.
A
E
What
were
the
other
ones,
so
one
of
them
was
the
one
I
was
commenting
on
specifically.
Was
the
motivation
use
cases
one?
What
were
the
other?
I
think
two
or
three
a
reference
implementation.
E
Yeah
that
one
was
for
me
at
the
moment,
people
I've
noticed
are
using
the
implementation
section
as
a
way
to
basically
advertise
their
product
that
they're
trying.
Basically,
people
are
using
eips
as
an
advertising
thing
like
they.
The
belief
is:
hey
lots
of
ethereum
users
are
reading
eips.
E
Don't
link
out
textual
recompose,
and
the
argument
I
generally
make
to
users
is
that
we
want
to
make
sure
that
the
aips
repo
never
gets
404
links
and
all
that
stuff,
but
really
what
it
comes
down
to
is
we.
We
don't
want
to
open
the
doors
for
turning
eips
into
an
at
like
a
place
to
advertise,
and
it's
a
huge
amount
of
work
for
us,
like
I,
I
would
say
well,
over
half
the
ieps
I
review
in
my
opinion,
don't
need
to
be
standards.
E
They
just
are
someone
documenting
their
app
on
the
earpiece
repo,
and
so
it's
a
big
burden
on
the
editors
to
constantly
be
dealing
with
that.
So
anything
we
can
do
to
make
it
more
clear
that
hey
this
is
not
a
section
where
you
go
link
to
your
your
app.
This
is
a
section
where
you
put
code
is
kind
of
what
I
was
going
for
to
play
devil's
advocate
since
the
other
people
who
don't
like
this
idea.
Aren't
here
I'll
try
to
represent
the
best
I
can.
E
Their
argument
is
that
the
implementations
first
of
all
try
and
write
the
spec.
It
is
very
useful
to
be
able
to
go
look
at
someone
else
who
has
written
the
spec,
and
so,
in
those
cases,
a
link
out
to
a
third
third-party
repository
can
be
very
valuable
and
oftentimes.
Those
repositories
are
much
bigger
than
as
reasonable
to
put
in
line
in
the
iep
or
even
as
like,
in
the
assets
directory,
and
so
by
constraining
that
section.
B
Follow
on
this
topic,
specifically,
I
would
like
to
make
a
mention
here.
The
category
started
peep
and
eep
series
that
is
dedicated
to
eip
and
we
discuss
about
proposal.
The
very
first
episode
of
that
is
about
creating
an
eip.
I
mean
like
kind
matt.
B
So
I
I
think,
I'm
not
sure
if,
if
it
is
appropriate
to
make
a
mention
of
that,
we
can
probably
put
a
link
of
that
and
people
can
go
and
watch
that,
because
in
that,
like
clan
has
explained
a
lot
of
stuff,
which
would
be
very
helpful
when
you
are
creating
an
eip
for
the
first
time.
E
We
don't
have
to
then
decide
okay.
This
is
valuable
as
an
eip,
or
this
is
just
an
advertisement,
because
there's
a
lot
of
vips
are
kind
of
borderline
where
it's
like.
I
think
this
is
really
just
an
advertisement
for
for
an
app,
but
I
mean
the
user
can
make
an
argument,
and
now
we're
getting
into
the
debate
of
okay
is.
Is
there
argument
sound?
Is
it
a
good
argument?
E
Whereas
if
we
just
made
it
so
they
couldn't
advertise,
then
all
those
people
would
kind
of
just
go
away
and
they
wouldn't
even
try
to
fight
us,
because
even
if
they
did
get
an
eip
created,
it
wouldn't
help
them
advertise,
and
so
so
I
guess
there's
two
problems.
One
people
writing
apas,
don't
know
how
to
write
good
aps
and
I
think
the
peep
and
eap
is
episode
that
you
talked
about
is
great.
E
B
B
E
So
at
the
moment,
basically,
the
only
thing
that
gets
you
kicked
out
of
the
ap's
repo
is,
if
it's
not
technically
sound
like
like
it's
very
cut
and
dry,
there
is
no
wiggle
room
for
editors,
making
opinionated
decisions.
It's
just
like.
Does
this
meet
the
technical
requirements
of
an
erp?
Yes,
okay,
it's
an
erp.
Historically,
the
editors
have
all
and-
and
I
actually
agree
with
this-
that
editors
have
all
been
very
hesitant
to
introduce
any
judgment
calls
by
the
editors
like
we've
tried
very
hard
to
make
it.
E
This
is
why
we
don't
have
any
fuzzy
rules.
All
our
rules
are
very
clear-cut
which
and
which
is
also
why
I
would
like
a
rule
that
is
clear-cut.
That
makes
it.
You
cannot
link
to
your
personal
repo
in
any
ip
and,
like
I
said,
they're
they're
downsizing
this.
It
means
that
for
the
legitimate
use
cases,
people
can't
link
to
repos,
and
so,
if
we
want
to
stick
to
our
hard-line
stances,
we
need
to
choose.
E
B
I
can
see
one
thing
that
you
have
mentioned
that
mentioning
their
personal
eip.
I
mean
github
repo.
That
is
there
in
most
of
the
genuine
cases,
because,
while
working
on
some
project,
they
came
across
something
and
that
is
again
sent
to
the
eip
repo
as
a
pull
request.
So
it
is
going
to
be
linked
back
in
most
of
the
cases.
So
I'm
not
sure
if
that
can
be
a
hard
rule.
B
E
However,
historically
both
this
all
core
devs
has
this
exact
same
problem
where
everybody
is
very
hesitant
to
give
anyone
else,
the
power
to
set
rules
and
enforce
rules,
and
so
I'm
not
confident
that
would
go
over
well,
I
do
agree
with
you,
though
things
would
go
way
better
if
we
had
like
an
authority,
figure
or
figures
who
just
said
no,
I
do
not
accept
and
I
don't
need
to
give
you
a
reason,
or
at
least
I
don't
need
to
convince
you
of
my
reason
I
should
say,
but
yeah
that's
it'd-
be
very
hard
sell.
E
F
So
curious,
sorry,
so
what's.
F
Being
no
linking
external
code
in
the
repo
I
mean,
I
understand
it
would
be
more
difficult
for
certain
projects,
but
then
couldn't
those
projects
just
write
out,
hey
like-
and
I
understand
that
like
having
a
link,
would
make
it
easier.
But
you
know
it
seems
like
yeah.
What's
the
main
issue
against,
I
guess.
E
As
I
understand
it,
and
again,
I'm
trying
to
represent
people
who
aren't
here
so
it's
best
if
we
get
it
from
them
once
they're
around.
But
I
my
understanding
of
their
issue
is
that
they're
concerned
there
are
some
eips
that,
when
implemented,
are
very
complicated,
particularly
core
eips,
where
implementing
a
core
eip
like
a
reference.
Implementation
may
be
like.
E
Yes,
like
that's
your
reference
implementation.
It's
like
an
entire
repository
of
stuff
and
like
the
eip
is
implemented.
You
know
all
over
that
that
repository,
like
especially
evm
changes.
You
know,
there's
not
just
like
one
line
somewhere
where
it's
like.
Oh
here's,
the
evm
change,
it's
like
here's,
the
entire
evm
and
here
are
the
12
different
places
in
that
giant
code
base
that
we
touch
with
this
eip
and
so
reference
implementations
for
those
are
very
difficult.
Whereas,
if
you're
just
linking
to
geth,
then
it
all
of
a
sudden
becomes
much
easier.
E
You
can
just
say:
hey
here's,
the
guest
repo
they've
implemented
it.
Here's
the
15
files
that
it
you
want
to
look
at.
If
you
want
to
check
to
see
you
know
the
places
that
this
touches,
whereas
a
reference
implementation
was
like.
Okay,
go
write,
another
client,
it's
kind
of
the
replica
yeah,
the
reference
implementation,
yeah.
F
That
makes
sense,
I
guess,
like
the
issues
that
you
were
proposing
of
people
or
teams,
trying
to
simply
use
the
repo
as
advertisement
is.
I
would
assume
that's
not
something
that
usually
happens
from
client
teams,
though
so
could
like
or
sort
from
corey
isd
so
could
core.
I
eips
have
a
specific
distinction
of
allowing
links
just
to
keep
things
the
way
it
is
and
then
just
have
other,
like
all
other
eips
not
allow
links.
Would
that
be
a
way
just
to
kind
of
okay?
F
Well,
you
know
what
these
more
complicated
eips
we're
going
to
allow
links
still
but
try
something
different
with,
or
this
new
way
of
doing
things
with
other
efps,
potentially.
E
That
could
potentially
could
could
help.
I
think
that
there
are
situations
where
an
eip
is
complicated
enough
to
probably
warrant
its
own.
You
know
linking
out
to
separate
repo
and
it's
not
a
core
ap.
Those
are
definitely
much
less
common.
I
think
I'm
I'm
not
against
that.
What
you
just
suggested
again
playing
devil's
advocate.
E
I
think
the
argument
is,
is
we're
now
adding
more
complexity
into
our
process,
because
now
we
have
to
draw
a
line
between
what
is
core
and
what
is
not,
and
there
there
have
been
examples
recently
in
the
past,
where
it's
kind
of
blurry,
sometimes
what's
the
core
ap
and
what's
not
and
then
like
what,
if
someone's
linking
out
to
a
fork
of
death
and
because
it's
not
implemented
in
gaff
yet
such
as
their
fork,
but
whether
that
fork
ends
up
being
you
know,
another
ethereum,
client
or
another
ethereum
network,
like
you
know,
turbo
gas,
for
example,
is,
is
that
part
of
ethereum
network?
E
It
doesn't
actually
sync
with
the
ethereum
network
right
now
fully,
I
don't
think
but
they're.
Also
not
you
know,
building
for
tron
or
something.
Yet
there
are
ethereum
clients
that
are
forked
from
geth
that
are
building
for
tron.
Should
we
allow
them
to
link
like
it's
just.
I
think
I
think
there's
going
to
be
a
fear
and
pushback
of
like.
E
Where
do
we
draw
the
line,
because
now
we
have
we're
the
arbiters
of
what
is
an
official
client
and
historically,
no
one
has
named
any
official
clients
like
geth
is
the
most
popular
but
there's
open,
ethereum,
there's
another
mine,
there's
bessu,
there's
turbogeth
and
the
line
there
is
very
blurry
of
okay.
Where
do
we
draw
the
line
who's
allowed
to
do
this
and
who's
not
again,
I'm
not
against
what
you
suggested.
I
just
that's
that's
what
a
problem
I
can
see
coming
up
potentially
well,
that
makes
that
makes
a
lot
of
sense.
Thank
you.
B
Will
it
make
sense
to
kind
of
mention
this
thing
like
in
this
particular
group,
this
eipab
group?
What
we
are
trying
to
do
is
kind
of
improve
the
process
which
is
ongoing.
We
discuss
about
some
of
the
issues
and
we
brainstorm
potential
solutions
and
try
to
come
up
with
solution,
but
the
implementation
part
in
my
mind
would
not
be
effective
if
we
are
not
getting
support
from
everybody
and
if
they
are
not
willing
to
accept
the
you
know,
decisions
that
are
being
made
or
the
proposals
actually
is
not
decision.
B
The
proposals
that
are
like
going
out
from
this
meeting
so
will
it
make
sense
to
kind
of
guard
the
all-core
devs
sentiment
on
this
part
like
how
good
it
is
to
define
certain
rules
like
so
far.
There
are
not
hard
lines
now
we
want
to
define
hard
lines.
Is
it
something
that
is
acceptable,
then
then
this
particular
group
can
come
up
with
certain
rules
and
we
can
share
it
with
them
to
get
collectors.
E
So
if
I
pretend
to
be
james
for
a
moment,
I
will
I'll
say
that
putting
my
james
hat
on,
I
think
james
would
say
we're
trying
really
hard
to
separate
eips
from
the
core
devs
and
not
have
they
are
a
user
of
the
ips
repo,
but
they
are
not
special
they're,
not
authoritative.
They
like.
Basically,
we
don't
need
to
get
permission
from
the
core
devs
do
anything.
The
efps
is
not
a
coordinated
thing.
It
is
a
totally
separate
entity,
separate
people
managing
it.
B
Yeah,
I
know
I
I'm
getting
the
point
here
so
in
that
case,
in
my
mind,
it
feels
like
you
know.
The
eip
author
should
be
like
the
the
group,
the
people
who
should
be
like
making
rules
and-
and
we
the
cat,
headers
or
the
ipip
group
group-
can
support
to
get
it
enforced
like
we
should
list
it.
A
B
B
B
C
So
greg
said
that
eap
is
already
tagged
with
labels,
I'm
not
yeah.
I.
C
Yeah
so
for
tags
I
don't
know
what
would
be
added
so
like
tagging
implies
that
multiple
tags
could
be
applied
to
the
to
a
single
eap
and
then
it'd
be
used
to
filter,
maybe
like
in
the
eap
website.
E
E
Personally,
I
worry
that
what
is
a
tag
and
what
isn't
and
which
things
get
tagged
with
which
things
is
going
to
be
complicated,
and
I
don't
know
if
it's
worth
it
like
I,
my
personal
opinion
is
people
should
really
only
be
reading
final
eips,
like
too
many
people
read
drafty
ips
and
there
are
relatively
few
final
eips
so,
like
I
don't
know
if
we
have
enough
final
efps
to
warrant
having
a
mechanism
for
filtering
them
yet
and
for
draft
eips
I'd
rather
people
just
like
get
them
out
of
draft.
C
B
A
B
And
the
next
item
in
this
was
also
referring
open
issues.
Okay,
on
the
expectation
guideline,
there
was
already
a
pull
request
open
as
a
role
of
editors
in
eip
process.
I'm
not
sure
did
you
also
consider
that,
while
considering
the
expectations
for
eib.
B
B
Okay,
so
there
is
a
the
next
topic
which
is
on
the
agenda
item.
First
about
the
expectation
of
responsibilities
of
eip
editors.
There
was
also
an
open
pull
request.
Talking
about
these
things,
I
think
it's
one,
four,
six,
seven
pull
request
one
four,
six:
seven
role
of
editors
in
eip
process
just
wanted
to
bring
it
to
your
attention,
while
documenting
the
expectation
if
this
can
be
considered
as.
B
B
Okay,
anything
more
on
agenda
item,
one
on
onboarding,
eip
editors.
I
think
we
came
up
with
two
decisions.
One
edson
would
be
writing
up
a
medium
post
on
elp
editor's
expectations
and
responsibilities,
and
he
would
be
also
opening
up
a
request
for,
for
what
more
could
be
added
when
we
are
proposing
an
elp.
C
Just
one
thing
before
we
move
on,
I'm
I'm
looking
through
the
issue
and
it's
saying
that
eap
editors
assign
numbers,
I
don't
think
that's
actually
true.
We
should
probably
update
the
eap
one
with
that.
B
I
think
I
have
seen
some
comments
of
greg
on
that
part.
He
mentioned
that
it
is
actually
the
role
of
editor,
but
most
of
the
time
author
does
by
themselves.
They
do
it.
Like
I
don't
know,
I
have
found
that
bot
does
not
give
it
a
pass.
If
we
don't
add
the
eip
number
or
something
like
that,
I'm
not
sure.
C
E
B
C
Oh
because
I
was
looking
through
the
core
devs
chat
and
they
had
suggested
that
I
think
they
had
decided
that
the
the
ap
number
is
the
pull
request.
Number.
E
Yeah
a
couple
times
has
happened
where
something
other
than
the
full
request
number
was
used,
one
of
one
time
it
was
because
someone
was
trying
to
squat,
and
so
we
punished
them
by
giving
them
a
different
number
like
they're,
trying
to
squat
on
a
particular
pr
number
and
the
way
they
did
it
was
they
spammed
the
ips
repo,
with
a
bunch
of
issues
to
bump
the
number
up
to
what
they
wanted,
and
then
they
took
number
they
wanted,
and
we
just
said
no
and
we
gave
them
something
different
and
that
made
them
very
sad
and
that
made
us
very
happy.
B
C
I
mean
generally
like
so
I
think
it's
the
exception
where
the
eip
editor
changes
the
number,
but
most
cases
the
eap
number
is
the
poor
cost
number,
and
I
don't
usually
see
authors
asking
permission
from
the
editors
for
that.
In
that
case,.
E
Yeah,
currently,
that
is
the
case.
The
vast
majority
of
vips
are
just
the
pull
request
number,
because
it's
easy
we've
also
given
people
like
if
they
start
with
a
an
issue
and
like
like,
we
recommend
they
do,
they
start
with
an
issue
as
an
idea.
They
flesh
it
out
a
little
bit
and
they
create
a
draft,
sometimes
we'll.
Let
them
use
their
issue
number
instead,
just
because,
like
maybe
they've,
already
referenced,
it
or
they've
already
talked
about
it.
E
C
I
guess,
like
the
biggest
benefit
would
be
to
new
new
authors,
because
it's
not
anywhere
in
the
ep
one,
but
that's
the
way
it's
done
so.
E
Oh
you're
saying
we
could
save
the
editors
some
effort
like
right
now,
author
creates
an
eip.
They
put
tpd
and
the
eip
number
editor
just
immediately
posts.
A
comment
saying
change
this
to
the
pr
number
we're
saying
we
could
avoid
that
step.
If
the
author
is
just
did
put
the
ip
sorry.
If
the
author
is
filled
in
on
the
first
draft.
B
Well,
on
the
contrary,
I
believe
that
keeping
it
with
the
editors
will
help
us
prevent
some
squatting
thing
as
well
right.
So
if
we
don't
do
that,
and
if
we
allow
the
editors
to
just
choose
the
pr
number,
then
I'm
not
sure
if
we
would
be
able
to
stop
that.
C
We
could
all
we
could
also
just
specify
any
if
you
want
these
things
aren't
allowed
like
inflating
opening
issues
to
get
a
specific
number
opening
a
pr
with
that's
empty
for
a
specific
number.
B
My
thought
is,
it
should
be
with
the
eip
editor
itself
like
they
should
have
authority
of
like
we
are
giving
everything
to
the
eip
editor.
We
are
saying
that
they
are
the
boss
and
they
would
look
into
everything.
So
the
the
like
top
most
thing
is
the
number
that
it
is
referred
with,
but
that's
again.
B
E
C
I
can
maybe
try
to
rejoin,
I
should
be
using
headphones,
so
this
shouldn't
be
an
echo.
E
A
E
And
so
it's
very
minor
to
me
to
have
to
tell
people
hey
like
it's
just
you
know
triple
backs
back,
take
suggestion
type
in
the
number
triple
back
tick
like
it's
super
easy
for
me,
super
easy
for
the
the
author,
and
so
that's
why
I
don't
really
care
like
there's
so
many
more
time
consuming
problems
when,
as
an
editor
that
one's
easy.
B
Keep
it
open
for
one
more
meeting
and
share
it
outside
this
group
present
group
to
get
some
more
response
on
that.
If
general
opinion
is,
it
does
not
matter,
I'm
fine
with
that.
C
So
here
here's
can
you
hear.
C
C
So
it
would
be
weird
to
open
a
pr
with
the
file
name
that
doesn't
that's
just
empty.
B
E
C
B
So
like,
as
far
as
I
remember,
it
is
already
mentioned
in
there,
but
not
all
the
time
that
you
just
do
that
like
in
in
my
case,
I
have
made
three
four
pull
requests
so
for
a
couple
of
files
when
it
was
not
getting.
I
bought
pass
so,
like
ken
suggested
me
micah
suggested.
Then
I
I
went
ahead
and
I
corrected
it
tried
the
wrote,
the
eip
number
and
it
then
started
showing
me
the
green
check.
So
it
was
fine
by
me.
A
A
B
Anyone
has
any
anything
concluding
on
this
topic.
B
Okay,
then,
in
that
case,
like
I
would
like
to
keep
it
open.
Like
maybe
add
it
only
this
point
before
you
go
ahead
and
make
couple
requests
for
changing
this
particular
point
like
the
eip
number
would
be
provided,
would
be
added
by
the
author
itself
and
it
does
not
come
in
the
responsibility
of
eip
editors.
Just
this
point
and
let's
some
more
opinion
on
it.
B
If
people
think
that
it
is
not
very
important
thing
and
like
it
can
go
and
all
the
authors
should
go
ahead
and
do
that
that
will
be
added
in
the
pull
requester
one,
the
one
you
are
creating
for.
B
B
Oh,
my
god,
we
are
okay,
so
there
are
a
few
other
topics
that
we
have
to
touch
today.
I
am
not
sure
like
we
would
be
able
to
get
on
all
of
them,
but
there
is
one
topic
which
was
suggested
by
mika
about
the
mika.
Has
too
much
power?
B
B
A
B
C
B
So
yeah
historically,
a
selection
of
editor
was
a
simple
like
complete
the
present
editor.
They
select
somebody
and
that
person
is
now
auditor
and
they
can
start
taking
up
responsibility,
but
I
think
we
can.
B
I
mean
if
it
is
okay
with
the
group,
we
can
make
a
you
know,
tweet
about
it,
asking
for
in
inviting
for
adjectives
and
let's
see
if
people
who
are
from
the
community
and
they
are
interested,
it's
just
that
they
are
not
aware
of
like
we
are
looking
for
more
editors.
If
they
show
up,
then
we
can
pass
along
the
names.
C
B
C
Maybe
we
could
ask
current
core
developers,
since
they
already
have
an
understanding
of
the
like
ethereum.
They
should
like
a
at
least
an
intermediate,
if
not
advanced,
understanding
of
ethereum.
B
C
B
Okay,
so
in
that
case,
maybe
this
document
that
edson
specifying
what
is
the
expectation
five
hours
a
week,
but
maybe
I'm
not
sure
if
they
are
comfortable
or
like
taking
out
time
and
doing
it.
B
C
Yeah,
so
the
the
time
requirement
was
minimum
zero
to
five
hours.
So
I
mean
even
one
hour
a
week
is
fine.
As
long
like
one
hour
of
work
for
eap
repos,
I
don't
think
it
takes
much
time
to
review
eaps
because
it's
mostly
just
approving
or
specifying
why
it's
not
approved.
E
E
People
won't
go
educate
themselves
before
they
create
an
eip
and
then
like
should
are
we
supposed
to
just
be
like
if
someone
shows
up
writes
in
the
iep
and
it's
bad?
Am
I
supposed
to
just
say,
go,
go.
Take
this
course
and
come
back
or
should
I
okay?
I
feel
that's
a
little
bit
rude,
but
I
mean
at
the
same
time
I
don't
have
infinite
time,
so
that
may
be
the
only
option.
I
have.
C
Yeah,
so
I
was
thinking
that
right,
an
entire
course,
but
there
could
be
say
say:
there's
something
that
they
that
they
miswrote
or
some
something
that
they
have,
that
isn't
meaning
the
requirements
of
a
specification.
Instead
of
writing
it
out
entirely,
you
could
summarize
it
and
then
link
to
an
external
source.
That
says
read
this
to
understand.
Really
what
I'm
saying.
D
You
could
also
like
say,
create
a
core
or
let
me
just
think
about
like
a
documentation
for
how
it
works,
and
then
you
can
just
reference
that
documentation
whenever
you
have
a
problem
with
that
documentation.
Having
like
the
full
explanation
regarding
the
problem
itself,
that's
like
relatively
common
or
whatever.
That
might
be
easier.
F
Yeah,
if
you
personally,
if
it
was
a
course,
I
mean
you,
can
call
it
like
a
course
or
documentation
or
whatever
it
is,
but
I
think,
having
you
know
the
editor
being
able
to
link
just
like
you
know
not
having
to
teach,
because
I
feel
like
all
the
teaching
that
you're
doing
like
is
probably
could
have
been
put
into
a
course.
Anyways,
probably
notice
you.
So
you
know
if
there
was
this
like
place,
people
to
go
to
for
michael
can
just
be
like
okay.
Well,
I
mean
you're
way
off
base.
F
C
Easier,
I
mean
like
because
we
we
do
want
more
editors,
but
if
most
of
their
time
is
being
spent
educating,
we
could
just
do
the
education
beforehand
and
then
have
the
editors
like
back
because,
like
the
ultimately
like
one
of
the
larger
goals
is
just
reducing
the
backlog.
C
But
I
still,
I
still
think
we
should
add
more
editors
and
we
should
brainstorm
how
to
how
to
onboard
more
editors.
E
Regarding
yeah,
so
I
think
that
we
need
more
there's
two
reasons:
one
to
help
keep
up
with
everything
like
I
fall
behind
frequently
and
it's
hard
to
catch
up,
and
we
still
have
a
backlog
of
prs
that
haven't
been
touched
for
a
year
because
I
have
not
like.
Currently,
I
only
try
to
keep
up.
I
do
not
try
to
clear
the
backlog.
If
we
had
more
editors,
we
could
do
both.
E
Informational
eips
are
de
facto
banned
from
the
repository,
because
I
won't
merge
them,
and
I
do
not
think
that
I
should
be
have
the
power
to
do
that,
like
without
discussion
without
agreement.
Like
no
one
agrees
with
me
on
this,
which
is
my
personal
opinion,
yet
that
is
effectively
what
is
happening,
and
I
do
not
like
that,
and
so,
even
if
we
do
reduce
my
workload,
I
still
do
think
we
need
more
editors.
B
So
yeah,
I
think
the
best
way
that
is
like
we
should
try
to
first
finish
up
with
this
document
this,
the
medium
post
that
tarzan
will
be
working
on
then
we'll
try
to
reach
out
the
co-developers
or
the
people
who
are
heavily
engaged
in
ethereum
development
if
they
would
be
interested
to
be.
You
know,
editors
to
to
be
giving
some
time,
maybe
an
hour
a
day
or
something
like
that.
B
E
B
D
B
B
Okay,
so
I
think
this
is
not
something
that
we
can
decide
right
away.
It's
going
to
take
time,
maybe
in
next
three
four
meetings
we
would
be
in
a
good
position
to
speak
more
about
it,
how
we
are
proceeding
and
like
we
are
almost
time.
I
would
quickly
like
to
cover
a
few
things
which
was
which
is
coming
from
the
action
item
from
the
previous
meeting.
B
A
light
line
shared
a
twitter
account
eip
info
for
tweeting
eip
updates.
I
have
shared
that
with
james,
so
everybody
else
is
interested
they
can
get
in
touch
with
james.
On
this
part,.
B
There
is
another
item:
should
meta
and
information
eip
be
part
of
eip
at
all,
so
that
was
listed
here
in
today's
agenda,
like
eip
repositories
scope,
but
we
could
not
cover
it.
It's
a
long
discussion
and
we
could
not
cover
it
in
this
time.
So
I'm
going
to
move
it
to
the
next
meeting.
A
B
Puja
will
reach
out
to
eip
authors
to
get
them
to
follow.
The
documented
network
upgrade
mika,
and
I
mentioned
this
in
the
all
called
meeting
that
the
author
should
be
creating
pull
requests
to
change
the
status
of
their
proposals,
which
are
getting
into
berlin
mika
reached
out
to
aragon
to
tell
them
they
need
to
put
in
comment
to
eip3000,
I'm
not
sure
mika.
Is
it
a
closed
item
now.
E
Yeah
that
was
handled
they,
I
told
them
to
add
content,
and
they
did
after
like
a
day
and
then
it
covers
it.
B
Great
move
agenda
item
four
to
six
to
the
to
the
next
meeting
that
we
tried
to
cover
in
this
meeting
and
yeah.
That's
all
from
the
previous
meeting
anything
else
people
would
like
to
cover
today.
We
are
like
one
minute
past
the
time,
but
yes
is
something
that
can
be
quickly
seen.
I
don't
see
a
light
line
or
james
on
the
call
or
hudson
so
skipping
the
triaging
permission
item,
but
anything
else.
If
anybody
would
like
to
discuss.
B
Cool,
so
we
made
good
progress.
We
have
some
decisions
or,
being
you
know,
to
do's
for
us.
Thank
you.
All
for
joining
today
see
you
in
two
weeks
november,
4th
2020.
one
more
thing
like
on
november.
4Th
the
time
is
going
to
be
changed
for
the
daylight
people
living
in
the
daylight
area,
like
est,
is
going
to
change,
so
we
be
sure
that
the
meeting
is
at
1500
utc,
even
if
it
is
like
change
in
eurozone.