►
From YouTube: Manage Stage Roadmap Presentations
Description
The Manage PMs share the annual plans for each group
Meeting notes: https://docs.google.com/document/d/1z8Zu8zkwgxQP6yBMi-qy7YRUwmZS8Oqhu3S2DTBlV6w/edit#
A
A
A
The
plan
is
for
each
pm
to
present
about
15
minutes
of
a
presentation
and
then
followed
by
a
three
minute:
q,
a
session
so
feel
free
to
write
down
your
questions
during
the
presentations
and
we'll
leave
some
time
at
the
end
to
address
those
questions.
Whatever
we
want
get
to
we'll
we'll
answer
asynchronously.
A
A
So
the
objective
of
the
workspace
team
and
group
is
focusing
on
creating
a
better
experience
for
organizations
to
manage
their
get
lab
experience,
and,
as
I
mentioned,
this
is
really
everything.
It
includes
moving
administrative
capabilities
that
previously
existed
only
for
self-managed
users
to
our
sas,
offering
as
well
like
management
of
users
and
groups
and
supporting
cascading
settings
and
permissions
and
so
on,
and
it
also
introduces
a
new
concept
for
us
for
feature
parity
between
projects,
subgroups
and
groups,
and
it
creates
a
more
intuitive
user
experience
for
all
users
which
expects
common
behaviors
throughout
the
product.
A
Every
one
of
you
on
the
call
and
was
listening,
probably
at
one
point
in
time,
expected
some
kind
of
feature
on
a
project
or
group
level
and
found
that
there
wasn't
the
same
behavior
when
they
were
looking
at
the
other
level.
So
this
team
is
really
focused
about
on
creating
that
really
nice
user
experience.
A
And
what
we
gain
here
is
we
we
don't
have
any
more
duplication,
features
are
released
once
and
we
can
remove
the
duplications
and
the
code
for
those
that
we
developed
both
for
the
group
level
and
for
the
project
level.
We
can
create
a
consistent
experience
between
self
and
self
and
sas
and
self
managed
users,
and
also
the
users
experience
between
groups
and
instances,
projects
and
in
terms
of
accessibility.
A
A
A
So
this
will
also
be
available
on
set
in
terms
of
midterm
goals
or
further
goals
that
the
currently
working
on
we
have
consolidating
and
cascading
settings
which
will
allow
enforcement
of
settings
top
down.
So
you
can
set
something
at
a
top
level
and
that
will
automatically
trickle
down
to
anything
beneath
it
in
the
hierarchy.
A
A
We
also
completed
backfilling
all
the
existing
projects,
almost
all
of
existing
projects
to
this
new
concept
of
project
namespace
and
now
we're
in
phase
two,
which
is
replacing
core
usages
of
project
with
project
name
space
and
I'll
talk
about
that.
A
little
bit
further
down
phase
three
is
the
one
that
I'm
most
excited
about.
A
We
need
to
complete
phase
two
before
that,
but
it's
the
ability
to
migrate
functionality
to
the
new
namespace
concept,
which
will
allow
every
single
group
in
gitlab
to
start
migrating
their
features
over
to
this
new
level,
and
that
means
that
once
you
develop
something
you
it's
supported
already
for
the
project
and
group
level,
and
then
we
have
a
cleanup
in
parallel.
We're
working
on
administrative
features
that
we're
moving,
as
I
mentioned
from
that
instance
level
admin
panel
to
the
group
owner
level,
so
that
we
can
use
this
in
sas.
A
A
A
A
In
terms
of
planned
validation
efforts
that
we
plan,
we
are
planning
to
kind
of
fix
the
or
work
on
a
right
terminology
for
workspace.
Every
time
that
we
discuss
workspace
internally
there
it
seems
to
be
a
source
of
confusion,
and
even
more
so
when
we're
resolving
to
our
customers.
So
it
it's
a
the
terminology
is
really
associated
to
our
backend
architecture
and
we
feel
it's
not
really
customer
facing.
A
In
the
last
few
months,
we
had
adding
an
api
endpoint
for
delete
topics.
So
in
the
past
you
could
create
project
topics,
but
there
was
no
way
for
you
to
delete
them,
and
so
you
could
have
all
these
weird
deprecated
names
and
things
like
that,
and
now
you
can
actually
delete
it.
We
added
a
configuration
to
for
admins
to
disable
personalization
questions.
These
are
questions
that
are
asked
when
you
create
a
new
group
in
the
product.
A
We
added
that
to
the
admin
area
as
well,
where
you
can
see
and
manage
those
project
topics
and
now
ongoing
is
allowing
to
unfollow
someone
in
a
user
pop-up.
So
when
you
look
at
someone
who,
for
example,
commented
on
something-
and
you
just
have
their
overlay,
you
can
just
unfollow
or
follow
them
through
that
or
realize
whether
or
not
you
are
following
or
unfollowing
that
user,
so
some
really
exciting
stuff,
and
that
was
a
really
quick
overview
of
workspace
and
I'll
go
to
the
q.
A
section
now.
A
B
Go
ahead,
okay,
so
you
mentioned
cascading
settings
and
permissions.
I
understand
how
inheritance
works
for
groups
and
projects.
Can
you
give
a
little
overview
of
what
exactly
cascading
settings
and
permissions
means?
Is
it
different
from
the
inheritance
model
and
will
it
be
changing
at
all
with
workspace.
A
So
if
you
look
at
permissions
today,
we're
thinking
about
adding
this
enforce
globally
option
where
you
can
mark
whether
or
not
this
is
going
to
cascade
down
to
all
the
things
beneath
you.
So,
for
example,
if
you
allow
users
to
request
access,
this
will
be
done
for
every
single
group
and
project
beneath
wherever
you
are,
and
if
you
don't
enforce
it
globally,
then
this
can
be
overwritten.
So
I
hope
that
answers
the
question
in
terms
of
permissions.
A
I
think
things
will
change
for
I'll.
Give
you
an
example
to
yesterday
inside
we
had
this
whole
conversation
about
we're,
we're
consolidating
groups
and
projects
and
in
groups
there's
a
group
owner
and
in
projects
there
really
isn't
one,
and
now,
when
you
invite
people
to
the
group,
you
can
actually
give
a
higher
permission
than
you
can.
So
this
requires
some
thinking
about
things
that
we
didn't
have
in
the
past
and
how
we
can
consolidate
them.
So
I'm
sure
things
will
change
it's
too
early
to
tell
what
okay.
A
C
C
A
A
It's
two
early
days,
I'm
sure
that
we're
going
to
have
to
figure
this
out
on
a
workspace
level,
because
many
organizations
want
to
set
permissions
at
that
top
level
group
and
have
that
cascade
down
to
everything,
and
so
we
need
to
figure
out
how
we
do
that.
What
is
different
than
what
we
have
today.
C
Thanks
thanks
for
this
answer-
and
my
next
is
not
actually
question,
but
the
statement
rather
is
about
terminology,
I
believe
that's
one
terminology
that
is
used
both
internally
and
externally.
So
what
we,
what
we
call
things
between
ourselves,
what
we
call
things
when
we
talk
to
customers
it's
best
and
usually
very
like
best
and
most
clear,
and
when
it's
the
same.
A
Yes,
I
agree.
Hopefully
we
have
a
new
pm
joining
in
may
and
we
can
get
this
validation
work
started.
I
will
say
that
today
we
use
the
concept
name
space
between
us
internally
and
that
cannot
be
user-facing.
It's
really
a
very
technical
term.
So
that's
going
to
change
for
sure.
What
will
it
be
called?
C
B
So
everything
we
do.
It
serves
both
the
admin
and
the
end
user,
of
course,
but
it
kind
of
serves
the
end
user
through
the
admin.
So
I
wanted
to
write
our
objective
statement
from
the
the
system
administrator
perspective,
we're
currently
working
on
splitting
out
our
categories,
so
this
isn't
fully
approved
yet,
but
we
have
user
management
system
access
permissions
and
then
we're
going
to
be
taking
credential
management
from
compliance
as
soon
as
that's
approved.
B
B
B
So
what
the
auth
team
provides
in
this
metaphor
is
we
provide
the
building
structure
itself
right,
we're
kind
of
that
structure
we
decide.
The
building
is
safe.
It's
made
from
certain
material.
It's
this
certain
shape.
We
own
the
keys
to
the
offices
inside
the
building.
We
provide
the
security
guard
at
the
front
desk.
We
provide
regular
maintenance
for
the
building
itself
and
we
also
manage
the
leases
of
all
of
the
offices
inside
the
building.
B
Now
our
individual
tenants,
what
do
they
do?
They're
responsible
for
extra
precautions
for
their
specific
office,
so
maybe
you
can't
get
into
their
office
unless
you
have
a
badge
or
you
scan
your
fingerprint
they're
responsible
for
their
their
regular
maintenance,
so
they
have
their
nightly
cleaning
crew
that
comes
in.
B
They
have
their
own
policies
on
how
long
visitors
can
stay
inside
their
office.
Maybe
they
can
just
come
for
a
day,
maybe
they're
just
there
for
a
meeting
and
then
they're
kicked
out
and
then
they
can
also
provide
a
different
level
of
access
based
on
how
trusted
someone
is
so
we
don't
know
about
their
visitors,
but
they
know
about
who's
supposed
to
be
visiting
their
office.
They
can
decide
do
we
need
to
sign
in
at
the
front
desk.
B
B
Currently,
under
development
within
the
next
few
milestones
we're
going
to
be
releasing
saml
group
sync
for
self-managed
instances.
This
currently
exists
on
sas
actually
and
so
we're
bringing
parity
to
our
self-managed
customers.
Here
we
have
this
concept,
which
I'll
dive
into
more
on
the
next
slide
of
enterprise
users.
As
more
and
more
large
companies
sign
on
with
git
lab,
they
have
a
slightly
different
set
of
needs
and
they
really
want
more
control
over
their
users.
B
B
B
Once
we
have
our
administrators
able
to
claim
those
users
under
their
domain.
Like
I
said,
the
main
thing
they
want
is
more
control
over
them.
So
we
have
an
epic
with
a
whole
bunch
of
controls
that
administrators
want
put
into
place
on
what
people
can
do
within
their
office
or
ecosystem
things
that
are
a
little
further
out.
B
We
know
what
we
need
to
do
for
credentials
inventory
and
that
needs
to
be
brought
over
for
self-managed
has
a
lot
of
utilities
around
allowing
admins
to
manage
their
users
credentials
we're
bringing
going
to
bring
that
to
sas
for
customizable
roles.
You
can
imagine
as
people
we
add
to
the
product
and
we
add
new
features,
things
that
need
permissions.
B
B
Maybe
uncheck
this
uncheck
any
of
these
topics
from
the
matrix
they're,
probably
going
to
be
some
of
these
things
that
don't
make
sense
to
allow
them
to
be
configurable
and
we're
gonna.
It's
going
to
be
disabled
for
some
of
them,
but
just
the
overall
concept
is
think
of
these
as
actual
live
checkboxes,
where
you
can
check
and
uncheck.
B
B
All
right,
our
other
sort
of
large
problem
we're
solving
for
this
year,
is
our
enterprise
customers.
So,
yes,
enterprises
usually
provision
their
users
via
saml
or
skim,
but
sometimes
their
users
go
outside
of
the
process
and
end
up
signing
up
for
a
gitlab
account
with
xyz.com
email
address.
So
we
have
this
user
floating
around.
We
don't
know
that
that
user
is
floating
around
in
gitlab,
but
they
belong
to
my
domain.
B
B
The
user
will
then
get
some
kind
of
notification
that
says
hey.
Your
account
now
belongs
to
your
enterprise,
move
any
personal
projects
that
you
may
have
under
your
no,
your
personal
account
something
like
that
and
then
once
these
customer
once
these
accounts
are
enterprise
accounts,
our
admins
will
be
able
to
have
a
lot
more
control
over
them
right
now,
we're
still
at
that
domain
verification
stage.
I
think,
there's
a
quick
win.
B
B
Initially
we
met
with
over
a
dozen
customers
just
to
understand
their
problem
and
kind
of
get
a
sense
for
what
we
need
to
build
here.
We're
currently
in
the
validation
phase,
revisiting
a
lot
of
the
same
customers
to
show
them
what
we
have
because
they're
excited
about
seeing
their
input
come
to
life
and
then
also
some
new
customers
who
popped
up
recently
wanting
to
understand
where
we
are
with
our
back
and
we've
been
going
over
the
designs,
getting
feedback
and
moving
forward.
There.
B
All
right,
we
have
community
contributions,
this
one's
interesting.
This
is
under
development.
What
this
is
is
allowing
an
administrator,
so
this
for
now
will
be
available
self-managed.
Only
since
we
are
talking
about
administrators
to
be
able
to
find
to
define
a
password
policy,
so
they'll
be
able
to
set
a
minimum
character
length
for
the
password,
whether
it
requires
numbers
symbols,
uppercase,
a
lot
of
websites
have
this
now
and
we
are
getting
this
as
a
community
contribution
which
is
really
nice.
B
Also,
we've
gotten
some
good
community
contributions,
one
of
our
biggest
ones
ever
was
group
access
tokens
in
14.7
and
then
in
14.9
we
got
a
nice
one.
That
kind
of
provides
a
little
bit
more
security
around
whenever
a
new,
pat
or
a
new
email
address
is
placed
on
an
account
that
user
automatically
gets
an
email
notification
and
then
we've
sort
of
fleshed
out
well.
Our
community
contribution
helped
us
flesh
out
our
apis
more
for
keys
and
tokens.
A
B
So
as
it
stands
today,
we
technically
do
have
enterprise
users
and
that's
any
user.
That's
provisioned.
They
have
that
flag
behind
the
scenes
and
I
think
what
is
really
going
to
be
the
difference
is
so
in
the
future.
Enterprise
users
will
not
only
be
provisioned,
but
they
will
be
anyone
who
has
been
claimed
during
that
claim
process
whenever
they
match
the
domain
and
what
that's
going
to
do
is
give
any
admin
or
group
owner
that
has
enterprise
users,
the
ability
to
enforce
certain
policies
or
limitations
on
those
users.
D
All
right,
thanks
hannah,
let
me
go
ahead
and
share
my
screen.
Can
you
all
see
that
should
have
the
disclaimer
slide,
showing
all
right,
perfect
yeah?
So
anyone
watching
the
recording
this
is
our
same.
Disclaimer
slide,
we'll
be
talking
about
forward
future.
Looking
statements
that
are
all
subject
to
change.
Please
don't
rely
on
these
for
purchase
decisions,
so
hey
folks,
I'm
sam,
I'm
the
product
manager
for
compliance
and
we're
going
to
be
talking
about
a
few
different
things.
D
So
we've
seen
this
slide
in
each
of
the
previous
presentations,
but
the
one
thing
I
want
to
kind
of
give
you
as
food
for
a
thought
from
a
compliance
perspective
is
manage
and
compliance
really
does
cover
every
single
one
of
our
users.
It
covers
every
single
one
of
the
actions
they
could
potentially
take.
D
This
represents
a
huge
opportunity
for
us
to
make
a
difference
in
our
users
experience
and
we
have
to
make
sure
that's
a
good
impact
and
that
compliance
doesn't
become
the
bottleneck
and,
to
that
end,
the
objective
we
really
have
for
compliance
at
gitlab
is
to
make
our
experience
something
that's
built
in
to
the
product
rather
than
bolted
onto
the
product.
Traditionally,
compliance
has
been
a
separate
tool
or
a
word
document
that
you
have
to
fill
out
as
part
of
every
release
or
every
time
you
commit
code.
D
We
feel
that,
if
we're
able
to
build
a
built-in
experience,
this
is
actually
going
to
be
something
that
helps
organizations
move
faster
as
a
result
of
the
compliance
policies
and
postures
they're.
Taking
we're
going
to
be
doing
this
through
three
main
categories
that
our
group
has
responsibility
for
of
audit
events,
audit
reports
and
compliance
management,
but
I
wanted
to
talk
a
little
bit
more
about
how
we
feel
that
we
can
help
organizations
move
faster
as
a
result
of
the
compliance.
D
If
we
make
it
easy
to
do
the
right
thing,
people
are
going
to
do
that,
and
that's
really
going
to
help
those
interactions
between
developer
teams
and
compliance
teams
be
more
collaborative.
How
do
we
get
this
done
efficiently,
rather
than
adding
additional
friction
to
getting
new
products
out?
Getting
new
releases
out
additionally
doing
this
in
a
built-in
sort
of
way?
This
is
going
to
really
give
those
compliance
teams
that
the
confidence
to
sleep
well
at
night
they're
going
to
be
able
to
focus
their
time
on.
D
Did
I
define
the
right
policies
for
my
organization,
rather
than
is
my
organization
following
the
policies
that
I
already
defined
because
everything's
going
to
be
built
into
those
existing
workflows,
they
can
focus
their
time
on
what
those
workflows
are.
Rather
than
did
people
use
these
external
tools
and
so
to
talk
a
little
bit
more
about
our
categories.
We
really
view
compliance
management
as
how
do
we
define
policies?
How
do
we
manage?
How
do
we
enforce
those
policies
that
compliance
teams
care
about?
D
Audit
events
are:
how
do
we
give
compliance
teams
traceability
into
what
is
happening
inside
of
gitlab
so
that
they
can
go
back
during
an
audit
or
during
some
sort
of
retrospective
or
remediative
effort
to
figure
out
what
happened?
When
did
it
happen?
Who
was
involved
and
also
audit
reports,
because
we
know
that
audited
events
create
a
lot
of
data.
People
want
to
get
to
insights
of
that
data.
They
don't
want
to
spend
all
their
time
sifting
through
it,
and
so
those
are
really
the
three
categories
we're
focused
on
and
how
they
fit
together.
D
D
We
have
plans
to
allow
further
customization
of
that
compliance
report,
integrate
any
feedback
we
receive
in
the
future,
as
well
as
continue
focusing
on
adding
more
audit
events-
and
I
mentioned
audited
events-
I
don't
know
how
many
times
so
far,
but
really
this
is
one
of
the
key
things
that
is
critical
for
the
success
of
the
otter
events.
Category
customers
rely
on.
I
need
to
be
able
to
see
everything
going
on
inside
of
git
lab,
since
we
release
monthly.
D
We
have
to
commit
to
adding
new
audit
events
to
keep
pace
with
all
of
the
new
feature
development.
That's
going
on
inside
of
git
lab
we've
had
positive
customer
feedback
that
they've
seen
you
know
a
difference
in
us,
adding
all
these
new
events
that
they're
happy
with
that
pace
and
we've
also
made
it
easier
for
other
groups
to
contribute
their
own
audit
events
with
our
audit
event.
Development
guide,
if
you've
not
seen
that,
I
would
encourage
you
to
check
it
out.
D
D
So
the
compliance
report
today,
it
will
show
you
the
latest,
merge
request
in
any
of
the
projects
inside
of
a
group
that
have
what's
called
a
merge
request
violation.
This
is
typically
something
related
to
separation
of
duties.
I
sam
wrote
the
merge
request
and
then
I
self-approved
it.
You
normally
shouldn't
be
able
to
do
that.
D
What
we're
going
to
be
doing
with
this
overhaul,
though,
is
rather
than
just
showing
the
latest
merge
request,
we're
going
to
show
all
individual
violations
that
have
occurred
inside
of
any
project,
and
this
is
really
going
to
make
a
big
difference,
because
then
people
can
see
over
a
historical
time
frame.
What
were
all
the
violations
that
occurred
in
my
release,
that
happened
seven
months
ago,
and
how
do
I
make
sure
all
of
them
had
an
action
plan
associated
with
it,
so
our
nbc?
D
If
this
overhaul
is
going
to
be
coming
soon
and
some
of
the
follow-on
efforts
we
see,
there
are
a
lot
of
ui
ux
changes
to
refine
those
workflows,
additional
filtering
to
help
people
get
to
the
nuggets
of
information
they
care
about
as
well
as
customization,
so
that
organizations
that
don't
care
about
one
of
our
default
checks
can
turn
that
off
or
if
they
do
care
about
a
check
that
we
don't
have.
They
can
turn
that
on
streaming.
Audit
events
is
another
area
we're
going
to
be
spending
a
lot
of
our
time
on.
D
We
released
this
feature
relatively
recently.
We've
already
got
really
good
feedback
about
it.
Today,
users
can
send
audited
events
to
an
http
destination
of
their
choosing,
but
which
is
great,
but
where
this
leaves
them
is
they
then
have
to
figure
out
how
to
ingest
process
and
either
filter
or
build
their
own
automation
around
it.
Really.
D
Another
piece
of
feedback
that
we've
heard
and
that
we
really
want
to
address
is
adding
filtering
of
streamed
audit
events
and
that's
the
the
picture
of
that
picture
in
the
bottom
right
of
the
slide
is
kind
of
a
concept
of
what
that
might
look
like,
because
right
now,
streaming.
Audit
events
sends
you
everything
that
is
being
done
in
your
group,
but
if
you're
only
trying
to
drive
automation
based
on
when
new
users
are
created,
you
don't
necessarily
need
everything.
D
So
we
want
to
be
able
to
offer
a
way
to
filter
down
to
just
the
events
that
you
care
about,
so
you
don't
overwhelm
your
own
endpoints
with
data
that
you
don't
necessarily
care
about.
This
is
really
early
stages.
We're
going
to
be
doing
a
lot,
more
validation,
work.
Doing
mock-ups
prototypes
before
this
comes
to
comes
to
the
product,
and
I'm
really
excited
for
this
one
external
status
checks
is
another
area
we're
going
to
be
focusing
on
in
the
year
to
come.
D
D
So
having
this
concept
of
external
status
checks
allows
the
merge
request
to
call
out
to
those
tools
provide
some
metadata.
Let
that
tool
make
its
analysis
that
says.
Yes,
this
merge
request
is
good
to
go
or
no,
it's
not,
and
customers
can
use
this
today
to
get
a
thumbs
up
or
a
waiting
status,
but
we're
going
to
be
adding
a
no.
This
merge
request
is
not
ready
to
be
merged
status
and
we're
going
to
add
enforcement
around
that
as
well.
D
So
those
are
some
of
the
high
level
roadmap
things
that
we're
focused
on.
I
want
to
also
talk
about
some
of
our
research
and
validation
efforts,
and
one
of
those
is
going
to
be
around
our
category
of
maturity
and
advancing
those
we've
had
these
categories
in
compliance
for
a
few
years.
At
this
point,
and
we've
talked
to
a
lot
of
different
customers,
how
they're
using
them
to
solve
real
world
business
problems.
D
So
what
we're
going
to
be
doing
is
doing
our
category
maturity
scorecard
effort
to
advance
those
maturities
to
for
compliance
management,
and
I'm
really
excited
to
get
the
results
of
that
testing.
Hopefully
it's
all
good
and
we
can
move
it
forward,
but
I'm
also
assuming
we're
going
to
get
some
points
of
feedback
that
we
can
address
and
use
to
continually
make
our
product
better.
D
Final
piece
of
validation,
effort,
we're
going
to
start
taking
on
the
next
year,
is
looking
at
what's
called
supply
chain
levels
for
software
artifacts
for
salsa,
and
this
really
fits
in
with
the
broader
get
lab
story
around
our
focus
on
software
supply
chain
security,
because
we
know
today
that
software
is
composed
from
many
many
different
parts.
If
a
vulnerability
or
some
piece
of
malicious
code
is
in
one
of
them,
it
can
potentially
foul
an
entire
application.
D
This
is
going
to
be
a
large
cross
stage
initiative,
so
we'll
work
with
our
own
group,
competition,
analysis,
container
security,
I'm
sure
some
others
to
figure
out
how
we
can
come
up
with
a
good
solution
for
our
customers
so
that
when
they
ship
or
release
they
can
say
this
is
what's
in
this
release.
This
is
the
only
thing
that's
in
this
release
and
it's
all
compliant
and
secure.
D
That
said,
I
don't
think
only
salsa
is
the
way
we
should
look
at
this.
So
I
want
us
to
investigate.
Are
there
more
generic
ways
that
we
could
build
out
these
sort
of
checks
and
examination
patterns
in
a
way
that
we
could
use
to
implement
salsa?
But
also
do
additional
customization
on
top
of
it
for
new
standards
that
emerge
in
the
years
to
come
with
that.
Thank
you
for
your
time.
Happy
to
take.
Take
your
questions
either
now
or
asynchronously.
C
B
Sure
so
I'm
excited
about
your
developer
guide
for
submitting
audit
events,
and
I
need
to
look
at
that.
But,
aside
from
the
how
we
submit
our
audit
events,
do
you
have
any
general
guidelines
for
what
should
be
audited
like
do
we
need
to
be
thinking
what's
too
much
information
versus
what's
valuable
or
is
it
just
kind
of
like
as
much
as
possible
is
great?
What
are
some
general
principles
here.
D
Yeah,
so
that's
a
that's
a
great
question,
one.
We
wrestled
with
about
a
year
or
so
ago.
So
there's
actually
a
section
in
the
handbook
I
can
add
to
the
doc
later,
but
it
talks
about
how
we
think
about
what
are
our
most
critical
sort
of
audit
events
really
are
events
that
do
that
actions
that
do
things
that
are
irreversible,
such
as
data
deletion,
are
things
that
we
want
to
really
critically
audit.
D
D
Your
question
about
data
volume
is
an
interesting
one
and
that's
actually
why
we
develop
streaming
audit
events,
because
we
knew
that
there
were
lots
of
things
that
users
care
about
things
like
monitoring.
How
often
do
our
users
log
in
what
is
the
number
of
times
this
git
repository,
gets
pulled
every
day
that
are
important
to
them,
but
would
generate
so
much
data
that
we
couldn't
reasonably
store
in
the
gitlab
database,
and
so
we
do
have
that
mechanism
of
streaming
events.
D
D
During
hannah's
presentation,
we
talked
about
credential
inventory
a
little
bit
that
is
currently
only
available
at
the
self-managed
instance
level
rather
than
group
level,
which
means
none
of
our
sas
users
can
use
it.
We
have
some
epics
and
some
issues
about
bringing
that
down
to
the
group
level
for
com
users
trying
to
think
of
other
features.
Really,
we've
tried
to
keep
that
sas
first
mentality
front
of
mind.
So
when
we
develop
new
features
like
compliance
frameworks,
we've
always
tried
to
start
that
at
the
group
level
same
thing
with
streaming.
D
A
D
Yeah,
the
probably
the
main
concern
I've
heard
on
customer
calls
is
that
developers
are
just
trying
to
get
something
in
at
the
last
minute.
They
just
want
to
go
ahead.
Click
do
it,
because
you
know
it's
a
friday
afternoon,
I'm
not
able
to
get
a
review
before
the
weekend.
Let's
just
get
it
done.
So
really
the
self-approval
self-submitted
merge
request
is
probably
the
number
one
thing
people
are
concerned
about
also,
and
this
kind
of
ties
back
to
some
of
what
hannah
was
talking
about
with
roles
people
are
concerned.
D
D
We
address
that
mostly
today
by
trying
to
set
enforcement
at
the
group
level.
So
you
can
say
things
like
the
author
cannot
commit
their
own
merge
requests
at
the
group
level
and
then
enforce
that
at
the
project
and
that
really
helps
to
to
mitigate
that
concern.
Someone
might
be
a
project
owner,
but
they're,
not
a
group
owner,
so
they
wouldn't
be
able
to
get
around
that
control.
E
E
They
want
to
find
a
single
source
of
truth
of
what
is
happening
right
now
with
their
teams.
What
is
working,
what
not
and
getting
any
any
insight
that
they
can
file
from
from
the
data
finding
opportunities
to
improve,
finding
a
risk,
detection,
detecting
risk
if
needed
and
looking
for
best
practices
and
across
all
the
platform
and
specific
with
optimize.
E
E
A
E
Into
the
next
year,
from
a
rodent
perspective,
we
are
for
the
short
term.
We
are
very
focusing
on
completion
of
the
dora
for
metrics,
the
dora,
the
marketing
standard
to
measure
devops
performance,
and
so
we
are
going
to
finish
the
fourth
api,
a
change
failure
rate
in
1410
and
we
are
starting
planning
and
working
on
the
ui
to
support
to
visualize,
eventually
the
metrics,
and
in
addition
to
that,
in
the
shoulder,
we
also
want
to
add
the
ability
of
a
having
the
option
of
further
investigation
from
the
value
stream.
E
In
addition
to
that,
in
order
to
improve
the
accuracy
of
the
door
metrics,
we
want
to
add
integration
into
servicenow
and
jira,
especially
around
the
measuring
incident.
This
is
very
important
for
the
change
failure
rate
metric
and
the
mean
time
to
to
restore
service.
Those
are
key
metrics
to
measure
the
stability
of
of
the
deliveries
by
the
by
the
teams
and
getting
those
insight
directly
from
a
servicenow
ngo
will
make
it
much
more
powerful.
E
Also,
we
want
to
do
a
consolidation
centralization
and
focusing
the
guild
of
analytics
around
the
value
stream
management.
In
a
devops
report,
we
have
several
others
report
with
the
optimize
and
we
are
investigating
exactly
what
is
working,
what
a
bit
not
and
we
might
folding
some
of
them
and
reorganize
them
in
a
way
in
a
workflow
that
will
make
it
easier
for
users
to
use
the
product
and,
in
a
bit
specific,
I
had
here
a
few
examples.
E
This
is
another
thing
that
we
are
investigating
in
addition
to
that,
using
dora
is
a
kind
of
bring
everything
together
with
the
value
stream
analytic
with
the
the
devops
report.
Yes,
so
we
have
a
similar
metrics
and
a
similar
way
of
reporting
across
those
reports
and
again
by
that,
make
it
easy
for
users
to
understand
the
insight
and
to
a
investigate.
E
For
their
needs-
and
these
are
examples
for
the
integration
about
the
servicenow
and
jira-
so
we
also
think
about
taking
labels,
for
example
from
jira,
and
they
have
it
into
the
value
stream
analytic
and
by
that
making
the
a
development
workflow
align
into
the
way
that
we
report
a
value
stream
to
be
aligned
into
the
development
workflow.
A
few
topics
that
we
are
going
to
validate
and
for
us
it's
very
important
to
understand
one
of
the
top
metrics
that
are
the
most
important
one
for
for
leadership.
E
So
we
again,
we
have
this
kind
of
single
source
of
truth
of
having
a
dedicated
or
having,
in
one
page,
the
most
important
metrics,
both
for
leadership
and
both
for
for
engineering
leaders
and
eventually
tie
those
metrics
into
decision
making
process
to
make
it
easier
for
users
to
to
get
the
right
data
that
they
want.
Also,
we
have
investigate
opportunity
around
the
adding
traffic
analytics
and
also
to
assist
with
the
adoption
of
the
devops
adoption
report
to
increase
the
awareness.
We
are
rethinking
the
deterring
strategy
around
that
last
slide.
E
E
D
E
Have
opportunity
over
there
there
is
a
gap,
we
did
a
gap,
analysis
and-
and
this
is
a
definitely
great
opportunity
for
for
us-
for
the
t
for
the
optimized
team,
but
also
for
gitlab
to
to
do
dog
fooding.
Also,
I
can
tell
you
that
internally,
just
getting
a
kind
of
a
single
source
of
truth
for
the
optimized
team
to
see
the
the
team
velocity,
the
team
stability.
A
A
A
The
objective
for
import
is
building
importers
that
our
customer
will
will
find
valuable,
reliable
and
easy
to
use
and
removing
any
friction
from
migrating
to
gitlab
and
creating
a
more
positive
first
impression
when
adopting
gitlab.
So
this
is
really
the
first
entry
point
for
any
user
coming
into
gitlab
and
as
gitlab
evolves.
We
want
anyone
in
around
the
world
to
be
able
to
to
use
this
application
and
to
contribute
to
it.
A
That's
the
second
category
that
the
team
is
responsible
for,
and
this
is
really
about
not
only
translation
but
al.
Also
other
aspects
of
enjoying
the
product
around
the
world,
so
this
can
be
first
and
foremost,
translation
of
different
strings
into
different
languages.
And
today
we
have
spanish,
chinese,
russian,
french,
japanese,
portuguese,
german
and
korean
as
our
primary
targets
for
translations.
But
we
have
many
more
languages
that
the
community
usually
contributes
translations
to
and
once
a
month
we
pull
that
in
from
an
external
tool
called
crowdin,
but
it's
also
about
localization.
A
A
First,
they
want
to
do
a
testing
environment,
see
that
everything
still
works,
and
so
they
move
it
from
one
place
to
another
and
verify
that
everything's,
okay
and
then
they
go
ahead
and
upgrade
their
production
environment.
So
this
supports
everything
today,
besides
designs,
which
is
pretty
new,
so
that's
a
gap
similar
to
audit
events.
A
If
this
is
something
that
people
do
not
tend
to
when
the
feature
is
under
development,
usually
it
lags
behind,
and
so
it
takes
a
while
until
we
get
around
to
supporting
it
group
and
project
export
github
importer,
which
is
also
one
of
our
major
importers-
and
there
are
some
gaps:
we
don't
import
epics,
we
don't
import
designs
and
they're.
Also
some
other
fine-tuned
nuances.
Why
sometimes
that
doesn't
work?
A
Bitbucket
gidea
git
manifest
csv,
jira
fox,
bugs
and
fabricator
you'll
notice,
for
example,
that
azure
devops
is
not
on
the
list
and
others
like
perforce
and
others
that
we
do
want
to
give
the
capabilities.
But
the
demand
isn't
as
high
as
you
would
expect.
So
we
have
not
yet
added
the
support
to
this.
A
If
you
see
here,
I
posted
the
popularity
of
our
importers
taken
from
this
last
month's
data,
and
you
can
see
that
nearly
52
percent
of
our
users
are
using
the
migration.
So
this
is
definitely
the
highest
priority
for
the
team
and
coming
in.
Second,
is
the
github
importer
with
nearly
18
of
our
users.
A
So
what
we
want
to
do
is
really
provide
a
world-class
experience
and
delight
the
user
by
making
this
really
seamless
and
just
having
everything
work,
and
we
recently
shipped
the
ability
to
do
get
lab
group
migrations,
which
was
a
really
huge
achievement
for
the
team,
and
we're
really
excited
about
it.
And
this
is
supposed
to
replace
our
old
importer.
A
A
So
we
want
to
work
on
making
that
experience
much
better
and
lately,
we've
had
lots
of
large
organizations
that
are
looking
to
move
over
from
github
to
gitlab,
which
is
great.
The
the
challenge
here
is
that
they
have
may
have
hundreds
or
thousands
of
projects
and
really
large
source
codes
like
over
20
gigabytes
of
storage.
That
needs
to
move
over
and
our
experience
today
isn't
optimized
for
scalability.
It's.
It
works
for
small
data
data
sets,
but
once
you
are
a
bit
larger,
the
experience
is
very,
very
clunky.
A
So
when
we
select
repositories
to
migrate,
there's
really
no
really
easy
way
to
view
large,
a
large
number
of
them
at
the
same
time
and
or
to
select
a
subset
of
them
and
import
them
slowly.
So
the
experience
is
not
smooth
and
we
have
a
lot
of
concepts
like
organizations,
teens
releases
and
so
on
that
are
currently
not
included
in
the
import.
A
So
you
don't
get
a
full
experience
when
the
import
is
complete
and
sometimes
if
we
don't,
if
we
don't
have
the
ability
to
import
these
things
over,
it
can
be
a
deal
breaker
for
a
larger
organization
and
they
will
just
not
move
over
to
gitlab.
So
this
is
a
real
key
focus
and
why
it's
important
in
terms
of
what's
next.
A
And
then
designs,
as
we
mentioned,
these
two
are
missing
in
toward
in
terms
of
our
full
parity,
so
those
two
will
complete
the
git
lab
migration,
and
this
is
I'm
sure
that
you're
all
familiar,
but
this
is
what
the
designs
look
like,
and
we
want
to
make
sure
that
they
move
over
to
a
new
lab
instance.
When
you,
when
you
finish
the
migration.
A
And
in
terms
of
the
github
project,
what
we
plan
to
do
is,
as
I
mentioned,
reach
parity.
But
what
we
want
to
do
is
import
organizations
to
groups.
We
had
to
do
this
full
mapping
of
how
that
maps
out
also
in
terms
of
github
events,
we
had
to
figure
out
a
mapping.
Not
everything
is
a
one-to-one
so
figuring
that
out
was
a
bit
challenging,
but
but
that's
the
main
effort
that
we're
going
to
do
these
first,
two
and
then
snippets
releases,
branches
and
dashboards
would
be
next.
A
We
have
lots
of
customers
or
prospects
rather
that
are
interested
in
it,
and
since
we
don't
really
support
it,
they
don't
necessarily
continue
the
continue
on
with
talking
to
gitlab
in
terms
of
migrating
over.
So
this
is
something
that
we
want
to
understand:
the
gap
and
capture
we
do
have
a
workaround
which
is
importing
the
csv
type
of
import
and
those
familiar
with
dfs.
It's
really
easy
to
export
to
excel
and
then
save
the
csv,
but
it's
a
manual
and
lengthy
process.
So
we
want
to
make
that
easier
as
well
and
researching.
A
This
will
validate
whether
or
not
there's
a
business
need
for
it
in
terms
of
community
contributions.
We
had
also
a
few
nice
contributions.
Lately
we
had
a
bit
bucket
server
contribution,
some
related
to
the
export
group,
and
we
had
quite
a
few
around
fabricator
and
importer,
different
small
issues
that
kind
of
bucketed
together,
it's
a
really
large
community
contribution.
D
A
A
A
C
B
Go
ahead
with
my
next
question
too:
if
you're
still
looking
yep
go
ahead,
all
right,
so
you
mentioned
some
customers
have
just
not
migrated
to
gitlab
because
of
our
scalability
limitations
in
these
situations.
Is
this
something
where
like
they've
done,
the
import?
It
fails
and
they're
frustrated,
or
are
we
able
to
identify
this
ahead
of
time?
And
if
so,
what
do
we
say.
A
Usually
we're
talking
about
large
organizations
because,
as
I
mentioned,
for
a
smaller
subset
of
data,
usually
it
works.
The
larger
enterprise
customers
that
are
interacting
with
git
lab
usually
will
use
professional
services
in
order
to
help
them
migrate
over.
So
there's
usually
going
to
be
a
professional
service
opportunity
that
goes
along
with
it,
and
the
import
team
works
really
closely
with
the
professional
services
team,
with
every
hiccup
and
escalation
that
we
have,
but
for
smaller
customers
that
are
not
able
to
do
it
themselves.
A
A
D
C
A
But
it's
a
good
question:
I'm
not
sure
what
the
answer
is
so
I'll
need
to
come
back
and
tell
you.
We
can
see
different
activity
of
people
who
suggest
you
can
see
deletions
and
you
can
see
comments
and
suggestions
which
is
really
interesting,
and
we
have
also
reports
to
see
like
activity
so
this
month
had
a
lot
of
approved
words
and-
and
we
went
down
in
terms
of
translation
suggestions,
and
you
can
see
that
sometimes
we
have
spikes.
A
For
example,
we
had
a
spike
last
year
for
norwegian
this
person,
just
like
decided,
he
was
going
to
translate
all
gitlab
and
just
like
rolled
up
his
sleeves
and
went
up,
went
on
a
translation
splurge.
So
it's
interesting
and
you
can
see
the
difference
between
translation
and
the
proofreading.
So
proofreading
is
much
slower,
much
fewer
people,
but
we
do
have
excited
community
members
who
who
are
active
in
this.
It
especially
address
this
to
people
who
don't
necessarily
code-
and
this
is
a
really
great
way
for
them-
to
contribute
to
the
products.
C
A
Well,
great,
I'm
really
surprised
that
we
were
able
to
keep
on
time.
I
was
I
thought
that
the
20
minutes
per
person
wouldn't
be
enough,
but
I'm
really
proud
of
everyone.
I
want
to
thank
everyone
that
presented
today.
I'm
especially
excited
about
the
different
validation
efforts.
It
seems
like
every
validation
effort
in
the
in
the
stage,
is
very
different.
We
have
scorecards,
we
have
terminology,
we
have
business
case,
we
have
tiering,
so
I
think
it's
really
interesting
to
see
very,
very
different
efforts.