►
From YouTube: EIPIP Meeting 61
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/161
A
A
Right,
okay
and
gavin
does
not
have
a
microphone
in
the
chat
he
mentioned,
I'm
in
favor
of
that
okay,
as
next
steps
who
is
supposed
to
do
what
it
is
just
to
be
honest.
Okay,
thank
you.
So
that
is
done.
A
Moving
on
to
the
biggest
section
of
this
meeting
today,
there
are
some
github
issues
and
pull
requests
that
I
have
collected
and
added
here
for
discussion.
Some
of
them
were
suggested
as
a
comment
to
this
agenda
and
some
I
found
it
in
the
repository
and
I
have
tried
to
order
them
based
on
their
number.
The
first
one
is
five
two
six
five
it
is
to
include
superseded
status
and
superseded
by
any
thoughts.
B
A
If
I
remember
correctly
sometimes
ago,
it
was
decided
that
superseded
should
not
be
there
anymore.
A
A
B
I
think
it
is
but
that's
kind
of
why
I
brought
it
up
on
the
media
instead
of
just
changing
it.
So
if
anybody
has
any
objections,
we
don't
have
to
do
it
yet.
D
It's
it's
pretty
strict,
which
I
generally
like
I'm
a
big
fan
of
it.
Overall,
I'm
just
a
little
concerned
that
we
may
end
up
having
to
override
it
frequently
compared
to
the
eapv.
I
don't.
I
don't
have
a
good
answer
for
this,
because
either
we
have
a
very
strict.
So
it's
super
useful,
but
we
have
to
override
it
more
often
or
we
loosen
it.
So
it's
not
particular
not
as
useful,
but
it
means
we
don't
have
to
override
as
frequently.
D
B
Downgrade
some
of
the
particularly
strict
checks
to
warnings
that
way
they
still
show
up,
but
they
don't
block
the
merge
if
we
like.
If
we
want
something
like
that.
D
D
I
kind
of
on
the
topic
of
the
bot
commenting
so
much.
I
kind
of
almost
wish
the
bot
would
comment
after
the
the
person
has
managed
to
clear
all
of
the
things
rather
than
it's
like
every
single
person
has
errors
like
100
of
time,
and
so
it's
useful
to
have
the
bot
tell
the
person
hey.
You've
got
errors
go
look,
but
for
me
personally,
I
would
like
it
to
receive
notification
when
the
boss
says
hey
this
person,
finally
fixed
all
the
errors,
it's
time
for
you
to
go,
look
at
their
pr
at
the
moment.
D
I
basically
just
every
single
time.
I
see
someone
comment
if
I
don't
see
the
bot
reply
to
that,
then
I
go
check
but
oftentimes
it's
just
I'm
faster
than
the
bot,
and
so
they
still
have
a
bunch
of
errors.
I
don't
know
how
other
people
feel.
I
know.
B
A
A
All
right
is
there
any
precedence
like,
even
if
it
is
marked
as
required,
will
it
go?
A
Will
it
go
in
residence
like
there
would
be
bot
number
one
going
first
part
two
going
next
and
then
we
can
decide.
Then
this
vip
part
will
go.
D
Oh,
I
see
no,
currently,
they
all
run
simultaneously
in
parallel
and
really
we
only
we
have
so.
We
have
the
auto
merge
bot
that
basically
just
checks
and
comments
on
who
needs
to
approve
a
thing,
and
then
we
have
the
ipv,
which
does
everything
else.
The
eip
bot
does
do
a
handful
of
other
things,
but
it
doesn't
actually
come
up
say
much
very
often,
so
I
think
having
them
in
parallel,
I
think,
is
probably
the
best
bet.
D
Oh
eap,
bot
is
the
one
that
requests
editors,
I
think
having
them
in
parallel
is
appropriate
here
it
makes
it
so
it
gets.
People
get
the
information
they
need
as
fast
as
possible.
A
Right,
so
just
for
declaring
clarity
of
the
decision
here
related
to
this
particular
issue.
Are
we
okay
to
have
it
enabled,
although
it
has
already
been
enabled
by
mac
and
whatever
issues
will
come
up,
sam
may
be
able
to
help
them
fix
it,
and
we
can
revisit
this
in
the
next
making.
D
A
Okay,
so
yeah
for
people
documenting
notes.
Eipw
has
now
been
added
as
a
mandatory
check
and
if
there
is
any
issue,
if
there
is
any
very
strict
rule,
sam
may
be
helping
them
make
them
go
easy.
So
we
do
not
stuck
and
bart
does
not
stop
things,
and
we
can
revisit
this
in
the
next
meeting.
A
Moving
on,
as
we
were
discussing
2.1
that
was
proposal
to
include
superseded
status
by
superseded
by
is
there
anyone
in
this
group.
Presently,
I
think
that
it
is.
It
is
something
that
can
be
considered
and
that
has
to
be
changed
in
eip1.
I
believe
right.
A
A
I
don't
see
the
proposal
in
this
meeting
yeah-
it's
not
here
in
this
meeting,
so
I
I
can
let
it
be
there
and
maybe
we
can
expect
some
more
feedback
and
comment
from
other
eip
editors
if
they
have
their
in
any
strong
feeling,
either
in
favor
or
and
against.
So
we'll
keep
this
issue
open.
A
Yeah
yeah
no
relates
to
will
will
be
the
next
one
yeah.
So
I
was
just
talking
about
superseded
by
superseded
by
so
yeah.
There
is
a
request
to
change
in
the
name
of
one
of
the
headers
in
preamble
section.
The
issue
number
is
five:
two,
six
five.
A
Moving
on
to
the
next
sub
item
that
is
issue
number
5274,
it
is
the
proposal
for
eip
preamble
include
relates
to
as
an
optional
field.
This
is
by
again
by
the
same
user.
D
My
personal,
I
don't
I
don't
feel
super
strongly
on
this
one.
My
personal
general
preferences
is
that,
in
my
experience,
people
who
reference
eips
gratuitously
generally
would
have
a
better
eip
like
the
quality
would
be
better
if
they
just
didn't
reference
so
many
iaps
and
the
act
of
requiring
that
they
add
them
to
the
required
field,
forces
people
to
really
think
about
the
eips
they
want
to
depend
on
and
it
causes
them
to
drastically
limit
and
constrain
the
set
of
vips
they
depend
on.
It
makes
their
eip
overall
better.
D
That
being
said,
like
there's,
probably
other
ways
to
solve
that
problem,
we
could
just
you
know.
Editors
can
just
spend
more
time,
coaching
people
and
trying
to
work
through
them
and
say:
do
you
really
need
this
one?
You
really
need
this
one.
You
really
need
this
one.
It's
a
little
bit
more
effort
than
just
saying
hey.
You
can
include
as
many
as
you
want,
but
beware
you
have
a
hard
dependency
on
all
of
them,
so
your
call
yeah,
like
I
said,
I'd
like
to
solve
that
problem.
D
B
D
B
Of
adding
more
context
than
less
context
like
I,
I
don't
see
a
problem
with
referring
to
other
eips
that
aren't
mandatory,
even
if
they're
just
interested
or
interesting
reading.
B
So
I
think
you
and
I
have
different
opinions
there,
but
I
also
don't
think
we
need
a
relates
to
field
because,
like
we
have
marked
down,
we
can
just
link
to
things
if
we're
related
to
them.
So.
D
Yeah
and
for
what
it's
worth,
I
was
editing
one
of
my
eips
today
and
I
added
a
link
to
eip165
and
I
was
like,
oh,
but
now
I
have
to
add
it
to
the
require
section
dammit
I
removed
it,
but
I
will
admit
the
text
was
slightly
worse
because
of
it
like
yeah.
If
you
want
in
65
would
have
been
like
a
perfect
example.
D
Like
I
was
saying
you
know,
I
was
suggesting
in
my
eop
that
authors
should
also
implement
some
kind
of
introspection
or
interface
detection
mechanism
such
as
the
ip165,
and
so
I
do
recognize
the
value
in
any
sort
of
links.
It's
not
lost
on
me.
B
Yeah,
if
we
were
like
referring
to
some
so
just
because
we
have
get
and
we
have
like
markdown
rich
links,
I
think
internal
eip
references
are
always
like
fully
qualified.
It's
it's
very
difficult
to
have
a
more
accurate
reference
section
than
you
know.
The
file
name
and
the
git
commit
hash.
But
if
we
did
allow
external
references,
I'm
fully
on
board
with
like
fully
qualified
references
and
just
like
you're
describing.
E
E
D
D
D
E
Because
the
specification
section
should
have
nothing
but
normative
references,
but
to
mount
a
reasonable
motivation
and
rationale
can
can
have
you
referring
to
non-normative
references
that
are
part
of
your
argument,
but
not
part
of
your
specification.
D
I
see
so,
would
you
would
you
be
okay
with
allowing
allowing
non-reque
links
to
non-required
eips
in
the
non-normative
sections,
just
free
form
so,
like
I
can
just
say
my
motivation,
blah
blah
c
eip123.
E
Yeah
often
your
motivation
is
that
this
is
an
alternative.
If
you
can't
talk
about
what
you're
an
alternative
to
your
floundering,
making
statements
of
fact,
with
nothing
to
back
them
up.
D
Right,
I
mean
I
think
I
can
probably
be
convinced
by
sam's
suggestion
that
we
just
and
what
greg
described
you
know
we
just
for
the
non-normative
text.
You
can
link
to
any
other
eip.
I
would
like
to
retain
the
requirement
that
the
status
be
further
along
than
your
eip
or
immutable
in
some
way,
just
because
we
even
for
the
non-normative
sections,
I
really
don't
want
people
linking
eips
that
are
going
to
change
drastically
and
then
therefore
change
the
non-normative
content.
A
Us
so
is,
is
there
action
needed?
Like
I
see,
this
is
in
the
issue
form.
D
E
D
A
No
problem
with
that
that
sounds
good
to
me
because
I
see
the
opinion
are
divided
here
like
some
of
them
are
in
favor,
and
some
of
them
are
in
again.
So
let's
continue
discussing
in
that
issue
and
if
we
make
a
concrete
decision
on
that
in
the
issue
itself,
it's
fair
enough.
If
not,
then
I
can
bring
it
back
in
the
next
meeting
and
see
where
we
are
okay,.
D
And
I
I
still
do
feel
worried
that,
while
in
the
ideal
scenario
where
all
the
editors
are
good
editors,
this
solution
would
be
fine,
I'm
concerned,
because
I
see
a
lot
of
vips
where
people
just
link
to
you
know
a
dozen
different
things
and
it
makes
the
standard
incredibly
hard
to
follow
and
read
and
understand
because,
as
gavin
said,
people
like
to
write
history
books
in
their
motivation
section
and
the
motivation
section
should
be.
You
know
a
succinct,
pithy
description
of
why
this
is
a
useful
thing.
E
E
A
All
right,
okay,
so
yeah,
let's,
let's
keep
it
the
issue
we
continue
discussing,
let's
have
more
feedback
collected
from
eip
editors
and
if
the
issue
is
not
resolved,
we'll
bring
it
up
in
the
next
meeting.
I
hope
the
proposer
also
joins
the
next
meeting,
because
I
don't
find
him
on
the
call
moving
on
to
the
next
number
that
is
5294.
A
D
A
D
A
D
A
Okay,
number
six
is
about.
No,
I
think
I
I
mistakenly
have
added
the
wrong
number.
The
number
is
5272,
it
is
about
add,
rfc
information
to
ethereum.
D
Yeah,
I'm
so
the
the
tldr
my
position
at
the
moment
is
that
I
don't
have
any
problem
with
linking
to
rfcs.
My
problem
is
the
door
that
it
has
potential
to
open
because
we
actually
do
get
quite
a
few
people
who
want
to
link
to
their
new
standard
repository.
D
These
are
not
we're
opening
the
door
to
people
to
argue
that,
oh
my
standard
repository
should
be
allowed
as
well,
and
we
do
get
people
suggesting
this
like
they're
like
well,
you
reference
rfc
2119,
so
that's
a
standard
repository
thing
which
reference
mine
as
well,
and
so,
if
we
had
like
a
strong
mechanism
like
a
good
shelling
fence
for
saying
you
know
preventing
this
from
happening,
then
I
would
feel
a
little
better
about
rfcs,
in
which
case
I
wouldn't
care,
whether
we
linked
them
or
included
them
or
whatever.
D
The
one
reason
I
do
like
the
current
suggestion
of
including
the
rfc
is
wholesale
is
because
this
allows
anyone
to
include
any
standard
from
any
other
place
as
long
as
they're
willing
to
copy
it
over
wholesale
into
the
repository
and
they're
allowed
to,
whereas
if
we
link
to
it
now
we
have
to
get
in
the
fight
over.
You
know
what
external
resources
are
people
allowed
to
link
to
and
what
aren't
right
now,
the
it's
very
simple.
D
None
is
the
answer,
and
we
can
give
that
answer
out
very
quickly
very
easily
and
we
can
stick
to
it.
We
don't
have
to
fight
with
people,
whereas
if
we
start
saying
some,
then
things
get
much
harder.
D
Require
that
any
standards
that
we
link
to
must
be
around
for
three
years
and
matt
suggested
30.
I'd,
think
I'd
be
okay
with
30.
like
if
you've
got
a
standard
repository
and
still
around
for
30
years.
I
mean
that
that's
like
what
rfcs,
maybe
a
couple
other
from
the
I,
the
ietf
and
not
much
else,
and
so
it
does
give
us
a
pretty
nice
thing
and
sam's
question.
What
is
a
shelling
fence?
A
shelling
fence
is
a
yeah
line
in
the
sand.
D
It's
it's
more
specifically
it's
a
thing
that
you
can
reasonably
believe
that,
once
you
cross
some
blurry
line
when
you
get
to
this
thing,
it's
very
clear
that
you
have
a
new
line
that
you
will
not
cross,
and
so
it's
it's.
Basically,
if
you
imagine
slippery
slope,
a
shelling
fence
is
some
fence
that
everybody
can
agree
on
where
everybody
is
everybody
involved
in
this
process
that
it
will
be
very
clear
when
you
cross
that
later.
A
So
is
there
a
general
consensus
of
letting
it
have
for
like
let's
go
ahead
with
this
proposal
at
rfc
information
and
keep
it
there
for
a
few
years.
D
So
I
think
the
disagreement
right
now
is
there's
three
options:
one
continue
their
current
policy,
which
is
do
not
allow
any
external
links
whatsoever.
Two
allow
external
links
to
some
subset
of
things,
and
then,
if
we
go
with
two,
we
have
to
define
what
that
subset
of
things
are
option.
Three.
Is
we
allow
people
to
import
external
standards
into
the
repository
as
assets
and
then
we
don't
care
where
they
come
from
as
long
as
they
are
imported
into
the
repository?
So
that
way
we
can
be
sure
do.
C
D
Okay,
so
sam
has
allowed
himself
to
do
it.
So,
yes,
I
guess
we
do
collectively
yeah
that
I
mean
this
is
why
this
is
coming
up,
because
people
are
wanting
something
here
and
sam's
is
one
such
person.
I
guess.
D
Maybe
that's
some
bias
making
me
think
it
happens
more
freely.
D
So,
regarding
greg's
suggestion
of
just
common
law
or
precedent-based
law,.
D
My
two
problems
with
that
are
one
and
we'll
discuss
this
more
later,
but
the
whole
credible
neutrality
thing
it's
really
hard
to
like.
When
you
have
just
say
editors
decide
if
the
editors
are
all
totally
honest
and
on
the
same
page
and
agreement
and
they
align
with
the
ethos
of
the
broader
community,
then
that
works
great.
The
problem
is,
is
there's
no
way
to
guarantee.
D
They
want
to
help
and
they're
being
helpful,
but
they
just
don't
agree
on
what
is
acceptable,
and
when
that
happens
now
we
have
like
a
change
in
the
ethos
and
that
change
may
go
in
the
direction
of
the
community
as
a
whole
or
it
may
go
against
the
direction
of
the
community,
and
so
now,
if
it
goes
in
the
direction
against
the
community,
now
you
have
lost
some
credible
neutrality
with
with
the
community.
D
D
But
not
that
allowed,
and
the
second
reason
I'm
not
a
huge
fan
of
it
is
just
because
we
historically
have
been
very
short
in
editors,
and
I
will
admit
lately,
there's
been
a
lot
more
active
editors,
and
so
maybe
this
is
not
as
big
of
an
issue
as
it
used
to
be,
but
we
have
also
gone
through
times
of
lots
of
editors
and
then
they
all
disappear,
and
so
hopefully
you'll.
D
Forgive
me
if
I
assume
that
some
subset
of
the
people
in
this
room
right
now
will
be
gone
by
the
end
of
the
year,
and
I
will
be
back
to
the
only
active
editor
and
once
again
having
to
do
all
the
work
myself.
And
in
that
scenario
I
do
not
want
to
be
getting
engaging
in
debates
and
discussions
with
every
single
author
that
wants
their
thing.
A
D
B
D
I
mean
my
personal
policy,
which
I
don't
think
is
written
down.
Is
everything
must
be
cc0
licensed,
which
basically
forbids
external
standards?
I
know
that
it's
not
everybody
follows
the
same
policy,
I'm
more
of
it
and
is
one
of
the
many
things
that
we
don't
all
agree
on.
As
editors.
D
D
A
A
Yeah,
this
is
an
interesting
comment.
I,
if
something
is
murdered,
it's
very
likely
to
stick
around
so,
let's,
let's
keep
it
open
and
we'll
collect
some
more
feedback
from
other
eip
editors,
and
if
we
see
we
can
have
an
unanimous
decision.
That
would
be
the
best
case
scenario.
If
not,
then
we
can
try
to
maybe
make
some
changes
in
the
pull
request
and
come
to
a
general
agreement.
A
All
right,
moving
on
to
the
next
item
listed
here,
this
is
this
particularly,
is
very
interested
because
we
have
been
planning
to
discuss
this
for
past
few
meetings.
Now
that
we
have
it
in
form
of
pull
request,
I
believe
it
will
be
easier
to
maybe
discuss
and
come
on
a
decision.
It
is
about
how
do
we
write
erc
and
eip,
especially
for
documentation
purposes?
A
We
did
make
one
change
on
eip1
that
wherever
it
was
written
as
erc
for
documentation,
we
did
write
it
as
eip,
but
this
pull
request
is
to
suggest
that
it
should
be
written
as
erc
any
thoughts.
People
would
like
to
share.
B
D
D
A
I
think
one
important
feature
change
that
we
discussed
earlier
as
well
like
if
this
has
to
be
done.
We
might
want
to
like
change
the
header
that
is
generated
for
every
eip,
because
currently
it
is
written
as
eip.
No
erc,
no
code,
no
networking
and
no
interface.
It
is
just
eip,
followed
by
the
number.
D
And
so
I
think
that
at
least
for
this
initial
change,
if
I
understand
correctly,
it
would
just
be
changing
the
links
relative
links,
people
put
in
their
eips,
it
would
not
be
changing
anything
else,
and
that
being
said,
if
we
did
this
change,
I
can
definitely
see
wanting
to
do
a
follow-up
change
that
also,
maybe
edited
the
rendered
page
and
what
not
and
then
I
do
not
think
we
should
change
the
file
names,
though,
because
that
would
be
a
huge
headache.
A
I
may
be
wrong
here,
but
for
some
reason
it
feels
to
me
if
we
are
not
changing
the
header
and
we
are
making
this
change
in
documentation,
we
are
inviting
confusion
in
terms
of
eips
and
ercs.
Again
like
earlier.
We
agreed
that
the
ercs
are
standard
track
proposals.
They
are
standard
attack
eips
and
that's
why
or
like
all
other
standard
track
eips.
It
is
also
documented
at
least
documented
as
the
eip
and
people
are
free
to
call
whatever
they
want
to
call
it.
D
I
think
that's
fair.
I
can
see
the
argument
that,
if
we're
going
to
do
this,
we
should
do
it
all
at
once,
meaning
I
still
don't
think
we
should
rename
the
files
and
I
don't
think
we
should
change
the
the
number
at
the
top.
But
I
can
appreciate
simultaneously
updating
the
rendered
page
to
render
them.
D
C
Maybe
the
zoom
is
plugging.
There
are
a
lot
of
erc
links
in
the
erc,
the
different
eip
and
erc
category
that
start
erc
dash
number
and
then
link
to
eip
dash
number
dot,
md.
A
Generally
speaking,
I
feel
like
this
would
be
an
easy
convincing
point
for
people
who
are
calling
I
mean.
I
know
the
community
is
very
big,
very
strong
and
they
have
their
own
mind
to
decide
and
call
whatever
they
want
to
call.
But
when
an
author
is
documenting
a
proposal
and
he
or
she
is
trying
to
refer
to
an
erc
category
proposal,
he
is
writing
erc-20
and
directing
it
towards
eip
20
dot
md.
He
knows
that
it
is
called
as
eip20.
A
So
it
may
be
way
easier
to
convince
that
you
see
it
is
the
ip20.
Let's
call
it
eip20
and,
let's
start
educating
people
ercs
are
standard
track,
eips
category
eerc,
but
that's
again
my
argument,
my
thought
is
there
any
suggestion
how
we
can
collect
more
feedback,
and
how
can
we
come
up
with
a
solution
that
we
can
start
educating
people.
A
One
thing
that
we
can
do
is
like:
we
can
start
sharing
this
pull
request
and
ask
more
people
to
come
and
have
feedback
how
they
would
like
to
see
it.
It's
it's
about
community,
so
maybe
it's
beyond
editors
only
and
we
can
probably
invite
more
community,
though
I
don't
know
how
much
is
the
reach,
but
does
that
sound
like
a
reasonable
solution
for
now.
D
I
mean
I'm
okay
with
punting
this
until
later,
I'm
always
hesitant
with
inviting
the
community,
because
it's
a
very
amorphous
set
of
people
and
it
can
very
easily
lead
to
brigading.
Like
you
know,
someone,
that's
got
a
lot
of
twitter
followers
tweets,
hey
everybody
go
comment
on
this
and
all
of
a
sudden
you
have
100
people
agreeing
with
that
person,
but
none
of
them
posing.
You
know
new
arguments,
they're
all
just
inheriting
what
their
thought
leader
has
told
them
to
parrot.
D
Does
I
think
several
of
these
are
yours:
gavin,
remove
old
eap,
20
file,
disallowed
smart
in
eap,
title
description,
centralized
discussions,
2
and
last
call
edition
with
changes
in
standard,
so
I
think,
for
we
can
skip
number
10.
The
person
who
wrote
that
I
don't
believe
is
here,
and
so
we
would
just
be
agreeing
with
ourselves.
D
D
Okay,
let's,
let's
get
rid
of
it,
that
one's
easy
yeah
is
anyone
passionate
about
talking
about
the
word
smart
in
titles
descriptions
today?
If
not,
I
propose
we
skip
it
until
next
week.
B
Yeah,
I'm
I
I
don't
see
it
enough
to
think
it's
a
concern
like
we
looked
through
quickly
on
the
apprenticeship
meeting
where
smart
was
in
titles
and
it
was
almost
always
paired
with
smart
contract
except
for
one
and
yet
that
one
was
just
a
bad
title.
So
I
I'm
okay
with
allowing
it,
but
we
should
just
be
more
careful
and
forcing
people
to
have
descriptive
titles.
D
Okay,
I'm
fine
with
that.
For
the
record,
though,
I
do
think
that
if
you're
saying
smart
contract,
you
should
just
say
contract,
I
think
that
it's
redundant
say
smart
contract
when,
yes,.
D
Okay,
we
can
talk
about
some
other
time,
but
I'm
fine
with
not
standardizing
on
that,
at
least
not
making
it
official.
A
There
can
be
some
exception
for
that,
and
we
discussed
it
briefly,
as
I
mentioned
that
in
the
eip
apprenticeship
meeting
we
can,
I
mean
it
can
be
in
discretion
of
eip
editors
right,
it's,
it
is
like
not
good
at
all.
Probably
it
can
be
recommended
there.
D
D
I'd
say:
number
five
number
three
and
five
are
more
or
less
the
same
conversation,
but
I
think
five
is
one
that
we
need
to
resolve
sooner
rather
than
later.
Whereas
three
is
one
we
can
delay
if
we
need
to.
A
All
right,
I'm
gonna,
share
the
link
here
and
wait
available
on
agenda,
so
I
know
there
has
been
discussion
going
on
on
the
discord.
D
So
for
those
listening
in,
I
will
try
to
describe
the
situation
as
fairly
as
I
can
feel
free
after
I'm
done
to
correct
me
in
all
the
ways
that
my
biases
are
showing
the.
I
think
the
crux
of
the
issue
to
skip
all
of
the.
What
led
to
this.
I
think
the
crux
of
the
issue
from
my
perspective
is
that
there's
a
disagreement
on
whether
editors
should
be
weather.
D
Basically,
everything
that
we
discussed
has
led
me
to
inclusion.
I
think
that's
the
core
disagreement,
I'm
in
the
camp
of
I
think
we
treat
everybody
equally
if
italic
shows
up,
I'm
probably
gonna
treat
him
more
strictly
or
when
he
shows
up.
I
treat
him
more
strictly
than
I
treat
other
editors
specifically,
because
I
want
to
make
it
clear
that
no
one
gets
special
treatment.
D
I
believe
and
I'll
let
matt
jump
in
here
in
a
second,
but
I
believe
matt
holds
the
position
that
we
should
be
kind
of
rewarding
and
favoring
and
giving
nicer
treatment
or
better
treatment
to
the
long-time
contributors
you
know
like-
and
this
is
called
before,
like
I've
conflicted
with
peter
on
a
number
of
occasions
on
this,
because
peter
hates
the
iep
process
and
he
hates
it.
D
When
I
tell
him
to
do
you
know
the
busy
work
that
every
eip
author
has
to
do,
and
I
keep
telling
him
no,
you
have
to
do
this
busy
work
and
eventually
hand
it
off
to
tim,
and
that
worked
worked
great
because
tim
just
did
the
busy
work
and
we
got
it
through
pretty
quickly.
But
this
isn't
the
first
time
this
conflict
has
come
up
where
long
time
contributors
want.
D
You
know
preferential
treatment
or
special
treatment,
or
you
know
to
for
things
to
go
a
little
smoother
for
them
than
it
has
been
everybody
else,
they're
not
have
to.
They
don't
have
to
follow
the
rules
like
everybody
else
does,
and
I'm
pretty
strongly
against
that
and
to
finish
the
reason
I'm
against.
D
That
is
because
I
do
think
the
eip
process
is
part
of
ethereum's
governance
process,
and
I
think
it's
very,
very
important
that
ethereum's
governance
process
remains
as
credibly
neutral
as
possible,
and
one
way
to
remain
credibly
neutral
is
to
make
it
very
very
obvious
that
there
is
no
favoritism.
There
is
no
old
boys
club.
There's
no
insider
deals,
there's
no,
because
everybody
is
treated
exactly
the
same.
We
can
be
confident
that
there's
nothing
underhanded
going
on
there's
no
one
trading
favors
behind
the
scenes,
because
everybody
follows
the
exact
same
set
of
rules.
E
D
Sure
so
like
there
are,
that's
the
second.
The
second
thing
that's
issue
number
three
on
our
agenda
here
is:
how
can
we
resolve
this
very
specific
problem
of
eip
number
assignment,
but
I
think
the
broader
problem
is
that
the
editors
currently
don't
all
agree
on
whether
we
should
be
giving
preferential
treatment
to
the
core
devs
and
long-time
contributors,
or
should
we
treat
everybody
the
same,
and
I
think,
even
if
we
solve
the
numbering
problem,
we're
still
going
to
have
this
problem
crop
up
somewhere
else,
and
I
think
we
should
resolve
that.
E
E
E
C
E
E
E
D
D
C
I
guess
I
I
didn't.
I
don't
really
see
it
as
preferential
treatment
because
to
me
it
their
contributions
more
weighed
into
like
my
editorial
judgment,
of
whether
or
not
they
were
spamming.
The
repo
everything
else
was
followed
according
to
eip1
and
it's
not
like
they
were
breaking
any
kind
of
rules
and
I
was
allowing
them
to
break
rules.
C
There's
no
rule
against
sniping
an
eip
number
and
you
know
if
somebody
else
came
in
with
that
number.
Maybe
it
would
have
been
more
likely
that
they
created
that
spam,
but
I
just
feel
like,
given
you
know
my
experience
working
with
them
in
the
past,
that's
not
something
they
would
do,
and
so
I
felt
that
you
know
they
have
followed
all
the
the
standard
procedures,
and
so
I
don't
think
it's
the
same
as
like
peter
wanting
to
just
move
something
to
final,
which
I
like
agree
it.
I.
C
D
So
I
think
what
you
described
there,
I
think,
is,
I
think,
what
you
described
aligns
with
my
feeling
situation,
because
my
feeling
is
is
that
if
your
familiarity
with
a
particular
author
comes
into
play
or
decision
making,
then
it
by
definition,
is
not
a
credibly
neutral
process
any
longer
like
if
you're
saying
well,
you
know
I
know
alex.
I
know
him
personally,
I
we're
friends,
you
know
I
work
with
them.
I
have
a
history.
E
But
that's
not
the
same
thing:
it's
you
can
know
them
as
a
contributor
to
ethereum
right
like
I'm,
not
friends
with
alex.
Like
I
mean,
we've
met
a
few
times
but
like
I
know
who
he
is
because
I
know
he's
the
guy
who
works
on
all
these
evm
eips
and
like
he
does
really
good
work
and
I'm
not
an
editor.
But
if
I
was,
I
would
be
like
willing
it's
not
even
to
like
accommodate
him,
because
it's
like,
I
think
I
agree
with
matt
that,
like
he
generally
followed
the
process.
E
D
D
Sure,
and
so
that's
why
I
think
we
have
the
ethos
of
misalignment
like
you
and
matt.
I
think
that's
reasonable,
and
I
I
don't
want
to
claim
that.
I
believe
that
mine,
my
view
on
the
credibility
here
is
necessarily
right.
I
think
that
the
disagreement
is
that
you
guys
think
that
is
an
acceptable
behavior
and
I
think
that
is
unacceptable
behavior
and
we
need
to
come
up
with
a
cohesive
vision
on
you
know
what
is
acceptable
behavior
for
me.
D
I
get
it
or
should
we
be
looking
at
the
contribution
history
and
you
know,
there's
eap,
authors
who
have
submitted
10
eips
in
the
past,
and
I
really
would
rather
not
give
them
any
personal
stream.
I
think
their
ips
are
terrible.
It's
now
it
comes
down
to
like
am
I
preferring?
Is
it
just?
If
you
have
n
eips,
then
you
get
treated
better,
but.
E
Consensus
system
is
going
to
end
up
like
that.
It's
like
the
same
thing
as
all
core
depths.
You
know
like
another
way
to
like
frame.
This
would
be
like.
Why
do
we?
Let
you
mika
speak
on
awkward
right,
like
people
could
just
say
like?
Oh,
you
know
he's
not
part
of
a
client
team.
He
doesn't
like
he
shouldn't
be
here
and
we
don't
have
like
a
soft
rule
for
that.
You
know
it's
like
generally.
You
make
good
contributions
and
people
kind
of
recognize.
That
and,
like
you
know,
you
get
like
preferential
treatment
relative
to.
E
I
don't
know
some
random
person
on
the
discord
who
shows
up
and
like
I,
I
don't
know
that
we
could
draw
a
line
there
and
I
think
if
we
drew
a
line,
it
would
just
be
bad
because
it
becomes
like.
E
I
don't
know
you
just
can't
like
manage
this
as
like
a
pure
bureaucracy,
because,
like
people's
idiosyncrasies
kind
of
end
up
in
different
places
and
if
they're,
good
contributors,
you
need
to
accommodate
that
some
extent
and
some
people
want
a
nice
eip
number.
So
I
I
don't
know
especially
for
something
like
for
something
like
that.
Where
it's
like,
you
know,
like
very
soft
abuse
of
the
bot,
you
could
say
I
that's
kind
of
why
I
see
it
as
a
non-issue
I
guess,
except
if,
if,
if
alex
had
like
spammed
a
thousand
issues,
you
know.
D
Something
and
then
alex
immediately
sniped
the
problem
is,
is
we
cannot
the
only
reason
we
don't
believe
alex
found?
The
issues
is
because
we
trust
alex,
and
I
really
don't
like
the
idea
of
saying
I
trust
that
guy,
even
though
all
the
symptoms
look
like
he
did
something
very
bad
that
would
have
should
have.
We
should
have
gotten
him
banned,
even
though
it
looks
like
that.
I
trust
him,
whereas
that
other
guy,
who
did
the
exact
same
thing?
I
don't
trust
him,
because
you
know
I
don't
have
a
history
of
them.
E
D
Sure
so
I
have
the
ability
to
mess
up
the
process,
but
my
hope
would
be
that
if
I
did
mess
up
the
process
I
would
be
kicked
out
and
everything
would
be
reverted.
And
so,
in
this
case
you
know
someone
came
in
and
messed
with
the
process
potentially
and
so
the
you
know.
Should
we
allow
that?
Should
we
let
it
stand,
and
this
is
where
I
don't
think
we
should.
D
I
agree.
I
agree
with
that
when
I
brought
this
issue
up
initially,
the
the
number
was
not
actually
the
big
deal.
The
the
bigger
issue
was
that
I
saw
that
sam
told
an
author
to
renumber
their
eip
and
then
they
refused
to
renumber
the
eip
and
they
merged
it.
D
I
didn't
actually
notice
that
alex
was
a
co-author
at
the
time
and
when
I
initially
saw
the
issue
and
then
you
merged
it,
I
assumed
initially
that
you
just
didn't
notice,
sam's
comment
and
you
merged
it
without
realizing
the
author,
didn't
respect,
sam's
comment
or
respond
to
it
or
anything
like
that.
So
I
was
like
hey.
This
is
just
a
mistake.
You
know
this
author
is
maybe
maybe
they
missed
the
comment
from
sam
or
they
forgot
about
it
or
something,
but
then
the
more
I
dug
the
more
I
was
like.
Oh
wait.
D
D
Every
other
time
that
this
has
occurred,
it's
brought
up
in
public
and
so
like
this,
the
issue
that
triggered
this
all
was
the
eap
number
sniping,
but
by
itself
that
was
not
that
big
of
a
deal-
and
I
probably
wouldn't
have
even
I
would
have
pushed
a
little
bit
to
renumber
it
after
the
fact.
But
if
that
was
the
only
issue,
someone
got
away
with
this
night.
People
have
gotten
away
with
snipes.
Before
we
know
of
several,
I
probably
would
have
let
it
slide.
D
My
bigger
far
bigger
issue
is
how
the
situation
was
handled
and
who
was
involved
with
it
again
the
private
discussions
it
feels
like
it
is
not
how
we
have
historically
handled
any
of
this.
We
have.
We
had
an
off
an
editor
who
specifically
told
the
author
to
change
the
number
and
there's
no
public
discussion
after
that
it
just
you
know,
changed
like
these
are
the
things
that
are
the
issues
because
to
an
outside
observer,
and
this
is
to
answer
your
question.
D
My
problem
here
is
to
and
out
to
the
observer,
it
looks
like
you
have
a
couple
of
eip
editors.
You
have
an
eap,
editor,
who's,
an
author
and
the
ip
editor
who
you
know
followed
a
normal
procedure
of
renumbering
snipes
and
then
another
aip
editor
who
just
merged
it
blindly
like
without
respecting
that
first
editor's
comments,
and
at
best
you
know
it
looks
it's
sketchy
looking
and
so
from
a
credible
neutrality.
Point
of
view
not
not
arguing
that
anyone's
non-neutral
here,
just
from
appearing
neutral
to
the
public.
D
This
does
not
appear
like
a
neutral
process.
This
appears
very
much
like
our
traditional
governance
institutions
where
back
room
deals,
happen
and
people
engage
outside
of
the
public
view,
make
decisions
and
then
just
apply
them
without
any
public
discussion
or
public
discourse
or
anything
like
that,
and
so
that
is
kind
of
the
bigger
issue.
D
That
and
again
this
ethos
misalignment,
where
I
think
that
I
guess
there's
really
two
issues
here:
there's
ethos
misalignment,
where
some
of
us
think
that
we
should
be
giving
preferential
treatment
like
tim
and
matt
to
long-time
editors
or
long-time
authors
and
contributors
and
there's
a
separate
issue
of
this.
You
know
that
the
whole
thing
occurred
behind
closed
doors.
We
don't
know
what
to
the
average
external
person.
We
don't
know
what
happened.
What
was
in
that
conversation?
Who
was
in
that
conversation
where
the
conversation
occurred?
You
know
what
what
was
exchange.
D
Was
it
just
a
a
request
and
an
okay
or
was
it
like?
Some
deal
was
made,
and
this
is
stuff
that
no
one
can
know
because
it
wasn't
done
in
the
public,
and
so
these
are
the
issues
that
the
numbering
really
doesn't
matter.
I
do
think
we
should
solve
it
to
kind
of
avoid
this
class
of
problems,
because
we've
been
getting
more
and
more
sniping
attempts
lately,
but
those
that
the
numbering
is
really
not
the
issue
in
my
opinion,
and
that's
not
what
I'm
worried
about.
C
C
You
know
how
or
when,
but
we
have
on
many
times
in
the
past.
You
know
overwritten
other
decisions,
and
typically
it's
like
followed
by
I'm
not
going
to
stop
you
or
like
I'm,
not
going
to
prove
this
myself,
so
somebody
else
can
approve
it.
That's
happened
like
many
times
in
the
past,
and
it
just
happens
that
sam
and
I
have
you
know,
worked
together
in
the
past
and
we
talked
somewhat
frequently-
and
I
happened
to
ask
him
hey.
C
D
So
I
I
personally
agree
with
that.
Then.
So
I
think,
if
you
would
have
posted
on
the
issue
and
sam
would
have
posted
the
response
from
the
issue,
then
I
think
it
would
have
been
less
of
a
problem,
though
most
likely,
if
you
would
have
posted
on
the
issue,
I
would
have
replied
and
say:
I'm
definitely
not
okay
with
this,
and
then
we
would
have
had
to
have
a
discussion,
and
you
know,
engaged
and
have
longer
this
longer
debate
that
we
need
to
have
about
numbering.
D
I
I
still
feel,
though,
that
so
that
would
that
would
resolve
the
half
of
the
issue,
which
is
the
the
decision
was
made
in
private.
So
so
that
is
one
problem.
I
don't
think
we
should,
as
editors
should
ever
be
making
decisions
in
private,
like
everything
should
be
done
in
the
public,
to
maintain
our
credible
neutrality
and
you're
right.
What
you
described
would
have
addressed
that
half
of
it.
D
I
still
don't
think
it
addresses
the
issue
of
it's
alex,
so
it's
okay
like
I,
don't
think
that
should
ever
be
an
answer
to
anything
that
comes
up
in
the
ips
repo
that
it's
so
and
so
so.
Therefore,
it's
okay
like
or
it's
so
and
so
so.
Therefore
we
can
trust
them
like.
I
don't
think,
that's
how
we
should
be
doing
business
for
any
big
issues
or
small
issues
like
they
should
be.
Did
this
person
follow
the
rules?
D
Would
I
apply
this
rule
evenly
even
handily
to
everybody,
and
I
think
this
is
where
you
know
tim
and
matt
disagree
with
me
on.
Should
we
be
treating
everybody
equally
or
should
we
be
giving
preferential
treatment
to
long-term
contributors,
and
so
I
still
think,
even
if,
even
if
what
you
described
happened,
we'd
still
need
to
resolve
that
problem,
because
I
do
think
that's
going
to
come
up
again
and
again.
C
D
So
yeah,
I
agree
that
we
should
address
the
numbering
issue.
There's
a
this
is
so
if
we
very
briefly
switch
over
to
general
item
number
three,
there
are
several
options
that
I
think
would
completely
mitigate
this
entirely,
so
numbers
are
essentially
randomly
assigned
and
editors
don't
have
any
control
over
them
anymore
and
then,
if
you
happen
to
get
5000,
you
got
lucky
but,
like
I
said
I
I
still
would
like
to
resolve
the
issue
of
whether
editors
should
be
treating
core
devs
different
from.
D
So
some
examples
have
happened
in
the
past
and
some
of
these
I
think
you
and
I
agree
on
some.
I
suspect
we
don't
there's
that
peter.
You
know
has
repeatedly
requested
that
he
doesn't
have
to
follow
the
the
process
so,
but.
D
D
There's
one
that's
much
more
subtle
that
I
again
this
one
I
suspect
we
disagree
on.
I
have
noticed
that
when
a
core
dev
submits
an
eip,
it
gets
reviewed
with
like
within
two
days
and
not
by
me
like
someone
else
actually
beats
me.
It's
like
the
one
time
I
get
beaten
to
reviews
on
eips
is
when
a
courtois
submits,
and
this
is
a
subtle
one.
It's
nothing
that
you
know.
D
You
can
say:
hey
you're,
obviously
doing
something
bad
here,
but
it's
noticeable,
I
think,
to
repeat
eip
authors
who
get
frustrated
when
they
see
you
know
every
time,
vitalik
submits
something
or
his
name's
on
something
it
gets
reviewed
like
within
24
hours
and
it
gets
merged
like
almost
right
away
and
and
not
just
because
they're
they're
I
mean
he
does
do
a
pretty
good
job.
Writing
the
ips.
But
that's
not
always
it
like.
D
There
are
other
people
who
write
very
good
at
peace
and
they
take
a
long
time
to
get
reviewed
just
because
we
don't
have
the
staff.
It's
just
another
small
example
of
us
giving
preferential
treatment
to
a
inside
group
versus
an
outside
group.
D
So
they,
like,
I
said
it's
all
about
the
credible
neutrality
like.
I
think
that
it's
very
important-
and
perhaps
this
is
the
real
core
disagreement
between
us-
perhaps
is
whether
credible
neutrality
for
the
ap
process
actually
matters.
I
believe
it
matters
and
we
should
be
as
credibly
neutral
as
possible
like
it
should
be
as
plain
as
day
like.
D
If
someone
goes
and
really
digs,
they
should
be
able
to
find
absolutely
nothing
that
suggests
that
we're
giving
better
treatment
to
one
particular
group
or
some
other
particular
group,
and
if
someone
digs
a
day
they'll
find
a
number
of
cases.
You
know
where
we
are
potentially
giving
better
treatment
to
one
group
or
some
other
group,
and
I
I
believe
that
it
should
be
impossible
to
find
such
examples
of
things
and
so,
like
my
process,
just
coming
from
as
an
example,
I
go
through
the
eips
in
the
order
that
they
show
up.
D
I
ignore
who
the
authors
are.
I
treat
everybody
exactly
the
same,
and
that
includes
sometimes
telling
peter
to
go
away
because
and
he
has
followed
the
same
process,
everybody
else.
It
sometimes
means
that
I
leave.
You
know
vitalik's
pr
to
much
later
than
because
I'm
backlogged
other
people's
stuff,
but
these
are
things
that
give
us
credible
neutrality
that,
I
think,
is
very
important.
D
So,
on
the
the
very
immediate
issue,
though,
maybe
we
can
resolve
this
one,
we
do
need
to
decide
what
to
do
about
eip-5000.
I
would
like
to
at
least
renumber
it
to
something
else,
there's
a
pr
out
that
does
that.
I
believe
we
have
a
few
editors
that
have
agreed
to
it.
I
think,
if,
if
you're
willing
to
move
forward
with
that,
we
can
at
least
close
out
that
issue
and
move
move
on.
D
I
mean
sure
we
we
have
three
three
editors,
but
my
general
preference
is,
I
don't
think
we
should
like.
If
we
don't
have
unanimous-
or
at
least
no
one
arguing
against
it,
then
we
should
wait
quite
a
while,
and
so
the
question
is
is:
do
we
continue
discussing
and
over
the
next
month
or
so
and
eventually
maybe
renumber,
maybe
not
eip
5000
at
the
end
of
the
month.
D
Or
would
you
rather
just
us
renumber
it
now,
and
you
agree
that
you
know
you're,
I
I
don't
say
you
agree
but
like
I
don't
see
an
option
where
it's
we
don't
renumber
it
ever.
I
think
the
options
are
we
decide
we
continue
discussing
and
then
we
decide.
D
D
Okay,
so
we
can
keep
in
limbo,
continue
discussing
them.
Probably
the
on
the
pr
is
probably
the
best
place.
I
think.
A
Well,
yeah,
we
can
probably
take
it
for
a
few
more
days
weeks.
Whatever
is
needed
to
get
this
decided
and
people
are
free
to
leave
their
comments
on
the
request
number
that
is
added
here
in
the
agenda.
I
believe
one
of
the
important
questions
that
we
were
discussing
earlier
was
like
this
quarting
issue
or
so
for
squatting.
A
I,
if
I
have
to
like
put
it
in
the
work
for
the
note
writers,
which
generally
agree
that
if
we
find
some
not
so
useful
issues
or
requests
created
before
grabbing
a
good
number,
then
we
can
particularly
refer
to
them
as
a
squatting.
However,
this
is
not
exactly
that
issue,
but
it
is
about
the
authority
or
the
governance
process
that
can
be
particularly
considered
as
one
time
issue
and
could
be
discussed
in
the
pull
request
here.
D
I
think
the
the
summary
is,
we
have
lots
of
problems.
The
one
we
didn't
talk
about
was
the
yeah
numbering.
Unfortunately,
I
suspect
that
was
actually
one
of
the
easier
topics.
Despite
it
getting
a
lot
of
discussion.
A
Right,
maybe
we
can
have
it
on
like
top
of
our
agenda
for
the
next
meeting
we
could
not
touch.
A
D
D
One
option
would
be
to
you
know,
schedule
this
meeting
to
be
weekly
until
we
resolve
it
kind
of
as
punishment
to
us
recurring
punishment.
Until
we
fix
our
problems,
we
have
to
suffer
through
more
frequent
meetings,
but
I'm
not
sure
that
would
actually
help
like.
D
I
think
that
when
you
have
ethos
disagreements
like
this,
it
just
requires
a
lot
of
dialogue
and
that
dialogue
needs
to
be
spaced
out
enough,
that
people
have
time
to
go
home,
cool
down,
think
restructure
their
world
model
etc,
and
that
is
not
a
fast
process
like
that
can
take
weeks
months
years,
depending
on
the
topic,
and
so
I
I
don't
know
if
we're
gonna
get
this
resolved
anytime
soon.
I
do
think
we
need
to
keep
talking
about
it.
Yeah.
I
don't
have
any
quick
and
easy
paths
to
resolution
here.
A
A
D
See
if
you
can
get
feedback
from
other
people,
if
they're
willing
to
continue
engaging
on
a
more
frequent
basis,
like
all
the
parties
involved,
I
think
are
passionate
about
it,
but
I
think
also,
I
suspect,
most
of
the
people
would
rather
not
discuss
it
because
an
uncomfortable
topic
anytime,
you
have
political
or
ethos.
Disagreements
like
this.
It's
not
fun
to
discuss
them
and
oftentimes.
D
It's
not
you
don't
make
progress
either
like
it's,
you
don't
get
anywhere,
and
so,
on
the
one
hand,
you
know
scheduling
more
meetings
would
give
us
more
opportunity
to
discuss,
but
that
opportunity
may
just
be
wasted
if
no
one
actually
wants
to
engage,
and
so-
and
I
don't-
I
don't
know
so-
it's
probably
worth
at
least
talking
to
the
other
people
involved
and
seeing
if
they
want
to
engage
in
a
voice
call
more
frequently
until
we
get
this
resolved
or
if
they
think
that
would
not.
That
would
not
help.
D
I'm
really
quick
to
answer
jay's
question,
so
I
think
the
eip
bot
still
exists.
It
still
has
a
purpose.
It
is
still
being
used
and
at
the
moment,
basically,
we
have
a
long
list
of
things.
We
want
bots
to
do
for
the
repository
whether
they
go
into
eipw
or
the
eap
bot
doesn't
really
matter
to
me
at
least,
and
so
it's
really
just
you
know
who
gets
to
it
first,
if
someone
has
the
ipw
great
someone
adds
it
to
the
ap
bot
great.
D
We
just
want
things
to
get
improved
and
fixed
and
better,
and
so
I
don't
think
the
ip
bot's
dead.
It
still
has
a
large
number
of
things
that
eftw
doesn't
do
and
I
don't
believe
there's
any
intention
to
have
efw
do
many
of
those
things,
and
so
so
no
bot's
not
dead,
and
if
you
or
someone
else
is
interested
in
adding
features
to
it.
I'm
totally
fine,
it's
probably
good
to
coordinate
with
the
people
working
on
epw,
just
to
make
sure
you're,
not
both
working
the
same
thing
at
the
same
time
but
yeah.
E
E
That
is
no
way
that
I
can
set
a
test
environment
for
for
the
code
in
the
board
so
and
we
can
do
a
lot
of
progress
because
I
have
a
code
for
for
these
pull
requests
that
are
already
there
and
five
more
issues,
but
I
know
the
eipw,
which
already
I
tweaked
the
I
read
the
call
and
it's
good
but
yeah
there
are
things
that
the
is
not
gonna
do
and
we
never
do.
I
agree
with
you,
but
there
is
no
way
to
I
mean
there
is
no
way
to
test
it.
D
A
D
Yeah
feel
free
to
let's
talk
in
the
one
of
the
eip,
editing
channels,
and
let
me
know
in
there
what
you're
running
into
you
definitely
should
be
able
to
test
it.
I
know
elita
was
able
to
test
it
and
it
should
just
be
a
matter
of
working
in
the
ethereum
repo
and
attaching
the
bot
to
it,
but
I
can
maybe
try
to
help
you
a
little
bit
more
on
getting
through
whatever
roblox
run
into.
Let's
do
that
in
one
of
the
editing
channels.
A
Thank
you,
jay
for
sharing
a
concern
and
micah
for
a
resolution.
I
think
it
would
be
a
good
idea
in
general
to
put
any
question
comment:
concern
in
the
ap
editors
channel,
I'm
sure
someone
on
the
channel
if
they
find
an
issue
and
they
are
aware
how
to
resolve
it.
They
would
be
there
to
help
out
with.
A
So
thank
you
on
that
and
for
the
next
meeting
I
am
currently
considering
that
I
will
be
definitely
making
a
making
an
outreach
to
ap
editors
and
see
if
they
are
interested
in
having
next
week
meeting
but
because
most
of
them
are
already
gone.
Probably
we
can
have
the
next
meeting
two
weeks
from
now,
but
we
can
definitely
share
this
word
in
the
channel
to
collect
feedback,
and
if
they
are
interested
going
forward,
we
can
have
weekly
cadence
for
sometimes
at
least
till
we
get
some
resolution.
A
Well,
thank
you,
everyone
for
staying
a
bit
longer.
I
know
we
could
not
touch
on
most
of
the
things,
but
we
hope
to
get
a
get
on
it
in
the
next
meeting.
Have
a
good
rest
of
your
day.
All
of
you
bye.