►
From YouTube: GitLab 12.10 Kickoff - Manage
Description
The Product team for GitLab's Manage stage (including the Access, Analytics, Compliance, Spaces, and Import groups) assemble to showcase what's ahead for us in 12.10:
- Access: 00:20
- Analytics: 10:35
- Spaces: 20:12
- Compliance: 24:47
- Import: 37:43
Agenda and issue links are publicly available at https://docs.google.com/document/d/e/2PACX-1vRnN91k9Rx1AyF8cIQga3KGFpjkI-sheTB16Jg-4e8fO3snZas2Th4hJC5C5wKIrNWbzr8aYDjI-T7-/pub.
A
Hey
everyone
thanks
a
lot
for
joining
us
for
the
manage
States
kickoff
for
12.10,
which
is
get
labs
next
release
releasing
April,
22nd,
2020
I'm
joined
here
by
the
rest
of
the
product
team
here
on
the
manage
stage,
really
excited
to
talk
to
you
through
a
few
really
exciting
issues
that
we're
working
on
for
the
next
release.
So
I'm
gonna
go
ahead
and
start,
and
this
time
we're
actually
doing
this
as
a
team.
A
So
each
one
of
us
is
going
to
represent
and
talk
through
some
of
the
issues
that
we're
excited
about
and
we're
planning
on,
attacking,
so
I'm
gonna
go
ahead
and
share
my
screen
and
I'm
gonna
talk
you
through
a
couple
of
issues
that
were
working
on
on
the
access
group
and
the
first
one
is
as
I
share.
My
screen
share
screen
button
is
optionally,
disabling
group
membership
inheritance,
and
this
is
a
problem
that
is
especially
prominent
on
gitlab
comm,
we're
currently
group
membership.
A
So
this
is
actually
taken
us
some
time
to
get
to
an
MVC,
but
right
now
our
goal
is
to
ship
an
MVC
for
this
feature
that
introduces
configuration
at
the
top-level
group
level
that
allows
you
to
define
whether
or
not
you
would
like
the
membership
for
that
group
to
be
inherited.
So
again,
this
option
is
in
the
first
iteration
is
only
going
to
be
available
for
top-level
groups.
A
A
Something
like
you
know,
production
applications
or-
or
you
know,
all
team
where
you
or
all
members
will
go
in,
but
if
there
is
a
certain
like
executive
group
that
where
they
tab
projects
that
you
want
to
keep
kind
of
separate
with
a
separate
membership
group
that
so
that's
a
thing,
a
subgroup
or
a
yes
list
of
everyone
in
subgroup
a
you
can
go
ahead
and
do
that
with
quite
creating
subgroup,
D
and
defining
those
members
members
differently.
I
can
mention.
A
The
other
issue
that
I'm
kind
of
excited
about
is
this
restrict
members
instance,
membership
changes
to
a
single
user.
So
you
know
what
some
organizations,
especially
enterprise
organizations,
may
use
a
like
identity
and
access
management
system
with
like,
as
kind
of
like
a
middleware
solution
for
managing
like
their
identity,
their
identities
from
an
identity
provider
and
using
this
as
a
single
source
of
truth.
Well,
we
want
to
make
it
easy
for
you
to
kind
of
integrate
and
use
those
types
of
systems
with
gitlab.
A
So
what
we
plan
on
doing
is
doubling
down
on
the
on
the
fact
that
many
of
our
our
customers
will
use
service
users.
Essentially,
though,
designated
like
an
admin
users,
they,
the
user-
that
is
able
to
kind
of
mate
some
of
make
these
changes
and
then
actually
lock
down
membership
changes
to
that
designated
user.
So
that,
if
you
have
an
integration
or
if
you
have
an
external
system,
that
you
can
that
you
get
to
want
to
make
responsible
for
all
membership
changes.
A
So
we
think
that
both
of
these
kind
of
issues,
both
the
optionally
disabled
group
inheritance
and
then
the
restricting
membership
changes
to
a
single
user,
both
going
to
be
really
kind
of
important
changes
to
really
help
enterprises
thrive,
especially
those
that
are
sensitive
to
to
security
and
compliance
needs.
So
I'll
pause
there
that
make
sense
any
questions,
any
other
thoughts,
Matt
I
know.
This
is
something
that
your
customers
have
been
excited
about.
Did
that
issue
kind
of
make
sense
to
you?
Yeah.
C
D
Question
yes,
please,
on
the
previous
issue,
talking
about
about
these
subgroups
inheritance.
Why
how
you
mentioned
it
mentions
in
the
issue
that,
in
order
to
reduce
scope,
that
we're
only
doing
this
for
the
top-level
parent
group
is
it?
Is
it
really
that
much
extra
scope
to
add
that
for
each
group,
underneath
that
I'm
just
wondering
why
that
decision
was
made
yeah.
C
A
You
know
this.
This
behavior
was
introduced
in
the
gate
lab
a
really
long
time
ago,
and
we
made
the
assumption
that
this
inheritance
will
always
be
the
case.
So
we
made
a
number
of
engineering
decisions
with
that
assumption.
So
one
of
those
is
the
use
of
basically
an
engineering
technique
called
recursion
and
all
of
our
all
these
membership
calls
so
that
we
just
automatically
assume
and
then
and
then
pull
from
the
continue
like
pulling
membership
members
from
from
higher
and
higher
groups.
A
Until
we
run
out
of
room
because
of
this,
it
makes
it
really
hard
for
us
to
break
that
assumption,
and
so
we
have
to
kind
of
change
the
way
that
we
better
nourish
of
logic
works.
There's
other
places
where
this
members,
where
this
logic
kind
of
lives
like
an
autocompletes,
for
instance,
like
when
you're
typing,
in,
like,
as
in
the
shirts
bar
for
like
a
particular
author.
It
is
using
that
same
logic
to
pull
from
every
single
group
and
all
the
members
in
all
the
parent
groups.
A
Above
so
it's
one
of
those
things
that
it
seems
like
you
know
we
we,
you
know
when
I
first
thought
about
it.
I
thought
this
is
kind
of
something
very
similar,
but
as
we
dug
into
the
engineering
kind
of
effort,
it
was
actually
getting
pretty
pretty
soon.
So
by
constraining
it
to
just
the
top-level
groups,
we
can
kind
of
retain
that
recursive
approach
and
then
just
have
an
exception
for
the
top-level
group
that
allows
us
to
kind
of
modify
that
logic,
but
not
break
it
completely.
A
If
there
are
other
ideas,
unlike
how
to
how
to
kind
of
how
to
navigate
this
problem,
I'd
love
to
I'd
love,
to
hear
about
him,
love
to
get
more
feedback
on
that,
but
thus
far
I've
been
unable
to
kind
of
find
a
smaller
NBC
just
because
I've
heard
definite
from
customers
and
it's
like
you
know,
the
problem
we
want
to
solve
is
for
gitlab
to
not
do
the
exact
thing
that
it
is
doing
and
there's
and
it's
kind
of
hard
to
solve
that
problem
without
unwinding
the
existing
behavior.
So
that's!
That's!
That's!
Gonna!
D
That
makes
sense,
I
wonder
if
it
would
be
helpful
if
there
was
an
issue
opened
for
adding
the
same
functionality
to
subgroups
that
also
have
nested
groups
within
them,
so
that
there
is
somewhere
for
people
to
go
rather
than
lots
of
people
might
create
multiple
issues
of
that.
If
it
don't
know
that,
maybe
you
need.
A
D
D
Haven't
heard
anything
specific
I
just
like
reading
through
the
issue
that
you're
showing
us
I,
anticipate
that
that's
something
that,
but
that
was
the
first
question
that
came
to
mind
is
like.
Why
would
we
only
choose
the
top
group
if
there
is
a
group
underneath
that's
maybe
being
used
by
a
different
team
and
they
might
have
the
same
problem?
But
it's
just
a
smaller
version
of
that
problem.
Yeah
yeah
one.
A
Thing
one
thing
that
I'm
gonna
do
with
this
is
we're
still
refining
the
the
engineering
path
forward.
Once
we
kind
of
get
a
ton
of
confidence
in
that
I
am
going
to
start
circulating
this
a
little
bit
more
throughout
the
product
team,
because
it
is
going
to
I
think
that
you
know
the
configuration
the
convention
over
configuration
kind
of
question
all
it's
always
something
that
we
need
to
kind
of
think
about
and
when-
and
this
is
introducing
a
more
complex
way
of
configuring
kind
of
like
your
group,
that
might
not
be
readily
obvious
and
I.
A
C
E
The
use
case
that
you
saw
most
most
the
use
case
you're
solving
or
the
use
case,
that
it's
more
prevalent,
the
one
where
there
are
some
people
that
it
should
be
prevented
from
accessing
an
area
or
is
it?
Is
it
always
going
to
be
a
group
of
people
that
took
there
should
be
restricted?
So
is
it?
Is
it
case
like
I?
Have
some
individuals
I
want
to
kind
of
restrict
access
versus,
always
when
I
do
it
to
a
defined
group?
What
was
the
most
prevalent
I.
A
Think
it's
it's
less,
it's
it's
a
so
the
use
case.
The
most
fertile
in
mind
is
a
large
telecommunications
company
that
has
thousands
of
users,
but
they
want
to
have
a
certain
subgroup
of
projects
that
is
only
available
to
a
few
dozen
of
those
users,
so
a
privileged
subgroup
of
the
general
populace.
Basically,
so
this
the
it's
the
executive
team
that
is
responsible
for
product
launches
or
making
like
significant
decisions.
A
So
the
first
issue
is
one
that
we
may
have
talked
about
in
a
previous
release:
kickoff
and
that's
adding
lead
time
and
cycle
time
to
value
stream
analytics
so
right
now,
value
stream,
analytics
I'll
go
ahead
and
click
on
that
page.
It.
It
provides
you
with
a
of
an
overview
of
your
kind
of
you,
the
stages
that
we've
already
predefined
for
you
here
and
within
the
application
from
issue
through
staging,
and
it
rolls
it
up
to
a
total
kind
of
kind
of
lead
time
kind
of
kind
of
kind
of
median
KPI.
A
This
is
useful,
but
this
pitted
stages
will
make
it
particularly
clear
in
terms
of
which
metrics
are
really
the
most
important
like
what
could,
as
is
the
measurement
of
success,
and
it
doesn't
use
you
know,
kind
of
industry,
standard
language
for
what
people
would
like
to
see
out
of
this
page
and
I.
Think
we
want
to
take
this
first
step
towards
this
by
introducing
lead
time
and
cycle
time
specifically
into
this
page
by
calling
them
out
and
in
this
container
here
in
the
top
of
this.
So
we're
lead.
A
Time
is
gonna,
be
the
the
the
initiation
and
eventual
like
completion
and
delivery
of
product
where
a
cycle
time
is
when
you
actually
an
engineer
actually
like,
begins
production
and
then
actually
completes
that
work
product.
We
want
to
actually
introduce
both
of
these
into
the
into
this
page
you're
able
to
eventually
visualize
these
over
time,
see
which
aspects
of
your
value
stream
are
influencing
this
the
most
and
then
so.
A
A
This
epic
here
show
the
DevOps
life
cycle
and
value
stream
analytics
and
I'll
talk
a
little
bit
about
the
actual
visualization
of
the
lifecycle
in
a
minute,
but
you
can
see
that
we
actually
want
to
iterate
towards
introducing
a
number
of
these
categories,
these
kind
of
KPIs
on
the
value
stream
page
so
that
you
can
understand
them
track
them
over
time
and
we're
starting
with
lead
time
in
cycle
time.
That's
kind
of
the
first
step.
A
The
next
thing
that
I'm
really
interested
in
is
visually
depicting
value
stream
analytics
as
a
flow.
So
you
know,
like
I,
like
I,
showed
you
on
that
previous
page
value
stream.
This
is
useful
in
itself,
because
it
does
kind
of
tell
provide
of
a
out-of-the-box
value
stream
in
terms
of
way
how
information
and
work
product
is
gonna
flow
in
through
gitlab,
but
it
doesn't
really
depict
it
as
a
staged
actual
flow.
So
each
of
these
stages
are
kind
of
laid
out.
A
You
know,
vertically,
were
you
able
to
click
into
each
one
and
then
show
should
different,
KPIs
and
and
time
durations
for
each
of
these.
But
what
we'd
like
to
do
is
we'd
like
to
see,
if
resonates
with
customers
to
actually
like
arrange
these
as
they
as
a
flow.
So
each
one
of
those
those
stages
that
I
just
highlighted,
issued
plan
code
and
test.
A
What
we
want
to
do
is
we
want
to
lay
them
out
with
Chevron's
on
the
top
and
allow
you
to
eventually
in
a
future
iteration
click
into
each
to
be
able
to
understand
them
a
little
bit
more.
So
why
I
think
this
is
really
interesting?
Is
you
know,
we're
able
to
find
tella
start
telling
a
visual
story
of
like
what
they
ought
value
stream
analytics
does
for
your
organization
test
and
see
if
these
were
actually
the
right?
A
This
is
the
right
terminology
to
actually
use
with
customers,
we're
not
really
sure
if
we've
gotten
the
stages
right,
we
want
to
validate
that.
This
is
working
for
customers
and
then
to
see
how
you
know,
customers
actually
start
using
this
if
their
behavior
changes
at
all,
we
actually
lay
this
out
visually.
So
again,
this
is
mostly
right
now
and
it's
current
we're
still
in
discussions
with
engineering
on
the
specific
approach.
A
Why
we
think
this
is
interesting
is
one
cussed
problem
that
we
tend
to
hear
from
customers
is
that
they
don't
really
understand
how
their
customer
or
their
users
are
really
using
gitlab
and
one
customer
has
actually.
It
has
showed
me
a
report
where
they
could
run
a
report
themselves
of,
like
all
the
groups
that
are
they
have
on
their
instance
and
then
how
many
MMR's
are
they
creating
how
many
security
scans?
Are
they
doing?
How
many
pipelines
are
they
running
and
they
really
think
about
return
on
investment
as
just
simply
usage?
A
It's
like
are
people
doing
things
with
the
product,
and
so
this
is
like
a
small
step
forward
to
start
showing
that
information
at
the
group
level
and
then
in
a
future
iteration.
We
can
think
about
aggregating
all
the
group
level
information
up
into
a
single
report
so
that
someone
can
you
know,
take
this
information,
show
it
to
their
CTO
and
say:
look
people
are
getting
a
lot
of
value
at
a
gitlab
for
creating
merge,
request
the
creating
issues
and
it
becomes
a
really
easy
conversation
to
justify
what
kind
of
value
it's
adding
to
your
organization.
D
A
question
on
the
very
last
one,
all
of
this
stuff
for
analytics:
it's
really
cool
o
for
the
issues
EMAS
and
people
added
users
added
in
the
last
90
days.
Are
we
storing
that
data
anywhere
like
for
it
to
be
like
it?
Are
we
storing
it
somewhere
so
that
we
can
add
on
to
it,
rather
than
it
just
being
overwritten
like
in
order
for
us
to
be
able
to
pull
a
report
and
say
that
these
are
how
this
is
how
these
this
date
has
changed
like
90
days
to
90
days?
That's.
A
The
reason
is:
is
that
we're
not
storing
this
data
anywhere
right
now
we're
just
pulling
those
queries
like
when
you
visit
the
page
and
the
reason
for
that
is
because
we're
still
trying
to
figure
out
on
analytics
what
the
best
way
of
storing
this
time
series
data
is:
that's
going
to
be
performant
over
time
if
you're
totally
right,
like
the
next
request.
Out
of
that
comes
from
this,
it's
gonna
be
I.
Wanna,
see
this
our
time,
I
wanna
be
able
visualizes
and
stuff,
and
right
now
you
can't
and
we're
still
trying
we're
doing
some.
A
Some
exploration
and
engineering
work
to
understand
whether
or
not
like
Prometheus
or
another
or
another.
That
datastore
is
gonna,
be
a
way
to
do
it
because
right
now,
it's
a
challenge
to
make
it
work
with
Postgres,
with
with
it
with
the
database.
It's
our
that
we're
using
already
with
gitlab.
So
I
think
it's
a
great
point.
I
totally
agree
that,
like
we're,
definitely
a
request
for
to
see
this
over
time
and
understand
to
do
more
interesting
things
or
the
reports.
A
C
B
Somewhat
related
to
have
a
question
for
you
about
like
what
are
the
thoughts
you've
had
or
given
to
this
seemingly
recurring
theme
from
customer
conversations
recently
that
they've
liked
the
idea
of
API
driven
kind
of
everything,
and
so
two
recent
conversations
come
to
mind
about
how
they
talked
about
being
able
to
import
their
own
data
to
get
lab
dashboards
to
be
able
to
aggregate
everything
in
one
place.
Ideally,
but
then
is
this
stuff
available
via
API
to
be
pulled
out
and
just
love
to
hear
your
perspective
on
that
yeah.
A
I
think
there's
two
questions
that
I'm
still
trying
to
understand.
One
is
what
what
is
gonna
be
the
data
store
that
we
use,
because
that's
going
to
influence
what
data
we
make
it
and
then
to
what?
What
data
do
we
make
available
like
we
can't
just
API
all
the
things
and
kind
of
go
from
there
like
if
we
are
using
like
Prometheus
there
are
there
are
we
can?
A
A
It's
something
that
that
John,
Mason
and
I
are
gonna,
have
to
keep
in
mind,
but
I
think
it's
kind
of
dependent
on
on
on
that
engineering
question
and
also
we'll
dig
into
that
customers
once
we
kind
of
have
a
path
forward
there
to
understands
like
cool
what
kind
of
dashboards
do
you
want
to
start
building?
How
can
we
expose
that
data
and
we
can
kind
of
iterate
from
there,
but
III
don't
have
a
great
sense
right
now
of
like
that
question:
I
yeah,
but
well
thanks
for
bringing
it
up.
Yeah
thanks.
B
A
D
Thanks
for
me,
so
a
little
bit
of
context
on
group
managed
accounts
for
those
of
you
who
have
not
heard
of
this
feature
before
this
is
about
to
be
released
from
behind
a
feature
flag.
Once
we
finished
the
testing
that
the
access
group
has
been
doing
on
it.
So
what
it
is
is
it's
currently
connected
to
our
SSO
sam'l
configuration.
So
in
order
to
enable
group
managed
accounts,
you
have
to
enable
configure
and
enable
sam'l
SSO.
So
you
need
an
identity
provider
to
be
able
to
utilize
this
feature.
So
you
already
get.
D
You
already
have
the
ability
to
manage
your
users
accounts
through
your
ant
identity
provider,
but
that
doesn't
mean
they're
able
to
fully
manage
their
accounts
through
your
github.com
group.
So,
for
example,
a
user
may
be
part
of
your
group
and
they
it
may
also
be
a
member
of
your
identity
provider,
but
that
that
user
is
a
user
on
get
our
comm,
so
they
may
be
able
to
go
and
do
other
things
on
get
love
comm
if
they
want
to
outside
of
your
group.
D
So
the
goal
of
managed
accounts
is
to
allow
better
isolation
and
control
over
those
users
for
group
owners.
So
I
select
an
in
control
are
the
two
main
problem
areas
that
we're
trying
to
focus
on
at
the
moment
in
the
space
is
group,
and
one
thing
that
we're
actually
focusing
on
now.
Now
that
group
accounts
is
about
to
be
released
as
it
currently
is,
which
is
connected
to
samurai.
So
so
is
we
want
to
be
able
to
extend
that
to
other
groups
that
may
not
have
a
configured
identity
provider?
D
So
you
still
want
those
enterprise
customers
to
be
able
to
have
some
some
element
of
control
over
the
users
that
are
actually
accessing
their
group
and
extending
group
managed
accounts.
All
groups,
I
think,
is
a
good
first
step
to
do
that.
The
way
we're
going
to
do
that
in
12.10
is
we're.
Gonna
work
on
decoupling,
SSO
from
group
managed
accounts
on
the
backend,
we're
going
to
spend
some
time
waiting
for
some
feedback
seeking
out
some
feedback.
D
Some
customers
that
are
using
current
configuration,
which
is
SSO,
sam'l
plus
group,
managed
accounts
in
its
current
state
and
we're
also
going
to
work
on
introducing
a
administration
menu
for
group
owners
which
will
contain
the
current
configuration
settings
for
SSO,
samel
and
group
managed
accounts
and
will
also
provide
us
a
location
so
that
we
can
start
introducing
things
like
more
comprehensive
user
management
which
currently
isn't
something
we
provide
as
a
great
solution
to
enterprise
focus
on
sass
offering.
So,
hopefully
these
will
be
some
big
improvements
going
forward
over
the
next
few
months.
Questions.
A
D
Yeah,
it's
a
good
question.
There
isn't
gonna,
be
a
new
role
for
it
at
the
moment.
This
is
just
going
to
be
a
new
administration
menu
for
group
owners
and
it's
not
changing
anything
as
yet.
All
we're
doing
is
we're
bringing
settings
that
currently
exist
under
the
general
settings
menu
and
making
it
more
discoverable
for
folks
that
behave
as
administrators
of
their
group.
B
A
Here,
like
I,
don't
like
we're
adding
like
administration
for
group
owners.
That's
that's
very
cool.
Like
we're,
gonna
I
know,
look
I
know
you
have
big
plans
and
like
where
you'd
like
to
take
that,
but
I
think
that's
gonna
be
hugely
exciting,
especially
for
users.
I'm
Caleb,
comm,
I
love,
it
mm-hmm.
D
D
C
B
It's
this
one
should
be
MVC,
apply,
complaints,
project
topics,
okay
yeah,
so
for
the
compliance
group,
our
focus
is
largely
around
the
compliance
dashboard
and
audit
management.
I
would
say
the
two
themes.
The
the
first
issue,
we're
looking
at
is
an
MVC
for
basically
helping
our
customers
with
labeling
their
projects,
because
part
of
the
challenge
we've
had
lately
with
some
implementations
is
that
how
do
you
apply
certain
settings
or
enforcement's
to
projects
that
you
know
might
be
the
minority
of
the
larger
project
set?
B
The
compliance
frameworks
that
we
find
are
the
most
common
on
our
platform
and,
if
you
label
a
project
with
one
of
these
topics,
we'll
track
basically
track
that
label
so
that
we
can
eventually
do
things
like
report
on
it.
In
the
compliance
dashboard
to
show
you
data
around
those
projects,
their
compliance
status,
things
like
pipeline
results,
those
sorts
of
things,
but
it
also
gives
us
an
ability
to
give
better
flexibility
or
control
over
applying
those
enforcement
settings.
B
So,
in
twelve
eight
as
one
example,
we
gave
admins
the
ability
to
restrict
merge,
request
approval
rules
in
all
projects,
but
that's
a
little
too
broad
and
we'll
do
heavy-handed.
So
this
would
enable
us
to
build
out
an
experience.
It
says
yes
apply
this
strict
enforcement
only
for
projects
that
are
labeled
with
Sox
or
HIPAA
topics
as
one
example,
so
we
felt
this
was
a
fundamental
building
block
for
a
few
different
areas
in
the
compliance
group
and
so
just
to
give
kind
of
a
quick
little
example
of
that
this
project
view
on
the
right
side.
B
Here
is
what
we'd
like
to
try
to
manifest
in
the
current
projects
listing.
So
when
you
go
and
view
all
the
projects
in
your
group,
you
could
see
at
a
high
level
these
project
topics.
When
you
click
into
the
project,
it
would
be
visible
there
as
well
and
then
in
the
compliance
dashboard
with
just
a
which
this
is
a
rough
prototype,
for
this
is
how
we
could
surface
those
insights
at
that
higher
level.
A
B
So
for
the
compliance
dashboard
as
far
as
surface
surfacing
those
insights,
we
would
be
looking
for
those
specific
topics.
So
if
a
project
has
of
these
seven
or
eight
predefined
ones
and
we'll
pull
it
into
this
view,
if
it
doesn't
have
one
of
those,
we
won't
pull
it.
In
this
view,
that's
the
initial
plan
anyway.
Thank.
B
B
Several
of
our
conversations
with
customers
have
largely
been
around
this
idea
of
aggregating
what
they
consider
to
be
kind
of
these
key
data
points
around
compliance
and
so
kind
of
the
long
term,
vision
or
goal
for
the
compliance
dashboard
is
the
the
stakeholder
or
the
the
user,
whose
day-to-day
job
or
common
ask
of
them
involves.
These
asks
from
their
internal
or
external
auditors
is
by
living
on
this
page.
The
compliance
dashboard
view
they
can
answer
all
of
the
important
questions
that
are
being
asked
to
them.
B
If
we
can
build
this
out
to
the
point
where
they
never
have
to
leave
that
page
to
do
that,
part
of
their
job
I.
Consider
that
a
win
and
that's
kind
of
my
my
hierarchy
and
goal
for
this,
but
part
of
that
is
aggregating.
This
type
of
data
there
and
one
of
the
challenges
here
is
that
there
can
be
several
pipelines
associated
with
the
merger
quest
and
trying
to
navigate
what
do
we
show
what's
relevant?
B
D
D
That's
a
really
nice
thing
to
highlight,
because
it's
I
mean
our
product
is
a
you
know,
it's
a
it's
a
one
tool
for
everything,
so
kind
of
extending
that
even
further
and
saying
like
you,
don't
need
to
leave
this
product
to
do
your
job
day
to
day,
like
just
highlighting
little
features
like
that
that
make
that
goal
a
little
bit
more
clear,
I
think
is
really
cool.
Yeah,
good
yeah.
B
Thank
you
thank
you
both
and
the
so.
The
third
issue,
we're
focused
on
four
twelve
ten,
is
going
to
be
this
concept
of
essentially
simplifying
and
automating.
These
repeatable
workflows.
What
we
found
is
that
there's
a
pain
point
around
trying
to
manage
evidence,
artifacts
and
collecting
this
data
that
our
day
to
day
users
are
being
asked
for.
B
B
So
right
now
it
solves
a
few
different
problems
in
that
experience
and
that
you
may
want
your
auditors
to
have
access
to
get
lab
for
the
purposes
of
maybe
managing
the
audit
or
collecting
evidence
and
aggregating
at
one
place.
But
you
maybe
don't
want
them
to
have
additional
permissions
and
make
particular
projects.
So
this
isolates
the
project
and
the
work
that's
happening
there.
You
might
as
a
get
lab
user
after
you've
gone
through
the
painstaking
process
of
finding
all
of
this
data.
B
It
might
be
easier
to
simply
into
one
of
these
issues,
that's
already
in
the
gitlab
application,
and
then
you
know
exporting
that
to
send
it
to
your
auditor
or
telling
your
auditor
hey
log
in
and
go
view
it
it's
updated.
So
you
can
take
advantage
of
some
of
these
simplified
workflows
that
help
you
to
your
point.
Lucas
stay
within
get
lab.
That's
a
it's
an
environment,
you're
familiar
with
you
can
leverage
things
like
labels
milestones
due
dates.
B
All
of
that,
but
ideally
it's
all
about
that
long-term
goal
of
automating
as
much
as
we
can
so
that
the
date
of
the
users
of
guilt,
I,
don't
have
to
worry
about
it.
It's
no
longer
a
headache.
It's
I
don't
have
to
worry
about
it.
It's
all
just
taken
care
of
I,
see
that
this
is
all
being
put
into
those
issues
and
it's
just
simpler
for
everyone.
B
A
B
B
Their
primary
responsibility
is
doing
kind
of
like
a
day
to
day
or
week
to
week
type
of
audit
to
make
sure
that
the
thing
what
we
say
we
do,
which
is
our
policies,
are
actually
put
into
practice
and
collecting
evidence
to
prove
that,
and
so
they
might
ask
me
for
a
semi,
the
merger
quest
artifact
or
the
the
release
artifact.
For
that
last
push
that
we
made
to
production
show
me
the
audit
logs
for
the
last
three
weeks
of
login
failures
and
successes.
B
Show
me
the
password
reset
and
like
take
a
screenshot
of
that
take
a
screenshot
of
the
pipelines,
and
so
it's
it
can
range
in
terms
of
what
that
evidence.
Artifact
is
or
plural
what
they
are,
because
it's
every
organization
is
going
to
approach
it
differently.
But
ultimately,
what
they're
trying
to
do
is
collect
all
of
the
proof,
to
then
hand
off
to
an
external
auditor,
because
it'll
always
be
a
third
party,
independent
auditor
to
say:
here's
proof
that
we're
meeting
the
controls
of
this
external
framework
like
PCI.
B
A
When
someone
goes
ahead
and
Korea
I'm
thinking
like
so,
we
have
a
hundred
eighty
issues
and
we've
done
someone
a
human
being
go
in
and
create
and
comment
or
add,
whatever
evidence
that
they
need
to
meet
whatever
particular
like
issue
is
created
at
that
point,
I
wonder
like
what
are
they?
How
do
they?
How
do
we?
A
That's
in
the
issue
like
the
issue
tracker
into
like
a
CSV
or
some
type
of
like
structured
format,
then
you
can
Det.
Then
you
can
add,
handle
an
auditor,
so
you
could
say:
hey
here's
all
the
issues
like
human
beings
work
on
them
once
we're
done,
and
we're
kind
of
like
ready
to
hand
this
off
just
to
a
third
party
click
this
button
and
then
hand
them
this
file
and
then
you're
done
yeah.
B
B
That
is
another
added
benefit.
Is
you
could
archive
the
project
or
maybe
close
the
issues
and
reopen
them
later,
and
that
also
maintains
its
own
kind
of
audit
audit
audit
trail
right,
an
audit
trail
of
the
audit,
so
you
can
even
pull
last
year.
So
if
I'm
doing
this
annually
or
even
quarterly
I
can
look
back
to
the
previous
evidence
and
say:
actually
you
know
what
that's
still
applicable.
Let
me
pull
that
over
and
so
you
end
up
saving
a
lot
of
time
in
that
way
as
well.
B
E
My
planning
issues,
so
we
have
two
issues
that
are
tied
to
our
direction.
That
I
want
to
talk
about.
I
also
want
to
just
talk
a
little
bit
about
the
longer-term
vision
for
import
and
in
this
in
in
twelve
ten,
we
plan
to
start
gathering
some
of
the
metrics,
as
well
as
doing
some
New
York's
discovery
that
is
going
to
inform
future
milestones.
So
that's
one
of
the
one
of
the
goals
for
1210
for
us
is
actually
to
get
data
now,
so
we
could
use
it
to
to
plan
better.
E
Our
feature
milestones
that
said:
we're
gonna
have
some
bias
for
action
to
and
not
wait
until
all
the
research
has
been
done
to
actually
move
some
things
forward,
especially
some
things
where
we
know
we
can.
Actually,
we
can
make
some
some
quick
improvements,
so
the
the
first
issue
I
want
to
talk
about
is
just
the
user
experience
for
creating
the
project.
This
is
part
of
the
overall
rethinking
of
the
user.
Experience
for
for
the
import-
and
you
know
I
sale-
is
that
every
users
is.
E
It
deserves
a
great
user
experience,
including
user
who's,
just
like
one
time
importing
something
into
good
club,
and
sometimes
especially
that
user,
because
that
is
the
first
first
impression
they
might
have
of
good
lab
could
be
them
trying
to
move
their
work
into
good
lab,
and
we
want
that
first
impression
to
be
a
great
one
for
the
user,
so
parts
a
part
of
that
user.
Experience
is
really
this
one
view
that
we
have
when
we
create
a
new
project.
E
Just
kind
of
you
know
a
user
who
lends
here
and
there's
a
lot
of
text
and
there's
some
fields
and,
and
then
the
green
button
people
tend
to
just
follow
the
visual
cues,
and
one
of
you
know,
like
a
main
queue
on
this
view,
is
that
I
need
to
type
in
the
project.
Name.
I
need
to
maybe
add
a
description,
make
a
decision
whether
this
is
private
in
public
and
then
hit
the
green.
E
But
if
you
do
that,
you
have
actually
missed
your
opportunity
to
import
your
data
from
from
wherever
it
is
right
now
and
you'll
also
miss
the
opportunity
to
create
to
create
a
new
project
from
a
template,
because
that
choice
is
no
longer
available
as
soon
as
you
create
the
project.
So
you
know
you
may
have
known
you
may
or
may
not
have
noticed
these
so
a
lot
of
times.
If
you
don't
notice,
the
tabs
you'll
end
up
creating
a
project,
and
you
will
no
longer
have
the
ability
to
do
that.
E
If
you
have
noticed
these
tabs,
you
can
also
make
an
assumption
that
this
is.
You
know,
wizard
a
type
of
checkout
experience
online,
where
you
know
you
are
going
to
be
taken
from
tab
to
tab
and
you're
gonna
fill
out
a
lot
of
things.
Eventually,
your
project
will
be
created.
E
Like
you
know,
once
you
fill
this
out,
hit
the
green
button,
you
will
no
longer
be
able
to
do
that
so
trying
to
sort
of
see
what
a
small
change
would
be
that
could
counteract
you
know
this
user
experience
we
kind
of
come
up
with
a
an
approach
where
at
the
very
base
this
is
a
mock-up,
we're
gonna.
You
know
we're
gonna
get
a
better
they're.
E
Looking
design
soon,
but
this
is
sort
of
the
flow
that
we're
thinking
about-
and
that
is
you
know
from
the
very
top
level
view
you're
presented
with
several
larger
choices
that
all
look
equal
to
each
other
and
you
kind
of
have
to
make
a
selection.
Whether
this
is
a
new
empty
project.
Is
this
or
is
this
coming
from
an
import
and
we're
still
toying
sort
of
with
whether
the
templates
are
going
to
be
a
top-level
choice
here?
So
there
would
be
a
blank
project
template
import
right
now.
E
The
mock-up
shows
shows
this
differently
as
in,
if
you
select
a
new
project,
your
choices
are
then
to
either
start
a
blank
project
or
a
project
that
starts
with
a
template,
still
haven't
finalized
the
choice
there
of
how
that's
gonna
flow.
But
the
idea
is
that
we're
gonna
present
the
user
with
the
choices
so
that
they
is
as
obvious
to
them
that
it's
going
to
be
either
going
down
the
path
of
creating
a
new
project
or
going
down
this
other
path
of
importing.
E
And
it's
not
you
know,
and
once
they
make,
that
conscious
choice
is
we're
hoping
to
actually
be
able
to
catch
more
people
who
are
thinking
about
importing
and
you
know
and
we're
gonna
help
and
avoid
going
down
the
wrong
path
in
the
flow.
So
that's
the
change,
if
we're
thinking
about
doing
and
in
this
release,
to
kind
of
keep
the
ball
moving
and
have
the
biased
or
inaction
while
we're
still
doing
some
of
the
larger
research
around
exactly
how
all
this
is
gonna
play
out
is
some
of
the
some
of
the
imports
happen
here.
E
E
E
So
the
solution
that
we
want
to
have
the
full
solution
is
to
have
one
place
where
you're
gonna
be
able
to
specify
which
group
which
subgroups
projects
you
know,
specify
a
subset
or
your
entire
set
of
data
in
one
good
lab
instance
and
migrate
that
to
another
instance
of
get
lab
one
to
one
where
everything
is
going
to
arrive
there.
Your
projects,
your
groups,
your
settings,
picture
issues,
everything
there
right.
So
that
is
the
big
vision
and
you
know
in
in
1210,
and
this
particular
issue
we're
going
to
find
the
smallest
change.
E
We're
still
teasing
out
the
details,
but
we're
gonna
try
to
actually
expose
or
hide
the
API
or
to
put
the
API
calls
that
you
can
currently
make
behind
the
button
that
looks
similar
to
how
a
new
project
works
so
similar
to
being
able
to
say.
Okay
I
want
to
do
a
good
lab
export.
You
should
be
able
to
the
for
a
group
when
you
create
a
new
group.
E
That
solution
is
might
be
potentially
temporary,
so
we
will
make
this
change
and
then
once
we've
finalized
our
UX
research.
The
experience
might
still
change
from
this
solution,
but
we
actually
want
to
make
move
in
that
direction,
to
to
start
sort
of
building
the
ability
to
move
groups,
from
instance,
to
instance,
into
good
labs.
So
this
will
be
that
MVC
with
the
user
experience
that
takes
you
step
away
from
the
API,
so
thoughts
and
questions
on
sort
of
what
we're
approaching.
A
Think
it's
super
interesting
I
think
that
the
new
project
creation,
page
I,
believe
when
I
looked
at,
which
pages
users
use
the
most
that's
I,
think
top
three,
all
the
most
common
things,
a
user
does
and
there's
a
lot
of
room
for
improvement.
So
I
love
that
you're
thinking
they
were
thinking
about
the
UX
more
fundamentally
and
how
we
can
improve
it.
A
Thanks
for
sharing
the
the
envision
prototype,
even
though
it's
a
bit
early,
one
thing
that
I
linked
an
issue
in
the
in
the
agenda
doc
for
the
manage
kickoffs
under
under
any
questions,
and
one
thing
that
I
wanted.
I
just
wanted
to
show
you
this
issue,
which
was
something
that
we
did
a
long
time
ago
on
new
when
we
were
doing
new
project
flow
exploration
and
I'll
I'll
hijack
screen
share
for
just
a
second.
A
This
is
about
a
year
ago
or
so,
and
when
we
did
this,
but
we
were
trying
to
understand
how
we
can
improve
floo.
So
there's
some
information
here
and
some
notes
and
some
journey
mapping
here.
That
might
be
interesting
once
that
one
idea
that
I
had
was
I
was
inspired
by
Google
Docs.
A
So
whenever
like
we
have
a
choice
or
the
ability
to
consider
how
we
can
remove
steps
from
the
process,
we
should
kind
of
definitely
consider
that,
like
this
might
be
one
of
those
opportunities
where,
like
you,
click
on
new
project
boom,
you're
in
a
repository
and
then
within
that
flow,
you
can
say
like.
Oh
actually,
I
want
to
import
from
a
source
and
then
you
can
click
on.
A
But
if
you're
happy
with
the
blank
project
as
many
users
are,
you
can
navigate
away,
and
we
just
assume
that
that's
you
know
you're
gonna
do
that
and
use
a
blank
project.
You
can
say
like
oh,
but
you
can
also
use
a
template
like
to
import
stuff
and
pull
that
information
into
this
repo,
or
you
can
also
use
it.
You
know
import
from
another
source
or
something
but
immediately
they're
getting
value
without
having
to
kind
of
like
struggle
through
that
typing.
A
E
A
great
idea-
and
you
know,
I'm
a
big
fan
off
some
of
those
websites
where
you
can
just
go
and
start
prototyping
things
without
ever
giving
it
an
email
or
signing
up
or
doing
anything.
You
like
you,
you
you
go
there,
you
lend
and
it's
already
editable
and
it's
ready
to
go
and
then
later
on,
I
can
solve
for
all
these
other
things
do
I
need
to
move
something
in
do
I
need
to
sign
up
for
it.
I
need
to
save
it
like
we'll
figure
that
out,
but
here
just
start
working
right
now.
E
This
is
a
great
great
way
to
go
so
I
like
that
I
think
so
we
gave
this
some
thought
actually
and
I.
Think
what
we're
gonna,
where
we
want
to
get,
is
the
ability
to
merge
projects
really
because
at
that
point,
if
you
already
started
some
work-
and
you
have
some
of
the
data
in
the
project
that
you
have
any
kind
of
an
import
is
going
to
merge
additional
data
into
it.
So
we
do
want
to
be
able
to
do
that.
E
I
think
it's
very
restrictive
right
now
that
the
only
place
where
we
let
you
import
or
apply
template
is
you
know
before
we
even
create
the
project.
I
think
we
should
be
able
to
do
it
further
down
like
once
the
project
is
created.
We
should
be
able
to
still
get
your
data
into
it.
On
top
of
that,
so
I
do
think
that's
a
great
final
goal
and
I.
Definitely
like
the
user
experience
of
hey.
You
know
you
wanna,
you
want
to
work.
E
Here's
a
here's,
a
repo
here
as
a
board
everything's
empty
just
you
know,
put
an
issue
here
and
start
putting
files
there
or
whatever
or
we'll
put
just
a
readme
file
in
there
for
you
and
you
just
get
going
and
then
we'll
ask
you
for
what's
your
project
name
later,
who
you
are
and
all
these
things
we
can.
We
can
figure
this
out
along
the
way,
but
we
want
you
to
get
going
with
the
work
so
yeah.