►
From YouTube: EIPIP Meeting 85
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/248
A
Welcome
to
eipip
meeting
85,
we
have
agenda
issue
number
248
at
eipip
GitHub
repository
for
discussion.
We
have
some
eips,
which
are
already
in
final
status
and
there
are
respective
PRS
to
make
some
changes
in
that
will
be
discussing
the
issue
of
EIP
and
ERC
GitHub
repository
that
we
have
been
discussing
for
past
few
meetings
and
I
can
provide
updates
on
eips
inside
and
maybe
followed
by
EIP
editing
office
hour.
So
starting
with
the
first
item
listed
on
the
agenda
changes
to
final
proposal,
the
first
PR
here
is
a
7295.
A
B
If
it
was
valid
solidity,
When,
It,
Was
Written,
then
we
should
probably
keep
it.
If
it's
invalid
solidity,
then
it's
fine
to
change
it.
A
Could
we
move
on
to
the
next
item
and
I
just
wanted
to
bring
it
to
the
attention
yep
perfect,
so
the
next
one
is
a
PR
number
7261.
It
is
a
change
proposed
to
EIP
6059.
A
This
also
seems
to
be
a
small
change.
The
author
here
is
a
willing
to
add
a
statement,
a
sentence
which
is
like
you
know
when
this
proposal
may
not
be
good,
and
it's
just
a
statement
to
like
let
implementers
know
about
it.
No
spec
changes
here.
A
A
Okay,
before
we
move
on
I
see,
we
are
joined
by
more
editors
here,
so
just
to
let
people
know
that
we
have
already
taken
up
two
PR's,
seven,
two,
nine
five
and
seven
two
six
one.
Those
are
proposed
changes
to
funnel
eips.
If
you
guys
have
any
thought
comments
or
objection
on
that
PR,
please
add
as
a
comment,
so
we
can
close
it
and
we
can
also
inform
the
author
and
if
it
seems
generally
good
and
not
a
big
change,
we
can
perhaps
merge
that
moving
on
to
the
last
proposal.
A
B
A
Thank
you
all
right.
Moving
on
to
the
next
item,
which
is
discussion
continued
from
the
past
meeting,
we
have
EIP
ERC,
GitHub
repositories,
split
that
we
were
discussing
so
for
a
quick
recap.
Light
plan
opened
a
PR
7206
to
split
the
GitHub
repository
in
the
last
meeting.
We
were
evaluating
the
effect
of
split
on
ERC
community
Victor.
A
Post,
split
I,
don't
see
William,
I'm,
sorry
I,
don't
say
Victor
on
the
call
today,
but
he
has
already
updated
on
the
Discord
that
he
had
a
meeting
of
all
ERC
Dev
and
it
seems
like
ERC
developers
or
authors
are
not
strongly
opposing
to
this
split.
They
are
generally
okay
with
whatever
the
process
is.
They
just
want
a
clear
communication,
so
it
can
be
followed
yeah
with
this.
A
Perhaps
we
can
start
sharing,
updates
and
add
comments
and
I
suppose
it
would
be
a
good
idea
to
take
a
look
at
the
hack,
MD
and
discuss
next
steps
to
you
know
getting
volunteers
for
specific
actions.
A
I
don't
know
Juan
if
you
would
like
to
maybe
talk
about
the
document
and
share
the
next
steps.
Yeah
and
yeah
perhaps
update
all
of
us.
C
I
I
don't
have
very
strong
opinions
about
the
process.
I
was
trying
to
just
sort
of
as
The
Outsider
play
secretary
and
just
write
down
ideas.
I
saw
in
different
threads
in
different
places
on
the
across
the
Discord
additions
and
the
pr
threads
and
I.
Don't
necessarily
you
know,
I'm
unqualified,
to
own
it
or
to
mediate.
If
people
disagree
with
any
of
the
items,
I
was
just
trying
to
throw
it
together
to
have
you
know
a
draft
to
work
from.
C
If,
if
anyone
has
strong
opinions,
the
heck
MD,
hopefully
is
not
access
controlled
and
anyone
should
be
able
to
change
it.
C
D
C
A
A
Do
have
a
Greg's
proposal
added
as
next
item.
I
am
fine
going
over
that,
because,
if
I
remember
correctly
like
mentioned
that,
if
we
take
a
look
into
his
PR,
that
perhaps
will
help
him.
You
know
get
motivated
to
you
know,
think
about
it
and
it
will
solve
some
of
the
issues.
Do
you
think
that
would
be
a
good
approach
to
First,
discuss
that
and
we
can
come
back
on
this
hack
MD
after
that
issue?.
E
D
D
E
It's
I'm
not
finding
it
adequate.
That's
why
I've
made
the
pr
to
indicate
the
direction
of
a
plan
that
makes
sense
to
me.
We
we
can
discuss
this
or
not.
A
A
No
sorry
and
no
worries
all
right,
so
let
me
bring
up
that.
C
D
E
The
the
comment
on
the
commit
pretty
much
summarizes,
I.
Think,
of
course,
if
you
have
particular
things
to
go
through
that's
fine
too,
but
for
General
discussion.
The
comment
is
I.
Think
still
a
good
summary.
C
Yeah
I
I
think
maybe
since
it's
your
PR
and
there's,
you
know
change
requests
throughout
and
some
topics
you
could.
You
could
guide
us
to
what
what
you'd
want
to
discuss
with
a
group
to
decide
on
change
requests
then
update.
E
See
Victor
wasn't
able
to
make
it
today.
The
pain
I've
seen
and
experienced
as
an
author
is,
in
my
opinion,
we're
in
general
way
too
picky,
but
especially
we're
way
too
picky
way
too
early.
It's
it's
a
pain,
just
getting
a
draft
into
the
system,
but
until
you
have
a
draft
in
it
can
be
difficult
to
get
discussion
threads
going
to
have
a
number
to
refer
to.
E
So
the
main
concept
here
is
just
to
make
it
easier
to
get
a
draft
in
and
tighten
the
standards
as
we
move
through
the
process
and
so
I've
made
specific
PRS,
but
I'm
not
wedded
to
the
specific
PRS
I
simply
and
presenting
the
concept
of
tightening
as
we
go
and
doing
it
at
the
transition
points.
So
people
can
get
into
the
process
and
work
on
their
proposal
without
a
constant
battle
of
your
doing.
E
Fine,
you
make
a
change
and
the
ipw
says
Nope
not
anymore,
and
suddenly
a
short
session
of
work
becomes
a
long
session
of
work,
or
you
discover
that,
oh,
you
can
no
longer
use
that
link.
Your
whole
proposal
is
stuck
just.
These
are
pain
points.
It's
just
a
painful
process
for
people
on
link
policy.
I
really
think
I
think
we're
too
tight
on
it,
but
certainly
at
the
draft
phase.
If
some,
if
someone
needs
to
use
a
link
or
wants
to
in
the
draft
okay,
we've
set
it
up.
E
That
will
need
to
go
through
a
process
of
approving
that,
but
please
let
it
into
the
draft
so
that
the
draft
makes
sense.
While
we
go
through
that
process
and
I've
suggested
actually
tightening
up
legs
as
much
as
possible
having
a
full
citation
into
the
literature
so
that
if
a
link
goes
404
you're,
not
just
scratching
your
head,
you
have
an
author,
you
have
a
title.
Hopefully
you
have
the
journal
A
publication
date,
so
you
can
probably
find
another
copy
online.
E
If
necessary,
you
can
go
to
a
library,
get
a
copy
on
interlibrary
loan.
You
can
send
an
email
to
the
author
lots
of
ways
to
get
a
copy
if
a
link
goes
404..
So
having
a
link
is
nice,
but
it's
actually
less
important
than
a
proper
citation.
C
Or
or
a
DOI
I
love
the
DOI
idea,
because
yeah
dois
or
even
ipfs,
cids
sort
of
create
a
yeah
location,
independent
fall
back
I
like
that.
A
lot
I,
I
think
I,
don't
think,
there's
going
to
be
much
pushback
on
any
of
those
details.
C
I
I
think
the
block,
like
the
things
to
resolve
to
merge
this
quickly
would
be
the
technical
assistant
idea.
There's
seemed
to
be
a
little
contentious
and
yeah
I
I,
don't
know
the
history
there
you
if,
if
I
I,
definitely
know
the
analogy
to
ITF
and
I.
Guess
if
you
you,
it
probably
isn't
the
right
place
to
talk
about
like
money
or
or
formal.
C
But
if,
if
it
is
a
concept
that
already
exists,
if
there
are,
if
there
is
already
a
way
to
call
someone,
an
expert
enough
to
advise
is
where's
the
where's,
the
disagreement
I
think.
E
The
problem
part
of
the
problem
is:
we've
got
too
many
low
quality
drafts.
That
is
a
problem.
I,
don't
think
we
can
bot
our
way
out
of
that
problem.
Yeah
and
we
haven't
gotten
like
the
ITF.
E
E
Something
comes
in
for
publication
and
you
know
two
or
three
experts
review
it
before
it
goes
in,
and
we've
had
some
talk
on
this
that,
if,
if
you
can't
find
two
people
to
help
you
with
this
draft,
then
is
it
really
worth
standardizing?
If
nobody
cares
to
read
it,
but
you
what's
the
point:
if
we
can
establish
this
as
a
practice
and
often
Publishers
push
back
on
the
author
to
say:
hey
find
some
reviewers
we're,
not
experts
here.
We're
just
we're.
E
Just
editors
find
us
some
reviewers
to
work
with
you
on
this,
so
that
we
have
you
know
we
have
some
reason
to
think.
It's
technically
sound.
C
C
So
I
think
I
think
people
are
I,
think
people
are
thinking
about
being
permissive
of
PRS,
but
postponing
the
numbering
perhaps,
and
that
I
don't
know
if
that
balances
the
the
pain
of
proposers
against
the
pain
of
editors.
Well
enough,
but
I
do
think
you
know
like
just
to
just
to
give
a
comparative
perspective
Casa,
which
is,
you
know,
pretty
different,
pretty
different
animal
but
like
diff,
two
sort
of
has
an
informal
two
competitors
rule
like
it.
C
It's
I've
been
trying
to
make
it
more
formal
at
dif
that
a
new
work
item
proposal
that
just
comes
from
people
that
are
already
collaborating
on
a
product
or
you
know
a
thing
they're
building
where
they're
already
collaborating
like
that,
isn't
really
a
place
for
a
standard
I
think
that
to
publish
it
as
a
document
you
could
require
BYO
technical
assistant
or
you
could
require
of
orbs
something
that
looks
like
the
thinnest
possible
precursor
to
a
working
group
like
those
might
be
ways
to
I
mean,
particularly
if
combined
with
this
idea
of
a
pre-numbering
or
you
know,
except
the
PR,
but
don't
give
it
a
number
till
it
has
someone
to
review
it.
C
B
It's
just
if
we
give
drafty
IPS
a
number
and
URL
that
changes
when
they
get
promoted
to
a
review,
whether
that's
you
know
a
different
number
or
using
the
title
or
whatever
I
think
that
would
give
enough
difference
between
a
draft
and
a
real
EIP
that
I'd
be
okay
with
like
a
lower
standard
for
those
eips.
E
I'm
I
guess
I'm
suggesting
an
initial
stage,
which
is
just
a
draft
PR.
They
can
hang
out
there
forever
and
never
be
merged
and
they
don't
need
a
number
and
that's
the
stage
which
you
want
some
peer
review
before
it's
numbered
and
becomes
a
draft.
F
B
Now
we
have
drafts
have
very
very
like
you:
don't
even
have
to
have
a
finished
EIP
right
like
you
can
you
can
leave
to
do's
and
all
sorts.
E
Think
so
so
we
we're
just
getting
flooded
with
drafts
that
are
too
low
quality
to
bother
looking
at
or
just
they're
too
far
out
of
anyone's
technical
expertise
to
help
with.
So
it's
simply
not
uncommon
for
technical
journals
to
do
a
phase
of
peer
review
before
it
gets
very
far
at
all.
E
They
don't
put
in
the
work
of
of
actually
editing
until
some
peer
reviewers
have
said.
This
is
technically
sound
and.
D
D
E
I,
don't
I'm
saying
a
rule:
the
editors
will
not
merge
a
draft
until
some
peer
reviewers
have
actually
looked
at
it.
It
will
need
to
establish
a
little
bit
of
process
there.
So
it's
clear
this
is
a
process.
This
isn't
go
out
and
find
some
things.
It's
like.
No,
we
act.
We
want
actual
actual
work
on
the
draft
PR
until
the
reviewers
are
happy
with
it.
G
So
I
think
this
is
a
good
spot
to
jump
into
my
meta
complaint.
This
doesn't
address
the
issue
that
the
core
eips
and
the
erc's
are
two
increasingly
Divergent
communities
with
two
increasingly
resurgent
process
needs
getting
a
person
with
the
technical
knowledge
to
review
a
core
EIP
proposal
is
going
to
be
easy.
G
Yeah,
it's
all
over
the
place
and
getting
someone
to
review
a
random
ERC
for
random
token
protocol
that
may
or
may
not
be
viable,
is
going
to
be
increasingly
difficult
and
the
standards
that
need
to
be
put
to
a
core
EIP
versus
some
ERC
standard.
That
just
needs
for
to
some
extent
have
well-formed.
Solidity
are
increasingly
in
diversion
and
have
very
different
needs.
G
E
E
It
doesn't
seem
complicated
with
GitHub
you
put
in
a
draft
PR.
It
doesn't
merge
until
the
editors
approve
it.
So
it's
easy
for
the
editors
to
say
we're
not
going
to
merge
it
until
you
know
until
I
guess
at
least
one
technical
expert
helps
us
review
it
and
that
can
be
at
either.
That
can
be
a
standard
process
or
at
our
discussion.
Often
an
editor
has
the
skill
to
look
at
it
and
and
do
that
job
often
that
it
or
doesn't
have
the
skill.
G
We
don't
need
this
type
of
a
process
to
move
stuff
in
core
core
will
ignore
the
EIP
process
and
set
up
their
own
standards
rather
than
go
through
these.
The
needs
are
Divergent.
Very
divergent
This
is
not
something
that
core
protocol
changes
go
through,
except
as
a
final
box
checking
step
just
to
satisfy
some
people,
we're
increasingly
abandoning
the
EIP
process,
because
it's
not
serving
the
needs
of
the
core
protocol
I
understand,
which
is
why
we
need
to
split
it.
If
you
understand
it,
why
don't
you
support
splitting
it.
A
E
Thought
he
is
against
this
I've
I've
set
I've
I've
had
this
discussion
so
many
times
for
so
many
years
and
I'm
not
alone.
In
my
opinion,
it's
more
like
the
people
who
agree
with
me
have
just
gone
away,
but
I'm,
not
I'm,
not
an
alterably
proposed,
what's
laid
out,
doesn't
look
so
bad
I
have
strong
fears
that
the
Divergence
will
actually
hurt
us
so
we're
better
off
preventing
the
Divergence,
because.
E
D
E
F
D
E
D
But
I'm
saying
that
you,
your
arguments
against
splitting,
like
they
don't
have
a
lot
of
basis
and
like
reason
it's
so
far,
I've
heard
just
generalizations
about.
Oh,
it's
going
to
fragment
the
process.
It's
going
to
make
it
harder.
You
know
Etc,
but
there's
not
like
specific
things
that
you're
stating
like
this
is
a
bad
thing,
whereas
we've
given
specific
things
about
the
split
that
will
benefit
the
core
Dev
community
and
generally
people
from
the
core
Dev
community
and
the
ERC
Community
are
not
opposed
to
this
questions.
E
G
E
G
And
what
we're
on
the
precipice
of
is
people
abandoning
the
EIP
process?
It's
already
happening
in
the
core
protocol.
We
have
execution
specs,
we
have
execution
spec
tests,
nothing
networking
has
gone
through
in
a
long
time.
Slowly,
but
surely
it's
peeling
off-
and
this
is
bad
I-
mean
if
you're
going
to
wind
up
it's
just
an
ERC
repo.
Anyway,
if
we
don't
acknowledge
this
I.
E
E
Could
be
and.
E
No,
if
I
walk
away,
I,
walk
away,
that's
okay,
I'm
I'm,
a
very
busy
old
man!
So
and
that's
that's,
not
a
that's,
not
a
hostile
act
on
my
part.
It
would
just
be
you.
People
need
to
do
what
you
need
to
do
and,
if
I'm
not
comfortable
with
doing
it.
That
way.
E
It's
okay
for
me
to
say:
okay,
do
what
you
need
to
do.
It
may
well
work
out
just
fine.
D
I
think
it's
time
to
do
what
we
need
to
do.
We've
had
the
eapip
process
for
three
years.
E
E
Some
of
it
looks
like
the
core
devs
are
trying
to
use
the
EIP
process
for
things
that
have
nothing
to
do
with
the
editorial
process.
The
the
status
of
something
as
a
as
a
as
an
edit
edited
document,
and
the
status
of
a
proposal
moving
through
to
get
into
the
protocol
have
different
stages.
E
D
G
E
E
G
We
need
we
want
to
change
the
process
and
it
takes
like
a
year
to
get
a
process
change
through
and
that's
just
it
doesn't
align
with
what
we
need
with
our
workflow,
which
is
where
we're
putting
in
hack
MDS
we're
putting
in
separate
repos.
Why
we're
basically
abandoning
the
process?
Because
it's
not
suiting
our
needs.
Why.
G
G
Like
the
w3c,
like
the
what
would
like
there's
all
sorts
of
things
that
are
like,
like
the
PIP
I
mean
they,
they
split
to
reflect
the
needs
of
the
communities
when
they
diverge.
E
Other
tables
the
ietf
editors
did
not
divide
themselves
into
multiple
organizations,
just
because
the
ITF
covers
a
huge
range
of
Technology.
E
So
I:
that's
where
I'm
going
loosen
our
workflow,
so
it's
not
in
their
way
and
find
out.
Well,
how
can
you
clean
up
your
workflow
I?
Get
that
the
that
the
protocol
level
they've
been
working
directly
with
their
python
specification
and
that's
where
some
process
probably
needs
to
change
that
the
EIP
really
isn't
done
until
after
they've
done
their
work
on
the
reference,
implementation
and
I?
Don't
I
don't
have
a
problem
with
that.
E
E
G
G
G
Ercs,
do
not
necessarily
ever
need
a
raw
and
Main
net;
they
could
run
on
all
sorts
of
the
pick.
Your
random
alt,
L1
or
L2.
The
application
layer
has
nothing
to
do
with
with
changes
to
the
consensus
layer
with
changes
to
the
networking
between
the
two
clients
between
the
the
two
different
layers,
they're,
fundamentally
different
layers,
that
the
only
interact
in
very
few
places.
E
It's
not
our
problem.
If,
if
you
prefer
to
use
hack
MDS
rather
than
use,
ethereum
PM.
D
E
E
It
was
a
pretty
solid,
long-term
intention.
So
that's
a
lot
of
what's
going
on
here
and
I
have
a
lot
invested
in
that.
G
E
E
And
that's
where,
with
no
hostility,
I
will
need
to
move
on
if
I've
decided,
the
philosophy
no
longer
corresponds
to
the
philosophy
we
had,
which
is
that
were
Publishers.
All
we're
trying
to
do
is
to
get
a
good
final
document
at
the
end
and
with
the
core
devs.
We
always
considered
them
to
be
a
separate
organization
who
could
pull
documents
out
of
our
process
because
their
workflow
is
not
ours.
E
All
we
wanted
was
to
do
our
best
to
get
a
final
document
ready
to
describe
what
actually
went
on
to
the
main
net.
D
I
mean
that's
still
the
goal.
It's
just
the
way
that
we're
going
about.
It
is
disenfranchising
the
people
who
are
writing
the
documents
and
involved
in
the
process
of
dealing
with
the
documents.
So
it's
like
I'm
kind
of
ingenuous
to
say
that
that's
the
goal
to
have
the
best
final
documents
when
we
don't
listen
to
the
feedback
from
the
actual
creators
of
these
documents.
E
And
I'm
hearing
two
sorts
of
problems:
one
sort
is
just
the
difficulty
of
dealing
with
the
editorial
process
and
that's
this
IP
is
trying
to
solve
some
of
those
problems
and
lo,
it's
low
hanging.
Fruit
is
low-hanging
fruit.
If
you.
D
Just
but
again
like
at
the
very
beginning
of
this
debate,
we
came
to
a
specific
propose
that
you
made
where
you
feel
that
there
should
be
more
peer
review.
That
happens
before
something
goes
to
the
draft
Daniel
says
specifically,
this
would
be
easy
to
have
with
core
devs
yeah
at
some
stage
in
the
process,
it's
very
hard
to
have
with
erc's,
because
they're
so
fragmented
and.
B
D
Is
just
like
a
clear
place
where
we
can't
easily
have
some,
you
know
rule
across
both
categories
of
VIPs
and
apply
them
in
the
same
way.
E
G
E
I'm
simply
in
this
case
I'm
simply
saying
the
court
proposals
or
more
likely
to
be
reviewed
and
solid
right
away
and
erc's
are
more
likely
to
be
not
solid
or
not
useful.
So.
F
E
B
E
E
E
It
won't
get
through
our
bot,
so
we're
not
going
to
put
it
in
until
it
does
that's
an
easy
pain
point
to
get
rid
of
it's
clearing
out
low-hanging
fruit,
that's
not
very
controversial,
is
worth
doing.
It
eliminates
some
pain
right
away.
E
E
Explicitly
not
giving
anybody
special
privileges
and
already
it's
the
case
that
the
editors
have
to
approve
a
draft
before
it
goes
into
the
repo
I'm,
simply
saying:
if
the
editor's
discretion
they
can
ask
for
outside
technical
review
and
tell
the
author
that
we
are
not
confident
to
review
this
or
to
the
extent
we
are,
we
don't
think
this
is
up
to
Snuff
and
you
need
help
so
we'll
work
with
you
to
try
and
find
that
help,
and
this
is
not
a
core
Dev
versus
CRC
thing.
We
will
get
Court
proposals
that
have
the
same.
E
You
know
you
look
at
it
and
you
just
go.
This
doesn't
make
sense.
If
it
does,
somebody
needs
to
help
this
guy
so.
G
E
A
I
I
would
like
to
like
cite
an
example
here
for
one
of
the
latest
CL
side
proposal
that
has
been
added
to
EIP
repository
as
core,
and
the
proposal
number
is
7044
and
there
is
another
proposal
in
progress
which
is
a
eip6110
for
both
proposals.
What
I
noticed
for
them
is
like
their
discussion
to
thread
is
completely
empty.
There
was
no
discussion
that
is
public,
because
discussion
definitely
happened.
A
It
happened
on
client,
Dev
meeting
and
perhaps
in
the
client,
a
specific
spec
repos,
so
it
is
not
easily
accessible
following
the
process
of
whatever
has
been
established.
So
far
is
also
helpful
for
core
EIP
is
what
I'm,
considering
it's
just
that
we
need
to.
Let
people
know
about
the
process.
One
other
common
thing
about
these
two
specific
proposals
coming
up
from
the
CL
side:
I
I'm,
sorry,
6110,
I,
guess-
is
on
El,
but
7044
is
on
sale
that
they
are
not
aware.
A
The,
Proposal,
I
think
the
spec
has
already
been
implemented,
because
that
is
a
part
of
denub
upgrade,
but
the
proposal
still
is
in
the
draft
status.
It
is
not
even
in
the
review
status,
which
would
be
an
ideal
status
for
that
proposal.
So
what
I
felt
like
the
proposer,
the
author?
They
have
no
issue
moving
the
proposal
from
draft
to
review
it's
just
that
they
are
not
aware
if
we
let
them
know
that
this
is
the
process
and
you
want
to
follow
I'm
still
hoping
that
it
will
work
out
for
those
people.
A
But
going
back
to
Greg's
initial
PR
I
think
Greg.
It
would
be
a
good
idea
to
talk
about
7230
the
pain
relief
point
that
you
are
suggesting
and
get
an
agreement
on
what
we
agree
and
if
this
can
be
merged
because
I'm,
assuming
that,
if
this
can
be
merged,
perhaps
we
can
move
on
so
I
see
from
the
chat.
Lifeline
is
not
in
favor
of
the
draft
and
numbering
idea.
A
A
It's
always
a
good
idea
to
have
a
smaller
PR,
so
we
can
get
clarity
on
situation.
We
can
keep
moving
on
like
if
this
particular
section,
like
draft
numbers
thing,
can
be
moved
out.
What
is
the
next
point
that
we
don't
agree
on
like
as
an
editor's
group?
They
are
not
comfortable
moving
this
to
eip1.
If
they
are,
then
that's
a
small
step,
but
a
step
forward
in
improving
the
process.
A
A
The
idea
we
can
definitely
take
it
up
in
the
thread
and
Greg
not
saying
that
it
is
going
to
happen
just
today,
but
again,
considering
both
the
possibility
of
splitting
as
well
being
one
of
the
possibilities
for
repo.
It
would
be
a
good
idea
to
follow
the
you
know
proposed
and
next
steps
to
understand.
If,
at
all,
we
go
ahead
with
the
splitting,
we
are
in
a
good
position.
We
are
in
a
comfortable
position
and
nothing
is
breaking
up.
A
So
if
it
is
fine,
we
can
perhaps
in
next
10
minutes
quickly
go
through
the
hack
MD
that
is
being
proposed
here.
It
will
give
an
assurance
to
community
I
suppose
that
if
the
split
is
happening
we
are
not
abandoned,
we
are
in
a
good
hands.
F
A
All
right,
I,
think
of
just
to
make
good
use
of
the
time.
Let's
quickly
go
over
the
points,
we
will
continue
discussing
Greg's
PR
in
the
thread
and
see
if
it
can
be
split
and
PR
number
7230
can
be
merged.
At
least
it
will
give
some
relief
to
the
present
process
and
editors,
and
then
we
will.
A
We
will
separately
discuss
the
pr
which
is
split
or
coming
up
as
new
and
for
this
time
for
people
who
are
in
favor
of
having
this
a
split,
but
they
are
wondering
if
the
split
will
be
useful
or
helpful.
Let's
go
ahead
with
the
hack
MD,
with
proposed
process.
I
think
collecting
thoughts
from
Matt
and
other
people
who
are
in
support
of
this
split
would
be
a
good
idea
and
it
will
be
helpful
for
people
like
Juan
and
us
to
you
know,
coordinate
and
have
things
in
place
before
before
the
split.
A
Juan,
if
you
would
like
to
maybe
pull
up
the
document,
and
we
can
discuss
specific
points
there.
A
Yeah
looks
like
he
he
has
been
disconnected,
but
okay,
fine,
the
Hakim
day,
is
with
everybody.
I
have
also
added
here
in
the
agenda:
I'm
gonna
re-share
it
okay,
someone
did
pull
up.
Thank
you
any
specific
point
that
people
think
is
worth
discussing
in
this
group.
We
can
perhaps
talk
about
it.
Any
objectionable
point
would
be
priority
because
that's
what
we
would
like
to
resolve.
A
A
E
F
D
D
I
mean
I
have
proposed
on
many
occasions,
even
outside
of
the
conversation
of
the
splits
that
we
should
just
have
a
shared
document,
some
sort
of
hack,
MD,
some
sort
of
GitHub
or
Google
sheet,
whatever
some
spreadsheet,
that
we
can
all
use
and
just
update
the
latest
number
that's
used
in
the
pr
that
it's
assigned
to
and
just
manually
assign
them
like
that,
like
we
have
so
many
problems
with
numbering
like
we
should
just
do
that.
Instead
of
using
the
pr
numbers,
that's
something
we
can
do
right
now.
A
D
A
Okay,
I
think
that
is
a
good
point
and
perhaps
we'd
like
to
get
an
agreement
of
all
eipi
editors
because
they
are
responsible
for
allocating
the
EAP
number
and
we
have
been
joined
by
a
new
editor
kind
of
no
I.
Don't
know
we
can
call
them
editor,
but
definitely
helping
with
the
EIP
number
allocation,
and
it
would
be
a
work
in
which
all
all
the
EAP
editor
and
that
user
would
work
together
to
allocate
so
I
am
open
to
keep
this
as
a
discussion
discussion
point
for
next
meeting.
A
How
do
we
want
to
go
ahead
with
the
EIP
numbering?
Maybe
we
can.
E
F
D
F
D
I
think
we
can
just
assign
the
EIP
number
and
have
the
author
do
it?
Okay,.
A
Do
we
want
to
have
it
like
for
a
particular
number
in
mind,
because
it
would
be
easier
to
communicate
it
to
community
that
from
this
number
onwards,
whatever
number
allocation
you
see
is
based
on
this
process?.
F
A
D
B
D
B
D
B
A
B
No,
we
we
won't
have
issues
or
like
pull
requests
and
code
search,
won't
work,
so
we
have
to
create
a
new
repo
and
push
the
commits
to
it.
A
F
A
Case
we
need
a
plan
to
have
the
secret
shared
over
there
as
well.
A
B
A
Okay,
so
definitely
will
communicate
this
to
Panda
and
whenever
we
are
ready,
we
are
just
trying
to
make
sure
that
our
checklists
are
covered.
So
whenever
we
are
ready,
we
can
do
that
if
at
all
needed,
correct
I
am
still
there
if
at
all
needed,
I.
A
Think
it's
a
good
discussion
for
today
considering
we
still
have
some
pros
cons
going
on
and
I'm
hoping
that
if
some
of
the
concerns
of
Gregs
are
already
answered
and
the
pr
is
merged,
perhaps
we
can
have
him
on
board
as
well
and
we
will
get
to
understand
better.
A
We
have
just
two
minutes
left
on
the
call
and
yeah
anything
specific,
very
well.
I
have
also
shared
the
hack
MD
file,
which
is
for
eips
insight
and
I've,
tried
to
add
this
image,
for
you
know
how
many
proposals
we
get
every
month
and
how
many
gets
merged
as
final.
A
Definitely
we
agree
that
most
of
the
proposals
which
are
not
merged
as
final
are
from
ERC
side,
because
the
number
of
ERC
proposals
are
higher,
but
at
the
same
time
this
is
also
true
that
proposals
which
are
being
merged
on
month-to-month
bases
are
mostly
from
ERC
side
as
well.
So
ERC
people
are
also
trying
to
follow
whatever
they
have
been
advise
to
and
get
their
proposal
merged
and
ERC.
Well,
that's
a
discussion
for
the
next
meeting
going
through
the
EIP
is
inside.
A
We
have
received
four
final
eips
for
the
month
of
July
as
on
July
12th
and
all
four
belong
to
ERC
category.
There
is
one
proposal
in
last
call
and
I
suppose
its
deadline
has
passed,
so
we
will
have
to
reach
out
to
the
author
to
ask
him
to
make
a
proposal
to
make
it
to
the
final
status.
A
With
three
new
drafts,
the
EIP
repository
seems
to
have
a
lot
of
open
pull
requests
which
would
need
some
addressing,
but
EIP
editing
office
hour
has
been
doing
great.
Thank
you,
Sam
for
taking
out
time
and
responding
to
particular
questions
of
new
Authors
who
are
trying
to
follow
the
process.
We
do
have
added
the
EIP
editing
office.
Our
meeting
recording
from
yesterday
you
can
find
that
in
agenda
and
agenda
for
the
next
meeting
is
also
linked
there.