►
From YouTube: EIPIP Meeting 66
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/181
A
Welcome
to
AP
I'll
be
meeting
66
I
have
shared
agenda
and
chat.
We
have
a
few
items
listed
from
the
open
pool,
requests
and
issues
side.
The
first
item
here
is
open
items
from
the
past
meeting,
but
I
think
that
most
of
them
have
been
added
by
Sam
already
as
the
issues
where
we
haven't
reached
consensus.
So
maybe
we
can
start
with
the
with
the
items.
Those
were
partially
discussed
and
are
listed
here
again
so
website.
A
Add
Mad,
Jacks
I
believe
it
was
discussed
in
the
meeting
last
meeting
as
well,
but
I
don't
know
like
client
was
not
there
at
the
time
and
it
was
only
Greg
and
Sam,
which
seems
to
be
on
on
board
anything
specific.
We
would
like
to
discuss
about
this
proposal.
Yeah.
B
A
So
I
can't
see
panda
on
the
call
I'm,
not
sure
if
we
have
any
further
updates
on
that.
So
maybe
we
can
skip
this
one
unless
anyone
else
on
the
call
has
anything
to
add
or
share.
B
A
Thanks
for
support
cool
the
next
one
is
a
CI
disabled,
certain
levels
from
becoming
Steel.
B
Should
make
it
fail
or
not
I
think
we've
been
discuss
in
the
CR.
A
Agreed
I
have
actually
added
that
in
the
item
number
two
as
a
change
in
eipib
meeting
time,
though
we
recently
have
changed
from
15
to
1400,
but
obviously
we
are
open
to
thoughts
here.
I,
don't
know,
I
can't
see
Panda
or
Victor
Victor
mentioned
in
the
chat
that
he
may
be
fine
with
somewhere
around
1500
or
15
30
UTC
Sam.
Do
you
have
any
preference
or
like
him,
maybe.
A
A
Okay,
sorry
just
to
be
sure,
Again
Sam.
What
are
your
thoughts
on
like
number
two
CA
disable
certain
levels
from
becoming.
We
continue
discussing
this
in
the
beer
itself,
exactly
yeah,
okay,
cool.
A
B
A
Fair
enough,
maybe
I
can
bring
it
up
in
the
next
meeting.
If
assumingly
we
have
more
editors
and
reviewers
joining
in
with
the
new
change
in
time,
so
I'll
make
sure
to
bring
it
up
again.
Five,
two
seven
three.
B
A
A
So
if
I
remember
correctly
from
the
past,
like
it
was
mentioned,
that
requires
is
a
section
that
is
there:
it's
not
applicable
to
all
eids,
but
for
particular
eips,
where
someone
is
trying
to
reference
something
from
the
past
or
existing
eips.
They
must
mention
it
as
in
request
section.
The
number-
and
we
generally
recommend
to
have
that
proposal
which
is
under
the
required
section,
must
be
having
status
of
final.
B
A
Okay
sure
yeah,
as
per
my
understanding,
requests,
were
generally
used
when
it
is
maybe
either
the
extended
version
of
an
existing
EIP
or
using
some
part
of
any
other
Erp
like
this.
This
standard
won't
work
if
the
project
hasn't
implemented
the
earlier
EIP.
A
A
It
is
clarify
when
to
use
request
so
looks
like
the
general
agreement
is
when
we
are
using
an
eip's
extension
or
sending
a
proposal
for
an
EIP
extension
or
the
present
proposal,
which
is
using
any
other
EIP
in
final
status
must
be
mentioned.
There.
B
Okay,
I
thought
the
original
consensus
that
we
needed
we
are
we
were
near
was
that
if
it's
mentioned
in
the
specification
section,
we
will
require
that
to
be
required
and
then
elsewhere
with
the
authored.
A
fifth
question
is
that
if
this
meeting
reached
a
different
sentences
and
I
think
that's
just
the
trail
indicator
of
what
we
actually
want
like
I,
don't
think
that
you
could
mention
an
EIT
in
the
specification
section
unless
it's
required
as
part
of
the
specification,
but
that's
like
a
separate
thing
like
if
I
haven't
mentioned.
B
Oh,
this
is
similar
to
the
VIP
I
shouldn't
include
it
requires
I
should
just
not
have
that
statement
and
the
specification.
So
the
thing
that
we
actually
wanted.
We
want
required
to
only
be
you
know,
required
if
you
have
to
have.
You
have
to
implement
that
VIP
to
implement
the
want
to
describe
yeah
that
argument.
I
agree
with
you
in
like
plan
I,
actually
don't
know
when
you
go
buy
that
stuff.
B
So
my
understanding
about
our
views
on
specification
is
that
specification
that
particular
section
should
be
as
free
as
possible
and
not
mention
anything
unnecessary
in
your
very
simple.
It's
like
the
other
one
that
it
is
like
the
other
VIP
should
actually
go
to
rationale.
B
Examples
is
that
a
good
understanding,
yes
I,
definitely
agree
with
you
I'm
just
saying
that
I
think
that
if
we
say,
if
you
were
describing,
the
IP
in
the
classification
section,
it
must
be
required
is
not
getting
to
the
underlying
thing.
The
original
it's
like
that
we
want
here.
We
want
the
AP
to
only
be
described
and
require
if
it
is
actually
required.
B
Yeah
I
I
respect
that
if
there's
the
consensus
to
the
team,
I
just
I
just
feel
that
record
making
the
vacation
minimum
plus
required
when
up
here
I
require
a
VIP
won't
appear
in
verification.
Is
the
probably
the
easiest
for
argument
to
be
participate.
B
I
can
see
these
examples
when
you,
when
we
basically
describe
it
as
like,
when
it's
depending
on
something,
for
example.
Yes,
the
young
eip1191,
adding
the
new
check
Dom,
because
we
think
it's
depending
on
the
ice.
The
ipicu
55
in
your
original
check
from
without
considering
the
channel
ID
I
think
on
the
argument
can
be
made
both
ways
and
then
I
think
that
way
we
reduce
our
productivity
in
terms
of
reaching
containers.
Whether
one
should
be
disappointed
or
not,
because
I
just
want
to
put
that
into
consideration.
B
But
I
do
expect
the
the
10
30
fish
supply
additives.
A
So
I'm,
just
trying
to
understand
here
from
where
I'm
hearing
looks
like
both
of
you
are
saying
the
same
thing:
it's
just
that
I'm
trying
to
understand
what
is
the
difference
of
opinion
or
thought
here.
So
the
idea
is
like
if
someone
is
mentioning
any
proposal
in
specifications.
That
means
the
new
proposal
which
is
on
the
table
cannot
be
implemented
unless
the
earlier
proposal,
which
is
being
mentioned
in
the
specification,
is
already
implemented.
That's
my
understanding,
and
if
that
is
the
case,
that
proposal
the
earlier
proposal
must
go
into
the
required
section.
A
I
am
looking
into
eip1191
that
you
just
shared.
So
here
we
have
two
eips
in
require
section,
55
and
155,
so
they
have
mentioned
50
155
in
specification
as
well
as
eip-55.
Yes,
they
did
mention
both,
so
both
are
in
required
sections.
So
if
you
can
help
me
understand,
what's
the
difference
here.
B
B
It
achieves
protection
on
things
on
the
play
we
play
attack,
but
it
actually
didn't
require
155,
which
at
least
I
think
based
on
the
specification.
If
it
says,
however,
that
Chennai
leaves
system
of
chain
ID
is
a
requirement,
then
definitely
this
one
is.
B
It
is
depending
on
155,
but
since
the
specification
didn't
mention
it,
we
can
just
ask
to
remove
it
so
I'm,
just
using
the
example
code,
just
provide
to
see
to
provide
an
a
demo
of
editorial
feedback
for
author
and
I.
Think
that
that's
actually
a
simple
rule
to
remember
to
propagate
between
editor
and
also
to
help
authors.
A
B
Judgment
here
is
that
whether
chain
ID
is
a
taken
for
granted
thing
if
people
think
in
the
AIP
in
the
development
of
the
later
eiph
Chen
ID.
If
it's
taken
for
granted
pain,
then
people
should
assume
that
that
chain
ID
has
defined
by
155
should
be
considered
non-required
because
it
was
already
taken
for
granted.
But
if
we
do,
but
if
we
don't
think
they
are
taking
for
granted,
many
other
things
like
hot
works
should
actually
be
required,
and
that
goes
on
and
on.
B
My
take
but
I
I
I
do
respect
that
if
we
want
to
just
keep
it
a
little
bit
vague
or
giving
me
way
of
more
depression,
virus
editor,
I'm,
okay
with
that
either
so
yeah,
depending
on
the
word.
A
Right
so
it
looks
like
there
is
no
strong
recommendation
of
changing
of
the
wording
existing
wording
in
eip1,
so
we
can
probably
let
it
live
like
that,
and
if
we
come
across
any
new
proposal
in
the
future,
where
we
might
need
more
clarification,
then
probably
we
can
bring
up
this
this
discussion
again,
because
all
these
eips
that
we
discussed
so
far
are
like
already
in
the
final
status
and
eip1191
is
actually
having
both
the
eips
in
requires
section.
B
A
Cool,
so
now
we
can.
We
don't
need
to
change
the
wordings
over
there
and
we
can
let
it
live
all
right.
A
Yeah,
thank
you
and
we
can
probably
move
ahead.
The
next
number
is
five:
five,
one,
seven
that
is
update,
eip1,
add
finalized
date
to
the
Preamble
we
discussed
about
it
in
the
past.
If
I
remember
correctly
right
now,
the
templates
suggests
only
created
date.
However,
the
created
date
is
is
not
the
date
when
it
is
merged.
So
having
the
date
finalize
date
when
the
EIP
gets
into
final
status,
I
guess
that's
the
proposal
here.
B
I
really
don't
want
to
add
the
field,
but
I
would
absolutely
love
to
have
an
upgrade
field.
Yeah
like
I,
would
love
to
have
some
kind
of
a
field
that
describes
the
state
on
ethereum.
The
block
number
was
activated
in
like
that
kind
of
thing
and
yeah
I
don't
think
finalized
things
is
probably
going
to
think
it's
not
a
good
prophecy
for
that
information.
A
I
think
a
state
on
ethereum
and
block
number
is
only
applicable
to
one
particular
category.
That
is
core
and
it
may
not
be
there
for
any
other,
including
interface
and
networking,
because
they
can
be
implemented
on
client
level
at
different
point
of
time.
So
we
may
want
to
look
into
something
which
is
common
for
all
types
and
categories.
B
Dropping
in
I
I
think
this
was
originally
requested
by
Mikhail
materialize
that
his
request.
But
if.
A
B
If,
if
your
poor
editors
are
like
not
in
favor
of
this
I,
I
I'm
happy
to
enjoy
the
request,
I
would
love.
A
A
So
in
that
we
came
across
this
field,
I'm
I
was
trying
to
collect
data
for
the
past
eips,
so
when
it
was
introduced
as
of
now
as
of
date,
what
we
do
is
like
whenever
an
Eid
is
merged
for
the
first
time
as
draft
to
eip's
GitHub
repository,
then
we
add
it
as
EIP
added
in
that
particular
month,
but
we
were
having
hard
time
finding
this
information
for
old
eips,
because
we
have
to
actually
go
by
every
comic
number.
A
So
we
have
to
go
to
Every
IP
go
to
its
first
commit
and
then
collect
the
date
from
there
one
of
my
resources,
what
they,
what
he
tried
to
do
is
like
collect
the
created
day,
but
obviously
the
date
it
was
created
and
the
date
it
was
merged
was
not
not
in
the
sink.
So
I
was
also
thinking
of
having
one
date
in
which
we
can
be
finding
it
like
everywhere.
A
So
if
it
is
useful,
when
that
proposal
is
merged
as
draft
for
the
first
time,
that
could
be
the
first
time
when
it
entered
into
the
eip's
repo.
If
we
can
have
that
date,
instead
of
create
a
date
or
finalize,
because
finalization
can
be
there
for
core
EIP,
we
can
track
when
an
upgrade
is
activated
and
that
particular
EIP
was
considered
for
that
upgrade.
So
we
can
definitely
have
the
final
date
because
we
can
collect
it
from
there
yeah
any
thoughts.
There
I
mean
any
suggestion
solution
for
it.
B
A
So
for
creating
this
Eid
is
Insight
dashboard.
We
are
collecting
information
of
how
many
eips
were
merged
as
draft
or
as
final
or
change
of
a
status
in
a
particular
month.
So
draft
is
the
first
status
when
an
EIP
is
added
to
GitHub
repository,
so
I
was
hoping
if
we
can
have
that
field.
Definitely
it's
a
it's
something
that
we
can
collect
by
scraping
data
from
GitHub,
but
if
we
can
have
it
in
eaps
as
well.
B
I
I
think
you
are
coming
from
like
a
collecting
that
kind
of
reasoning
and
and
that
that
makes
the
time
to
merge,
helpful
I,
wonder
if
we
can
kind
of
lead
to
a
simple,
simpler
version.
One
is
the
created
which
should
actually
be
the
first
day.
It
was
merged
and
also
the
also
a
finalized
day
for
non-core
to
be
the
date
that
it's
announced
to
be
finalized
because
ercs
and
others
in
other
VIPs
are
using
final
status
to
declare
that
they
are
ready
to
be
implemented.
B
But
core
is
actually
going
to
de
facto
de
facto
adoption
mechanism,
which
means
only
client
adopted
means.
It's
final
so
or
maybe
we
can
just
say
for
core.
We
will
use
that
final
day
to
to
match
with
the
the
hard
work
it
happens.
Would
that
be
helpful.
B
I'm
proposing
for
final
the
non-core
use
the
day
that
it
was
declared
final
for
core
use.
The
date
of
the
merge
yeah,
sorry
not
upgrade
of
the
yeah
use
the
the
date
of
the
heart
of
the
upgrade
or
hard
work.
B
B
So
we
I'm
okay
of
adding
data
types
like
block
number
or
name
of
upgrade.
Do
you
think
that
would
be
helpful.
B
B
Until
we
find
it
more
urgently
necessary,
then
like
with
basically
I
heard,
what
you
say
is
basically
making
trade-off
between
adding
new
film,
creates
more
complexity
for
Preamble
versus
not
having
a
few
reviews
with
the
visibility
and
some
of
the
cases,
and
it
seems
like
in
your
mind,
knowing
the
finalized
phase
is
not
super
helpful.
To
justify
the
the
more
value
is
introduced
to
the
Korean
role.
B
Okay,
how
about
this?
Let's,
let's
pause
the
request
to
add
final
I,
say:
let's
prioritize,
adding
what
is
adding
the
the
upgrade
available
to
the
to
the
Core
so
that
you
don't
have
to
think
about
it.
Every
time
when
talking
about
finalizing
and
then
we
can
decide
whether
your
client
might
say
is
helpful
at
all
for
all
eisens
I
I
lean
towards
not
having
one
day
that
is
seems
to
be
common,
but
people
constantly
come
and
ask
hey:
why
do
core
doesn't
have
it
things
like
that?
B
Yeah,
so
okay,
here
is
my
proposal.
I
will
create
a
new
VR.
Add
a
final
and
add
a
add.
A
new
field
says
this
is
the
upgrade
for
the
core
and
because
people
are
easily
understand
it
only
applies
the
core.
We
will
not
have
access.
Question
asked
competitors
are
happy
with
that
and
through
that,
and
then
we
talk
about
where
the
finalized
should
be
will
be
useful
or
not.
How
about
that?
These
are
my
proposal.
B
I
think
there
are
reasons
why
we
don't
have
upgrade
and
block
number
generally
in
eib
template,
but
I
think
the
idea
is
that
you
know
if
we
somebody
were
to
Fork
the
chain
or
start
a
new
ethereum,
then
embedding
the
the
kind
of
governance
information,
the
EIP
might
be
a
bad
thing
because,
like
it
makes
it
extensive
to
our
chain
as
opposed
to
any
source
of
ethereum
I'm,
not
sure
if
that
matters.
So
much
now
with
his
mistake
and
all
that,
but
yeah
I,
don't
know
it's
a
good
arguments.
B
I'm!
Sorry,
you
can
organ.
If
you
can't
afford
our
repository
and
figure
out
how
to
remove
that
I,
don't
know
what
to
tell
you
you
shouldn't
make
it.
We
shouldn't,
make
it
easy
to
work
and
then
make
our
lives
worse.
Because
of
this,
like
sorry
at
the
Port
button,
I
think
I
I
think
that
is
that
has
a
philosophical
assumption
that
I
agree.
B
A
lot
also
I
have
I,
don't
know
if
I
have
these
movies
of
that
light,
I
think
you
mentioned
somewhere
that
you
are
thinking
that,
if
you're
an
EIP
trying
to
govern
the
ethereum
and
particularly
learn
it,
which
I
think
at
least
in
my
intuition,
I
agree,
and
in
that
argument
we
should
not
it's
not
very
helpful
to
assume
the
other
foreign.
B
B
So
if
they
want
to
adopt
it,
they
can
use
it.
So
that's
a
small
voice
now
coming
back
I
I
have
another
like
more
practical
question,
for
you
guys
is:
let's
assume
that
you're
going
to
have
shot
in
very
soon
what
happens
is
from
charities
allowed?
The
block
allow
some
of
the
the
upgrades
first
then,
in
the
other.
Shutting
on
top
later
do
we
use
no.
B
No,
we'll
always
have
one
global
Walker
Squad
number
to
refer
to
we'll,
never
get
into
a
scenario
where
I
mean
sharding
like
this.
The
idea
has
changed
a
lot
over
the
last
several
years,
but,
like
the
shards,
are
now
Layer
Two.
So
it's
a
layer
two
upgrade
to
the
different
point.
That's
not
a
concern
of
the
board
that
we
call
I
can
see
in
the
old
one
in
the
outshotting
mechanism.
It
is
possible.
I
can
see
that
in
dank
shock
is
much
unlikely
that
they
will
have
a
different.
A
B
That
that's
thinking
too
much,
because
that's
a
very
un
mattress
on
the
scenario
that
hasn't
happened.
So,
if
you're,
all
in
favor
of
of
having
a
upgrade
I,
will
create
a
new
field
and-
and
you
can
comment
on
it-
would
that
be
helpful.
B
A
Sounds
good,
thank
you,
but
one
last
question
before
we
move
ahead
right
now.
The
created
field
is
there
in
the
EIP
template,
and
that
is
for
the
date
of
creation.
When
author
originally
created,
or
maybe
some
sent,
the
pull
request,
is
it
possible
to
have
that
replace?
Have
that
date
replaced
with
the
date
of
March
I'm
checking
if
that
can
be
done
with
the
help
of
Bot
existing
Bots.
A
A
Okay,
then
I
will
create
an
issue
which
bot
would
it
be
times
but
I
mean
like
eapw
or.
B
B
A
A
B
It's
not
you're
putting
on
the
hold
okay.
What
was
it
but
yeah
I
will
come
up
with
a
PR
for
sure.
A
A
Cool
yeah:
that's
right!
Thank
you
for
reminding
that
Sam
yes,
so
here,
EIP
number
was
an
issue.
Looks
like
this
proposal
was
earlier
created
and
editor
has
some
concern.
Yeah.
A
Item
number
two
is
past
meeting
discussion
continued.
We
discussed
about
change
in
the
meeting
time.
A
I
know
we
are
short
of
editors
on
this
call.
I
will
try
to
reach
out
to
them
individually.
However,
Victor
proposed
1500
or
15
30
UTC.
So
if
people
are
in
support
of
either
of
those,
they
can
signal
that
on
the
Discord
Channel.
A
A
So
yeah
earlier
we
used
to
have
it
at
1500,
but
in
the
last
survey
probably
six
months
ago,
and
it
has
a
shared
signal
that
they
would
be
interested
into
having
it
at
1400.
So
it
was
moved
to
1400.
But
if
people
are
fine
moving
it
back
to
1500,
we
can
do
that,
which
is
that
we
want
to
be
having
more
attendance
here
on
the
calls
so
yeah.
Whatever
works.
A
A
B
A
A
B
In
that
case,
yeah.
A
A
Okay
and
the
other
item
from
the
past
was
about
get
power,
so
we
were
joined
by
one
of
the
team
members
of
GitHub
in
in
one
of
the
earlier
meetings
recently
they
have
reached
us
stating
that
the
git
pop
for
EIP
editors
are
almost
ready.
They
are
working
with
panda
peep
on
that,
so
they
mentioned
that
we
have
created
a
bot
bot
on
GitHub
that
Panda
peep
will
tag
with
the
list
of
authors
of
each
finalized
EIP.
A
And
if
someone
was
an
author
of
a
given
EIP
in
the
given
year,
they
will
be
awarded
that
Year's
get
power.
I
wanted
to
check
here
with
the
team
like
people
present
here.
If
anyone
has
any
strong
objection
or
thoughts
or
suggestion
on
this
like
this
can
be
managed
differently
or
they
should
not
be
done
at
all.
B
Yeah
I
don't
have
to
I
cannot
do
surfing.
So
if
there
is
a
boss
that
pays
in
the
comments
appears
into
guitar,
because
Burger
season
I
think
yes
they're
good.
B
Why
would
they
have
a
bot
posting
on
every
PR,
so
the
architecture
that
I
think
was
discussed
a
while
ago
and
it's
been
a
while
since
I'm
a
little
fuzzy
on
it
is
get
pull-up,
has
a
bot
already
that
you
can
arbitrarily
like
give
Co-op
people
by
taking
in
a
comment
and
then
Panda
pip
was
going
to
write
a
bot
for
our
repository
that
tag.
Please
get
a
co-op
on
okay,
yeah
I'm,
not
okay.
With
that.
B
A
Feedbacks
collected
from
EAP
editors,
if
there
are
any
objection
or
not
so
far,
if
I
understand
correct,
this
is
to
be
done
by
Panda,
Pete,
so
I'm,
assuming
that
it
is
a
work
to
be
done
manually.
So
every
time
Panda
peep
is
dragging
the
box,
then
only
that
will
be
activated.
A
Maybe
we
can
bring
it
in
the
next
meeting
again
with
these
comments
registered
as
like,
not
in
favor
of
activation.
But
let's
see
if
they
have
other
ways
to
convince
editors
or
come
to
a
consensus
whether
to
go
by
this
or
not.
A
A
B
Yeah,
the
original
required
recommendation
we
have
is
rfc2119
which,
by
iepf,
which
that
suggests
using
must
not
required
and
all
those
keywords
document
the
intention
when
describing
the
standards
the
ifsc
iot
2119
itself
says
it
is
upgraded.
It
is
updated
by
the
901
81754,
so
I
created
pull
request
to
upgrade
the
recommendation
for
us
to
use
the
new
one
it
requires
all
the
editors
approves.
If,
therefore,
added-
and
this
thing
is
not.
B
I
think
I
I
happen
to
see
that
download
like
character
generally
okay,
but
he
didn't
issue
a
form
of
you
know
30
days
ago.
So
I
want
to
see.
If
I
we
should
go
ahead
and
do
it
see
that
we
could
Rock
consensus
or
do
you
want
to
wait
for
Alex
and
go
into
approve
it
so
I'm
totally
fine
marching
it.
So.
B
B
No!
No!
It
is
right
because
you,
you
all,
have
your
eyes
and
I'm
I'm,
okay,
with
doing
the
link
but
I
just
wanna.
Just
for
now.
For
now,
okay
I
did
but
look
I'm
running
up
an
EIT
on
how
to
deal
with
Sterling
and
well
I'll
post
that
in
terms
of
the
next
video
I
have
one
as
well.
You
want
to
add
to
it
or
we
can
like
you're
talking
about
the
solution,
because
it
happened.
Yeah
I'm,
trying
to
consolidate
there.
B
B
B
Have
modeling
we
have
existing
name
of
Teen
Titans?
Yes,
in
line
116
EIP
had
a
preamble
already
have
our
attitude.
B
You
really
want
it
to
be
moved
to
me
because
you
want
it
to
be
interested
just
right
now,
if,
if
anything
Eid
like
if
the
link
is
in
an
actual
EIP
other
than
eip1
or
there's
one
other
one,
that
has
a
reception
ew
will
not
let
you
merge
the
pr.
So,
oh
you
don't
so
just
for
a
template
right,
yeah.
B
A
All
right,
let's
move
on,
let's
move
on
in
that
sense
of
time
we
have
just
10
minutes
left,
though
we
don't
have
many
more
items.
We
are
good
by
the
time.
A
The
next
one
here
is
item
number
three
EAP
bot,
I.
Think
the
main
concern
that
was
shared
with
me
earlier
in
that
Catholics
reading
was
that
we
are
not
getting
a
clear
understanding
of
what
all
issues
to
be
worked
on
or
not.
For
example,
issue
65
that
we
just
discussed
briefly
to
have
the
created
take
looks
like
because
they
wanted
to
work
on
it,
but
panapeep
is
also
working
on
a
tool
which
will
probably
cover
this
issue,
so
we
may
not
be
able
to.
A
A
Next
is
the
eaps
inside
for
the
month
of
October.
Today
is
this
5th
of
October?
We
do
not
have
ton
of
eaps
to
be
discussed
for
this
month.
So
far
we
have
two
eips
that
move
to
the
draft
that
move
from
draft
to
review
status
and
there
are
a
handful
of
eits
added
in
the
repository
in
the
form
of
pull
request.
We
hope
to
see
more
coming
up
as
new
draft
I
have
added
information
for
proposals
in
the
eits
inside
hack
can
be
added
to
the
agenda.
A
Next
is
a
EIP
editing
officer,
we
organized
office
hour
yesterday
it
was
fine.
We
tried
to
look
into
the
proposals,
the
pull
request
and
we
were
also
joined
by
a
couple
of
authors.
Thanks
Sam
for
conducting
this
officer.
I
have
a
question
here
which
I
actually
have
added
there
for
the
next
meeting
agenda
as
well
like
do
we
want
to
have
this
meeting
for
30
minutes
giving
q
a
because
most
of
the
time
it
is,
you
are
reviewing
the
proposal
live,
which
is
good
thing
to
have.
But
yes,
there
I.
B
A
I
think
we
can
do
it
for
30
minutes
like
for
first
q
a
and
if
we
have
any
author
on
the
call
staying
longer,
because
we
could
not
address
their
problem,
then
probably
it
makes
sense
to
extend
the
call,
but,
generally
speaking,
if
we
keep
it
for
30
minutes
and
address
those
questions,
and
you
do
a
reviewing
at
your
own
Canadians.
Does
that
sound
reasonable?
A
B
I'm
not
following:
can
you
upgrade
the
update
on
the
calendar?
Okay,.
A
I
will
do
that
cool,
that's
it.
People
can
follow
the
recording
from
the
past
meeting.
A
link
is
added
and
we
also
have
added
agenda
for
the
next
meeting,
which
is
about
two
weeks
from
now
last
one
is
review
action
items
from
earlier
meetings
looks
like
we
had
only
one
action
item
from
the
past
meeting,
which
was
for
Victor
to
create
a
PR
to
further
discuss
on
the
copyright
fever
section.
Do
we
have
the
pull
request?
If
you
would
like
to
add
the
number
here
for
discussion,
maybe
in
the
next
one.
A
A
So
if
anyone
has
any
question
like
people
following
this
recording,
if
you
are
interested
to
work
on
this
particular
issue-
and
you
have
questions
feel
free
to
reach
out,
and
you
can
probably
post
your
questions
on
EIP
editors
channel
on
ethereumcare
Justice
card,
so
that's
all
for
meeting
today.
Anyone
would
like
to
bring
up
anything.
A
Cool,
so
let
me
collect
some
more
consensus
for
the
next
meeting.
Time
and
I
will
share
the
information
on
cathodes
Discord,
as
well
as
the
eth
RNA.
It
is
called
both
places,
so
people
following
either
of
the
channel
for
this
eipap
meeting
may
be
able
to
join
us
in
the
next
meeting,
based
on
whatever
AP
editors
present.