►
From YouTube: Package group: ThinkBIG 07-08-20
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
think
big
is
becoming
official,
more
official
we're
adding
a
handbook
page
in
the
UX
Department.
You
can
check
out
the
merge
request
and
review
app
feel
free
to
take
a
look
and
provide
any
feedback
on
how
other
teams
could
use
think
big
and
how
to
be
successful,
and
you
know
things
that
we
should
avoid
stuff
like
that,
so
feel
free
to
jump
into
that
next
up,
I
think
is
Tim
cool.
A
Just
well,
this
is
more
of
a
just
a
quick
update
on
some
of
the
work
that
we're
doing
on
the
problem
and
solution
validation.
So
if
we
were
planning
on
doing
solution,
validation
for
the
dependency
proxy,
this
iteration,
but
it's
been
really
challenging,
recruiting
people
so
we're
working
with
the
account
managers
and
sales
to
try
and
work
with
our
existing
customers.
To
do
this,
as
well
as
reaching
out
to
people
on
the
issues
and
for
13-3
we're
working
on
the
problem.
A
Validation
for
more
granular
permissions
for
the
container
registry
and
some
frequent
requests
that
we
hear
from
customers
saying
that
they
want
to
have
more
fine-grained
control
and
it
seems
like
as
where
we
architecting
things.
It
might
be
a
good
time
to
revisit
this
and
then,
after
that,
we'll
focus
on
sharing
and
discovery
and
really
trying
to
zoom
in
on
the
inner
sourcing
problem
for
sharing
images.
So
it's
kind
of
what
we
have
lined
up
in
terms
of
validation.
Any
any
questions
on
that
yeah,
okay,
I'm
dating
and
then.
B
Equally
quick
highlight
and
updated
about
what
we've
been
doing
on
the
design
side.
This
milestone
has
been
very
busy
and
we
made
a
lot
of
progress
in
a
lot
of
different
directions.
One
big
thing
is
that
Maria
on
the
configured
team
is
working
on
a
design
for
a
new
registry.
It's
going
to
start
with
terraform
and
include
that
infrastructure
is
code
modules.
I.
Think
puppet
is
another
example
of
what
could
go
in
there.
B
Another
thing
we're
working
on
is
the
package
registry
UI
polished,
we've
been
working
on
it
for
quite
a
while
now
and
made
a
bunch
of
changes,
and
so
we're
going
through
from
a
design
view
and
trying
to
just
polish
it
and
refine
it
to
make
it
look
even
better
than
it
already
does
some
light
weight
issues
are
as
easy
as
there's
this
line
in
here
that
we
don't
need
it
to
be
there
anymore.
Let's
remove
it.
B
We
got
some
feedback
from
our
users
and
it
wasn't
quite
clear
all
the
time
what
they're
doing
with
the
expiration
policy-
and
it
has
a
really
big
impact
on
the
organization,
so
we're
working
on
refining
the
UI
make.
It
is
absolutely
crystal
clear
as
possible.
So
if
you
have
any
experience
with
cleanup
policies
or
anything
close
to
that,
please
dive
into
that
issue
and
provide
as
much
feedback
as
you
can.
A
B
B
B
B
At
the
first
thing,
we
have
this
history
section
which
tells
you
how
the
package
was
created,
the
install
commands
underneath
it,
and
then
we
have
additional
metadata
where,
depending
on
the
package
type
there's
additional
pieces
of
information,
I
think
nougat
has
a
license.
Url,
for
example,
we're
going
to
be
putting
that
into
this
additional
metadata
section.
We
cleaned
up
the
files
and
are
trying
to
make
it
look
a
little
bit
more
modern
and
then
at
some
point
in
the
future,
add
their
readme.
B
C
B
B
A
D
B
That's
a
really
good
point:
I,
don't
know
if
it's
really
necessary
to
include
in
there
considering
that
the
project
name
would
in
theory,
be
up
here.
The
only
reason
I
put
it
in
there
originally
was.
If
you
are
looking
at
a
group
and
then
you
click
on
a
detail,
it
would
be
nice
to
see
the
project
name
but
I'm,
not
sure
if
that's
necessary,
the
good
look
at
moving
that
out.
D
E
B
That's
a
good
piece
of
feedback,
we've
gotten
data
that
shows
us
both.
If
the
pipeline
is
included
in
history,
that's
the
most
important
thing
that
they
will
look
at
to
understand
what
happened
with
this.
If
there
isn't
a
pipeline,
then
what
you're
saying
is
100%
correct?
They
just
want
the
install
instructions
in
Sivan,
so
I
have
moved
them
back
and
forth
about
a
hundred
times
and
have
never
picked,
which
one
is
actually
better
got.
E
B
F
C
B
A
We
don't
see
any
drop
off
really
for
the
container
registry
either
like
for
people
clicking
the
button
like
there's
a
very
high
success
rate
of
people
that
expand
it
and
then
still
copy
something.
So
it's
originally
I
would
have
responded
and
said
well.
Are
we
concerned
about
people
getting
to
it,
but
it
seems
like
for
the
container
registry
they're
doing
it.
No
problem.
B
B
A
Think
mine's
less
of
a
question
about
this
design,
but
I
see
the
history
here
and
I'm
I'm
wondering
there
is
this:
does
this
also
show
up
in
the
get
web
activity
feed,
or?
Is
that
something
that
we
would
need
to
address
separately.
B
So
from
a
design
standpoint,
I
pulled
this
from
an
issue
history.
So
if
you
look
or
a
merge
request
is
a
better
example
and
you
add
a
commit
and
there's
a
timeline
that
happens
similar
design
in
terms
of
the
Activity
Feed
I,
wonder
if
it
would
be
useful
for
users.
If
we
add
this
like
publish
to
the
registry
as
an
event
in
the
Activity
Feed,
but
I'm,
not
quite
sure
if
the
rest
of
the
data
would
be
worked
at
high
level
of
importance.
B
E
F
A
small
note
about
the
previous
comment
about
the
updated
history
event,
for
example
on
Navin
packages.
We
can
just
upload
new,
not
new
versions,
but
you
can
upload
new
archives
for
the
same
package,
name
and
same
version
and
the
files
just
get
appended
to
the
package
and
at
an
update,
and
there
isn't
any
limit
to
that.
So
you
could
be
having
a
date
event
update
and
trace
us
as
much
as
as
many
as
you
want.
F
Otherwise,
to
me
on
the
tabs
the
details,
dependencies
and
other
versions,
it's
a
bit
strange
to
me
because
the
two
first
ones
are
related
to
the
given
package,
name
and
version,
but
the
other
versions
is
related
more
to
the
list
of
given
package
name
and
it's
like
we
are
mixing
two
two
layers
together.
So
I
guess
I
have
a
strange
feeling
about
seeing
these
ones.
B
C
B
B
B
Would
like
to
get
to
the
point
that
we
can
do
that
and
just
follow
the
pattern
get
lab
uses
for
opening
a
file,
and
it
shows
it
and
just
kind
of
instead
of
having
the
files
tab
open
in
the
navigation.
It
would
still
be
the
package
registry
I,
don't
know
how
technically
difficult
it
is,
but
I
would
like
to
see
it.
You've
been
moving
into
the
container
registry
being
able
to
see
the
docker
file
would
be
something
equivalent
and
it
would
be
nice
to
be
able
to
see
the
files
themselves.
C
F
B
Yeah
I
can
open
up
just
a
whole
new,
separate
issue-
that's
not
contained
in
this
epoch
that
would
be
devoted
to
looking
at
the
files.
I've
heard
it
from
users
that
it
would
be
handy,
so
I
think
it
would
be
valuable
and
we
can
get
it
into
the
backlog
and
address
its
fullness
when
we're
ready
for
it.
I
do
think
it's
a
good
idea,
though,.
B
All
right,
thank
you
so
much
everyone
for
the
feedback.
It
was
really
good,
I'm,
hoping
to
revise
the
design,
create
the
issue
and
then
on
Friday.
We
have
a
conversation,
tin,
Nico
and
I
about
how
what's
prioritized
in
terms
of
all
the
designs
we
have
going
on,
but
I
hope
to
see
this
live
soon,
because
it's
a
big
improvement,
I
think
Tim
is
up
next
and
thank
you.
Everyone
for
taking
notes
by
the
way
I
appreciate
it.
I
just
saw
them.
A
B
The
original
issue
that
I
put
together
was
the
idea
that
a
package
that
contained
or
readme,
we
would
show
it
I,
don't
know
how
popular
that
is.
I
know
the
different
package
managers
handle
it
differently.
To
be
honest,
this
was
a
response
to
the
terraform
module,
which
usually
includes
her
readme
and
so
I
was
wanting
to
satisfy
that
need
across
multiple
registries.
I
think
it
will
require
some
technical
investigation
per
package.
Manager'
formats
really
figure
that
out.
Okay.