►
From YouTube: EIPIP meeting #20
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/38
A
B
A
Brent,
I
think
you
can
go
ahead
and
say
that,
because
that
was
like
pre-discussion,
so
we
were
unfortunately
not
able
to
record
that.
So,
if
you
have
anything
further
on
these
comments,
please
feel
free
to
add
it
here.
C
Okay,
yeah-
and
this
is
all
just
my
opinion,
so,
but
basically,
how
can
we
clarify
what
steps
the
ip
authors
need
to
take?
We've
had
this
discussion
in
the
last
in
multiple
meetings,
where
people
and
and
also
the
peep
and
eat
that
discussion
came
up
yet
again.
C
A
So,
as
far
as
the
present
process,
I
believe
like
at
this
point
of
time
the
the
process
is
to
bring
it
to
all
coders
attention
and
there
the
clients
are
providing
their
opinion
and
asking
questions
and
that's
the
way
an
eip
author
can
actually
request
for
including
that
to
be
in
the
clients
for
the
corey
ips,
as
well
as
with
this
new
process
in
place,
the
network
upgrade
process.
There
is
at
1.0
repository
there.
A
They
can
go
ahead
and
create
an
issue
and,
with
the
help
of
hardware
coordinator
that
can
be
brought
into
clients,
attention
is
there
anything
else
that
we
can
add
mic
up,
because
you
are
the
editor.
D
I
would
say
the
get
your
eip
to
at
least
into
draft
I've
seen
plenty
of
people
try
to
bring
eips
to
the
core
devs
without
even
being
in
draft
yet,
and
that's
almost
certainly
not
going
to
work
well
for
you.
Another
thing
I
think
you
can
do
is
if,
once
we
institute
the
review
step,
assuming
that
goes
through
then
getting
it
all
the
way
to
review,
I
think,
would
be
most
appropriate.
D
The
review
stage
will,
if,
if
we
go
forward
with
that,
indicate
that
the
eip
is
ready
for
general
consumption
and
review,
and
ideally
it
means
there
will
be
an
editor-
will
go
through
and
make
sure
that
everything
is.
You
know
structurally
sound
well
worded
stuff
like
that
and
so
you'll
have
by
the
time
it
gets
to
review.
D
D
While
I
know
it's
tempting
to
write,
you
know
a
long
essay
about
why
your
eip
is
great.
Editors
are
or
sorry
core
devs
are
very
short
on
time
and
having
something.
That's
quick
for
them
to
scan
over
and
read
is
very
valuable,
and
this
is
where
the
abstract
comes
in
very
handy
in
the
simple
summary
keeping
a
simple
summary
very
simple:
you
know
like
one
sentence
like
a
subject:
line
of
an
email
really
does
help
and
the
abstract
keeping
it
have.
It
be
a
human,
readable
and
very
short
version
of
the
specification.
D
B
D
Want,
I
would
say,
no
to
eip1
because
we're
trying
really
hard
to
keep
the
eips
repository
out
of
the
hard
fork
coordination
process,
and
this
is
really
a
hardcore
coordination
question.
The
ife
specs
definitely
seems
more
appropriate
to
me,
since
that
is
the
hard
four
coordination
repository.
A
Yeah,
probably
these
can
be
added
to
the
readme
section
of
at
one
spec,
just
to
add
more
clarification
on
what
steps
author
needs
to
take.
I
think
there
is
some
text
already
there,
but
we
can
add
some
more
information
that
would
be
helpful
for
new
authors
to
follow
along.
B
Okay,
the
next
question
is:
how
can
we
make
the
eap
process
more
well.
D
A
So
generally,
there
are
very
small
group
of
people
who
are
actually
involved
in
writing
an
eip.
Those
people
are
from
the
you
know,
who
are
already
engaged
in
ethereum
development,
and
most
of
them
are
there
in
the
all
core
dev
meeting.
So
if
we
can
get
this
thing
out
with
the
participants
of
the
all
coder
meeting,
I
think
that
is
one
place
from
where
we
can
start
and
let
people
know
about
this
process.
A
But
for
that,
since
we
are
avoiding
any
kind
of
eips
for
like
stating
the
processes,
we
can
definitely
add
it
in
read
me
section.
B
D
That's
that's
fair.
I
I
worry
that
the
rate
of
growth
of
people
wanting
to
draft
eips
will
outpace
the
rate
of
growth
of
editors,
just
because
that's
historically
been
the
case.
I
don't
know
how
to
solve
that.
D
Don't
take
my
my
comment
too
seriously.
It's
mostly
meant
glibly,
like
I
do
think,
want
people
to
use
the
eap
process
where
appropriate.
D
My
main
concern
is
that
the
eip
process
is
currently,
in
my
opinion,
misused
by
a
lot
of
people
like.
I
spend
a
lot
of
my
day
just
explaining
to
people
why
this
is
not
a
good
eap
or
why
this
isn't
this
thing
that
they
want
to
do
it's
not
appropriate
for
the
ips
repository,
and
so
it
whatever
solution
we
come
up
with.
It
would
be
nice
if
we
are
making
sure
we're
attracting
the
right
crowd
like
attracting
people
who
actually
should
be
writing
eips
or
who
we
would
benefit
from
writing
eips
rather
than
just
getting.
D
A
So
recently
I
have
come
across
some
queries
around
the
process
of
the
network
upgrade
like
because
that
that
has
changed
like
we.
We
did
some
modification
separated
the
eip
process
and
the
hard
work
process.
So
we
came
across
some
queries,
but
I
personally
feel
that
eip1
is
the
best
place
to
you
know
at
least
understand
what
the
eip
process
is
or
if
somebody
is
trying
to
write
it
down
for
the
first
time
now.
That
is
the
best
reference
available
at
this.
A
D
A
D
A
D
I
mean
the
readme
is
not
great,
don't
talk
about
me.
It's
got
like
maybe
two
paragraphs
about
the
process
and
a
lot
of
it's
duplicate
of
vip
one.
D
Maybe
I
mean
this
is
getting
a
little
off
into
the
weeds,
but
there
has
been
talk
in
the
past
and
I
tentatively
agree
that
we
should
just
have
the
readme
and
just
get
rid
of
eip1
and
have
the
readme
be
eip1.
If
you
want
it
would
be
named
readme,
but
you
can
call
it
eip1
or
something
or
I
don't
know
if
github
sports
some
links.
D
The
readme
is
the
way
that
most
people
who
use
github
regularly
get
their
information
and
then
eip1
then
duplicates
that
kind
of
same
purpose,
but
in
a
different
location,
and
so
I
think,
that's
part,
maybe
part
of
the
confusion
is
that
you
have
people
coming
to
the
re
coming
to
the
repository
reading,
the
readme,
which
is
what
they're
used
to
and
then
that
read
me
does
not
give
them
the
information
that
necessarily
we
want
to
give
them.
A
I
I
may
have
a
different
opinion
here
about
eip1
to
be
replaced
by
readme,
because
I
believe
that
that
eips.etdm.org,
the
website,
where
we
have
the
collection
of
all
eips,
I'm
not
sure
if
I
have
seen
that
read
me
section
there.
But
if
eips
I
mean
the
directions
are
mentioned
in
eip1,
eap1
would
be
there
and
it
would
be
an
easy
reference
for
people.
You
know.
So
personally,
I
feel
that
it
is
good
in
a
any
eyepiece
itself,
but
again.
D
D
Yeah,
it's
apparently
a
third
place
that
duplicates
the
exact
same
set
of
information
that
I
don't
even
know.
I
don't
know
where
that
comes
from.
We
should
figure
that
out
so
so
yeah.
We
have
three
places
that
essentially
are
trying
to
do
the
same
thing
which
is
describe
what
this
repository
is
and
what
its
purpose
is.
I
feel
like
we
should
try
to
consolidate
that
single.
A
D
So
yeah,
so
it
definitely
feels
so
now,
I'm
better
understanding
why
all
four
of
these
have
gaps.
So
each
one
of
these
is
not
ideal
like
they're
each
missing
something
or
they
each
have
a
little
problem
that
we've
run
to
one
point
or
another,
and
I
think
the
problem
is
just
that
there
are
four
different
places
that
all
share
a
purpose.
D
D
So
what
can
someone
help
me
understand?
What
the
difference
is
between
that
and
like
everyone
or
the
readme
or
the
front
page
of
eips.ethereum.org.
D
D
So
maybe
the
the
read
me
then
perhaps
it
should
mirror
ethereum.org
eips.
Does
that
make
sense
like
should
the
readme
of
the
eaps
repository
just
describe
what
an
eip
is
and
why
you
might
want
it,
or
should
it
be
more
like
eip1,
where
it
describes
the
process.
D
It
does
all,
I
believe,
all
of
these
link
to
each
other.
So
we
have
this
kind
of
mesh
of
these
four
things
that
are
all
very
similar
in
purpose
and
so
yeah,
like
the
this
first
paragraph
of
the
readme
says,
please
read
the
eip1
and
then
it
goes
on
to
kind
of
reiterate
what
eip1
just
said,
which,
if
you
follow
the
instructions,
you
would
have
already
read.
A
D
D
D
A
I
would
agree
that
makes
a
lot
of
sense
like
we
have
just
one
place
for
processes
and
arrest.
Others
just
to
you
know
let
people
know
about
it
like
there
is
a
place
where
you
can
find
the
right
process.
C
C
Also
also
micah
had
some
great
descriptions
of
the
process
and
what
to
go
through
and
those
are
contained
in
the
notes,
and
it
looks
like
pooja
you're
on
for
notes
for
to
this.
Today's
meeting
is
that
true.
A
Yeah
I
saw
myself
there,
but
I
may
not
be
doing
that.
Somebody
else
would
be
doing
it
on
let
people
know,
but
yes,
it
will
be
done.
C
Yeah,
but
I
was
wondering
if
whoever
is
going
to
do
the
notes,
if
I
could
work
with
that,
because
we've
captured
what
mike
has
said
on
those
steps
and-
and
we
should
work
on
capturing
that
and
get
that
we
talked
about
what
needs
to
be
done,
but
no
one's
volunteered
to
do
it
so
anyway,
I'd
like
to
help
with
that.
If
I
could.
D
I
don't
know
about
what
a
good
way
to
mirror
is,
I
think,
in
an
ideal
world
world,
where
engineering
was
free,
we
would
write
a
little
bot
that
just
made
it
so
anytime.
One
of
them
was
updated.
The
bot
would
go
and
submit
and
accept
and
merge
a
pr
into
the
other
two,
so
they
would
always
stay
in
sync,
but
that's
non-trivial
engineering
work,
and
so
I
don't
know
if
there's
a
better
process,
there's.
C
Always
source
source
source
page
include
where
you
just
blatantly
suck
another
page
into
your
page,
so
that
shouldn't
be
too
but
anyway,
I
could
look
into
that
I'll
I'll.
Take
a
task
to
look
into
that.
D
Yeah
that'd
be
great.
It's
like
you
figure
out
how
to
do
that
in
markdown.
Specifically,
like
does
markdown
support
just
like
iframe
or
something.
C
D
Yes,
the
other
thing
there
is
one
other
thing:
that's
in
the
readme
for
the
repository,
which
is
how
to
build
the
eip
site-
that's
very
common
in
re
enemies
for
github
things.
D
If
we
can
keep
that
in
the
footer
like,
so
the
top
would
be
a
mirror
of
everything
and
then
just
the
bottom.
It
just
says
hey.
This
is
how
you
build
this
repository.
That
would
be
nice.
If
that's
not
possible,
we
could
probably
move
it
to
another
file
and
I
don't
think
anyone's
gonna
cry
too
much
about
that.
C
B
I
could
go
with
the
next
question.
It
says:
how
can
the
community
track
progress
free
aps
and
who
has
it
implemented.
D
A
But
james
question:
I'm
just
helping
him
out
and
keeping
it
up
to
date,
for
example
the
current
process.
What
we
have
done
is
like
we
have
created
two
two
files
for
yellow,
v2
and
v3,
and
if
you
get
into
that
v2
and
v3,
you
will
get
to
know
what
state
of
development
any
client
is
say.
For
example,
like
earlier,
we
were
considering
that
open
ethereum
may
not
be
able
to
join
yellow
v3,
but
recently
they
have
shared
their
consent
that
they
would
be
joining
version
three,
so
it
is
marked
like
open.
A
Ethereum
would
also
be
a
part
like
they
have
mentioned
that
they
would
be
participating,
but
their
progress
is
still
to
be
captured
as
they
move
along.
The
process
is
captured
there
and
every
client's
status
is
being
updated
in
this
at
one
dot,
oh
spec,
so
people
can
follow
along
with
that
repository,
to
get
to
be
up
to
date
with
where
a
proposal
is
with
any
particular
client.
B
Yeah,
so
is
there
a
way
we
could
let
the
community
know
that
it's
trapped
in
the
ap
or
buzzer.
A
A
B
A
A
It's
not
in
the
so
if
community
wants
to,
if
community
wants
to
track
the
progress
of
any
core
eip
like
where
is
it
going,
the
core
eip
progress
can
be
tracked
with
the
help
of
at
one
dot.
Oh
spec
repository
there,
we
have
created
folders
based
on
the
devnet
developers
network
that
they
are
doing
for
at
the
moment
they
are
working
on
yellow
test
net,
yellow
fnet,
so
based
on
every
version
of
yolo,
the
progress
can
be
track.
A
Whatever
is
the
latest
version
of
yolo
there
before
any
upgrade
and
the
list
of
eips
are
there?
Those
will
get
into
the
hardware
and
those
eips
can
be
particularly
tracked
with
the
help
of
like
client
tracker
that
is
already
a
table
is
already
there.
So
if
you
can
look
into
that,
you
can
get
more
information
of
those
eips
and
that's
how
we
can
follow
the
progress.
B
A
Yeah
on
that,
like
this
network
upgrade
process,
this
is
actually
a
new
process
and
yeah.
I
agree
that
many
people
may
not
know
completely
about
that.
As
I
mentioned
earlier
in
the
call
that
I
have
received
some,
you
know,
queries
regarding
how
this
process
goes
around,
so
there
were
two
things
like
I
already
have
like
drafted
an
eip
that
was
eip1929
about
mentioning
the
process.
A
How
does
it
work,
but
that
is
still
there
and
we
still
have
not
decided
whether
we
should
be
keeping
that
as
an
meta,
informational
or
any
form
of
eip,
or
we
want
to
keep
that
information
anywhere
else,
but
if
that
is
not
going
to
be
in
the
form
of
any
eip,
I
would
be
happy
to
draft
a
medium
blog
on
that
and
explain
the
entire
process,
how
how
we
are
considering
it
like
this
with
this
new
network
upgrade
process.
If
that
helps.
B
I
think
I'm
in
the
process
of
writing
a
blog
on
medium
for
that,
so
what
I'm
doing
for
the
eap,
specs
repo?
I
guess
you
could
do
the
one
for
the
network
up
your
process.
A
I'm
not
sure
both
are
one
or
the
same.
I
like.
B
A
A
Got
it
got
it
yeah,
so
yeah?
I
can
go
ahead
and
do
that
like
I'll
sync
up
with
you
and
see
where
we
are,
if
that
has
to
be
separated,
yes,
we
can
go
ahead
and
do
that.
B
Do
we
have
time
for
the
other
ones
we
have?
I
think
six
minutes
left.
D
Yeah
or
at
least
having
when
a
discussion
happens
outside
the
discussion
link,
kind
of
back
port,
the
conclusion
of
that
discussion
into
the
discussion
link.
So
I've
done
this
in
eaps
before,
where
I'll
have
an
eib
drafted
up,
have
a
discussion
to
link
but
then
have
a
conversation
over
in
discord.
Somebody
and
then
I
try
to
go
back.
If
that
discord,
conversation
generated
some
new
change
or
some
new
content
or
some
new
conclusions,
I'll
go
back
to
the
discussion,
link
and
say
had
a
conversation
discord.
This
is
the
outcome
of
it.
D
D
D
Yeah
I'd
say
that
I
I
can
get
a
board
keeping
that
in
the
mp1,
I'm
generally
hesitant
to
add
things
the
ap
one,
because
it's
already
so
long
that
no
one
reads
it
and
it'd
be
nice.
If
we
can
keep
it
short,
but
I
do
think
that's
valuable
enough
and
it's
short
enough
that
we
can
have
like
you
know
one
sentence
that
just
says:
if
you
have
discussions
outside
the
discussion
too
link,
please
make
sure
to
kind
of
backport
the
conclusions
of
those
discussions.
So
people
who
are
following
can
follow
along.
A
I
think
these
questions
are
more
from
the
network
upgrade
side.
I
really
wish
james
could
have
been
here
to
answer
all
these
questions,
but
I
mean
like
if
a
proposal
needs
some
attention.
A
I
mean
we
have
ways
for
that,
but
technical
discussion
can
be.
You
know,
kept
up
in
the
some
for
some
time
like
for
some
some
proposals
that
can
be
there
in
the
github
pull
request
where
it
is
there,
but
that's
my
my
thought
on
it.
E
E
A
So
yeah
so
yeah
we
were
about
to
wrap
up.
E
B
B
Another
thing
is,
we
would
want
somewhere
a
point
of
maturity
where
the
eap
is
out
of
draft
and
into
a
point
where
the
author
is
asking
for
external
review,
which
should
be
helpful
in
the
hard
four
coordination
process,
because
at
that
point
we
could
have
a
prerequisite
for
an
eap
to
go
into
cfi.
By
needing
to
be
in
review,
you
can
make
that
explicit.
E
Pull
to
pull
drafts
into
the
core
dev
process
at
any
point,
that's
pretty
independent
from
from
the
ipp
process
point
of
view.
As
with
the
vip
process,
it
was
modeled
on
yeah.
The
main
transition
is
just
a
final
and
also
for
the
itf
process.
Things
just
stay
our
rfcs,
so
I
I
just
don't
see
that
adding
yet
another
status
solves
the
problem.
E
So
it's
it's
really
just
down
to
the
author
to
to
push
the
discussion
forward.
D
Out
of
curiosity
is
your:
do
you
hold
the
same
contention
if
this
was
a
like
a
new
field
in
the
the
front
matter
that
was
like
review
last
call
and
the
status
was
only
draft
and
final.
E
E
I've
just
used
just
adding
a
notes
field
that
gets
removed
at
the
very
end
of
the
process,
so
that
I
can
inform
people
what
the
status
of
the
document
is
yeah,
but
not
as
not
the
official
status,
but
just
things
like
this
is
where
it
is.
These
things
are
still
in
flux.
These
things
are
not
yeah,
some
non-normative
material,
basically.
E
D
So
my
main
desire,
whether
it's
through
statuses
or
something
else,
is
just
that
we
have
a
mechanism
for
authors
to
signal
that
hey.
I
am,
I
think,
I'm
done
with
this.
I
am
ready
for
other
people
to
start
looking
at
it
as
an
editor.
I
have
way
more
work
than
I
have
time
for,
and
so
I
need
a
way
to
filter
out
eips
that
are
not
actually
ready,
like
the
author
is
not
ready
for
me
to
start
looking
at
it
yet
because
they're
still
iterating,
which
we
we
want
to
we've
been
trying
to
encourage.
D
We've
been
trying
to
encourage
two
people
to
get
an
eip
into
draft
quickly
and
then
iterate
on
it,
and
I
need
a
way
for
them
to
be
able
to
tell
me
hey,
I'm
done
iterating.
I
think
I
need
someone
else
to
look
at
this
who's
similar
to
the
ip
process
and
understands
you
know
what
makes
good
idea
and
to
help
me
get
it
improve
it
from
here
and
whether
that's
a
status
or
whether
it's
a
separate
field.
I
care
much
less
about.
I,
just
as
what
I'm
looking
for
personally
is
just
some
signaling
mechanism.
D
That
is
standardized,
so
that's
you
know
tools
like
for
me.
The
tool
is
github
so
when,
when
the
in
the
github
bot,
so
when
the
bot
says
hey
you're,
trying
to
change
the
status,
you
can't
without
an
editor.
That's
my
signal
to
step
in
the
bot
could
of
course,
look
at
anything
any
other
field,
and
that
would
work
just
as
well
as
long
as
I'm
getting
some
signal
that
the
author
is
saying,
I'm
ready
and
that's
that
was
all
my
problem.
E
D
Sorry
so
labels
work
on
pr's
and
issues,
but
you
cannot
label
files,
which
is
what
we
would
need
in
this
case.
E
Okay,
that
was
my
question
so
that
doesn't
work.
It's
just
drafts
vary,
but
they
should
be
ready
for
people
to
look
at
as
soon
as
they're
a
draft,
and
some
people
will
want
to
immediately
start
looking
at
them
and
start
helping
an
author
say
whose
english
isn't
up
to
snuff.
Just
at
that
level
yeah
other
people's
drafts
will
already
be
excellent
in
that
respect
and
ready
for
substantial
discussion.
E
Typically,
the
purely
editorial
work
happens
on
the
pr's
and
the
substantial
discussions
happen
on
the
magicians
and
other
discussion
two
places.
So
I
just
don't
see
that
adding
as
fast
status
really
helps
the
issue
of
people
not
paying
attention
to
things
they
care
about.
You
know
they
will.
They
will
continue
to
not
pay
attention.
D
Yeah,
so
for
me,
I
I
think
I
agree
with
greg
to
a
certain
extent
and
that
I
don't
think
the
statuses
will
help
with
getting
people
to
review
normative
content.
For
me,
it's
it's
purely
just
as
an
editor
like
I
would
like
a
signaling
mechanism.
I
I
agree,
though
I
don't
think
that
anyone
else
is
actually
watching
the
status.
Besides
me,
and
perhaps
some
other
editors
like,
I
think
everybody
else
ignores
it.
D
In
fact,
I
think
people
ignore
it
to
the
point
where,
like
we
have
things
going
into
hard
forks
that
are
still,
you
know,
drafts
that
have
had
zero
edits
done
to
them,
because
you
know
the
author
has
had
no
one
look
at
it
or
no
one.
You
know
review
it,
so
I
think
the
status
is
ignored
by
basically
everybody
right
now,
except
for
me,
and
you
know
other
editors.
E
D
D
There
for
for
me,
be
again
because
I'm
looking
for
automated
signaling
and
right
now,
I
ignore
all
pr's
that
are
auto
merged,
so
any
pr
that
someone
does
to
their
own
eip
gets
auto
merged
by
the
bot,
and
I
immediately
archive
I
don't
even
look
like.
I
do
not
read
it,
because
I
do
not
have
time
to
read
every
single
change
that
everybody
makes
to
their
own
stuff,
and
so
I
wait
until
the
bot
says
hey.
D
E
E
Well,
there's
enough
people
interested
to
keep
these
calls
going
and
I've
said
that
the
only
real
privilege
editors
have
that
other
people
don't
is
write
permissions
on
the
repository.
E
E
E
But
this
this
is
in
my
review
of
the
pr.
So
discussion
can
continue
there.
I
did
notice
that
particular
pr
has
no
discussion
too,
like
so
usually
ppr.
D
That's
probably
true
all
right
go
check
real
quick.
I
don't.
D
F
It
makes
it
harder
to
have
these
discussions
that
one
discussion
two
was
recording
on
this
wall.
B
D
E
E
E
B
B
D
And
what
you
just
described
is
the
current
process.
I
think
the
the
problem
is
by
the
time
someone
moves
to
last
call.
In
my
experience.
They
are
to
a
point
where
they're
no
longer
willing
to
make
changes
like
they're
psychologically,
at
a
place
where
they're
like
I
am
done
with
this,
and
it's
not
getting
changed.
This
is
particularly
for
corey.
Ap
is
not
as
big
of
a
problem.
It's
a
real
big
problem
for
ercs,
where
someone's,
like.
D
Oh
I've,
already
implemented
this
and
there's
17
implementations
out
in
the
wild
on
production
and
we've
been
in
production
for
six
months,
and
now
I'm
moving
to
last
call,
and
so
yeah,
like
the
I
recognize
this
is.
This
doesn't
solve
that
problem
like
of
people
waiting
too
long.
The
hope
is
is
that
it's
a
little
more
clear
to
people.
That
review
is
very
early
in
the
process,
whereas
last
call
is
very
late
in
the
process
right
now.
People
think
last
call
is
very
late,
and
so
they
wait
until
like
they
are
done
done.
D
This
thing
is
out
the
door
already,
I'm
just
formalizing
it,
and
the
hope
is,
I
think,
by
having
it
labeled
review
they'll
instead
think.
Oh,
this
is
a
stage
that's
early
in
the
process.
That
means
I'm
done
iterating,
but
if
so
now
is
a
good
time
to
give
feedback.
I
don't
know
if
that
will
be
successful
in
that
I
don't
know
if
people
actually
pick
that
up
or
not
it's
hard
to
say.
E
Well,
then,
should
review
be
a
major
milestone
rather
than
an
afterthought,
the
author's
happy
with
it.
The
editors
are
happy
with
it.
So
as
far
as
form
yeah,
a
big
announcement
is
actually
made
through
all
the
channels,
and
you
know
sort
of
leave
no
doubt
that
the
community
has
been
informed
that
this
thing
is
under.
D
Review
think
that's
kind
of
the
hope
is
that
by
having
this
review
step
in
the
middle,
that's
not
at
the
very
end,
and
it's
not
the
very
beginning
so
drafts
is
very
beginning.
Last
call
is
basically
the
end,
but
having
the
step
in
the
middle,
it
kind
of
gives
a
a
nice
big
milestone,
like
you
said,
like
a
a
time
that
is
appropriate
to
announce
to
the
world.
Now
is
the
time
to
look.
You
know.
Now
is
the
time
for
everybody
to
start
caring.
D
You
know
before
this,
probably
me
and
my
friend,
you
know
care
and
me
and
my
my
close
colleagues
who
are
working
on
this
together.
Whereas
last
call
is
you
know,
like
I
said
it's
in
production
by
the
time
it's
last
call,
and
so
it'd
be.
E
A
E
D
I'm
more
ambivalent
on
on
that,
whether
it's,
I
guess
the
question
is:
whose
job
is
it
to
announce
an
eip?
If
we
decide
there's
a
milestone
in
the
middle
whose
job
is
it
to
announce?
Is
it
up
to
the
author
to
go
and
outside
everywhere,
or
is
it
up
to
like
they
mark
it
as
review
an
editor
reviews
it
and
make
sure
it's
actually
as
good
and
then
like
cat
herders
announces
it
like
who
who's
in
charge
of
that.
E
A
D
B
E
D
E
That
is
a
hurdle
to
get
over
and
the
world
knows
about,
or
else
it
doesn't
really
serve
a
huge
point,
yeah
the
author's
free
to
make
blog
posts,
and
otherwise
let
the
world
know
hey.
This
is
here
I
really
wanted.
D
Do
the
cat
herders
think
they
might
be
interested
in
that
part
of
it
like
getting
word
out
about
eips
that
have
moved
into
review.
A
A
D
D
Twitter,
maybe
if
we
had
a
place
to
announce
in
discord,
if
that's
where
people
are
hanging
out
for
especially
for
core
eips,
maybe
announce
it
in
all
core
devs
channel
the
first
time
once
it
hits
review.
So
I
got
people
twitter,
all
core
devs,
maybe
maybe
there
are
others
channels,
people
listen
to
is.
D
A
A
A
And
yes,
any
video
about
that
and
when
it
gets
into
review,
is
also
a
very
good
suggestion.
We'll
try
to
get
in
touch
with
others,
especially
for
the
corey
ips,
we'll
try
to
make
an
episode
on
that.
A
So
one
more
topic
that
we
were
discussing
before
many
of
you
joined
is
like.
There
are
a
handful
of
proposals
which
are
there.
They
have
been
reviewed
by
one
of
the
editors,
but
not
many
editors.
Attention
were
there.
So
how
and
like
what
can
be
the
process
in
which
we
can
agree
to
move
those
proposals.
A
I
mean
that
is
being
reviewed
by
one
editor,
but
if
he
has
a
reservations
of
pushing
it
like
merging
it
directly,
how
do
we
handle
this
kind
of
situation?
How
do
we
want
to
keep
it
going
and
not
just
become
a
blocker,
because
we
did
not
get
opinion
from
other
editors
now
that
we
have
three
editors
here
on
the
channel.
So
if
anybody
has
to
share
anything
on
that.
D
This
is
specifically
for
changes
to
eip1
the
readme
evp
template
stuff,
like
that,
when
those
suggest
prs
are
made,
if
one
editor
reviews
it
and
all
the
other
editors
remain
silent
for
say
a
month
or
weeks
or
whatever.
Should
we
take
that
for
a
cent
and
it's
okay
to
merge,
or
should
we
continue
to
try
to
wait
until
we
get
some
sort
of
quorum
of
editors
actually
reading
it.
G
Wait
am
I
muted
sorry.
I
thought
I
was
hardware
muted.
I
think
for
right
now,
like
the
current
time
period,
we
should
take
that
as
approval
and
it
can
get
merged.
However,
the
root
problem
is
not
having
enough
active
editors,
so
if
we
can
tackle
that
as
a
priority-
and
I
apologize-
I
haven't
been
able
to
be
on
the
last
few
calls
so
that
might
have
been
heavily
discussed,
but
that
that
should
make
that
problem
less
of
a
problem.
G
Yes,
achieving
quorum
is
much
easier
when
you
have
people
who
show
up
yeah
exactly
so
solving
that
would
be
nice
and
I'm
I'm
starting
to
brainstorm
and
talk
to
people
about
funding
options
for
editors
to
get
more
incentive.
Since
there's
not
really
an
incentive
to
do
this
other
than
goodwill,
and
you
know
it
takes
time,
so
people
should
get
monetary
reimbursement
for
this.
G
D
Meantime
in
in
the
meantime,
so
if
I
understood
you
correctly
just
I
will
make
sure
I
didn't
misunderstand
in
the
meantime:
until
we
get
more
editors,
you
think
that
it's
reasonable
to
just
like.
If
we
get
one
editor
to
review
a
change
to
like
eip1
or
the
template
or
the
readme
and
everybody
else
remains
quiet
for
some
amount
of
time,
then
we
should
just
go
ahead
and
merge
it
and
that's
okay,
and
if
so,
what's
your
time
frame
ideal
like
a
week
two
weeks
a
month
six
months.
G
Two
weeks
is
the
ideal
time
frame,
and
that
is
my
position,
but
I
don't
hold
it
very
strongly.
I'm
open
to
other
people's
opinions
on
it.
Obviously,.
D
I
mean
the
one
caveat
is
everybody
should
be
aware
of.
Is
that
micah
is
going
to
become
a
benevolent
dictator
or
malevolent
or
to
be
seen
yet
very
soon?
If
we
can
move
forward
with
this,
there's.
F
D
A
dozen
it
doesn't
eip
that
a
dozen
prs
out
there
that
are
changes
to
the
process
or
changes
to
the
template
that
I'm
the
only
reviewer
on
and
as
soon
as
I
have
the
green
light,
I'll
be
merging
them
all.
And
so
I
just
have
been
hesitant
to
give
myself
the
green
light
without
anyone
else
having
to
say.
G
I
personally,
like
the
idea
at
this
point
in
the
eip
editor
life
cycle
history,
whatever
of
having
somewhat
of
a
active,
benevolent
dictator
or
a
group
of
editors
who
were
semi-active
too
active,
who
are
making
all
the
decisions,
because
if
you
look
back
at
the
history
for
a
long
time,
like
the
overhaul
that
I
made
to
eip1
back
in
2017,
I
think
I
just
did
on
my
own
and
merged
it
on
my
own.
So
there's
a
precedent
for
this
that
I'm
comfortable
with
right
now.
G
By
the
way
they
just
launched
the
deposit
contract
for
eth2,
which
is
why
I
was
I
was
having
to
run
around
doing
a
little
bit
of
comms
work
for
that
and
there's
like
a
blog
up
and
spread
the
word
about
the
address.
So
people
don't
use
a
fake
scam.
A
Great,
so
for
the
time
being,
we
consider
that
the
eips
that
have
been
open
for
over
a
month.
I
am
particularly
targeting
this
eip,
that
was
for
eip.
One
number
pr
number,
two,
nine
nine
six
in
which
we
are
trying
to
address
the
recent
status
change
that
can
be
merged
if
there
is
no
further
discussion
on
that,
considering
greg
you,
you
are
here
and
the
concerns
that
you
have
raised.
Can
we
consider
that,
as
a
result
like
what
is
the
consensus?
E
E
A
Yes,
so
the
the
main
difference
that
we
were
trying
to
create
here,
the
draft
and
review
is
like
that.
We
also
announced
in
one
of
the
all
core
dev
meeting
as
a
proposal
gets
into
the
process
of
network
upgrade
at
least
that
should
not
be
considered
in
draft,
because
now
that
is
heavily
under
review,
so
it
makes
sense
to
change
the
status
to
review,
and
that
would
be
like
obvious
for
everyone
that
it
is
under
review.
A
Clients
are
considering,
and
that
will
give
a
clear
signal
that
it
has
moved
from
the
status
of
draft
and
people
can
start
looking
into
it.
So
that
was
the
whole
idea
of
it.
So
if
it
is
not
a
hard
descent,
I
think
it
makes
sense
that
we
can
continue
with
the
process.
The
statuses
that
we
have
decided
earlier
with
the
help
of
this
group
and
go
ahead
and
merge
that.
G
G
Okay,
many
of
us
who
got
here
on
time
besides
me
because
I've
got
the
daylight
savings
time
wrong.
I
have
been
on
for
an
hour
and
a
half.
Do
we
want
to
wrap
it
up?
You
were
not
alone,
there's
like
two
of
us
here
on
time
and
six
that
showed
up
late,
oh
okay,
yeah,
but
I
didn't
want.
I
didn't
want
like
people
to
feel
like
they
have
to
be
here
for
two
whole
hours.
I.
A
So
that
was
like
the
main
item
of
discussion
and
the
number
two
questions
brought
up
on
the
eib
survey.
We
already
have
discussed
it,
so
people
may
find
it
in
the
recording
the
next
question.
The
item
that
we
were
hoping
to
discuss
here
is
about
the
eib
triaging
permission.
Do
we
have
any
progress
on
that
like?
Is
it
still
something
to
be
considered,
and
what
is
the
update
on
that?
A
A
Yeah,
that's
about
the
triaging
permission
for
eaps.
I
think
hudson
likeline.
G
A
So
while
we
have
a
like
good
amount
of
editors
on
the
call,
there
is
another
item
which
was
sometimes
discussed,
but
it
has
never
appeared
as
a
part
of
agenda
item
here
about
the
meta
and
information
in
eip.
G
I
believe
we
should
have
meta
that
serves
a
bit
better
purpose
than
informational,
I'm
indifferent
on
keeping
informational,
because
I
think
it's
not
used
very
much
and
it
I'm
kind
of.
I
think
it
was
micah
or
gregor
both
who
kind
of
said
that
this
is
a
specifications
repository
and
therefore
having
an
informational,
eip
kind
of
throws
a
wrench
into
things.
As
far
as
the
purpose
of
the
entire
you
know,
repo.
D
It's
a
slippery
slope
because
there's
no
clear
line
to
draw,
in
my
opinion,
there's
no
clear
line
for
this
is
acceptable
for
this
repo,
and
this
is
not
because
I've
seen
people
submit
informational
reports
that
are
informational,
eips
they're,
like
hey,
I'm
documenting
my
my
app
in
the
eips
repo
and
it's
informational.
So
that's,
okay
and
I
don't
have
as
an
editor.
I
do
not
have
a
strong
argument
other
than
I
feel
that
it's
not
appropriate
for
this,
and
I'd
rather
have
better
statements
than
I
feel.
E
Yeah
we've
had
those
for
a
while.
We
picked
them
up
from
vip.
I
think
I
think
we
can
just
tighten
down
the
standards
on
those.
E
They
should
still
be
technical
documents,
not
necessarily
specifications
to
build
something
but
technical
documents
offered
for
technical
discussion,
and
it's
not
that
slippery.
A
So
a
recent
addition
in
the
information
category
is
eip2982,
that
is
about
the
serenity
phase
zero
or
that
is
created
by
danuran
and
metallic
butarian.
It
talks
about
what
these
you
know,
this
itam
2.0
phase
zero
is
so
I
personally
feel
that
these
kind
of
information
is
valuable
and
for
that
purposes
we
should
certainly
have
the
informational
eip
in
that
repository
and
yeah.
Of
course,
we
can
do
screening
what
to
be
approved
and
not
approved,
but
that's
general.
My
thought
on
that.
A
A
A
Right
so
in
that
case,
do
we
see
any
more
use
of
meta
eip
there
like
do?
We
still
want
to
have
it,
although
it
explains
the
process,
and
that
was
one.
I
mean
example
that
I
came
across
explaining
of
the
process
and
the
other
one
is
to
keep
the
list
of
eips,
and
if
we
are
containing
the
list
of
eips
in
at
one
dot
or
spec
repository,
do
we
still
see
the
need
of
having
mata
in
eip
depository.
G
G
It's
literally
just
eip1
for
now
and
if
there's
anything
in
the
future,
that
requires
it
like.
If
we
were
to
like
eventually
split
out
ercs
and
eips,
for
instance,
there
might
need
to
be
a
meta
talking
about
that.
Otherwise,
otherwise,
no.
A
A
A
So
there
was
this
another
discussion
of
eip1
before
some
of
you
joined
today
about
having
readme
and
eip1
in
the
same
page
like
do
we
need
to
have
these
two
separately
or
should
be?
Should
we
have
it?
A
D
Before
before
I
move
on
real
quick
is
there,
I
wonder
if
it
would
help
with
the
and
I
don't
want
to
go
too
deep
on
this
rabbit
hole
so
just
know,
I
don't
actually
have
strong
opinion
here.
I
wonder
if
there's
value
in
renaming
the
meta
status,
to
special
just
to
indicate
that
this
is
not
a
status
that
anyone
should
probably
ever
you
know,
go
create
an
eip
with
this
status.
C
D
A
No,
that's
all
right.
That's
that's
really
helpful.
So
I
think
we
should
you
know
when
we
are
having
that
blog.
I
know
edson
has
dropped,
but
we
would
like
to
let
these
points
to
be
included
in
that
blog,
so
that
this
information
should
be
publicly
available
for
people
to
refer,
and
then
the
confusion
around
this
will
be
solved
like.
Should
it
be
meta,
should
it
be
informational
and
others
that's
my
hope.
G
A
Cool
so
yeah,
I
think
most
of
the
items
that
were
added
for
discussion
today
we
have
covered,
and
we
went
a
little
over
time.
Sorry
about
the
confusion
created
with
this
daylight
saving.
This
meeting
eipap
generally
takes
place
at
1500
utc,
and
we
would
like
to
keep
it
that
way.
If,
if
we
do
not
come
across,
like
many
people
saying
that
we
would
want
to
change
it,
but
if
not,
then
the
time
is
1500
utc.
A
C
I
would
like
to
take
a
sec
just
to
review
the
decisions
made.
It
sounds
like
one
decision
made
is
we
will
have
a
review
state
and
the
other
decision
made
was
we're
going
to
convert
meta,
to
be
special
and
and
we're
going
to
have
that
and
all
and
eip1
is
the
only
one
that
has
a
special
state.
Have
those
decisions
been
made.
C
D
More
specifically,
we're
saying
that
if
there
is
a
change
to
the
process
that
is
proposed
via
a
pr
to
the
eips
repo,
the
editors
will
be
tagged
on
it
and
then,
after
two
weeks,
if
none
of
them
have
responded
or
if
the
only
ones
that
have
responded
have
responded
positively,
then
we
will
go
ahead
and
merge
that.
A
D
Really
really
quick
before
you
stop
recording,
since
we
have
hudson
and
greg
here,
they're
speaking
of
micah
as
a
dictator,
there
are
a
few
eips
that
I
personally
am
not
merging,
because
I
disagree
with
them,
but
I
believe
that
I'm
alone
in
not
merging
them,
and
so
we
need
some
other
editor
to
step
in
and
merge
them
like.
We
should.
G
My
github
notifications
are
a
little
out
of
control,
so
I
I'm
happy
we're
just.
G
A
good
place
to
get
a
hold
of
you
discord
or
telegram
either
one
is
equally
fine.
Okay,.
D
Yeah,
I
can
send
them
over
to
you
I'll
have
to
dig
them
up
puja.
You
actually
know
what
they
are,
because
I
think
some
of
them
are
yours,
like
basically
any
informational
and
meta
eip.
I
have
a
I've
been
personally
blocking,
not
not
blocking
just
refusing
to
merge.
My
hope
was
that
some
other
editor
would
step
in
and
merge
because
they
think
those
are
okay
and
I
I
don't,
and
so
they
want
my
personal
opinions
to
be.
You
know
dictator-like,
but
they're
ending
up
that
way.