►
From YouTube: GitLab Package ThinkBIG September 2021
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
Hello
and
welcome
to
august
oh
september,
someone's
still
on
vacation
2021,
stick
big.
So
we
have
a
few
items
on
the
agenda
today
and
the
first
one
is.
I
wanted
to
share
results
actually,
in
our
last
think,
big
or
the
one
prior
to
that
we
were
talking
about
object,
storage
providers
and
the
difficulty
in
testing
both
the
oops.
Sorry,
sorry,
don't
look
at
that.
The
difficulty
in
testing
both
the.
A
The
package
registry
and
container
registries
with
different
storage
providers,
because
we
have
many
different
options
that
we
could
test.
So
we
talked
about
sending
out
a
survey
to
self-managed
admin
to
understand:
are
they
using
object,
storage
or
local
storage
and
then
which
providers
for
object,
storage
and
which
settings
so
it's?
It
was
quite
difficult
to
get
a
lot
of
gitlab
self-managed
talking
to
research.
It
turns
out
that
that's
a
very
researched
group,
so
we're
only
able
to
get
about.
A
A
Okay,
you
can't
you
can
see
that
this
chart
right,
okay,
so
yeah.
This
is
mainly
focused
on
get
lab
administrators
and
then
we
just
see
that
that
there's
no
easy
answer
here.
Basically
that
storage
is
split
between
local
and
object
storage
fairly
evenly,
although
locals
more
common,
we
see
azure
disk
here
identified
and
then
under
providers.
A
This
is
what
worried
me
is
just
seeing
that
other
is
the
majority,
so
it
wasn't
like
s3
or
google
cloud
was
the
largest
provider
and
you
could
see
some
of
the
numbers
there
and
then
here
I
guess.
A
A
lot
of
the
other
here
identified
are
s3
compatible
providers,
which
is
what
drought
expected
when
when
we
were
talking
about
this
and
then
we
could
see
pretty
even
among
those
who
know
that
they're
using
an
s3
or
who
selected
s3
about
50,
50,
split
between
s3
and
a
compatible
service
and
then
amongst
those,
I
believe,
ceph
was
the
most
popular
and
then
other,
and
you
could
see
just
a
list
of
some
brands
that
I
hadn't
heard
of
before,
and
then
we
have
just
the
three
questions
about
object:
storage
settings.
A
So
do
you
have
direct
upload?
Enabled
pretty
evenly
split
between
yes,
no
and
I'm
not
sure
and
that's
kind
of
the
case
for
the
rest
of
them.
So
do
you
have
background
upload,
enabled
the
majority
said
no
or
or
not
sure,
and
then
the
proxy
download
enabled
the
majority
is
no
and
then
not
sure.
A
That's
it
stop
sharing
for
a
second
any
surprises
there
or
anything
that
does
that
stir
any
thoughts.
A
Sample
yeah,
apparently
I
talked
to
the
research
team
and
they
just
said
that
they
are
having
a
really
hard
time
getting
qualified,
get
that
admin
self-managed
admin
to
take
the
survey
because
they've
been
paying
so
many
so
often
for
surveys,
so
that
the
response
rate
is
really
low.
So
we
we
sent
it
out
to
our
mailing
list.
We
published
it
on
linkedin
and
social
on
several
times.
A
I
posted
it
to
social,
I
think,
but
that
doesn't
you
know
with
a
few
followers.
We
could
expand
it
to
to
reduce
the
restrictions
like
to
ask.
We
don't
have
to
ask
for
admin,
we
could
just
cast
a
wider
net
and
we
may
see
a
larger
percentage
of
people
say,
I'm
not
sure
I
don't
know,
but
at
least
like
as
a
developer.
You
know
that
we
use
you
know
google
cloud,
you
might
be
able
to
answer
it
without
being
an
admin.
B
A
D
Yeah
I
I
would,
I
would
not
like
to
have
it
expanded
beyond
the
confirmed
qualified
gitlab
admins,
just
because
having
more
potentially
worse
data
does
concern
me
I'd
rather
I'd
rather
try
to
bump
the
number
of
these
kind
of
responses.
First,.
A
D
Yeah
any
and
you
just
yeah
somebody
who
would
be
familiar
with
the
configuration
okay.
A
D
E
Maybe
maybe
we
should
take
in
consideration
the
size
of
the
self-managed,
so
if
we
could
reach
out,
for
example,
the
top
10
biggest
self-managed,
because
we
may
reach
out
to
100
self
manager,
each
with
20
user,
and
then
there
is
two
or
three
that
have
5
000
user
and
the
impact
is
different.
I
think.
A
And
actually
it
would
be
biased
survey,
but
we
could
actually
send
out
the
survey
to
our
top
50
most
the
customers
that
use
the
container,
or
at
least
the
packages
registry
most
frequently
that
could
help
too.
At
least
we
could
include
them.
D
A
So
the
next
maturity
target
that
I
was
hoping
we
could
review
is
the
make
the
package
registry
lovable,
which
is
a
little
bit
further,
a
little
bit
further
out
it's
about
two
years
away,
so
we
have
some
time
to
get
there.
But
if
you
remember,
the
previous
maturity
target
make
the
package
registry
complete
was
really
focused
on
adding
a
few
additional
formats.
A
Here,
we
start
to
make
the
feature,
I
think
well
more
lovable
for
people,
so
some
items
that
I
have
here
is
make
the
adding
all
of
the
package
metadata
to
the
user
interface.
That's
something
I
hear
very
often
from
from
people
that
we're
missing
data
which
prevents
the
package
registry
from
really
being
the
single
source
of
truth
for
for
teams
so
ensuring
that
we
have
all
that
data
extracted
when
needed
and
then
presented
and
searchable
in
the
user
interface
and
is
very
important.
A
So
we
have
a
bunch
of
issues
here
that
are
mainly
focused
on
either
displaying
or
extracting
or
presenting
the
metadata
for
each
format
we
started.
We've
tried
planning
this
for
npm
a
few
times
and
it
always
seems
to
fall
by
the
wayside,
which
I
think
is
okay,
because
we've
had
other
priorities
but
it'd
be
awesome
to
get
to
those
in
the
future.
A
E
Gonna
ask
a
question
there
yeah
actually
on
the
previous
one.
So
it
comes
to
mind.
We
have
a
bunch
of
display
available
metadata,
but
wouldn't
it
be
a
good
mbc
step
to
instead
show
the
configuration
file
first
because
most
of
them
they
all
contain
the
metadata
so
package.json
composer.json.
I
think
most
of
the
package
manager
have
a
configuration
file
that
we
could
just
bubble
up
to
the
ui
and
be
a
catch
hole.
A
Would
it
make
sense,
I
think
so
so,
basically,
just
displaying
that
file
in
the
in
the
user
interface
would
be
helpful.
I
think
that
would
definitely
be
helpful.
In
fact
I
that
issue
I
have.
We
have
issues
for
those
somewhere
but
yeah.
I
really
like
that.
I'll
make
sure
it's
added
to
this.
C
F
I
think
we'll
kind
of
just
have
to
cross
the
path
of
we're
going
to
have
to
extract
something,
so
we
can
extract
the
file
the
metadata
either,
both
of
them
at
the
same
time,
or
you
know
we
can
choose
to
to
like
just
look
at
the
file
first
but
like
david
was
saying
like
on
a
lot
of
these
formats,
neither
are
currently
extracted.
F
So
there
is
some
extraction
before
we
can
even
display
the
files
for
some.
F
I
was
going
to
ask
when
it
comes
to
searchability.
Is
there
a
way
that
we're
like
looking
at
or
measuring,
like
the
types
of
things
that
people
expect
to
be
able
to
search
for.
A
I
think
that's
a
good
research
project
that
we
could
look
at,
I
think,
to
start
we
could
probably
like
each
format
kind
of
has
like
if
you
look
at
npm,
they
have
the
most
their
required
fields.
That's
like
a
good
way
to
start
any
of
those
fields
should
probably
have
be
searchable,
or
at
least
filterable,
and
then
we
could
sort
of
exclude
the
all
of
the
other
fields
for
conan.
A
It's
a
little
more
complicated,
because
the
way
that
attributes
work
there
could
be
many
many
options
it
could
be
up
to
like
100
attributes
or
more.
So
I
think
for
that.
We
would
want
to
be
a
little
bit
more
careful
with
what
we
allow
searching
by.
Otherwise
we
could
end
up
in
trouble
what
just
like
what
artifactory
does
is-
and
I
don't
want
to
build
this,
but
they
have
their
own
like
search,
query
language
that
they've
created
and
they
sort
of
put
push
users
into
using
that
to
to
find
packages.
A
I
really
like
what
you
know
sort
of
what
we
have
already
with
the
similar
to
how
we
search
for
issues
and
merge
requests.
So
if
we
could
just
have
instead
of
searching
by
you
know
created
date,
you
could
search
by,
like
you
know,
dependency
or
bin
property
like
that
would
be
really
cool.
E
E
Could
we
bring
it
to
the
package
details
even
if
it
does
almost
nothing,
but
we
can
that
way,
look
at
what
exactly
people
search
for
like
or
even
the
search
that
doesn't
bring
any
value
and
we
will
can
collect.
I
don't
know
they
search
for
package
type,
not
package
type
af,
but
whatever
100
times.
Maybe
we
should
implement
this.
E
A
A
F
I
think
for
npm
there's
more
work
up
front
because
it
involves
extracting
one
or
the
other,
the
file
or
the
metadata,
which
actually,
I
believe,
will
involve
us,
probably
first
doing
the
the
workhorse
changes.
I
don't
know
if
that's
actually
true,
if
we
need
to
move
it
to
workforce
before
we
can
start
doing
extraction,
but
it
seems
like
it
might
be
a
good
idea
to
do
that.
First,
I'm
trying
to
think
if
there's
a
specific
format
that
the
file
is
already
available
and
either
the
metadata
is
or
isn't.
F
C
Also
for
the
npm
package.
I
don't
think
we
need
the
word
cross
change
because
that
change.
It's
just
a
matter
of
how
better
said.
When
do
you
upload
the
package
file
right
now?
It's
just
done
by
rails
and
it
will
change.
It
will
be
done
by
workflows,
but
you
get
the
same
result.
You
have
a
file
on
object,
storage
and
you
need
probably
a
background
job
to
extract
the
package.json
file
from
the
from
the
archive
that
is
on
object,
storage,.
A
C
Nuget
could
be
a
good
candidate
because
we
already
have
a
worker
that
needs
to
pull
the
archive
and
needs
to
read
the
dot
spec
file.
And
so
we
could
just
update
that
worker
to
add
the
dot,
not
new
spec
file
to
the
dark
range
that
could
work.
F
A
C
I'm
not
sure
if
it
is
important,
but
right
now,
when
the
package
is
processed
by
a
background
job,
the
package
is
flagged
as
not
available
for
pulling,
so
you
can't
pull
it
from
from
outside
and
we
wouldn't
need
that
for
all
the
packages.
Let's
say
that
we
start
with
npm.
I
wouldn't
mark
the
package
as
not
pullable.
C
Yeah
exactly
we
have
a
actually
it's
a
state
on
the
package
which
is
called,
I
think
it's
processing,
and
this
is
to
mark
okay.
We
are
processing
the
package
and
you
can't
pull
it
right
now,
but
we
we,
if
we
start
with
npm,
we
need
to
be
to
have
some
caution
to
not
mark
the
npm
package
as
processing
okay,
because
the
explanation
is
that
npm
install
will
not
use
this
package
is
on
file.
It
will
just
pull
the
whole
archive
and
work
from
there.
A
A
Okay,
so
yeah,
we
I
touched
on
identifying
packages
as
protected.
I
think
for
this.
It's
mainly
see
the
functionality
working
similar
to
how
protected
branches
work,
so
you
could
identify
a
package
as
protected
and
then
only
an
admin
or
an
owner
could
make
an
update.
That's
another
really
frequently
requested
feature.
A
I've
been
putting
off
this
this
epic
here
the
package
registry
cleanup
policies
for
a
while.
It's
a
lot
of
stuff
in
here
needs
to
be
cleaned
up,
but
I'm
starting
to
hear
more
and
more
about
this
from
customers.
As
we
see
increased
usage,
which
I
think
is
pretty
cool
but
we're
starting
to
see,
people
say
they
have
so
so
much
that
they
need
to
think
about
auto
expiring
some
packages.
So
this
will
be
something
I
need.
A
I
think
we
need
to
start
to
tackle,
and
actually
I
was
talking
to
katie
yesterday,
our
new
designer-
and
we
were
talking
about
doing
a
ux
scorecard
for
one
of
the
jobs
to
be
done
around
storage
management.
So
hopefully
we'll
start
working
together
on
this
and
start
to
put
together
some
designs
and
ideas
and
research
around
this.
A
Good
thing
we
have
a
lot
of
experience
with
container
registry
cleanup
policies
and
now
time
to
life
policies
for
the
dependency
proxy,
so
we'll
we'll
be
pros
by
the
time
we
get
to
that
one.
A
This
one
is
kind
of
a
catch-all,
epic
that
I
made
a
while
ago,
and
it's
really
just-
I
probably
need
to
rename
it,
but
it's
I
originally
had
this
idea
that
a
lot
of
the
data
model
or
api
needed
to
be
updated,
but
that's
probably
not
what
these
are
so
just
some
issues
that
I
hear
about
often
combining
like
main
packages
in
the
same
in
the
list
view.
A
So
if
you
have
many
versions
put
all
the
versions
together,
I
know
we
have
an
issue
for
that,
including
if
a
package
contains
a
readme
displaying
it
in
the
detail,
view
better
mess,
error
messages
when
transferring
a
group
with
packages.
We
have
another
issue
for
docker
images
that
should
be
updated.
A
Adding
new
package
version
publish
to
project
notifications
is
another
one
that
we
hear
about
every
now
and
then
adding
counts
download
counts
to
the
list
tabs.
I'm
going
to
close
that
issue,
because
we.
A
A
Another
one
we
hear
about
is
more
support
for
tags.
We
talked
a
lot
david
opened
this
issue
for
package
labels
a
while
ago
now
and
it's
something
that
we
talk
about
on
and
off
again
as
a
way
of
helping
customers
to
identify
packages
and
label
them
and
then
allowing
the
tags
to
be
added
and
removed
with
the
api,
and
then
I'm
not
sure
what
this
one
is
validating
package
types
in
the
metadata
models.
A
Okay,
yeah,
so
a
couple
just
a
couple
more
here,
I'm
hearing
a
lot
about
conda
repository,
there's
a
few
formats
that
we
hear
a
lot
of
a
lot
about
from
the
community.
But
condo
is
one
that
I
hear
from
customers
regularly.
So
really
any
customer,
that's
kind
of
doing
has
a
significant
or
a
decent
sized
data
science
team,
they're,
probably
using
conda
instead
of
pi
pi,
just
because
conduct
comes
built
in
with
a
lot
of
machine
learning
packages.
E
A
E
Okay,
because
if
we
didn't
support
them,
it
sounded
like
easy
changes:
it's
just
models
and
it
in
the
ui.
But
no,
if
there
is
that
package
manage
api
to
be
touched.
A
A
Cool
okay,
we'll
move
on
to
the
container
register,
make
the
container
registry
lovable,
which
I
think
this
probably
will
change
over
time.
As
we
add
the
metadata
database
and
we
start
to
add
new
features
from
the
previous
epic,
but
I
did
want
to
call
out
some
of
the
things
that
we
hear,
often
from
customers,
but
are
not
as
important
as
getting
the
metadata
database
on
production
and
deployed
and
also
fix
fixing
some
long-awaited
issues.
This
is
sort
of
like
the
next
level
of
what
we
hear.
A
One
really
popular
issue
is
people,
and
I'm
not
sure
if
we
can
do
this.
I
know
I've
mentioned
this
a
bunch
of
times,
but
removing
branch-related
images
when
the
branches
merged.
So
right
now
in
the
mr
ui,
you
could
say
squash
related
branches
on
on
merge.
People
would
like
to
do
the
same
thing
with
images
as
an
easy
way
of
cleaning
up
the
registry.
A
A
A
We
don't
do
that
today,
because,
especially
for
gitlab.com,
because
it
would
display
way
too
much
info-
and
we
have
some
concerns
about
this
in
general.
About
is
this:
is
this
safe
to
do
even
for
self-managed,
but
this
is
something
we
we
do
here
often.
So
it's
on
the
list.
A
Identifying
images
as
protected
so
similar
to
what
we
had
for
the
package
registry,
this
one
I
used
to
hear
more
often,
I
don't
hear
it
as
often
now,
but
having
the
ability
to
publish
images
to
your
group,
not
just
to
a
project,
not
something
we
could
do
now,
but
we
do
hear
people
asking
for
that
same
thing
for
the
workspace.
So
you
know
well
right
now
we
don't
really
have
the
idea
of
a
workspace,
but
for
in
the
future,
instead
of
there
will
be
for
com
or
sas
customers.
A
A
No,
this
is
another
one
that
we
hear
often
so
people
would
like
to
take
some
action
once
an
image
has
been
pushed,
they
want
to
take
some
other
action,
whether
that's
scanning
or
whether
that's
kicking
off
another
build,
or
something
like
that.
A
A
The
signing
images
we
may
have
a
small
breakthrough
in
that
the
oci
spec
is
now
supporting
signing
of
images,
potentially
even
packages
right.
So
we
have
an
investigation
for
to
see
if
we
could
do
this
and
scheduled
in
a
couple
of
milestones
from
now.
A
A
We
do
hear
questions
about
more
granular
permissions,
although
I
haven't
heard
it
in
a
while,
as
we've
added
more
token
support
for
things,
but
this
is
kind
of
an
older
research
issue,
we're
hearing
more
and
more
about
granular
permissions
a
year
ago-
and
this
is
kind
of
another
web
hook
type
feature
so
a
little
thinner
on
the
lovable
list.
For
now
but,
like
I
said
we
have
to
we're
going
to
get
to
the
complete
and
we'll
see
what
happens,
but
still
a
lot
of
cool
features
here.
A
Any
questions
on
that
one.
A
D
It
also
this
would
be
nice
to
have
the
metadata
database
and
fraud
before
taking
on
a
lot
of
these
issues.
Some
of
them.
A
Require
it,
I
think,
for
all
of
these
all
stand
behind
in
terms
of
I
just
I
stopped
sharing
my
screen,
but
this
epic
is
due
in
november
of
2023
as
well,
so
it
it's
all
of
these
issues
will
will
only
be
prioritized
after
we
have
the
metadata
database
in
production.
A
Oh,
I
did
have
something
about
the
documentation,
but
I
know
nick
is
out
on
vacation
and
not
available
today,
so
I
would
be
cool
if
he
was
here,
because
I
kind
of
wanted
to
just
have
a
look
group
look
at
the
docs
and
see
if
there's
room
for
improvement
or
suggestions
or
if
people
just
because
looking
at
our
last
sus
score,
which
is
done
quarterly
and
for
git
lab
it's.
A
It
hasn't
been
great
for
the
past
several
quarters
where
we
have
a
failing
grade
and
for
our
team.
Normally
the
scores
are
good,
but
in
this
last
one
we
got
dinged
by.
I
think
four
or
five
users
that
the
documentation
was
hard
to
follow
and
what
is
us?
It's
like
where's,
some
use
something
user
satisfaction.
A
Oh
dang,
I
don't
control
that
doc.
I
could
pull
it
up
or
maybe
I
shouldn't
do
that.
I
could
stop
recording.
A
F
Yeah,
I've
noticed
that
too.
I
think
the
one
that
stands
out
to
me
is
npm,
because
I
think
it
is
the
most
frequently
updated
by
like
community
members
and
just
people
sort
of
fixing
things,
but
I
know
that,
like
I'll,
you
know
I'll
revisit
npm
after
a
while
and
be
like
oh
yeah.
F
How
do
I
do
this
and
then
I'll
go
and
look
and
it's
like
totally
different
than
what
I've
done
before
and
and
so
just
like
that,
that
changing
process
isn't
necessarily
a
good
experience
unless
there's
a
really
good
reason
for
it
to
be
changing
like,
like,
I
know
like
we
used
to
only
have
npm
rc
files,
and
now
it's
a
lot
more
configuration
command
based,
so
that
can
create
some
confusion.
F
A
Docs,
I
think,
maybe
if
we
had
a
structure
that
like
this
is
the
structure
that
doesn't
change,
because
this
makes
the
most
sense
and
then
any
community
contribution
would
have
to
still
fall
within
that
structure.
They
couldn't
just
like
remove
any
of
those
headers
or
sections
that
could
be
really
helpful,
but
we
would
have
to
agree
that
this
is
the
most
critical.
This
should
never
change,
not
never
change,
but
it
should
only
change
with
a
really
good
reason.
E
This
is,
this
is
like
I'm,
not
sure
it's
valid,
or
it's
not
a
valid
idea,
but
will
it
make
sense
to
add
bullet
point
to
the
onboarding
for
any
new
team
member
to
pick
a
section
of
the
docks
and
try
to
go
through
it
like
as
a
complete
newcomer
to
this
word
and
see
if
it
makes
sense,
because
I
think
we
are
all
biased
by
knowing
the
system,
ins
and
outs
sometimes
or
and
not
being
familiar
with
it?.
H
I
like
the
idea-
I
I
include
myself
on
that
one
and
for
the
questions
that
you
were
having
steve
about
like
if
we
have
a
process
for
the
community
contributions
for
documentation
yesterday
on
the
retrospective
we
were
talking
about
like
we
don't
want
to
accept
contributions
if
they
are
affecting
quality.
So
probably
we
can
also
work
on
that
like
if
we
cannot
accept
contributions,
his
implementation,
don't
stay,
updated.
A
Yeah,
I
agree
and
we
we
can
always
say
no
or
we
can
move
something
or
I
think
we
just
need
to
be
more
careful
about
what
makes
makes
it
in
because
of
this
shifting
baseline.
It's
it's
really
easy
to
get
off.
So
maybe
what
we
could
do
is
since
npm
is
the
most
crowded.
We
can
try
and
make
you
know,
go
through
and
see
if
we
can
make
any
improvements.
F
I
know
hugo
just
recently
went
through
npm
to
you,
know,
work
through
publishing
and
installing
first
packages,
so
I
can
reach
out
to
hugo
later
and
see
if
he
had
any
feedback
after
going
through
those
docs.
A
Cool
yeah:
I
think
that
our
docs
are
really
part
of
our
product
for
for
a
lot
of
people.
So
if
there's
confusion,
then
it's
even
if
we
have
the
best
user
interface
or
the
best
user
experience
it's
gonna
be
people
are
not
gonna,
be
pleased
when
they
get
stuck
okay.
Well,
let's,
let's
start
with
npm
and
see
if
we
can
come
up
with
like
a
a
format
that
we
really
oh.
A
F
I
think
like
pipi
is
relatively
short
and
simple,
like
it's
very
like
looking
at
on
the
right
side
of
the
page
there.
It's
very
easy
to
navigate
and
there's
obvious,
like
sections
about
like
build
a
package,
authenticate,
publish,
install
and
that's
kind
of
it,
whereas
if
you
click
over
to
like
npm
or
maven,
suddenly
trying
to
navigate
that
right
side
to
find
a
specific
section
becomes
a
little
bit
more
difficult
and
it
might
be
just
because
pipi,
there's
less
usage
and
there's
less
complexity.
But
I
do
like
the
simplicity
of
the
sections.
A
C
I
think
the
issue
on
documentation
is
that
we
need
to
mix
two
sets
of
three
things.
One
set
is
the
actions,
so
it's
authentication
pulling
and
pushing
a
package
and
the
other
set
is
the
levels
that
are
available,
so
we
can
have
up
to
three,
which
is
project
group
and
instance,
so
for
packages
where
the
they
support
three
levels.
We
need
to
like
mix
those
two
sets
together
and
that
makes
the
documentation
hard
to
read
on
npm.
It's
only
two
levels:
it's
the
instance
and
project,
and
you
see
what
we
are
on
maven.
C
We
have
the
three
levels
and
if
you
look
at
the
authentication
section,
you
have
three
sub
sub
sections
for
each
level,
so
I've
been
wondering
if
perhaps
it
would
be
better
to
instead
of
having
sections
on
the
operations.
First,
you
have
sections
on
the
levels
first,
meaning
that
for
me,
then
you
would
have
three
sections
the
project
level,
a
group
level
and
instance
level,
and
then
you
describe
the
operations,
authenticate,
publish
and
install.
E
Another
thing
that
we
could
do
is
that
we
could
mimic
how
a
lot
of
open
source
packages
are
done
and
start
the
docs
without
getting
started
section,
which
is
very
slim
and
cover
the
most
common
use
case.
And
you
know
you
copy
paste,
copy,
paste,
click
link
and
you
are
done
and
you
are
covered
most
of
the
user
and
then
moved
all
the
advanced
stuff
below
that.
E
A
Well,
I
really
like
the
I
like
that
idea,
david
too,
of
kind
of
making
each
basically
three
sections,
or
so
you
have
a
project
group
and
instance
level,
and
then
in
each
one
of
those
you
would
put
build
authenticate,
build,
publish,
that's
a
good
idea.
I
think
that
could
simplify
things
because
right
now,
you're
kind
of
jumping
around
from
section
to
section
which
it's
hard
to
follow.
F
For
nico's
point
like
we
could
even
do
something
like
like
I'm
curious,
how
many
users
really
understand
project
versus
group
versus
instance,
if
they're
just
getting
started
or
if
they
even
care.
So
it
could
be
something
where
we
just
say.
Here's
all
the
project
level
stuff,
because
that's
the
most
straightforward
and
the
most
base
usage
and
then
have
the
other
group
and
instance
level
on
a
separate
linked
page
or
something
like
that.
A
A
Well,
lots
of
ideas
nico.
I
would
love
an
intro
if
you
know
the
person
that
that
that
would
be
great
I'd,
love
to
just
pick
their
pick,
their
brain
a
little
bit
and
ask
them
what
they
think.
I
will
okay
and
then
steve
you'll
ask
hugo
to
see
if
he
has
any
suggestions
and
then
david
do
you
want
to
try?
Should
we
try
something
for
maven
as
well
as
create
an
mr
that
kind
of
just
combines
them
into
project
endpoints
or
project.
G
Group
instance
yeah:
we
can
try
something.
Could
I
do
that
I
could
try
that.