►
A
B
A
C
Yeah
absolutely
hi,
my
name
is
margaret.
I
am
on
github's
policy
team
and
we've
been
doing
some
work
with
npm
on
securing
registries
and
also
collaborate
a
lot
with
miles
and
trevor,
which
I
think
you
guys
are
familiar
with.
So
we
are
going
to
present
and
share
our
thoughts
and
get
feedback
from
you
guys.
D
A
A
Here,
aside
from
margaret
and
justin,
I
was
hoping
to
for
miles
or
someone
to
be
able
to
give
us
like
a
kind
of
recap
of
the
announcement
on
npm
and
six
star
integration,
but
if
they're
not
here,
maybe
we
won't
get
that,
but
I
did
want
to
make
everyone
aware
that
that
blog
post
was
made
and
there's
an
rfc
now
with
lots
and
lots
of
comments
on
it.
I
think
you
know
this.
This
proposal
aligns
pretty
well
with
what
some
of
the
other
repositories
have
already
proposed,
or
what
planning
to
propose.
E
E
More
that,
like
there
would
be
sort
of
stuff
you
do
at
a
command
line
as
a
developer.
You've
got
your
npm
tool
and
you
say
I
want
to
sign
this
thing
versus
I'm
using
an
existing
ci
provider
to
sign
on
my
behalf
right,
I'm,
you
know
trusting
not
so
much
with
the
cli,
where
you
trust
the
oidc
provider
id
provider
to
to
say
you
know
this
person
is
all
authenticated
by
google
or
github
or
microsoft
as
they
are
now
versus.
E
This
build
is
authenticated.
This
signature
is
authenticated
by
a
build
process
managed
by
github
or
gitlab
or
circleci.
What
have
you-
and
I
did
not
pick
up
that
distinction
at
first,
but
it's
it's
interesting
that
they
have
included
the
rfc
as
a
compare
and
contrast
with
rubygems.
We
spent
a
lot
of
our
time
scratching
our
heads
about
the
ci
case,
because
it
is
a
valid
one,
but
we
also
hunted
it
to
a
future
feature
rfc
and
focused
purely
on
the
cli.
F
Haven't
had
a
chance
to
think
I've
been,
I
haven't
been
able
to
dig
into
that,
but
that
sounds
interesting,
because
the
the
human
versus
the
machine
is
one
of
the
things
that
I
know
we
have
to
contend
with
on
the
maven
side,
because
we're
we're
the
last
mile
of
so
many
so
many
places
build
systems
right.
So
I'm
interested
to
see
if
there's
a
proposal
in
there
how
they're
tackling
that.
B
B
So
typically,
what
happens
proposal
goes
to
tac,
and
then
you
know
if
the
governing
board
is
already
approved
of
the
of
the
category
which
happens
for
some
areas,
smaller
tasks,
then
off
you
go
otherwise
it
goes
up
the
governing
board,
for
you
know,
thumbs
up
thumbs
down.
Okay,
so,
hopefully
kind
of
help
the
where
things
go
in
the
little
process.
There
thanks.
F
I
was
just
gonna
add
this:
one
is
still
waiting
for
the
governing
board.
Approval
attack
basically
agreed
to
send
it.
I
think,
there's
still
not.
I
think
I
know,
there's
still
some
work
going
on
to
kind
of
decide
between
the
the
gb
and
attack
you
know.
Is
there
a
certain
level
below
which
it's
delegated
directly
to
attack?
That's
an
active
conversation,
but
this
proposal
was
was
specific
enough.
It
had
a
vendor
and
all
of
these
types
of
things
right.
So
it's
it's.
F
F
You
know
we,
we
have
this
thing
and
we're
gonna
achieve
the
following
milestones,
and-
and
we
have
somebody
on
the
hook
for
this
proposal
to
go,
do
it,
but
there
there
is
discretionary
money
available.
I
don't
remember
off
top
my
head,
but
I
think
yeah.
Your
point
is
a
good
one
to
remind
everybody
that
this
thing
exists,
and
so
we
might
be
able
to
use
it
if
we,
if
we
want
to.
E
A
A
G
Nothing
too
long.
I
think
I
found
an
email
just
a
few
minutes
ago
with
a
link
to
the
glossary,
if
you
know
you're
in
a
different
ecosystem,
if
you
take
a
look
at
it,
fill
in
fill
in
what
you
can
even
a
sentence
or
saying
I
don't
know
what
this
is
or
we
don't
use
this
word
or
whatever
would
be
super
helpful.
G
I
think
if
I
don't
get
much
more
traction
on
it
by
the
next
time
we
meet,
I
might
just
invoke
what
cunningham's
law
and,
like
just
fill
it
in
the
way.
I
think
it
is
in
those
ecosystems-
and
you
tell
me
if
I'm
wrong
but
yeah.
If
you
have
any
any
time
you
can
spend
on
it
and
films
and
things
will
be
really
helpful.
A
A
A
C
C
C
We
follow
the
santa
clara
principles
and
are
kind
of
engaged
in
these
sort
of
you
know,
content
moderation,
type
discussions
and
so
key
principles
of
that
is
putting
developers
at
the
center
of
moderating
their
own
projects,
fair,
empathetic
and
transparent
moderation
and
optimizing
for
code
collaboration
and
we've
worked
on
this.
For,
like
you
know
a
long
time,
and
I
guess
that
the
question
is
what
is
the
developer
first
ethos
for
package
ecosystem?
C
D
C
C
And
so
yeah,
so
I
think,
like
you're
thinking
about
a
platform
like
github
is
very
different
than
a
package
registry
and
they
have
unique
features
and
concerns,
and
so
thinking
about
developing
governance
principles
for
a
registry.
What
what
does
like
align
and
what
needs
to
be.
You
know
unique
and
considered
for
this
type
of
ecosystem.
D
Yeah
I
mean
in
particular,
I
think
the
big
distinction
right
is
like
github.
You
know
when
you're
doing
code
collaboration
there,
it
really
is
kind
of
code
at
rest
right
where
you
know
you
know
it
can't
be
activated
with
a
push
of
a
button
and
there's
this
you
know
there's
this
there's
this
principle
and
law
that
I
always
come
back
to
which,
which
actually
kind
of
draws
an
interesting
line
here
between
registries
and
kind
of
you
know.
The
source
code
itself
is
that
you
know
first
amendment
like
like
free
speech
in
the
united
states.
D
D
You
know
situation
where
you
press
a
button.
The
idea
is
that
you
don't
necessarily
want
to
change
the
package
coming
in.
In
fact,
like
you
want
that
kind
of
stable
runtime
environment
for
the
code
that
you're
writing
provided
to
you
by
the
package
registry,
which
is
different
than
on
github,
where
you're
actually
trying
to
kind
of
improve
the
code
itself
and
understand
what
it
does.
C
Yeah,
and
so
with
that,
I
think
that
the
unique
element
means
that
there
are,
you
know,
unique
roles
and
unique
issues
that
come
to
package
registries,
and
so
we
identified
these
two
as
like
kind
of
key
governance
questions.
So
what
is
the
role
of
registries
when
it
comes
to
publishing
malware
on
registry
or
known
security
vulnerabilities?
When
does
the
registry
get
involved
and
when
is
it
the
responsibility
of
the
maintainer,
and
when
does
it
not
fall
to
the
registry
or
the
maintainer
to
intervene.
D
D
D
You
know
safe
place
to
to
to
build
code
on
dava
right
maintainers.
You
know
they
have.
They
have
a
little
bit
of
a
you
know:
they're
often
users
as
well,
but
they're
also
thinking
you
know
that
they,
their
their
real
kind
of
sweat,
has
been
put
into
maintaining
that
package
over
time
and
what
they're,
really
you
know
thinking
about?
Is
you
know
this
is
this?
Is
my
package
I'm
expressing
myself
in
various
ways?
I'm
supporting
you
know
doing
my
part
to
uphold.
D
You
know
this
great
ecosystem.
That's
that's
in
here
by
maintaining
one
or
more
packages-
and
you
know
you
know
my
my
voice
matters
in
this
ecosystem
and
in
this
community
as
well,
and
so
packages
can
be
a
way
of
expressing
yourself
and
and
kind
of
participating
in
that
in
that
system,
and
we
want
to
give
them
kind
of
free
reign
for
how
to
you
know,
govern
their
projects
and
bring
it
in
various
various
ways.
D
And
then,
finally
there's
you
know
the
registry,
and
what
the
registry
is
trying
to
do
is
make
sure
that
you
know
maintainers
have
a
you
know
great,
tooling
and
good
place
to
develop
and
put
stuff
on
their
registry
and
that
users
are
well
supported
in
that
ecosystem,
and
so
we
need
to.
We
need
to
think
about.
D
You
know
balancing
these
three
interests
at
any
point
when
we're
when
we're
developing
principles
for
like
how
are
we
going
to
handle
incidents
on
the
on
the
registry
and
when's
the
right
time
to
to
take
something
down?
If
you
take
something
down,
you
know
too
quickly,
you're
breaking
a
lot
of
users
or
upsetting
a
lot
of
maintainers,
and
so
you
need
to
do
it
in
a
really
principled
fashion,
so
that
you
know
people's
builds,
aren't
broken.
D
C
Awesome
and
so
going
into
that
we've
kind
of
thought
about
and
and
talked
to,
npm
and
nuget.
To
start-
and
you
know
you
guys-
are
the
the
next
step
of
you-
know
getting
feedback
on
this,
but
trying
to
think
about
these
different
issues
of
governance,
moderation,
different
incentives
and
goals,
and
then
it's
kind
of
congeal
them
into
five
sort
of
draft
principles
for
package
registries.
C
C
D
Yeah-
and
I
I
mean-
I
think
it's
important-
to
recognize
the
draft
nature
but
b,
you
know
having
having
consensus
around
the
from
the
registries
on
this,
I
think,
would
be
really
helpful,
consensus
and
input
from
both
users
and
maintainers
an
opportunity
for
input
from
both
users
and
maintainers.
If
we
kind
of
like
widen
this
out,
and
the
reason
for
that
is
that
I
think
we
should
all
like,
like
the
whole
ecosystem
has,
you
know,
concerns
around
this
right.
The
whole
ecosystem
wants
security.
D
The
whole
ecosystem
wants
to
express
that
the
whole
ecosystem
wants
to.
You
know,
make
make
itself
better,
and
so
you
know
recognizing
that
and
staying
this
up.
The
other
thing
I
want
to
say
about
you
know
these
these
principles,
I'd
think
of
them
as
kind
of
guide
posts.
One
of
my
one
of
my
law,
professors
in
law
school,
said
everything
in
law
comes
down
to
two
different
tests:
there's
either
a
bright
line
rule
or
a
musty
standard.
Brightline
rules
are
easy
and
great
and
awesome
to
do.
D
If
you
try
to
have
a
like
only
bright
line
rules
in
this
space,
I
think
you're
going
to
run
into
problems
very
quickly
because
there's
always
going
to
be
a
kind
of
what
about
new
edge
case
and
so
having
these
is
kind
of
guide
posts.
Or
you
know
these
are
the
factors
we
consider
when
we
make
a
decision,
I
think,
is
important,
so
some
of
them
might
be
conflicting
or
protect,
potentially
overlapping.
C
Yeah
and
we
can
get
into
the
actual
text,
but
I
should
just
say
you
know
this
is
again
very
much
draft,
but
we're
trying
to
think
about.
You
know
you
guys
all
work
on
like
the
front
lines
with
this.
So
how
do
you
think
these
can
actually
be
operationalized,
they're
mushy,
but
what
do
they
mean
in
in
real
life
and
so
kind
of
keeping
an
idea
when
we
pass
them
on
for
your
feedback?
C
C
Okay,
now,
I'm
clicking
so
the
first
one
is
trust
comes
first
and
this
one
is
really
trying
to
get
at
the
expectations
of
the
ecosystem
that
the
ecosystem
should
be
consistent,
reliable
and
then,
with
that
we
have
that
the
ecosystem
should
be
able
to
provide
resources
that
enable
developers
make
informed
decisions
about
dependencies
and
also
avoid
breaking
developer
workflows
whenever
possible.
So
those
are
the
kind
of
the
general
ones
with
trust
that
the
code
is
going
to
work
and
people
can
generally
understand
what
they're
getting
into
when
they
use
it.
C
But
I
think
that,
while
this
is
relatively
vague,
you
can
definitely
see
how
this
would
be
operationalized,
and
we
could
talk
about.
The
issues
of
you
know
are
all
package
registries
able
to
provide
these.
You
know
different
options
for
appeal
and
what
are
the
you
know,
issues
with
that?
Let's
go
to
the
third
one.
D
And
so
you
know
with
this
one
I
think
there's
kind
of
like
a
bright
line,
a
bright
line
almost
test
here
right,
which
is
that
you
know
when,
when,
when
you're,
detecting
kind
of
active
malware
and
like
you
know,
what's
the
line
between
malware,
I
mean
maybe
there's
not
a
bright
line.
But
what's
the
line
between
like
malware
and
a
bug
is
an
important
kind
of
question?
I
think
you
know
there's
an
intent
issue
there
that
you
might
need
to
consider,
but
you
know
like
having
a
zero
tolerance
policy.
D
For
you
know,
malware,
I
think
is,
is
I
think,
probably
in
everybody's
best
interest,
both
users
and
other
maintainers
right,
where
the
idea
is
that
you
want
to
ensure
that
stable,
reliable
base
that
people
can
build
on
top
of,
and
if
people
are
actively,
you
know
trying
to
break
that.
It
compromises
the
trust
across
the
entire
ecosystem.
So
there
should
be
proactive
measures
by
the
by
the
platform
against
that
and
give
tools
to
identify
the
situation
where
that,
where
that
occurs,.
C
B
Yeah
so
give
developer
the
tools.
I
mean,
I'm
not
a
first
of
all.
I
agree
mal
or
bad.
I'm
library,
oh
hope.
We
can
all
agree
on
that.
Yeah.
I'm
sure
there's
some
some
nuance
there,
but
on
that
last
bullet
give
developer
the
tools
I'd
like
to
go
a
little
further,
because
I
mean
developers
already
have
tools.
I
really
want
to
make
it
so
that
developers
get
a
lot
of
information
get
a
lot
by
default.
B
In
other
words,
if
you
start
in
you,
add
a
package
and
it
has
a
known
vulnerability,
I
don't
want
to
be
possible
for
a
developer
to
find
out.
I
want
it
to
be
pretty
obvious
if
the
developer
doesn't
have
to
do
anything
extra
to
the
extent
that
we
can
enable
it.
You
know
secure
by
default
and
trying
to
make
it
so
they
don't
have
to
go
out
of
their
way
to
find
out
information.
C
C
E
E
B
D
What
I
love
about
this
is
exactly
the
kind
of
like
guidepost
problem
right.
Consistency
and
reliability
are
are
paramount,
but
so
is
you
know,
but
and
breaking
builds
kind
of
interferes
with
that,
but
then
there's
also
the
the
fact
that
you
know
that
that
breaking
builds
increases
security.
I
see
another
hand.
H
B
D
Yeah
and
may,
and-
and
you
know,
I
think
that
this
this
last
bullet,
which
you
know,
is
kind
of
operationalized
in
the
in
the
in,
like
a
text
document
that
we'll
share
out
also,
you
know,
maybe
we
want
to
make
that
stronger
and
if
there,
if
there
is
a
commitment
by
all
the
you
know
all
the
registries
here,
you
know
which
are
which
are
the
major
ones
to
do
that
and
and
and
want
to
make
that
commitment.
That
would
be
an
interesting.
D
You
know
something
that
comes
out
of
this
I
mean
the
goal
here
is
for,
for
everybody
to
kind
of
you
know,
agree
on
those
principles
get
user
input.
I
mean
you
know,
users
want
that,
you
know,
and
and
and
maintainers
want
that
that's
another
step
in
in
the
right
direction
and
giving
people
the
opportunity
to
comment
around
that,
I
think
would
be,
would
be
really
interesting
and
a
good
way
to
have
that
conversation.
Perhaps.
D
And
then
so
so
this
is
really
kind
of
you
know
putting
the
the
you
know
putting
the
maintainer
hat
on
a
little
bit
more
right,
which
is
you
know
the
registry
shouldn't
be
in
the
business
of
you
know
the
day-to-day
package
maintenance
issues
across
their
entire
ecosystem.
If
they
are,
then
that
I
think
is,
would
be
considered
by
a
lot
of
maintainers
it'd
be
a
little
bit
of
overreach.
So
you
know
you
could
imagine
some
kind
of
like
obscure
bug.
D
Man
package
maintainer
and
apply
your
measures
like
thoughtfully
and
carefully.
So
that
you're
not
kind
of
overstepping,
you
know
where
that
is,
and
as
I've
said
before,
there
is
kind
of
this
intent
issue
there
right,
which
is
like
what
is
a
security
vulnerability
bug
on
the
maintainer
such
that
you
want
to
kind
of
like
de-list,
their
or
or
that
the
rise
level
of
delisting
their
package
or
something
right,
and
when
is
it
malware,
where
you
like
automatically
de-list
right
and
so
there's,
maybe
a
range
there
or
or
something
like
that.
D
B
In
many
ways
this
harkens
back
to
the
whole,
making
your
policies
clear
right.
So
you
know
npm
didn't
but
now
has
a
policy
of
after
a
certain
amount
of
time.
They
won't
delete
a
package
I
mean,
except
for
malware.
I
hear
left
pad
had
something
to
do
with
that.
So
so,
basically,
normally
maintainers
can
do
things,
but
if
there's
an
exception,
you
would
hope
that
that
would
be
a
clearly
explained
exception.
C
Yeah-
and
I
think
that
the
carefully
is
is
operative
there,
you
know
both
understanding
dependencies
and
you
know
the
possible
unintended
consequences
for
takedowns,
as
well
as
the
potential
risk
for
anything
all
right,
and
then
I
think
this
is
yeah.
This
is
our
last
one,
so
always
innovate
great
thing
to
say,
and
in
general
this
is,
I
would
say,
a
squishy
guide,
post
saying
that
things
are
constantly
changing
and
that
while
registry
should
take
advantage
of
existing
tools
but
also
update
best
practices,
and
that
also
includes
the
policies.
C
So
you
know
when
we
say
policies
should
be
continually
like
updating
that
includes
these
principles,
so
we
would
love
your
feedback
if
you
think
that
this
is
something
that
could
be
useful,
how
you
think
it
would
work
in
practice
we're
imagining
that
agreeing
on
these
principles
with
leaders
in
the
package,
regular
digital
street
ecosystem
would
allow
people
to
both
share
resources
and
strategies,
increase
trust
in
package
registry
moderation
decisions.
We
are,
you
know
affirming
these
principles
we're
committed
to
these
principles.
C
This
is
why
we
made
this
decision
and
there's
a
bit
of
a
guide
post,
that
you
can
refer
to
that's
outside
of
the
day-to-day
scram
and
then
having
shared
principles
for
responding
to
incidents.
So
you
know
you
don't
need
to
go
alone.
Everyone
can
share
this
and
potentially
would
make
it
easier
for
registries
to
have
moderate,
like
moderation,
decisions
that
aren't
necessarily
in
isolation.
They
can,
you
know,
build
off
of
each
other's
decisions.
D
B
Yeah,
so
you
earlier
talked
about
what's
the
goal
and
basically
trying
to
deal
with
malware
and
known
vulnerabilities,
if
you
it's,
I
think
it's
often
helpful
to
answer
the
question:
hey.
What
are
you
trying
to?
What
are
you
overall
trying
to
accomplish?
You
know
and
I
think,
countering
malware
countering
you
know.
B
Helping
people
counter
prevent
known
vulnerabilities
isn't
bad,
but
I
would
divide
up
the
malware
into
two
categories:
it's
the
intentional
from
the
actual
developer
and
it's
an
attacker
taking
over
an
account
and
the
re
and
the
reason
I
would
split
that
up
is
because
I
think,
there's
different
countermeasures
for
different
circles.
Obviously,
things
like
2fa
can
really
help
counter
the
account
takeovers
and
things,
and
then
some
things
like
that
and
some
of
the
other
issues
and
signatures
can
help
that
doesn't
help.
Obviously,
for
the
here
I
am.
B
B
D
It
that's
that
that's
a
prince,
that's
something
I
hadn't
thought
through
before
really,
and
I
wonder
if
you
know
if
these
principles
could
be
shaped
in
some
way
to
kind
of
you
know
to
kind
of
hit
that
right
where
it
it.
You
know
that,
like
we
kind
of
say,
like
you
know,
give
people
tools
for
for
securing
that.
Maybe
there's
something
around
around
that
kind
of
like
identity,
protection
that
we
that
you'd
want
to
put
in
in
the
maybe
the
empowerment
section
or
something
like
that.
E
You
know
you
just
see
it
as
an
imposition
with
with
nothing
for
you.
You
know
nothing's
in
it
for
you,
so
I
guess
what
I'm
trying
to
drive
at
is
that
another
way
of
slicing
through
this
is
what
does
the
registry
owe
the
maintainer?
What
does
the
registry
own
the
end
user
and,
in
particular,
when
those
interests
conflict?
E
D
And
that
we've
really,
I
think,
that's
why
the
trust
comes
first
is
is
first
right,
which
is
that,
like
the
stability
of
the
ecosystem,
is
really
what
what
what
matters,
and
I
think
that
you
know
you
need
to
take
all
three
of
those
things
into
consideration.
But
but,
as
you're
balancing
you
know,
like
stability
is
the
most
important
thing
both
for
you
know,
takedowns
and
for,
as
you
say,
maybe
putting
you
know,
guideposts
and
restrictions
on
on
maintains.
I
mean
one
one
other.
D
You
know
sometimes
that's
that's
not
there,
and,
and
I
understand
why
it's
not
because
it's
hard
to
to
do
at
scale
and
make
everybody
do
it,
and
you
know
you
want
more
packages,
and
so
you
want
to
you
know,
ease
things
up
in
maintainers,
but
you
know
not
knowing
that
has
license
implications.
Also,
has
security
implications
be
great
to
have
that
as
a
you
know,
another
thing
that
people
would
do,
but
you
don't
want
to
throw
too
much
burden
on
everybody.
Sorry,
dr
wheeler.
B
Yeah
I'm
wondering
if
there's
a
sixth
one
about
providing
information
necessary
to
make
good
decisions.
I
mean
you
could
argue
that
that's
part
of
that
transparent
policy,
but
I
think
it's
also
the
you
know:
it's
not
just
the
policies,
but
the
information
yeah.
So
I'm
wondering
so.
I
think
in
at
least
some
of
these
cases.
I
think
there's
trade-offs,
and
in
that
case
probably
there's
going
to
be
transparent
and
consistent
policies
is
going
to
be
key
for
I'll.
B
It
would
also
be
awesome
if,
if
you
know,
package
registries
repositories,
package
repositories
would
attempt
to
rebuild
the
package
to
see
if
they
can
reproduce
it
and
then
tell
developers
either.
Yes,
I
can
reproduce
it.
I
know
this
is
from
the
source
or
no,
I
can't
reproduce
it.
I
don't
know
if
this
is
from
that
source.
B
The
good
news
for
the
end
users
is
that
gives
them
more
information
to
work
with
the
bad
news.
Is
I'm
more
dependable.
The
bad
news
is,
that's
a
lot
to
ask,
and
you
know
pi
pi
might
be
able
to
do
that,
because
you
know
a
lot
of
people
care
about
python
and
you
have.
It
has
a
large
but
not
crazy,
large
number
of
packages.
I
don't
know
how
to
do
that
with
npm.
That
has
a
even
larger
number
of
packages
and
then
there's
like
the
common
list
package
registry.
B
D
Right
and
that's
and
that's,
and
that
kind
of,
like
different
differences
between
different
registries,
one
of
the
reasons
we're
trying
to
keep
you
this
super
high
level
right
like
like
broad
top
level
commitments
that
you'd
want
to
make.
You
know,
regardless
of
the
ecosystem,
regardless,
regardless
of
your
user
base
or
maintainer
base.
You
know
just
kind
of
thinking
about
those
things
more
in
the
abstract,
rather
than
you
know.
You
know
diving
down
and
saying
you
know,
we
will
make
sure
that
you
know
we
we
commit
to
the
top.
D
D
Yeah
we,
I
think
we
had
that
point
on.
I
I
forget
which
one
it
was.
Maybe
trust
comes
first,
but
there
was.
It
was
a
last
bullet
and
one
of
them
that
that's
you
know,
tools,
basically
and
and
committing
to
to
provide
so
secure
the
supply
chain
give
developers
tool
to
identify
vulnerabilities
in
their
stack,
and
I
think
there's
the
you
know.
I
think
there's
an
analog
to
that
which
is
for
a
lot
of
these.
You
know
questions
of
you
know.
D
Are
you
really
going
to
ask
the
maintainer
to
do
one
more
thing
right,
it's
kind
of
like
if
you
can
make
it
seamless
and
the
tools
easier
for
doing
it
or
you
know
like
automatic.
You
know
you
could
you
could
imagine
you
know
integration
with
github
or
git
labs,
or
you
know,
whatever
your
code
hosting
is
where
you
know
kind
of
auto
tags.
You
know
as
you
as
you
publish
up
or
something
should
be
a
really
nice
nice
feature
that
would,
you
know,
drive
some
of
that
behavior
that
you
want
with
it.
D
D
C
I'm
muted,
but
yeah
we'll
definitely
integrate
that.
I
think
that
we
can
tweak
the
existing
policies
to
incorporate
that
feedback.
Is
there
anything
else
on?
I
guess
any
of
the
the
past
five
that
anyone
thinks
that
we
might
want
to
rework
before
we
pass
them
on
to
you
for,
like
a
more
thorough
review
and
feedback
period.
D
Hearing
hearing
hearing
nothing,
maybe
the
right
thing
is
like
what
you
know:
what's
the
best
way
to
collaborate
would
be
the
kind
of
you
know
going
forward.
I
mean
this.
Is
you
know
the
feedback's
been
awesome
in
this
call,
but
you
know
it
might
be
nice
to
to
to
stand.
Maybe
stand
up
at
google
doc
to
share
these
slides
out.
You
know
which,
which
really
are
reflective
of
a
of
a
one-pager.
F
F
D
Yeah
exactly
I
mean,
I
think
the
the
end
goal
is
to
you
know.
Have
you
know
this
group
agree
or
this
group,
or
you
know
this
group,
the
group
of
package
managers
that
are
here
and
maybe
others
if
you
know
others
that
that
would
be
interested
in
participating
kind
of
agree
on
a
you
know
this
set
or
a
set
of
principles
right
like
get
a
document
together
and
then
I
think,
stand
it
up
somewhere
and
make
an
announcement
and
say:
hey.
D
You
know,
maintainers
users,
you
know
on
these
ecosystem
like
here,
are
the
principles
we're
thinking
about
adopting
for
how
we're
going
to
think
about.
You
know
you
know
dealing
with
this
stuff
moving
forward.
We'd
love,
you
know
open
up
for
comments.
What
should
these
principles
be?
And
then
you
know
close
it
down
at
some
point
and
and
everybody
sign
it
and
and
and
there.
F
Yeah
it
you
know,
it
reminds
me
I'll,
have
to
dig
this
up.
It
was
probably
five
or
six
years
ago
now
and-
and
you
know
our
nexus,
repo
team
started
drafting
a
thing
that
was
titled,
something
like
so
you
want
to
create
a
new
format
and,
like
you
know,
the
principles
rule
number
one
was
like.
Please
don't
there's
enough,
but
then,
if
you
really
need
to,
we
started
listing
things
that
not
quite
these
principles
but
principles
at
a
different
level.
C
C
F
B
B
For
so
that
you
know
more
care
as
as
it
starts
solidifying
we
can
make
more
careful
tracking,
but
the
google
doc
makes
it
easier
to
get
started,
but
it
sounds
like
the
goal
is
really
an
output
from
this
group.
Saying
hey.
We,
these
repositories
agree
on
these
principles
and
you
know,
obviously
somebody
else
doesn't
have
to
agree,
but
that
will,
I
think,
have
a
big
influence
on
everyone
on
any
other
registry.
D
Right
exactly
and
again
standing
up
for
public
comment
period.
You
know,
did
we
get
it
right?
I
think
it's
really
great
too,
because
then
you
know,
I
think
you
know
if,
when
moderation
decision
comes
down-
and
you
know
you
you're
doing
it-
you
know
reflecting
back
on
that.
You
know
this
is
this
is
kind
of
the
way
that
we're
balancing
this
this
trilogy
of
package
user
maintainers
is
a
helpful.
You
know
framework
and
then
you
know
comment
over
here
too.
If
you're,
if
you
don't
like
our
decisions,
right.
C
Yeah-
and
I
I
will
say
you
know
the
comments
that
you
provide
can
be
on
the
text
specifically,
but
also,
if
you
have
thoughts
on
the
ambiguities
of
operationalizing
at
those
sort
of
things,
we're
trying
to
collect
that.
So
we
can
have
a
broader
idea
of
you
know
just
what
this
would
mean
for
npm
and
other
registries.
So
it
doesn't
just
have
to
be
about
the
text.
It
can
just
be
about
the
issues
in
general.
E
B
H
H
Down,
oh,
no,
no,
don't
worry
about
it.
I
hated
to
be
the
guy
that
guy,
but
thanks
thanks
jack.
Yes,
I
I
did
want
to
raise
this
important
point.
Is
that
I'm
worried
that
we're
accidentally
leaving
some
people
out
and
we
may
be
missing
them
just
because
the
timing
is
not
right.
This
is
something
I
think
we
should
think
seriously
about
yeah.
H
I
don't
know
how
we
would
solve
this
problem
and
I
don't
think
we
have
enough
time
to
solve
it
now,
but
something
that
I
think
is
worth
doing
is
maybe
sending
out
a
survey
to
the
repo
communities
and
see
what
people
think
we
may
be
missing
a
demand
here.
I
don't
know
what
does
everyone
else?
Think
timing
is
always
hot.
I
know
it's
a
difficult
problem.
A
Yeah
we're
trying,
I
think,
logistically
it
might
be
challenging
as
well,
because
I
don't
think
we
have
a
like
jack
and
I
unfortunately
are
both
in
the
same
time
zone.
So
we
don't
have
a
chair
and
if
this
would
occur
at
a
later
time,
like
that's
sort
of
getting
into
my
bedtime,
so
I
think
we
could
try
and
shift
it
like
a
little
bit
later.
I
don't
know
if
that
might
be
helpful.
H
A
H
F
A
So
we
did
do
a
poll
when
we
originally
set
this
mean
time
and
split
this
into
a
pack
friendly
and
emea
friendly
time
zones.
This
was
the
time
that
was
selected
by
the
people
that
respond
to
the
poll,
it's
possible,
that
you
know
there's
folks
but
I'll,
raise
it
in
the
slack
channel.
Let's
see
if
we're
missing
anyone,
then
I'll
send
an
email
out
about
that.
So
thanks
trisha
for
raising
that.