►
From YouTube: Package ThinkBIG: 05-13-20 (partial recording)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
So
we
have
think
big
think
big
updates,
which
are
always
exciting.
We
have
two
different
content
coming
up
for
think
big
to
help
some
other
teams
and
get
lab
as
well
as
even
people
outside
of
the
company
utilize.
This
is
a
tool
to
help
teams
align
on
vision,
so
we
have
two
of
them.
One
of
them
is
a
blog
post.
That's
gonna
go
on
unfiltered.
This
is
gonna
focus
on
the
story
of
how
we
came
together.
B
We
think
big,
the
iterations,
how
it
aligns
with
get
lab
values,
despite
being
a
synchronous,
meeting
and
stuff
like
that,
and
then
the
other
is
a
single
source
of
truth.
Definition
in
the
handbook
of
what
think
big
is
so
reason.
I'm
sharing
with
all
of
you,
is
a
it's
exciting
because
it
means
this
idea
is
expanding
and
going
to
other
teams,
because
we
have
had
some
successes,
she's
always
really
powerful.
B
The
other
is
that,
as
members
and
contributors
of
think
big
for
quite
a
while
now
I
was
hoping
to
get
some
insights
from
all
of
you
around
what
kind
of
content
or
learnings
that
you
should
be
included
in
these
two
articles.
What
are
things
that
we
did
that
didn't
work
very
well?
What
are
things
that
we
do
that
work
very
well
and
should
be
emphasized
stuff
like
that,
so
feel
free
to
jump
into
either
of
the
issues
or
the
merge
requests
that
are
posted
in
the
agenda.
B
To
add
that
information
I'd
really
appreciate
it,
I'm
hoping
to
get
the
content
out
in
the
next
week
or
two,
so
other
teams
can
start
to
use
it,
which
will
be
really
exciting
and
I.
Think
I
also
have
the
next
update.
Yes,
research,
I
love
research,
and
we
all
know
that
the
user
validated
jobs
to
be
done
are
out
and
they're
in
the
wild,
which
is
really
exciting.
So,
as
many
of
you
know,
we
did
a
survey,
we
asked
our
users.
Are
these
the
things
you
care
about?
How
important
are
they
to
you?
B
Can
you
stack
rank
them
things
like
that,
and
we
completed
it.
We've
shared
it
out
with
some
other
UX
teams
through
the
UX
showcase
and
they
were
received
really
positively.
So
we
know
from
our
users
that
our
jobs
to
be
done
or-
and
we
know
from
kind
of
the
strategy
side
to
get
lab-
that
the
way
we've
built
them
and
structured
them
have
matches
the
way
that
we're
doing
them.
B
I
think
my
prediction
is
that
as
we
move
forward,
they
will
become
more
of
a
staple
in
the
product,
design
and
product
management
world
for
measuring
our
success
with
heuristics
about
evaluations,
as
well
as
understanding
places
that
we
can
innovate.
We
also
major
props
to
Nico,
Tim
and
I.
Have
both
works
on
two
different
em
ours
to
add
them
to
the
handbook
and
Tim
spend
quite
a
bit
of
time
and
I
spend
way
more
time
than
I'd
like
to
admit
and
almost
threw
my
laptop
out.
B
The
window,
I
was
so
frustrated
and
then
Nico
came
in
at
about
eight
seconds
made
it
perfect,
which
was
great.
So
thank
you
very
much
Nico
for
making
the
job
Sibylla
look
good
in
the
handbook.
We
shared
it
all
with
the
release
management,
as
well
as
the
growth
teams
who
are
also
working
on
their
job.
So
we
done,
then
they
really
liked
the
formatting.
It's
nice:
it's
easy
to
look
at
really
really
good.
B
The
most
important
job
story
for
our
jobs
to
be
done,
revolved
around
CI,
so
the
most
important
thing
to
our
users
is
that
when
they
push
a
commit
or
merge
a
merge
request
that
everything
Auto
magically
happens
and
it
gets
added
to
the
registry.
So
that's
something
we
should
pay
specific
attention
to
when
we're
thinking
about
stability
as
well
as
just
what
that
experience
is
like
for
setting
it
up
or
confirming
that
it
built
the
way
we
wanted
it
to
I.
B
Think
I've
shared
this
before,
but
there's
eight
unique
insights.
If
you
want
to
go
into
the
issue
for
our
user
validation,
for
the
jobs
to
be
done,
and
you
can
kind
of
see
the
architecture
and
the
insights
that
we
gathered
from
that
about
why
they
were
thinking
what
they
were
thinking
a
couple
of
both
quotes
as
well.
So
this
is
really
exciting
stuff.
Any
questions
about
the
talks.
Are
you
done?
We're
move
on
to
the
other
research.
B
B
This
is
a
problem
space
that
is
a
little
ambiguous
in
certain
areas,
because
the
way
your
organization
is
structured
or
even
the
size
of
your
organization
really
influences
how
you
would
want
to
connect
to
remote
repositories
compared
to
the
gitlab
repository
and
what
they
want
from
their
virtual
repository
I'm,
going
to
go
through
the
process
of
creating
individual
insights,
but
here
are
kind
of
a
list
of
the
major
things
that
Tim
and
I
heard
and
I'll
just
go
through
them.
Our
current
naming
conventions
won't
scale
for
a
lot
of
our
customers.
B
We
need
to
have
it
more
flexible
so
that
they
can
directly
interact
with
their
party
package
managers
without
having
to
completely
redo
their
systems
and
their
setups.
So
one
of
the
things
we
discovered
was
really
important
is
that
when
you
have
a
large
organization
with
many
business
units
with
many
best
tech
teams,
they
don't
want
to
be
prescriptive
and
say
you
have
to
use
this
container
registry.
They
want
us
or
this
package
registry.
B
They
want
a
solution,
that's
flexible
enough
to
evil,
to
accommodate
anything
they're
currently
using
and
create
a
better
experience
on
gitlab
and
the
naming
conventions.
Just
don't
quite
a
lot
for
that
right
now
we
discovered
the
project's
had
a
pretty
solid
50/50
mix
between
public
packages
or
open
source
packages
and
private
custom
build
packages
which
helps
us
kind
of
scale.
Some
of
those
things
the
number
one
thing
we
kept
hearing,
especially
from
the
DevOps
managers,
is
that
developers
don't
want
to
think
about
how
packages
dependencies
are
resolved.
B
A
I
add
a
note
on
the
previous
item:
Ian,
which
was
the
50-50
mixture
that
did
change
from
interview
to
interview.
Sometimes
it
was
6040.
Sometimes
it
was
50/50
on
average
and
I
should
say
that
for
the
private
packages
there
are
four
public
packages.
Rather
sometimes
those
were
hosted
in
things
like
like
MP
MJ
s
comm,
but
also
some
customers
mentioned
that
they
pay
like
a
consulting
company
to
put
up
a
private
s3
server
somewhere,
that
has
packages
that
were
specifically
built
for
them.
So
it's
accommodated
it's
not
just
coming
from
them.
B
Where
was
I
motto,
repose
will
scope
packages
based
on
the
feature
level.
This
is
an
insight
that
just
kind
of
helps
us
understand
how
scopes
work
for
different
organizations,
so
bringing
it
down
to
the
feature
level
helps
us
understand
how
they
are
going
to
break
it
up.
Users
really
do
want
that
universal
endpoint.
They
would
like
to
be
able
to
call
get
lab
and
say
I
want
this
package
and
forget
lab
to
figure
out
where
it
is
based
on
the
list
of
repositories.
B
They
have
and
they'd
like
that
for
all
the
different
package
managers
again,
this
kind
of
bleeds
into
the
they
don't
want
their
developers
to
have
to
deal
with
solving
this
problem
instead
focus
on
building
great
stuff
for
their
customers.
We
heard
that
whether
it
was
an
engineering
manager
or
a
DevOps
manager
or
even
a
system
architect,
we
kind
of
heard
that
same
threat
over
and
over
again
users
care
more
about
caching,
for
stability
than
pipeline
performance.
B
I
walked
in
to
this
conversation
with
the
hypothesis
that
it
was
really
important
that
pipelines
are
faster
because
they
get
charged
per
minute,
and
they
only
have
so
many
of
them.
I
was,
it
was
not
as
important.
The
thing
that
mattered
most
to
them
is
if
NPM
goes
down.
I
don't
want
my
bills
to
suddenly
start
failing,
which
is
a
story
we
heard
from
one
of
our
users
of
the
maintainer
of
a
third
party
package
took
it
down
to
rename
it
and
for
a
good
two
hours.
B
We
couldn't
build
anything,
and
so,
if
we
had
a
customer
complain
or
something
we
needed
to
push
immediately,
we
were
just
stuck
and
had
no
way
around
it
with
caching.
We
would
have
the
ability
to
keep
moving
forward,
even
though
this
third
party
went
down,
so
that
was
what
was
really
important
to
them
and
that
kind
of
changed
my
perspective
around.
Why
the
caching
is
so
important
for
them
scanning
in
security
there's.
B
Another
big
thing
that
kept
coming
up
is
especially
for
the
really
large
organizations
they
wanted
to
be
able
to
to
say
this
is
a
block
list
of
packages,
and
we
don't
want
where
these
are
licensed
types
that
we
don't
want.
We
also
heard
the
opposite
of.
We
want
the
approved
license
types
or
you
know
be
able
to
restrict
it
in
some
way
so
being
able
to
pull
in
and
from
everywhere,
through
gate
lab
and
then
have
Caleb
say
this
is
approved.
This
isn't
approved.
B
This
is
you
should
check
it
kind
of
idea
came
out
quite
a
few
times,
based
on
all
the
research
we
created.
Tim
creative
I
didn't
take
credit
for
this
one.
An
investigation
issue
for
I
think
13
one
for
us
to
really
look
at
the
type
of
technical
implementation
of
what
it
means
to
create
these
repositories.
What
you
just
want
think
about
how
the
UI
should
be
set
up
so
I.
C
B
C
B
C
If,
if
not
a
design,
at
least
of
what
capability
that
we
want
to
give
to
the
user
so
like
this
is
a
system
that
can
be
like
on
the
go
working
on
his
own
just
back-end
code,
but
we
may
want
to
give
some
control
and
oversight
to
the
users.
So
maybe
we
want
to
list
those
so
forth
their
front.
End.
Research,
it's
easier,
makes
sense.
I.
A
Think
what
you're
saying
is
that
we
should
at
least
make
sure
that
the
user
actions
that
they
could
take
are
well
defined
so
that,
when
we
think
about
about
the
back
end
in
front
end,
that
we
have
clear
definitions
of
what
they
could
do,
yeah
I
think
we
could
do
that.
That
actually
is
surprisingly
missing
from
that
investigation
issue,
I
define
that
I
went
and
was
thinking
more
about
the
API
that
we
built
for
the
backhand,
but
not
necessarily
in
terms
of
user
actions.
I
think
we
could
add
that
in.
C
A
B
A
A
E
I
just
wanted
to
clarify
what
the
universal
endpoint
is
referring
to.
Is
that
just
a
single
URL
that
any
package
manager
any
package
manager
can
just
pull
from
and
like
the
end,
the
endpoint
will
be
smart
enough
to
work
out
what
type
of
package
is
being
pulled
or
is
that
something
slightly
different?.
A
I
think
it
would
be
limited
to
package
format,
so
it
wouldn't
be
like
one
endpoint
and
it
could
resolve
NPM
and
maven
packages,
but
you
would
have
one
you.
You
could
create
one
grouped
endpoint
that
would
resolve
all
of
the
different
and
like
endpoints,
that
are
grouped
within
it.
So,
for
instance,
you
could
set
up
like
NPM
private
one
NPM
private,
to
NPM
public
one
and
and
public
to,
and
then
you
could
group
those
in
order,
whatever
order
you
behind
one
endpoint
and
it
will
know
to
go
through
the
list
of
for
any
order.
A
A
E
A
D
I'm
not
doing
if
there
is
a
way
we
could
use
the
same
prefix
for
all
package
managers
so
like
right
now
we
have
the
prefixes
all
defined
and
we're
course
of
the
different
endpoints
that
we
can
accept
and
they
all
like
include
like
slash,
maven
or
slash
NPM
I,
wonder
for
a
given
project,
for
example.
If
we
could
just
have
it
be
like
project
packages
and
then
use
that
for
all
package
endpoints
and
then
allow
users
to
be
able
upload
any
package
type
like
just
kind
of
thinking.
I,
don't
know
if
that's
possible.
C
C
D
F
A
C
It
is
common
I
mean,
even
even
as
we
use
JavaScript
and
Ruby
right.
So
we
have
that
right.
Npm
package,
okay,
Ruby
gems,
but
but
my
question
is
when
we
talk
about
Universal
endpoints,
we
are
not
really
talking
about
an
end
point
for
all
the
package
type
but
more
like
one
entry
point
for
all
the
registry
locally
and
external
and
third-party
in
whichever
right
or
emmys
understood
this
part.
B
C
B
Then
lastly
go
see:
if
it's
in
npm,
then
they
wanted
to
be
able
to
organize
it
and
Tim.
Correct
me
if
I'm
wrong,
I
believe
that,
based
on
each
package
type
could
also
change
the
different
ways
that
they
want
to
navigate
that
and
order
the
priorities.
So
that
might
be
another
reason
we
might
want
to
make
them
different
per
package
type.