►
From YouTube: Think BIG - 11-20-19
Description
In which we review making it easier to add npm packages, new designs and discuss investigating other open source package managers
A
Oh
well,
thank
you
to
our
think
big
session,
for
we
have
these
every
other
week
for
the
package
team.
So
we
have
a
few
things
to
cover
in
the
agenda.
Today.
Ian
was
going
to
go
first,
but
I
can
save
save
his
for
next
I
could
read,
Nathan
is
not
attending
so
I
could
read
this
one.
He
had
an
idea
to
make
it
ridiculously
easy
to
set
up
an
NPM
package
that
works
with
get
labs
registry
and
there's
some
ideas
that
have
been
discussed
in
that
possible
issue
and
then
a
possible
implementation.
B
Yeah
sure
I
could
do
a
live
just
like
now
so
yeah.
This
was
another
proof
of
concept
that
I
did
I
had
an
idea
to
make
this
easy
is
that
we
could
add
the
NPM
RC
file
as
an
option
from
the
project
presenter
page,
which
has
a
bunch
of
options
for
other
different
types
of
files
there,
such
as
like
weed,
Me's
and
change
logs,
etc,
etc.
B
So
my
idea
was
that
if
we
could
detect,
there
was
a
package.json
file
at
the
top
level
that
we
could
offer
this
as
an
option
to
act
to
create
this
file
in
the
exact
same
way,
she
would
do
with
any
of
these
other
files.
The
only
difference
being
is
that
we
would
pre
populate
the
NPM
RC
file
with
some
information,
so
basically,
what's
in
the
docs.
Currently,
the
only
thing
that
we
wouldn't
populate
in
there
is
the
authorization
or
access
token.
B
Also
flood
access
a
bit
like
I,
don't
feel
it's
quite
the
right
place
in
there.
We
did
have
a
little
bit
of
a
discussion
about
that
in
the
issue
that
Nathan
raised.
So
the
issue
that
I
created
I
was
able
to
do
a
POC
Ennis.
It
was
fairly
easy
to
get
it
up
and
running.
You
can
see
gif
of
that
in
action.
The
only
thing
is
is
that
it's,
basically
all
backend
work
and
I
wasn't
entirely
sure
where
you
would
store
the
the
pre-populated
content
so
on.
B
None
of
the
other
files,
as
far
as
I
could
see,
would
have
any
kind
of
pre-populated
content.
It
would
just
open
up
the
editor
with
a
blank
file
for
the
user
to
being
wherever
they
wanted.
So
as
pilot
PhD
I
just
did
that
in
line.
Obviously
that
probably
isn't
the
right
place
for
it
and
the
other
part
of
the
PhD
I
didn't
do
is
detect
whether
or
not
there
was
a
package.json
file
at
the
top
level.
So
the
button
would
basically
always
a
bit
I.
Don't
think
those
are
insurmountable
problems
at
all.
B
B
Yeah
I
don't
see
why
not
the
only
thing
I
would
say
with
the
maven
and
possibly
the
conan
one
as
well,
is
that
I
suspect
there's
a
stronger
chance
that
that
file
might
exist
before,
like
you,
wouldn't
create
it
through
this
interface
like
it
might
exist
as
part
of
like
creating
a
a
project
as
opposed
to
so
the
NPM
RC
file.
Is
it's
solely
to
give
NPM
some
behavioral
changes,
whereas
the
other
two
files
like
the
settings.xml
and
potentially
whatever
conan
uses?
Could
I
don't
know
for
sure.
C
A
B
I
mean
that's
certainly
easier,
I'd
I
question
whether
or
not
it's
valuable
I
suspect
it
loses
quite
a
lot
of
the
value
by
not
having
that
the
things
pre-populated
there
I
mean.
The
alternative
is
that
these
buttons
are
just
links,
they're,
not
actual
well,
they
don't
actually
have
to
lead
to
functionality.
They
can't
just
link
off
to
a
different
page.
So,
alternatively,
like
you,
could
potentially
do
something
where
for
say
maven,
it
would
create
an
M
R.
A
C
Think
yeah
I
mean
like
it
certainly
seems
like
a
defiant
issue
and
it
like
there's
nothing
like
super
crazy
going
on.
Necessarily
that
like
it
would
need
to
be
completely
Nadel
I'm,
just
checking
to
see
if
I
can.
So.
The
piece
that
you
need
to
populate
is
pretty
much
the
the
package
name
really.
That's
all
you
really
need
from
the
package
JSON
and
then
you
can
use
the
CI
took
and
the
CIA
yeah
the
CI
token
for
the
lost
token.
D
D
On
this
line,
I
think-
and
there
are
other
solution
that
actually
do
something
like
that
and
they
are
able
to
identify
which
kind
of
common
you
need
to
run
to
build
the
type
of
packages,
because
there
are
some
part,
for
example,
if
you
news
next:
okay,
that's
not
for
packages
but
still
build
something.
That's
the
common
that
you
always
run
so
this
day.
Actually,
every
time
the
package.json,
maybe
is
not
impossible
to
do,
but
definitely
it's
another
step.
E
Just
I
have
a
quick
question
for
everyone:
if
we
come
up
with
these
new
ideas
and
we're
in
the
middle
of
building
them-
and
it's
really
exciting
is
there,
and
this
could
just
be
me
new
it
get
loud.
Is
there
like
canary
version
that
we
could
actually
go
out
and
test
with
users
and
be
like
hey?
We
build
this
thing?
Can
we
validate
that?
It's
actually
helpful
for
you,
instead
of
trying
to
kind
of
make
that
assumption
ahead
of
time,
I.
A
F
A
E
F
F
I
was
gonna
say
like
one
of
the
things
we
try
to
do
and
not
to
not
try
and
I'm
not
trying
to
shut
down
the
conversation,
but
I
think
this
is
definitely
falls
in
the
bracket.
We
wrote
something
and
it's
customer
value
and
we're
not
I
represent
sure
release
it.
And
if
people
don't
like
it,
we
can
iterate
on
it
or
if
it
doesn't
quite
do
what
they
expect
and
we
can
iterate
on.
F
It
would
probably
try
a
channel
Syd's
iteration
I
am
a
slash
office
hours
yesterday
of
like
hey,
let's
just
get
it
out
and
if
people
don't
like
it,
we
can
improve
or
change
once
it's
out,
I
mean
I.
Think
the
only
reason
we'd
want
to
I
like
the
idea
of
testing
it
with
users,
but
maybe
it
just
means
you're
leasing
it
and
and
targeting
particularly
users,
to
get
feedback
like
actively,
rather
than
just
kind
of
waiting.
Until
we
hear
back
from
people
I,
don't
that
would
be.
A
My
thought,
one
of
the
things
that
that
Sid
said
yesterday
in
the
call
that
was
really
interesting
to
me
in
the
iteration
office
hours
was
not
necessarily
don't
necessarily
worry
about
delivering
value
but
deliver
something
that
could
be
useful.
So
that's
that
was
the
sort
of
the
biggest
mind
shift
that
he
gave
me
on.
A
The
call
yesterday
was
yeah,
it's
good
to
deliver
value,
but
you
don't
always
have
to
if
you
could
deliver
the
tiniest,
tiniest
sliver
of
value
and
that's
okay,
so
that
that
was
a
really
interesting
perspective
for
me,
because
I
was
I,
I
think
I've
always
been
saying
well
as
long
as
it
delivers
value.
As
long
as
it's
an
improvement,
we
should
do
it,
but
that
even.
F
F
Well,
the
example
that
I
thought
was
the
best
bet
and
thanks
for
mining
in
that
to
Jim,
because
that
was
pretty
good,
was
just
changing
the
documentation
to
make
the
documentation
about
the
feature
you
haven't
released
and
then
people
will
go
hey.
Where
is
this
thing
and
we
go
well,
we
didn't
do
it
yet
and
they
go
well.
We
don't
like
the
thing
that
you
said
here.
The
documentation
like
you
know
at
the
API
and
nothing
else
at
the
front
end
and
nothing
else
like
in
order
to
get
more
things
out
there.
A
E
Definitely
so
I'm
really
excited
because
we've
been
talking
about
what
we
could
be
doing
with
package
and
I
feel
like
this
is
the
first
time
we
we
have
a
thing
to
talk
about
so
I'm,
I'm,
very
excited
and
I
wanted
to
take
the
opportunity
to
get
everyone's
feedback
and
there's
quite
a
few
of
us
on
the
call
and
we
are
an
async
company.
So
a
lot
of
the
index
feedback
should
be
coming
from
there.
E
So
I
wanted
to
run
a
quick
trial
of
a
round
robin
that
I've
done
before
and
so
I'll
show
you
a
design
and
basically
what
I'd
like
for
you
to
do
is
look
at
the
design
and
then,
in
order
on
the
agenda,
give
one
piece
of
feedback.
It
could
be
something
positive.
It
could
be
something
negative.
It
could
build
on
somebody
else's
comments
and
provide
that
one
piece
of
and
then
we'll
move
on
to
the
next
person
we'll
keep
going
around
in
a
circle
until
everyone
has
given
enough
feedback,
or
you
run
out
of
time.
E
One
thing
to
call
out
you
can
+1
somebody
else's
idea
that
doesn't
count
as
your
your
required
contribution.
You
can
say
Oh
Nico
had
this
really
great
comment.
I
agree
with
that
and
then
also
I
have
this
piece
of
feedback.
I
would
like
to
timebox
it
just
so
we
don't
accidentally
consume
all
of
think
big
with
design
which
we've
done
before
so
if
I
could
nominate
Dan.
Who
is
really
good
at
this
for
stopping
us
at
10
after
the
hour
as
he
shrinks
and
shrivels
into
a
nothingness?
E
So,
though,
we
either
run
out
of
time
when
we
run
out
of
feedback
just
to
make
sure
we
still
trying
to
discuss
some
of
the
other
things,
and
if
we
do
another
feedback,
I
have
a
second
design
to
go
over
so
we'll
go
dive
in
I
know,
that's
not
necessarily
the
most
instruction,
but
I.
Think
it's
enough
and
I
have
to
figure
out
how
to
share
the
right
thing
sketch
all
right.
Can
everyone
see
a
design?
E
Exactly
what
I'm
intending
to
show
you
have
validated
stage
1
of
the
design
Dan.
Thank
you
so
much
all
right,
so
I'm
gonna
give
a
quick
overview.
This
is
the
package
registry
page
that
contains
all
of
the
different
packages
a
registry
could
have
in
this
example.
They
have
NPM
and
Conan
and
maven
packages.
All
in
one
group.
E
The
goal
is
that
this
should
serve
as
a
better
way
to
show
users
the
latest
information
about
their
packages,
as
opposed
to
the
table
view
that
we
kind
of
offer
now
quick
run-through
of
things
that
I
have
changed
on
the
design
and
then
we
can
dive
right
into
the
feedback.
So
I
want
to
make
that
a
census.
We
can
I've
kind
of
changed
the
structure
of
the
navigation,
I've
kind
of
changed
us
over
to
registries,
because
we
contain
two
types
of
registries.
E
One
of
them
is
the
container
registry,
which
has
docker
images
which
are
very
unique
and
then
package
registry,
which
is
more
similar
but
different
languages
as
a
second
option.
Right
now
we
just
say
list
and
that's
already
confused
a
couple
of
users
as
to
what
like
this
list
means,
and
they
don't
know
until
they
they
dive.
In
from
here.
We
have
the
breadcrumb,
shows
you
what
project
and
the
registration
etc.
That
you're
in
we
give
a
table
level
view,
so
you
can
sort.
These
are
all
the
MPM.
These
are
the
Maven.
These
are
the
Konan.
E
You
notice,
there's
an
indicator
that
says:
I
have
nine
maven
packages,
don't
necessarily
get
hung
up
on
the
fact
that
there's
nine
of
them,
because
I'm
not
very
good
at
counting
so
I,
know
there's
less
than
nine
but
they're
just
there
to
show
you
as
a
quick
view.
There's
this
many
of
this
type
of
package,
I've
added
the
ability
to
filter
by
name.
We
have
this
sorting
component,
so
I've
kind
of
given
it
a
better
home.
E
Each
package
gets
an
icon.
That
tells
you
what
kind
of
package
it
is.
We
talk
about.
The
namespace,
which
I
know,
is
something
unique
to
NPM,
so
I'm
curious
about
how
maven,
Coenen
and
the
others
could
response
this.
There
is
a
package
name,
I've
added
the
ability
to
verify
a
package.
This
comes
directly
from
user
feedback,
they
want
as
a
DevOps
manager,
to
say
everybody
that
is
using
a
package.
This
is
the
version
of
the
package
we
want
you
to
use.
E
It
has
been
verified
by
some
person
for
the
first
time,
just
kind
of
said:
it's
a
maintainer
house,
the
authority
to
say
this
is
verified,
and
then
we
show
what
the
different
tags
are.
We
have
a
version
published
by
a
person
and
then,
on
the
other
side,
we
have
the
branch
and
commit
information
where
you
can
copy
the
commit
sha.
E
This
is
the
number
one
piece
of
data
everyone
seems
to
care
about,
that,
isn't
a
name
is
the
Commissioner
came
from
and
then
I
made
it
really
really
highlighted,
giving
it
its
own
space
as
to
when
it
was
created.
That
seems
to
be
how
recent
something
has
changed
as
a
big
indicator
of
when
it
can
be
helpful.
E
Top
of
that
for
each
item,
there's
also
a
warning.
This
warning
is
our
system
saying
this
package
is
zero
kilobytes,
it's
probably
wrong.
This
package
can't
be
built
by
NPM,
install,
maybe
something's
wrong,
and
these
are
very
like
I,
don't
want
to
say
idiot
checks
by
very
basic
requirements
of
a
package
in
order
to
be
successful,
and
if
it's
not
there,
we
show
a
warning.
E
The
last
piece,
that's
kind
of
unique
is
this
vulnerability
found.
This
is
from
the
security
team
that
does
a
sweep
of
all
the
stuff
that
we
upload
to
the
registry
and
says
this
didn't
meet
a
security
requirement.
It
could
be
a
dependent
that
you
use
is
vulnerable
or
it
could
be
there's
a
vulnerability
in
the
code.
That's
something
else
we
could
explore,
and
then
we
have
this
nice
pagination
function,
whoo
that
was
the
fastest
I've
ever
run
through
a
design
which
is
always
very
exciting.
E
I
actually
like
to
skip
questions
in
this
face.
So
and
it's
your
turn,
if
you
have
a
question,
feel
free
to
jump
out,
because
it
could
mean
something:
I,
I
design
doesn't
work
very
well,
but
that's
kind
of
the
high
level
so
I
think
first
up
is
I
volunteered
Niko
to
go
first,
so
Niko.
Do
you
have
a
piece
of
positive,
negative
or
neutral
feedback?
Just
one
can.
D
You
just
ask
to
not
select
the
right
tinggi,
the
red.
There
is
a
red
line,
I
suppose
that's
like
the
I
have
gotten
rid
of
the
red
thingy.
Thank
you,
yeah
first
feedback.
Without
the
tooltip
I'm,
not
sure
what
the
copy
button
does
does
it
copy
the
pipeline?
Does
it
come
in
call
me?
Cha
doesn't
copy
the
full
line.
A
E
H
Do
what
happens
when
there's
a
bunch
of
different
package
may,
like
NPM,
maven
Conan?
What
happens
as
that
expands
beyond
the
space?
That's
provided
for
them,
the
so
so
over
it!
That's
so
where
it
says
all
package
is.
Gonna
has
a
PM
21
mate
and
nine
Conan
one
as
there
are
more
and
more
package
managers.
What
happens
if
it
was
just
keep
going
like?
What's
the
overflow
for
that
look
like
for.
E
E
B
Okay,
so
for
me,
then,
is
registries.
The
right
word
on
the
left-hand
side
menu
because
I
know
that
we
have.
Is
it
dependency
proxy
that
appears
in
this
list
as
well,
and
potentially
other
areas
or
more
sections
could
go
in
there
and
I
know.
There
was
quite
a
lot
of
discussion
around
whether
or
not
it
should
be
called
list
and
we
sailed
with
lists
in
the
end,
so
yeah
I.
E
Am
certainly
open
to
feedback
here,
I've
heard
from
a
couple
of
users
that
the
way
it's
architected
now
is
confusing.
I,
don't
know
what
the
right
answer
is
to
move
forward,
so
this
can
definitely
be
an
open
question
that
we
open
an
issue
and
really
dive
into
what
the
correct
way
to
do
it,
especially
considering
the
dependency
proxy
as
a
different
unit.
E
G
G
E
I
have
heard
numerous
times
that
the
merge
requests
into
the
master
or
into
a
specific
branch
is
actually
what
triggers
the
CI
pipeline
generate.
A
new
package
I've
only
heard
that
a
couple
of
times
so
I
am
very
open
to
changing
it,
but
that's
why
it
is
that
kind
of
merge
icon,
as
opposed
to
necessarily
a
branch
or
commit
icon.
G
G
E
So
gala
pattern
is
that
when
you
hover
over
it,
there's
a
tooltip
that
kind
of
tells
you
where
the
link
will
take
you,
because
it
is
a
little
abstract,
I'm
happy
to
follow
that
pattern
in
the
ListView.
In
the
detail
view
I
want
to
be
a
little
bit
more
explicit
to
kind
of
call
out
what
you're,
what
you're
mentioning
is
the
commander's
or
branch
like?
What
is
this
thing.
A
Get
so
I
one
thing,
I've
noticed
in
the
past,
with
using
the
different
icons.
I
feel
like
it
looks
nice
when
it
comes
to
design,
but
then,
when
it
comes
to
actual
implementation,
it
never
looks
like
you
like
you,
planned
it
on
the
design
and
it
can
end
up.
Looking
messy
I
was
I
was
just
wondering
your
thought
about
that,
and
if
we
did
also
like
would
we
allow
them
to
upload
custom
icons
in
here
as
well
and
with,
and
would
that
make
it
a
little
bit
more
dision
this
uniform
as
well
for.
A
E
E
If
that
becomes
the
case,
then
we
will
need
to
address
the
fact
that,
outside
of
that
image,
the
design
doesn't
tell
you
what
kind
of
package
it
is,
but
when
we
explore
that
we
should
make
an
adjustment,
so
it
says
it
could
be
published
NPM
package
by
Ian
Camacho,
for
example.
So
it
is
something
we
should
definitely
address,
that
the
changes
and
one.
A
Other
thing
I
know
I
was
only
supposed
to
go
once
is
what
about
some
kind
of
like
spark
line
or
something
that
was
showing
like
how
often
it
was
used.
I
know,
I,
know
that's
kind
of
far
away
from
when
we
could
do
that,
but
just
from
a
visual
perspective
is
that
something
that
you
think
users
would
be
interested
in.
E
Yes,
don't
like
it
as
a
design
person
and
so
I'm
in
conflict.
It
may
create
a
very,
very
busy
screen,
but
numerous
times
to
your
point,
DevOps
have
come
back
and
said:
I
want
to
know
how
often
a
package
is
being
used
because
I'm
the
person
who
knows
whether
it
should
or
should
not
be
being
used,
and
so
it
is
really
relevant
to
be
able
to
look
through
and
be
like.
C
F
C
E
Away
so
I
took
the
approach
that
I
mean
just
straight
into
that
question,
that
if
they're
not
building
packages
on
gitlab,
we
simply
surface
less
information
and
the
reason
I
pick
that
route
is,
if
you're,
not
using
your
left,
to
generate
your
packages.
We
want
you
to
and
I
want
to
very
clearly
demonstrate
why
it's
file,
so
you
can
totally
just
upload
a
package
and
so
you'll
just
be
missing
some
information,
so
just
kind
of
live
boring.
What
do
you
think
about
that?
E
C
C
E
E
F
That's
that's:
that's
Tim
I'm,
not
taking
credit
for
Tim's
great
note-taking.
It's
not
fair.
First
piece
of
feedback,
yeah,
so
I
would
say
what
jumps
out
to
me
is
particularly
gitlab.
We
love
our
labels
and
we
label
everything
with
everything
we
can
possibly
think
of,
and
that
makes
for
some
pretty
busy
screens
but
we're
partially
using
labels
here
and
partially.
F
Not
so
if
we
wanted
to
have
a
custom
icon,
you
know
having
a
label
for
NPM
because
it
was
an
NPM
package
and
then
you
could
use
standard
filtering
that
we
have
already
built
into
the
side
we
we've
recently
added
or
recently
I.
Don't
know:
we've
added
functionality
to
disable
labels
in
some
areas
like
so
you
could
send
them
all
off.
F
So
in
this
case,
I
would
wonder
whether
they'd
be
some
value
in
using
labels
for
the
package
type
and
using
labels
more
extensively,
so
that
it
would
function
the
same
way
as
the
rest
of
the
rest
of
a
lot
of
the
rest
of
the
user.
Experience
on
BLM
that'd
probably
be
my
feedback,
because
I'm
going
to
want
to
go,
click,
verify
and
just
see,
verified
stuff,
and
if
we
were
labeling
and
traditional
label
way.
I
can
use
that
as
part
of
the
filter
and
search
on
it
right.
F
I'm
not
gonna,
try
to
make
an
argue
about.
Oh
you
meant
about
what's
intuitive
through
our
users.
I
think.
That's
not
really
my
my
area
of
expertise,
but
I
would
say
that
we
have
a
consistent
experience
across
gitlab,
where
we,
you
know,
use
labels
extensively,
to
put
it
politely,
or
maybe
too
much
as
some
people
say,
because
if
I
absolutely
have
an
ability
to
item
right,
so
I
think
that
using
that
model
resolves
any
concerns,
we'd
have
about
adding
a
custom
icon.
E
F
F
We
we're
gonna
be
getting
we're
investing
a
fair
bit.
The
search
team
is
being
built
out
and
you
know
we're
probably
going
to
end
up
with
more
extensive
searching,
including
like
not
searching
and
stuff
like
that.
So
you
know
if
I'm,
if
I'm
an
administrator
for
this
this
organization,
I,
can
go,
I
only
want
to
see
stuff
that
has
a
warning
on
it.
I
am
they
want
to
see
stuff
that
has
a
security
warning
and
I.
You
just
click
that
it's
a
label
and
it
ends
up
showing
up
really
easily.
E
Yeah,
that's
great
feedback.
I
will
I've
actually
been
hesitating
to
the
opposite
of
that,
so
it's
kind
of
good
to
get
some
feedback
that
I
can
abused.
Maybe
not
it
is
I
can
utilize
that
a
little
bit
more
to
show
more
of
the
information
so
like
the
fact
that
it's
NPM
can
kind
of
float
up
to
that
level.
Yeah.
E
E
D
Your
Niko
I
believe
you
next
ok,
so
I
want
to
connect
what
Dan
said.
I
tried
to
put
myself
on
the
point
of
view
of
asset
user.
Why
would
I
even
want
to
see
non
verified
stuff?
So
maybe
this
list
should
be
like
default
filter
by
verified,
non,
no
warning
and
then
you're
able
to
begin
if
you
are
interested
in
other
stuff.
But
if
I
just
need
to
go
to
my
package,
why
should
I
download
something
that
doesn't
work
or
something
Montana
is
not
sure,
is
correct.
E
That's
really
cool
I
want
to
explore
that
idea.
I
don't
have
an
immediate
solution,
but
that
is
you're
totally
right.
If
I
was
a
normal
user,
I
just
want
the
verified
use
this
package
information
I,
don't
care
about
all
the
other
available
options.
That's
the
good
call.
I'm
gonna
have
to
play
with
that.
E
F
H
So,
off
to
the
left
of
the
package
names
you
see,
an
image
of
that
represents
the
type
of
package
manager.
Is
that
the
most
is
that
the
most
distinguishing
way
to
tell
what
kind
of
package
that
is,
for
example,
just
just
having
the
see
with
the
block
if
you're
not
familiar
with
Conan,
you
know,
is
that
meaningful
to
you
as.
E
The
user
yeah
I
definitely
worked
off
the
assumption
that
everyone
would
know
what
every
icon
meant,
but
now
that
you
brought
it
up,
I've
never
seen
maven
until
I
were
to
get
lab,
so
I
have
no
idea
what
that
icon
means.
That
is
a
really
good
and
very
important
call-out.
It
kind
of
adds
to
the
idea
that
we
should
probably
have
that
in
you
know
the
label
or
some
other
place.
That
very
clearly
says
this
is
a
Conan
package.
This
is
an
NPM
package.
H
G
B
E
So
my
first
assumption
is
that
if
there
is
ZERO
Konan
packages,
there
just
wouldn't
be
a
conan
tab.
I
couldn't
be
persuaded
otherwise,
but
I'd.
Imagine
that
it's
the
most
the
majority
of
the
use
cases.
I
can't
imagine
a
situation
where
someone
needs
to
know
that
something
doesn't
exist
necessarily
in
this
kind
of
realm.
E
E
B
E
So,
as
my
inner
UX
er
I
would
say,
yes
immediately,
provide
all
things
that
users
need
I
want
to
jump
on,
that
I
have
to
have
a
deliberation
with
Natori.
She
is
in
terms
of
navigation
in
terms
of
the
design,
team
and
I
would
imagine
we're
going
to
have
that
exact
conversation
of
it
would
be
really
great
if
they
could
just
link
to
the
NPM
packages
from
the
sidebar,
and
her
response
may
very
well
be
that
that's
too
busy
and
just
class
the
water
certainly
worth
an
investigation,
though
cuz
I'm
sure,
as
a
front-end
developer.
E
I
G
E
Nope,
that
is
100%
correct,
that's
a
great
question
and
from
what
I've
heard
users
would
prefer
the
pipeline
data
as
opposed
to
them
the
branch
data,
so
I
wonder
if
this
is
changing
depending
on
the
situation.
So
if
a
pipeline
built
it,
we
show
pipelining
commit.
If
it's
some
other
situation,
we
we
demonstrate
it
differently.
That
is
actually
one
of
the
questions
I'm
going
to
be
asking
during
the
round
of
validation.
E
E
Would
want
to
explore
that
it
might
be
tuned
for
me
too
much
information
in
just
the
static
page,
but
maybe
on
the
version
stage,
where
we
have
the
individual
package
and
all
the
versions
of
that
package
or
being
displayed,
then
we
can
show
this
one
failed.
This
one
failed
this
one
passed.
That
could
be
a
really
interesting
experience
for
sure.
E
A
E
For
sure,
when
I
originally
built
this
I
assumed
this
was
the
project
view
of
a
mono
repo
that
produces
many
different
types
of
projects,
I
think
on
a
project
view
or
a
group
on
a
group
view
or
an
instance
view
we
should
include
what
project
it
came
from
and
it
could
float
here
or
it
could
end
up
down
here.
I'm
not
sure
but
I
agree.
I,
think
it
should
be
on
the
list.
C
C
Thing
that
I
was
thinking
about
was,
as
a
user
of
packages,
a
common
thing
that
I
find
myself
doing.
A
lot
is
I'll,
look
for
a
certain
package
and
then
the
number
one
thing
I
need
is
like
the
install
command
and,
like
you
know,
for
example,
on
NPM.
When
you
go
to
visit
any
given
page,
you
can
just
click
and
it
copies
there
like
npm
install
package
name.
C
E
Where
one
of
the
things
I'm
considering
is
adding
a
add
to
project
button
similar
to
how
I
have
it
in
the
details
screen
which
you've
never
seen,
which
kind
of
accommodates
all
of
that
here's,
the
NPM,
install
instructions,
here's
the
package,
jason
employed
whatever
you
need,
because
exactly
what
you're
saying
once
I
find
the
one
I
want
I
wanted
a
hot
added
you
all
right,
we're
almost
done
cool
Dan.
How
fast
can
you
go?
I.
F
Just
a
way
this
takes
up
a
heap
of
space
for
each
item.
So
if
I'm
an
organization
with
like
300
packages,
maybe
I
can
filter
them
down
to
verified
like
we
suggested
earlier.
But
if
I
have
you
know,
68
verified
things
that
I
might
like.
Then
how
do
I
figure
out
what
I
need
next
I
mean
the
filtering
might
help
there,
but
you
know
we're
using
two
lines
for
every
single
one.
Is
there
a
minimal
view
or
a
review
where
we
could
include
more
on
a
single
page.
E
We
can
certainly
create
a
more
dense
view
of
this.
However,
based
on
the
research
that
I've
done
so
far,
most
companies
aren't
hitting
that
level
to
where
I
think
it
should
be
a
primary
concern.
It
should
be
something
like
you
suggested.
We
do
with
filtering
and
searching,
but
it's
certainly
something
to
consider
and
while
I
do
validation,
I'll
ask
it:
how
many
packages
do
you
actually
end
up
seeing
on
this
list?
Cuz
I
can
really
dictate
how
much
we
have
to
accommodate
things
when.
F
I
generally
just
put
everything
in
a
condensed
view
for
myself
anyway,
and
that's
just
the
way
I
work
compared
to
other,
like,
even
even
if
there
was
three.
This
takes
up
a
hit,
the
space
on
the
screen
and
so
you're.
This
is
a
full
screen
view
of
a
single
page
in
the
app,
and
so
if
we
added
the
filter
bar
with
the
labels
in
it,
that
would
take
up
some
space
and
then
you've
got
fewer
things
that
are
physically
on
the
screen
physically
on
the
screen,
and
you
know
so.
F
E
I
H
E
Should
have
all
the
other
times,
we've
done
this,
we
should
have
fixed
this
by
now.
It's
so
true
all
right.
Thank
you.
All
that
was
really
really
great
feedback
and
I
think
the
process
of
getting
feedback
was
really
helpful,
because
everyone's
got
a
unique
view.
I've
only
consumed
most
of
the
time,
as
was
all
of
it.
This
is
iterative,
improvement,
Dan
and
so
I
did
it.
Thank
you
very
much
for
the
feedback
and
I
think
somebody
else
is
up
now,
as
the
post
adjust
meet,
we're.
A
A
There's
also
been
some
other
changes
at
key
for
spelled.
I
was
been
mispronouncing
at
Quay
for
my
whole
time
at
git
web,
which
is
super
embarrassing,
but
key
open
source,
their
container
registry
and,
if
you're
familiar
with
the
repple
that
ID
they
just
recently
open
sourced
a
universal
package
manager
as
well.
So.
A
There's
a
lot
of
movement
in
in
the
space
that
we're
in
and
a
lot
of
people
moving
towards
open
sourcing.
This
and
I'm
just
wondering
as
a
team,
maybe
there's
something
that
we
could
learn
from
the
projects
that
they've
open-source,
maybe
there's
something
that
we
can
integrate
into
our
platform,
or
maybe
it's
just
worth
a
discussion
over
where
the
industry
is
going
in
this
sense
and
I'm
I'm
wondering
what's
the
best
way
that
we
can
have
that
conversation.
Do
maybe
do
that
investigation
and
talk
about
those
things?
Is
it?
A
H
Yeah
I
think
ki
is
probably
the
thing
to
look
at,
because
that
is
a
do
believe.
They
have
online
garbage
collection,
which
is
our
big,
which
is
a
really
big
goal
for
us
and
I.
Don't
know
if
that's
I
think
part
of
that
consideration
is
like.
What
does
it
mean
just
to
use
key
is
that
is
that,
like
the
quickest
fastest,
most
boring
way
to
solve
our
problem,
and
what
is
what
would
the
transition
over
look
like,
and
what
would
I
do
here.
H
Yes,
so
yeah
I
mean
I,
think
we
I
think
that's
definitely
probably
worth
an
issue
just
so
that
we
can
I
think
that's
kind
of
like
a
thing.
That's
gonna
have
a
lot
of
gar
like
a
path
to
go
down.
So
I,
probably
just
it's
own
separate
issue
to
discuss
what
we
could
do
about.
That
would
be
my
instinct
on
that.
A
Okay,
cool
yeah,
I
really
I
like
that
idea.
A
lot
maybe
could
we
can
have
a
way
of
sort
of
timeboxing
an
investigation
and
and
doing
it
that
way,
I
don't
know
that
the
repple
open-source
project
really
applies
to
us,
but
there
might
be
some
learnings
that
we
could
take
just
in
terms
of
how
they've
abstract
it
away
some
of
the
functionality
like
it
really
is
just
you
can
install
any
package
with
like
a
common
framework,
so
I
really
like
that
idea.
Okay,
so
maybe
I'll
open
up
some
team
issues
to
talk
about
it.
A
F
I
think
I
think
the
one
thing
I
want
to
call
out
on
evaluating
at
this
point
different
alternatives
to
daca
distribution
registry.
Is
the
I
think
it's
a
big
it's
worth
looking
at
key
to
see
what
they're
doing
and
to
determine
whether
that
could
be
useful,
I
think
the
concern
there
is
evaluating
that
against
how
much
effort
would
be
required
to
add
this
to
existing
solution.
This
would
be
in
cooling
installing
a
whole
new
system
using
a
language
that
currently
Montana
is
using
for
the
most
part
inside
collab
I'm.
F
So
the
ability
to
support
that
across
the
team
would
be
relatively
limited.
At
least
early
on
I
mean
I'm
sure
there
are
plenty
of
people
that
knows
them
Python
at
some
level,
but
there
are
a
lot
of
other
sort
of
organizational
slash
support
level
considerations
there
and
then
the
other
big
red
flag,
I
have
in
my
head
around
that
is
migrating
all
of
our
existing
packages
from
what
we
have
to
that.
F
So
far,
we've
been
able
to
just
do
upgrades
in
place
with
the
changes
that
we've
been
been
able
to
make
so
far
with
the
our
implementation
of
container
registry.
Having
a
whole
new
system
means
migrating
and
building
code
and
functionality
to
migrate
customer
packages
from
one
to
the
next
and
then
it's
a
local
install,
which
has
to
be
verified
for
our
on
premise
or
self
hosted
people
so
I
think
there
are
a
bunch
of
considerations
that
would
have
me
sort
of
going.
F
Okay,
I
want
to
have
a
really
good
reason
why
this
is
valuable
wiesen
why
this
would
actually
be
the
way
we
want
to
go
I'm
not
saying
I'm,
gonna
block
it
a
shoal.
Okay,
that's
kind
of
think.
That's
really!
My
role!
I
just
want
to
flag
those
things
for
people
to
think
about,
as
we
considering
these
options.
F
But
doesn't
it's
not
always
super
easy
to
do
that,
and
in
that
case
it
means
that
we
can't
actually
implements
fixes
or
like
features
that
we
want
to
implement.
So
that's
actually
kind
of
restrictive
and
we're
working
on
that
by
the
way,
just
for
everyone
watching
out
in
the
rest
of
the
the
rest
of
the
Internet,
but
like
we're
working
on
that
effort.
So
definitely
something
we
won't
consider
as
we're
evaluating
other
open
source
options.
Let's
make
it
better
if
we
can
and
if
we
can't
that's
kind
of
like
okay.