►
From YouTube: GitLab 13.4 Kickoff - Manage
Description
The Product team for GitLab's Manage stage (including the Access, Analytics, Compliance, and Import groups) assemble to showcase what's ahead for us in 13.4:
- Access: 0:47
- Analytics: 6:08
- Compliance: 14:07
- Import: 21:57
Agenda and issue links are publicly available at https://docs.google.com/document/d/e/2PACX-1vRnN91k9Rx1AyF8cIQga3KGFpjkI-sheTB16Jg-4e8fO3snZas2Th4hJC5C5wKIrNWbzr8aYDjI-T7-/pub.
A
Hey
y'all,
thanks
for
joining
for
the
managed
stage
kickoff
for
13.4,
releasing
september
22nd
2020,
I'm
jeremy
watson,
I'm
a
product
manager
here
at
gitlab.
I
am
here
with
harris,
matt
and
melissa,
and
we're
really
excited
to
talk
about
what's
in
store
for
the
four
groups
here
at
on
the
manage
stage,
we're
also
gonna
do
our
best
to
highlight
along
the
way
some
telemetry
and
instrumentation
improvements
that
we're
prioritizing
they're.
A
B
B
B
So
you
can
see
here
on
my
screen
what
it
looks
like.
Basically,
you
can
go
into
a
project
and
create
a
token
and
scope
it
and
it's
not
tied
to
any
particular
user,
and
it's
also
doesn't
count
against
your
licensee.
So
what
this
allows
you
to
do
is
you
know
separate
a
token
from
a
user.
You
don't
have
to
worry
about
if
that
user
leaves
your
organization
or
your
group
or
anything
like
that,
and
you
can
manage
them
separately.
C
B
B
You
were
by
default
added
as
a
guest,
so
now
you're
able
to
customize
that
to
any
of
the
four
existing
roles
that
that
we
have
with
this
change,
you
can
actually
set
yourself
to
what
we're
calling,
no
role
right,
which
basically
means
you're
part
of
the
top
level
group
you
can
sso
in.
But
you
can't
access
any
of
these
sub
groups,
so
basically
you're.
B
A
Awesome
thanks
a
lot
melissa.
I
still
think
that
the
the
no
role
is
was
such
like
a
creative
way
of
working
around
the
inheritance
problem.
I
guess
for
context.
The
challenge
we
were
trying
to
solve
was
figure
out
a
way
we
could
make
inheritance
kind
of
optional,
so
you
didn't
have
forced
inheritance
of
members
on
child
subgroups.
A
Every
single
place
where
you
had
you
had
were
using
subgroups
in
your
product
and
we
couldn't
find
a
way
around
the
very
hard
engineering
work
of
of
making
inheritance
optional.
So
instead
we
introduced
this
no
role
which
allows
you
to
inherit.
This
allows
us
to
continue
respecting
inheritance,
but
you're,
inheriting,
essentially
a
base
level
of
access
which
doesn't
let
you
see
anything
and
then
you
can
incrementally
increase
the
level
of
access
like,
depending
on
where
you
want
the
user
to
have
to
have
access
which
is
super
creative.
B
So
it
I
think
this
is
I'll,
describe
it
as
like
a
workaround
to
our
current
kind
of
like
how
gitlab.com
works
specifically
right.
I
think
long
term,
where
I'd
like
us
to
go
is
to
have
sort
of
like
a
more
proper
user
management
area
for
gitlab.com
right,
and
that's
where
you
know
when
you
first
are
onboarded
right.
That's
where
you
go
similar
to
how
we
have
self-managed
right,
where
you
kind
of
join
an
instance
and
you're
in
this
user's
holding
place
right
until
you
get
signed
out.
A
Cool
that
sounds
good.
I'm
excited
to
see
that
direction
where
we
take,
it
awesome
I'll,
go
ahead
and
go
next,
so
I'm
representing
the
analytics
group,
this
particular
release
and
the
objectives
for
this
really.
So
we
really
wanted
to
focus
on
like
our
core
direction
and
vision
for
the
analytics
group,
which
is
all
about
kind
of
making
teams
and
knowledge
workers
more
efficient
in
gitlab.
A
We
ideally
want
to
be
able
to
give
you
really
powerful
insights
that
help
you
work
more
efficiently
and
more
productively
than
you
can
in
any
other
tool
chain,
and
we
wanted
to
focus
on
two
themes
this
release,
one
of
which
was
what
I'm
calling
instance
level
devops
reporting,
which
is
large
organizations
that
are
using
gitlab.
They
want
to
be
able
to
understand
and
get
and
make
sure
that
they're
getting
the
most
they
can
out
of
the
product
and
then
number
two
is
really
dog.
A
Fooding
and
helping
engineering
teams
be
more
productive
by
using
the
pain
that
we,
our
internal
customers
here
at
gitlab
kind
of
feel
when
they're
using
the
product
so
we're
on
kind
of
on
theme
with
those
with
those
themes,
we're
prioritizing
a
few
things
and
the
first
one
I'll
talk
about
is
this
instance.
Statistics
mvp
and
the
problem
that
we
want
to
try
to
solve
here
is
like,
as
a
large
enterprise.
A
We
are
spending.
We
have
a
lot
of
infrastructure
and
a
lot
of
resources
and
people
devoted
to
using
gitlab,
and
we
want
to
make
sure
that
people
that
were
where
we
have
like
a
solid
return
and
investment
on
our
investment
in
gitlab
and
that
we're
continuing
to
see
people
use
the
product
and
use
it
productively.
A
So
the
first
kind
of
mvp
that
we're
going
to
ship
against
this
is
by
introducing
this
new
instant
statistics,
kind
of
kind
of
feat.
Page,
that's
in
the
admin
panel
for
starters,
and
it's
going
to
very
look
very
simple.
With
a
with
the
users
projects,
groups,
issues,
merge,
requests
and
pipelines
container.
A
This
we're
planning
on
offering
is
it
in
in
gitlab
for
in
gitlab
core
as
a
free
feature
and
we're
also
planning
on
more
kind
of
advanced
reporting
at
the
enterprise
level,
that
I'll
kind
of
and
I'll
kind
of
talk
a
little
about
a
little
bit
later.
But
as
far
as
the
first
iteration
goes
we're
hoping
to
plan
at
least
to
deliver
the
containers
at
the
top
and
then
as
a
stretch
goal
the
chart
at
the
bottom.
But
the
whole
feature
is
an
effort
to
kind
of
help
people
understand
at
the
organizational
level.
A
A
We're
introducing
this
merge
request
report
feature
which
is
going
to
show
you
kind
of
like
your
throughput
of
the
number
of
merge
requests
that
your
team
has
burst
at
the
project
level
over
time,
but
it's
simply
a
simple
chart
and
a
simple
data
table
and
in
13
4
we're
going
to
continue
to
iterate
on
this
by
adding
a
filter
control
at
the
top.
So
you
can
filter
by
a
variety
of
labels
within
your
project.
A
So
a
team
of
gitlab
can
understand
for
their
specific
group
how
productive
they
are
and
how
many
merge
requests
emerging
kind
of
over
time
and
we're
also
going
to
add
a
number
of
additional
columns
to
the
data
table
that
we
will
have
in
this
feature.
So
you
can
see
in
merge
request
analytics
we're
going
to
list
the
specific
merge
requests
underneath
that
the
chart
that
corresponds
to
the
merge,
merge
requests
in
our
first
version
of
this
in
13.3.
A
We're
only
going
to
show
the
date
merged
time
to
merged
milestone
and
number
of
line
changes
per
merge
request,
but
in
134
we're
going
to
introduce
comments,
commits
approvals
and
pipelines.
So
we
will
have
like
a
fully
fledged
and
built
that
data
table
kind
of
like
what
you
see
here.
So
this
will
help
engineering
teams
really
understand
for
their
specific
group
and
for
a
specific
label.
A
But
the
problem
is:
is
that
right
now,
there's
only
one
value
stream
that
you
can
create
and
you
have
to
re
every
kind
of
new
department
that
comes
along
has
to
reorder
this
that's
specific
for
the
the
stages
that
are
specific
for
them
in
13
3.
We're
introducing
this
idea
in
multiple
value
streams,
where
you
can
create
specific
custom
stage.
Setups
that
you
can
use
for
specific
departments
where,
like
qa,
can
create
like
a
set
of
value
of
stages
that
matters
for
them.
A
So
those
are
the
things
that
we
are
committing
to
and
the
stress
of
the
stretch,
goals
that
we
have
and
we're
still
refining
are
some
improvements
to
issues
analytics
where
we
have
currently
just
the
bar
chart
in
this
feature.
That
just
shows
the
open
issues
over
time,
but
we
actually
want
to
add
a
total
issues
line
in
a
bar
for
closed
issues
as
well,
so
you're
able
to
kind
of
visualize.
Are
we
actually
making
progress
against
like
the
burn
down
of
open
issues?
A
A
That
kind
of
shows
you
some
of
the
instance
level
reports
and
we're
going
to
start
by
just
showing
like
merge
request
activity
like
based
emerge,
merge
requests
for
author
in
the
in
the
first
iteration
and
then
in
13
and
13
in
our
35
in
our
next
release.
We're
gonna
try
to
go
a
little
bit
deeper
and
show
a
lot
more
interesting
kind
of
specific
metrics
and
also
allow
you
to
create
custom
segments
across
your
instance.
A
You
can
you
can
create
like
a
a
a
series
of
projects
and
groups
that
encompass
like
a
particular
business
unit
and
see
like
productivity
and
kpis
for
that
specific
unit.
So
that's
coming
in
13.5,
but
for
right
now
we
hope
to
get
a
start
on
that
and
really
excited
about
the
direction.
So
that's
that's.
All
I've
got.
A
A
It
so
if
you
click
on
the
some
looking
gitlab
or
itchy
analytics
and
then
we
do
have
the
filter,
bars,
click
on
group
access-
and
you
can
see
here
so
currently
it's
sorted
just
by
you
can't
you
can't
sort
columns,
but
it's
sorted
by
default
by
age,
but
you
can
see
here
milestone,
issue
due
date
and
so
forth.
So
you
can,
if
you're
interested
in
like
security
issues
or
bugs
or
whatever
you
can
go
ahead
and
and
take
a
look
at
that.
There.
C
C
C
C
But
as
far
as
the
feature
work
for
thirteen
four
we're
focused
on
bringing
export
audit
events,
this
was
originally
put
on
pause.
While
we
were
refactoring
audit
events,
because
there
were
a
lot
of
performance
considerations,
I
think
it
was
something
like
several
seconds
to
pull
even
10
or
20
records,
and
so
now
we've
essentially
greatly
reduced
that
limitation
and
were
able
to
now
implement
this
feature.
C
There
are
still
some
trade-offs
we
have
to
make
as
we
continue
refactoring
audit
events
like
we'll
pull
a
maximum
of
the
most
recent
hundred
thousand
events
for
the
current
view.
So
if
you
sort
and
filter
through
the
audit
events
table
and
there's
a
hundred
thousand
and
one
you're
not
gonna,
get
that
one
last
event
for
now
we'll
be
continuing
to
to
improve
that
experience
overall,
so
we
can
hopefully
do
away
with
those
types
of
limitations.
C
So
that's
just
another
improvement.
We're
making
there
so
that'll
be
available
for
self-administ,
self-managed
administrators
and
we'll
be
considering
how
we
bring
this
to
gitlab.com,
because
there
are
certainly
some
challenges
in
terms
of
the
overlap
between
sort
of
your
professional
life
and
your
personal
life
as
it
pertains
to
your
your
account
on
gitlab.
C
As
the
last
major
piece
of
feature,
work
is
going
to
be
group.
Push
rules
api,
so
push
rules
existed
at
the
instance
and
project
level.
We
shipped
it
for
the
group
level,
but
now
we
have
several
enterprise
customers
who
automate
a
lot
of
their
work
via
api,
and
this
is
one
of
the
many
ways
in
which
they
do
that.
C
So
this
is
something
we'll
be
working
on
for
13.4
to
bring
that
functionality
to
an
api
so
that
enterprises
can
continue
that
automation
work.
Those
are,
I
think,
the
big
three
things
that
we're
focused
on
there
are
several
other
issues
tied
into
the
audit
events,
refactor
and
instrumenting.
Some
product
usage
type
metrics,
but
I
don't
think
we
necessarily
need
to
cover
those,
since
this
won't
be
customer
facing.
C
A
Know
I
know
there
was
a
challenging.
I
don't
know
we
had
a
number
of
challenges
around
like
the
refactor
and
trying
to
understand
the
engineering
work
so
great
job.
Finally,
prioritizing
that
I'm
super
excited
to
see
that
I'm
curious.
What
kind
of
feedback
have
we
received
on
the
credential
inventory.
A
Awesome,
I'm
glad
to
hear
that
people
were
wanting
to
see
more
out
of
it.
I
think
we
had
the
opposite
problem
where
no
one
cared
obviously,
but
it's
great
to
see
that
people
want
us
to
do
more
of
it.
I
not
surprised
to
hear
that
people
want
to
see
more
credentials
exposed
in
there
and
I'm
guessing
at
some
point.
They'll
ask
us
to
have
like
filtering
and
because
they'll
be
so
many
credentials
at
some
point.
They
won't
be
able
to
actually
find
anybody
so,
but.
C
Yeah
and
and
as
melissa
tackles
some
of
the
challenges
around
like
project
level,
access
tokens
and
things
like
that,
some
of
those
more
nuanced
scoped
credentials.
Those
will
need
to
be
included
and-
and
that's
kind
of
a
side.
Note
to
your
first
comment
about
export
audit
events,
one
of
the
things
that
became
obvious
when
we
were
scheduling
that
was
we
plugged
it
into
the
issue,
analytics
view
and
it's
sorted
by
the
age,
and
I
think
that
one
was
like
1400
days
so
that
should
bring
our
average
down
by
some
small
amount.
C
D
Cool,
hey
everybody.
I
am
going
to
talk
about
what
import
is
planning
in
1304
and
we've
had
a
great
and
exciting
planning
session,
where
we
were
able
to
focus
on
advancing
in
parallel,
three
of
our
top
directional
items:
the
gitlab
migration,
the
github
scaling
improvements
and
automating
translations.
D
D
We
currently
do
that
by
exporting
group
files
exporting
project
files
and
then
somehow
reassembling
all
those
by
importing
it
back
into
the
target.
So
we
want
to
make
this
a
self-serve
feature
that
that
our
users
will
be
able
to
to
to
use
so
to
do
that.
To
unblock
this
nbc,
we
are
actually
running
two
spikes
in
thirteen
four
to
research,
the
technical
feasibility
of
the
two
potential
approaches
we
can
take
before
we
start
running
down.
D
One
of
these
one
is
the
api
based
approach
in
which
we
would
have
a
solution.
That's
similar
to
how
the
github
and
the
big
bitbucket
importers
work
today,
where
you
know
you
go
to
your
destination
instance
and
enter
your
credentials
for
the
source,
and
we
will
just
pull
your
projects,
your
groups,
all
of
your
data
across
into
the
new
instance.
D
The
other
approach
is
kind
of
more
similar
to
what
we
currently
have,
and
that
is
a
file
based
approach
where
we
would
create
an
export
file
and
import
file.
But
we
would
automate
a
lot
of
this
so
that
the
users
wouldn't
have
to
actually
download
the
export
and
then
store
it
somewhere
and
then
upload
it
back
into
the
destinations.
D
The
next
on
our
list
is
github
importer
and
specifically,
the
scaling
of
github
imports,
the
ability
for
the
github
importer
to
handle
either
large
projects,
a
large
amount
of
data
or
a
large
number
of
projects
that
are
being
imported.
The
the
problem
we're
going
to
solve
in
13
for
is
the
fact
that
when
we
pull
your
list
of
projects
available
in
github,
we
pull
all
the
projects
and
then
try
to
display
them
in
the
view.
D
So
if
you
have
something
like
thousand
projects,
there's
a
good
chance
that
this
view
will
time
out
and
or
in
best
case,
it
will
be
really
large
and
hard
to
to
sit
through.
We
do
have
filtering
here,
but
we
don't
have
the
ability
for
you
to
just
browse
through
all
the
projects
that
you
have
if
you
have
a
large
number.
D
So
what
we're
doing
is
we're
adding
our
you
know,
trustee
standard
pagination
at
the
bottom
of
this
search
so
that
we
can
show
you
know
x,
amount
like
20
projects
per
page
and
and
make
it
so
that
we
only
pull
those
that
number
across
into
the
ui
and
don't
wait
for
all
of
the
projects
to
be
loaded.
If
you
have
thousands,
especially
this
this
this
times
out
regularly,
and
you
only
get
a
subset
of
other
projects
that
you
see.
D
Finally,
the
last
the
last
direction
item
that
we're
going
to
try
to
move
forward
is
automating
crowding
translations.
Right
now,
when
we
have
new
translations
in
our
translation
tool,
name
called
crowdin
in
order
to
get
those
into
gitlab.
There
is
a
multi-step
manual
process
to
get
those
those
translations
in
that
involves.
D
D
This
feature
is
large
enough
for
us
to
actually
split
it
into
multiple
issues
so
that
we
we
can
iterate
better
and
faster
on
this.
So
we
are
planning
to
pull
all
three
of
these
issues
related
to
this
into
13
4..
There
is
one
other
issue
that
we're
going
to
have
to
discuss
separately
regarding
the
csv
issues
importer,
but
that
number
is
very
low
compared
to
the
overall
number
of
imports
that
we
have.
A
Awesome
thanks
and
thanks
for
breaking
this
down
into
an
epic
and
all
the
great
detail
here,
and
I
also
I
also
appreciate
you,
tom
by
time
boxing
the
spikes
you
mentioned,
that
the
migration
spikes
your
time
boxing
to
five
days,
if
we
can
go
ahead
and
just
immediately
get
started
on
that
work
right
afterwards.
What
do
you
think
about
continuing
that
work
in
13.4.
D
A
D
So,
in
order
to
understand
this,
I
have
done
this
two
or
three
times
so
these
monthly
imports.
I've
worked
on
the
issue
and
the
merge
request
with
some
help
from
the
team,
because
there
are
a
couple
of
couple
of
steps
that
I
really
need.
Somebody
to
help
me
with
like
squashing,
the
you
know,
the
like
50
or
60
different
commits
into
one
and
then
making
some
changes
there,
but
it
it.
Definitely.
D
It
definitely
would
take
a
good
day,
like
you
know,
contiguous
out
of
your
time,
but
it
took
me
several
days
each
time
because
I
would
spend
several
hours
each
day,
so
it
does
take.
You
know,
maybe
a
good
good
day
out
of
out
of
some
of
these
month
and
also
we're
still
not
able
to
deliver
the
frequency
that
we
would
want
to
deliver,
which
is
more
than
just
the
monthly
updates.
D
D
What
takes
up
a
lot
of
time
is
reconciling
any
errors.
So
the
linters
will
catch
a
lot
of
things
and
then
you
know
somebody
has
to
manually
reconcile
that
either
in
crowden
or
in
the
merger
quest,
and
then
you
know,
make
those
changes
and
try
kind
of
running
the
pipeline
again
and
see
if
we
can
pass
all
that
and
in
the
end,
also
again
just
a
couple
of
steps
that
need
to
be
done
manually
with
that
number
of
merger
quests,
you
get
warnings
about
how
much
you're
changing
that
you
can
have
to
overcome.