►
From YouTube: EIPIP Meeting 86
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/252
A
Okay,
so
first
up
we
have
the
semi
stagnation
of
last
call
eips,
it's
a
proposal
by
Panda
pip,
which
is
saying
suggestion
that
we
move
last
call
eip's
back
into
review.
If
six
months
has
gone
by
since
the
last
call
deadline.
A
A
These
are
mostly
formatting
changes.
I,
don't
think,
there's
anything
we
need
to
talk
about
here.
Yeah
they're,
just
formatting
changes
so
I'll
take
care
of
those.
A
B
This
is
non-controversial
not
not
worth
having
depending
on
personally
yeah.
Okay,
this
one
I
was
hoping
people
who
have
already
been
dog
fooding
this,
because
I
noticed
on
the
Discord,
there
were
EIP
authors
already
asking
for
access
to
a
Google
sheet
and
stuff
is
anyone
who's
working
with
those
authors?
A
Yeah
so
I
have
some
comments
for
this
one,
but
I
don't
think
Panda
pip
is
here
so
I.
Don't
think
there's
any
point
in
me.
Talking
about
them.
I
will
leave
them
on
the
pull
request.
A
Then
we
have
the
split
yeah
and
that's
probably
the
rest
of
the
meeting
there.
So
I
have
nothing
to
say
about
the
split
everything
I
wanted
to
say
has
been
said
so
I'm
just
gonna
sit
here
until
people
who
want
to
argue
show
up.
B
Also,
people
who
want
to
say
anything
other
than
our
good
girls
are
welcome
here,
like
if
you
know
just
operational
stuff.
If
this
should
be
updated
because
of
anything,
that's
happened
in
the
last
two
weeks.
C
Let
me
say
what's
non-controversial
for
me,
although
it
may
be
controversial
for
others,
the
one.
The
one
thing
that's
just
absolutely
blocking
for
me
is
that
we
remain.
C
We
remain
a
single
autonomous
editorial
organization,
splitting
up
the
organization
into
more
than
one
editorial
organization.
Just
is
not
at
all
what
I
signed
up
for
as
it
were.
It's
not
at
all
the
vision
that
we
were
working
for
back
in
I,
guess,
2017
2018.
C
So
it's
it's
partly
that
and
partly
just
that
I,
don't
I,
don't
see
any
good
coming
of
taking
the
various
conflicts
among
the
editors,
creating
more
than
one
organization
and
getting
to
argue
the
same
issues
in
more
than
one
organization,
getting
different
answers
and
different
organizations
and
trying
to
trying
to
handle
all
that.
We
need
one
organization
and
that's
that's
just
bottom
line
for
me.
I
have
strong
opinions
on
the
rest,
but
I
can
probably
live
with
the
consensus.
A
B
Well,
in
terms
of
like
how
the
conversation
has
evolved
over
the
two
weeks,
like
I
I,
dove
into
this
PR,
for
a
little
while
and
commented
on,
some
threads
and
I
saw
a
lot
of
you
know,
I
thought
it
was
48
separate
commits.
You
know
this.
This
has
been
you've
been
putting
it
a
lot
of
time.
Fine-Tuning
this,
which
I
really
appreciate
I.
B
Think
one
thing
I
noticed
in
the
last
two
weeks:
sort
of
an
option-
I
personally
didn't
realize
four
or
six
weeks
ago
was
an
option,
was
to
have
a
very
strong
working
group
notion
like
to
to
interpret
working
groups,
not
as
one-off
topics
for
like
us,
individual
EIP,
but
like
standing
bodies
like
the
core
devs
could
be
a
working
group
and
wallet
wallet
implemented.
Implementation
group
could
be
a
like
a
permanent
working
group.
B
Do
you
do
you
think
that
that
option
might
be
under
specified
like
do?
Do
people
realize
how
different
the
thing
is
they're
describing
as
the
working
group
when
they
talk
on
this
yeah
nfts
I,
just
clearly
like
nfts
are
like
half
the
half
the
PRS
on
on
the
repos
that
they
should
be
talking
to
each
other
it'd
be
great
to
force
all
the
interview,
people
to
talk
to
each
other,
yeah
I
mean
do
you?
Do
you
feel
like
that?
B
That
might
be
a
way
to
make
some
progress
whittling
down
the
like
building
Common
Ground?
If
people
understood
this
idea
of
still
being
one
entity
but
having
more
sort
of
like
status,
change
power
until
review
or
until
final
be
staying
within
the
working
group
or
something.
C
That's
a
fairly
loose
noise
notion
at
this
point
I.
Clearly
there
could
be
some
groups
that
are
pretty
ad
hoc.
Their
job
is
done,
no
reason
to
stick
around
true
the
notion
of
a
higher
level,
a
higher
level
group,
this
Less
ad
hoc
that
keeps
a
higher
level
group,
the
CL
teams,
Cel
teams-
we
don't
expect,
we
don't
expect
to
not
have
teams
at
that
level.
They
can
certainly
split
off
smaller
teams
when
they
want
to
and
clearly
protocol
is
different
than
applications.
C
They're
running
on
a
schedule,
they've
got
to
coordinate
and
once
something's
on
the
main
net.
It's
on
the
main
net.
There's
no
there's
no
going
back.
C
But
yeah
what
I've
suggested
is
nowhere
near
as
as
it
hasn't
been
laid
out
or
reviewed
nearly
as
much
as
the
current
split
proposal,
so
pretty
much
I've
I've
simply
made
suggestions.
C
Part
of
that
PR
is
just
you
know:
here's
low
hanging
fruit,
here's
good
things
we
could
have
without
splitting
and
then,
if
we
can't
come
in,
if
we
can't
come
to
consensus
on
those,
it
doesn't
seem
like
splitting
will
will
help
that
a
whole
lot
and
I
just
I
just
don't
see
how
it
helps.
C
So
you
can
get
two
groups
to
to
argue
about
those
things
and
and
have
trouble
with
them
still
and
I'm
I'm,
nowhere
near
enough
of
an
expert
on
GitHub
and
how
the
bot
works
and
how
people
try
to
use
Street
Hub,
but
I.
Just
I
don't
see
the
point
of
a
two-way
split
if
I
look
at
as
Dana
left,
unfortunately,.
B
Time
yeah,
he
said
at
the
10
minute,
Mark
he'd
be
back
at
the
30th
Mark
as.
C
Refactoring,
it's
sort
of
I
just
really
see
three
pieces
there
and
we're
splitting
it
in
two
and
it's
it's
true
that
what
we
classify
under
eip's
has
a
certain
status,
that's
more
than
arcs,
because
it
is
the
protocol.
There'd
be
nothing
else
without
the
protocol
and
the
protocol's
not
working
nothing
else.
C
Works
Etc,
so
looking
at
my
EIP
I'd
be
pretty
happy
to
replace
a
lot
of
wear
I'm,
giving
privileges
to
the
core,
devs
I'm,
giving
privileges
to
working
group
to
just
say,
I'm,
giving
privileges
we
are
giving
privileges
to
the
core
devs
and
we'll
consider
down
the
line.
C
Weather
particular
working
group
should
have
that
level
of
privilege,
but
some
way
for
the
working
groups
to
be
able
to
handle
and
the
core
devs
being
able
to
handle
the
status
changes
in
their
workflow
without
having
to
push
back
on
the
editors-
and
you
know,
keep
complaining
that
last
call
is
in
the
way
and
have
to
come
back
to
us
if
they
change
something.
C
It's
the
editor
shouldn't
care
where
it
is
as
to
considered
for
implementation.
Is
it
going
on
that
the
test
nets?
All
of
that?
That's!
Not
our
problem!
We're
editors,
we're
Publishers
and
the
main
eips
repo
has
been
the
repo
that
the
editors
have
been
working
in
and
Publishing
documents
out
of
for
years.
C
So,
even
from
that
point
of
view,
it
just
seems
to
make
sense
to
get
to
get
most
of
the
editing
flow
out
of
the
editor's
repo
in
in
other
standards
bodies.
The
working
groups
pretty
much
handle
the
documents
up
until
it's
time
to
to
present
them
to
the
the
whole
Community
or
whatever
part
of
the
community
is
actually
cares
and
and
actually
get
them
finally
published
and
in
some
other
groups
the
the
working
group
has
a
lot
more
to
say
over
the
actual
format
of
the
documents.
C
If
motivation,
reference
rationale
is
just
not
an
appropriate
format.
Fine,
the
editors
don't
start
concerned
about
that.
But
if
you
tell
us
what
your
rules
are
we'll
review
for
that
things
like
that,
these
are
not
precise,
they're,
just
things
to
put
on
the
table
as
instead
of
the
split
it's.
C
Basically,
we
need
to
split
things
up,
so
what's
the
best
way
to
split
them,
and
things
have
gotten
very
polarized
I
think
because
we're
just
considering
the
split,
so
even
if
we
want
to
split
them
up
we're
arguing
over
this,
this
single
single
way
to
do
it
when
there's
really
a
broader
range
of
possibilities.
C
So
that's
sort
of
my
take
on
it,
trying
to
be
as
as
calm
as
possible.
Things
have
gotten
pretty
heated
and
I've
gotten
pretty
heated,
because
I've
I
just
put
a
lot
of
work
into
this
over
the
years
and
breaking
up
the
editor's
group
is
just
sort
of
I
wake
up
with
Nightmares
From
it.
That's
that's
what
it
means
to
me.
So
yeah.
B
Okay,
well
definitely
thanks
for
thanks
for
pushing
on
this
and
trying
to
iterate
this
so
much
over
the
over
these
weeks,
I
see
the
participant.
Let's
keep
changing
I
guess
people's
conflicts
are
over
height.
D
Later
I
had
another
work
meeting
that
I
had
too
I'm,
also
a
10,
so
I'm
double
booked.
Of
course.
So
one
of
the
high
level
concerns
I
have
with
looking
at
yet
another
approach
is
we've
been
in
a
cycle
of
looking
at
yet
another
approach
for
years
and
it
never
comes
to
fruition.
It
never
actually
gets
to
the
final
step.
We
talk
about
it.
We
argue
the
benefits
and
the
drawbacks,
and
no
action
never
happens.
D
So
that's
one
of
the
reasons
why
I
advocate
just
going
straight
for
the
split
leaving
the
editors
in
two
different
groups.
You
could
join
whichever
group
you
could
probably
even
join
two
groups.
People
have
disagreements
on
that,
but
I
don't
see
the
problem
of
joining
both
groups
and
they
can
even
coordinate
on
standards
together.
But
the
key
thing
is
it's
action
and
there's
the
more
we
talk
about
it,
the
more
the
less
likely
we
are
to
ever
see
consensus
specs
in
an
EIP
form.
D
We
need
to
act
now,
or
else
they're
going
to
passively
split
and
then
passive
split
is
going
to
look
like
on
execution.
Layer,
specs
also
leave
an
EIP
process,
and
that
is
not
a
good
outcome,
so
the
pain
relief.
Yes,
let's
do
all
these
pain
relief
steps,
but
that
does
not
remove
the
need
from
the
split.
This
is
not
a
mutually
exclusive
proposal.
I
think.
C
B
B
Maybe
another
way
of
maybe
a
follow-up
question
would
be.
What
is
still
on
I
mean:
is
this
PR
in
draft
or
is
every
little
net
sorted
I
mean
because
this
looks
I'm
not
seeing
anything.
I
have
opinions
on
still
open,
I
I,
don't
understand
much
the
the
lint
linting
part,
but
other
than
that
it
seems
like
this
could
be
merged,
and
that
would
help
close
some
of
the
gap
between
between
people.
D
I
still
think
the
EIP
ERC
split
should
be
resolved
first
before
we
merge
this,
and
then
we
can
merge
this
second,
after
it
splits,
and
the
reason
is
because
the
split
was
proposed
first,
the
split
is
what
predicated
these
and
the
conclusion
from
the
all
core
devs
Engineers.
We
had
a
meeting
last
week
we
talked
about
it,
we
asked.
Does
anybody
feel
any
different
multiple
times
and
what
what
what
the
group
being
served
there
wants
is
two
different
repos.
D
So
once
we
get
to
two
different
repos
I
think
we
can
look
at
these
paid
release
and
see
what's
relevant
to
ERC
group
versus
the
EIP
group.
For
example,
I,
don't
think
the
protocol
group
really
needs
the
working
group
structure,
but
I
think
the
working
group
structure
would
be
immensely
beneficial
to
the
erc's
set
of
ones,
and
we
get
one
for
D
Phi
we
get
one
for
wallets.
We
get
one
for
smart
contract
patterns.
D
I
think
those
would
be
immensely
beneficial
for
those
organizations,
but
the
awkward
damage
group
kind
of
has
their
own
setup
that
isn't
really
really
quite
working
groups
and
it's
kind
of
a
square
peg
round
whole
thing.
There
they
have
a
process
and
they
just
need
to
reflect
in
the
documents
they
produce.
B
Sorry,
sorry,
don't
know
you
what,
while.
B
Yeah
sorry,
he
missed.
He
missed
that
whole
conversation
like
we,
my
question
like
actually
I,
think
just
after
you
dropped
was
hey,
I
saw
on
a
I
think
it
was
Discord
or
Discord
conversation
not
not
GitHub
conversation.
The
idea
that
maybe
all
core
devs
is
like
a
standing
working
group,
that's
like
slightly
more
official
or
long
term
or
has
different
privileges
than
a
more
lightweight
working
group
that
might
be
topical
and
we've
been
sort
of
kicking
around
this
idea
that,
like
is
kind
of
working,
run,
a
repo
I,
don't
know
so.
D
My
concern
is
asking
to
set
the
working
group
standard
for
the
ERC
side
of
the
house
too
high,
because
we
have
weekly
meetings.
We
have
very
specific
processes,
we
have
very
nailed
down
processes,
and
so
the
other
groups
coming
in
think.
Well,
we
can't
compete
with
that.
So
we
just
won't
form
working
groups
or
the
working
groups
will
form
and
they'll
be
held
against
the
standard
that
is
completely
impossible
for
them
to
meet.
D
If
they're
in
separate
groups,
they
can
set
their
own
working
group
norms
and
standards,
it
might
just
be
an
email
list.
It
might
just
be
a
group
of
people
that
review
the
PR's
on
a
regular
basis.
D
C
D
So
why
do
we
need?
A
third
group
above
us
I
think
was
the
other
discussion
that
was
on
Discord
there's
like
basically
little
to
no
value
and
one
of
the
concerns
that
I
got
that
I
got
in
the
chat
from
one
of
the
other
Engineers
who
was
in
awkward
devs?
Was
we
don't
want
a
hierarchical
group
over
us
and
third
group
sounds
like
hierarchy.
We
don't
want
hierarchy,
what
was
needed
as
a
peer
relationship
between
ERC
and
EIP,
and
not
a
hierarchical
group
above
them.
C
C
It's,
as
you
say,
like
a
software
refactoring
having
decided
to
refactor
I
want
to
get
it
right
and
I,
don't
think.
That's
a
two-way
split
and
I
think
it's
a
three-way
split
at
least
just
get
out
of
eips,
which
is
where
the
where
the
editors
have
been
working
for
years.
It's
the
directory
we
work
in
and
where
we
publish,
but
it's
also
gotten
cluttered
up
with
all
of
the
editing
for
all
of
the
IPS
and
we've
set
standards
on
workflow,
as
well
as
editorial
concerns
and
workflows.
C
D
C
D
C
D
D
C
C
That
I
hear
these
complaints
and
we
need
to
coordinate
better.
You
know
I
think
we
need
some
process
where
the
core
devs
can
say
things
like
this
has
to
go
to
final
and
I.
Don't
know
what
that
looks
like,
but
some
sort
of
appeal
to
deal
with
that.
D
D
It's
not
the
repos,
the
jurisdiction,
it's
where
we
can
say
in
all
Cortez.
Okay.
This
has
been
implemented
for
years
in
the
clients.
Let's
just
go
straight
to
final,
and
no
one
from
another
group
can
say:
no.
You
can't
do
that.
You
have
to
go
to
two-week
final
call
and
see
if
anybody
has
any
more
comments,
all
the
clients
are
there.
D
C
The
autonomy
I
think
you
should
have
the
last
basically
I'm
hearing
there
shouldn't
be
a
last
call
I'm
going.
No,
there
shouldn't
be.
We
need
those
stages
for
erc's,
because
they're
not
currently
organized
enough
to
hand
over
to
DRC
to
say
what's
your
process,
so
we
have
sort
of
a
default
process.
C
The
core
we
shouldn't
say
what
their
process
is.
We
cut.
They
come
in
pretty
early,
just
to
sort
of
snag
a
number
and
say
Here's,
a
graph
we're
working
on
after
that.
The
stages
are
up
to
the
devs
final
happens
when
something
is
finally
on
the
main
net.
It's
final,
if
there's
some
delay
in
finally
getting
that
documented
and
some
back
and
forth,
it
isn't
in
the
way
of
getting
it
on
the
mainnet.
Whatever
your
last
spec
is
that
you
work
from
for
for
actually
getting
the
upgrade
done.
That's
all
the
document.
D
C
Then
the
editor
should
resign
and
tell
the
core
devs.
We
will
no
longer
publish
your.
We
will
no
longer
publish
your
things
if,
if
you
feel
that
that
you
should
be
the
Publishers
of
them
and
not
let
anybody
else
have
any
say
over
that
you
can
fire,
you
can
fire
us
Inspire
us
as
Publishers
and
create
your
own
group
and
Encore
death
meetings.
You
can
argue
overlink
policy.
B
How
could
we
still
be
talking
past
each
other?
If
Greg
is
saying
you
could
set
your
own
status
to
final,
without
or
without
the
broader
group
and.
D
D
So
what
what
does
this
third
group
do,
then
I
mean
we
can
get
Seth
repo
set
it
up,
but
I
want
boundaries
and
expectations
what
their
role
is
and
if
they
have,
and
if
this
in
its
ERC
and
EIP,
has
full
rights
to
ignore
anything
that
that
the
editors
group
imposes
on
them,
then
I
want
that
written
into
the
document.
So
the
founding
group.
D
C
C
C
We've
set
up
a
default
workflow
and
we
need
that
for
the
erc's,
because
there
is
no
standing
group
to
to
handle
any
of
that
for
the
core
developers.
There
is
I
think
you
missed
some
of
this
discussion,
so
I'm
trying
to
repeat
myself
more
briefly
the
for
the
core
devs.
C
C
C
C
Was
that
final,
that,
basically
things
went
to
the
to
the
devs
in
draft
State
and
they
came
back
in
final
State
and
what
happened
in
between
wasn't
the
editor's
business
and
somehow
somehow
these
stages
started
started,
getting
pulled
into
the
editorial
status
stages
so,
to
some
extent,
I
feel
we're
just
arguing
about
the
use
of
a
status
field.
B
And
Let
Me
Maybe
This
would
help
what.
If
so,
you
said
that
working
groups
as
sort
of
self-governing
as
all
core
devs
should
have
full
Reign
to
add
and
subtract
headers
change
the
options
about
what
the
status
can
be,
what
if
all
quartets
had
a
status
called
Almost
final
and
going
from
almost
final
to
final
we're
just
a
a
matter
of
like.
B
Let's
make
sure
this
is,
you
know,
documented
in
a
way,
that's
really
future
proof
and
can
just
be
an
immutable,
could
go
into
ipfs
and
be
useful
for
five
years,
and
that
were
the
only
sort
of
distinction
so
that,
if
that
process
takes
too
long
every
once
in
a
while,
everyone
in
El
cordovs
is
like.
Oh,
we
already
put
it
at
almost
final.
B
C
Yeah,
that's
what
was
imagined
years
ago,
so
I
think
on
the
core
dev's
current
workflow.
There
would
be
a
document
called
it,
the
mainnet
document,
which
would
be
a
stage
of
the
EIP,
where
there's
consensus,
that
this
is
what
is
going
into
the
next
upgrade.
So
there's
a
document
everybody's
working
from
it
may
or
may
not
meet
editorial
standards.
C
C
By
that
point
we
should
have
a
working
executable
specification,
working
clients
and
the
mainnet
spec
and
the
the
final
can
be
produced.
If
there's
some
delay,
it's
not
a
big
deal.
If
there's
disagreements
over
editing
standards,
they
can
be
worked
out.
So
we
need
that
we
need
some
sort
of
process
for
collaborating
I.
Don't
think
the
editors
should
be
should
be
in
the
way
of
the
core.
C
Devs
I
understand
that
I
do
understand
as
a
Dev
that
you
don't
you
don't
want
the
editors
in
in
control
of
whether
you
can
ship
and
you
don't
want
to
just
hit
a
wall.
If
there's
a
disagreement
about
you
know.
Stuff
is
stupid,
as
you
know
whether
I'm
not
allowed
to
links
to
something
yeah.
C
B
That
sense,
that
going
from
what
I'm,
basically
calling
the
almost
final
step
to
the
final
step
is
really
more
of
a
like
a
service
to
the
other
two
working
groups
that
are
Downstream
right,
like
you
want
to
have
a
version,
that's
nautical
and
permanent,
so
that
when
people
are
designing
wallet,
interfaces
or
or
solidity
interfaces,
they
have
the
you
know
final,
it's
sort
of
like
so
then
editorials
role
in
that
last
step
is
less
about
making
sure
all
core
debt
has
passed
the
right
thing
and
more
about
making
sure
that
what
all
cordov
has
passed
is
documented
well
enough
to
be
like
unambiguously
helpful
to
everyone
else.
E
C
There
wouldn't
be
an
issue
without
the
split
but
and
I
keep
saying
I
at
this
point
as
I'm
coming
to
understand
it
I'm
not
against
a
split
it's
like.
Yes,
we
need
to
refactor
things,
but
as
a
software
engineer,
looking
at
refactoring,
if
someone
comes
in
and
says
this
has
to
be
refactored
and
here's
how
we
are
going
to
do
it
and
I
I
look
and
go.
This
refactoring
doesn't
seem
right.
You've
taken
three
things,
lumped
two
things
together
and
it's
it's
still
a
problem.
Yeah.
C
The
problem
is
that
we
have
a
repo
we've
been
working
in
that
repo
for
years,
and
the
editors
use
that
repo
to
do
their
work,
and
then
we
do
a
split.
So
this
repo
becomes
both
the
place
where
the
editors
work
and
the
place
where
only
eips
are
done,
and
somehow
the
core
developers
feel
some
direct
ownership
over
it,
which
pretty
much
pretty
make.
It
makes
it
pretty
unclear
who
the
editors
are
and
what
their
role
is.
C
And
then
we
move
the
ercs
out
and
then
they're
suddenly
abandoned
it's
not
clear
what
their
place
in
the
process
is
and
I'm
just
going.
The
editors
or
the
editors
we've
given
people
the
privilege
of
being
able
to
add
it
directly
on
our
repo
and
by
by
this
point,
there's
simply
too
many
documents
for
that
to
be
workable.
Even
on
the
course
side.
There's
there's
just
too
many
documents
and
people
don't
need
on
that
repo
to
be
seeing
so
many
changes
in
the
documents.
C
The
core
dads
need
their
own
repo,
where
they
can
take
a
document
all
the
way
through
to
the
mainnet,
without
without
the
editors
having
anything
directly
to
say
about
it,
I
mean
I,
don't.
E
E
C
In
the
discussions
I'm
seeing
people
talking
complaining
about
decentralization
about
hierarchy,
and
this
sounds
like
the
core
devs
I
mean
you
took
a
PR
to
the
core
devs
and
if
you
tell
somebody
there
are
problems,
here's
a
PR
that
fixes
them.
Do
you
want
us
to
fix
it.
They
will
of
course,
say,
of
course
fix
it
fix
what
fix.
Whatever
problems
you
believe,
displaying
the
repos
will
fix.
E
E
E
D
We're
not
proposing
splitting
getting
rid
of
editors.
That
seems
to
be
when
you
say
when
we
don't
want
the
third
group.
That
seems
to
be
the
undertone,
that
core
devs
reject
editors.
We
want
editors,
we
want
them
split
between
the
two
groups.
We
want
editors,
focusing
on
the
needs
of
ercs
and
editors,
focusing
on
the
needs
of
VIPs.
They
have
very
distinctive
District
needs
and
different
things
need
to
be
done
with
those
two
repos.
D
So
when
we
propose
the
split
we're
not
saying
no
editors,
no
standards,
nothing
that
can't
be
put
on
put
on
an
ipfs
link
for
five
years.
We
still
want
that.
We
just
don't
see
what
value
a
third
group
over
both
of
them
has.
They
can
both
create
high
quality
standards
independently.
There's
nothing
about
unifying
the
processes
that
magically
makes
it
better.
D
The
itdf
does
not
have
a
board
of
direct,
does
not
have
a
board
of
editors,
it
has
a
director,
it
has
areas
and
those
areas
have
working
groups.
Working
groups
have
a
chair
and
one
editor
per
working
group.
So
there
is
no,
you
know,
centralized
editor
group
doing
this.
Editors
within
each
working
group
have
independent
full
control
over
it.
So
unless
you
can
show
me
what
the
higher
levels
of
the
ietf
would
add
to
the
situation,
that
is
not
just
overhead
and
frustration.
C
The
standarding
working
groups
are
and
I
think
in
a
similar
way.
The
Developers.
C
Yes,
if
you
feel
a
need
in
managing
your
workflow
to
set
up
somebody
typically,
the
project
manager
has
done
a
fair
amount
of
this.
To
say
these
are
the
standards
we
need
to
enforce
for
our
documents.
Fine,
but
the
chief
editor
and
staff
there
in
the
ITF
have
become
more
bureaucratic,
but
they
do
set
standards
for
just
your
basic
editorial
stuff.
There's.
E
Nothing
stopping
us
from
having
this
at
some
point
like
I'm,
not
against
the
structure
fundamentally,
but
we
just
don't
have
enough
people,
we
don't
have
a
need
for
this
right
now.
We
can't
even
get
the
other
three
editors
to
show
up
on
this
call.
We
have
you
know
basically,
three
editors.
There
is
no
need
for
another
group
to
manage
the
three
of
us
like.
We
just
need
a
group
chat.
C
B
B
2023
ITF
process
is
something
I
could
actually
speak
to
off
the
top
of
my
head,
but
I
think
I
think
that
maybe
Dana
made
a
good
point
that
the
area
groups
are
standing
working
groups
and
working
groups
are
sort
of
topical
chartered
short-lived
and
the
area
groups
each
have
an
editor
who's
sort
of
coordinates
within
the
area
group
within
the
multiple
working
groups
and
the
area
groups
coordinate
amongst
each
other
to
with
dispatch
to
make
sure
all
new
items
only
go
to
one
area
group
don't
create
redundant
working
groups
within
across
area
groups,
so,
like
I,
do
think
that
function.
B
It's
sort
of
like
I
think
that
what
Deno
just
said
in
terms
of
like
maybe
one
editor
per,
let's
just
call
them
area
groups
right,
let's
just
say:
ERC,
EIP
and
wallets-
are
area
groups
and
there's
three
of
them.
This
fourth
group,
whatever
we
want
to
call
it
I
I,
really
don't
I
think
that
if,
if
anyone,
if
anyone
in
any
of
the
four
groups
thinks
that
fourth
group
is
the
overarching
hierarchy
or
the
final
say
or
the
ultimate
Authority
doomed
to
fail,
will
never
work,
we
aren't
ITF.
B
We
aren't
big
enough.
There
aren't
enough
hands
to
justify
that
right.
I
I,
think
all
those
points
are
totally
valid.
I
just
think.
Coming
from,
like
a
project
management
and
coordination
community
background
I
see
that
fourth
group,
as
the
the
the
core
of
like
almost
administrative
function,
that
just
helped
that
group
chat
of
the
editor
in
each
area
group
work
right.
B
A
I
think
what
we
really
need
to
consider
is
what
Points
of
Authority
I
don't
know
if
there's
a
more
formal
term
for
it
or
not,
but
what
Points
of
Authority
exist
in
the
system
so
like,
for
example,
core
developers
have
the
authority
to
choose
where
they
publish
their
documents
and
where
they
read
their
documents
from,
and
you
know,
EIP
editors
have
the
authority
to
decide
what
pull
requests
get
merged
in
their
repository
and
those
are
really
the
only
two
points
of
like
power
in
this
entire
system.
Everything
else
is
just
it's
imaginary.
A
Right,
like
you
know,
you
know,
all
quotas
can
say
that
there
are
peer.
We
have
a
peer
relationship
with
them
or
whatever
it
doesn't
matter.
Our
Authority
is
over
pull
requests
it
like
our
actual
authorities
of
over
pull
requests
in
the
eip's
repository
and
core
dev's
actual
Authority
is
you
know
where
they
read
their
documents
and
where
they
publish
their
documents
to
and
like
I
I,
don't
think
we
need
to
think
of
anything
outside
of
those
two
like
decisions.
Do
all
core
devs
use
the
eip's
repository
to
publish
stuff?
A
B
If
there
was
a
coordination
group
that
included
hopefully
at
every
meeting
one
editor
from
each
of
the
area
groups,
it
might
need
to
meet
more
often,
but
maybe
it
would
only
need
to
have
more
participation
from
the
entire
all
core
devs
or
wallet
devs
or
EIP
devs,
every
fourth
meeting
or
every
eighth
meeting
or
something
because
then
you
could
just
sort
of
schedule
for
that
meeting.
Everything
that
needs
more
detailed
or
wider
review.
B
I,
don't
know
but
I'm,
not
I'm,
I'm,
totally
hijacking,
like
client's
agenda
item,
like
client
I,
think
you
you
were
just
talking
about
quarterly
reading
full
stop.
I,
don't
know
what
else.
What
else.
E
C
E
Oh
okay,
okay,.
A
E
A
E
Meeting
could
be
an
email
most
of
the
time
or
a
discussion
on
pull
requests
if
editors
are
unable
to
just
like
respond
to
pull
requests
in
a
timely
manner,
then
that's
like
a
bigger
problem,
but
I
don't
want
to
come
on
here
every
two
weeks
and
debate.
Should
we
add
VIP?
Should
we
add
you
know
whatever
you
know
new
links?
E
You
know
this
is
just
like
a
total
waste
of
time
and
we
can't
even
get
most
of
the
others
to
comment.
I
am
like
frustrated
that
I
come
every
two
weeks
almost
and
the
other
rest
of
the
editors
come
whenever
it's
convenient
for
them,
so
they
can,
and
especially
because
panda
is
the
one
who's
creating
most
of
these
changes,
and
we
have
to
come
on
and
debate
his
changes,
but
he
doesn't
even
show
up.
B
I
might
be
a
signal
of
an
orthogonal
and
also
very
serious
problem,
which
is
that
if
the
coordinating
body
that
is
supposed
to
be
helping,
other
processes
is
holding
back
other
processes.
That's
like
a
funding
issue
like
the
the
like
you're
doing
this.
On
top
of
your
day,
job
and
but
everyone's
doing
this
on
top
of
their
day,
like
no
one's
being
paid
to
attend
these
meetings,
every
two
weeks
is
like
its
own
problem.
B
Okay,
sorry
that
exactly
but
like,
if
the
if,
if
this
were
someone's
job,
they
were
holding
up
the
processes
they're
supposed
to
be
enabling.
Then
we
would
say,
like
you
are
bad
at
your
job.
We
need
a
new
person
to
sit
in
your
role
but,
like
maybe
that's
a
sort
of
structural
issue
to
like
where
the
money
comes
from,
to
keep
this
process
going,
that
the
timeline
is
that.
E
E
D
D
That's
my
number
one
concern
about
a
third
organization
is
it'll,
become
a
trophy
job
and
it
won't
provide
actual
value.
If
that
can
be
shown
that
this
provides
actual
value,
that
Above
and
Beyond
Simple
collaboration
between
two
groups,
then
that
would
be
persuasive
to
me,
but
I'm
concerned
that
a
third
group
is
just
going
to
be
a
trophy
job.
E
A
E
10
Bako
looks
like
a
an
editor
in
some
ways.
He
looks
like
a
somebody
who's
in
charge
of
you
know,
organizing
a
group,
a
area
group,
and
it
makes
sense
like
he
does
a
lot
of
work.
He
does
a
lot
of
work
like
coordinating
things,
and
this
is
like
you
know
not
something
that
editors
do
at
all
by
Design.
C
C
But
it
it's
not
an
editing
job
to
say:
we've
we're
considering
this
for
inclusion,
it's
not
an
editing
job
to
say
it's
time
to
put
it
on
the
test.
Nets,
it's
not
an
editing
job
to
say.
Yes,
we've
decided
we're
going
to
put
this
into
the
next
upgrade
and
it
doesn't
need
to
be
an
editing
job
to
to
keep
those
directly
in
the
editing
status
that
that's
what
I'm
saying
to
work.
C
But
just
saying
we
have
one
repo,
that's
that's
where
both
the
editors
and
the
core
devs
are
going
to
work
and
we're
going
to
create
the
CRC
repo
and
it's
an
awful
lot
less
clear
to
me.
We're
going
to
manage
that.
Are
we
going
to
wind
up
with,
like
just
Victor.
E
C
E
We're
not
struggling.
Yes,
we
have
editor.
We
have
editors
who
have
enough
time
to
just
write.
You
know
multi-paragraph
essays
rebooting,
other
editors
like
we
have
the
time
we
just
need
to
apply
it
to
editing.
Eips
we've
got
ERC
sitting
there
that
haven't
been
looked
at
in
months
we've,
but
instead
all
of
the
editors
are
sitting
here,
arguing
about
numbering
and
about
how
to
deal
with
the
process.
We're
not
even
serving
the
community.
C
E
I
mean
personally
I,
don't
see
why
this
is
a
problem,
but
I
I,
honestly,
don't
really
care
that
much
about
this
point.
I
want
to
split
the
repos.
If
we
have
to
have
an
I,
don't
know
what
it
means
if
we
have
to
have
an
organization
that
goes
above
the
two
that
I
don't
really
care,
because
I
don't
think
this
organization
does
that
much,
but
I
don't
want
to
then
spend
the
next
three
months,
trying
to
figure
out
what
the
processes
are
going
to
be
for
the
organization.
C
Yeah
this
we're
running
into
some
fundamental
disagreements
and
going
around
in
these
meetings,
isn't
helping.
They
may
be
fundamental
enough
if
the
other
devs
it
excuse
me
if
the
other
editors,
if
the
other
editors
want
to
go
with
the
split
you
know,
D
split,
not
a
split
okay,
but
I'm.
Just
hearing
just
fundamental
disagreements
as
to
how
the
editors
should
be
relating
to
the
developers
and.
C
That
that's
the
blocker.
For
me,
the
editors
need
to
remain
a
single
autonomous
organization
and
I'm,
also
tired
of
arguing
about
that
and
they're.
That's
what
I've
just
sort
of
laid
down.
That's
a
long-standing
intention.
I
see
no
good
coming
of
break
coming
from
breaking
it
up.
I'm,
not
interested
in
participating
in
the
process
of
breaking
things
up
and
having
an
organization.
I
help
create
split
up
in
pieces
and
I
can
keep
arguing
about
it.
You.
C
For
crying
out
loud
after
a
few
years,
access
joined,
I
went
in
to
edit
eip1
to
add
his
name
and
I
looked
and
said
Gee
my
name's,
not
an
eip1.
It's
been
a
long
time.
I
should
probably
put
it
in
you'd
have
to
go,
find
the
old
Skype
dogs
to
figure
out
when
I
first
joined,
if,
if
they're,
even
still
there
and
complete
I,
don't
know
as
to
whether
I
started
in
2016
or
17
Hudson
might
remember.
Nick
Johnson
would
remember
perhaps,
but
he's
he's
pretty
much
moved
on.
D
C
Fine,
this.
E
B
I
think
the
I
think
the
fundamental
question
for
me,
just
as
a
newcomer
as
an
outsider,
walking
in
on
this
family
dispute,
it
seems
to
me,
like
it's
actually
kind
of
important
how
these
so
I've
been
doing
open
post
for
a
long
time,
I've
been
trying
to
coordinate
processes
across
companies
for
a
long
time.
It,
it
seems
to
me
like
part
of
the
issue
here,
is
that
core
devs
have
pretty
conventional
employment
relationships
and
it
is
their
full-time
job
to
advance.
B
You
know
one
of
those
three
working
groups
within
that
area
group
in
in
Daniel's,
analogy
execution,
apis
or
whatever,
and
because
of
that,
this
feels
like
some
weird
external
process
outside
of
their
job
outside
of
their
company
outside
of
their
colleagues
outside
of
their
sort
of
Specialists,
who
were
all
focused
on
this
on.
You
know:
company
style
timelines
and.
D
It's
not.
It
wasn't
built
as
an
independent
thing
that
should
have
independent
standing
like
the
ietf.
It
was
built
as
a
facilitator
in
a
formal
process
to
help
these
protocol
things
go
forward
and
to
serve
the
community.
My
concern
is
what
what
is
what
like
client
was
saying
before
he
left
to
go
to
his
meeting.
That
I
should
probably
be
on
sorry.
D
Is
that
we're
spending
time
not
serving
the
community
but
fighting
about
our
own
standards
and
we're
not
spending
time
reviewing
eips
in
the
erc's
coming
from
the
communities,
which
should
be
the
purpose
of
it?
We're
too
busy
worried
about
structure
and
format
to
serve
the
communities
it's
set
up
to
serve,
and
that's
one
of
the
things
I
think
the
ERC
split
will
do
erc's
handle
just
erc's
EIP,
essential
core
protocols
and
all
of
the
the
minutia
of
people.
D
You
know
what
you
know:
the
app
developers
don't
want
this
thing
for
the
protocol
and
their
process
so
great,
let's
split
them
up
and
that's
the
core
core
win
for
the
process,
and
it's
easy
to
split
them
now
and
if
the
third
group
needs
to
form
after
we
do
the
split,
because
there's
value
to
the
added
to
be
demonstrated,
we're
fine
with
that.
D
We
just
don't
think
that
should
be
predicated
on
the
split
split
now
let
things
figure
out
what
need
to
be
done
and
let's
focus
on
serving
the
communities
rather
than
arguing
about
what
our
jobs
are
and
whether
we
should
be
paid,
because
if
we
do
a
good
enough
job,
the
pay
will
follow,
some
company
will
hire
us
or
there
will
be
formal
funding
for
this
process.
That's
always
been.
D
The
Mantra
of
ethereum
is
get
in
and
work
and
if,
if
you've
really
found
something
valuable,
there's
a
company
that
has
an
empty
slot,
that
does
what
you
do
so
that's
kind
of
where
we've
been
maybe
we're
growing
past
that
part
we
need
to
have
it
I,
don't
think
we're
quite
there,
yet
maybe
we'll
be
there,
but
I.
Don't
think
that
those
issues
should
stop
what
needs
to
be
done
now,
which
is
get
core
processed
separate
from
application
process,
they're
very
Divergent
communities
and
are
continuing
to
diverge.
D
B
Completely
ends
no
I
I.
Take
your
point
but
I'm
wondering
if
this.
If
the
original
idea
was
for
this
process
to
facilitate,
were
the
was
the
initial
idea
for
those
facilitators
to
be
completely
unpaid,
because
that's
like
never
that
that's
where
I'm
confused!
It's
like
it's
almost
like
this.
The
problem
isn't
that
volunteers
write
too
long
of
PR's.
It's
that
they're
volunteers,
with
no
sort
of
incentive
structure
to
make
them
I,
don't
know,
structure
a
criteria
of
success
around
fast,
happy
communities,
they're
serving.
D
So
that
what
these
are
based
off
of
was
the
it
was
the
Bitcoin
Improvement
protocol,
as
well
as
the
the
python
Improvement
protocol
and
that's
kind
of
the
heritage
of
this
more
so
than
the
ietf
processes,
and
in
those
there
is
no
real
paid.
Editor
a
lot
of
people
work
on
python.
You
know
to
have
your
your
page,
IP
python
you're
not
paid
to
work
on
python
you're
paid
at
Google
to
count
ads,
and
they
decide
that
it
would
be
valuable
for
them
to
have
somebody
building
core
python,
because
it
helps
them
build.
D
Apps
I
think
that's
more
to
the
core
of
what
it
was
originally
founded
on,
and
he
looked
at
all
the
list
of
the
original
Founders.
They
were
all
either
employed
by
the
ethereum
foundation,
or
they
had
companies
that
were
building
early
ethereum
things
built
off
of
hopes
and
dreams
rather
than
actual
money,
so
that
that
truly
is
the
foundation
of
where
this
came
from
is
is
hopes
and
dreams,
not
a
formal
process,
because
that
ETF
wasn't
even
found
until
the
mid
80s.
D
It
was
just
an
RFC
process
back
before
the
internet
was
when
it
was
academic,
research
process
and
I.
Think
if
we're
going
to
compare
the
EIP
process,
the
ieta
process
I
think
we're
still
in
the
RFC
land.
We
don't
have
yet
a
need
for
formal
LLC
around
this
process.
I,
don't
think
we're
large
enough
yet
I,
don't
think
the
community
is
large
enough.
Yet
I
want
to
get
it
there
there
and
the
way
we
need
to
get
there
is
and
I'm
serious
I
will
volunteer.
D
If
there's
a
need
for
people
on
the
ERC
side,
I'll
do
it
on
the
EIP
side,
but
I,
don't
think
that's
where
getting
a
shortage
is
going
to
be.
I
will
volunteer
to
help
review
these
and
get
these
through
the
processes.
If
that's
what
needed
to
grow
it
because
the
process
needs
to
serve
the
community
to
not
serve
the
editors.
B
I
mean
I.
My
only
disagreement
with
anything
that's
been
said
today
is
that
we're
making
no
progress
because
just
attending
the
last
four
feels
to
me
like
each
of
these
meetings,
the
Gap
seems
smaller
between
between
everyone's
definition
of
success.
I
mean
it
sounds
to
me,
like
the
the
I've
I've,
just
been
talking
to
people
in
other
corners
of
the
universe,
about
like
the
wallet
stuff.
Primarily
for
me,
that's
the
fourth
group
that
should
exist,
but,
like
it.
D
B
I
agree
for
everybody:
if
the
wallet
is
the
working
group
at
the
court
and
throw
a
working
group
and
the
sort
of
like
one
volunteer
like
the
way
you
described
it
as
like
one
one
multi-editor,
he
each
would
have
at
least
one
editor,
but
definitely
one
editor.
That
also
coordinates
with
the
other
groups,
like
that.
D
From
my
perspective
for
this
third
group
this
this
group,
on
top
to
succeed,
it
can't
be
forced
as
a
function
of
the
split
it
needs
to
naturally
grow
out
from
all
from
ACD
and
from
from
the
EIP
process,
from
the
ERC
process
or
from
the
wallet
process
and
grew
up
and
show
and
find
the
the
gaps.
They
can't
be
filled
from
simple
coordination.
That
requires
the
organization.
I,
think
the
need
reads:
acquire
the
org
rather
than
the
org
searching
for
a
need.
That's
my
concern.
D
If
we
create
this,
that
it's
not
really
going
to
solve
any
problems,
we're
just
going
to
shuffle
where
the
problems
are.
This
is
this
is
a
bold
move
that
we
need
to
just
separate
it,
and
it
is
absolutely
a
leap
of
faith,
but
if
there
is
a
need
for
third
group,
then
it'll
be
apparent
that
this
is
what
we
need
and
the
people
that
see
it
will
come
together
and
build
it
on
top
of
it.
D
But
I
honestly
think
right
now
that
just
email,
coordination
and
PR
coordination
in
each
group
will
still
have
high
standards
and
still
have
high
processes.
Do
they
necessarily
need
to
be
the
same
and
centrally
coordinated?
That's
what
I
questioned,
but
if
there's
other
values
that
come
from
a
third
group
and
that's
where
the
value
can
be
added.
D
D
C
D
The
only
way
we
ever
get
progress
on
major
issues
is
to
move
the
Overton
window,
and
that
is
the
definition
of
dysfunctional.
This
is
not
the
first
time
that
the
original
window
has
had
been
moved.
We
have
to
do
the
end
move
to
break
this
pattern.
Otherwise
it's
just
going
to
become
a
continual
series
of
one
upsmanship
I'm
10
minutes
late
to
the
eof
call.
I
really
should
know
that
yeah.
That
sounds
important.
B
Don't
worry
thanks
for
staying
after
I
I
found
it
very
helpful,
at
least.
B
I
yeah
I'm
not
sure
how
to
what
what
vital
words
are.
All
I
guess:
try
to
mimic
puja's
minute
note,
PR
policy
to
close
this
up
thanks.
Everyone.