►
From YouTube: Package: 12.2 Milestone Grooming Session
Description
The team discusses the upcoming 12.2 milestone, reviews issues and discusses action items.
B
A
A
So
this
is
our
first
one
of
these
actually
officially
and
John,
and
and
Dan
I
put
together
an
agenda
and
I
found
it
helpful,
at
least
in
the
past,
for
working
with
product
managers
to
have,
even
if
we
don't
use
it
every
time,
but
to
prompt
us
to
sort
of
think
things
through
through
other
perspectives,
to
question
our
bias
or
to
allow
for
people
to
chime
in
in
different
ways.
So
I
I
put
these
one
of
my
inspirations
for
doing
that.
A
My
last
job
was
these
six
thinking
hats,
but
the
idea
is
you
walk
through,
and
you
say,
okay
think
about
this.
Now,
do
we
have
all
the
information
we
need
think
pessimistically
think
optimistically
things
like
that,
it's
just
a
way
for
us
to
when
we
talk
about
something-
and
it
sounds
like
we're
all
being
really
positive
about
something
to
break
it
down
and
say:
okay!
Well,
now
what?
If
things
didn't
go
well
or
you
know,
is
there
another
creative
solution?
It's
just
for
me.
A
A
This
would
not
get
the
direction
tab.
It
wouldn't
show
up
in
the
kickoff
document.
I.
Don't
think
that
we
have
any
trackable
work
that
will
be
or
code
that's
being
contributed
as
part
of
this,
this
is
just
an
architecture
decision
for
now,
but
yeah.
Let
me
open
it
up.
Let
me
stop
talking
and
open
up
for
questions
or
comments.
B
Yeah
I
think
right
now,
I
one
of
my
action
items
right
now
is
this
is
a
follow
up
and
keep
this
conversation
moving.
I
think
my
concern
here
is:
is
that
people
have
all
kind
of
had
an
opinion,
no
one's
really
moving,
but
everyone
seems
to
be
being
quite
quite
polite
about
it,
which
is
great
collected,
but
ultimately,
I
have
to
make
a
decision
around
how
we're
going
to
move
forward.
B
The
package
that
we're
trying
to
get
the
dependency
inside
the
dependency
proxy
and
pull
it
he's
thinking
about
implementing
just
a
simple
version
of
a
push
inside
the
dependency
proxy
to
sort
of
validate,
or
at
least
in
rails,
to
validate
that
this
is
possible
and
isn't
a
huge
deal.
Given
that
that's
not
a
huge
deal,
I
think
the
only
major
outlying
concern
that
we
have
right
now
is
the
performance.
B
We're
going
to
have
at
least
the
long-running
processes
of
doing
those
uploads
and
downloads
in
workhorse,
which
means
out
split,
is
a
little
better
across
rails
and
goes
there's
a
bunch
of
factors
here,
I'm
right
now,
unless
there's
some
again
making
the
assumption
right
now,
the
kamil
is
actually
moving
forward
with
we're
doing
that
main
to
follow
up
with
in
realizations
in
that
process.
That
suggests
otherwise
I'm
I'm
I'm
ready
to
make
a
call
to
stay.
B
We
move
forward
and
that
that
meant
I
rather
than
trying
to
fork
and
build
and
deal
with
the
whole
side
of
things
which
I
think
does
down
some
more
complex
of
forking
and
and
updating
our
own
version
of
Dokka
distribution
registry.
So
I
feel,
like
salt
is
a
good
point
for
that.
There's
anyone
any
questions
about
how
that's
set
up
and
and
what's
actually
going
on
there.
A
I
think
I'm
pretty
clear
on
what's
happening
I'm
just
I
one
piece
of
information
that
I
just
wanted
to
share
is
that
it
found
from
the
user
research
so
far
is
that
our
our
internal
developers
don't
really
think
about
this
problem
too
much.
You
know
they're,
they're,
more
worried
about
sorry
guys.
I
have
to
shut
off
my
video
because
you
keep
freezing
and
I
have,
and
first
the
customers
that
I've
interviewed
so
far.
They
are
able
to
use
our
garbage
collection
method
for
their
server
because
they
don't
have
the
same
dependencies.
A
A
B
B
That's
part
of
the
reason
why
we're
pushing
this
work
forward,
but
if
we
do,
if
we
sort
of
odd
generally
come
in
to
the
conclusion
that
is
really
affecting
us
more
than
anyone
with
a
couple
of
notable
exceptions,
I
don't
mean
to
I'm
just
not
going
to
mention
that
intervenes,
but
you
know
with
a
couple
of
notable
exceptions.
We
were
generally
finding
that
it's,
it's
really
asked
for
biggest
issue.
So
is
there
some
workflow
around
this?
That
sort
of
just
addresses
the
problem?
B
I
think
I
think
a
couple
of
ideas
that
pop,
to
my
mind,
were
what
we
were
discussing
briefly
yesterday.
Tim
was
if
we
can't
rebuild
these
images
that
are
currently
in
our
store
from
the
repo,
because
if
they
lead
at
the
branch
that
they
came
from,
do
we
actually
still
need
the
images
anyway
so
like?
What
are
we
really
saving
with
all
of
this
data?
B
Now,
obviously,
that's
the
big
question
is
like:
how
do
we
clean
this
up
because
there's
a
lot
of
unused
data
in
there
but
I
just
wonder
if
we're
really
thinking
about
this
in
a
get
ladee
way
of
what
we're?
Actually,
what
is
the
actual
important
thing?
What
is
the
product?
Is
it
the
repo
itself
or
is
it
the
image?
Is
the
image
a
a
function
of
the
repo?
B
Is
that
just
a
what's
the
word,
an
artifact
in
the
repo
or
an
appendage
of
it,
or
is
the
image
the
actual
end
product
and
so
I
wonder
whether
we've
really
as
a
company
sort
of
worked
out?
What
what
actually
is
the
important
thing
so
that
to
your
question
yesterday,
I
think
Tim
was
you
know
if
we
delete
the
branch?
Do
we
need
the
image?
Is
it
relevant
anymore?
So
that's
that's
I,
think
that's
somewhere,
where
I'm
not
really
sure
of
an
answer.
A
Yeah
that
makes
a
lot
of
sense,
I'm
hoping
to
get
at
those
answer.
Those
questions
with
the
user,
research
that
we're
conducting
and
actually
we
have
a
conversation
with
the
infrastructure
and
distribution
team
tomorrow.
So
we
could
ask
them
some
of
these
questions
more
directly
in
that
call
as
well.
A
C
A
For
me,
too,
the
big
reason
that
this
is
important,
one
is
the
immediate
urgency
of
the
deletion
story
and
retention
and
expiration
policies,
but
thinking
about
some
of
the
more
advanced
use
cases
like
auditing
and
security
scanning
and
whitelist
approved
and
and
banned
dependencies
things
like
that,
and
it
seems
like
we
can't
get
to
those
things
without
first
storing
the
data
and
having
more
control
over
the
registry.
Yeah.
A
B
A
So
the
second
issue
is
a
new
one,
I'm,
not
sure
if
everyone
has
seen
this
one
yet
and
Steve
I
know
you're
working
on
the
NPM,
and
maybe
you
and
then
you
set
it
up.
You
had
to
currently
were
forcing
users
to
generate
their
own
ooofff
tokens
for
use
with
our
NPM
product.
That's
because
NPM
insists
on
use
using
OAuth
tokens
only
so
originally
talk
to
the
manage
team,
one
of
the
developers
on
that
team,
Emre
Farkas
sent
over
a
bunch
of
notes
detailing
about.
A
We
actually
do
support
OAuth
token,
with
our
personal
access
token,
we're
does
not
using
the
proper
headers
and
so
there's
some
way
that
we
can
modify
the
headers
and
allow
and
support
OAuth
with
our
personal
access
token.
So
this
issue
I
summarized
the
problem,
but
a
lot
of
the
content
I'm
taking
from
in
raise
note
in
another
issue,
which
is
also
linked
in
that
it's
linked
in
that
particularly
let's
say:
that's
like
two
six,
two,
two
nine
five,
but
this
unlocks
our
ability
to
support
personal
access.
B
C
Know
this
makes
total
sense.
I
mean
it's
very
obvious
that
that's
something
we
need
to
be
able
update.
I
mean
the
first
thing.
I
tried
to
do
when
I
started,
because
I
had
an
NPM
issue
was
set
up
an
NPM
package
with
my
personal
get
lab,
but
I
already
had
to
factor
off
so
I
couldn't
really
do
it.
So
that
makes
total
sense
as
to
you
know
why
we
need
it
and
I've
read
briefly
through
the
issue
and
the
connected
ones
and.
C
What
the
various
notes
that
are
left
seem
to
make
sense
about
the
headers,
certainly
I
think
the
people
that
wrote
these
notes
know
a
little
bit
more
about.
What's
going
on
in
the
get
logged
code
than
me
right
now,
but
I
have
I
briefly
looked
at
that
section
of
code
and
and
where
the
changes
need
to
be
made
and
yeah.
So.
A
My
one
concern
trying
to
put
on
my
nun
optimism,
bias
hat
is
that
this
doesn't
do
anything
to
support
us
for
CI
job
token
and
and
I'm
not
sure,
if
that,
if
this
moves
us
in
that
direction
at
all
or
if
it's
a
totally
separate
thing
that
we're
gonna
have
to
wait
on
in
the
future.
But
it's
the
one
thing
that
I'm
concerned
about
is
that
we
may
make
this
change
doing
this
sort
of
small
a
patch,
and
then
we
have
to
go
and
redo
things
anyway,
but
I
think
that's.
C
D
A
A
B
C
B
A
It's
a
great
point.
One
of
the
things
that
I've
been
considering
is
right
right
now,
the
way
the
personal
access
token
works
is
you
set
the
scope
for
the
token
when
you
create
it,
so
you
say,
as
API
writes
or
read,
repository
read
or
write
access,
I
think
there's
space
for
us
in
the
future
to
create
special
scopes
for
the
read
package
registry.
So
read:
register
package
registry
write
package
registry-
that's
that's
in
line
with
what
github
is
doing
with
their
personal
access
token
for
their
product
and
I
think
it
makes
a
lot
of
sense.
A
B
And
I
would
I
would
suggest
from
a
purely
security
focused
standpoint.
You
want
to
be
able
to
limit
access
as
much
as
possible
to
reduce
the
potential
impact
of
losing
tokens
or
having
a
breach.
I'm,
it's
that
model
of
saying.
Well,
we
only
grant
the
very
minimum
and
that
way,
if
there's
any
problem
with
it,
then
the
the
impact
is
is
reduced.
D
A
All
right
so
moving
on
the
next
issue
is
about
collecting
data
for
our
stage
currently,
and
we
have
one
metric
that
is
included
in
the
corporates
now
dashboard.
It's
just
whether
or
not
the
container
registry
is
turned
on
or
off
I
believe.
So
this
is
the
our
smile
metrics.
Basically,
how
I
define
them
and
we
could
iterate
on
this
as
a
team
interrupt
smile,
good!
Oh
sorry,
it's
monthly,
active
users
I
forget
what
that
stands
for,
though,
something
monthly
active
users.
I
should
don't,
hopefully
no
one.
A
Is
an
ass
way
exactly,
hopefully,
Jason
isn't
watching
this
video
and
it's
cringing,
so
I
walked
through
basically
each
category,
so
the
container
registry,
the
dependency
proxy
and
the
package
registry.
What
are
the
different
pieces
that
we
would
want
to
track
the
aggregated
column?
You
could
ignore
a
lot
of
this
informations
already
being
captured
as
part
of
the
usage
Bing
and
snowplow.
So
really
it's
it's
pageviews
its
unique
users
for
the
container
registry.
It's
counting
key
events
like
docker,
build
and
and
docker
push.
A
One
it'd
be
great
to
start
tracking
this,
because
this
is
tracking
data
and
having
these
dashboards
is
on
all
of
our
corporate.
Ok,
ours
to
start
tracking
this
stage
data,
so
I
really
don't
want
us
to
fall
behind
and
for
me,
it'd
be
much
better
to
be
making
decisions
based
on
data
versus
I
guess
this
is
important.
I
guess
this
is
highly
used
or
something
is
wrong,
so
I
think
it'll.
It
be
valuable
for
us
yeah.
B
Any
questions
on
mind
is
really
valuable:
I
guess
I
pecan
and
about
sort
of
really
being
careful
about
what
our
expectations
are
for
12-2
in
terms
of
how
we
deliver
on
this
specific
issue,
you
know
for
me:
I
don't
want
to.
You
know
in
the
case
that
we
have
some
metric,
that's
obviously
there
already.
So
we
can
start,
including
that,
yes,
we
have
metric
that
we
can
add
fairly
easily.
That
might
be
sort
of
something
we
could
do
and
then
also
add
in
12.
B
But
if
there's
stuff
that
we
have
to
go
research
and
figure
out
where
we
need
to
add
it,
that
could
be
a
feather
I've,
quite
a
bit
more
involved
in
terms
of
the
engineering
effort.
I,
don't
know
if
you've
worked
with
any
of
this
stuff
before
John
I
know,
you've
been
here
the
longest
EDD
of
everyone
in
this
meeting
so
I
wonder
if
you've
had
experience
with
these
reports,
no.
D
B
A
Think
the
goal
for
this
milestone
would
be
to
start
tracking
the
data,
so
the
success
criteria
would
be.
We
are
now
tracking
these
metrics
separately.
There
is
a
data
team
that
could
help
with
updating
the
periscope
dashboard
and
reports,
and
some
teams
are
writing
those
queries
themselves.
I
have
some
sequel's
skills,
but
it's
it's
been
a
bit.
So
take
me
a
minute
to
get
back
into
that,
but
but
people
have
offered
help
to
help
build
those
dashboards
if
it
helps
what
we
could
do.
That
may
be.
A
The
smallest
iteration
of
this
is
to
just
start
tracking
the
pages
so
any
page
view
ticket
babcom,
slash
container
registry
or
to
slash
packages
or
to
slash
the
different
page
view,
options
that
are
there.
That
would
give
the
executive
team
a
sense
of
a
better
sense
of
smell
than
what
they
have
now
of
monthly
active
users.
B
Yeah
and
I
think
that
might
be
a
good
approach
to
select
some
of
these
metrics
that
are
actually
fairly
clear.
I
think
if
we're
just
dealing
with
with
sequel,
query
updates,
then
I
would
just
have
us
do
that.
Do
that
ourselves,
I
mean
I've,
got
a
fair
bit
of
experience
in
cycle
over
the
years
and
I'm
sure
we
can
figure
that
out,
but
if
we
sort
of
look
at
if
we
sort
of
just
look
at
some
of
these
metrics
that
are
pretty
easy,
that'd
be
a
great
place
to
start.
B
I
think
the
other
thing
that
I
have
in
mind
here
is:
if
we
have
it
fairly
simple
metric.
We
also
have
team
member
joining
on
the
8th
of
July
and
a
couple
of
weeks
I'm.
So
having
some
some
tasks
for
that
person
to
start
on
would
be
would
be
valuable,
and
this
good
fall
into
that.
If
that's
like
a
simple
metric,
you
said,
add
it.
A
C
I
think
looking
at
the
list,
I'm
assuming
most
of
this
data
is
easily
accessible.
The
only
ones
that
I
really
have
any
concern
with
are
things
that
are
event
based
and
whether
or
not
we
currently
you
know
log
that
somewhere,
because,
obviously,
if
we
don't,
then
that
makes
it
a
bit
more
complicated
to
begin
tracking.
C
A
C
Mean
I
think
I
mean
especially
from
like
from
our
current
team
standpoint,
just
not
necessarily
knowing
where
this
data
exists,
then
the
answer
would
be.
Yes,
we
have
to
find
where
the
data
is
before.
We
can
determine
how
easy
it
is
to
put
it
on
a
chart,
and
you
know
if
something
is
just
in
a
table
and
a
schema
or
somewhere
else
that
we
can
pull
really
easily.
Then
we
can
just
check
it
off.
C
B
In
that
vein,
I
agree
with
Steve
I.
Think
the
the
complete
order
complexity
is
really
into
three
buckets.
You
know
it
already
exists.
It's
well
known,
like
page
views,
we
really
just
have
to
update
the
report
to
show
that
data
that
we
already
know
is
there.
Secondly,
is
data
that
we
don't
know
is
there
we
have
to
go
investigate
where
it
is
and
what?
And
thirdly
as
data
that
as
we
as
we
go
to
look
and
investigate,
you
realize
it's
not
being
tracked
at
all
and
we're
going
to
actually
have
to
go.
B
Add
those
metrics
in
increments
and
stuff
into
the
actual
code
base
through
a
release
and
then
be
able
to
get
it
into
the
schema
and
then
be
able
to
get
it
into
a
report.
So
those
to
me
are
the
three
sort
of
orders
of
magnitude
or
levels
of
difficulty
that
we
have
some
of
those
we
won't
know
until
we
actually
start
looking
into
it,
though,
or
identify
which
of
our
unsure
metrics
are
and
then
still
reach
out
to
members
of
the
team
that
probably
may
or
may
not
already
know
and
say:
hey.
B
We
don't
know
about
this.
One
is
it
already
there
question
mark
if
it
isn't,
where
do
we
add
it,
and
those
are
going
to
be
the
way
you
feel
that
out
so
I
think
if
we
can
identify
the
priority
ones,
the
easy
ones
like
the
pageviews
and
then
the
other
ones.
We
might
have
question
marks.
We
just
have
to
do
some
investigation
to
determine
what
those
are
that.
A
Makes
a
lot
of
sense,
I
think
for
the
pageviews,
none
of
nothing's
being
tracked,
but
it's
an
easier
story.
It
just
it's
like
adding
an
updating
one
line
in
a
file,
but
for
the
Steve's
exactly
right
for
things
like
how
many
times
was
docker
push
run,
that's
what
probably
needs
to
be
updated
in
the
code
somewhere
and
a
little
bit
harder
problem,
maybe
I
shouldn't,
say
I
shouldn't
say
that,
but
it
sounds
like
it'll
be
harder
than
the
pages.
A
A
The
next
issue
is
we
talked
a
little
bit
about
a
roundabout
way
with
the
OAuth
discussion,
but
this
is
actually
adding
support
for
the
personal
access
token
to
the
NPM
registry.
This
we've
been
blocked
by
this
by
the
OAuth
issue,
so
the
proposal
here
is
to
once
we
enable
OAuth
to
basically
just
update
our
documentation
to
show
that
we
support
it.
D
Tim
can
I
jump
in
for
one
second
yeah
sorry,
I
need
I,
have
a
2:30
2:30.
My
time,
I
need
to
drop
four
so
just
to
add
in
real
quick,
the
last
to
start
a
jump
ahead,
but
the
two
front
end
issues
that
are
here.
They
should
be
good
to
go
from
our
perspective,
they're
tentatively
assigned
to
Nick
already
they're,
just
not
marked
as
deliverable
as
you
want
to
give
everybody
a
chance
to
talk
about
those,
but
I
do
I
need
to
drop
for
this
over
eating.
D
A
D
A
I
will
look
at
that
with
blissed
I'm
sure
that
we
have
something
small,
but
I,
don't
know
if
that
we
have
any
major
work.
That's
red!
That's
designed
ready
or
anything
like
that
right
now:
okay,
that
yeah
on
that.
No
we
have
the
designers
starting
next
in
two
weeks,
so
hopefully
we'll
start
to
be
able
to
increase
our
throughput.
Okay.
D
Awesome
sorry
to
hijack
the
call
for
a
second
I
just
want
to
make
sure
I'm
not
super
late
to
this
next
meeting
yeah
we
should.
We
should
have
front-loaded
those
I
didn't
say
no,
no,
no
word
no
worries
at
all
all
right.
Well,
thank
you
all
yeah.
This
is.
This
has
been
super
helpful.
Thank
you
all.
So
much
and
I
will
see
you
on
the
next
call.
Okay,.
A
B
B
This
milestone
just
a
couple
of
items
like
bugs
we're
going
to
need
we're
going
to
need
a
couple
of
quick
fixes
for
new
engineer
to
get
into
and
then
I
think
Steve
might
get
through
a
couple
of
more
things
than
he
did.
The
last
time
around
since
I
think
stated
pretty
bit
more
up
to
speed
after
a
month
or
so.
C
C
B
C
C
I
think
the
API
issue
was
like
a
perfect
initial
task
in
terms
of
size
and
scope.
It
was
just
big
enough
to
kind
of
get
me
looking
a
little
bit
of
code
make
a
you
know,
fairly
small
change
and
then
go
through
that
merge,
request,
review
process
because
I
think
that's
sort
of
the
most
important
part
initially
is
not
necessarily
like.
C
C
A
I
have
two
issues
like
that
that
I
could
bring
forward
and
just
put
in
the
milestone.
One
is
for
a
the
ability
to
list
the
containers
at
the
group
level,
which
we
don't
currently
have.
It's
only
lists
at
the
project
level
and
another
one
might
be
something
similar
to
that:
I
have
to
find
them,
and
so
I'll
groom
those.
This
I'll
just
add
in
some
color
this
week
and
I'll,
let
you
know,
and
then
I
post
them
into
twelve
yeah.
B
No
I'm
just
feels
like
it's
fairly
well
discussed
as
well,
so
it
seems
like
there's
a
good
amount
of
information
that
someone
can
grab
so,
whether
that's
Steve
picking
it
up
or
whether
a
new
new
engineer
will
start
looking
into
that
has
a
sort
of
a
first
issue.
It
might
be
a
little
big
for
that,
given
the
history
of
it,
but
either
way,
I
think
it
looks
fairly
well
discussed
and
there's
players
here
that
talking
about
it
that
people
can
reach
out
to
you,
sir
okay.
C
A
one
side
question
for
my
reference,
so
with
you
off
issue
and
this
access
token
issue
would
those
fall
into
like
a
security
issue
that
wouldn't
need
to
be
reviewed,
because
this
or
anything
like
that,
because
I
know
that
part
of
the
merge
request
sort
of
checkoff
list?
Is
you
know
if
it's
a
issue
that
has
anything
to
do
with
security?
It
needs
to
be
reviewed
by
someone
from
the
secure
team,
I'm,
not
sure,
if
maybe
I'm
misunderstanding
it.
But
I
want
to
see
if
that
he's
falling
to
that
skillpa
I.
A
We
talked
a
little
bit
earlier,
a
big
picture
about.
What's
you
know
in
terms
of
a
revenue
perspective,
what's
important?
What's
not,
these
integrations
are
highly
requested
issues
and,
and
a
lot
of
customers
are
saying,
I
will
upgrade
if
you
support
new
guys
or
if
you
support
PHP
or
you
support
this,
so
could
be
something
that
if
we,
if
we
could
first
figure
out,
we
end
up
at
this
place.
It's
like
okay,
this
we
all
agree.
This
is
sort
of
a
decent
product.
A
A
Okay,
just
a
couple
more
and
this
one
is
more
of
a
front-end
issue.
It's
the
improved
discovery
and
navigation
for
get
lab
features.
It's
worth
talking
about
that.
This
came
from
this
had
been
being
talked
about
for
a
while
I
get
lab
it
raised
in
importance
again
when
we,
when
we
launched
the
dependency
proxy
and
Sid
and
Dimitri
we're
asking.
Why
do
we
have
four
separate
main
navigation
items
for
package
features,
and
so
this
issue
is
aims
to
combine
all
of
them
into
one
banner.
A
So
there's
a
group
level
which
will
have
dependency
proxy
and
list
eventually
will
add
to
contain
a
registry
group
view
to
that
as
well,
and
then
there's
another
piece
of
it.
That's
adding
in
basically
packages
and
then
contain
a
registry
and
lists
so
you'll
be
able
to
it'll
all
be
combined
under
one
nose
and
it's
UX
ready
and
you
could
read
through
it.
Are
there
any
questions
or
concerns
about
doing
this?.
D
A
Lost
one
of
my
issues:
okay,
I'll,
find
it
there's
another
one.
That's
a
that's
about
changing
the
documentation
format
to
match
this,
so
I
guard
documentation
currently
lives
under.
You
have
NPM
and
maven
for
the
user
guides,
but
combined
it
under
one
package
registry
guide
and
same
thing
with
the
admin
Docs
and
I.
A
Next
issue,
we
were
is
more
of
a
documentation
effort,
so
Nick
actually
made
the
front
end
changes
for
this.
What
what's
been
happening
is
if
you
have
a
special
character
in
your
project,
name
or
group,
name
or
branch
name
and
then
go
to
navigate
to
the
container
registry,
and
you
get
a
500
error
and
you
get
just
so.
A
You
know
no
explanation
on
what's
happening
and
it's
a
really
bad
user
experience
and
we
get
a
bunch
of
issues
that
are
created
every
week
that
are
saying
I
landed
here,
I
get
this
500
or
what's
happening,
so
we
we
cleaned
up
the
front
end
for
it
to
add
in
an
empty
state
and
to
tell
the
user.
You
know
you
may
have
encountered
this
error.
A
How
do
you
resolve
it
and
I'm
not
sure
that
it
could
be
as
simple
as
you
have
to
go
and
navigate
to
here
and
change
your
group
name
or
you
change
your
project
name,
but
we
should
probably
test
that
and
I've
seen
some
users
where
they
say
that
doesn't
work.
They
had
to
go
and
reset
some
setting
or
restart
the
registry
in
some
cases,
so
I
think
just
some
documentation
and
a
help.
Article
would
be
really
valuable
because
we
see
a
couple
of
issues
per
week
for
for
this
MS.
C
A
Like
I
have
a
sample
project
where
I
have
my
it's
got
like
underscore
container
registry
and
it
breaks
because
the
path
is
created
off
of
the
name,
but
then,
if
I
go
in
and
manually
change,
the
path
and
I
could
fix
it.
So
it
is,
it
isn't
the
path
and
it's
problematic
for
for
branch
names
as
well,
so
I
think
just
the
idea
of
we
don't
necessarily
have
a
fix
for
this
in
the
short
term,
because
it's
based
on
called
the
reading
that
I
had
done.
A
There's
no
easy
fixes
in
terms
of
maybe
there
is
I,
don't
know,
but
I
thought
at
least
if
we
can
have
a
help
guide.
So
when
it
happens,
people
are
aware
of
what
happened,
and
so,
if
it
happens
in
the
UI,
we
point
them
to
this
help
guide.
If
it
happens
in
an
API,
we
could
you
know
they
could
still
get
to
that
and
if
it
happens
from
CIC
the
same
thing,
they
could
at
least
they
could
find
an
article.
It
tells
them
what
this
error
means.
C
A
It's
not
I'll
link
it
in
there,
but
I
think
there
was
I
when
I
first
started.
Thinking
about
this
I
created
a
lengthy
issue
about
how
we
could
warn
users
with
like
a
JavaScript
warning,
but
as
I
started
to
go
through
it.
I
realized
that,
like
there's,
no
way
that
we'll
ever
build
that,
because
projects
and
groups
can
be
created
from
LDAP,
they
can
be
created
from
CI
CD,
they
can
be
created
from
an
API.
They
can
be
created
from
the
UI.
A
C
A
C
C
C
C
A
Okay,
okay,
so
just
one
more
issue:
oh
and
this
one
will
be
quick,
so
this
last
issue
is
assigned
to
me
and
this
one
is
about
the
user
research
that
we're
doing
to
answer
all
these
questions.
We've
been
asking
about
the
container
registries,
so
the
goal
is,
you
know,
we're
making
this
investment
we're
spending
a
lot
of
time
talking
about
how
to
build
the
next
phase
of
the
container
industry
and
Danny
said
something
really
impactful
to
me
yesterday,
which
is
just
because
go
harbor
or
docker
is
solving
it.
A
This
way,
it
doesn't
mean
that's
the
way
that
we
should
solve
it.
We
should
really
think
about
the
problems
that
our
users
are
facing
and
how
those
are
relevant
for
us,
because
we
have
a
different
product
than
those
other
companies
that
are
just
building
a
container
registry.
So
that's
really
my
goal
in
doing
this.
Research
is
for
figuring
out
where
the
and
how
does
how
can
get
lab
presents
something
that
that
solves
those
problems
for
the
users,
that's
unique
to
get
lab
or
follows.
A
B
And
I
think
that's.
That
is
something
that
I've
been
thinking
about,
is
and
I
really
respect,
get
hugs
approach
in
that
get
helps
approached
it
in
a
github
way
and
they're
not
really
doing
what
everyone
else
is
doing.
Now
we
have
a
different
product
and
so
therefore
we're
not
going
to
make
the
same
choices
that
they
will
know
about
my
beter
access
there
wasn't
then
accepted.
Yeah
I
spoke
out.
B
I'm
like
I
still
want
to
see
it
so
I
don't
know,
obviously,
but
just
that
concept
of
like
you
know,
let's
I
think
it's
a
boring
in
fast
way.
To
just
say:
let's
do
what
other
people
are
doing,
and
so
we
had
dr.
distribution
registry
working
on
away,
doing
a
lot
of
the
stuff
for
the
container
registry
and
that's
great
but
I.
Think
as
we
start
thinking
about
where
we
want
to
go
with
this
product,
I
think
it's
really
important
for
us
to
say
well,
hang
on
what
are
we?
B
What
are
what
are
we
actually
trying
to
solve?
Now
we
might
support
docker
hub,
or
you
know
you
know
whatever
it
might
be.
We
might
support
that
protocol,
but
that
doesn't
mean
that
our
users
are
going
to
have
the
best
experience
if
we
just
implement
the
same
way
that
other
companies
do
it
so
I
think
that's
something
that
I
I
don't
have
answers
for.
Obviously
otherwise
I
would
have
said
them
or
suggested
them.
Perhaps
so
yeah
I
don't
know
how
best
to
help
with
that.
B
A
Perfect,
that's
really
helpful
and
my
goal
is
to
meet
with
three
internal
people
and
seven
to
10
external
people
for
this
initial
round
and
then
once
we
that
will
help
help
me
to
us
to
build
a
hypothesis
and
some
ideas
and
then
once
we
do
that
we
can
come.
You
know
turn
that
hypothesis
into
a
something,
that's
testable
and
then
go
and
do
it
talk
to
users
again
and
see
if
that's
if
it's
meeting
their
needs.
A
Okay,
well,
I
realized.
We
went
ten
minutes
over
I.
Think
I
I
must
have
thought
we
scheduled
this
for
the
full
hour
for
50
minutes.
So
thank
you
for
hanging
on
for
the
extra
ten.
This
was
great.
I
really
really
appreciated
this
and
something
I've
been
missing
in
my
first
couple
of
months
here.
So
I'm
really
happy
that
everyone's
on
board
and
now
we're
working
together
as
a
team
yeah.
B
Let's
action
arms
from
this,
we
need
to
split
up
a
couple
of
tickets.
We
also
issued
excuse
me,
and
we
also
need
to
identify
some
sort
of
smaller
items,
to
help
people
with
onboarding
tasks
and
any
overflow
that
we
have
or
extra
tickets
or
issues.
Excuse
me
still
learning
that
we
can
have
assigned
to
peeps
as
they
as
they
sort
of
get
through
this
milestone.
A
Okay,
so
yeah,
actually
a
good
point.
I
have
a
few
I
could
just
read
them
off
to
make
sure
we're
on
the
same
page.
So
I
want
to
make
a
note
in
the
Roth
issue
that
just
about
CI
job
token
and
how
that's
the
next
priority
and
something
to
consider
I'm
going
to
update
the
data
issue
to
add
a
priority
column
and
whether
or
not
the
data
is
currently
available.
I'm
going
to
groom
and
update
the
to
container
registry
API
issues
for
our
new
hire.
A
B
C
B
To
pick
up,
because
you
know
Steve
I'm,
looking
at
it
like
you
know,
I
want
to
give
you
the
time
that
you
need
to
be
officer
to
learn
what
you
need
to
learn.
That's
awesome.
That
may
be
a
good
way
to
learn.
This
is
in
the
context
of
doing
some
work
that
will
give
you
a
little
bit
more
of
a
framework
to
work
around
as
well.
So
having
is
an
option
would
be
good
if
we
have
a
couple
in
mind,
yeah.
C
A
I
think
it's
up
to
us
what
I've
seen
so
far
with
Demetri
his
as
he's
working
he's
worked
through
issues
he's
naturally
had
to
create
separate
smaller
issues
for
himself.
Those
don't
always
get
the
same
level
of
this
is
a
feature
proposal
and
it
has
the
problem
to
solve,
and
so
I'd
say.
If
you
have
an
issue
and
you
create
something,
you
could
see
see
me
and
we
can
go
from
there.
It
could
be
that
I
can
go
in
and
make
sure
the
labels
are
all
up
to
date.
A
C
A
C
Because,
like
the
the
one
I
think
of,
is
that
you
know
that
the
fact
that
you
can
change
the
path
on
NPM
and
it
causes
an
you
know,
there's
a
there's,
an
issue
there,
because
there's
an
the
user
doesn't
know
what's
going
on,
but
they
can't
do
anything
so
certainly
on
the
MDM
outside.
If
it's
small,
then
I'll
just
do
it
and
add
it
into
this
milestone,
along
with
the
existing
issue,
but
I've
identified
that
that
also
is
true
for
maven.
C
B
In
this
particular
case,
I
think
it
makes
sense
to
like
if
I
call
out
the
generalized
problem,
and
then
it
had
issues
underneath
or
related
issues
that
I
NPM
fix,
maven
fix
and
then
sort
of
break
it
out
like
that.
But
I,
honestly,
if
you,
if
you're
sort
of
approaching
this
as
hey
I,
think
I
can
get
to
this
fairly
quickly.
I,
don't
really
mind
how
you
structure
that
I
want
to
be
too
pedantic
about
that
type
of
thing.
But
the
only
thing
to
think
about
is
going
forward
in
this
scenario.
B
When
we
have
people
in
different
parts
of
the
world,
we
may
want
them
spelt
out
a
little
more
clearly
in
case
someone
else
was
going
to
pick
it
up
and
they're
going
to
want
context
and
all
that
stuff.
So
the
big
thing
is
as
you're
doing
that
work
do
what
makes
sense
to
you,
but
just
try
to
remember
that
we
get
other
people
that
are
trying
to
contribute
and
participate
in
what
we're
doing
cool.