►
From YouTube: Think BIG discussion 10-2-19
Description
In which we review our most recent survey results, how to help users get started faster and create packages from the UI.
A
B
C
A
D
Sure
so
survey
result
we
sunsetted
it
end
of
last
week
and
we
ended
up
with
243
responses.
That's
really
great
too,
when
we
originally
talked
about
it,
I
did
have
a
thousand
goal.
That's
a
really
high
number
for
a
survey
result,
and
usually
companies
like
Apple
and
Facebook
have
to
do
like
big
campaigns
in
order
to
get
that
kind
of
number.
So
the
fact
that
we
didn't
hit
it
is
not
a
big
deal,
which
is
great.
You
can
take
a
look
at
the
issue
which
I
have
linked
in
the
agenda.
D
If
you
want
to
go
over
the
history
of
it,
it
also
has
kind
of
the
segment
breakdown
of
who
responded
to
the
survey
we
got
pretty
lucky.
There
was
a
good
mix
of
different
engineering
types.
Full
stack
was
the
most
popular
with
26%.
The
fact
of
that
number
is
so
low
lets
us
know
that
there
was
a
good
chunk
of
all
the
other
groups,
which
is
really
great.
D
The
engineering
size
was
a
bit
of
a
mistake
on
my
end.
They
came
to
discover
so
61.7
percent
of
respondents
said
that
they
belong
to
a
team
between
one
and
ten
engineers
and
I
realized
the
way
that
I
phrased
the
question.
You
can't
discern
whether
I'm
talking
about
the
entire
team
as
in
the
gitlab
Package
team
or
the
entire
gitlab
engineering
force.
D
So
that
was
my
mistake
and
I'm
going
to
make
sure
I
clarify
next
time,
but
it's
great
because
even
if
that
were
the
case,
we
know
know
that
users,
you
know
61.7%
of
them
at
least
view
themselves
to
be
on
teams
of
about
that
size.
So
that's
kind
of
mix
that
we
know
that
their
mental
model
is
fixing
around.
So
it's
cool
that
we
got
a
good
piece
of
information,
just
not
quite
what
I
was
going
for
project
architectures
between
the
micro
services,
SOA
and
monolith
repos.
D
We
actually
got
a
pretty
solid
mix
of
them.
The
monolith,
repo
and
the
micro
services
kind
of
held
most
of
them,
and
then
under
that
was
a
little
bit
the
SOA
and
then
very
few
respondents
had
anything
else
which
is
kind
of
great.
We
know
we're
capturing
the
right
amount
of
data
NPM
and
docker
we're
the
top
four
data
sources
in
terms
of
the
different
package
managers
that
we
had,
and
that
means
the
most
number
of
people
that
took
the
survey.
Did
the
NPM
and
docker
part.
D
One
thing
that
really
surprised
me
as
we
asked
what
tools
they
use
I'm,
not
quite
sure
how
it
got
in
there.
But
Linux
is
one
of
the
options.
So
my
question
to
the
group
is:
is
there
a
linux
package
manager
that
we
should
be
capturing
and
we
should
look
at
see
if
there
is
a
big
demographic
that
has
that
need,
because
we
did
get
a
lot
of
responses
or,
if
that's
outside,
of
our
purview
and
that's
just
a
weird
little
hiccup.
That
I
should
ignore
know.
A
It
that's
one
of
our
it's
a
common
request.
We
hear
and
definitely
an
internal
dogfooding
request.
I
know
we
have
requests
for
apt,
YUM
and
I
just
thought
another
one
that
came
in.
We
could
review
it
in
the
next
step.
I
think
we're
gonna
go
through
the
package
managers,
but
yeah
that
was
yeah.
Well,
you
should
support
Linux.
It
sounds
like
so.
D
We
got
a
lot
of
responses,
so
we
should
certainly
look
into
it.
I
don't
have
any
data
around
what
they
were
doing
with
that,
but
we
know
that
we
should
look
into
it,
which
is
pretty
great
one
thing
about
the
data
is
it
was
really
boring
and
that's
actually
really
exciting.
It
means
that
the
model
that
we
built
all
the
questions
around
matches
what
our
users
models
were.
For
example,
we
asked
the
users:
what's
your
primary
reason
for
going
to
X
package
manager
UI,
then
we
gave
them
a
list
of
five
options.
D
A
majority
of
our
users
fell
into
one
of
the
options
we
provided
and
the
other
option.
The
ones
that
we
didn't
capture
was
almost
never
used,
and
the
text
response
is
worth
things
like:
I,
don't
or
I,
never
go
there
or
I
clicked
on
the
link.
So
we
we
did
a
great
job
of
kind
of
knowing
what
our
users
are.
Gonna
try
to
do,
which
is
really
exciting.
So
that's
the
value
of
boring
data.
D
C
A
D
So
we
had
them
stack,
rank
them
all
and
when
you
do
start
cranking
with
more
than
a
four
or
five
options,
the
answer
gets
pretty
hazy.
But
we
know
that
as
a
general
trend-
and
this
is
an
insight-
I
still
have
to
create
that
there
was
kind
of
the
top
tier
things
where
your
basic
package
data.
So
what
the
name
is,
what
the
link
is,
how
to
use
it,
that
kind
of
thing
and
then
underneath
it
was
a
band
of
kind
of
the
gitlab
data
which
is
exciting
that
we
placed
up
there.
D
So
that's
things
like
where
what
pipeline
built
this
where's,
the
repo
ad
that
kind
of
thing
and
then
there's
this
bottom
tier
of
just
what
seemed
like
random
junk,
because
the
orders
in
that
bottom
tier
we're
not
consistent
at
all,
but
the
things
that
we're
in
there
were
such
as
that
tar
file.
That's
a
perfect
example
of,
like
it
almost
always
placed
there
were
17
total,
so
it
always
placed
in
like
15,
16
or
17.
So
we
know
that
it
like
fell
in
the
bottom,
and
it's
not
important.
D
What
we're
going
to
do
is
take
that
hazy.
Data
and
then
combine
it
with
the
user
interviews
that
I'm
going
to
be
doing
next
week.
That
is
asking
them
asking
users.
How
do
you
organize
this
data
so
we're
going
to
ask
them
to
categorize
them
instead
and
then
some
qualitative
information
about
why
it's
valuable
and
so
we'll
combine
the
survey
data,
the
categorization
data
and
that
qualitative
data
on
understand
how
we're
gonna
lay
out
the
package
screens.
D
One
thing:
that's
pretty
great
is
that
we
now
know
or
have
some
data
so
to
support
that
the
different
package
managers
could
probably
have
a
reasonably
consistent
UI,
because
the
things
that
are
in
the
different
areas
are
pretty
consistent.
There's
gonna
be
some
minor
variation,
but
on
the
whole,
the
basic
architectures
didn't
work
great.
So
that's
one
of
the
things
I
was
worried
about
is
that
every
package
manager
we
wanted
to
do
is
going
to
need
a
whole
custom.
Ui
excuse
me
and
we're
not
gonna.
Do
that.
So
that's
great.
D
Perfect,
a
couple
of
insights
that
I
thought
were
cool
and
I've
linked
to
the
detail,
so
you
can
see
how
the
data
works
out,
but
users
who
manage
21
or
more
NPM
packages
were
significantly
more
likely
to
visit
the
UI
to
look
up
which
version
of
the
package
to
use.
Usually
this
at
around
20%
of
users-
that's
why
they
were
coming
to
it,
but
for
that
one
group
that
had
21
or
more
that
jumped
almost
67%.
D
So
there's
a
huge
spike
when
you
hit
that
number
of
people
coming
to
the
UI
to
look
up
which
package
they're
supposed
to
use
in
their
projects.
So
that's
kind
of
a
useful,
peaceful
piece
of
information
to
know
when
we're
looking
at
the
bigger
projects
and
the
bigger
kind
of
Enterprise
II
companies
tend
to
have
more
packages.
If
there's
ways
that
we
can
accommodate
that
more
successfully,
I
give
an
example
of
how
the
data
priority
works.
D
To
be
honest,
the
data
doesn't
look
very
pretty
so
it's
just
kind
of
a
list
in
order,
and
then
the
data
is
kind
of
the
average
place
they
were
and
it's
sorted
by
that
average.
It's
not
there's
so
many
pieces
of
data
that
it's
not
going
to
be
particularly
clear
where
exactly
it
places,
but
that's
how
we
get
those
bands
that
I
was
talking
about
earlier.
B
D
Got
some
confirmation
on
kind
of
the
flipside
when
you
have
data,
that's
not
very
interesting.
We
know
that
users
do
actually
have
a
mix
of
how
many
images
they
use,
because
we
had
respondents
that
there
was
a
group
of
them
that
were
one
image
and
then
there
was
an
almost
equal
group
of
two
to
five
and
then
an
almost
equal
group
of
six
to
eleven
and
an
almost
equal
group
of
eleven
or
more.
So
it's
it's
good
to
know
that
the
docker
registry,
as
an
example,
will
need
that
kind
of
flexibility.
D
What
I
was
hoping
for
is
as
I
kind
of
went
over
this
data
and
you
can
kind
of
see
some
things.
Is
there
anything
from
the
survey
that
you
wanted
to
see
compared?
So
if
there
any
insights
that
you
thought
would
be
here
that
I
didn't
really
cover
today
or
aren't
listed
in
the
insights
on
that
issue,
and
then
the
other
thing
I
would
love
to
hear
from
you
guys
is.
Does
anybody
have
any
ideas
of
how
to
take
these
insights
and
kind
of
turn
them
into
solutions?
D
Whether
we
want
to
start
discussions
on
these
insights
with
the
team
or
if
you
know
we
should
I,
should
go
through
and
make
issues
based
on
my
own
judgment
or
how
you
wanted
to
handle
that
as
a
team,
and
that
is
my
11
minute
presentation,
the
survey
data
I
have
to
admit,
I've
been
looking
at
it
for
three
days
straight,
which
is
really
exciting
and
very
zenful
for
me,
because
I'm
kind
of
OCD
but
I
am
burnt
out
on
it
now.
So
the
if
I
kind
of
murmur
I
apologize
well
square,
eyed,
I,.
A
D
Definitely
so
the
majority
of
the
respondents
seemed
to
come
from
the
Twitter.
Push
that
we
got
from
just
get
LabCorp
said
to
get
out.
Twitter
is
a
great
way
to
get
respondents,
because
it
is
one
of
the
more
open
markets
in
terms
of
who's
gonna
respond.
So
it's
anybody
that
follows
get
lab
as
opposed
to.
We
may
get
a
bias
by
pinging
people
who
use
issues
to
talk
about
npm
already.
D
B
D
Its
I
don't
know
if
it's
necessarily
something
to
be
concerned
about,
but
because
it's
a
possibility
I'd
prefer
to
avoid
it.
It's
you
can
create
your
own
bubble
if
you're
only
talking
to
yourselves.
So,
for
example,
if
we
are
using
a
package
manager
and
they're
talking
on
github
issues,
it's
unlikely
that
we'll
be
able
to
capture
someone
who
is
from
github
and
they
could
have
this
different
perspectives
on
the
same
problem,
so
that
kind
of
makes
sense
versus
if
we
only
went
to
one
source
we'd
only
get
that
one
opinion.
C
C
Sorry,
it's
cuz
I,
though
the
envy
is
too
surprising,
I'm
interested
in
the
first
two
ones
about
the
the
people
who
manage
21
or
more
NPM
packages
sounds
like
quite
a
lot
for
a
private
organization
to
have
like
21
or
21
or
more
private
packages.
So
I
wondered
if
there's
some
more
well
I,
don't
know.
I
wondered
if
there's
some
more
insight.
We
can
take
from
people
who
are
using
it
that
extensively
and
like
what
features
can
help
them
or
what
features
are
going
to
encourage
other
people
to
get
to
that
cut.
C
D
That's
that's
great!
So
for
the
first
part,
we
definitely
should
figure
out
how
those
power
users
are
using
it
and
why
it's
so
successful
because
they
have
to
do
less
of
the
other
work
to
use
the
UI.
It
was
also
one
of
our
smaller
sample
sizes
and
so
they're
kind
of
harder,
a
harder
user
to
get
a
hold
of
in
general,
so
you're
right,
most
people
sat
in
either
the
one
or
two
to
five
range.
A
When,
when
I
hear
things
like
they
they're
going
to
the
registry,
because
they
want
to
confirm
that
something
was
built
properly,
is
that
in
the
best
experience
for
confirming
that
something
was
built
like,
for
example,
we
have
pipelines,
we
have
little
pop-up
Mobile's,
that
pop
up
and
say
pipeline,
succeeded
or
failed.
There's
an
activity,
feed
we'd,
be
thinking
about
things
like
that
for
letting
users
know
when
an
image
is
pushed
or
something
like
that.
Yeah.
D
So
one
of
my
next
steps
was
actually
to
reach
out
to
hi
Jana
she's,
one
of
the
designers
on
verify
I
think
they
work
on
the
pipeline's,
but
to
see
if
there's
a
place
where
we
could
present
that
data.
So
you
don't
have
to
come
to
the
package
repository
to
see.
If
it
happens,
we
can
just
show
you
when
it
does
or
give
you
access
to
that
data
in
a
more
relevant
area,
and
then
maybe
let
you
click
directly
to
the
image.
D
If
you
need
it
to
so,
I
definitely
do
plan
on
reaching
out
I'd
love
to
kind
of
explore
how
we
can
flourish
because
that's
how
we
get
to
be
a
bit
more
of
a
sticky
feature
and
the
more
integrated
we
get
with
the
rest
of
the
platform.
The
more
likely
people
are
to
use
us
as
part
of
the
platform.
So
it's
really
successful
for
us.
E
I'd
be
curious
if
there's
a
trend
between,
like
the
number
of
packages
like
if
the
users
that
only
have
one
or
two
packages
are
the
ones
that
are
more
likely
to
go
and
check.
If
the
package
is
there
versus
the
ones
with
21
or
more,
if
they
only
go
specifically
to
look
up
versions
of
packages
and
other
things,
because
I
could
see
it
like.
E
From
my
perspective
of
if
I'm
gonna,
like
you
know,
make
myself
a
package
for
the
first
time,
then
I'm
just
gonna
want
to
like
validate
to
myself
that
it
exists
and
like
check
in
three
different
places.
Whereas
if
I
work
at
an
enterprise
company
and
it's
what
I
do
all
the
time,
I'm,
probably
not
going
to
do
that
as
much
yeah.
D
So
we
asked
in
the
survey,
if
you
were
coming
to
check
the
UI
for
the
version
that
you
should
be
using
versus
if
the
CI
built
it
versus,
if
it
uploaded
correctly,
which
were
three
different
options,
all
three
of
them
kind
of
got
equal
responses,
so
they
are
doing
those
three
different
things
reasonably
equal
amount
of
time.
Does
that
kind
of
address
what
you
were
saying?
It's
interesting.
C
D
D
A
D
For
sure,
so,
my
next
step
is
to
take
the
results
of
the
data
from
the
survey,
which
kind
of
give
us
quantitative
data
and
the
interviews
I'm
about
to
do,
which
is
the
qualitative
data
to
look
at
the
current
package.
Experience
and
figure
out
both
kind
of
a
long-term
strategy
of
where
it
can
go,
based
on
how
this
data
is
shaking
out
and
then,
after
that
kind
of
partnering,
with
everyone
to
see
how
we
could
tease
out
individual
issues
to
allow
us
to
do
this.
The
gitlab
way
and
incrementally
move
us
towards
a
different
direction.
A
A
So
I
think
we
could
go
through
where
it's
my
stuff.
Maybe
we
could
just
go
through.
Actually
it's
a
good
time
to
go
through
that
the
epic
expand
our
user
base
by
sorry
someone's
flatlining
in
the
hotel.
Yes,
it's
good
toaster
and
we
can
go
through
this
expand
our
user
base
by
integrating
with
additional
high,
really
highly
requested
package
managers.
So
I
can
share
my
screen
for
a
second.
A
Can
everyone
see
this
issue
or
the
epic
yeah?
Okay?
So
this
we,
you
know
we're
always
receiving
new
requests
for
new
package
managers
and
I
think
it's
important
to
have
a
prioritized
list.
So
you
know
the
goal
is
that
we
have
this
prioritized
and
discoverable
list,
because
we
get
asked
like
several
times
a
week
by
customers
and
by
users
if
what
the
order
is
and
why
and
we
want
to
expand
our
list
of
supported
package
managers
include
the
most
common
programming
lean
languages.
A
So
we
don't
want
to
cover
everything
we
don't
want
to
I,
at
least
as
of
now.
We
don't
want
to
build
exactly
what
Jay
frog's
built.
Maybe
it's
top
10
we'll
see
we'll
see
how
it
goes,
but
if
it's
feeling
like
top
10
might
be
good
and
then
we
want
to
standardize
the
implementation
and
user
experience.
So
that's
something
we've
been
talking
about
in
terms
of
like
naming
conventions
or
what
is
the
three
so
this
one.
Last
week
we
did.
Oh,
my
god,
I'm
still
sorry
guys.
I
am
like
off
my
game
big
time
today.
B
A
A
First,
before
we
start
expanding
into
net
new
integrations,
so
I
think
I'm
gonna
push
new
get
back
a
bit
and
it's
a
little
bit
more
supported
based
on
some
of
the
data
that
Ian
just
shared,
seeing
that
we
just
didn't
get
as
many
respondents
as
we
thought.
So
this
is
a
very
popular
issue
for
us.
It's
our
most
popular
issue
in
terms
of
upvotes,
but
in
terms
of
other
sensing
mechanisms
and
wanting
to
prioritize
availability
and
stability.
A
I
think
we're
gonna
push
this
back
to
twelve
six
I'm
gonna
just
turn
it
136
uploads.
So
that's
a
quick
note
on
that
and
then
there's
a
few
new
ones
that
came
in
and
I
thought
it
would
be
important
just
to
highlight.
We
do
have
Debian
rpm
and
Alpine
and
pac-man
as
the
the
Linux
package
managers
that
people
have
all
requested
for
us
to
integrate
with
and
rpm
and
Debian
would
would
be
for
internal
dogfooding,
and
so
that
to
me
is
important.
A
Alpine
would
help
also
for
dogfooding.
This
request
came
in
from
the
secured
team
recently
as
something
that
they
could
use,
and
then
someone
just
asked
me
about
pacman
and
I
had
never
actually
heard
of
it
before,
but
that
was
another
one
that
I
just
added.
So
all
of
these
three
new
ones
I
set
to
awaiting
further
demand,
because
we
haven't
really
heard
it
too
much
from
customers.
Just
a
quick
update
on
that
then
and
given
I,
know.
A
A
So
the
goal
of
this
epic
is
to
provide
a
consistent
and
delightful
user
experience
by
standardizing
workflows,
improve
navigation,
resolve,
high-priority
UX
bugs
and
improve
our
documentation,
examples
and
templates.
So
a
lot
of
the
things
that
ian
is
very
focused
on
and
I
was
just
came
up
with
some
ideas
for
outcomes
each
out.
A
Each
package
manager
has
the
standard
set
of
features,
and
we
mentioned
some
of
these
last
week,
but
like
authenticating,
the
ability
to
support
multiple
levels,
like
instance
group
and
subgroup,
and
flexible
naming
conventions
for
self-managed
customers,
and
we
also
want
to
reduce
the
set-up,
time
and
integration
time
for
each
package
manager.
So
that's:
okay,.
B
A
Okay,
I
think
when
you
shared
just
chrome,
if
you
switch
tabs,
it
doesn't
like
it.
I've
noticed
no
okay,
so
I
was
just
reading
through
these.
So
this
was
like
how
do
we
have
a
standard
set
of
features
and
how
do
we
reduce
setup
and
integration
time
for
each
package
manager
so
the
it's
kind
of
a
mixed
bag
on
this
epic?
And
we
don't
have
too
many
things,
but
there's
some
things
that
are
coming
up
that
are
maybe
worth
talking
about
so
for
NPM.
We
want
to
support
CI
job
token.
A
This
actually
is
an
interesting
point
of
conversation,
because
there's
a
larger
conversation
going
on
about
extending
our
CI
tokens
that
to
one
be
OAuth,
supported
and
then
two
to
have
like
more
grannie,
more
granular
scopes
so
like.
Instead
of
supporting
API
and
read
registry,
we
could
have
read
container
industry,
read
package
registry,
write,
container
and
rewrite
package,
but
right
container
industry.
A
We
talked
about
maven
support
for
subgroups.
That
would
give
us
subgroup
support
for
NPM
and
for
maven,
which
would
be
nice.
I
would
bring
parity
and
I'm
not
sure
if
we
have
subgroup
support
yet
for
Conan,
but
that's
something
I
would
probably
ask
I,
don't
think
we
do,
but
I
think
it's
a
little
off
the
plan.
A
If
that's
not
on
here,
it
should
be
then
adding
authentication
for
CI
token
to
for
Conan.
We
talked
about
the
naming
conventions
and
actually
I
need
to
go
through
and
from
our
conversation
last
week
and
update
some
if
issues
as
follow-ups
for
talking
about
naming
conventions,
and
then
we
have
project
and
group
level
support
for
for
Conan
for
not
scheduled
for
12:7
right
now
and
then
one
that
I'm
really
interested
in
but
I
think
we
need
to
do
a
little
bit
of
research
on
is
setting
up
the
integrations
with
templates.
A
A
You
just
get
walked
through
a
process.
You
just
fill
in
a
template
and
it'll
automatically
generate
those
files
for
you
and
set
up
your
integrations
later
so
I'm
really
interested
in
this,
and
maybe
that's
something
we
don't
need
to
research.
Maybe
we
just
need
to
look
at
what
informations
being
populated
and
how
can
we
create
this
and
send
this
is
similar
people
want
this
to
be
able
to
auto
provision
required
files
for
maven,
so
it's
very
similar
to
setting
up
the
templates.
A
E
The
idea
of
with
setting
up
the
package
registry
with
templates
like
it
would
be
cool
if
there
was
a
way
to
you
know
it
might,
it
might
almost
interact
with
the
auto
dev
up
side
of
things
where
you
know
you
could
click
a
switch.
That
just
says,
you
know
generate
a
package
for
this
project
upon
pushing
and
then
anytime
you
push
or
or
or
do
something
they
will.
B
Yeah,
that's
what
I
was
thinking
as
well.
I
feel
like
a
lot
of
a
lot
of
people,
use
our
pipelines
to
generate
their
excuse
me
wonderful
voice.
Today
they
generate
talking
containers
as
well
as,
as
obviously
as
sorry
shouldn't
saying,
basically,
but
that's
part
of
the
build
process
being
able
to
do
that
is
like
yeah.
This
is
an
NPM
back
and
she
see
the
check
box
and
then
it
automatically.
It
knows
that
it
is
and
then
generates.
Like
Steve
said,
that's
exactly
what
I
was
thinking.
I
was
gonna,
say
the
same
thing.
E
Now
you
got
it,
I
was
just
gonna
say:
I
got
I,
can't
I,
don't
really
know
in
particular
like
like
I'm,
not
like
you
know.
My
experience
is
like
as
more
of
a
hobbyist
creating
packages
so
or
you
know,
dealing
with
maybe
some
like
fun
open-source
projects
that
I
work
on
so
like
for
me
like
and
maybe
like
you
know,
someone
on
the
end
of
like
I,
don't
know
how
to
create
a
package,
but
I
would
like
my
project
to
be
a
package.
I
could
see
that
just
being
in
the
setting
somewhere.
E
C
Yeah
I'm,
sorry,
you
go
ahead,
I
was
gonna
say:
could
you
there's?
You
could
attack
this
from
two
angles?
Can
you
say
you
could
do
what
Steve
just
suggested
there,
which
I
think
it's
a
good
idea
is
to
have
that
on,
like
the
settings
page
or
even
like
the
project
homepage,
if
it
was
important
enough,
that's
just
a
sort
of
a
toggle
or
something
like
that.
E
Think
that
would
actually
be
really
cool
like
because,
like
the
version
I
was
talking
about,
would
be
more
like
every
time
you
push,
it
creates
a
new
version
of
a
package
or
it
creates
a
new
package
which
a
lot
of
people
might
not
need.
They
might
just
want
to
create
it.
You
know
when
they're
ready
to
create
it,
so
that
can
be
cool.
Unlike
the
packages
page,
they
just
click
the
button
or
or
two,
and
it
creates
it
at
that
time
and
only
at
that
time.
B
B
Maybe
I
have
a
release
version,
a
beta
version
of
whatever
package
I'm
trying
to
create
the
rest
of
my
teams,
and
so
as
they
merge
as
I
merge
my
code
into
one
of
the
branch
that
is,
you
can
enable
a
package
generation
for
that
as
it
merges
and
passes
everything
once
it's
passed,
then
it
would
generate
the
package
automatically.
What
I'm
thinking
about
is
the
idea
of
like
at
least
the
way
I
visualize
it-
and
this
is
where
some
of
this
user
research
and
interviews
really
helpful.
I'm
visualizing
the
situation
when
someone
goes
through.
B
B
It
may
be
desirable,
which
is
fine,
we're
not
precluding
people
from
doing
whatever
they
need
to
do
for
their
workload.
That
makes
sense,
but
having
that
option
of
being
like
okay
master
I'm
gonna
check
a
box,
it
says
auto-generate
on
the
unsuccessful
merge.
It
would
go
ahead
and
run
all
of
that
stuff
and
then
generate
a
new
version
of
the
package
and
then
other
branches.
B
F
Can
I
tell
me
here
I
think
from
the
point
of
view
of
testing
having
packet
generated
on
branch
can
be
useful,
so
sometimes
you
work
with
like
four
or
five
rifles,
and
then
you
are
connecting
them
with
packages.
If
you
can
ship
out
a
package
that
is
like
branch
name
feature
name
and
import
it
in
immediately
can
help
a
lot
like
see
that,
with
a
new
version
of
the
UI
library,
all
the
unit
tests
are
not
broken
or
all
the
integration
Testament
exploding
as
well.
B
A
So
your
idea,
when
you
say,
create
a
new
package,
wouldn't
would
we
have
like
a
they
would
fill
in
all
the
fields,
because
you
know
when
you
create
a
new
package,
an
NPM.
It
walks
you
through
all
the
different
settings
from
the
command
line,
and
so
would
we
offer
like
a
little
like
a
window
and
they
they
fill
in
that
information
as
part
when
they're
filling
that
out.
C
Yeah
I
think
so,
potentially
I
wouldn't
say:
they'd
necessarily
need
to
fill
out
all
the
information.
For
example,
we
might
be
able
to
get
away
we've
just
taken
like
a
name
and
I.
Don't
know,
maybe
like
an
entry
point
or
something
like
that,
or
basically
the
bare
minimum
I,
don't
think
it
need
too
much
stuff
like
I
could
do
a
full
description
or
I
don't
know.
C
We
could
perhaps
even
include
like
an
example
yeah
Mel
file
for
CI,
so
that
it
could
just
like
be
ready
from
the
very
first
commit
to
start
a
pipeline.
That
kind
of
stuff,
so
I
think
there's
a
decent
amount
of
work
that
you
could
do
to
make
this.
Like
creation.
Experience.
Really
really
nice
for
the
end
user.
I
think
you
just
need
to
solve.
We
need
to
spend
a
little
bit
of
time,
just
figure
out
what's
possible
and
what's
actually
beneficial,
so
things
really
so
I
was
gonna,
say.
What
ultimately,
is?
D
Just
gonna
call
out
like
Nick,
that's
a
free
cookie,
which
is
always
great.
Everyone
loves
a
free
cookie,
but
one
of
the
things
we
can
do
is
when
we
have
these
like
great
ideas
and
great
brainstorming
idea
is
that
I
can
actually
quickly
do
some
user
research
to
validate
and
even
generate
some
opinions
from
our
users
about
like
yes,
this
is
something
they
would
use
or
like
yeah,
that
seems
cool,
but
I
probably
wouldn't
use
it.
D
B
I
think
the
other
thing
I
want
to
call
out
here
is
whenever
we're
thinking
about
like
ideas
about
adding
functionality,
is
to
sort
of
also
consider
what
an
MVC
would
look
like
like
try
to
come
up
with
a
simplest
version
of
what
it
is
to
provide
that
the
core
value
that
we're
trying
it
buildin,
we
can
all
discuss
what
that
core
value
is
in
my
head.
It's
just
avoiding
this
process,
someone
uploading
and
you
know,
building
it
themselves
and
then
pushing
something.
It's
like
you,
don't
really
need
a
people
to
do
that.
B
So
I
think
in
my
head
at
least
having
some
pre-built
pipeline
step
that
you
could
just
plug
into
your
pipeline.
That
seems
like
a
real,
simple
way
to
do
it.
I,
don't
know
if
that's
actually
the
minimum
viable
change
that
we
would.
We
could
provide
to
people
to
do
that,
but
that's
kind
of
just
an
example
of
the
way
you
might
at
it.
A
So
if
I'm
understanding
it
correctly,
there's
like
a
few
different
pieces
of
that
so
I'm
just
trying
to
repeat
back
to
make
sure
I
understand
it.
True
and
there's
the
idea
of
setting
up
your
overall
I
want
a
maven
repository
or
an
NPM
registry
and
get
lab
and
so
set
some
template
to
be
able
to
ease
that
where
you
would
set
up
your
NPM
or
C
or
your
settings
file
and
it
would
it
would
live
there.
Then
there's
the
idea
of
creating
packages
and
having
a
template
for
that.
A
So
you
could
say,
create
new
package
and
we
walked
the
user
through
how
to
do
that
and
then
there's
the
integration
with
Auto,
DevOps
and
pipelines
like
how
could
we
figure
out
how
now
that
you
have
build
packages?
How
can
you
most
easily
make
sure
that
your
pipelines
are
picking
those
up
and
making
those
changes?
Is
that
do
I,
miss
anything
just
know.
B
There
was
a
double
thumbs
up.
Yes,
you
totally
missed
something
for
me
and
I.
Don't
take
you
missed
anything
I,
I,
think
I.
Think
I
still
like
I
think
with
all
that
said,
like
just
identifying
the
shortest
path
here
to
provide
this
value.
I
think,
while
I
think
that,
having
the
reason
user
research,
that's
so
good,
such
good
value,
because
we
can
actually
target
the
right
ideas
like
this
might
I
think
it
sounds
like
a
great
idea.
It
seems
like
we
all
think
this
is
a
great
idea.
B
Do
I
users
think
it's
a
great
idea
and
is
that
the
best
way
we
can
add
value
to
our
users,
given
where
the
teams
at
and
we're
still
growing?
Maybe
we
don't
have
the
capacity
to
do
some
of
these
things
right
now.
Maybe
we
do
I'm
not
be
done,
but
looking
at
this
and
saying
well,
how
can
we
sort
of
float
this
as
an
idea,
I?
Think
we'd,
like
you
called
out
earlier,
you
know
prioritizing
security
and
availability
over
velocity,
pretty
quick
depending
on
what
you
want
to
call
it.
B
A
What's
in
the
epics
but
shifting
the
conversation
towards
okay,
we
have
a
few
things
that
we
want
to
discuss
like
how
do
we
ease
the
setup
and
creation
of
packages
and
we
could
talk
about
10
ports
and
things
like
that
or
I
know
Nick.
You
had
topics
that
you
wanted
to
talk
about
that
I
kind
of
punted
on
to
in
favor
of
going
over
the
epics
things
like.
How
do
we
do
NPM,
dogfooding,
internally
and
I'm
sure
there's
some
other
things?
A
C
I
think
it's
a
good
idea,
I'm
pretty
happy
to
fill
up
a
document
with
ideas.
That's
that's
not
difficult
at
all.
Is
whether
or
not
they're
worth
discussing
so
say,
yeah
I,
don't
mind,
taking
a
look
at
like
next
week's
document
and
just
put
like
a
dump
of
all
my
ideas
and
force
in
there
and
then
like.
C
B
I
think
a
combination
of
looking
at
what
we
should
prioritize
from
a
product
standpoint.
Then
we
can
filter
those
ideas
down
and
ideas
that
we
have
other
thing,
as
necessarily
needs
to
be
synchronously
there,
particularly
equipments.
They
just
know
them
down
at
a
document.
I
do
want
to
be
aware
that,
like
our
synchronous,
time
should
be
used
sparingly,
given
how
much
overlap
we'll
have
at
some
level
and
and
when
we
have
overlap
with
Europe
from
the
US
side.
B
You
know,
obviously
it's
difficult
for
Gigi
to
be
involved
and
I'm,
okay
to
say,
obviously
in
this
particular
case,
so
like
I,
think
that
might
be
worth
discussing
asynchronously
at
least
and
then
taking
those
things
and
ordering
them
in
terms
of
our
product
priorities
and
some
of
the
research
that
we're
getting
as
well
from
Ian,
and
then
we
could
certainly
discuss
those
ideas.
I
think
the
other
thing
we've
got
to
think
about.
B
B
So
the
other
thing
we
should
maybe
be
thinking
about
as
well
as
like
we
have
a
bunch
of
different
bugs
that
we
need
to
start
addressing
prob
continue
to
address,
because
we're
already
going
at
home
I
mean
we
asked
them
all
sort
of
some
product,
Direction
ideas,
so
an
example
might
be
the
stuff
that
Steve's
kind
of
got
turning
over
in
his
head
about
how?
How
if
and
how
much
we
make
generic
how
various
package
managers,
if
you
know
how
sure
how
we
integrate
technically
with
our
dependency
proxy
as
it
comes
online.
B
You
know
we
want
to
do
more
than
just
the
layers
in
Dhaka.
We
also
want
to
have
a
dependence
in
proxy
working
for
packages
as
well.
You
know
so
there
it's
had
some
technical
conversations.
We
could
have
I,
don't
know
if
this
is
the
forum
for
that
conversation,
just
because
I
one
is
to
be
sort
of
more
of
a
product.
B
A
Would
love
it
if
we
were
talking
about
some
of
those
technical
discussions
here
as
well,
because
I
think
that
is
part
of
it
right
like
whether
or
not
we
you
know,
use
the
dependency
proxy
for
all
of
our
integrations
like
that.
That
is
talking
about
our
direction
for
where
we
want
to
be
in
a
year
or
two
from
now
so
I
think
that
would
be
a
fun
awesome.
Conversation
I
love.
That
idea,
then.
B
B
A
E
A
Like
we
could
set
up
an
p.m.
audit,
we
could
set
up
like
the
dependency
graph
or
for
NPM
could
work
without
getting
to
like
the
full,
approved
and
banned
lists
of
packages
and
and
some
of
those
more
advanced
features.
So
we
might
be
able
to
take
a
step
in
that
direction,
but
really
getting
to
that
I
think
is
a
bit
far
away
because
we
have
a
bunch
of
container
registry
stuff
to
change,
and
then
we
have
some
probably
at
least
another
integration
or
two
to
two
handle
and
then
the
dependency
proxy.
B
You
know
how
we
integrate
that
with
our
existing
securities
tools
and
when
how
much
and
what
that
looks
like
and
that
will
rely
on
some
conversations
or
would
probably
be
best
served
by
some
conversations
with
our
security
team
right.
So
you
know
we
have
a
dashboard
that
shows
us
the
security
concerns
with
the
code
versions,
licensing.
You
know
any
other
holes
that
might
be
in
the
code.
Does
that
sort
of
report
belong
in
that
screen?
Is
it
tied
to
and
having
certain
tiers
of
the
product?
B
Question
mark
question,
mark
question
mark
so,
like
I
think
there's
some
fairly
big
things
that
decide
before
we
can
start
trying
to
execute
on
it
without
just
doing
a
sort
of
a
straight
up
NDC
of
some
of
the
things
you
suggested,
which
I
think
can
be
happening
in
parallel,
so
that's
kind
of
where
I'm
like
you
know,
and
it's
just
I
feel
like
this
is
stuff
that
we
need
to
be
at
least
starting
to
put
on
our
radar,
if
not
having
a
serious
chat
about
it.
So
I.
A
Just
thought
I'm
time
for
me
and
Nicole
Schwartz
who's
the
product
manager
on
that
side,
so
we're
starting
the
conversation
at
least,
but
it's
pretty
casual
right
now.
It's
just
having,
like
all
of
the
question
marks.
You
just
said
just
to
get
those
out
of
the
way
and
then
we
could
think
more
about.
Where
do
things
belong
and
how
do
we
plan
that
work?
Yeah.
B
B
E
My
perspective
just
add
on
like
the
idea
of
this
meeting
going
forward,
like
I
really
do
like
you
know,
maybe
like
bi-weekly
or
something
until
we
ran
out
of
stuff
to
talk
about,
but,
like
certainly
I,
think
priority,
it
should
play
and
do
it
but
I
think
as
the
idea
of
this
sort
of
just
being
like
a
big,
like
you
know,
like
vision,
type
meeting
like
I
like
what
we
did
where
we
just
kind
of
like
brainstorm
about
like.
Maybe
this
will
happen,
maybe
it
won't.
A
E
A
Like
ya,
sorry,
if
we
can,
if
we
write
our
writing
down
these
issues
in
this
document,
like
I,
may
change
the
format
of
this
document.
Now
that
we've
gone
through
the
epics
and
we
write
down
a
bunch
of
ideas
for
things
that
we
can
review
and
throughout
the
week
we
could
like
this
truce,
agile
way
would
be
like
we
would.
A
Each
add
boats
like
+
well
and
I
want
to
discuss
this,
but
I
want
to
hear
more
about
Steve's
idea
after
this
or
Nick's
idea
for
this
and
then
we'll
just
prioritize
those
in
these
meetings,
cuz,
I,
I,
I'm
sure
you
know
we
all
have
ideas,
but
getting
them
out
there
and
talking
about
them.
I
think
would
be,
will
be
really
valuable.
I
love
these
I've
loved
these
meetings.
Aside
from
my
you
know,
going
over
the
same
epic
multiple
times
not.
B
Area
the
one
thing
I
want
to
sort
of
remind
everyone
off
and
I
conclude
myself
in
this
reminder,
because
also
people
the
having
these
freeform
discussions
is
great.
If
we're
not
putting
an
issue
in
a
place
or
doing
something
with
this
information.
What
you're
not
really
doing
is
a
very
good
lobby
way,
so
I
would
definitely
encourage
people
like
it's
cool,
to
have
like
really
simple
ideas
and
I'll
call
that
neck
just,
but
you
know
whatever
it
could
be
myself
too,
because
I've
suggested
an
idea
as
well
right.
B
You
know
you
don't
have
to
make
it
all
pretty
formatting
and
stuff
you're
welcome
to,
of
course
like,
if
you
don't
have
to
like,
if
we
don't
get
these
things
down,
as
in
in
an
issue,
format
in
hand,
book
format
and
something
like
that,
we're
kind
of
doing
our
own
thing
and
it's
we're
at
risk
of
losing
all
of
these
ideas
and
thoughts
that
we
have
and
and
it
means
that
other
people
can't
participate
and
can't
contribute
to
those
conversations,
because
it's
only
whoever
gets
invited
to
the
meeting.
So
I
really
want
to
caution
everyone.
B
Instead
of
when
we're
thinking
about
these
things,
you
know,
let's
think
about
them
in
terms
of
let's
go,
create
an
issue
and
again
it
doesn't
have
to
be
super
hardcore.
It
just
could
be
real,
simple
here's,
my
idea,
you
know
a
sentence
or
two
about
it.
Boom
created
the
issue
and
then
share
it
with
everyone,
and
that
could
be
the
link
in
the
document
we
chat
about,
but
let's
sort
of
have
a
chat
around
our
bread
and
butter.
B
If
I
just
know
I'm
not
one
to
be
like
you
got
to
do
this
or
else
but
like
this
is
one
of
those
things
that
it's
kind
of
like
I'm,
pretty
sure.
If
Sid
saw
that
we
had
these
random
documents,
all
this
stuff
in
it
he'd
be
like
come
on,
and
he
wouldn't
say
it
was
a
funny
Australian
accent
and
a
terrible
cold
either.
C
B
When
you
have
ideas
that
relate
to
what
our
our
customers
and
the
rest
of
Giller
because
remember
we're
all
using
our
own
product,
those
should
be
in
our
standard
product
and
they
don't
have
to
live
forever.
They
can
be
like
thrown
away.
The
internal
team
discussion
forum
is
meant
to
provide
people
a
space
where
we
can
float
ideas
that
are
crazy
about
how
we
do
stuff
and
have
the
team
functions.
B
So
what
what
process
should
use
to
capture
these
ideas
is
an
example
of
an
issue
we
might
put
inside
our
team
project
and
it's
really
it's
closed
off
from
everyone
else
and
I'm,
not
a
huge
fan
of
that,
but
I
think
it's
helpful
because
I
want
people
to
feel
comfortable
that
you
know
someone's,
not
gonna,
just
randomly
show
up
from
some
of
the
team
and
go.
Why
would
you
think
about
this
is
stupid
or
whatever
not.
B
A
Yeah-
and
you
could
always
create,
like
Dan
said-
create
an
issue
with
just
like
a
summary
and
send
it
over
to
me
and
Ian,
and
we
can
both
we'll
flush
it
out,
we'll
get
it
scheduled,
we'll
make
sure
labels
are
added,
like
it's
really
just
to
make
sure
your
ideas
are
captured
somewhere,
not
that
you're,
like
writing
issues,
and
you
know
adding
in
all
those
details.
If
you
want
to
you
ever
like
really,
you
want
to
write
out
all
of
your
thoughts.
That's
great,
but
I.
Think
a
good
action
item
could
be
like.
A
We
talked
about
this
idea.
That
comes
up
it's
an
action
item
in
the
document
and
we
have
to
create
an
issue
as
a
follow-up
of
that.
So
yeah
I
think
I
think
that's
a
good
call
out
then,
and
something
we
haven't
done
yet,
because
mostly
we've
been
reviewing
issues
that
are
already
created
but
like
Nick,
created
and
shared
this
in
four
changes
to
the
package
registry-
and
we
created
a
bunch
of
front-end
issues
from
that.
Although
we're
probably
ready
to
create
some
more
neg
and
yeah
I.
A
E
Was
curious
need
to
asked
about
labeling
and
so
anytime
I've
created
new
issues
that
are
kind
of
like
you
know,
either
a
technical
debt
issue
or
just
like
a
new
something
I
noticed
that
we
should
probably
do
issue
I,
just
throw
on
the
DevOps
package
and
a
group
package
labels
do
do
you
get
notified
or
does
someone
get
notified
when
new
issues
are
created
with
those
labels?
I
was
kind
of
curious,
yeah.
A
B
And
the
distinction
between
those
two
labels
is
that
group
group
package
refers
to
the
our
team,
and
devops
package
refers
to
the
actual
code
base
that
relates
to
the
areas
of
code
that
we
handle.
So
if
you
are
creating
an
issue
that
is,
you
know,
let's
just
say
for
randoms,
for
example
sake
we
were
going
to
work
on
something
that
wasn't
one
of
our
sort
of
areas
of
the
product
you
would,
it
still
might
have
that
box.
B
What's
what
you're
not
sure
about-
or
you
know,
discuss
fleshing
out
the
idea
as
to
mention
but
like,
but
you
could
put
it
in
the
async
the
document
for
our
team
meeting
so
that
if
you
just
be
raised,
it's
like
hey
I
created
this
issue.
I
thought
this
is
something
worth
discussing
and
then
we
can
figure
it
out
that
sound
good
Tara.
A
Take
I'll
just
say:
thank
you,
thanks
for
spending
time
and
I
do
really
enjoy
these
meetings
and
talk
chatting
with
you
all
and
I'm
looking
forward
to
keep
having
them.
So
maybe
we'll
switch
them
to
every
other
week
and
see
how
that
goes,
and
we
can
always
adjust
further
and
I'll
work
on
updating
that
the
agenda
Docs
and
make
two
so
that
we're
not
just
talking
about
the
epics
and
I'll,
send
it
out
and
just
people
can
add
in
their
ideas
for
the
subsequent
meeting.
B
And
the
other
thing
you
can
do
here
that
just
occurred
to
me.
Sorry
Tim
was
you
know
we
could
start
thinking
about
this
time
is
doing.
Demo
is,
if
we
don't
have
anything
specific
I
think
we
want
to
get
into
because
I
know
we've
been
flooding
the
idea
of
demos
in
various
capacities,
capacities
for
a
while
and
I
think
they
would
be
see
the
valuable
like
me
saying
how
a
frog
works.
You
know
when
everyone
gets
to
look
and
see
how
that
it's
together
and
sessions
would
be
kind
of
cool
I.
F
Can
I
ask
something
regarding
demos,
I
think,
especially
now
that
you
have
a
new
engineer
joining
like
a
global
demo.
The
fool
that
I
work.
A
lot
for
example,
I,
would
have
benefited
a
lot
if
I
would
have
seen
from
the
dancing
cells
like
the
full
package,
instead
of
just
discovering
bits
by
bits
by
my
own
I.
Think
it's
a
bit
slower,
yeah.
B
I
understand,
agree
and
I.
Think
that's
why
Tim
created
an
issue
agency
go
in
that
team
project.
That's
why
I
created
another
issue:
cuz!
No
one
actually
was
nice
enough
to
actually
give
sym
feedback
on
his
idea,
and
this
is
going
to
happen
soon.
We're
gonna
start
doing
demos
and
have
the
purpose
of
the
demo
and
the
format
of
the
demo
is
up
for
discussion.
B
I
think
whether
it's
the
intention
of
like
a
is
our
an
area
of
ours
works,
whether
it's
dog
treating
and
saying
here's,
what
I
do
a
thing
and
they're
calling
bonds
out
of
that
process
for
issues
or
whatever
there's
plenty
of
reasons
you
do
demos,
one
of
it
might
be:
hey
I
finished
this
thing.
It
looks,
awesome,
I'm,
really
stoked
on
it
check
this
out.
You
know
that's
what's
for
tea
right,
so
this
is
a
couple
of
different
reasons.
Why
we
do
demos
I
think
we
need
to
do
them.
Let's
discuss
it.