►
From YouTube: EIPIP Meeting 63
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/170
A
Welcome
to
eipip
meeting
63,
we
have
quite
a
few
items
on
agenda
for
today.
I
see
we
are
joined
by
call
facts.
I
am
assuming
that
he
is
here
for
one
particular
topic
that
is
get
for
our
badges,
so
maybe
we
can
bump
that
up
and
start
from
there
before
we
get
into
our
usual
discussion.
Is
that
okay.
A
B
Absolutely
sounds
great,
thank
you
all
for
having
me
here
today.
My
name
is
Colfax
and
I
am
working
on
a
project
called
gitpo
app
and
essentially
what
gitpop
is
is
what
we're
doing
is
we're
working
on
issuing
poapps
that
represents
contributions
Central
to
the
ethereum
ecosystem.
So
here
I'll
just
share
my
screen
quickly.
B
B
We've
onboarded
about
600
repos
here,
including
like
ethereum.org
many
D5
projects,
core
tooling
projects,
and
the
goal
here
really
is
to
offer
recognition
for
the
work
that's
happening
and
through
the
issuance
and
Co-op.
So
you
can
see
here.
This
is
the
2022
ethereum.org
contributor,
Pro,
app,
there's
83
people
that
hold
it,
and
so
what
gitpo
app
is
doing
is
we've
integrated,
Co-op
issuance
into
GitHub,
and
specifically
most
of
the
projects
that
we
have.
B
Onboarded
are
software
projects
where
they
work
on
the
flow
of
like
submitting
code
through
PR
and
then
that
PR
getting
merged
and
I
open
up
an
issue
for
eipip
to
award
and
get
Pops
to
EIP
editors
and
contributors,
and
through
this
conversation
it
became
clear
to
me
that
sort
of
the
way
that
eips
are
developed
is
a
little
bit
different
from
just
writing
software.
And
so
what
I
wanted
to
discuss
with
you
guys
today
is
one
we're
excited
to
award
apps
to
everybody.
B
Who's
contributed
to
eips
in
any
sort
of
way,
and
we
would
do
that
sort
of
by
issuing
an
annual
contributor
pull
up
to
the
eip's
repo
and
we've
we're
working
on
onboarding.
Actually
a
few
of
these
other
repos
that
were
suggested,
and
so
today.
What
I
wanted
to
do
is
talk
to
you
about
the
tool
that
we've
built.
That
I
think
will
be
useful
for
awarding
gitpo
apps
to
EIP
editors,
given
that
it
doesn't
work
normally
on
just
like
a
pull
request
model
where
the
issue
or
where
the
pull
request.
B
Submitter
is
the
most
valuable
contributor
before
I,
get
into
sort
of
the
spec
of
the
tool.
I
wanted
to
show
you
guys
this
is
our
working
designed
for
the
EIP
gitpo
app
I'm
happy
to
take
any
feedback
offline,
but
I
just
wanted
to
share
this
with
you
guys.
I
can
share
this
in
the
in
the
zoom
chat
as
well.
B
If
anybody
would
like
to
take
a
look,
I
don't
know
if
anybody
has
any
feedback
or
any
thoughts
to
share
about
this
right
now,
if
you'd,
like
and
I
know,
it
says,
2023
we're
going
to
update
the
date
to
the
annual.
B
Awesome
thanks,
I
think
it's
particularly
cool
to
see
sort
of
like
the
imagery
around
the
ethereum
logo
and
the
different
components,
and
so
we're
there's
a
couple
other
repos
that
are
related
to
EIP,
editing
that
we're
working
on
a
different
git
pull
app
store,
for
example
like
eipw,
and
we're
sort
of
taking
sort
of
components
of
this
sort
of
ethereum
upgrading
process.
We're
diving
into
it.
B
So
here's
just
like
a
little
behind
the
scenes,
sort
of
aspects
of
like
how
we're
coming
up
with
our
designs
and
so
I'll
share
with
you
next
the
tool
that
we're
building
to
hopefully
allow
the
EIP
maintainers
to
award
get
polypsy
IP
editors.
Thank
you,
panda
pit
for
some
early
feedback.
B
Basically,
what
we're
planning
on
doing
is
building
a
bot,
and
we
already
have
some
components
of
this
already
built
and
basically
would
be
githo
app,
dash
bot
and
you'd
be
able
to
tag
it
on
a
given
issue
or
pull
request,
and
so
here's
like
an
example
one
here.
So
if
you
go
to
an
issue,
basically
what
you
would
be
able
to
do
is
say
this
was
a
particularly
important
issue.
B
So
yeah
I,
don't
know
if
I
was
talking
to
Panda
pip
before
in
terms
of
awarding
for
historical
contributions,
we
can
help
sort
of
automate
the
process
and
identifying
and
actually
executing
the
bot
for
like
past
ones,
but
on
an
ongoing
basis,
we're
hoping
to
sort
of
build
a
tool
that
can
integrate
into
your
existing
workflows
of
reviews,
and
you
can
award
them
on
the
Fly
for
for
Meaningful
contributions.
C
I
think
Victor
has
some
things
to
say.
D
D
C
Me,
you
might
kind
of.
D
So
is
it
better
now.
D
Okay,
yeah
I
love
the
ideas.
The
two
questions
I
have
is
one
is
that
how
do
we
avoid
rewarding
spammers?
Because
we
recently
seen
that
some
people
were
issuing
spam
posting
either
spec
issues
and
the
other
one
is:
how
do
we,
whether
we
have
considered
having
different
Milestones
or
contributors,
for
example
like
their
first
EIP
or
their
first
final,
or
things
like
that,
so
as
opposed
to
annual
contribution
or
in
addition
to
any
contribution?
So
that
would
be
true
of
my
feedback
and
by
the
way.
Thank
you
for
coming.
D
I
think
this
is
the
perfect
value
to
discuss
this,
because
you
have
Panda
cave
and
Sam
who
are
majorly
under
on
the
automation
side
of
those.
B
Awesome
yeah
two
good
questions,
also
yeah.
Thank
you
for
having
me
here.
I
think
it's
a
great
form
to
be
a
part
of
so
on
the
first
one
in
terms
of
fighting
spam.
This
is
something
that's
very
much
on
our
minds
and
the
initial,
like
the
the
architecture
of
git
Co-op
for
code
contributions,
specifically
only
Awards
collapse
for
merged
pull
requests
which
inherently
have
manual
review
in
them.
B
So
like
any
spammer
that
tries
to
burn
one
they're,
not
gonna,
get
it
because
the
code
is
not
is
only
going
to
be
merged
if
it's
actually
meaningful,
and
it
was
something
that
we
were.
Definitely
like.
Our
heightened
awareness.
We
had
a
heightened
awareness
about
around
our
launch,
which
happened
back
in
April
and
so
far
nobody's
reported
back,
like
an
increase
in
spam,
pull
requests
being
sent
as
a
result
of
earning
get
pull-ups.
B
In
fact,
somebody
actually
was
tweeting
yesterday
saying
that
it's
too
hard
to
earn
get
poapps
for
spam
contributions.
I
thought
it
was
kind
of
funny.
So,
in
terms
of
like
fighting
spam,
I
would
say
that
really
lies,
and
so
it's
going
to
be
only
a
manual
process
to
award
apps.
But.
D
B
If
we
want
the
EIP
bot
to
be
able
to
tag
the
gitbot,
we
can
work
out
those
implementation
details,
but
the
idea
at
least
the
way
that
I'm
envisioning.
It
is
one
of
the
maintainers
so
like
either
you
pen
to
pip
or
maybe
Sam.
If
a
particular
issue
or
pull
request
for
a
new
EIP
is
valuable,
you
guys
would
go
ahead
and
then
manually
tag.
The
GitHub.
E
C
I've
been
thinking
make
a
bot
that,
when
Erp
gets
merged
as
final
then
tags,
the
the
get
Pro
I
bought
to
then
assign
to
then
assign
the
githo
app,
and
it
would
be
the.
C
And
I
think
that
it's
pretty
and
I
think
that
it
should
not
be
too
difficult
to
do
that
and
since
the
AIP
I
don't
think
that
it
requires
any
configuration
with
Git
pop
itself,
just
because
the
EIP
bot
itself
has
admin.
So
if
the,
if
the
git
Co-op
does
it
by
pinging
GitHub
the
API
to
see
what
permissions
the
sender
has
well,
VIP
bot
has
the
permissions.
B
A
I'm
I
do
see
a
couple
of
them
might
need
to
the
bot
side,
but
I
I'll
quickly
mention
that
Panda
people
that
would
be
like
if
an
EIP
is
finalized,
then
the
bot
will
tag
the
person
or
the
set
of
authors
who
have
contributed
to
that.
But
if
you
are
making
any
changes
post
it
is
finalized
or
minor
changes
at
its
here
and
there.
A
In
that
case,
we
may
have
to
customize
that,
to
you
know
it.
C
B
That
sounds
good
to
me
too,
and
the
get
pop
bought
as
designed
can
support
that.
We
just
need
to
figure
out
how
the
EIP
bot
would
then
trigger
calling
to
get
brought
up.
C
I
could
just
have
it
use
the
GitHub
API
to
send
a
comment.
It's
not
that
difficult
awesome.
B
Cool,
thank
you
cool,
of
course,
and
then,
let's
see
to
address
Victor's
second
question.
B
So
the
first
question
was
about
spam
and
then
the
second
question
was
about
sort
of,
like
repeat
contributors
or
sort
of
like
scaling
that
up
the
way
that
we're
handling
that
right
now
for
code
contributions
is
we're
issuing
annual
contributor
get
Pro
apps,
and
so
you
can
actually
see
if
somebody's
track
record,
if
they've
earned
the
annual
contributor
get
pop
over
the
course
of
a
number
of
years,
like
2019,
2020
2021
we're
also,
we
haven't
released
this
yet,
but
we're
also
working
on
visualization
of
depth
of
contribution
within
a
year.
B
B
So
that's
one
aspect
of
it
and
then
secondly,
specifically
for
eips
I
think
it
could
be
interesting,
so
I
think
it's
a
good
start
to
work
on
just
issuing
this
annual
contributor
get
poapp
for
EIP
editors,
but
going
forward
if
you
guys
are
interested
for
particularly
impactful
eips.
If
there
were
some
specific
ones,
we
could
actually
create
a
customized
GitHub
app
with
its
own
design
and
award
that
just
to
the
folks
who
contributed
to
a
particular
EIP.
B
So,
for
example,
it
could
be
like
the
EIP
1559
app
so
I'm
just
throwing
that
out
there
as
an
idea.
If
there
are
particular
eips
that
you
want
to
award
separately
from
just
like
General
EIP
editing,
we
can
do
that
too.
B
That
makes
total
sense,
I'll
discuss
with
my
team
and
sort
of.
Maybe
we
can
yeah
discuss
with
the
community
or
something
but
yeah
just
throwing
it
out
as
an
option,
but
I
appreciate
that
cool.
We'll
add
some
next
steps,
I'll
sort
of
draw
up
the
feedback
that
you
guys
have
given.
B
Panda
pip
I'll
continue
to
coordinate
with
you
on
our
development
of
the
gitbot
and
how
you
can
tag
that
with
the
EIP
bot
and
we'll
go
forward
from
there.
I
just
want
to
say.
Thank
you
guys
so
much
for
having
me
here
today.
A
And
people
can
always
leave
comment
and
feedback.
I
have
shared
the
issue
that
is
on
eipip
GitHub
issue
number
is
one
three
four.
A
Thank
you.
Moving
on
Let's
start
from
item
number
one
which
is
proposals
to
include
in
Preamble.
We
have
collected
quite
a
few
proposals
which
are
there
to
suggest
some
edits
or
updates
for
preamble
in
eaps.
A
The
first
one
listed
here
is
ADD
finalized
date
to
eips
I
see
there
are
already
ongoing
conversation
yeah.
Anyone
has
any
commenting
thoughts
to
add
for
this
issue.
A
I'm,
sorry,
it
has
been
merged.
I
know
there
was
one
created
by
Witcher,
I
guess.
C
D
Yeah
that
one,
since
no
no
controversy
right,
no
one
has.
A
Any
thoughts
Sam
if
you're
talking
you
have
muted
you.
E
Know
I'm,
okay
with
adoptable
I
guess
yeah
I
can
I
can
approve
it.
D
A
A
So
we
could
move
on
to
number
two
I
mean
sub
item
for
this
one.
C
E
C
E
I'd,
rather
just
not
include
it
at
all,
I
think
if,
if
somebody
wants
to
withdraw
an
EIP
and
put
in
the
withdrawal
reason
superseded
by
eipx,
they're
perfectly
allowed
to
do
that,
but
I
don't
think
we
need
a
special
field
for
superseded.
A
E
A
That
we
have
presidents
of
doing
that,
like
with
withdrawal
we
generally
mentioned,
that
which
is
I
mean
if
there
is
the
reason
that
any
other
EIP
is
better
than
the
proposed
one.
We
do
mention
it
in
reason.
D
So
I'm
the
one
that
proposed
this,
because
it
was
inspired
by
ietf,
RFC
and
there's
the
RFC
field
for
rcpc,
so
that
the
whole
Community
can
continue
to
evolve
and
notify
the
future
readers
of
what
what's
something
is
being
updated.
D
So
as
much
as
I
respect
and
understand
the
concern
that
Sam's
had
I
think
we
can
I
love
to
kind
of
not
try
to
propose
a
proof
or
not
proof
of
this
PR
on
today's
meeting,
but
to
further
discuss
under
what
concerned
condition
and
who
are
able
to
add
such
thing
and
whether
we
enable
field
is
the
best
format
or
is
there
other
way?
We
can
do
that
signal.
I
can
I
can
take
that
offline
and
and
follow
up
in
the
future.
C
I
think
the
eip820
does
a
good
job
of
this,
so
I'm
just
going
to
quickly
send
a
link
to
the
markdown
file
in
the
chat.
So
what
it
does
is
before
any
of
the
settings.
It
has
like
a
big
thing
that
says:
ERC
1820
has
superseded
EOC
818.
So
basically
it's
a
hey
this.
This
is
the
authors
here
saying
that,
due
to
some
due
to
a
change
in
solidity,
actually
you
have
to
use
this
other
thing
instead
of
this,
yet.
A
We
can
definitely
keep
the
issue
open
for
another
few
weeks.
People
can
add
comments
and
thought.
A
And
yeah
is
that
a
good
resolution
Victor.
D
Yeah
I
Heard
the
concern
and
I'll
document
the
concerns
and
then
I
intend
to
continue
to
pursue
a
proper
way
to
indicate
that
So
yeah.
Thank
you
for
keeping
it
open.
A
Awesome
moving
on
the
next
one
is
proposal
proposal.
The
print
relates
to
field
issue.
Number
is
5274,
I
guess.
This
was
also
proposed
by
Victor.
D
Yes,
I
think
the
people
with
the
interprets
that
requires
you
differently.
Some
people
think
of
me
included,
see
that
requires
and
and
thought
that
it
means
a
to
implement
some
EIP.
It
requires
some
previous
pre-existing
VIPs
to
be
implemented,
to
be
final
and
to
be
to
be
final
for
sure,
but
to
be
implemented
as
well,
and
that's
that
seems
not
aligned
with
panda
and
with
mikao
and
so
I
think
that
requires
is
a
little
bit
confusing.
C
Maybe
we
don't
need
a
separate
required
to
field,
but
it
relates
to
field,
but
I,
wonder
if
we
could
just
I
mean
I
can
I'd
be
okay,
if,
if
in
eip1
we
changed
it
to
so
that
it's
only
eips
that
are
referenced
in
the
spec
that
need
to
be
included
in
the
requires
field.
I'd
be
okay
with
that
change.
D
So
may
I
ask
under
what
surfences
stance
do
we
feel
that
we
want
to
have
a
special
call
out
of
eits
being
referenced
other
than
the
body
already
have
a
requirement
to
link
to
EIP
if
they
mention
that
yeah.
C
I
I
would
be
okay
if
any
ip1
we
changed
it
to
be
anything,
that's
anything.
That's
included
in
the
spec
has
been
hidden
in
the
requires.
D
I'm
not
sure
sometimes
the
boundary
can
be
right.
For
example,
the
introduction
of
create
two
is
a
prerequisite
in
some
of
the
erc's,
but
that
you
don't
necessarily
need
to
understand
that
we
create
two
or
read
recreate
it
to
be
a
reader.
You
might
need
it
to
to
be
able
to
author
it,
and
if
someone
has
handled
that
for
you
on
a
dependency
or
SDK,
you
don't
have
to
understand,
create
too
right.
So
I
think.
D
So
what
I
feel
is
that's
if
we
make
a
heart
requirement
and
make
it
clear
of
what
required
means.
For
example,
if
you
we
say
that
technically.
C
We
didn't
catch
that
you,
you
kind
of,
like
you
might
die.
C
I
guess
the
last
one
is
the
advanced
digit
EIP
since
Mike
is
not
here,
I
well,
I
mean.
Is
there
any
reason
not
to
add
this
foreign.
C
A
I
think
we
had
a
discussion
about
this
in
the
past
and
there
was
some
agreement
disagreement.
The
issue
was
dropped
then,
but
it's
good
that
we
have
it
back
in
the
form
of
issue
and
yes,
we
have
consensus
there.
I
believe
we
just
need
a
pull
request.
Okay,
you
have
shared
the
pull
request
that
needs
to
be
merged.
A
All
right
we
can
move
on
to
number
two,
that
is
from
GitHub
issues
and
pull
requests.
The
first
one
that
we
have
considered
here
from
issues
is
merge
policy
discussion.
How
final
is
final?
The
issue
is
already
added
in
the
EAP
GitHub
repository,
so
we
have
seen
in
the
past
that
there
are
some
improvement
suggestions.
Minor
edits
are
going
into
Final
eips
in
this
month.
Only
we
have
seen
three
final
EIP
is
being
edited
with
small
changes
so
yeah.
This
is
about
discussing.
How
do
we
work
decide?
A
final
is
final.
C
I'd
say:
backwards
compatible
I.E.
Basically,
if
it's
able,
if
the
EIP
is
able
to
be
implemented
and
there's
no
ambiguity
in
how
it
can
be
implemented,
then
that's
how
it
has
to
be.
If
either
of
those
conditions
don't
fail,
then
it
is
okay
to
get
rid
of
any
ambiguity
or
to
make
it
so
that
the
EIP
can
be
implemented
at
all.
E
I
think
we
need
to
I,
don't
think
we
can
actually
write
in
backwards
compatible
or
backwards
incompatible
into
eip1.
Just
because,
like
let's
say,
the
EIP
specify
a
core
EIP
specifically
specified
something
and
all
the
clients
implemented
a
different
but
the
same
different
way.
C
E
I
really
just
think
that
we
should
make
it
policy
to
only
allow
backwards,
compatible
changes
to
final
eips,
but
I,
don't
think
we
should
make
it
a
hard
rule,
because
there
are
times
where
like
if
something
is
wrong
with
the
EIP
like
clearly,
it
is
not
what
the
author
intended
it's
it's
just
wrong,
then
I
think
it's
fine
to
fix
the
EIP.
Even
if
it's
backwards,
incompatible,
I,
think
backwards,
income
or
backwards
compatibility
is
a
good
Baseline,
but
there
should
be.
We
should
be
allowed
to
make
exceptions
to
that.
A
I
guess
the
important
question
here
would
be
to
maybe
outline
it
for
people
to
refer
to
like
what.
A
Not
a
problem,
so
what
is
the
point
where
we
can
say
that
we
are
not
going
to
make
any
edits,
basically
to
clarify
on
what
kind
of
edits
may
or
may
not
be
able
to
get
in,
and
if
there
are
edits
which
is
outside
this
guide
guidelines,
then
we
can
ask
author
to
maybe
come
up
with
a
new
proposal,
not
edit
the
existing
one,
not
edit.
The
final
proposal.
C
Up
changes,
the
meaning
of
an
EIP
I'd,
be
obviously
seven.
Seven
12
verses
just
doesn't
work
so
that
can
be
changed
just
because
there's
nothing
it's
backwards
compatible
if
there
isn't
any
implementation,
but
apart
from
that
I
just
don't
like
the
idea
of
yeah.
Basically,
if
it's
written
some
way
that
can
be
implemented
and
it
is
implemented
that
way,
then
that
should
always
for
the
rest
of
Eternity
be
compatible
with
that
EIP.
D
E
I
like
to
respectively,
challenge
that
so,
first
of
all,
what
what
Sam
says
if
a
core
EIP
has
been
implemented
and
every
client
have
implemented
differently
from
the
core
EIP
that
one
turns
final,
then
you
need
to
add
changes
to
the
core
EIP
to
reflect
what
everyone
is
implementing
I.
D
Think,
given
the
idea
of
EIP
being
issuing
an
improvement
proposal,
if
everyone
is
implemented
in
a
same
consensus,
different
way
than
the
better
way
is
to
keep
the
old
one
at
final
and
create
a
new
one
that
reflects
the
true
implementation
rather
than
fixing
the
o1
unless
they're
not
final
right.
If,
if
the
final
has
been
reached,
I
think
changing
things
make
it
essentially
life.
So
unless
we
want
to
agree
that
final
is
still
live,
I
am
I'm
very.
D
Weakly
lean
towards
making
final
changeable
other
than
editorial
requirement,
like
I,
don't
consider
backward
improvements.
Backward
Compatible
feature
improvements
as
qualified
in
this
case
as
well,
and
that's
also
why
I
propose
to
have
a
Super
C
so
that
if
they
also
do
think
that
this
EIP
has
been
final,
but
no
one
is
implementing
it,
it's
not
being
adopted,
and
everyone
has
a
new
idea.
Then
it
should
they
should
have
a
way
to
Signal.
What
is
the
better
way?
So
that's
that's.
D
It's
seven
one,
two
right:
seven,
one:
two,
the
type
six
assigned
signature,
so
seven,
one
two
on
the
exact
fee
side
is
the
same
I.
Think
if
everyone
has
been
implemented
in
a
different
way,
if
it
all
it's
a
wrong
way,
the
best
way
is
probably
just
to
start
a
new
one
copy.
The
old
one
fix
it
and
then
and
then
publish
that
one
as
new
Final
or
revert
on
in
a
one-time
exception,
reverted
back
to
drive
towards
to
anything
that
is
not
final,
then
I
think
we
can.
We
can.
We
can
modify
it.
D
Otherwise,
we
have
to
be
undermining
our
credibility
of
being
final
I
I,
don't
think
as
a
EIP
editor
group,
that's
the
best
in
the
best
reputation
best
way
to
hold
the
reputation
of
this
group.
E
So
we
we
can't
I
think
unless
we
could
like
completely
revamp
our
process
ever
move
an
EIP
out
of
final
unless
I
guess
it's
also
to
withdrawn.
Maybe
we
could
allow
that,
but
because
of
the
way
the
merge
Bots
are
set
up
once
an
EIP
moves
out
of
like
if
an
EIP
is
not
final,
the
editors
can
change
it
without
a
EIP
editor
approval.
So
you
would,
you
would
basically
just
lose
all
immutability
immutability
guarantees
if
it.
B
A
E
A
Agree
agree
to
some
like
changing
the
direction
of
a
process
flow,
I
I
think
we
had
a
long
discussion
on
it
about
a
year
ago.
This
is
one
way
like
when
it
is
moving
from
last
call
to
final.
It
is
unidirectional,
however,
from
last
call
to
review.
It
can
be
done.
D
D
Me
put
it
into
context,
I
did
and
then
for
what
I
know
it's
the
the
EIP
is
largely,
is
largely
ambiguous
and
not
even
ready,
I,
so
I
I
think
it's
not
even
ready
for
one
time
change
to
make
it
final.
That's
why
I'm
suggesting
it
it
has
to
go
to
some
status
that
is
updatable
that
either
start
a
new
one
or
or
move
it
back
to
drop,
because
I
think
it
would
take
another
several
months,
several
iterations
to
get
to
a
state
that
implementations
are
are
are
agreeing
on
each
other.
D
It's
currently
we're
seeing
different
I
personally,
see
different
implementations
of
of
what
ethers
have
been
doing
and
what
the
mathematics
is
doing
and,
and
so
I
think
that
the
consensus
have
not
been
breached.
That
there's
just
one
commit
to
go
in.
B
C
There
are
two:
there
are
two
specification
sections,
one
of
which
was
just
straight
up
copy
and
pasted
from
I,
think
it's
eip191
and
I'm
pretty
sure
all
of
it
needs
to
be
done
so
just
remove
that
accidentally
copied
and
pasted
the
specification
section
and
Damage
Done.
C
Currently,
as
is
it's
incompatible
with
itself,
there
cannot
and
will
not
be
any
specifications
of
712
in
this
form
just
because
it
just
because
it
has
two
masks
that
say
two
different
things
so
as
written,
it
is
not
possible
to
implement
it,
and
so
therefore
it
is
also
not
possible
it.
Therefore,
there
are
no
implementations
and
therefore
there's
nothing
that
can
be
broken.
D
And
but
we're
in
consensus
that
at
this
current
snapshot
it
doesn't
work.
No
one
can
implement
it.
That
I
think
we're
in
consensus.
I
wonder
if
I
make
myself
clear
that,
even
with
one
change,
it
is
still
not
capable
of
being
in
the
final
State
like
it's
in
a
stable,
State,
I
I,
wonder
if
I
made
myself
clear
that
I
I
think
in
my
personal
experience,
ignoring
one
of
the
specification,
the
other
specification
is
not
ready
to
be
implemented.
C
E
C
Just
because
that
last
call
also
requires
editors
to
prove
all
changes,
so
there's
that.
D
D
A
A
However,
they
did
not
show
up
for
pushing
at
the
proposal
and
final
status,
so
it
was
championed
by
one
of
the
cat
who
do
so
I
I
believe
in
this
case
we
can
consider
that
authors
are
Mia
and
having
a
new
proposal
of
competing
proposal
will
be
good
and
when
it
is
proven
that
the
new
proposal
is
fixing
all
the
ambiguity
of
the
712,
probably
we
can
take
an
attempt
to
make
it
stagnant
sorry,
withdrawal
and
of
shared
the
new
proposal
with
rest
of
the
job
developers.
That's
for
adoption.
D
I
agree
with
every
part
you
said,
except
for
the
withdrawn
decision
has
been
made
by
the
original
author.
If
the
original
author
didn't
care
enough
to
withdraw
it,
then
we
pretty
much
stuck
because
if
we,
if
we
open
up
a
precedent
that
editors
can
restore
on
behalf
of
the
original
author,
then
I
think
it
can
open
up
another
Pandora
box.
A
No,
no
I
mean
that
editing
that
I
guess
it
was
by
one
of
the
cat
hurdles.
So
probably
we
will
reach
out
to
that
individual
and
see
if
this
can
be
solved,
but
that
is
going
to
be
a
later
issue.
First,
we
should
look
into
getting
up
with
a
new
proposal,
so
app
developers
who
are
looking
into
implementing
of
this
has
some
solution.
They
do
not
start
because
this
is
not
Implement
table
foreign.
A
A
Moving
on
the
next
one
is
eipw
policy,
I
guess
there
is
some
ongoing
conversation
and
we
are
waiting
on
some
consensus.
Anyone
would
like
to
summarize
I
think
it
was
Again
by
Victor.
D
Sorry,
can
you
point
me
to
the
to
the
matter
I'm,
just
opening
up
my
my
computer
and.
D
Which,
which
lost
five
four
six
nine
yeah,
let
me
check
four
six:
five:
okay
yeah,
so
is
there
any
I?
Think
the
the
Sam
and
Panda,
probably
most
authoritative,
answer
whether
it's
the
technically
feasible
or
not?
I
personally
feel
that,
based
on
other
venting
tools,
that's
possible
to
do
so,
but
like
depending
on
how
much
it
is
also
like
Sam
and
Panda.
Do
you
have
preference
of
not
checking
only
the
change
line.
C
I
would
say,
probably
I'd
be
okay
with
eipw,
only
only
blocking
only
blocking
merges
when
the
IP
status
changes,
so
that
is
something
I
would
be.
Okay
with
now
I
much
I'd
be
my
I
am
much
less
happy
with
it.
Only
changing
nothing
changed
lines,
because
then
you
could
have
it
going
from
like
draft
to
review
the
entire
the
entire.
There
are
a
bunch
of
new
things
that
need
changing
and
that
aren't
being
changed
is
it's
only.
It's
only
requiring
eipw
to
pass
for
status.
Change.
D
D
So
so
Fame
I
can
give
him.
C
Pw
would
still
be
failing
the
it
it
wouldn't
actually
be
like
it
would
still
be
like
giving
all
the
errors
and
errors
and
stuff
it
just
would
be
that
erpw
would
no
longer
be
marked
as
a
required
check,
but
the
EIP
bot
wouldn't
merge
it
unless
I.
C
E
Am
very
I
am
very
much
against
linting
only
change
lines
because,
like
like
I
said
my
comment,
the
Boy
Scout
rule.
So
if
you
edit
the
file,
you
should
make
the
file
better
and
I
think
that
epw
is
probably
the
best
way
to
do
that
and
I
I.
Don't
think
we
should
only
require
lints
on
status
changes
because
then,
when
an
author
is
trying
to
move
something
from
review
into
last
call,
then
they're
suddenly
going
to
get
a
bunch
of
stuff
that
they
have
to
fix
that
they
weren't
forced
to
fix.
E
Before
and
like
right
before,
going
into
the
last
call
that
doesn't
feel
like
a
great
like
developer
experience,
I
guess,
I
think
we
should
just
have
it
lent
whenever
they
make
a
PR.
It's
not
like
it's
stopping
them
from
making
commits
it's
just
stopping
them
from
merging
them.
E
But
you
know
I
I,
don't
know
I'm,
not
a
dictator,
so
you
guys
can
decide
something
else.
If
you
want.
D
D
One
of
the
things
we
see
is
some
contributors
not
necessary
author
contributors
who
come
across
on
EIP,
realize
there's
a
typo
come
to
fix.
The
typo
I
think
that's
a
good
spirit
right
and
then
it's
also
a
good
way
to
get
into
EIP
editoring
and
in
that
case
the
micro
contributions
help
out
a
lot.
So
that's
why
I
am
suggesting
if
we
allowed
merging
just
checking
the
line
like
if
you're
touching
this
line
for
this
scope.
D
Maybe
it's
good
idea
that
you
want
to
fix
the
whole
thing
in
the
line
or
even
paragraph
but
for
the
whole
file.
It
scare
away.
People
who
just
want
to
come
in
and
contribute
I
I
have
first-hand
experience
starting
contributing
from
Wikipedia.
A
lot
of
page
I
contribute
just
fixing
typos
and
then
ultimately,
I
become
a
more
regular
contributors.
So
in
that
period
I
want
you
to
see.
D
If
you
would
reconsider
that
scenario
and
of
course
it
will
be
approved
by
author
in
our
current
setup,
but
I
think
so
long
as
at
the
time
it
moves
to
the
next
stage
should
I
change
status,
for
example,
review
or
fight
last
call
or
final,
then
someone
mostly,
they
also
have
to
be
responsible
for
what
is
editorial
fully
checked
so
Sam?
Does
that
make
a
good
argument
for
you.
E
E
Documents
they're
not
like
crowdsourced
explanations
of
things,
so
I
think
there's
a
little
bit
of
a
difference
from
Wikipedia
and
like
I,
do
appreciate
people
coming
in,
and
so
so
one
I
think
we
should
turn
off
UW
for
final
eips
for
sure,
because
that's
just
awfully
annoying
and
I
I
don't
think
we
want
to
be
fixing
the
formatting
for
final
eaps
unless
we're
intentionally
fixing
the
formatting
for
finally
IPS,
but
that's
a
whole
other
thing,
but
for
for
in
process
or
draft
eips,
I.
E
Think,
generally
speaking,
the
author
will
still
be
active.
So
if
somebody
puts
up
a
a
pull
request,
fixing
a
typo
in
like
a
non-final
EIP.
Presumably
the
author
will
eventually
see
it
and
we'll
probably
incorporate
it
into
their
work.
But
yeah
I
I
just
think
it's
better
to
keep
everything
as
strict
as
possible,
especially
while
they're
developing,
so
that
they
don't
get
surprised
on
like
a
status
change
or
or
when
they
go
to
final.
D
Fair
enough
doesn't
didn't
convince
you.
I
would
come
back
and
try
in
two
years.
D
Yeah
yeah,
but
I
I
agree
that
we
can
keep
it
as
if,
for
now,
I
can
close
this
issue
and
and
or
use
the
pendant
you
want
to
pursue
the
the
change,
the
the
the
way
of
that
it
only
check
when
their
status
changed
or
do
we
wanna
you.
C
Last
last
call
should
be
checked
just
because
the
changes
should
be
made
before
it
is
final.
Oh.
D
Actually
not
check
at
for
files
at
final
right
yeah,
that
is
consensus
for
sure
and
still
keep
it
on
for
every
other
status.
Every
other
commitment
commits
right.
D
D
Keep
it
on
for
everything
every
commit,
except
for
a
final
commits.
Okay,
that's
a
consensus
I
as
minority
disagree
with
that,
but
I
would
document
it
as
the
consensus
and
we
can
close
it.
A
Thank
you
and
yeah
for
closing
the
issue
and
also
Sam
and
panopy
for
having
this
as
a
decision.
I
hope
this
will
be
noted
in
the
notes
for
this
meeting.
A
Moving
on
the
next
item
for
discussion
here
is
a
pull
request:
number
5443,
it
is
there.
The
last
comment
is
for
a
manual
merch.
It
is
with
regards
to
eip4881.
A
D
Right
Sam:
do
you
have
any
further
concerns
I
think
they
fixed
the
links
for
your
request.
E
Yeah
I
think
it's
good
to
go.
I
just
wanted
to
make
sure
we
had
an
opportunity
to
talk
about
it
here
if
Greg
were
to
show
up
but
I
guess
it's
just
the
two
or
three
of
us,
so
yeah.
A
Last
opportunity,
one
Greg
here
to
miss
this
one
for
raising
any
concern,
but
anyway,
this
proposal
is
in
very
early
stages.
I
guess
we
will
have
more
opportunity
to
come
back
on
this
topic
when
this
is
merged
as
a
review
or
last
call.
A
A
D
Yeah
and
I
wonder
if
there's
any
because
my
goal
is
to
put
it
into,
let
people
come
and
like
have
a
broader
Rich
company
of
Interest.
That's
my
own
proposal,
so
yeah
whatever
you
decide
well,.
C
D
I
see
side
notes.
Panda
I
saw
that
you
tend
to
merge
lines.
Is
there
any
particular
reason
that
you're
doing
so
because.
C
C
So
the
reason
why
I
don't
like
that
is
just
because
text,
editors
generally
backlines
for
you,
but
if
you
have,
for
example,
but
basically
I
like
if
it
it
can,
if
it
can
all
fit
on
one
line
in
my
text,
editor
I,
like
I
I,
do
quite
like
it.
That
way.
Also
a
lot
of
people
think
that
oh
it'll
force
a
line
break
there.
No,
it
does
not
force
the
line
break
there
in
markdown.
C
Third,
third
of
all,
yes
I
do
agree
that
you're
being
able
to
Target
things
more
specifically
is
a
kind
of
a
nice
feature,
but
at
the
same
time,
GitHub
git
is
smart
enough
to
to
somewhat
be
a
distill.
Some
might
be
able
to
Target
it
enough.
A
C
Guess
I
and
that's
there
are
two
that
are
exactly
the
same
line,
but
generally
you
do
all
of
your
changes
at
one.
That
Target
is
specific
line
at
what
time,
as
as
you
can
see
like,
oftentimes
I
have
a
required
X
required
y
required
required
the
recommended,
whatever
recently
I,
prefer
it
all,
and
the
last
reason
I
prefer
it
all.
D
C
The
consensus
is
moving
actually
towards
there
being
a
specific
cell
there's
actually.
C
Do
we
there's?
Actually
you
know
one
of
my
PR's
is
open
right
here.
Let
me
figure,
it
add.
Markdown
menu,
this
one
right
here.
D
Oh
okay,
let
me
check
that
is
still
yeah.
We
I
think
we
agreed
to
have
a
markdown
later,
but
I
wonder
if
all
the
rules
in
that
intro
has
been
agreed
upon,
especially
all.
C
The
of
the
rules
currently
have
been
agreed
that
are
set
currently
have
been
agreed
upon,
I'm,
not
sure
if
the
multi-line
one
has
been
agreed
upon
or
not
speaking,.
D
E
C
Know
if
we
can
understand
that,
in
fact,
Micah
went
through
rule
by
rule
and
went
basically
argued
why
none
of
the
rules
should
be
applied
and
and.
D
C
D
I
see
can
I
propose
my
my
objection
to
reinforce
multi-line,
to
be
a
contact
and
Native
into
one
line.
C
No,
what
I'm
saying
is
that
currently,
that
is
not
not
an
issue
Tennessee
according
to
the
conflict
we
have
set
in
the
markdown
later,
you
can
do
multi-line
I
personally
need
to
test
it,
but
I
guess
I
guess:
I
will
no
longer
force
people
to
do
to
not
do
multi-line,
even
though
it
hurts
my
eyes
just
by
looking
at
it.
D
So
that's
why
I
I
in
in
the
in
an
EIP
I
prefer
breaking
down
then
just
because
like
gets
diff
much
better
with
different
lines
rather
than
single
lines,
and
also
GitHub
is
doing
that
same
thing
as
well.
So
that
would
be
my
personal
argument.
Yeah.
E
A
Thank
you.
Probably.
We
can
continue
discussing
in
that
pull
request,
adding
comments
there.
We
are
very
close
to
time,
but
I
wanted
to
quickly
bring
up
one
last
item
for
discussion
today.
It
may
not
be
discussed,
but
just
wanted
to
share
it
with
people.
The
item
that
has
been
added
by
Panda
peep,
it's
a
last
minute
Edition
and
the
pull
request
number
is
5502.
It
is
about
adding
a
new
editor
having
a
new
editor
added
to
the
repo
and
getting
them
access.
A
I
know
we
do
not
have
all
the
EAP
editors
present
in
this
meeting
today,
so
we
can
probably
consider
this
as
an
announcement
of
this
will
request
and
will
try
to
reach
out
to
more
editors.
Anyone
has
any
comment,
thoughts
quickly,
to
add
on
this.
No.
A
Sounds
good
I
think
it
is
waiting
on
reviewers
or
editors
approval
there.
We
will
try
to
collect
more
approvals
from
editors
who
are
missing
here
in
this
meeting
today
and
if
we
get
over
three
two
or
three
approvals,
then
probably
it
can
be
merged.
Now
that
we
have
five
editors,
so
three
sounds
okay
to
me.
A
Cool,
we
have
quite
a
lot
of
pull
requests
and
other
agenda
items
that
we
could
not
touch
today.
I
hope
that
it
will
be
discussed
in
the
issue.
Number
people
may
follow
the
link
added
to
agenda
and
leave
their
comment
thoughts,
feedback.
They
are
always
welcome
to
come
to
cat
orders,
EIP
editors
Channel
and
continue
discussing
it
with
creating
a
separate
thread
in
the
meantime
before
we
get
to
the
next
meeting
in
two
weeks
from
now.