►
From YouTube: EIPIP meeting #18
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/34
A
B
A
Okay,
so
there
is
just
one
last
comment:
I
added
to
the
pull
request
there
in
one
of
the
I
just
have
requested
to
remove
the
word
accepted
there.
I
think
in
the
comment
section,
I'm
not
sure
if
that
is
appropriate
or
not,
but
if
it
is
like
that
after
that
and
another
thing
that
I
wanted
to
discuss
was
on
the
part
of
the
living
status
so
for
living
status.
I
see
some
communication
on
the
other
should
be
one-sided
or
two-sided
and
the
status.
A
So
I
was
wondering
like
what
would
be
the
you
know,
ideal
situation
to
consider
it
because
the
ap
one
is
going
to
be
under
review
all
the
time,
but
changing
the
status.
Is
it
something
that
is
visible
and
should
be
considered
or
the
status
should
be
living,
but
we
will
be
considering
the
changes.
What
is
general
part
of
you.
B
So
there
are,
there
are
people
that
are
going
to
want
to
know
what's
happening
to
eip1
and
aren't
going
to
care
about,
what's
happening
to
many
other
eips
or
just
living
in
leaving
eips
in
general.
So
currently
we
have
an
rss
feed
for
last
call,
but
it
would
be
great
to
have
an
rss
feed
for
all
eips.
So
whenever
there's
a
change
in
state,
people
can
subscribe
to
that
are
state.
B
D
B
B
B
So
yeah,
maybe
it's
not
an
rss
feed,
that's
also
fine,
the
I
do
think
we
should
have
some
way
of
people
being
able
to
subscribe
or
see
that
these
changes
are
happening
because
people
are
going
to
care
about
what's
happening
in
eip1
and
they
shouldn't
have
to
go
and
look
at
eip1
every
week
just
to
see
if
something's
changed
and
look
through
all
the
different
pr's
and
make
sure
like
that,
we
should
make
that
fairly
easy
and
transparent.
That
stuff
is
happening
there,
so
whether
it's,
whether
it's
rss
feed
or
some
other
way.
B
That's
that's
fine.
When
I
had
thought
about
the
going
back
between
review
and
active,
it
was
if
it
changed
state,
then
the
rss
feed
would
show
that,
but
that's
an
optimization
in
just
like
relying
on
a
weird,
weird
part
of
the
process,
like
a
nuance
of
whatever
to
achieve
a
goal
rather
than
just
have
the
goal
and
then
achieve
it.
The
best
way
possible,
which
that
was
brought
up
by,
I
think
micah
on
the
on
the
pr.
B
But
as
far
as
if
there
are
living
vips
that
want
to
go
back
and
forth,
I
haven't
thought
about
it
enough
to
really
say
that
they
should
or
shouldn't
and
so
and
then
that's
kind
of
where
I
got.
I
didn't
feel
too
strongly.
We
needed
to
to
force
that
there
is
only
one
state
change
here,
given
that
we
just
don't
know
a
lot
about
living
eips
and
something
that
we
can
figure
out
as
we
go
along
down
the
road.
D
Yeah
I
mean
I
I
feel
like.
I
would
rather
see
living
eips
be
documented
in
another
way.
Like
obviously
ep
1
is
special
and
it's
unlikely.
We
can
change
that,
but
I
think
that
generally,
when
we
run
into
a
time
where
we
want
to
continue
updating
eep,
it
would
make
more
sense
to
do
those
updates
out
of
band
and
maybe
define
how
the
process
for
updating
and
where
those
updates
happen
as
an
eep
and
that
can
be
static.
A
C
A
A
A
B
C
D
C
B
C
B
C
A
So
I
mean
it's
it's
my
personal
opinion
here,
because
we
are
talking
about
standardization
process
and
every
time
the
arrow
way
points
it.
It
states
that
the
the
proposal
in
that
category
is
going
to
change
the
status.
So
let's
have
the
arrow
one
way,
but
while
documenting
what
living
document
is,
we
can
mention
it
clearly
that
it
is
a
living
document.
It
will
be
under
review
all
the
time,
but
this
status
is
going
to
be
living.
Is
it
something
that
is.
B
D
B
C
B
B
B
And
yeah
a
lot
a
lot
of
people
are
are
very
thinking
back
to
some
of
the
they
don't
care
about
it
until
suddenly,
everybody
does
and
changes
to
it
can
have
pretty
far-reaching
effects
like
the
like.
The
a
good
example
is
the
splitting
the
splitting
of
the
network
upgrade
process
and
the
standardization
process
actually
has
pretty
big,
far-reaching
effects
for
the
community
and
decision
makers
within
them.
C
B
A
Yeah,
I
think
that
is
a
good
idea,
since
this
eip
group
is
working
on
the
process,
improvement
part
and
looking
into
it.
So
one
of
the
eipip
group
member
can
do
that
or
maybe
from
the
cat
herders
official
account
if
people
would
want.
We
can
go
ahead
and
do
that
because
we
do
not
have
any
official
twitter
for
eipip.
A
Yeah
right
so
I
mean
like
most
of
the
eips
would
be
under
the
process
of
either
standardization
or
maybe
for
the
network
upgrade
I'm
not
sure.
If
any
of
the
eap
editor
would
like
to
volunteer
to
handle
that
twitter
account
separately.
Or
is
it
something
that
anyone
from
the
group
is
interested
to
do
that.
A
B
A
B
B
B
A
Right
cool,
so
we
can
take.
We
can
like
note
it
down
as
an
action
item
for
us
today
like
we
would
be
creating
a
twitter
account
for
tweeting
about
eip
status,
update
and
the
categories
the
hardware
coordinator
and
likeline
matt,
all
of
them
all
of
us
will
be
working
together
to
start
tweeting
about
it.
A
A
Moving
on
the
next
part,
was
a
network
upgrade
process
process
flow,
see
the
process
that
we
have
been
discussing.
I
have
tried
to
document
it
in
I
another
james.
Try
to
you
know,
work
together
and
document
it
in
a
proposal,
but
the
confusion
part
was:
should
this
proposal
be
a
part
of
eip
or
not
itself
in
itself,
like?
I
had
some
comments
there
going
by
the
current
process.
A
Right
about
that,
I
I
I
mean
if
people
are
comfortable,
I'm
going
to
put
that
as
a
specific
agenda
item
in
the
next
meeting
about
should
the
meta
and
information
eip
not
part
of
the
ap
at
all,
because
they
are
clearly
defined,
they
are
process
and
that
is
process
around
the
ethereum.
But
that
is
not
bringing
any
change
to
the
network
itself.
A
So
I
find
that
if
people
are
looking
for
only
technical
specification,
we
have
a
special
category
of
that
standard
track
eip.
So
we
can
look
into
that
and
I
was
also
looking
into
the
numbers
of
informational
and
meta
eep.
So
far.
I
think
we
have
like
very
few
under
10
for
information
as
well
as
for
meta
for
meta.
So
far
we
have
only.
A
Now
we
are
separating
the
process
of
standardization
as
well
as
for
networks,
so
I'm
proposing
to
have
another
meta
one
there.
Another
meta
er
proposal
for
documenting
the
process.
I
don't
think
it's
a
like.
You
know
creating
a
lot
of
confusion
because
for
technical
specification
we
have
a
clear
category.
B
So,
from
the
from
the
context
of
metas,
have
a
clear
category
and
technical
specifications
have
their
own
clear
category.
There
is
like
that.
Those
buckets
exist
within
eips
make
sense.
What
I'd
like
to
avoid
is.
If
we
have
the
process
for
network
upgrade
processes
being
within
an
eip,
then
we
once
again
have
eip
editors
in
the
politics
of
what
goes
into
the
upgrade
process.
A
I'm
not
so
sure
of
that,
because
if
we
look
into
the
process
it
just
tells
okay,
fine,
the
reason
behind
having
it
in
a
in
an
eip
in
the
first
place.
My
argument
was:
whenever
we
change
the
process,
we
don't
want
to
go
back
and
change
the
eip1
every
time.
It's
just
changing
one
eip
say,
for
example,
yeah.
B
A
Yes,
of
course,
so
the
point
was
like
when
we,
when
we
are
trying
to
reach
to
the
eat,
one
spec
repo
and
they
the
readme
file
there.
That
is
limited
to
this
particular
repository
only,
but
when
we
put
something
on
the
you
know,
eip
depot
I
mean
like
eips.ethereum.org,
then
it
is
accessible
to
everybody,
but
I
do
not
want
you
know
to
have
super
strong
opinion
on
it,
but
yeah.
If.
B
But
remove
these
stuff,
the
eip
specific
formatting
and
information,
and
just
put
it
there
and
and
make
it
so
it
it
fits
in
the
in
its
own
file.
Underneath
network
upgrade
specification
as
far
as
formatting
and
fitting
and
everything.
If
the
concern
is,
how
do
we
make
this
visible
because
there
isn't
a
website
that
shows
the
information,
then
we
should
figure
that
out
separately
and
not
not
use
that
it's
convenient,
that
eips
are
shown
on
eips.org,
so
we
could
plug
into
that
system
by
having
the
network
upgrade
system
use.
B
If
someone
goes
to
an
eip
and
then
reads
about
the
network
upgrade
process,
they're
you're,
they're
they're,
once
they're
getting
tied
like
the
the
worlds,
are
once
again
coming
together
into
one
place,
because
edits
to
the
process
become
an
edit
to
an
eip,
which
then
becomes
an
edit
in
the
eip
repo,
which
then
becomes
the
domain
of
eip
editors
and
then
also
the
people
that
are
there
working
on
it.
And
that's
the
this
one.
B
A
A
B
A
B
A
There
was
one
concern
which
I
think
should
be
brought
into
the
consideration
for
eip
additives.
It
was
about
the
eip
status,
like
the
network.
Upgrade
process
is
divided
into
three
phases
and
I
was
looking
into
eip
statuses.
What
I
have
seen
historically
is
even
if
an
eip
is
deployed
on
the
main
net,
the
status
does
not
change
to
change
from
draft
to
any
other.
Sometimes
it
happens.
So
I
was
looking
to
enforce
that.
You
know.
C
A
C
3
000
drafts,
and
you
know
10
final
eips
or
whatever
it
is
yeah.
I
don't
know
how
to
solve
this,
but
it
would
be
great
if
we
could
at
least
get
the
core
developers
to
not
implement
or
not
put
things
on
the
main
net
until
they're
final,
especially
with
this
new
process
like
an
eip,
should
be
final
before
it
touches
maintenance,
in
my
opinion,
like
or
rather,
maintenance
should
not
be
putting
non-final
standards
onto
maintenance.
I
think
it's
a
better
way
to
put
it.
A
Right,
so
that
is
what
I
wanted
to
specify
here
like
when
we
are
changing
the
I
mean
the
category
of
efi.
Sorry
cfi,
like
see.
If
I
applied
cfi,
approved
ci
devnet
waiting
room
whenever
we
are
changing
the
statuses
changing
the
bucket
for
any
of
the
proposal.
We
should
also
consider
the
status
at
that
point,
meaning
whenever
a
proposal
is
getting
in
the
bucket
of
cfi
applied,
they
can
be
in
draft
status
and
when
it
changes
from
cfi
applied
to
approved
the
status
must
be
between
review
to
final
okay.
B
C
Ideally,
we
can
work
with
the
core
devs,
since
that's
a
relatively
small
group
of
people,
and
we
can
hopefully
convince
them
that
this
is
for
the
betterment
of
the
ecosystem
as
a
whole.
If
they
would
stop
putting
drafts
onto
me,
that's
I
mean
really.
All
it
takes
is
just
someone
sitting
down
saying
you
know
submitting
a
pr
that
moves
it
to
final
or
last
call
and
final,
like
the
champion,
just
needs
to
do
those
extra
steps.
C
I
think,
for
for
most
cases
it's
just
a
matter
of
no
one
is
doing
those
steps,
so
my
hope
would
be
that
we
can
just
simply
talk
to
the
core
devs
and
convince
them
that
hey.
It
would
really
help
everything
if
you
guys
would
set
a
good
example
here
and
when
you're
ready
to
put
something
on
the
main
net
you
know.
Take
those
steps
have
whoever
the
champion
is.
You
know,
do
the
three
things
they
need
to
do
in
order
to
get
it
onto
mainnet.
C
A
A
A
B
Yeah
and
that,
and
that's
what
I
mean
I,
it
should
be
the
I
like
that
it
exists
as
a
rule,
but
I
think
the
enforcement
shouldn't
exist
on
the
eip
editors
or
even
defined
in
the
eip
side.
It
should
be
in
the
the
specifications
for
the
repo
for
the
repo
and
up
to
the
authors
and
the
people
like
me
to
make
sure
that
that
it's
enforced.
B
But
it
would
put
the
hands
of
the
decision
into
the
eip
editor's
hands
and
the
eipip
meeting
people
or
in
in
general.
The
eip
stuff,
like
the
decision
is
no
long,
is,
is
on
the
other
side
of
the
fence,
and
we
want
to
make
sure
that
that
decision
is
on
the
network,
upgrade
side
of
the
fence
and
it
stays
over
there
and
so
far,
because
it's
just
me
and
then
the
core
devs.
B
B
Yeah
it
can,
it
can
be
documented
in
the
network
upgrade
stuff,
and
then
I
really
just
want
to
be
very,
very
careful
about
stuff
about.
When
we,
when
we,
when
we
decide
that
something
should
be
done,
we
should
also
decide
who
is
it
that
enforces
the
who
is
it
that
enforces
those
decisions
and
does
it
and
does
it
fit
with
the
paradigm
that
we're
moving
forward
with.
A
A
middleware
here
I
mean
it's,
it's
again,
a
suggestion
like
for
network
upgrade
process,
most
of
the
time
cat
headers
are
helping
with
some
of
the
other
activities
reaching
out
to
author
for
some
or
the
other
task,
so
if
it
is
appropriate
and
if
it
can
be
considered
under
the
boundaries
of
cad
herders,
we
can
certainly
reach
out
to
the
authors
requesting
to
change
the
status
citing
this
document
that
this
is
the
new
process.
We
are
trying
to
follow
the
process
and,
according
to
this
process,
you
are
supposed
to
do
that.
A
A
Okay,
so
I'll
be
happy
to
reach
out
to
the
proposal
and
the
eip
authors,
which
is
considered
for
this
particular
upgrade
and
we'll
let
them
know,
but
before
that
we
have
to
have
it
documented.
In
apple,
I
mean
in
in
the
network
upgrade
repository
or
somewhere
else,
wherever.
How
can
your
repository
it's
fine?
A
D
C
C
A
B
I
mean
I
don't
know
we
certainly
so
at
some
point.
We
probably
need
it
today.
I
don't
think
we
need
it.
I
don't
there
even
the
eip,
you
mentioned,
we
had
kind
of
talked.
We
talked
a
bit
about
this
last
week
that,
like
the
the
philosophy
I've
had
when
designing
the
system,
is
that
sure
there
are?
There
are
many
more
things
to
be
added
or
things
that
could
be
added,
but
I
don't
I
want
to
add
them
as
they
come
up.
B
If,
in
the
beginning
I
sat
down
and
wrote
out
a
network
upgrade
process,
it
wouldn't
be
what
this
is
today.
It
would
have
been
something
else,
based
on
my
imagination
of
how
things
should
go
based
on
who
knows
what,
because
there
isn't
anything
really
to
to
big
back
off
so
the
at
some
point.
There
will
be
a
a
need
to
have
a
rejection
bucket,
but
I
would
not
want
to
define
what
it
is
or
how
it
gets
there
until
we
have
an
eip
that
needs
to
have
it
happen.
A
B
And
the,
and
that-
and
the
eip
you
mentioned
it
got
it
is
waiting.
It
is
technically
quote:
unquote,
isn't
necessary
is
superseded
by
another
one
going
into
mainnet,
because
if
that
goes
in
then
we
don't
need
to
have
that
one.
But
at
this
state
the
the
eip
that
would
supersede
it
also
isn't
in
mainnet,
so
it
hasn't
kicked
the
other
one
out
of
the
process
because
technically
at
this
point
the
other
one
could
not
that
we
could.
B
We
could
switch
our
decision
and
have
it
so
the
one
that's
waiting
back
at
20
89,
I
don't
remember
the
numbers,
but
the
gas
change,
the
gas
change
cost
for
that
eip.
We
could
change
our
mind
and
do
that
one
instead
and
then
the
other
one
would
be
rejected
or
whatever
it
happens.
So
so
because
there
hasn't
been
a
decision
that
kicks
it
out.
I
don't
think
we
should
build
the
process
for
kicking
it
out.
Yet
it's
fine
just
to
sit
in
the
waiting
room
or
as
efi.
A
F
A
C
Yeah,
so
we
have,
we
encourage
people
to
use
either
github
issues
or
ethereum
magicians,
one
for
discussion,
two
links
on
erps.
The
question
is
just:
should
those
remain
open
and
active
forever
with
ethereum
magicians
doesn't
really
matter
too
much.
They
kind
of
just
disappear
over
time,
just
how
forums
work
with
github
issues,
though
we
have
a
ever
growing
list
of
open
issues
that
doesn't
really
hurt
anything
per
se
just
means
the
search
results,
become
harder
and
harder
to
get
useful
results.
C
Out
of
someone
came
along
and
said:
oh,
the
cip
is
final,
so
it
makes
sense
to
close
the
discussion
link
and
that
got
me
thinking.
Historically,
we
have
not
done
that,
and
so
I
reopened
the
issue
just
because
that
is
not
our
general
process,
but
it
did
get
me
thinking.
Is
that
a
good
process
should
we
do
that?
Should
we
like?
Does
it
make
sense
to
continue
discussion
on
an
eip?
That's
already
been
marked
as
final
and
the
author
is
now
long
gone.
C
A
B
A
A
That
was,
you
know,
created,
but
I
think
like
if
people
have
done
it
like,
if
a
pr
is
open
for
very
long
time,
the
eap
is
in
process
for
very
long
time
understand
the
issue
of
having
it
a
discussion,
two
section
in
the
issue,
but
from
here
on,
we
should
try
encourage
people
to
get
it
in
at
magician,
and
I
think
it's
it
totally
makes
sense
that
we
should
close
it.
We
want
to
have
least
number
of
open
issues
so
that
it
can
be
addressed
and
finally
closed.
B
B
But
I
was
going
to
say
I
I
agree
closing
it
makes
sense
like
letting
letting
them
close
the
issue
and
then,
as
long
as
it's
findable
still
by
the
link
and
the
content
isn't
gone,
then
it
can
be
reopened.
If
whatever
happens,
okay-
and
I
I
I
feel
less
about-
I
feel
less
strongly
about
enforcing
it
being
on
either
one.
I
think
it
should
be
up
to
authors,
but
closing
it
makes
sense.
C
I
think
I
think
the
context
for
why
we
still
allow
people
to
do
github
issues
is
because
these
magicians
does
require
a
second
account,
and
we
want
to
enable
people
to
only
need
a
github
account
to
participate
in
the
iep
process
and
not
have
to
go
create
accounts
everywhere,
especially
since
you
know
these
magicians,
I
think,
requires
an
email
address.
I
don't
know
if
github
does
or
not,
but
if
you're
trying
to
remain
anonymous,
which
we
want
to
encourage
it's
easier,
the
fewer
accounts
you
have
to
go
create
at
random
places.
A
C
B
C
B
A
C
So
the
situation
is
the
ip
numbers.
Are
people
know
how
the
editors
choose
numbers
technically,
the
editor
choose
whatever
that
number
they
want.
They
sign
it,
but
people
have
figured
out
our
secret
formula,
which
is
to
just
use
the
pr
number,
and
so
when
they
want
to
have
a
particularly
cool
number
like
3000
or
2000
or
1337
or
777
or
whatever
it
is.
C
They
have
learned
to
do
one
of
two
things:
either
just
set
up
a
bot
or
something
and
wait
for
an
eip
number
to
be
next
and
then
immediately
go
create
an
eip
or
worse.
They
come
in
and
just
create
a
bunch
of
trash
issues
just
to
force
the
number
up
until
it
gets
to
the
one
they
want,
and
then
they
squat
on
that
one.
C
The
I
think
in
the
past,
we
have
kind
of
tentatively
tried
to
frown
on
this,
but
we
haven't
actively
done
anything
to
stop
it.
This.
The
question
here
is:
we
have
a
situation
where
someone
is
doing
exactly
this.
They
you
know,
saw
that
3000
was
coming
up
and
they
waited
until
2999
was
used
and
then
a
few
minutes
later
they
created
an
eip,
which
of
course
got
them
three
thousand,
but
or
at
least
they
got
their
pr
number
was
three
thousand.
C
A
I
think
this
is
something
that
most
of
the
editors
can
answer,
but
if
I
have
to
go
by
my
personal
opinion,
since
we
have
not
done
that
in
past,
we
could
let
it
go
for
one
time
making
it.
You
know
as
a
note
and
then
highlighting
this
issue
to
be
in
future.
To
be,
you
know,
lesson
learned
kind
of
stuff,
and
if
something
is
there,
we
are
going
to
be
more
strict
about
it.
But
that's
my
personal
and
I'm
not
edited.
C
I
believe
there
was
one
situation
in
the
past
where
we
actually
didn't
allow
the
squatting
in
this
particular
situation
for
mercury.
It
was
a
while
ago
someone
was
actually
like
creating
a
bunch
of
issues
to
bump
the
number
up,
and
then
we
closed
their
pr
on
them
once
they
got
the
number
they
wanted.
We
said:
no.
That
was
a
little
more
aggressive
this
this
time
around,
it's
a
little
more
passive,
and
so
I
don't
know
if
it
won't
be
as
harsh
now
we
do
have.
C
C
C
And
it
was
tpd
on
every
section,
they
had
had
a
title.
I
think,
and
that
was
it.
If
I
remember
correctly,
I
don't
know
if
they
might
have
updated
it
by
now,
but
at
least
I'll
check,
but
at
the
time
they
had
a
title
and
the
front
matter,
and
that
was
it
like
they
had.
They
had
no
content
yet
and
they're
like
oh,
we
have
a
plan.
A
C
B
B
D
It's
like
it
looks
like
they've
got
a
project
with
some
code
and
contracts
and
a
reference
implementation,
so
it
looks
like
they're
progressing
towards
like
writing
it.
As
a
spec,
I
mean
my
feeling
is
that
the
editor
should
come
in
and
say
hey.
We
have
complete
control
over
the
numbers,
and
so
you
did
this,
but
that
doesn't
necessarily
mean
the
future.
People
are
going
to
get
this,
but
I
mean
this
is
this
is
aragon?
This
isn't
like
some
random.
D
D
A
C
C
So
I
don't
think
they
were
doing
the
malicious
bumping.
And
so
maybe
it
sounds
like
the
general
feeling.
Is
that
if
we
believe,
if
you
are
causing
problems
like
generating
garbage
prs
or
issues,
then
we
will
stop
you
if
you,
on
the
other
hand,
just
wait
and
you
you
know,
fight
with
other
people
for
that
number
and
you
win,
then
will
you
have
it?
Does
that
sound
great.
C
D
D
A
A
And
it
would
be
helpful
for
us
to.
You
know
cite
some
example.
If
we
are
talking
to
somebody
it's
a
martyr,
it
would
be
helpful
for
us
to
cite
some
example
mentioning
that
this
is
something
not
acceptable
if
such
scenario
comes
in
future,
but
definitely
this
is
under
the
purview
of
editors,
so
I'm
not
sure
if
that
can
be
a
policy
just
for
reference
point,
I
was
mentioning.
C
B
Yes,
if
they
didn't
looks
like
that
and
with
if
they
didn't
within
a
couple
couple
days,
start
doing
something
with
it,
then
it's
then
it
then
it
was
a
oh.
We
just
place
hold
it
to
come
back
to
in
like
a
in
four
weeks
or
something
then
that's
also
kind
of
an
appropriate
time
to
tell
them.
Sorry,
you
don't
get
that
number
you're
you.
You
clearly
waited
six
weeks
two
years.
C
D
B
D
I
mean
they
have
done
quite
a
bit
of
work
like
they've
registered
all
these
sites
around
this
eep
number
and
they've
already
come
up
with
some
implementation
of
their
ep,
so
I
think
they
just
need
to.
If
that's
the
minimum,
we
should
let
them
know,
because
I
think
they'll
do
it.
They
have
all
this
information
they're,
like
obviously
continue
to
progress
on
it.
It's
not
a
case
where
somebody
decided
they
want
e3
000
and
they
just
like
fall
off
the
map.
B
Then
they
didn't
have
content
when
they
he
when
they
made
they
when
they
made
the
like
the
the
the
ideal
case.
Is
someone
sits
down?
They
write.
Some
stuff
doesn't
need
to
be
everything,
but
they
at
least
have
some
of
the
basic
things,
and
then
they
hit
submit
an
issue
and
then
boom
they
hit.
They
make
a
pr.
The
pr
gives
them
an
issue
and
then
that's
their
number.