►
From YouTube: Ops Cross-Stage Think Big - 2021-04-15
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
This
is
the
app
section
cross
stage,
think
big
for
april
15
2021..
Our
topic
today
is
one
that
I
added
to
the
agenda
so
I'll
be
moderating
today.
I
don't
have
a
mural
board
for
us,
so
we'll
just
be
doing
this
discussion
style
through
the
doc
and
verbally.
I
do
have
all
of
the
prompt
questions
in
the
agenda
if
you
want
to
click
into
that.
A
So
that's
our
topic
and
I've
started
with
a
problem
description
in
kind
of
our
jobs
to
be
done
style
around
as
a
developer
or
a
devops
engineer
who's
setting
up
gitlab.
For
my
group,
I
want
to
know
if
there
are
conflicts
between
the
gitlab,
ci,
yamo
and
settings,
so
I
can
avoid
hunting
down
questions
from
developers
who
have
a
bad
experience.
Slash,
I
know,
or
I
look
like
I
know
what
I'm
doing
when
it
comes
to
gitlab.
A
So
that's
what
they're
trying
to
accomplish
in
this
specifically
the
one
that
comes
up
for
us,
is
around
test
coverage.
You
can
set
up
your
coverage,
badges.
You
can
set
up
parsing
for
coverage
in
your
settings
in
ci
cd.
You
can
also
do
that
at
the
job
level,
in
your
gitlab
ci
yaml,
those
two
things
could
potentially
be
in
conflict,
and
when
that
happens,
it's
not
a
great
experience
for
a
user.
A
B
A
I
I
think
it
could
be
either
the
persona
being
that
devops
engineer
or
like
ci
cd
engineer.
Let
me.
B
B
B
I
never
run
into
such
a
problem.
I
haven't
seen
any
issues
in
this
topic
and
I'm
trying
to
understand.
C
C
Maybe
let
me
give
an
example,
and
then
james
you
can
tell
me
if
this
is
what
the
intent
is
and
then
victor
you
can
tell
me
if
this
helps
so,
let's
say
one
of
the
settings
project
settings
could
be
pipeline
must
succeed.
C
You
know
in
order
to
merge
under
the
merge
requests
section
of
project
settings
you
can
set
that
that
feature
pipeline
must
succeed
in
order
to
merge,
but
this
conflicts
with
a
yaml
file
that
maybe
already
just
get
created
for
the
same
group
or
a
project
that
doesn't
even
have
keywords
in
it.
That
would
run
a
pipeline.
So
is
that
an
example
of
there
is
a
conflict
between
a
setting
you're
about
to
select.
But
it's
not
something
that's
supported.
C
C
I
think,
in
those
cases
in
the
past,
we
have
tried
to
help
alleviate
that
with
some
tool
tips
for
each
of
those
settings
like
hey
when
you
select
this
just
be
aware
you
have
to,
but
but
that's
almost
too
passive,
to
help
prevent
these
scenarios,
and
so
I
totally
see
what
you're
presenting
here
james
is
something
that
we
want
to
solve
for
it
would,
it
would
make
our
product
actually
run
more
smoothly
for
for
new
users
and
even
even
experienced
users.
That's
new
to
that's
using
a
feature
for
the
first
time.
C
You
know
it
would
help
them
not
break
their
their
ins,
their
pipeline
for
their
their
project.
D
Yeah-
and
I
think
this
also
relates
a
little
bit
with
what
the
dove
is
not
here
right
today.
No,
but
I
know
that
pipeline
authoring,
they
are
working
on
a
sort
of
drawer
or
a
ui
or
creating
pipelines
in
a
much
more
smooth
way.
So
a
pipeline
builder,
where
you
have
the
ci
file,
but
you
also
have
some
sort
of
templates
that
you
can
quickly
apply
to
the
code
that
you're
writing
and
this
your
team.
I
think
they
they
showcase
this
week.
D
A
solution,
I
think,
was
a
lot
of
buzz
testing
or
football,
something
I
apologize
for
not
knowing
exactly
what
I'm
talking
about,
but
I'm
not
just
linked
here,
because
I
think
it's
that
if
I,
if
I
show
you
on
how
they're
trying
to
solve
the
linking
with
advanced
settings
and
configuration
ci
file
in
the
ui,
so
just
throw
you
some
related
vita
topics
from
other
stage
groups.
A
D
Let
me
see
what
they
think
the
description
you
can
easily
create
a
yaml
file
and
add
the
imo
file
in
the
ripple
by
an
api.
A
A
But
back
to
victor's
question
I
want
to
dig
in
does
do
those
extra
examples
help
clarify
a
little
bit
and
maybe
the
my
initial
problem,
description
of
setting
up
wasn't
a
good
one.
This
isn't
necessarily
a
new
group,
but
this
is
someone
who's.
Maintaining
a
pipeline
might
be
a
better
example
here.
B
Yeah,
I'm
still
thinking
a
lot
about
about
really
how
this
might
work
out
in
in
in
everyday
work
situations.
I
I
this
is
I
I
I
start
to
understand.
Subtitles
example
hub.
I
don't
have
any
examples
on
my
own,
so
that's
the
problem.
That's
why
it's
hard
for
me
to
get
much
involved
and
as
it
was
specifically
said
that
there's
only
a
reason
to
have
this
discussion.
If
there's
configure
somebody
from
the
configure
team
as
well-
and
I
think
that
what
what
I
don't
see
here
that
I
should
so.
A
Are
there
examples,
I'm
just
not
as
familiar
with
like
the
the
iec
bit
of
the
product,
but
are
there
examples
where
you
can
do
things
and
get
labcia
yaml
that
you
also
have
settings
for
potentially
like
around
terraform
or
any
of
those
kinds
of
things?
I
could
see
that
there
would
be
big
could
be
big
conflicts
there.
B
Actually,
the
other
way
around,
so
basically,
there
are
many
many
users
who
use
star
form
to
set
up
groups
and
create
projects,
and
everything
like
that
because
to
give
you
a
very
realistic
example
here,
whenever
you
have
a
new
project,
you
want
to
set
up
datadog
integration.
You
want
to
set
up
all
kinds
of
integration
sensor,
integration.
B
Whatever
and
simply
creating
a
new
gitlab
project
is
10
of
the
work
or
even
less.
As
a
result,
you
set
up
the
gitlab
project
with
your
custom.
Tooling,
that
actually
runs
star
form
and
terraform
creates
the
project.
It
could
just
do
it
from
a
template
or
in
any
way,
but
terraform
creates
you
the
project.
B
It
injects
the
environment
where
I
was
received
from
all
these
services
that
were
reached
at
the
project
creation
as
well,
and
then
your
project
is
set
up
as
you
want
it
to
be,
and
I
can
imagine
that
there
are
situations
when,
when
the
the
thing
that,
for
example,
tao
described,
can
can
came
up
sim
easily
if
you
manage,
for
example,
even
in
your
group,
video
form
and
you
change
something
in
terraform,
even
a
ui
based
notification
will
never
be
surfaced
to
you
actually
and
we
can't
surface
notifications
to
telephone.
So
it's.
B
D
Yeah,
I
can
think
of
a
lot
of
scenarios
for
cd
release
management,
so
they
release
team
also
for
verify.
We
do
have
a
lot
configuration,
for
example,
the
deploy
freezes,
automatic
rollbacks
variables,
so
many
things
that
we
set
up
in
the
both
in
the
ci
file
and
the
settings.
So,
for
example,
the
fly
phrases
you
must.
You
have
to
update
the
jobs
in
the
ci
file
and
then
go
to
the
settings
and
say
this
is
the
specific
period
of
time
or
the
dates
whatever.
Where
I
don't
want
my
deployments
to
run.
D
I
think,
like
that,
and
one
of
the
challenges,
many
challenges
actually
that
we
found
from
the
customer
interviews.
The
user
interviews
was
that
similar
to
merge
strings
people
just
didn't
know
why
their
application
was
not
working.
So
my
I'm
telling
the
starter,
because
my
question
is
james.
D
This
job
to
be
done
is
about
informing
users
that
configuration
needs
to
be
done
in
a
separate
part
of
the
project
or
it's
facilitating
that
that
setup,
so
that
they
can
that
we
can
yeah
just
connect
those
workflows,
because
I
understand
that
we
are
talking
about
the
super
technical
personas,
but
also
maybe
some
engineers
that
just
go
in
the
settings
page
and
click
a
button,
but
don't
necessarily
write
the
yml
file.
A
B
Yeah,
it's
something
that
that,
as
I
sat
on
to
say
it's
more
like
it's
something
like
a
compatibility
matrix
that
with
these
kinds
of
settings,
these
gitlab
keyboards
should
be
used
or
should
not
be
used,
and
something
like
this
that
that's
what
we
are
speaking
about-
and
this
is
today
might
exist.
I
don't
know
I
I've
never
seen
that.
A
B
Actually,
I
would
I've
read
the
third
option
as
well,
because
my
answer
to
your
question
would
be
someone
who's,
making
the
change
and
have
a
constant
banner
at
the
top
of
the
page
that
there
are
conflicting
settings
in
your
in
your
project
fix
it
here,
so
you
don't
have
to
experience
it.
You
don't
have
to
say
that
you
just
open
the
page.
You
see
that
there
is
something
weird.
B
A
Okay,
I
like
it
so
in
that
case
I
think
we
have
two
different
personas.
Then
we
have
that
devops
engineer
who's
potentially
doing
the
change
as
well
as
the
developer,
because
everyone
can
can
get
in
there
and
change
things
and
then
probably
it's
a
developer,
or
maybe
it's
a
release,
train
engineer
for
some
of
hayana's
examples
of
I
see
that
there
is
an
issue
somewhere
in
our
setup.
E
Sounds
reasonable,
I
I
guess
for
me
I'm
just
kind
of
listening
and
soaking
it
all
in
james
if
you're
wondering
why
I'm
being
so
quiet,
because
I
really
haven't
experienced
this
particular
use
case,
I'm
trying
to
understand
kind
of
like
where
the
where
the
the
problem
happens.
But
I
highly
that
sounds
reasonable.
Don't
mean
to
go
all
the
way
back
to
file,
but
I
was
just
wondering
how,
if,
by
chance
you
you
can
you
have
a?
C
Let
me
go
get
an
example
in
in
your
case,
by
the
way
darren,
it
might
be
something
that
they
didn't
configure.
They
didn't
configure
their
runners,
for
example,
in
their
settings,
and
so
they're
wondering
why
the
pipeline
is
not
running.
That
would
be
an
example
of
a
conflict
potentially
between
settings,
and
so
let
me
go
find
it
open
the
project.
D
D
Okay,
so,
for
example,
deploy
what
I
was
talking
about,
deploy
freezes,
so
the
user
needs
to
say
that,
okay,
what
what
jobs
or
what
the
what
configuration
needs
to
happen
in
the
ci.
As
I
was
saying,
and
then
here
in
this
view
in
the
settings,
they
need
to
say
when
the
free
starts,
when
should
I
not
be
deploying
to
production
and
at
what
specific
time
zone
so,
for
example,.
D
Set
this
up
and
if
I
say
let
me
get
an
example
here
from
prom,
if
I
just
say,
start
freeze
and
then
freeze
here
on
whatever
time
zone.
That
means
nothing
to
the
application,
because
the
ci
file
is
not
configured
and
this
doesn't
take
the
user
to
any
other
step.
Of
course
you
can
here
you
you,
you
first
off,
you
have
to
discover
this
in
the
settings
page.
That's
issue
number
one,
a
lot
of
options.
D
D
D
Example,
yeah,
you
need
to
say.
D
B
D
B
D
We
also
had
where's
the
merge
train
settings.
I
don't
even
know
where
it
is,
but
we
had
the
same
remember
when
we
first
released
motor
strains
and
then
we
had
to
disable
it.
C
C
C
C
Yeah
so
go
to
expand
your
in
general,
expand,
merge,
request
and
scroll
down
to
it's
under
merch
options.
C
To
general
and
expand
scroll,
so
you
can
expand,
merge,
requests
yeah,
but
by
the
way,
this
is
interesting
that
it's,
it
wasn't
obvious
to
us,
and
I
think
you
scrolled
right
past
it,
but
under
merch
options
here
you
have
to
enable
that,
in
order
to
enable
yeah
much
streams
the
moment
you
click
on
that
enable
merge
results,
then
it
it
makes
it
possible
yet
to
select
your
stream.
D
C
And
so,
while
you
have
your
screen,
go
to
ci
cd
and
I'll,
give
the
example
that
I
was
thinking
of
yeah
and
if
you
go
to
general
pipeline,
so
where
is
it
actually?
Maybe
I'm
thinking?
Maybe
it's
not
maybe
it's
under
the
general
as
well.
D
C
Yeah
so
sorry
it
it
go
back
to
where
you
were
under
settings
general
and
then
expand
merge
request-
and
this
is
all
about.
A
lot
of
settings-
are
here
about
ability
to
merge
and
there's
a
lot
of
potential
for
conflict
of
what's
in
the
yaml
file,
but
under
merge
checks
which
is
below
merge
options.
Yeah
keep
going
there,
it
is
merge
checks.
So
there's
a
couple
settings
there
about
pipeline
must
succeed
that
I
mentioned
in
my
example.
C
But
there's
another
setting
that
says
skipped
pipelines
are
considered
successful
and
if
you
don't
have
that
enabled,
but
you
put
in
your
commit
the
keywords:
ci
skip
it
and
you
haven't
enabled
this
checkbox
for
skip
pipeline
is
considered
successful.
Then
your
pipeline
will
get
stuck
as
well.
If
you
have
pipeline
must
succeed,
enabled,
but
it's
not
obvious
here
right,
it
doesn't
even
have
a
tooltip.
I
just
realized
so.
A
So
it
seems
we
have
a
number
of
places
where
it's
really
hard
to
figure
out
what
all
you
need
to
configure
to
actually
enable
a
feature.
Yes
and
there's
conflicts
between,
if
you
don't
do
them,
both
right
you're,
just
it's
not
going
to
work.
That
sounds
actually
like
the
same
thing.
So
it's
less
conflicting,
it's
more
multiple
steps
to
get
something.
C
Fully
set
up
and
and
we're
assuming
the
same
user
is
doing
this
and
it's
it's
not.
I
think
the
the
problem
arises
when
the
product
owner
is
selecting
these
settings,
but
it's
someone
completely
different.
That's
authoring
the
configurations
in
the
yaml
file
right
and
they're,
not
aware
that
these
settings
have
an
impact
on
what
they're,
what
they're
writing
in
the
ci
configs
yeah.
C
A
It's
yeah,
so
if
we
were
to
focus
in
like,
let's
think
small
for
just
a
minute
of
those
two
personas,
because
you
have
someone
who's
managing
the
instance
into
setting
these
things
up
there
and
someone
who's
managing
an
individual
project
and
like
in
victor's
example,
running
terraform,
to
build
the
project
and
maybe
setting
some
of
these
settings
up
at
the
time
which
of
those
two
personas
should
be
focused
on
for
our
purposes.
Today.
D
I
would
say
the
the
technical
persona,
I'm
not
sure
how
exactly
we
are
showing
in
the
in
the
job
logs
or
the
errors
that
things
are,
that
things
need
to
be
set
up
in
the
in
the
settings,
for
example,
what
type
of
error
messages,
but
from
my
learnings,
with
release
with
release
right
with
cd.
We
are
focusing
mostly
on
the
developer
persona,
because
they
are
the
ones
that
spend
the
most
time
working
on
the
application
in
the
sense
of
with
its
workflows.
E
So,
basically,
hyanna
if
to
reflect
back
you're,
basically
saying
the
person,
that's
kind
of
waiting
for
the
pipeline
to
actually
execute
gotcha.
C
I
I
I
would
if
we
assume
that
this
problem
is
out
there,
I
would
want
to
also
focus
on
the
persona.
C
That's
feeling
the
pain
because
of
this
mismatch,
because
changing
the
settings
may
not
happen
as
often
as
seeing
the
impact
of
improperly
configured
files
or
can
or
improperly
selected
settings
so
and
then
once
we
solve
for
that,
I
would
and
that's
very
it's
addressing
helping
with
addressing
the
pain
point
is
very
reactive,
but
after
that
I
would
like
to
do
the
proactive
thing
which
is
preventing
it
from
happening
by
having
more
intuitive
or
some
kind
of
guidance
when
settings
are
selected
or
when
authoring
is
done
on
a
yaml
file
like,
for
example,
we
talk
about
the
settings
having
an
impact,
but
on
the
other
hand,
if
you're
putting
some
kind
of
configuration,
the
yaml
file
be
nice.
C
A
C
B
So,
okay,
I
just
said
nothing
because
I
don't
have
a.
I
don't
have
an
opinion.
Actually,
the
thing
is,
I
don't
have
an
opinion
on
it,
because
sometimes
it
seems
to
me
that
it
does.
It
depends
on
the
settings
whether
it's
driven
from
the
ci
or
whether
it's
driven
from
the
setting
and
yeah,
and
so
things
might
be
better
because
the
developer
might
not
have
rights
to
to
change
their
action.
D
I
think
a
couple
of
things
I
I've
thought
in
the
past
related
to
the
release
management
functionalities
was
that
one
improve
how
we
are
helping
users
in
the
ui,
for
example,
like
really
state
that
you
know,
every
configuration
that
you
select
here
needs
an
update
in
dcui
in
the
ci
file,
like
that's
a
low
hanging
fruit
and
maybe
even
add,
like
some
sort
of
feedback
to
the
ui.
D
Once
the
user
clicks
that
checkbox
say,
hey
reminder:
hey
now
go
configure
your
ci
file
so
that
this,
whatever
the
deploy
phrases
it's
working
for
your
project.
So
those
were
the
low-hanging
fruits
that
we
thought
back
in
the
day
when
the
release
management
team
view
existed
and
or
the
things
in
the
apis
right.
So
in
the
ci
file
we
could
only
rely
at
that
point
on
the
job
failing
and
then
telling
people
why
it
failed
and
where
to
go,
configure
things.
D
So
that's
why,
when
I
talked
about
the
pipeline,
altering
proposals
for
the
visual
builder
for
the
ci
file
is
that
they
want
to
have
this.
This
connection
bridge
this
gap,
so
that,
while
you're
writing
your
ci
file,
you
see
all
these
templates
all
these
snippets
and
you
either
drag
and
drop
or
configure
things
there.
But
this
is
not
going
to
happen
anytime
soon,
so
this
is
really
like
the
long
term
vision
for
or
writing
the
ti
file.
A
B
We
can
just
open
those
things
up.
One
thing
that
how
I
would
imagine
the
ideal
outcome
is
that
I
change
the
setting
and
the
merge
request
is
opened
with
the
ci
more
changes,
and
I
just
have
to
accept
that
and
I'm
and
there's
a
notification
as
well
that
please
review
these
changes
in
the
merge
requests
that
go
together
with
this
setting
change.
B
C
Oh,
that's
a
so
I'm
glad
you
started
off
with
that
victor
because
you
said
from
the
yaml,
you
don't
know
what
could
happen.
It
could
create
a
to-do
to
go
to
change
the
project.
Setting
the
to-do
could
be
the
project
owner
and
the
person
who
is
the
author,
making
the
change
of
the
yaml
right,
yeah
yeah.
C
And
so
so
yeah,
so
that
would
be
a
very
think,
big
outcome,
both
of
these,
which
is
an
action
that
requires
some
other
thing,
for
that
action
to
be
effective,
triggers
some
kind
of
whether
it's
an
mr
or
to
do
to
marry
up.
You
know
the
two
requirements
to
make
that
thing:
work.
A
A
C
D
Generates
it
to
do
yeah
and
in
terms
of
discoverability,
the
the
create
team
they're
actually
working
on
a
cleanup
of
the
settings
page
and
the
ux
department
will
have
okr
now
in
q2
focus
on.
You
know
a
huge
facelift
on
the
settings
copy
and
the
structure
of
those
pages.
So
if
we
are
able
to
also
clearly
tell
users
where
to
find
things,
while
we
create
those
to-do's
and
a
link
to
where
they
should
set
things
up,
that
would
be
awesome.
D
D
There's
something
about
setting
here,
review
and
refactory
white
text
on
project
and
group
settings.
It's
all
the
way
on
the
bottom.
Let
me
face
here,
but
the
idea
is
that.
D
Just
the
idea,
but
the
the
ux
department
has
been
working
on
putting
together
those
patterns
and
reviewing
settings
across
admin
group
and
project
views
and
defining
those
senders.
So
what's
going
to
happen,
is
that
at
some
point
we're
going
to
have
a
bunch
of
tasks
for
the
product
teams
for
the
teams
to
implement
those
improvements
based
on
which
features
we
own
so
they're
going.
C
A
So
we've
done
a
great
job
of
think
big.
We
have
about
12
minutes
10
to
12
minutes
left
for
the
think
small
part,
but
I
think
that
we
are
ready
to
move
on
to
that
and
I
rearranged
the
order
of
the
questions
here
instead
of
thinking
about.
What's
the
next
thing
we
could
do,
I
want
to
talk
through
just
generally,
as
this
applies
to
a
bunch
of
different
areas
and
settings.
What
are
the
hardest
parts
or
the
single
hardest
part
of
this
to
solve.
B
B
A
D
A
B
B
B
E
Yeah,
I
agree
with
victor
and
I
just
had
a
thought,
I'm
not
quite
sure
james,
which
bucket
this
thought
goes
into
so
be
on
with
me.
So
I
was
kind
of
thinking
about
kind
of
reflecting
back
on
the
the
initial
problem
statement.
Very
you
know
very
early
on
the
agenda
right
where
the
devops
engineer
says
hey.
I
want
to
know
if
there's
a
conflict
between
the
ammo
and
the
settings
so
that
they
can
avoid
hunting
down
questions
from
developers
right
who
have
had
a
bad
experience.
E
So
I
was
thinking
so
far.
Our
discussion
has
been
trying
to
mitigate
the
risk
of
that.
I
think
by
letting
that
devops
person
know
hey
you're
about
to
make
a
change
in
a
setting
and
oh
by
the
way
you
need
to
go.
Do
this
other
action
to
make
sure
you
don't
create
the
incompatibility,
but
I
was
wondering
like
without
having
all
the
data
like
say:
james.
You
are
my
devops
engineer
and
you're
the
maintainer
for
my
project
right
and
then
I'm
just
a
production
developer.
Maybe
I
have
a.
E
I
have
my
feature
brand
and
maybe
hyanna
has
their
own
feature
branch
or
what
have
you?
I
create
some
change
in
my
feature:
branch
get
that
yaml
file
and
then
my
pipeline
doesn't
work
because
I'm
unaware
of
that
setting
change
that
we
still
have
that
risk
and
we
still
like
that.
You
know
I
need
to
call
james
like
hey
james,
the
five
times
broken
he's
like
oh
darren.
Did
you
not
see
my
ping
on
needing
to
change
to
whatever
for
the
deploy
freezes.
A
E
I
need
to
go
change
the
ammo,
that's
cool,
if
you're
all
working
off
of
maine,
but
let's
assume
we're
all
not
working
off
of
maine,
which
I'm
just
kind
of
into
without
us
having
data
at
our
fingertips,
like
maybe
that's
one
of
the
the
use
case
branches
here
right,
that's
causing
the
initial
experience
like
I
now
need
to
call
up
james
to
have
him
help
me
debug
when
I
find
this
broken,
and
then
james
has
to
like
oh
yo.
Yamaha
is
missing
the
regenexx
for
the
the
fly
freezes.
C
C
Branch
in
that
case,
that's
how
we
would
solve
for
it.
It
probably
I
mean
we
hadn't
thought
about
this,
but
maybe
changes
in
the
project
setting
should
result
in
some
more
tests
added
in
the
jobs
that
run
for
a
pipeline
that
you
know
for
merging
purposes,
and
so
the
the
the
job
error
can
be
very
specific.
This
failed
because
of
this
project
setting
or
this
existing
project
setting
required
this
in
the
yaml
file.
C
A
A
A
That's
the
yeah,
that's
the
example
that
comes
to
mind
because
yeah,
like
victor
your
example,
ford
deploys
like
I
don't
really
care
about
deploys
when
it
comes
to
a
feature
branch,
I'm
not
going
to
deploy
this
on
my
own.
I
trust
that
that
when
I,
when
I
merge
like
the
gitlab
ci
yaml,
that's
associated
with
the
branch
that
will
actually
deploy
will
match
up
with
settings
like
for
me.
That's
not
a
use
case.
I
care
about
as
a
developer,
but
a
merge
request.
Approval
rule
is
something
that
could
impact
my
workflow
today.
A
If
I
don't
have
a
job
or
I
do
have
a
job
that
is
now
no
longer
required
for
merge,
request
approval
that
there's,
I
think,
there's
some
sort
of
conflict
that
lies
in
there.
I
don't
know
exactly
enough
about
how
the
secure
jobs
work
to
know
that
for
a
fact,
but
I
would
take
as
a
next
step
for
us
maybe
talking
to
this
talking
to
the
secure
team
and
seeing
how
they've
thought
about
that.
B
I
don't
know
if
it's
a
problem
or
not.
I
don't
have
any
data,
but
from
from
what
you
see
here,
there
are
clearly
situations
when
that
you
don't
want
to
face
and
and
it's
hard
to
avoid,
so
the
question
is
how
often
these
change.
So
that's
that's.
I
think
the
question
because
it
might
be
super
annoying
in
every
project
once
in
a
lifetime.
A
Yep
yep
and
I,
when
we've
done
these,
think
bigs
within
testing,
sometimes
our
our
what's.
Our
next
thing
to
change
is
just
documentation,
and
maybe
that's
the
last
thing.
We
change
that
solves
our
problem
enough
today,
for
the
users
that
have
it
and
the
next
iteration
of
the
feature
might
make
the
overall
experience
better,
and
I
think
that
would
be.
I
think,
okay,
one.
B
Thing
we
could
do
is
the
growth
they
might
be
able
to
help
with
that
to
to
get
data
around
around
two
things
that
come
to
my
mind,
totally
independently
from
each
other.
One
is:
is
there
a
significant
change
in
churn
between
users,
whose
first
pipeline
run
was
successful
versus
users
whose
first
pipeline
was
not
successful?
Something
when
these
license
and
if
it
could
be
that
the
unsuccessful
pipeline
run
is
the
result
of
the
settings
yeah
more
income
incompatibility?
B
The
other
interesting
thing
would
be
to
check
the
data
on
gitlab.com
for
one
or
two
of
these
settings
like
how
often
do
they
happen,
that
they
are
that,
for
example,
the
the
deployed
freezes
are
not
properly
set
up
in
the
in
the
ammo
file
and
they
are
enabled
or
or
anything
gas
along
these
lines,
because
this
can
give
us
an
idea.
How
often
this.
B
C
While
james
is
writing
that
I
added
my
note
under
documentation
as
far
as
what
we
can
do,
next
is
all
the
things
that
we
want
the
logic
to
do
automatically.
We
should
start
with
defining
those
in
the
troubleshooting
guide
of
the
manual
step.
A
user
would
have
to
do,
and
once
we
clearly
know
if
this,
then
that
has
to
happen,
then
that
would
be
the
basis
of
what
we
would
automate,
but
at
least
give
them
the
guidance
of
what
they
have
to
manually
do
first
to
resolve
their
whatever
is
broken.
A
C
A
A
So
we
have
a
couple
of
next
steps
here
or
potential
next
steps,
things
that
we
could
do
what
are
actual
next
steps
as
we
wrap
up
in
the
next
minute
or
so
because
we're
getting
close
to
time
actually
over
time.
For
our
allotted
time.
C
For
for
me,
I
would
I
would
create.
I
would
look
at
the
settings
that
my
team
owns
that
require
certain
parameters
in
the
yaml
file
and
open
issues
for
our
tech
writer.
To
add
that
to
our
the
troubleshooting
guides
that
exist,
I
think
there's
one
for
you
know
troubleshooting
why
your
pipeline
is
broken
or
something
like
that.
C
So
that's
a
a
step
that
I
can
think.
A
Of
awesome,
I'll
share
this
with
or
reet
as
well,
not
to
put
to
do's
on
or
reed's
plate,
but
as
a
potential
thing
since
hannah
raised.
So
many
of
the
release.
Examples
for
us.
A
A
Well,
this
has
been
a
great
discussion.
I
appreciate
it
everyone
it
was
really
good
yeah.
I
I
thought
we
were
getting
close
to
this,
isn't
a
problem.
I
think
we
still
found
some
things
that
we
could
potentially
solve
and
it
didn't
end
up
anywhere
close
to
where
I
thought
it
would,
but
that
is
okay.
I
think
this
was
time
well
spent
and
that's
refining
some
user
experience
today
that
we
can
make
people's
get
lab
experience
a
ton
better
and
that's
why
we
do
these.
C
D
James,
I
also
suggest
you
reach
out
to
dove
since
he'll
be
working
to
to
improve
the.
I
think
the
templates,
but
also
oh,
my
goodness.
What
are
they
calling
the
generating
a
drawer
for
helping
to
help
write
the
emo
file,
my
goodness
anyways
I'll
link
the
issue.
C
James,
if
you
create
an
issue
out
of
this,
I
can
link
it
to
whatever
we
create.
In
addition
to
adding
the
thinking.
Like
I
don't
know,
okay,
I
wasn't
planning
on
creating
an
issue.
Oh
okay,
I
didn't
know
if
we
did
that
out
of
think
big
session.
Okay
sounds
good.