►
From YouTube: EIPIP Meeting #16
B
C
There's
a
project
board
now,
there's
a
readme
that
describes
it
in
gener,
like
generally
the
principle
and
then
there's
a
project
board
with
the
current
state
of
eips,
going
through
the
network
upgrade
process
which
in
which
up
to
this
point,
is
cfi,
which
we're
we're
proposing
to
change
the
name
of
efi
to
cfi,
which
is
going
from
eligible
for
inclusion
to
considered
for
inclusion
and
then
the
next
step
after
that
is
inclusion
on
a
client
integration
test
net
like
yolo,
v1
or
yolo
v2,
and
that's
the
process.
Up
to
this
point.
B
Great
in
previous
meetings,
we
also
were
discussing
about
the
process
like
how
we
are
going
to
you
know
move
so
this
project
board
that
we
can
see
there
is
actually
what
we
are
coming
up
to.
B
Like
two
or
three
meetings
back,
there
were
a
few
proposals
on
how
this
repository
is
going
to
be
managed
or
what
it
would
be.
The
process
for
network
upgrade,
because
I
guess
we
decided
sometimes
back
that
it
has
to
be.
You
know,
proposed
in
a
form
of
a
proposal
and
add
it
to
eip1
by
by
adding
this
proposal
separately.
So
I
was
just
wondering
if
we
have
anything
decided
on
the
process
part.
Do
we
want
to
discuss
it
now
or
it's
just
good
that
they
go.
D
Ahead
yeah
can
we
discuss
it
now.
Also
an
update,
I
said
the
statuses
on
the
our
whole
devs
call.
There
wasn't
much
feedback.
There
also
wasn't
any
opposition
to
the
new
statuses
james,
you
weren't
here,
but
we
discussed
a
possible
set
of
phases
for
the
hard
four
coordination
process.
D
B
B
Great
just
to
give
you
a
little
background
here,
so
a
few
meetings
back,
there
was
few
proposals.
One
was
presented
by
edson.
One
was
with
me
and
we
come
up
with
some
kind
of
solution
like
we
can
come
up
with
a
combination
of
these
things.
In
absence
of
you,
we
could
not
come
up
to
a
particular
decision.
So
that's
what
we
are
hoping
to
achieve
today.
D
Okay,
so
here
are
the
different
options
that
I
came
up
with
and
the
final
one
we
came
up
with
was
like
a
combination
of
these,
so
this
is
number
five
okay,
so
we
have
them
each
in
stages
stage.
One
is
eligible
stage:
two
is
implementation
stage.
Three
is
testing
stage
four
stage,
so
this
is
stages.
D
It's
the
decision
to
go
to
mainnet
and
then
the
the
date
is
decided
on
where
the
block
is
deciding
them
and
then
stage
five
is
deployed,
the
ap
is
live,
so
the
the
date
has
elapsed
and
the
amp
is
live
stage.
Six
maintenance
review
monitoring
the
ap
after
it's
launched.
I
mean
that
and
seven
is
just
rejected,
which
can
happen
after
after
any
of
these
stages.
D
Yeah,
that's
a
good
question,
so
originally
one
of
them
had
maintenance.
D
E
D
Yeah,
I
think,
like
the
difference
here
was
before
they
were
just
deployed,
and
then
we
never
really
saw
maintenance
before
that
makes
sense
like
we
never
made
that
our
priority,
where
once
it's
deployed,
do
we
keep
monitoring
it
or
not?.
C
A
C
C
C
Let's
go
back
and
look
at
a
decision
and
evaluate
it
would
is
kind
of
an
interesting
thing
for
me
personally,
when
I've
been
putting
the
hard
four
coordination
and
work
together
and
such
I've,
I've
worked
really
hard
to
not
be
prescriptive
about
what
things
might
what
things
will
look
like
later
or
what
things
could
look
like
and
the
the
reasoning
for
that
is
that
hard
four
coordination
is
really
not
like
most
other
software
upgrade
processes
and
the
combination
of
working
with
multiple
clients
for
ethereum,
even
out
even
within
blockchain
ethereum,
has
kind
of
its
own
way
that
that
it
develops
because
of
the
multiple
client
implementations
and
then
the
the
the
breadth
of
node
operators
and
and
community
members
like
they.
C
C
So
for
an
example
is,
and
and
this
the
these
stages
generally
describe
what
is
going
to
happen,
what
what
does
happens
or
what
is
going
to
happen,
but
I
don't
know
if
it's
it's
necessary
to
really
have
it
all
written
out
in
that
section
in
such
a
way
yet
because,
like
for
stage
one,
it's
the
having
an
open
discussion
about
if
it's
gonna
be
available
or
not
and
nine
months
ago,
before
efi
was
thought
of.
C
I
wouldn't
have
told
you
that
that
was
the
best
way
for
us
to
to
track
that
step,
but
it
it
turns
out
to
be
to
work
really
well
and
it
emerged
from
part
of
the
core
dev
calls.
There
was
a
little
bit
of
confusion
about
stuff,
and
so
then
now
we
have
efi
that
came
from
some
other
proposals
and
that
stuck
as
something
that's
working
really
well
and
then
for
stage
two
implementation.
C
I
guess
where
the
next
step
is
for
clients
to
implement
it,
but
we
didn't.
We
were
having
trouble
getting
clients
to
merge
prs
with
the
eips
themselves,
and
there
was
about
two
or
three
months
where
we
were
there.
We
were
in
this
weird
lull
where
we
had
eips
that
were
con
considered
for
inclusion
efi
at
the
time,
but
we
weren't
getting
them
merged
into
clients
in
a
way
that
allowed
us
to
do
testing
between
multiple
clients.
C
So
in
that
in
in
in
that
time,
where,
while
that
was
happening,
martin
and
some
others
thought
hey
this,
you
know
what
would
be
really
great
is
if
we
had
a
test
net
that
was
different
than
any
other
test
net
we've
ever
done,
and
we
make
sure
that
it's
a
test
net
that
no
one
else
is
going
to
deploy
on
and
all
it
does
is
sync
clients,
so
that
clients
have
something
to
work
towards
and
something
to
to
merge
into
their
clients
and
have
everybody
agree
on
what
to
think.
C
This
is
also
around
the
time
where
we
looked
at
the
instead
of
having
make
a
fork
figure
out
what
goes
in
it.
We
did
the
version
where,
as
eips
are
ready,
then
they
are
then
they're
scheduled
to
go
into
a
fork
like
the
train
model,
or
otherwise.
That
has
been
said
so
because
we
had
we
when
we
changed
to
that
model.
There
was
the
moment
of
without
a
deadline,
it's
hard
to
get
people
to
do
stuff
or
without
a
solid
target.
C
So
then
we
went,
we
went
back
and
evaluated
and
then
came
up
with
the
next
stage,
which
is
getting
your
eip
into
a
client
integration
test
net
like
yolo,
so
I'm
sure
that
so
and
then
so
stage
three
testing.
Of
course
we
need
to
have
testing
and
fuzz
testing,
but
what
is
what
is
it?
C
What
does
it
look
like
to
have
finished
that
stage
or
what
does
it
look
like
the
thing
that
we
need
to
do
to
make
sure
that
stage
is
being
done,
hasn't
really
been
established
yet,
and
I
don't
know
what
it
will
be,
but
it
will
be
something
and
then
stage
four
staged
is
when
something
goes
on
to
a
test
net
like
a
more
client
used
or
used
test
net
like
robston
or
whatever.
All
of
those
things.
That's
it.
C
That's
really
part
of
the
staging
process,
but
what's
the
decision
and
timeline
and
stuff
around
that,
I
think
is
yet
to
really
be
established
and
I'd
rather
let
I'd
rather
see
what
happens
with
the
core
devs
and
then
adapt
to
what
is
needed
on
on
that
and
then
stage
five
is
the
hard
fork
is
up
and
it's
and
it's
live.
C
So
I
think
this
does
a
this.
Does
a
great
job
of
highlighting
the
general
path
of
what's
going
to
happen,
but
I
wouldn't
I
wouldn't
like
to
specify
how
we
get
from
each
of
those
stages
and
what
it
needs
to
be
to
to
go
from
each
of
those
stages
until
we
are
going
through
them
and
observe
and
figure
out
which
are
the
best,
which
is
the
best
way
to
work
as
things.
G
B
I
I
can
also
see
a
table
here
like
the
project
board.
Is
it
reasonable
to
consider
that
maybe
the
stages
I'm
talking
about
the
project
board
that
is
available
on
the
ethereum
1.0
spec?
It
says
that
see
if
I
applied
approved
test
net
applied,
is
it
something
that
can
be
considered
as
stages
for
network
upgrade
and
that's
what
we
can
go
ahead
with.
C
Yeah
because
that
so
that
is
stage
one
a
and
stage
one
b
and
then
stage
two
a
and
stage
two
b
in
this
in
this
list
that
that
edson
has
here
and
the
reason
why
I
had
both
is
because
we
have
discussions
like
their
people,
propose
that
it
goes
from
one
stage
to
another,
and
then
it's
in
that
stage,
and
then
people
propose
that
it
goes
from
one
stage
to
the
next
and
it
made
sense
to
track
them
where
as
being
proposed
and
accepted
into
each
of
those
buckets.
B
Right
so
from
the
point
of
view
of
documentation,
is
it
do
we
really
need
to
document
it?
I
mean
like
in
the
in
one
of
the
previous
meetings.
There
was
this
document
shared
by
me.
I
mean
I
shared
it
in
which
we
tried
to
document
as
similar
to
the
eip1,
but
since
we
are
making
a
new
upgrade
process
for
a
network
upgrade,
it
was
just
for
the
other
one,
the
new
one.
B
Thank
you
edson.
So
here
we
have
actually
tried
to
document
the
process
or
how
we
are
doing
it
in
a
form
of
a
proposal
that
can
be
added
as
a
pull
request
to
the
new
repository
and
can
be
saved
as
a
reference
point.
Is
it
something
that
we
still
need,
or
we
are
good
with.
C
B
C
B
C
Yeah,
so
if
there
are
things
to
be
included
on
this
or
thoughts
for
stuff,
that
needs
to
be
included
so,
like
some
ideas
is
what
is
the
specification
of
mainnet?
Do
we
put
that
on
there
having
the
specification
for
yolo
putting
this?
Do
we
put
that
on
here
or
any
other
ideas
that
you
guys
have
for
free
to
propose
and
we
should
discuss.
B
Right
and
in
the
issues
section,
I
see
that
there
is
an
issue
already
created
for
discussion
on
efi
to
cfi.
Do
we
have
right
set
of
people
where
we
can
discuss
about
it?.
F
B
C
B
C
Yeah,
so
I
I'd
say
that
we
take
hudson
edson's
list
with
the
stages
and
we
can
put
them
into
the
readme
and
then
leave
off
specifying
exactly
what
or
how
that
the
each
stage
transition
is
defined
and
then
we'll
go
back
and
update
them
as
they're
they're
happening.
C
To
to
write
that,
as
that
is
the
rough
path
that
is
going
to
happen,
but
not
say
exactly,
how
like
by
implementation,
is
a
is
a
the
number
two
is
is
the
rough
path
is
the
path
that
an
eip
will
go
through.
It
has
to
go
through
implementation.
D
C
D
I'm
sorry,
I
guess
there's
a
stage
called
implementation,
so
we
we
just.
We
use
these
stages
right
like
officially,
but
we
don't.
We
we
go
through
them
to
see
how
how
it
works
going
through
each
of
them.
C
Yeah,
I
wouldn't
even
know
if
I
would
say
we
use
them
as
efficiently,
but
more
of
as
a
as
a
guiding
post
for
stuff.
That
will
probably
happen.
Okay,
like
the
consider
for
like
implementation,
the
yolo
stuff
is
the
stuff
that
you
track
and
have
for
the
stages
for
implementation.
C
Like
the
sub
stages,
I
don't
know,
I
guess
it
might
be
confusing
too
I'm
torn
between
the
giving
people
an
idea
of
what's
going
to
happen
and
me
or
or
just
what's
the
word
like
manufacturing,
a
process
that
it
doesn't
naturally
fit
when
there's
stuff
that
will-
and
we
just
don't
know
what
it
is
yet.
D
C
D
Okay,
also,
I
guess
like,
since
we
have
enough,
we
could
update
eap
one.
C
I
would
say
we
update
eip1
to
just
point
to
the
spec
repo
at
this
point
and
not
have
any
specification
of
the
network
upgrade
be
inside
of
it.
Yet
I.
E
Feel
like
that
pointer
is
wrong
direction.
I
think
network
specification
is
quite
dip.
Is
not
the
other
way
around
like
to
me.
The
eip
is
a
a
primitive
that
can
be
referenced
by
other
things.
It
is
not
a
high
level
construct
like
fair.
E
In
my
opinion,
the
efps
are
technical
specifications
only
they
have
no
politics,
there's
no
opinions.
It's
just.
This
is
a
technical
spec
for
a
thing
that
someone
thought
was
a
good
idea
and
then
the
network
upgrade
process
could
then
point
to
those
and
say
hey.
This
is
the
technical
spec
that
we'll
be
implementing
on
this
date
or
whatever,
but
having
eips
point
to
the
inclusion
process,
which
is
much
more
political
feels
to
me
like
the
wrong
direction
for
that
pointer.
E
F
F
C
E
Sure,
I
guess
for
me
that's
more
appropriate.
E
Than
the
ip1
like
to
me,
eip1
defines
this
is
how
you
write
a
spec,
whereas
the
readme
is
more
like
this
is
how
you,
how
ethereum
works
and
how
we
use
this
repo,
but
I
wouldn't
be.
I
wouldn't
push
back
hard
against
that
mta
if
you
want,
if
it
was
just
like
you
mentioned,
I.
C
Think
yeah
I'd
be
fine
with
either
of
those
it's
the
I
I
want
to
be
able
to
if
someone's
at
the
eip
repo
and
thinks
how
do
I
find
the
main?
How
do
I
find
the
upgrade
process?
I
want
them
to
be
able
to
find
the
right
repository.
So
if
that's
the
readme
or
if
that's
the
ip1
or
whatever
it's
less
than
I.
E
Think
I
think
the
thing
that,
like
lion's
bringing
up
and
the
point
of
disagreement
between
us
on
that
is,
is
the
eips
repo
specifically
for
ethereum
mainnet,
or
does
it
also
include
ethereum,
classic
and
rsk,
and
all
these
other
things
that
reference,
the
eip's
repo?
E
I
don't
know
if
that's
actually
on
our
agenda,
though
we
have
been
off
and
on
talking
about
it
for
a
while.
F
C
D
I
see
I
see
micah's
point,
though,
that
if
a
specification
is
a
specification,
it
can
be
used
by
other
protocols,
segregated
protocol
agnostic.
If
it's
well
defined,
like
erc
several
other
pro,
like
several
other
chains,
have
their
version
of
erc
now,
because
it
was
just
defined
well
and
used
enough
in
ethereum.
C
Yeah
we
had,
we
talked
about
it
earlier,
as
even
just
having
a
on
the
eip
website,
like
eips.ethereum.org,
have
a
tag
that
track
that
shows
up
on
eips
that
are
implemented
in
mainnet.
But
what
is
implemented
in
mainnet
is
tracked
in
the
network.
1.0
specs,
not
in
some
meta-empty
or
as
or
as
like,
explicitly
even
needs
to
be
a
field,
but
some
some
way
of
of
doing
that.
F
B
G
B
Just
one
point
I
would
like
to
mention
here
that
came
up
yesterday
during
a
conversation
with
greg
on
the
eip
repo
like
since
we
are
trying
to
separate
this
network
upgrade
and
other
proposals
there.
So
he
was
just
mentioning
it
like.
It
was
a
casual
conversation
where
we
were
thinking
about
like
should
it
be
called
as
eips,
because
we
are
taking
out
all
the
core
eips
and
taking
it
to
network
repository.
B
C
I
can
respond
quickly
that
the
it
sounds
to
me
that
greg
is
thinking
that
eips
are
going
to
be
moving
over
to
the
network
spec
repository,
but
that's
not
there.
There
won't
be
any
eips
in
the
network
spec
repository.
C
B
C
So
they're
they're
there
isn't
anything
there
isn't
anything
of
that
type.
That's
moving
over.
E
My
fear,
with
adding
anything
about
the
network
upgrade
process
to
a
vips.
Is
it
will
encourage
people
to
come
over
to
the
ph
repository
and
debate
politics
on
whether
we
should
include
something
or
not,
and
I
really
would
love
to
see
that
all
go
away
and
by
go
away
I
mean
become
someone
else's
problem,
which
means
whatever
manages.
E
E
Like
we
have
it's,
a
really
big
problem
with
eips
is
we're
trying
to
define
a
technical
spec,
and
we
end
up
with
just
like
a
bunch
of
people
talking
about
whether
this
is
a
good
idea
or
not,
and
I
would
love
to
make
it
so
we
can
just
tell
them
hey.
This
is
where
we're
discussing
the
technical
specification
which
may
or
may
not
go
into
ethereum
may
or
may
not
go
into
any
other
network.
It's
just
a
technical
spec.
E
C
Yeah-
and
I
and
I've
seen
similar
interesting
things
about
where
we're
talking
about
a
specification,
but
then
we're
really
talking
about
what
it
would
need
to
be
able
to
launch
on
the
main
net,
but
that's
not
something
that
needed
to
be
talked
about
at
that
stage
or
focused
on
so
makes
it
difficult.
C
I
saw
I
remember
what
I
was
going
to
say
that
I
do
think
we're
at
the
stage
where
we're
ready
to
start
the
new
ta,
the
new
processes
for
the
eip,
statuses
and
migrate,
yeah
and
migrate.
The
eip
repo
to
the
new
ones.
B
C
E
Here,
if
you're,
according
to
like
there's
a
document
floating
around
somewhere,
that
has
them
like
withdrawn
and
stuff.
C
B
D
Yeah,
I
just
want
to
comment
on
the
repository.
It
looks
like
people
already
using
that
to
have
their
eap
considered
for
inclusion,
which
is
good
that
the
discussion
is
being
moved
here
and
I
guess
like
we
could
make
as
many
issues
as
we
want.
So
we
can
actually
have
discussion
here.
C
Yep
yeah
and
feel
free
to
make
issues
to
for
like
things
you
want
to
see
in
the
repository
or
stuff,
you
think
we
should
we
should
be
considering.
C
B
So,
moving
on
to
the
next
item,
it
is
a
relative
versus
absolute
path.
There
is
a
link
in
the
agenda
and
that
leads
to
some
comments
by
micah.
So
micah,
would
you
like
to
take
it
over.
E
Sure,
I
think,
just
to
start
out
is
anybody
opposed
to
relative
paths.
Everybody
I've
talked
to
so
far
seems
for
a
relative
past
and
I
think
it's
just
a
matter
of.
We
need
to
do
it,
but
I
want
to
first
see
if
there's
anyone
opposed
is
just.
We
want
to
standardize
how
links
are
handled
and
the
question
is:
do
we
do
dot
slash
eip,
dash
one
dot
md
or
do
we
do
https
call
slash,
slash,
eips.ethereum.org,
slash
eip,
slash,
emp
dash
one?
Is
anyone.
E
Relative,
if,
if
not,
we
can
just
skip
this
whole
topic
and
just
do
it.
If
someone
is,
we
can
have
a
more
fruitful
discussion.
C
It's
so
that's
something
that
per
that
falls
to
the
purview
of
vip
editors,
more
that
more
so
than
other
topics
that
we
bring
up.
So
just
do
it.
We.
E
E
B
C
B
Right
for
people
who
could
not
attend
there
is
next
breakout
meeting
on
september
14th
at
1400
utc
and
the
eips
that
were
not
that
we
could
not
discuss
in
the
previous
meeting
would
be
continued
to
bid.
E
E
With
it,
I
do,
I
do
think
the
breakout
rooms
for
or
breakout
sessions
for
specific
topics
are
better
than
generalized
ones,
because
you're
more
likely
to
get
people
to
show
up
if
you're
talking
about
one
thing,
whereas
if
you
say
we're
gonna
talk
about
what
they
send
things
and
it's
hard
to
get
people
to
dedicate
time.
B
And
in
the
next
meeting,
along
with
2018,
we
would
be
discussing
about
29.35
for
the
consideration
in
yellow.
But
I'm
not
sure
if
people
add
further
in
the
agenda
that
is
available
in
ethereum
pm.
B
Moving
on
the
next
item
is
eip
triaging
permissions.
B
As
far
as
I
remember
light,
client
and
hudson
were
working
on
it.
Do
we
have
any
update
on
that.
A
F
H
F
B
I
have
a
question
here
related
to
you
know
not
related
to
the
permission
but
related
to
some
recent
bot
changes.
I
see
that
the
bot
is
now
able
to
figure
out
what
are
stale.
What
are
the
processes
I'm
going
to
share
a
link
in
the
chat,
and
with
that
we
could
see
all
the
eaps
that
are
still
is
anybody
here
that
may
be
able
to
explain
more
about
it?
This
new
process
on
this
new
bot.
E
Sure
it's
a
just
a
simple
github
action
that
if
a
pr
hasn't
been
commented
on
for
60
days
or
more
then
currently,
then
it
will
get
the
stale
tag
and
the
bot
will
comment
on
it.
Saying
hey!
This
is
mathematically.
If
you
don't
do
anything
and
then
I
think
as
soon
as
anyone
comments
on
that
pr,
then
the
stale
tag
is
removed
and
the
timer
starts
over.
If
pr
has
a
stale
tag
for
more
than
a
week,
then
it
will
be
closed
automatically
by
the
bot.
E
B
C
H
B
D
Let
me
pull
that
up
real
quick.
We
only
got
three
responses
from
eap
editors.
I
can
go
over
the
generally
what
they,
what
they're.
D
Saying
so
the
time
commitment
for
new
year
fitters
per
week,
it's
about
five
hours
per
week
to
zero
hours
per
week
in
that
range,
the
tasks
that
are
expected
to
do
make
sure
the
eaps
are
formatted.
D
Their
technically
completes
working
with
authors
to
get
new
eips
into
the
repo
looking
at
grammar
structure,
the
meaning,
if
it's
related
to
ethereum
and
looking
at
the
auto
merger
bot.
If
in
cases
it
doesn't
handle
it
good
requirements
for
someone
to
become
an
eap
editor
is
to
sh,
already
be
helping.
D
So
anyone
could
review
eaps
editors
are
only
needed
to
merge
and
someone
that
understands
the
difference
between
a
standard
and
a
good
idea,
someone
that
understands
the
content
that
should
go
into
standard
and
someone
who's
a
good
communicator
and
understands
ethereum,
at
least
into
an
intermediate
level
level
and
can
handle
contentious
discourse
and
understands
github.
B
Great
so
by
this
just
one
point:
I
want
to
mention
it
again
like
by
the
task
that
has
been
suggested
by
the
eip
editors.
They
want
to
focus
it
on
if
it
is
ethereum
related.
I
don't
know
if
it
brings
back
to
our
conversation
that
we
had
sometimes
back
on,
like
what
would
be
the
eib
repository
should
be,
for
maybe
I'm
not
sure.
Maybe
we
could
have
it
a
separate
agenda
item
in
one
of
the
future
meetings
and
then
would
like
to
discuss.
E
It
would
be
nice
to
settle
that.
It's
been
ongoing
when
discussion,
not
just
between,
like
my
client
and
I,
for
the
one
currently
having,
but
also
like
the
other
day,
someone
put
in
something
to
the
ips
repo,
which
was
a
specification
for
a
new
cryptographic,
primitive
which,
like
is
very
general,
that's
like
something
you
would
submit
as
an
rfc
to
some
other
standardized
body,
but
they
chose
the
ethereum.
E
Repo
is
ethereum
the
ip's
repo
the
right
place
for
that
like
yes,
ethereum
may
use
that
cryptographic
primitive
at
some
point,
but
there
are
definitely
better
places,
in
my
opinion,
to
get
feedback
on
like
cryptography
stuff
than
the
ips
repo.
So
I
think
answering
what
is
the
scope
of
the
ap's
repo
cover?
Does
it
cover
just
ethereum
and
stuff?
That's
going
into
ethereum.
E
A
All
right,
I
have
a
quick
update
about
the
triage
permission
that
we
were
just
talking
about.
It
turns
out
your
are:
we
have
a
legacy
github
organization
at
the
ethereum
organization
in
github,
and
we
would
need
to
upgrade
it
which
would
incur
cost
in
order
to
get
the
triage
permission.
A
F
F
A
A
paid
feature:
it's
that
there
is,
there,
was
a
when
microsoft
got
github.
They
had
this
thing
so,
instead
of
it
being
github
paid,
github
paid
accounts
per
repository,
it's
now
paid
per
user
and
there's
different
names
like
enterprise
and
team
and
stuff,
and
but
the
old
one
is
just
like
github
business
or
github
paid,
or
something
like
that,
and
that's
the
one
we're
on
the
new
stuff
has
new
features,
whether
it's
free
or
paid
so
because
this
is
a
paid
account
in
general.
A
F
B
B
So
the
next
item
here
is
clarification
of
how
a
pre-compile
address
is
decided.
I
think
this
is
something
james
was
looking
into,
for
which
part
item
number
six.
There
is
a
link
in
the
agenda.
A
A
A
C
B
Okay,
maybe
like
in
past
a
few
meetings,
we
could
not
answer
that
or
I
just
somehow
met
yeah.
A
I
think
it
was
just
because
james
wasn't
here
to
answer,
and
it
was
his
comment
in
the
thread
that
was
probably
it
yeah.
B
In
fact,
I
may
have
something
I
somehow
came
across
a
list,
not
a
list,
a
document.
I
think
it
is
originally
made
by
alex
exec
that
talks
about
some
of
the
problems
with
eip.
I'm
not
sure
if
people
would
want
to
have
this
in
some
of
the
future
meetings,
because
I
find
these
are
related
to
the
process
and
that
that
the
group
is
working
towards.
A
B
A
B
B
C
I
had
any
thoughts
on
if
we're
ready
to
start
migrating
eip1
to
having
the
new
statuses
we
discussed
previously.
B
So
I
think
pierre
would
be
required,
I'm
not
sure
gmc
would
be
taking
care
of
that.
E
C
Yeah
we
my
so
I
read
through
his
comment
and
we
we
have
discussed
this
previously
in
march
quite
a
bit,
but
I
we
had.
We
also
had
this
discussion
on
eip
calls
over
us
over
a
couple
sessions
of
calls,
and
I
I
and
I
feel
like
we
decided
on
having
those
both
having
the
withdrawn
and
the
abandoned,
and
we
went
through
a
lot
of
the
reasons
why
and
debated
them
back
and
forth
pretty
a
lot.
E
C
B
So
how
about
like
about
the
implementation
of
a
statuses
like
we
should
take
it
as
one
of
the
decision
item
here
and
we
already
have
proposed
in
the
all-coordinate
meeting.
We
did
not
see
any
you
know
over
my
dead
body.
Kind
of
opposition
are
not
the
not
so
welcoming
comment
on
that.
So,
let's
start
working
on
it.
Let's
keep
it
as
a
part
of
decision
item
for
now
and
as
we
go
on
populating
the
new
network
repository
we'll
make
a
pull
request
to
eip1,
adding
those
statuses.
C
B
Repo
yeah,
we
can
do
that
too,
but
I
would
be
happy
if
we
can
also
add
the
network
repository
there
in
this
pull
request.
B
Oh,
no,
I'm
proposing
that,
as
we
discussed
a
few
meetings
back
like
when
we
are
adding
something
to
the
eip1,
we
try
to
make
it
with
new
statuses.
Eip
statuses
should
be
there.
That's
number
one
and
number
two
we
wanted
to
add
about
the
network
upgrade
repository
now
that
we
have
repository
and
it
has
actually
I
mean
people
have
actually
started
populating
it.
So
my
suggestion
was:
let's
have
both
of
them
getting
into
one
pull
request.
C
I
would
I
would
just
do
the
eip
statuses
and
then
I'm
I
actually
like
micah's
feedback
of,
should
it
be
in
a
read
b
or
should
it
be
any
ip1?
I
think
it's
good
to
consider
and
I
wouldn't
want
to
get
the
conversation
muddled
between
the
two
of
them
by
having
them
both
in
the
same
pr.
E
A
either
one
of
those
read
me
or
everyone.
B
Okay,
that's
fine.
B
Any
just
so
we
don't
get.
D
B
C
H
B
Okay,
the
last
item
here
is
and
not
the
item.
It's
actually
the
review
thing
about
the
previous
meeting,
so
I
am
going
by
the
decisions
made
in
the
last
meeting.
The
first
one
is
bring
up
eap,
repository
scope
and
triaging
permission
in
the
next
meeting.
We
discussed
it
today
number
two
discuss
eip
repository
scope
and
triaging
permission
for
if
the
hard
fork
coordinator
is
available,
I
think
it's
repeated,
so
it's
both
both
of
the
same
thing
and
we
did
discuss
it
today.
B
B
E
B
Right,
the
initial
idea
was
to
collect
the
feedback
from
the
editors
and
based
on
that,
we
are
going
to
define
the
scope
timeline.
I
mean
the
number
of
hours
required
and
maybe
time
try
to
come
up
with
a
document
which,
which
can
be
referred
as
a
base
document.
Whenever
we
we
want
to
onboard
any
more
new
editors,
so
I'm
not
sure
just
checking
with
you
first
edson,
because
you
have
the
feedback.
Is
it
something
that
you
would
like
to
take
on.
B
The
document
on
onboarding
process
like
for
defining
this
scope,
the
duties
in
what
condition
an
editor
can
be
onboarded
and
when
what,
if
they
want
they
want
to,
or
the
the
group
decided
that
they
have
to
be
removed
from
the
position.
Something
like
that.
Would
you
like
to
come
up
with
a
document.
B
B
Thank
you,
everyone
for
joining
us
today
and
see
you
in
two
weeks.
The
next
call
is
in
on
september,
23rd
at
1500
utc.
Thank
you
have
a
good
day.