►
From YouTube: Ops Cross-Stage ThinkBig! - Auto DevOps
B
Everyone
and
welcome
to
the
cross
stage
think
big
for
the
ops
section.
This
is
a
chance
for
all
of
us
in
strategy
side
of
things,
so
design
and
product
management
to
come
together
and
talk
about
some
of
the
bigger
larger
scale.
Cross-Stage
issues
that
we're
trying
to
work
through
today,
nadia
and
maria,
have
something
really
interesting
to
talk
about.
So
I'm
going
to
pass
up
nadia
to
get
us
started
with
that.
C
C
But
I
don't
have
a
very
good
understanding
of
you
know
like
all
of
the
nitty-gritty
details
of
how
autodevops
works,
its
shortcomings
and
so
on.
So
basically
the
goal
of
this
meeting.
The
way
I
envision
it
is
to
give
everyone
a
chance
to
express
their
thoughts
and
ideas
around.
What
are
the
problems
that
we
have?
What
is
autodevops
and
what
is
your
vision
for
the
future,
and
how
do
you
think
we
could
leverage
it
so
kind
of
discuss
the
problems
and
the
ideas
around
it?
And
then
hopefully,
we
can
also
identify.
C
In
autodevops
and
discuss
how
we
could
further
calibrate
on
it,
I
know
that
product
has
been
having
lots
of
conversations
around
it.
There
there's
now
talk
about
moving,
auto
devops
to
the
pipeline
authoring
team,
so
yeah
we
can.
We
can
get
to
that,
but
I
wanted
to
get
started
with
just
talking
about
the
problems
that
I
see
from
from
the
user
experience
from
the.
C
C
Talking
about
the
three-year
vision
for
pipeline
authoring-
and
we
would
talk
a
lot
about
automation
and
how
we
want
to
make
pipeline
authoring
as
automated
as
possible
eventually.
So,
if
we're
talking
about
a
job
to
be
done
that
we
have
at
pipeline
authoring,
so
I
want
to
author
a
cic
pipeline.
So
I
can
automate
tasks
on
my
team
and
if
we
start
diving
deeper,
one
of
the
user
stories
might
be
when
I'm
authoring
my
cic
pipeline.
C
I
want
that
process
to
be
as
automated
as
possible
to
make
my
job
easier,
to
make
it
easy
and
quick
to
create
a
cic
pipeline
for
my
project
that
meets
my
needs
and
it
seems
like
autodevops
attempts
to
solve
a
similar
problem,
maybe
for
like
a
kind
of
a
narrow
subset
of
our
users
who
are
who
use
certain
platforms
and
so
on.
But
it
does
provide
that
automation
component,
but
currently
it's
very
disconnected
from
the
cicd
workflow.
So.
C
You
can
see
that
I
linked
this
issue.
It's
called
align
the
user
experience
for
autodevops
and
ci
cd
and
they're,
like
I
haven't,
proposed
any
solutions
basically
just
wanted
to
narrow
down
on
that
problem
and
define
that
problem,
and
it
seems
like
there
are
some
other
teams
that
also
have
an
interest
in
other
devops.
So
maria
perhaps
can
talk
more
or
justin,
or
someone
else
can
jump
in
to
talk
more
about
auto
devops
and
security
and
yeah
there
were.
There
were
some
other
problems
that
were
added
to
the
problem
section.
A
A
A
It
has
the
potential
to
be
something
that
is
very
transformational
for
gitlab
as
a
single
devops
platform,
it
kind
of
spans
many,
if
not
all,
of
our
stages
and
it
what
it
can
be
is,
if
you
think
about
today
our
process
of
asking
a
customer
to
use
our
tool
involves
like
if
we
say.
Oh,
you
want
to
use
review
apps.
You
have
to
kind
of
write
this
very
toilsome
yaml
to
directly
configure
exactly
how
you
want
to
use
review
apps.
A
If
you
want
to
james-
and
I
were
talking
about
today,
if
you
want
to
make
sure
you're
using
using
our
junit
test
report
widget,
you
kind
of
have
to
like
go
and
configure
this
very
prescriptive
yaml,
and
you
might
not
even
be
aware
that
that's
something
you
could
do
and
autodevops
has
the
potential
to
really
expand.
The
completeness
of
our
platform
and
make
it
easy
for
our
users
to
expand
the
completeness
of
their
use
of
our
platform
by
being
smart
about
when
to
showcase.
A
Like
oh,
hey,
here's
something
super
simple
you
could
do
to
add
to
your
pipeline
or
we
either
automatically
added
that
by
default.
It
kind
of
gives
the
notion
of
today
we
make
our
our
users
navigate
through
this
kind
of
forest,
to
figure
out
how
to
get
to
their
complete
devops
pipeline.
It
can
make
that
a
lot
easier,
and
so
I
it's
that's
important
for
our
users,
because
it
means
they're
getting
the
satisfaction
of
not
having
to
go
through
that
toil.
A
It
also
means
that
they
get
the
satisfaction
of
using
things
that
they
wouldn't
have
discovered.
Otherwise,
it's
super
satisfying
to
us
as
a
business,
because
it
it
increases
our
stages
per
user,
which
we
know
increases
the
likelihood
of
customers
to
increase
their
tier
and
also
increases
their
stickiness
with
our
platform
going
forward.
So
it
is
very
like
transformational
in
my
mind
and
to
date
we
have
we
created
it.
A
If
some
of
the
history
of
autodubs
is
we
created
it
for
a
very
like
a
visionary
purpose
to
say
this
is
where
gitlab
is
headed
and
I
think
we've
not
necessarily
pushed
that
vision
significantly
forward,
but
there's
a
lot
of
room
to
grow.
One
thing
that
sam,
I
think
put
in
in
one
of
the
mrs,
this
analogy
is
really
really
apt.
Before
we
had
google
maps,
we
would
think
oh
the
way
that
I
figure
out
how
to
get
from
kansas
city.
A
A
I
want
to
go
from
kansas
city
to
los
angeles
and
it
routes
you
around
the
tr,
the
the
wrecks
it
finds
where
you
should
stop
to
get
gas
like
that
kind
of
smarts
is
what
we
should
be
thinking
about:
auto
devops's
vision,
and
so
I
want
to
make
sure
that
we
ground
ourselves
in
that
there's
a
lot
of
questions
about
how
it
works.
Today.
What
works?
What
doesn't
work
but
there's
a
lot
of
potential
value
and
vision
in
where
we
can
take.
E
This
now,
if
I
can
add
from
a
ux
perspective,
I
think
autodevops
is
super
useful
and
we
can
have
a
great
vision,
but
at
the
moment,
in
the
ui,
it's
really
disconnected
it's
really
hard
to
understand
what
it
is,
how
to
use
it.
What
benefits
it
gives
you
so
we
have
in
settings.
You
can
enable
the
devops
for
a
project,
then,
in
my
knowledge,
to
work
with
a
cluster,
you
have
to
go
to
the
cluster
and
set
your
dns
and
there's
no
link
between
these
two
steps
and
then
for
the
icd.
E
F
Here's
a
left-field
thing:
should
we
even
be
considering
this
within
the
context
of
using
the
word
auto
devops?
Is
that
locking
us
into
what
it
is
today?
Should
we
just
be
locking
it
into
more
as
a
user?
We
want
them
to
turn
on
everything.
How
do
we
get
them
there,
because
that's
really
what
kenny's
saying
auto
devops
should
be
so
maybe
back.
A
D
D
D
So
it's
like
that's
that's
how
I
envision
autodevil.
So
it's
really
automatic.
It's
really
magical,
and
if
you
want
to
learn
more,
what's
going
behind
the
scenes,
then
I
would
make
it
obvious,
so
I
wouldn't
hide
it
as
behind
it
today,
but
I
would
provide
you
the
all
the
ci
templates
or
whatever
we
put
there,
because
you
might
want
to
customize
it
or
you
might
want
to
add
something
to
it,
which
means
that
we
did
not
fulfill
our
promise.
But
that's
the
that's
the
idea.
G
It
may
have
grown
old
and
we've
ruined
it
by
it,
not
working
right,
but
it's
also
might
be
something
where
we
have
some
cachet
already,
where
people
recognize
it
as
the
tool
in
get
lab.
That
does
all
of
these
things.
So
maybe
there
is
some
marketing
value
still
keeping
the
name.
That
might
be
something
to
consider.
D
H
And
we
also
need
to
think
about
who
is
coming
in
to
our
tool,
so
I've
talked
to
people
who
don't
do
auto
devops,
not
really
quite
sure
what
it
is,
but
they
could
benefit
greatly
from
it,
but
they
just
don't
do
it
currently
in
their
company.
It's
not
a
process
that
their
team
or
their
manager
supports.
H
So
how
would
we
want
to
give
them
the
magic
but
also
inform
them?
Hey,
it's
not
just
get
lab
magic
like
we're.
Also
doing
this
thing
called
autodevops
and,
on
the
other
end
for
those
who
are
used
to
it,
how
do
we
support
their
expectations
of
doing
things
that
fall
under
the
auto
devops
category
and
make
it
seem
like
magic
and
then
also
point
them
to
where
they
can
learn
more
about
this
magic
if
they
need
to.
D
I
would
add
one
more
point
to
this
is
that
I
made
quite
a
few
interviews
as
well,
and
what
I've
heard
is
that
people
who
think
they
use
autodevops
they
actually
don't
so
that
that's
how
they
exist
as
well
seriously.
Whenever
I
was
looking
for
users
who
were
recommended
to
me
by
solution,
architects
or
tams
that
look,
you
can,
if
you
want
to
run
some
interviews
with
out
of
those
users
interview
them,
and
I
did
the
interview
and
it
turned
out.
I
I
think
this
is
the
main
problem
we
have
right
now
is
it's
either
it's
magic
and
it
works
or
then
you
have
nothing,
because
when
you
move
from
this
is
magic
and
it
works
out
of
the
box
to
it
doesn't
work.
I
need
to
dig
into
it.
You
have
a
huge
amount
of
things
to
deal
with,
and
this
is
a
huge
barrier
to
me
and
honestly,
we
have
we
had
a
ton
of
project
we
wanted
to
enable
to
devops
and
it
didn't
work.
I
So
having
a
more
composable
approach
will
help
us
probably
to
achieve
that
quicker
than
trying
to
make
it
work.
Because,
honestly,
I
might
lack
ambition
about
that,
but
I
don't
think
there
is
a
place
where
we
can
have
this
working
out
of
the
box
for
every
project,
particularly
when
it
comes
to
the
secure
features
we
have
tons
and
tons
of
integration
issues
because
of
the
very
various
environments
a
project
can
run
in
and
I'm
not
sure
there
is
a
one
day
where
we
could
support
them
all
out
of
the
box.
Well,.
F
Backing
up
because
I
asked
this
in
product
multiple
times
and
I
never
really
got
great
answers,
but
we
use
variables,
project
level
variables
today
to
try
and
determine
some
things
and
I
almost
feel
like
we
don't
have
enough
of
them.
So
if
we
look
at
the
first
job
to
be
done,
when
I
start
a
new
project,
I
want
to
get
up
and
running
as
quickly
and
easily
as
possible.
F
So
would
kind
of
the
concept
of
this
magical
solution.
Be
that
we,
because
I
know
like
we're
talking
about
a
one-click
solution,
but
if
we
wanted
to
be
a
little
more
realistic
what
if
it
was
like
a
multi-click
solution
where
you
kind
of
came
in
and
said,
I
want
to
set
it
up
and
it's
like
we've
run
some
kind
of
detection
against
whatever
it
is
you're
doing
and
say:
hey!
Here's
like
a
pretty
map
of
what
you
have
so
think
like
pipeline
view,
but
way
fancier
like
here's.
Here's
what's
currently
going
to
happen.
F
We
can't
quite
tell
where
you're
deploying
to
are
you
deploying
to
aws
or
azure?
Can
you
tell
us
a
little
bit
about
that,
because
that
doesn't
seem
to
be
configured
yet
and
hey?
It
seems
that
you,
you
know
don't
have
like
you
know.
We
want
to
automatically
turn
on
dast
and
sas,
but
you're
not
using
review
apps,
which
will
disable
dast.
F
So
did
you
want
to
turn
on
review
apps
and
just
kind
of
like
prompt,
you
kind
of
like
someone
was
saying,
show
them
what's
going
on
behind
the
scenes
like
say:
here's
all
the
the
journey
that
you're
going
to
currently
go
through,
but
we
can't
help
you
here
here
and
here
until
we
get
the
piece
of
information
about.
Are
you
going
to
azure?
A
And
the
question
is
like
today
we
say:
autodevops
is
this
thing
that
it
should
just
automatically
work
for
everything
until
avia's
point?
That's
not
realistic.
What
we
should
be
saying
is
we're
here
to
like
just
like
the
clippy
example,
which
I
hate.
It's
like
we're
here
to
help.
You
evolve
like
you've
gotten
to
this
point
where
hey,
maybe
it
makes
sense
for
you
to
add
this
additional
sas
scanner,
but
like
we're
informing
you
about
it,
it's
a
it's.
A
huge
product,
discovery
capability
too
for
us,
but
yeah.
A
It's
not
gonna
immediately
just
work
out
of
the
box,
and
you
know
we
have
worked
around
that
fact
in
other
devops
for
a
long
time,
because
you
don't
want
your
first
pipeline
run
to
be
40
minutes
long.
So
we
have
like
scoped
down
and
made
concessions
in
that
regard,
but
we
can
think
about
it
like
this
is
a
journey.
Our
users
are
on
a
journey.
They
don't
need
the
whole
devops
pipeline
today,
but
they
need
to
get
started
and
we
need
to
guide
them
on
steps
as
they
go.
G
B
G
B
Yes,
I
agree
with
that
wholeheartedly.
One
thing
I
wanted
to
call
out
is
for
the
package
users,
who
tends
to
be
a
later
stage
transition
when
it
comes
to
devops
in
general,
we've
heard
the
same
thing
of
if
we
presented
them
with
the
idea.
We
saw
you
publish
packages
in
ci
and
then,
if
you
just
click
this
button,
we'll
automatically
set
up
a
registry,
and
you
can
just
try
it
we're
not
going
to
blow
anything
up
we're
just
going
to.
B
Let
you
see
what
it's
like
and
we've
heard
consistently
from
users
that
that
would
enable
them.
Usually
it's
the
story
of
it
would
enable
an
engineer
to
show
their
devops
manager
at
their
company
that
it's
actually
a
really
useful
idea
and
to
just
do
it,
because
this
is
all
it
takes,
and
I
would
imagine
that
story
is
pretty
similar
to
what
some
of
the
other
folks
have
heard.
J
D
What
I've
heard
from
the
best
salespeople,
I
know,
is
that
they
actually
don't
tell
anything
to
their
prospects.
They
just
ask
from
their
prospects
what
they
want
and
then
repeat
what
they've,
what
they've
heard-
and
I
think
we
could
build
a
similar
thing
with
around
autodevops
as
well-
is
that
we
don't
have
to
figure
out
with
amazing
logic
and
ai
and
machine
learning
and
all
the
nicely
things
that
yeah
these
people
are
building
packages.
No,
we
could
ask
them
when
they
create
a
project
that
are
you
publishing.
D
Do
you
want
to
publish
a
package
out
of
that
and
if
they
say
yes,
then
you
can
say
in
this
case
here
we
go
and
that
or
is
something
that
that's
easy
to
kind
of
automate,
because
they
told
us
that
I
want
to
publish
a
package
and
it's
a
great
that's
a
point
as
well
for
us
actually
when
they
create
the
project
that
we
can.
We
know
what
kind
of
projects
are
running
on
gitlab
and
what
target
it
is.
Is
it
container?
Is
it
specific
something-
and
I
mentioned
that
comment-
that's
really
cool.
G
And
and
nadia
brought
up,
brad
downey
had
an
interesting
post
on
one
of
those
issues
where
he
walked
through
a
series
of
steps
or
questions
that
we
would
sort
of
ask
the
user
once
they
kicked
off
a
project.
You
know
which,
which
is
similar
to
what
I
think
you're
getting
at
victor
and
to
me
it
does
feel
like
this
is
an
out
of
box
experience,
sort
of
set
up
scenario
where
we
do
as
much
as
we
can
to
understand
what
they've
got.
G
E
I
wanted
to
take
it
a
step
back
because
when
I
joined
and
people
were
explaining
all
the
devops
to
me
and
also
at
the
commit
in
london
users
said,
I
wouldn't
use
other
devops,
because
I
want
to
have
more
well
ownership
of
and
all
the
complex
pipelines
and
setups.
So
I'm
wondering
is
the
direction
we
are
discussing
for
all
personas
and
types
of
companies.
H
And
is
that
the
same?
Is
that
the
same
persona,
though
all
the
way
through,
because
some
smaller
companies
tend
to
have
more
generalists,
larger
companies
tend
to
have
more
specialists?
So,
as
you
look
at
changing
things
and
optimizing
things,
does
that
change?
Is
that
still
your
sasha
software
person
devops
engineer
person,
or
is
it
going
to
change
to
somebody
else?.
D
D
So
that's
the
that's
the
the
magic
there
from
the
developer's
point
of
view
from
the
let's
say,
gitlab
engineers,
point
of
view
who
is
who
sets
up
the
pipelines
and
all
these
things
from
their
point
of
view.
They
they
create,
they
configured
everything
but
how
they,
how
to
use
cells,
whether
containers
are
allowed
or
something
is
denied
by
definition
and
the
same
jobs
that
we
call
today
out
of
devops,
will
just
flag
it
right
if
it
contains
something
in
that
line.
K
So
answering
lori,
I'm
not
sure
I
think
it's
multiple
personas,
but
I
think
that
we
can
approach
the
different
personas
with
a
similar
approach,
meaning
if
I
don't
know
what
I'm
doing
and
I'm
a
beginner
give
me
auto.
Devops
give
me
whatever
I
can
without
you
know,
knowing
too
much
and
maybe
I'll
figure
it
out
later
and
hack
it.
But
if
I
do,
then
I
want
to
have
full
flexibility
and
the
way
that
we
were
doing
that
was.
K
So
you
have
a
specific
docker
image
that
does
one
thing
like
connect
to
aws
cli
or
push
to
s3,
or
it
just
does
one
thing,
and
I
can
select
just
choose
that
in
order
to
put
into
my
gitlab
ciaml
file
or
if
I
don't
know
what
I'm
doing
I'll
just
take
the
full
yaml
and
then
the
beauty
of
autodevops
is
that
you
have
a
bunch
of
includes
that
you
can
include
desk,
you
can
include
auto
build.
You
can
include
whatever
stages
you
want,
and
that
gives
you
tons
of
flexibility.
K
F
I
think
two
key
things
that
people
have
been
calling
out
and
I
just
want
to
like
make
a
specific
point
of-
is
letting
people
choose
and
recommending
in
small
batches.
So
what
I
mean
by
letting
people
choose
is
we
all
know
when
you
go
to
install
software
there's
those
of
us
who
are
picking
the
wizard
and
like
ask
me
as
few
questions
as
possible
and
then
there's
those
of
us
who
are
like
no,
I
want
to
check
every
box
and
see
what
you're
doing
so.
F
C
In
pipeline
authoring
we're
starting
to
look
into
the
idea
of
offering
job
templates-
and
this
is
something
that
we're
thinking
about
in
the
near
term,
because
we
realized
that
big
pipeline
templates.
They
are
they're
overwhelming
to
beginner
users
who
are
not
familiar
with
ci
cd,
and
then
they
get
this
whole
pipeline.
They
don't
know
how
to
take
it
apart
and
how
to
make
it
useful
for
them.
So
we
kind
of
someone
mentioned
github
actions,
so
we're
kind
of
thinking
along
the
same
lines,
making
those
job
templates.
C
These
more
granular
building
blocks
available
within
the
pipeline
editor,
so
one
would
be
able
to
pick
and
choose
and
then
the
next
step
would
be
to
make
that
process
as
automated
as
possible.
So
we
haven't
done
a
lot
of
discovery,
work
around
done
boarding
itself.
I
think
it's
very
important
that
we
take
it.
You
know
we
take
it
a
step
further
and
look
at
this
more
high-level
vision
for
a
new
gitlab
user
onboarding
as
a
whole
like
or
you're
creating
a
new
project.
And
then
we
ask
you
questions.
C
What
do
you
need
and
then,
depending
on
what
you
need,
we
give
you?
Okay,
we
have
this
automated
automatic
magic.
If
you
want,
if
you
want
some
more
control,
we
also
have
this
and
that
these
templates
and
they're
very
easy
to
manipulate
and
adjust
using
these
build
building
blocks
and
then
yeah.
So
we
need
to
provide
options
to
our
users
when
they
they're
ready
to
answer
that
question.
So
again,
it
kind
of
ties
ties
it
back
to
the
onboarding
experience
and
like
going
past
the
the
actual,
auto
devops
feature.
C
I
feel
like
one
of
the
problems
with
approaching
this
problem
is
that
it's
kind
of
owned
by
multiple
different
teams,
and
I
would
like
to
hear
some
ideas
I
think
I
know
product
has
been
discussing
this
like.
How
can
we
approach
this
because
the
growth
team
right
now
is
working
on
continuous
onboarding
for
new
github
users,
where
they
are
kind
of
thinking
about
a
similar
approach
where
they
guide
a
new
github
user
through
a
series
of
tasks
like
create
your
repository
set
up,
ci,
cd
and
so
on
and
so
forth?
C
F
F
Sam
white
is
designing
a
policy
builder
for
all
of
secure
and
he's
ideally
going
to
build
a
generic
engine
for
lack
of
a
better
word,
and
then
we
each
will
be
able
to
plug
in
our
pieces
to
it
to
make
it
work
for
us,
and
so
I
think,
having
some
kind
of
generic
question
engine
journey
engine
and
recommendation
widgets
that
are
universal,
for
you
know,
usability
consistency,
customer
expectation
setting
but
then
allow
every
group
to
plug
in
their
categories
and
features
with
certain
like.
If
this
than
that,
you
know
type
items.
D
One
more
more
thing
here
totally
agree
with
all
of
this.
That
is,
that
what
both
of
you
mentioned
with
the
lego,
building
blocks
and
orange
with
the
atomic
docker
images-
I
would
say
this
part-
should
be
extendable
by
our
users,
because
there,
if
you
have
a
platform
engineer
who
want
to
provide
their
own,
include
template,
it
should
be.
It
should
fit
really,
naturally,
into
this
whole
experience
and
the
pipeline
is,
however,.
A
I
know
we're
we're
thinking,
big
and
that's
kind
of
a
tactical
question
of
like
how
would
we
enable
others
to
contribute
to
it?
I
do
think
one
of
the
things
that
has
inhibited
us
from
building
that
kind
of
framework
and
investing
in
it
is
that
we
are
in
a
little
bit
of
a
self-fulfilling
prophecy
where
we
say
well,
autodevops
isn't
used
that
much,
and
so
people
just
include
the
templates.
So
I
don't
really
need
to
include
what
I'm
building
into
the
logic
of
autodevops.
A
I
just
need
to
publish
a
template,
which
is
very
sound
if
you
look
at
the
actual
usage
numbers
of
autodevops,
so
the
points
that
I
think
nadia
started
with
of
and
maria.
Actually,
I
think
you
were
pointing
them.
The
discoverability
of
autodevops
is
probably
the
first
place
you
want
to
start,
then
you
can
build
a
framework
that
says
hey.
This
thing
is
working,
people
are
using
it.
A
Wouldn't
you
love
your
features,
xyz
group,
to
be
recommended
in
this
process,
because
there's
like
what
I
what
I
have
said
is
I
wouldn't
blame
any
product
manager
from
saying
hey.
Why
do
I
need
to
integrate
with
other
devops?
That's
not
going
to
be
the
most
important
thing
for
driving
my
gmail,
which
is
the
metric
that
I
want
to
drive,
but
if
autodelos
was
heavily
used
and
it
was
like
hey,
it's
just
a
little
bit
of
effort
to
add
it's
to
this
framework
that
they
built,
you
would
do
it
in
a
heartbeat.
A
E
Yeah
and
I
think
whatever
solution
we
come
up
with,
we
need
to
come
up
with
the
user
experience
vision,
so
the
technical
implementation
is
a
different
thing,
but
in
order
to
know
where
we're
going
with
the
solution,
we
need
the
ux
vision
and
the
only
way
I
can
see
is
doing
that
is
multiple
product
designers
working
together.
So
we
could
start
with
mapping
the
existing
journeys.
Well,
basically,
we
have
the
vision
conversation,
but
then
we
have
the
compensation
of
the
immediate
needs,
because
we
have
a
couple
of
bugs
for
devops.
E
Auto
devops,
like
the
security
features,
currently
depend
on
other
devops.
We
need
to
turn
them
on
for
new
projects
and
just
left
a
point
like
which
team
has
the
capacity
to
work
on
other
devops.
So
as
designers
we
could
start
working
on
a
like
visionary
piece,
25
of
our
time,
or
I
don't
know
what
but
then
there's
a
question.
I
wanted
to
bring
up
for
the
immediate
actions
that
we
need
to
take.
B
I
do
want
to
call
out-
and
I
think
maria
touched
on
this
point-
that
I
think
we
should
start
with
designers
coming
together
to
figure
out
how
we
want
all
these
pieces
to
play
together,
because
then
we'll
all
have
a
uniform
product
vision
and
technical
roadmap
of
what
we
want
to
make
it
happen
and
make
sure
that
we
avoid
pitfalls.
Like
nicole
had
mentioned,
where
there's
question
overload
or
the
discoverability
issue
never
gets
resolved,
and
so
we
put
in
this
effort
and
it
doesn't
go
anywhere
so
that
may
be
the
place.
We
want
to
start.
J
J
I
know
that
in
like
the
secure
channel
and
slack
there's
a
lot
of
account
managers
or
product
managers,
etc
that
go
in
there
and
say:
hey
I'm
having
a
customer
that
has
an
issue
with
this
thing,
so
it
seems
like
there's
a
lot
of
really
great
feedback
out
there.
I
wonder
if
it's
worth
compiling
in
one
place.
H
C
Great
we're
almost
at
time
here
we
have
five
more
minutes.
So
I
really
like
that.
We
started
talking
about
the
next
steps,
so
it
seems
like
I
agree.
I
think
ux
can
really
help
drive
the
first
steps.
We
need
to
gather
all
of
the
insights
that
we
have
so
perhaps
we
could
start
with
that
and
there
was
an
idea
in
one
of
the
issues.
C
So
if
we
think
about
it
as
a
tool
that
somehow
fits
into
the
onboarding
experience
when
you're
creating
a
new
project,
how
do
we
automatically
provide
you
with
all
of
the
solutions
that
you
need,
so
we
can
explore
what
it
might
look
like
and
then,
based
on
that,
we
can
see
how
autodevops
can
help
with
creating
this
or
implementing
this
vision.
And
what
are
the
next
steps
we
have
to
take
from
there.
A
I
love
it
and
I
will
would
also
propose
maybe
a
second
track
that
is
more
for
the
product
management
group
and
victor.
I
know
you
wouldn't
take
offense
to
this,
but
our
present
vision
for
auto
devops
is
very
limiting.
We
all
talked
about
at
the
start.
Hey
we
have
this
big
vision
for
what
it
could
accomplish
and
the
business
goals
it
could
allow
our
customers
and
ourselves
to
achieve.
But
if
you
read
our
auto
devops
direction,
page
it's
fairly
limiting
to
kind
of
what
it
does
today.
A
B
A
E
E
Shall
I
go
back
to
my
question
for
the
immediate
action
for
solving
the
problems,
the
immediate
problems
we
have
so
the
secure
features
don't
work
without
other
devops
turned
on
autodevops
is
turned
on
on
instances
like
local
instances,
but
not
on
github.com.
We
are
planning
to
turn
on
other
devops
for
new
projects.
A
A
We
like
the
the
branding
term
for
autodevops.
We
would
like
to
have
a
new
experience.
Maybe
we
should
wait
to
turn
it
on
for
everyone
until
we
get
that
new
experience,
I
think
that
I
don't
know
who
the
driver
I've
turned
on
for
everyone.
If
that
was
a
secure
group's
question,
so
I
don't
want
to
like
suggest.
F
Yeah
right
now,
because
we're
at
various
points
we're,
depending
on
certain
things
like
having
review,
apps
and
other
things,
and
I
yeah.
I
don't
think
it
would
be
pretty
from
a
secure
perspective
and
we're
actually
going
a
different
route
to
make
it
much
easier
to
turn
on
by
default
and
make
it
discoverable.
F
E
C
Thanks
sam
yeah,
I
think
we're
time.
Thank
you
so
much
erin
for
participating.
I
feel
like
it
was
an
extremely
productive
discussion.
It
was
great
to
see
everyone
represented
product,
ux
engineering,
so
thanks
so
much
for
contributing.
I'm
gonna
summarize
the
outcomes
of
this
discussion
and
the
next
steps
in
the
think
big
issue,
and
I
will
take
you
all
and
yeah,
so
the
product
will
come
forward
with
the
vision
and
the
ux
research
in
ux
will
take
it
from
there
and
collaborate
on
gathering
insights.