►
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
This
is
actually
a
pretty
important
instance
in
our
user
experience,
because
the
user
interface
for
package
is
actually
a
catalog
that
shows
all
of
the
information
stored
inside
of
the
registry
and
one
of
our
most
important
aspects
and
things
we
need
to
convey
to
the
user
is
that
we
you
can
trust
that
the
registries
will
operate
as
you
expect
them
and
they're,
reliable
and
so
improving
the
ui
and
improving
that
polish
really
has
an
impact
on
creating
that
sensation
and
trust
for
the
users
from
a
user
goal.
A
A
A
All
the
way
up
to
let's
redesign
this
whole
section
of
the
page
in
this
subject,
there's
also
two
different
tech
debt
related
issues
that
focus
on
creating
components
that
we
can
use
and
repeat
throughout
the
different
interfaces,
whether
it
be
a
package
for
an
image
or
for
an
infrastructure
module
the
data
that
we're
presenting,
we
feel
really
confident
in
both,
because
we
did
quantitative
and
qualitative
research
in
the
beginning
to
really
understand
what
data
is
important
to
our
users,
as
well
as
through
solution
validation.
We
showed
them
this
ui
and
asked.
A
Again,
as
I
mentioned
earlier,
we
need
the
ui
to
convey
the
trust
and
stability
of
the
package
registry
and,
right
now
it
feels
a
little
different
from
the
rest
of
gitlab
and
while
it
accommodates
all
of
the
different
data,
it
creates
sign
of
a
sensation
that
it's
forced
in
and
that
pulls
away
from
that
idea
that
this
is
reliable.
This
is
stable.
This
is
just
as
good
as
the
rest
of
get
lab.
A
Ui
we
redesigned
it
and
I'm
pretty
excited
about
it
because
I
think
it
just
as
a
designer.
I
think
it
looks
a
lot
better,
a
little
bit
about
the
process
we
went
through.
It
took
about
two
weeks
for
us
to
initiate
the
design
and
go
through
the
iteration
process,
gathering
feedback
throughout
the
whole
scene.
A
We
also
shared
the
design
during
packages,
think
big,
which
is
an
opportunity
for
the
whole
team
to
get
the
get
together
and
talk
about
our
vision,
talk
about
the
work
we're
doing,
and
one
of
the
cool
things
that
was
nice
about.
This
is
that
we
had
all
the
engineers
in
a
room
and
we
were
able
to
ask
of
all
the
different
package
formats
that
you've
worked
on.
A
Does
this
new
design
actually
accommodate
all
the
different
data
while
making
it
easier
to
digest
and
throughout
the
process
we
had
a
really
close
partnership
with
the
front
end
during
the
design
review
process
to
make
sure
we
were
using
gitlab
components,
make
sure
it
was
reusable
and
flexible
and
as
easy
as
we
could
to
accommodate
all
these
different
things
from
the
design
aspect.
I
want
to
call
out
that
one
of
the
big
improvements
we
made
was
a
closer
alignment
to
the
package
or
sorry
to
pajamas.
A
Thinking
back
to
that
idea
that
we
need
to
establish
trust
by
moving
towards
more
pajamas-oriented
components.
We
really
reinforce
that
stability
from
the
rest
of
gitlab
that,
yes,
you
can
trust
that
the
package
stage
will
destroy
and
deliver
your
package
every
time
it
was
really
nice
to
be
able
to
lean
on
that
already
created
infrastructure.
A
A
We
have
a
different
section
related
to
what's
the
history
of
this
package.
Where
was
it
built?
What
commit
is
it
related
to
what
pipeline
actually
ended
up
building
it,
and
then
we
move
on
to
a
new
section
about
how
to
install
it.
How
do
you
set
up
this
registry
to
be
your
source
etc?
And
then
we
also
included
this
additional
metadata
section
that
really
helped
us
accommodate
different
package
formats,
where
npm
doesn't
really
have
any
additional
metadata.
A
One
thing
that
we
also
did
is
we
moved
to
the
one
column
layout
and
that
gave
us
a
lot
of
freedom.
We
were
able
to
expand
vertically
whenever
new
data
was
involved
in
the
ui
and
it
made
it
more
mobile
friendly
just
by
its
default,
which
really
helped
it's
not
a
high
priority
for
a
lot
of
our
users,
but
it
was
really
easy
to
convert
it
to
a
mobile
design
when
looking
at
it.
We
also
heard
feedback,
which
is
always
really
empowering
that
this
new
ui
is
going
to
be
better
for
community
contributions.
A
So
if
a
user
or
an
engineer
wanted
to
add
a
new
package
format,
this
new
design
enabled
them
to
adjust
the
ui
to
base
this
new
package.
All
of
that
was
really
exciting
news.
I
had
to
admit
the
collaboration
between
the
whole
team
and
getting
the
whole
bag,
and
engineers
involved
in
the
conversation
was
really
empowering.
When
thinking
about
this
detail.
A
Moving
on
to
a
different
story,
we
did
an
iteration
on
our
cleanup
policies
from
a
business
perspective,
one
of
the
important
things
that
we
wanted
to
make
sure
we
could
enable
our
users
to
help
them
manage
their
storage
costs
and
they
needed
to
be
easy
for
organizations
of
all
size
and,
regardless
of
their
technical
knowledge,
be
able
to
implement
and
save
in
their
storage
costs
from
a
user
goal.
We
really
needed
to
make
sure
that
the
technical
proficiency
needed
to
enable
the
cleanup
policies
helps
different
organizations
of
different
sizes.
A
A
little
bit
of
backgrounds,
I
I
think
there
is
a
showcase
about
our
mvc
for
the
cleanup
policies
back
in
in
on
filter.
We
got
a
lot
more
attention
from
this
from
our
users
than
we
initially
anticipated.
We
got
a
lot
of
feedback.
A
lot
of
our
users
came
to
us
saying
we
wanted
this,
and
some
of
these
other
things
were
maybe
less
transparent
and
what
we
realized
is.
There
were
two
main
areas
to
help
us
improve
one.
A
On
top
of
that,
from
the
design
perspective,
it's
inconsistent
with
the
pajamas
guideline:
it's
using
kind
of
an
older
style
of
form
and
input,
and
so
it's
just
not
quite
up
to
our
new
standards
that
we
like
to
employ.
So
we
redesigned
it,
and
this
was
a
really
exciting
process.
It
took
about
three
weeks
to
create
this
new
design
and
go
through
the
iteration
process
with
the
whole
team.
A
We
had
a
really
tight
partnership
with
tech
writing.
We
moved
over
to
the
pajama
sidelines
and
it
gave
us
a
little
bit
more
freedom
to
add
a
little
bit
more
copy,
and
I
think
every
designer
can
kind
of
relate
to
the
idea
that
that
is
empowering
and
scary.
At
the
same
time,
and
so
we
partnered
really
close,
really
big
props
to
suzanne
for
her
ability
to
understand
what
we
were
doing
and
give
really
valuable
feedback
around.
How
can
we
make
this
more
human?
A
We
also
were
able
to
get
some
feedback
from
our
active
customers
who
are
involved
in
issues
and
been
saying
we're
struggling
with
this
or
we're
not
understanding
this.
We
brought
them
over
and
said:
hey
we're
redesigning
this.
What
do
you
think,
and
it
was
really
cool
to
see
the
community
around
gitlab
jump
in
and
say
it
would
be
so
great
if
this
was
a
little
bit
different,
or
this
is
a
little
confusing.
A
Maybe
we
should
clarify
here
that
was
just
really
empowering
as
a
designer,
because
I
feel
confident
that
this
new
design
really
helps
users
understand.
What's
going
on,
we
also
added
a
couple
of
ui
moments
that
really
provide
actionable
feedback
when
a
user
changes
something
so
first
off,
we
tell
them.
When
is
the
next
time
this
cleanup
schedule
going
to
run?
A
We
also
made
a
subtle
change
where
we
made
it
very
clear.
These
settings
are
going
to
be
around
what
tags
are
being
protected
and
kept
and
are
important,
and
these
other
tags
are
open
to
be
removed,
which
our
users
responded
to
really
well
being
able
to
quickly
identify
which
will
apply
to
which
situation.
A
Last
but
not
least,
I
want
to
tell
the
story
of
this
little
ui
bug,
because
I
think
it
is
such
a
great
example
of
what
collaboration
can
look
like
and
how
fast
we
can
put
something
out
a
little
bit
of
background
when
you
have
a
tag.
That's
added
to
the
registry,
every
once
in
a
while,
you
will
run
into
this
situation
where
it's
missing
an
important
piece
of
data
called
a
manifest
digest.
A
Most
of
the
time
that
digest
is
always
there,
but
we
discovered
every
once,
while
it's
not
so
for
the
background,
we're
working
on
a
container
ui
epic,
that
kind
of
improves
the
experience
of
the
container
registry
overall,
and
we
were
working
on
a
specific
issue
that
introduced
this
expandable
data.
Well,
that
gave
additional
really
detailed
information
around
this
tag,
including
the
manifest
digest
the
configuration
digest
and
this
explicit
terms
of
what
registry
was
added
to
it.
A
So
we
took
finding
this
bug
and
we
worked
through
what
kind
of
feels
like
a
normal
process.
We
found
it
on
the
front
end.
We
did
a
technical
investigation
with
the
back
end.
We
had
a
go
engineer
who
specializes
in
container
registry
jump
in
figure
out
what
happens?
We
did
some
solution
design.
Here's
a
couple
ways
that
we
can
present
this
to
the
user.
A
And
then
we
implemented
a
new,
mr
that
merged
that
new
solution
into
code
out
to
production,
helping
our
users
always
feels
really
great
from
the
design
aspect.
We
broke
it
into
two
iterations.
One
of
them
was
focused
on
making
it
not
look
broken
anymore,
which
again
we're
trying
to
establish
trust.
That's
really
important,
so
we
kind
of
faked
some
data
and
said
this:
has
zero
bytes
of
space,
there's
no
digest
and
gave
a
really
subtle
warning
that
just
says
this
is
an
invalid
tag.
It's
missing
is
digest
for
a
second
iteration.
A
A
A
I
have
to
admit
I've
been
hiding
the
coolest
part
of
this
interaction,
one
day
from
the
time
that
we
found
this
bug
in
the
ui
all
the
way
through
design,
technical
investigation,
implementation
and
getting
merged
into
code
took
less
than
24
hours,
and
this
is
really
cool,
because
the
timing
of
when
it's
happened
was
right
before
the
end
of
13-2,
and
we
had
just
a
little
bit
of
an
opportunity
to
make
sure
that
nobody
in
production
actually
saw
this
bug.
We
were
able
to
implement
a
solution
that
just
elegantly
said.
We
know
this
is
happening.
A
Thank
you,
everyone.
Those
are
my
three
stories
for
the
day.
I
have
to
give
a
special
shout
out
to
nico
and
juan
and
suzanne,
because
they
were
incredible
about
giving
great
feedback
being
open
to
conversation
and
leading
us
all
to
the
best
designs
that
we
can
put
out
as
quickly
as
we
can
to
enable
our
users.