►
From YouTube: EIPIP Meeting #13
B
B
B
C
Yeah,
so
it's
something
that
we
started
with
statuses
separating
the
network
upgrade
process.
We
never
actually
finished
it
before
we
started
talking
about
onboarding
and
updating
the
ap
template.
C
One
thing
I
wanted
to
suggest
for
writing
out
a
new
process
is
oh,
like
one
one
method
for
creating
solutions
which
is
there's
two
parts
in
creating
a
solution.
C
So
you
have
the
idea,
and
then
you
evaluate
that
idea,
something
that
we
can
do
something
that's
used
in
creative
process
is
creating
multiple
different
solutions
before
the
call
and
then
just
having
so
for
like
for
the
hard
work
process,
it
would
be
multiple
different
ways
that
hard
fork
coordination
could
happen
and
then,
once
we
have
a
selection
of
things
to
choose
from,
we
can
evaluate
them
and
then
break
it
apart
and
see
what
works
and
what
and
maybe
deconstruct
and
combine
solutions
to
have
a
better
solution
that
we
would
have
gotten
had
we
just
gone
with
the
first
thing
we
thought
of.
C
So
the
process
is
pretty
simple:
it's
just.
Instead
of
just
creating
one
solution,
we
create,
say,
10
different
processes.
We
can
choose
from
quickly
present
them
on
the
call
and
then,
as
a
group,
evaluate
them.
If
that
makes
sense,
to
create
one
process
that
we
can
decide
on.
B
The
has
anyone
I've
had
I've
had
one.
In
my
mind,
I've
been,
I
just
need
to
write
down,
but
I
I
mean
I
feel
like
it
would
be
better
if
there
was
more
contribution
than
just
myself.
Is
there
others
that
are
interested
in
writing
out
a
a
like?
If
we,
if,
let's
say
we
scheduled
for
doing
it
for
the
next
eipfp
meeting,
is
there
are
some
other
people
that
want
to
draft
even
just
roughed
ideas
on
how
it
works
together,
I
can
draft
a
few
sweet.
B
B
Sweet
the
I
have
it
makes
sense
to
me
a
couple
of
things
I
would
propose
in
this
when
talking
about
the
network.
Upping
process
is
that
we
release
it
before
we
do.
The
eip
changes
the
eip
status
changes
and
that
it
be
its
own,
separate
eip,
which
I
think
we've
talked
about
before.
That's
just
has
cemented
more
on
my
and
recently,
but
that's
a
good
direction.
B
Because
the
if
we
remove
the
hard
four
coordination
part
from
the
eip
process
and
then
like
accept,
it
is
no
longer
a
status,
then
there's
a
huge
opportunity,
there's
an
opportunity
for
un
or
backlash
from
the
community,
because
there
isn't
there's
like
oh
well.
How
do
things
get
put
into
maintenance?
B
And
so
I
think
it
would
be
easier
to
have
that
defined
somewhat.
Even
if
it's
not
fully
defined,
I
don't
think
we
want
to
define
it
all
out,
but
we
should
at
least
have
an
eip
that
we
can
point
to
people
saying
oh
yeah.
Well,
we
separated
it,
and
here
is
the
proposal
for
the
other
part,
not
just
we
separated
it
and
nothing
is,
and
there
isn't
anything
for
the
okay.
A
I
think
that
sounds
really
good.
I
think
the
separation
is
needed,
and
I
also
think
that
which
we've
discussed
before,
obviously
and
kind
of
everyone
kind
of
agreed
that
there
needs
to
be
a
separation,
but
also
having
it
explicit
once
we
make
the
changes,
even
if
it's
in
its
infancy,
like
just
like
a
basic
form,
is
important.
D
D
If
we
have
an
additional
you
that
describes
what
the
network
upgrade
process
is
how
it's
not
tied
to
the
roles
of
the
editors
and
the
repositories
and
that
just
becomes
sort
of
like
a
bookkeeping
duty
for
the
editors
to
change
an
ep
status
to
state-of-the-art
mainnet.
Once
it's
like,
it's
actually
included
in
the
hard
fork.
D
A
C
Looking
at
other,
like
smart
contract
platforms,
they
actually
do
use
the
eap
repo,
but
they
use
like
erc's,
so
they
use
like
they
have
their
version
of
erc20,
that's
based
on
the
eip20,
and
then
they
have
their
version
of
non-fungible
tokens
that
was
taken
from
the
ap
repo.
But
as
far
as
standards
go.
Usually
standards
are
platform,
agnostic,
just
in
other
industries,
and
they
exist
there
to
be
kind
of
like
you
know,
like
experiments
exist,
and
then
you
can
reproduce
them
it's
kind
of
similar
to
standards.
D
It's
difficult
with
ethereum:
this
is
a
different,
very
different
paradigm.
If
I
have
an
upgrade
for
tcp,
then
we
can
still
negotiate
our
protocol
using
like
an
older
version
of
tcp,
potentially
where,
with
ethereum
once
we
make
a
network
upgrade.
Everyone
is
on
this.
There's,
no
way
that
I
can
say
I'm
using
this
old
version
of
ethereum,
that's
just
a
complete
different
fork
of
it,
and
so
I
I
feel
like
that
should
be
represented
within
the
process.
C
One
thing
we
we
can
do
say
we
define
the
network
operating
process
because
currently
we
don't
exactly
know
what
it'll
end
up
being.
We
could
just
create
a
new
header
that
tracks
that,
as
a
compromise
that
way,
it
doesn't
have
to
be
tracked
manually.
It
could
be
tracked.
C
I
mean,
obviously
you
have
to
manually
edit,
the
header,
but
you
we
could
have
another
section
in
the
eip
website
that
just
tracks
mainnet
and
that
would
simplify
it
for
people
who
are
trying
to
create
a
new
client,
so
they
have
somewhere
to
look
at
in
addition
to
the
yellow
paper.
A
The
only
thing
is
light
client
made
the
point
that
the
that
there
would
be
overhead
for
editors
to
go
in
and
merge
those
changes
all
the
time.
So
I
think
that
a
good
in
between
would
be
having
those
hard
fork
processes
as
separate
eips,
but
have
them
be
an
active
status.
So
what
that
means
is
there
never
needs
to
be
editor
input
in
order
for
it
to
be
merged,
an
active
eip
can
continually
be
edited
and
merged
without
consent
of
the
editors
is
how
we
can
change.
A
We
is
how
we
can
frame
it
right
now,
an
active
eip.
That's
not
the
case
because,
like
I
think
for
an
example,
I
think
eip1
is
an
active
vip
like
that's
the
status,
but
if
we
make
it
so
that
we
can
just
have
these
active
eips
be
able
to
be
changed
whenever,
except
for
eip1.
I
think
that
would
be
okay.
C
So
I
actually
we
had
already
proposed
that
so
I
think
efi
we're
going
to
make
active,
but
well
my
client
was
saying
we
should
just
have
the
status
instead
of
creating
a
new
ap.
Oh,
I
see.
B
I
mean
if
we
so
the
like
black
client
that
talked
about
how
we
could
make
a
permissions,
that
there
are
there's
a
group
that
could
do
tags
and
edit
tags
if
we
could
make
it
so
there's
a
group
that
would
be
able
to
edit
that
field
that
isn't
the
eip
editors.
So
so
it
so
it.
If
it's
bookkeeping,
then
we
can
have
permissions
for
bookkeepers
that
aren't
eip
editors.
D
I
feel
like
the
overhead
on
editors
is
pretty
small.
I
mean
we're
not
doing
that
work
upgrades
that
often
and
there's
really
not
that
many
use
that
go
into
it
should
be
pretty
quick
for
them
to
see.
Okay,
this
this
is
mainnet.
This
was
included
in
the
hard
fork.
Yes,
we're
going
to
update
the
status
for
that.
D
D
D
D
E
So
if
I
may
break
this
question
into
two
parts
like
there
is
one
part
about
active
status,
another
part
is
about
efi.
We
are
talking
about
efi
e
in
order
to
be
in
the
active
status.
So
I
believe
that
for
active
status,
we
are
clear
that
it
is
required
not
only
for
efie
but
for
the
eip1
and
possibly
we
would
have
a
couple
of
more
eeps
that
that
may
require
this
kind
of
a
status
and
for
efi
the
registry.
C
I
think
like
something
to
consider
with
the
efi.
If
it
isn't
active,
is
it
it
won't
actually
track
what's
deployed.
What
will
track
what's
deployed
is
an
eap
that
is
a
hard
fork
eip,
where
it
tracks
the
hard
work
names
like
mere
glacier.
What
eips
are
included
so
berlin,
eap,
bls,
is
included.
It
has
a
list
of
eaps
so
that
that
will
be
its
own
eap,
which
you
can
look
up
and
see.
C
What's
I
guess,
what's
canon
to
ethereum,
what's
in
mainnet
and
then
efi
would
just
be
tracking,
what's
currently
being
discussed,
so
things
might
go
into
efi
and
things
may
leave
efi.
Does
that
make
sense.
E
Right,
whatever
goes
under
the
main
net
deployment
that
is
separately
listed
in
the
hard
fork
meta
for
that
upgrade,
but
the
eaps
that
are
currently
under
consideration.
We
do
not
have
any
specific
place
to
kind
of
list.
Those
eips
which
may
or
may
not
be
going
into
the
heart
for.
B
B
F
A
B
Yeah
and
I
could
be
a
like-
I'm
hesitant
to
be
an
eip
editor
because
I
feel
like
that's
kind
of
a
conflict
of
interest
or
something
I
don't
know
like
having
having.
If
I'm,
if
I'm
doing
the
network
upgrade
process,
I
shouldn't
also
be
over
the
eip
process.
So
then
it
would
be
really
easy
for
me
just
to
get
started
working
on
the
network
upgrade
stuff
and
be
it
be
an
admin
there,
but
not
in
the
eip
part.
So
there's
separation.
A
Yeah
I
like
that
idea.
I
anyone
else
have
comments
on
that.
I
think
chloe
had
something
on
the
chat.
A
Stay
active
would
that
satisfy
both
issues.
Oh
yeah,
I
think
that's
that's
similar
to
what
we're
talking
about.
We
could
have
it
as
a
subsection
of
the
eip
repo,
but
I
guess
the
one
issue
there
would
be.
We
would
have
to
give
different
github
level
permissions
to
james.
That
would
allow
him
to
potentially
mess
with
other
stuff,
not
that
we
don't
trust
james,
but
he
could
get
malicious
suddenly
and
mess
with
other
stuff.
A
B
B
A
B
So
yeah
for
the
next
item-
onboarding
eip
editors
survey
to
and
we've
got
about,
30
minutes.
So
I'll
move
through
some
of
these
a
little
bit
faster
survey
to
set
expectations
of
an
eip
editor
triaging
permissions.
C
I
created
a
survey.
Let
me
bring
it
up.
C
If
I
should
add
or
remove
anything
before
I
send
it
out,
do
you
want
to
go
through
it
right
now
or
just
have
us
read
through
it?
I
sent
it.
I
put
a
link.
I
asked
what
tasks
are
expected
of
an
eip
editor.
C
What
is
a
good
requirement
for
someone
to
become
an
eip
editor?
Do
you
have
any
recommendations
for
new
eap
editors.
F
E
Yeah
and
maybe
a
couple
of
more
specific,
a
couple
of
more
specific
tasks,
like
you
know,
questions
maybe
like
in
what
circumstances
like
we,
we
are
trying
to
collect
information
about
when
we
can
on
board,
I
mean
like
when
who
and
how
these
three
things
so
like.
If,
if
certain
criterias
are
met,
we
can
onboard
that
people
and
what
are
those
criterias?
We
need
to
define
that
and
we
also
need
to
define
when
I
mean
like
in
in
cases
when
we
have
to
like
remove
any
editor.
E
So
what
can
be
those
circumstances
if
we
can
get
this
information
as
well
and
how
is
like,
like
if
we
can,
like
I
mentioned
in
the
previous
meeting,
also
james
added,
that
there
should
be
availability
for
meetings
like
quarterly
or
monthly
or
whatever
number
of
hours
per
month
or
per
week
or
some
general
guideline
that
would
be
in
my
mind,
would
be
helpful
and
like
making
it
more.
E
A
Oh
actually
hold
on,
I
had
one
and
I
just
lost
it.
This
is
okay,
the
the
onboarding
survey.
What
did
I
have
in
mind
I'll
tell
it
to
you
later
ed
sent
it.
I
lost
it.
G
So
I
think
never
mind
no,
this.
I
think
that
I
think
it
covers
everything
that
was
discussed
last
session
really
well.
B
E
So
the
triaging
permission
here
I
added
coming
from
the
previous
meeting,
where
we
discussed
that.
Possibly
you
would
be
looking
into
adding
permission
to
some
of
the
people
who
are
from
ethereum
foundation
and
may
be
able
to
kind
of
label
the
prs,
and
that
would
be
helpful
for
eip
editors.
B
A
D
Yeah
yeah,
we
could
do
I'm
available
to
do
that
at
any
time,
but
you
know
basically
the
only
thing
it's
going
to
let
people
do
is
they're
going
to
be
able
to
use
the
tagging
feature
to
tag
information
about
pr's
and
issues,
so
I
think
that
you've
probably
seen
axic
go
in
and
add
some
tags
a
while
back.
This
would
just
allow
new
contributors
to
do
that
without
having
right
permission
to
the
repo.
Oh,
that's
great,
you
should
be
able
to
do
it.
D
A
Okay,
once
we
figure
out
who
wants
to
do
that,
I'm
happy
to
just
real
quick,
ask
the
editors,
if
that's
okay
and
then
and
so
they're,
not
off
guard
by
someone,
adding
tags
and
then
add
out
a
person.
Whoever
wants
to
be
a
tagger
sounds
good.
B
Who
would
would
it
be
possible
for
me
to
be
able
to
add
people
to
that
list,
but
not
be
an
eip
editor
or
our
permissions
that
I
can.
I
can
I
help
with
that
part.
D
D
B
I
just
was
wondering
if
that's
something
I
could
help
with
without
becoming
having
total
right
access
to
the
repository.
B
Yeah
because
I'd
I'd
be
happy
to
help
like
at,
like
there's
a
bunch
of
people
here.
That
should
be
there
already.
A
B
D
Yeah,
I
don't
think,
there's
any
major
updates
from
the
last
meeting.
I
was
off
for
about
a
week,
so
I'm
still
working
through.
I
have
a
list
of
requirements
that
I'm
trying
to
get
the
validator
to
reach
and
that's
all
in
the
readme.
So
if
you
see
anything
on
there
that
you
disagree
or
if
you
feel
like
there
should
be
new
things
added,
you
can
just
paint
me
or
add
an
issue
to
that
repo,
and
I
can
have
that
added
one
other
thing
about
that.
D
I
had
a
comment
on
getter
I'll,
just
post
it
here
again,
so
people
can
see
there
is
like
maybe
a
little
bit
of
confusion
between
the
validator
script
and
the
merge
bot.
Those
are
two
different
components.
So,
right
now,
I'm
working
on
the
validator.
This
is
just
going
to
statically
analyze,
eaps
to
make
sure
they're
conforming
to
whatever
standards
we
have
like
do
they
have
all
the
sections
are
all
the
links
to
other
each
relative,
these
sorts
of
things
that
editors
are
currently
having
to
do
manually
after
that's
complete.
D
Hopefully
I
can
do
some
more
work
on
the
merge
bots
and
the
merge
bot
is
going
is
basically
what
manages
the
state
transition
types
of
changes.
It's
going
to
be
determining
if
the
author
has
moved
from
draft
to
review,
and
it's
going
to
like
automatically
upset
accept
that,
rather
than
forcing
like
an
editor
to
to
review
it,
but
if
they
want
to
obviously
remove
from
like
review
to
finalize,
then
that's
something
that
they
eat
better,
and
so
all
those
things
are
managed
by
the
merge.
Bots.
B
D
Yeah,
I
think
the
merge
bot
you
know
is
written
by
nick
dodson.
I
think
that
it's
pretty
pretty
good
in
general,
we
just
need
to
add
some
additions
to
it.
The
problem
with
the
validator
is
that
it
just
seems
to
crash
in
really
unhelpful
ways,
and
so
that's
why
I'm
rewriting
it
from
scratch
rather
than
just
working
with
it.
I
think
the
merge
quad
kit
is
a
lot
more
amenable
to
being
updated.
D
I
would
be
happy.
D
B
Something
I'd
like
the
merge
bot
to
be
able
to
do
is
to
have
subgroups
of
permissions
so
like
if
we
had
the
the
triagers,
if
we
also
gave
them
permissions
to
be
able
to
edit
the
footer
and
then
the
merge
bot
would
accept
those
that
would
be
cool.
That
would
be.
It
would
be
helpful
and
then,
like
the,
if
the
tracking
things
that
are
currently
ethereum,
like
the
whoever
is
a
tr,
the
triage
bot
making
updates
to
that.
H
D
E
B
E
E
It's
from
greg!
Oh
I'm,
sorry,
I'm.
E
I
think
I
by
mistake,
I
may
have
put
the
wrong
link.
Is
it
never
mind?
I
will
just
post
the
link
in
the
chat
when
lifeline
and
elta
would
be
looking
into
it,
made.
Consider
that.
E
It's
coming
up
from
the
previous
agenda,
but
we
just
somehow
missed
to
discuss
that.
He
has
commented
in
the
previous
agenda.
D
E
I'm
sorry,
I
think
it's
like
the
current
validator
has
a
spell
check.
It
might
be
good
if
some
things
could
be
handled
as
warning.
Merge
the
draft,
but
let
author
know
there
is
a
work
to
do
things
like
body,
abstract
and
missing
section.
B
G
B
On
the
well,
you
I'd
open
it
up
too.
If
you
have
a
comment
on
something.
G
Yeah
I
wanted
to.
I
think
that
this
is
a
really
quick
topic,
so
I
was
considering
kind
of
refactoring
the
current
eip1
in
terms
of
layout.
I
really
like
the
layout
of
the
improvement
proposal
from
python
that
or
from
javascript.
I
think
that
you
sent
in
the
chat
or
that's
in
I
forget
who
sent
it
but
regardless.
G
C
So
what
I
think
elita
is
referring
to
I
I
posted
the
the
process
for
how
javascript's
creates
new
releases,
so
like
ecma,
2019
2020,
like
es6
on
their
website,
I
think
they
have
a
table
with
the
status
and
then
the
description
of
that
status.
G
Yeah-
and
it
was
also
a
little
bit
of
like
because
we
have
a
bunch
of
different
categories
and
stuff,
and
so
you
could
say
just
kind
of
organize,
you
know
into
columns
and
say
I'm
not
exactly
sure
how
it
would
end
up
looking
or
if
it's
even
feasible,
but
just
in
the
sense
of
you
can
look
at
a
single
table
and
know
you
know
what
are
the
guidelines
like?
Maybe
even
with
you
know,
spreading
out
some
of
the
stuff
with
just
some.
C
So
the
reason
I
actually
brought
that
up
was
this
is
how
they
decide
what
become
what
is
released
into
javascript.
So
I
was
thinking
of
it
as
inspiration
for
hardware
coordination,
but
I
mean
I
mean
it's
up
to
you
guys
what
you
think
about
reform
writing
eip1.
G
I
can
also
just
like
give
it
a
try.
If
you
don't
like
it,
we
don't
have
to
go
with
it.
I
think
I'd
be
okay
with
that
too.
B
E
So
before
that
there
is
a
comment
from
micah:
I
guess
that
is
linked
to
item
number:
five
constraining
the
eip
repository
school.
So
thank
you.
D
Lion,
sorry,
I
just
wanted,
maybe
to
suggest
a
different
wording
than
postmortem,
because
I
feel,
like
post-mortem
usually
has
to
do
with
when
something
goes
wrong
and
we're
writing
a
summary
of
what
happened
where
I
think
this
is
just
generally.
We
want
to
have
an
ease
that
states
the
stats
of
the
hardboard.
E
E
D
E
C
I
think
there
are
so
micah's
suggesting
that
we
just
remove
all
of
that
from
the
eip
repo
and
keep
it
only
standards,
which
I
think,
we've
already
decided
in
the
beginning,
to
call
this.
What
we're
going
to
do
we're
going
to
keep
we're
going
to
create
a
new
repo,
basically
for
well.
B
We're
kind
of
we're
skipping
into
discussion
on
the
mere
glacier
poor
vault
force
more.
So
let's
we,
let's
finish
this
number
six
course
and
then
we'll
go
back
to
the
to
micah's
comments,
because
I
we
jumped
around
a
little
bit
on
the
agenda,
which
is
my
bad
yeah.
The
retrospective,
I
think,
is
a
better
way
better
wording.
It
there's
definitely
things
in
your
glacier
that
went
wrong.
So
that's
why
it
was
a
postmortem,
but
we
should
we
can
call
it
a
a
retrospective
for
all
of
them.
That's
fine!
That's
fine
with
me.
E
So
I
have,
I
think
I
missed
asking
this
question
earlier,
so
I
will
be
changing
the
name
to
like
network
create
a
retrospective
for
near
glacier
for
this
particular.
But
there
is
this
proposal
of
two
pull
requests.
One
is
for
the
template
in
general,
and
one
is
for
the
mere
glacier
post
and
retrospective
report
for
mere
glacier.
What
I'm
getting
is
like
from
previous
meetings
of
eipip.
We
have
categorized
it
as
informational
eip
and
I've
tried
to
document
it
with
that.
E
But
michael
left,
some
comments
over
there
feel
free
to
go
back
and
reach
to
that
and
for
this
the
template
one
I
was
wondering:
should
it
be
informational
or
should
it
be
again
if
we
say
meta,
it's
going
to
bring
a
lot
of
controversy,
but
I
was
just
thinking
about
eip
233,
which
talks
about
the
process
that
is
to
be
followed
to
create
and
meta
for
network
upgrade.
So
I
was
trying
to
relate
I'm
happy
doing
either
way,
whichever
community
is
like
okay
to
do
that.
So
just
looking
for
some
suggestions
here.
E
D
I
don't
know
I
I
feel
like
this
fits
well
in
the
eeps
repository.
It
doesn't
have
to
do
with
the
governance
at
all.
This
is
just
purely
informational.
This
seems
like
the
exact
reason
to
have
an
informational
eep
that
states
something
that
happened.
A
Yeah
but
I
think,
but
if
I
guess
the
fewer
eeps
that
are
non-standard,
the
better
is
how
I
like
to
look
at
it.
But
that's
like
more
of
a
personal
opinion.
I
guess.
D
You're
saying
non-standardising,
they
are
not
standards;
no,
they
are
not
standards
like
with
an
s
yeah.
Okay.
I
mean
I
kind
of
feel
like
that.
We
should
have
more
informational
eeps,
and
maybe
this
isn't
the
right
kind,
but
I
feel,
like
you
know,
seeing
you
know.
Peter
has
been
posting
some
stuff
about
the
implementations
of
get.
There's
been
a
lot
of
talk
about
how
the
databases
are
implemented.
I
feel
like
those
are
things
that
could
be
written
as
informational
eats
they're,
not
consensus
requirements,
but
they
are
something
to
help
future
developers
understand
decisions.
E
I'm
totally
on
that
and
that's
the
argument.
I
was
trying
to
give
there
when
in
one
of
the
comments
to
this
pr
like
according
to
erp
one,
we
have
these
three
different
categories
of
keep
like
meta
standard
and
this
informational,
so
informational
section
is,
in
my
mind,
is
created
to
provide
more
information,
and
that
is
a
placeholder
for
imported
information
and
community
reference
kind
of
place.
D
I
think
micah
micah's
point
of
view
is
that
he's
coming
from
this
place,
where
he
believes
that
the
eev's
repository
should
be
generic
to
the
platform,
and
so
he
doesn't
think
there
should
be
a
network
upgrades,
because
he
believes
that
you
know
there
could
be
spinalized
thiefs
that
are
not
ever
going
to
be
used
by
the
ethereum
mainnet.
It
might
be
used
by
a
different
project,
and
you
know
my
point
of
view.
Is
that
that's
not
that
shouldn't
be
the
case
we
are.
This
is
the
ethereum
improvement
proposal
repository?
D
We
should
be
focused
on
ethereum
related
things,
and
so
one
of
the
most
important
parts
about
ethereum
is
what
is
on
mainnet
and
information
about
mainnet.
I
definitely
think
the
governance
process
about
what
goes
to
mainnet
should
be
separate
from
this,
but
I
feel
like
we
should
have
a
singular
focus
on
our
ethereum.
A
Yeah,
so
that
I
could
go
either
way,
it
could
be
in
the
hard
fork,
one
that
james
is
creating
or
it
could
be
in
the
eips.
But
for
now,
since
this
is
already
a
pull
request
in
the
eips
repo-
and
I
just
looked
over
the
looked
over
it
a
little
more
closely
and
it's
purely
informational,
it
doesn't
well.
A
So
then
there
was
this
huge
thing
and
later
yoichi,
who
used
to
be
more
active
in
the
eip's
repository,
wrote
up
a
really
long
long
like
article
that,
like
a
github
thing
that
explained
you
know
if
anyone
was
at
fault
like
who
was
kind
of
at
fault
who
wasn't
and
it
became
a
whole
deal.
So
I
can
see
these
in
the
future
becoming
more
controversial
and
then
them
not
fitting.
In
the
eip
repository.
B
Yeah
I'm
and
I
similarly
can
see
them
both.
I
see
both
sides,
so
I
don't.
A
Want
to
push
one
in
either
direction,
and
we
could
take
more
time
to
think
about
this
and
talk
about
it
on
telegram
in
the
next
meeting,
make
a
more
immediate
or
make
a
more
final
decision.
I
guess
yeah,
that's
a
good
idea
unless
I
mean,
if
obviously,
if
there's
other
comments,
don't
I
don't
want
to
stop
anybody.
C
B
Okay,
the
we've
got
10
more
minutes.
So,
let's
go
over
to
on
item
5,
constraining
the
iep
repository
scope.
C
We
we're
considering
creating
a
new
repo
for
hardware
coordination
to
separate
that
out
from
the
eap
repo,
something
we
can
define
is
in
addition
to
we're
separating
stuff,
just
defining
what
the
scope
would
be,
so
it
would
be,
we
could
formally
define
it
as
for
specifications
and
for
standards,
so
that
would
include
that
would
include
specifications
that
would
also
include
new
processes.
B
Yeah
and
thoughts
on
what
we
should
call
the
network
upgrade
repo.
C
Upgrade
mainnet,
which
repo.
C
A
Nah
they
don't
care,
not
that
they
don't
care
about
the
process.
I'm
just
saying
as
far
as
naming
goes
they
don't
they
don't
care
if
a
repository
needs
to
be
made
for
whatever
official
reason
we
don't
have.
Policies
basically
like
it
needs
to
be
a
good
reason
that
you're
making
it
and
it
doesn't
need
to
be
abandoned,
but
otherwise,
like
naming
wise,
there's
not
like
hard
and
fast
policies.
C
Yeah
so
we're
separating
it
would
it
follow
the
same
rules
as
the
eip
repo?
We
could
divert
it,
but
I
think
just
starting
it
off.
We
just
have
the
same
template,
or
I
mean
I
mean
I
guess
we
could.
A
A
People
like
james
and
there
needs
to
be
organization,
like
folder
separation
like
how
the
pm
repo
is
separated
but
like
one
of
them,
could
be
like
a
folder
for
retrospectives,
and
then
there
can
be
a
template,
maybe
but
that's
like
similar
to
eips,
but
it
doesn't
need
to
be
super
super
strict
unless
people
want
it
to
be
and
have
an
efi
section,
yeah
have
an
efi,
subsection
and
then
retrospectives
or
maybe
even
not
efi,
but
like
whatever
efi
is
so
like
a
hard
fork,
policies
or
stuff.
Like
that.
B
A
E
One
last
question
on
this:
this
is
related
to
the
peer
that
I
have
already
made.
So
my
if
I
understand
it
correct
I
have
to
hold
on
to
this
one
and
when
the
new
repository
will
be
created,
I
have
to
just
close
and
create
a
new
pr
over
there
and
any
other
part,
any
other
suggestion
on
this
change
of
any
part
of
the
peer.
I
saw
one
comment
from
like
client
that
even
the
template
could
be
an
informational
one,
I'm
fine
with
that,
but
other
than
that.
B
Okay,
we
have
about
five
more
minutes.
E
James,
if
I
may
ask
for
one
more
agent
item
to
be
covered
quickly,
I
think
it
can
be
done
quickly.
The
number
of
phone
this
for
the
standard,
citation
format.
I
think
this
proposal
is
almost
on
the
final
call,
so
micah
was
asking
if
somebody
has
any
objection
on
that.
I
mean
that
is
just
about
the
standardization
of
footer
for
all
eips.
C
I
think
I
think
it's
good,
so
if,
if
it's
citations
for
eap
specifically,
I
think
that
is
good.
I
think
it
would
be
more
ethical
because
if
there's
it's
using
work
from
someone
else,
that's
copyrighted,
I
think
it
should
be
referenced
or
linked
back
to
the
original
work.
C
If
I
looked
at
the
pr,
it
looked
like
just
static
text,
or
I
wasn't
quite
sure
how
is
it?
Is
it
taking
part
of
the
a
section
of
an
eap
and
putting
it
in
there
or
is
it
just
one
citation
for
every
single
eap.
B
I
think
it's
an
edit
to
the
layout
the
the
template
eip
so
that
in
the
template
there
would
be.
I
don't
know.
E
Anyway,
we
just
wanted
to
bring
it
to
attention,
so
even
if
people
find
anything
like
to
be
commented
on,
this
is
something
getting
into
final
stages,
so
feel
free
to
go
back.
Go
ahead
and
comment
on
that
full
request.
E
B
Whatever
you
I'll
review,
the
action
films
at
12.1
edson
will
make
a
survey
to
conduct
editors
on
the
expectation
from
an
editor
time
commitment
qualifications,
and
he
did
that
20.2
james
will
look
at
the
necessary
permissions
and
how
to
set
up
users
with
the
triaging
capabilities,
and
I
I
talked
to
cletson
about
that,
and
then
we
talked
about
that
today.
12.3
a
process
for
removing
editors
and
criteria
for
removing
editors
is
a
future
item
to
discuss.
B
A
So,
thank
you,
everybody,
okay.
I
figured
it
out
just
before
we
go.
This
is
for
the
eip.html
jekyll
layout
file,
so
this
has
stuff
like
the
okay.
So
basically
at
the,
if
you
go
to
eips.ethereum.org
and
you
click
on
any
ip
and
it
gives
the
header
information
like
the
author
and
stuff
and
then
it
gives
the
content
of
the
eip
at
the
very
bottom.