►
From YouTube: CI-CD Cross Stage ThinkBIG! 2020-03-12
Description
Our first meeting where the CI/CD and Ops Product Designers and Product Managers came together to discuss cross-stage initiatives to improve our user's experiences.
A
Hi,
everyone
welcome
to
the
very
first
cross
stage.
Think
big
section
meeting
here
at
gate
lab
this
is
the
CI
CD
and
ops
group
will
dive
right
into
the
agenda.
So
one
of
the
reasons
we're
here
is
we
got
the
sus
score
or
the
system
usability
scale.
We
did
some
research
found
out
some
overarching
themes
around
what
our
users
are
feeling
about,
get
lab
in
general,
and
there
were
two
notes
that
I
thought
would
be
a
good
thing
for
us
all
to
address
this
one.
A
We
have
a
bit
of
a
walled
garden
experience,
so
each
feature
set
or
stage
kind
of
has
an
isolated
experience
for
our
users
and
the
other
is
that
getting
started
with
CI
CD
is
an
experience
that
we
could
improve
upon.
This
came
directly
from
the
sus
core
I
think
a
few
of
us
have
heard
that
just
talking
to
our
users,
so
I
don't
think
anyone's
really
surprised
by
that.
A
What
I
would
like
to
do
is
this
meeting
is
full
of
these
strategic
focuses
for
the
CI,
CD
and
Oxford.
So
this
is
the
product
designers
and
product
managers
and
I'd
like
for
us
to
come
together
and
talk
about
the
high
level
strategy
of
ways
that
we
could
resolve
some
of
the
issues
our
users
are
experiencing
outside
of
just
a
single
stage.
A
I
was
just
gonna
shamelessly
use
my
own
first
point
as
an
example,
so
good
call
Nadia
I
was
trying
to
be
sneaky,
but
you
caught
me
so
diving
into
the
first
idea.
One
of
the
areas
that
we
could
improve
upon
as
a
cross
age
unit
is
displaying
some
of
the
package
data,
and
so
that's
the
overall
question
and
the
thing
I'd
like
to
brainstorm
is:
where
can
we
present
this
data?
That's
not
the
package
UI
to
help
guide
the
conversation
and
kind
of
start,
some
brainstorming.
We
got
this
insight
from
our
users
and
I.
A
Think
that's
a
really
important
thing
to
call
out
is
this
is
their
experience,
and
this
is
representing
what
they've
talked
about
for
two
things
that
are
kind
of
related
to
this.
We
heard
from
all
of
our
users
pretty
regularly
that
if
they
never
have
to
go
to
the
package
UI
their
life
is
incredible.
It's
a
set
it
and
forget
it
feature.
So
as
long
as
it's
working
as
long
as
it's
predictably
doing
what
it's
supposed
to
be
doing,
they
never
want
to
visit
us
ever,
which
is
fantastic.
A
Being
an
invisible
feature
is
great
one
of
the
things.
The
three
main
reasons
they
come
to
our
UI,
which
is
again
we
came
from
research,
was
the
easy
one
is
to
check
and
see
if
the
package
I
uploaded
is
in
the
registry
like
it's
supposed
to.
This
is
a
pretty
encapsulated
issue
and
not
one
that
I
think
can
really
spread
apart
through
the
rest
of
CI
CD,
but
the
other
two
research
points
are
pretty
important.
A
The
first
one
is
that
they
are
visiting
the
packaged
UI,
the
registries,
whether
it
be
a
container
or
a
package
to
check
if
CI
builds
it
properly
and
published
it,
and
it's
just
the
final
check
to
make
sure
it
was
in
there.
So
this
could
mean
that
there's
places
in
the
pipeline
views
that
we
can
just
show
them
hey.
We
created
this
thing
and
they
never
have
to
go
to
the
UI.
The
next
is
a
little
bit
more
ambiguous.
A
One
of
the
reasons
they're
coming
to
visit
the
UI
is
to
look
up
what
version
of
a
package
they're
supposed
to
be
using
whether
that
be
what
is
the
new
released
container
or
image?
That's
supposed
to
be
used
in
production.
What's
the
new
dev
environment
there's
a
lot
of
those
different
areas
that
they're
looking
for
that.
If
we
could
offer
that
somewhere
else
throughout
the
rest
of
CI
CV,
we
could
really
enable
our
users
I'm
going
to
pause
for
a
second.
Those
are
the
two
research
insights
looks
like
Dimitri,
already
joven
and
has
an
idea.
A
A
Before
we
dive
into
high
on
our
mic,
I
do
want
to
make
one
more
comment.
That's
super
important
and
we
learned
our
lesson
with
our
package
stink
bags.
It's
really
important
that
we
take
notes
in
the
document
so
that
it
can
be
transformed
into
actionable
insights
as
well
as
include
everyone
that,
maybe
you
can't
make
this
time
zone.
So
if
we
can
all
work
together
and
be
awesome
at
notes,
that
would
be
much
appreciated.
Thank
you.
D
E
But
I've
heard
from
users
stability
on
the
UI
as
well
any
other
package.
They
are
soft
information
from
the
interface
as
well
and
have
the
ability
to
even
mean
that
make
available
to
different
types
of
users
in
their
systems.
So
we
think
about
as
well
permissions
and
things
like
that.
Around
passage,
I.
A
Ayana,
have
you
heard
anything
about
kind
of
the
usage
of
images
in
the
release,
as
well
as
packages
packages
and
images
tend
to
have
a
unique
usage?
One
of
the
things
I've
heard
from
our
users
is
when
we
release
a
new
version
of
our
software.
That
means
there's
a
new
image.
That's
supposed
to
be
used
for
everything.
Have
you
heard
anything
like
that
in
terms
of
release
or
the
way
that
they're
thinking
about
it.
E
F
A
A
Individual
sorry
organizations
that
we've
talked
to
tend
to
work
a
little
bit
more
manually
where
they've
gone
through
the
process
and
releasing
a
new
one,
and
then
they
want
the
commit
Shah.
Sorry
they've
used
the
commit
Shah
for
whatever
generated
this
new
release
as
the
tag
name,
and
so
they
have
to
go.
Get
that
ok.
D
A
A
D
D
So
it
seems
like
a
lot
of
time,
but
if
there
is
an
image
that
is
tied
to
a
release,
it
could
be
something
that
we
could
maybe
add
to
the
release,
evidence
page.
That
might
be
an
easy
way,
I'm,
not
sure
the
same
works.
The
same
is
true
for
packages,
though,
because
packages
tend
to
be
more
seen
as
code
and
not
tied
to
a
given
and
release
they're
kind
of
ongoing,
so
ongoing,
always
under
development,
but
at
least
for
images
it
does
seem
like
people
want
to
get
back
to
that
release,
time.
Environment.
D
C
So
this
question
was
recently
brought
up:
I,
read
it
somewhere
this
week,
I
believe
and
I.
This
was
brought
up
by
you
and
I.
Believe
you
asked
is
this
his
package
information
searchable
in
like
a
pipeline
to
you
and
they
need
the
example.
You
showed
was
of
a
pipeline
list,
page
and
I
think
my
answer
upon
that
was
I.
Think
it
makes
sense
to
to
show
it
in
the
pipeline
detail
view
for
sure.
On
the
other
hand,
in
the
pipe
on
list
you
we
should,
you
know,
make
it
a
you
know.
C
We
should
really
consider
it
if
it's,
if
it's
in
there
like
I,
would
say,
I've
only
streams
more
from
managing
pipelines,
instead
of
you
know
like
finding
out
or
downloading
multiple
versions
of
packages
across
pipelines,
but
I
could
be
wrong
like,
but
that
was
my
answer
back
then
I.
If
I
recall
correctly,
for.
A
Sure
I
think
your
first
point
is
really
valid.
The
detail
page
is
a
place
where
the
robust
package
data
could
be
I,
do
think,
there's
an
opportunity
when
users
are
looking
at
the
different
pipelines
and
what
they
produce
and
what's
going
on
pipelines
that
end
up
producing
a
new
image
or
a
new
image
with
a
certain
type
like
name
or
tag,
or
something
like
that,
would
help
determine
what's
happening
in
the
pipeline
in
that
kind
of
preview
of
all
the
different
pipelines.
Does
that
make
any
sense
or
Tim
do
you
have
any
thoughts
on
that?
A
A
Sure
so,
when
I've
talked
to
some
users,
they,
depending
on
the
outcome
of
a
pipeline,
if
I
pipeline,
will
produce
an
important
image
or
will
produce
a
new
version
of
a
package,
I
think
it's
useful
to
show
that
in
the
pipeline
list
view,
because
that's
two
differents
have
different
goals.
If
it
does
do
this
or
if
it
doesn't,
we've
kind
of
heard
that
from
from
users,
is
there
any
other
things
like
that
or
artifacts
that
get
created
that
are
shown
in
the
pipeline
view?.
D
A
A
Was
initially
thinking-
and
this
is
I'm
Way
out
of
my
depth
here,
so
everyone
can
feel
free
to
tell
me
this
is
not
a
good
idea,
but
in
the
pipeline
to
you
having
some
sort
of,
even
if
it's
an
icon
of
a
container
that
just
highlights
like
what
happened
in
that
pipeline
I,
don't
know
if
that's
an
option
we're
showing
now
but
I,
just
heard
from
users
that
that
does
differentiate,
how
they
view
a
pipeline.
If
it
creates
the
image,
it's
an
import,
it's
a
different
type
of
pipeline
for
them.
F
C
F
A
C
D
G
When
when
we
say
the
pipeline
details
page,
are
we
talking
only
on
the
pipeline
tabs
because
there
is
a
job
tabs
in
a
I?
Don't
over
talk
about
the
same
thing?
It
might
be
helpful
to
pinpoint
which
job
did
the
build
of
that
package
and
when
I'm
talking
about
real
quickest.
Is
this
example
here
where
I
know
when
you
know,
and
they
go
to
a
pipeline
details
of
you,
you
land
on
that
tab,
but
there
is
that
jobs,
town!
G
A
C
A
C
Additionally,
there
are
some
other
in
some
other
insights
here
shared
where
users
have
given
the
opinion
that
they
would
like
for
girls
to
be
able
to
build
locally,
where
they
you
know,
are
in
control
of
every
aspect
of
it
and
I
would
say
in
the
end,
the
idea
is
to
have
the
builds
be
faster.
He
run
faster,
of
course,
the
bigger
problem
is
that
more
impossible?
That
is,
but
they
want
to
give
that
that
feedback
loop
they
want
to
keep
it
as
short
as
possible.
C
Basically
and
lastly,
let
me
see
people
are
looking
for
both
pipeline
status
and
progression.
So
what
happens
when
a
user
is
less
certain
about
their
pipeline
configuration
or
the
code
there
to
stop?
They
are
more
interested
in
what's
really
going
on
inside
of
the
job
and
how
the
code
is
progressing
instead
of
just
like
hey
did
my
pipeline
do
well
or
not,
which
it
will
go
towards
like
the
users
more
interested
in
you
know
good
or
bad,
if
they're
more
certain
about
their
code
or
their
primal
configuration
rather
sort.
C
H
No
problem
well,
I'm
gonna
go
to
an
area
that
I
seems
to
be
overlooked.
A
lot
but
I
feel
like
it's
my
baby,
so
on
the
spot,
I'm
gonna
bring
up
pages
right,
like
pages
rises
and
fall
on
whether
or
not
that
pipeline
succeeded
in
that
process.
Right,
like
are
our
pages.
Implementation
essentially,
is
just
a
CI
tool
that
runs
right,
but
there
is
a
big
gap
between
people's
understanding.
Generally
of
you
know,
coming
from
other
things
like
a
wordpress
or
something
like
that,
people
want
to
interact,
say
build
this
thing.
H
Do
that
thing,
but
really
this
is
as
the
pipeline
that
they're
not
expecting
going
over
there.
So
on
the
pages
settings,
maybe
a
page,
a
status
of
of
where
pipelines
have
succeeded
and
failed
and
then
that
ultimately
results
in
a
pages
delivery
right.
It's
it's
almost
like
a
release
of
a
page,
so
everything
somewhere
in
the
pages
settings
might
be
an
interesting
place
to
surface
that
kind
of
information.
C
H
H
Really
pages
exists
as
just
a
domain
settings
thing
that
kind
of
tucked
away
deep
in
the
settings
thing,
but
if
we
had
some
sort
of
dashboard
like
that,
that
would
that
that
would
honestly
be
the
thing
that
would,
in
my
opinion,
drive
us
too
need
a
dashboard
type
of
thing,
which
is
what
users
are
really
looking
for.
We
found
in
our
user
testing
nine
times
out
of
ten
when
people
are
going
to
the
pages
settings
page.
What
they
want
is
a
dashboard.
What
they're
getting
is
a
domain
settings
configuration?
H
H
It's
really
that
is
just
the
is
it
built
right
like
I,
if
you
go
through
the
process
right
to
create
a
pages
deployment?
Really
it's
it's
one
or
two
lines
of
code
in
your
Yamaha
right,
like
it's
a
page
job
that
says,
build
your
thing
and
and
usually
folks
that
are
doing
that.
Don't
really
have
the
idea
of
you
know
full-on
CI,
CBE
and
that
whole
process.
H
So
if
they
just
had
this
simple
little
like
status
of,
did
it
get
built
I
added
my
line
of
code,
I
read
the
documentation,
I
figured
out,
it
ran,
but
right
now
the
only
way
to
do
that
is
is
it's
checking
in
on
the
pipelines
and
if
you're,
not
a
CI,
CD
user.
You
have
no
idea
what
a
pipeline
days
are
job
and
you
really
don't
want
to
acquire
that
information.
You
just
want
to
know
like
east
was
asleep.
F
Authority
is
this
behavior
that
you're
describing
happening
because
people
commit
to
master
directly,
because
I
would
expect
that
on
a
merge
request,
you
can
see
the
pipeline
widget
and
you
you'll
have
that
knowledge
of
whether
the
pipeline
is
gonna,
fail
or
not.
You
know
so
essentially
giving
you
insight
into
whether
it's
gonna
build
or
not,
but
what
it
seems
that
you're
saying
is
that
maybe
they
are
usually
committing
to
master
and
then
maybe
it
fails,
so
it
never
makes
it
to
master
because
it
never
really
actually
happened.
You
know
and
then.
F
H
I
think
you're,
hitting
on
a
good
point
there
that
yeah
a
lot
of
times
with
a
pages
project
in
particular,
but
maybe
we
can
expand
this
outside
of
the
pages
realm
a
little
bit
there
of
yeah
it's
it's
generally
you're,
less
advanced
users
that
want
to
you
know
just
understand
this
status
thing
and
they
don't
really
understand
the
whole
build
process
and
they're.
Maybe
not
maybe
their
project
isn't
even
at
the
point
where
they
they
want
to
get
into
that
whole
world
right.
H
It's
like
Auto,
DevOps,
plus
one
right
pages,
isn't
part
of
the
Auto
DevOps,
but
I
think
maybe
that's
the
user
we're
targeting,
and
maybe
we
can
expand
this
conversation
out
of
like
where
should
we
surface
the
status
type
information
would
probably
be
a
good
persona.
To
look
at
is
the
less
complex
I
have
a
very
simple
project:
I'm,
not
worried
about
branches,
I'm,
not
worried
about
that.
Like
the
simplest
places
for
our
less
advanced
users,
it's
probably
the
exact
kind
of
person
that
would
want
that
status.
I
I
Is
there
any
merit
to
pairing
that
information
with
anything
else?
This
comment
is
coming
from
world
of
let's
build
all
the
dashboards.
Oh
and
now
we
have
different
tabs
for
all
the
dashboards
and
oh
wait
now
any
one
meta
dashboard
for
all
the
dashboards,
so
I
use
caution
against
creating
a
dashboard
for
each
particular
thing,
not
that
that's
what
we're
doing
here,
but
just
keep
that
in
mind
like
can
we
pull
this
information
into
something
else
to
show
it
in
in
provide
additional
context,
instead
of
to
wait
something
standalone.
H
D
H
You
know
we
do
have
this.
Every
project
has
a
project
details,
page
right
and
at
the
top
of
that,
or
maybe
somewhere
in
that
like
maybe
this
is
a
great
place
of
servicing,
because
that
would
that
would
alleviate
the
need
for
a
pages
dashboard
it
wouldn't
it
would
be.
You
know
here
is
the
status
of
things
that
have
happened,
and
maybe
you
know
of
the
pipeline,
but
also
maybe-
and
we
maybe
that's
another
place-
we
serve
for
some
package.
Information
too
is
well
right.
Maybe
there
is
just
a
here.
H
F
It
does
show
the
latest
commit,
though
honey,
if
it's
being
run
through
a
pipeline.
You
better
show
that
at
the
top
of
the
file
list,
if
a
pipe
and
is
currently
being
run-
and
you
will
see
a
little
widget
there-
that
it
says
merge
branch
to
blah,
blah
blah
and
to
master,
and
then
it's
gonna
have
the
spinning
icon
of
the
pipeline.
So
in
there's
precedent
that
there's
already
a
pipeline
feedback
there,
perhaps
the
problem
is
that
people
don't
get
it.
Did
you
see
that
and
you're
like
yeah,
whatever
I.
C
Suspect
the
same
problem
as
you
assume,
with
them
wishing
to
master
directly
and
pages
being
in
our
notification.
The
only
like
pages
reference
in
our
navigation
is
the
settings,
so
people
are
navigating
they're
like
this
is
purely
at
something
that
people
are
navigating
there
and
then
we
wanted
to
see
information
about
pages.
They
do
not
make
a
correlation
between
pipelines
and
pages.
Yet
so
I'd
say
there's
some
some
opportunity
there
for
us
to
do
better
in
environments
potentially
or
on
the
project
setting
or
project
details
page,
as
you
suggest,.
F
Detail
you'll
where
you
have
the
list
and
I
could
get
maybe
a
little
bit
more
feedback
on.
What's
going
on
pipeline,
wiser
I
think
that
that
could
solve
for
many
of
these
problems.
Perhaps
but
I
don't
know,
that's
my
personal
experience
is
that
still
thought
you
had
to
drill
down
a
lot
to
just
fine,
hey
it's
the
pipeline
running.
You.
E
E
Environment
and
the
deployments
that,
if
you
have
projects
right
get
land,
is
very
difficult
to
get
a
notion
of
how
your
new
projects
are
doing
like
have
this
I
mean
we
don't
have
to
go
with
the
dashboard.
Our
proposal
is
to
go
in
a
dashboard,
but
we're
meeting
like
this
linking
point
to
see
and
manage
like
the
health
status
up
here,
public
pipelines
and
we
do
have
the
the
environments
art.
E
E
G
E
E
D
Totally
agree
with
this:
every
every
time
I
see
a
pipeline
running
I
get
the
original
notification
that
it
started
and
then
to
navigate
to
it.
I
have
to
go
to
find
my
project
and
find
my
merge
request
and
then
I
click
my
pipeline.
So
it
feels
like
it
takes
me
three
or
four
steps.
Each
time,
if
I
get
to
see
it
at
the
top
of
my
project,
that
there's
a
pipeline
running
a
little
indicator
and
I
could
drill
in
from
there.
That
would
be
really
they'll.
F
J
C
H
And
one
interesting
thing
that
I
stumbled
across
the
other
day
is
that
digging
through
settings.
You
know
there
is
a
place
in
our
settings
where
you
can
grab
a
snippet
and
put
it.
We
have
it
in
markdown
or
a
snippet
or
whatever
that
essentially
allows
you
to
wherever
you
have
markdown.
You
are
able
to
show
this
information
right.
We
can
do
this
this.
This
exists.
We
write
code
make
this
happen.
H
Maybe
it's
something
to
do
with
that
right,
where
we
just
evangelize
that
that
is
a
thing
that
can
happen
and
wherever
you
have
markdown.
You
can
include
this,
whether
it's
an
issue,
a
merger,
but
what
you
know
whatever
you
want
to
do
any
place
that
there's
markdown
ie
everywhere.
You
can
do
this
so
that
one
might
be
an
interesting
one,
just
evangelizing
that
I
believe.
H
A
Dimitri's
done
I'm
done,
I
wants
anything.
I
was
just
going
to
say
in
terms
of
time
management
we
have
about
15
minutes
left,
so
I
thought
it
would
be
good
to
try
to
get
this
third
topic
in
there,
and
then
we
have
a
little
bit
of
a
wrap-up
so
plus
there's
any
final
thoughts.
Let's
move
to
progressive
delivery.
H
All
right,
that's
hoping
I,
always
hoping
that
would
happen,
because
what
I
just
said
dovetails
perfectly
it's
my
point
right.
So
we
have
a
lot
of
things
that
we
can
do.
A
great
example
would
be
you
can
have
your
pipeline
status
in
markdown
and
display
that
wherever
you
want
the
problem
is
people
don't
know
about
a
lot
of
this
stuff
right?
So
we
suffer
from
this
a
lot
impressive,
progressive
delivery,
feature
Flags
spinnaker
auditor
review
apps,
but
we
found
a
lot
of
times.
H
Is
we're
getting
low
adoption
of
these
things
and
user
interviews,
and
things
like
that
are
showing
that
it's
not
well.
We
do
have
room
for
improvement
in
our
our
implementation
of
these
features.
A
lot
of
the
reason
why
we
have
low
adoption
of
these
things
is
people
just
aren't
aware
that
they
exist
right
so
review.
Apps
is
a
great
example:
everybody
that
uses
it
loves
it
one
of
their
favorite
feature.
Why
are
people
not
using
it
if
they
don't
know
what
it
is
and
they
don't
know
how
to
set
it
up?
H
A
Not
in
my
head
cuz,
you
said
our
documentation
could
improve
and
I
was
I
was
resonating
with
that.
We
just
are
in
the
middle
of
a
big
process
around
that.
My
question
is
you
had
mentioned
Auto,
DevOps
and
kind
of
users
are
expecting
the
ability
to
just
kind
of
turn
it
on.
Do
you
think
that
scenario
we
should
explore
some
of
these
more
advanced
features
that
our
users
really
love.
H
Yeah
and
there's
a
related
feature
or
issue
to
this,
the
difficult
things
that
I
found
personally
and
also
is
coming
in
huge
interviews.
A
little
bit
is
going
it's
Auto,
DevOps,
plus
one
right,
so
Auto
DevOps
is
great.
If
it's
bigger
than
it
does
everything
that
you
need
you
hit
the
button
magic
happens.
Your
world
is
wonderful,
but
the
moment
that
you
want
to
step
one
step
past.
That
essentially
requires
you
to
burn
down
your
Auto
DevOps
and
then
recreate
that
itself.
H
You
know
because
our
templating
system,
if
you're
using
the
web
ID
to
edit
this
thing
or
even
if
you're
doing
it
yourself,
your
option,
is
either
like
Auto
DevOps
is
on
and
then
there's
this
yamo
file
that
exists
out
there
and
magically
and
that
you
don't
really
have
access
to.
So
you
now
have
to
create
your
own,
which
you
could
use
the
template
for
Auto
DevOps,
but
you're.
Faced
with
you
know,
going
back
to
pages
again.
If
you
want
to
use
the
pages
example,
it
doesn't
include
all
the
auto
dev
ops
stuff.
C
C
I
couldn't
really
find
out
exactly
what
it
was,
but
in
the
end
where
it
came
down
out
through
that
github
actions
was
easier
to
use
for
them,
and
then
we
jumped
a
little
bit
in
today
into
details
on
that,
and
they,
where
we
came
out
to,
is
that
the
get
up
actions
has
some
kind
of
feature
of
like
you
could
say
it
like
sub
templates.
So
you
can
add
snippets
into
your
CI
configuration
which
are
managed
like
community
managed
and
then
that
snippet
has
variables
which
are
configurable
by
the
current
user.
C
So
you
could
say:
hey
I,
want
to
you
know:
I
need
to
make
connection
with
my
SSH
server
Wow
all
useless
SSH,
snippet
I'll
put
it
into
my
gillip
CIL
and
then
I
just
need
to
configure
this.
You
know
this
user
name
and
a
user
password
and
then
I
got
a
connection
with
SSH
no
pain.
And
if
something
is,
you
know
something
up
dated,
then
the
maintainer
of
the
snippet
does
that
and
automatically
stays
working
like
the
library
kind
of
thing
right,
yeah
makes
make
sense.
G
So
composable
the
auto
devops
lets
you
pull
out
distinct
jobs
within
the
entire
Auto
DevOps
templates.
The
CIA
template
to
use
I
had
this
discussion
with
Jason
a
while
back
when
I
was
working
on
templates
group,
which
is
now
not
getting
funded,
but
about
whether
or
not
we
wanted
to
model
something.
After
what
github
has
four
actions
which
uses
the
model
of
building
blocks
for
pieces
of?
G
Is
there
is
a
story
that
exists
now
to
enhance
the
way
our
templates
work
to
allow
when
you
create
a
template
and
it's
being
used
to
dynamically,
allow
the
user
to
add
variables
at
that
time.
We
don't
support
that
now.
I
can
see
pursuing
that,
but
not
necessarily
modeling.
What
we're
going
to
build
after
the
github
actions.
H
Awesome,
thank
you.
I
do
I,
don't
know
if
anybody
else
has
any
other
topics
on
that
yamo
file
being
a
potential
place
for
this,
but
I
think
that's
one
of
potentially
hundreds
of
ways
we
could
evangelize
or
a
surface
that
features
exist.
You
know,
other
ideas
could
be
you
know
kind
of.
If
you
have
feature
X
feature,
Y
is
presented
to
you
as
an
option:
infinite
bit
space
or
a
modal
or
or
that
kind
of
idea.
H
A
Funny
that
you
mentioned
that
yesterday
was
packages.
Think
big
and
one
of
the
conversations
we
were
having
is
how
to
improve
usage
of
the
dependency
proxy,
and
this
might
be
one
of
those
places
where
the
real
value
of
the
dependency
proxy
is.
It
can
speed
up
your
pipelines,
so
that
might
be
a
place
where
we
can
nudge
a
user.
Like
you
had
mentioned
something
subtle
like
a
toaster
may
be
one
of
those
little
marketing,
banners
that
says
hey.
You
can
speed
up
your
pipelines.
A
K
I
know
that
the
growth
team
is
working
on
a
couple
of
different
like
in-app
messaging
capabilities
and
push
messages
to
customers
or
even
like
a
be
testing.
So
if
there's
certain
triggers
that
we
can
add
to
the
in-app
messaging,
so,
for
example,
if
they
are
on
the
environment,
variable
page
saying
like
hey,
did
you
know
you?
K
Can
you
know,
mask
this
variable
or
do
whatever
you
want
to
do
with
it,
like
those
are
kinds
of
activities
that
I've
seen
done
in
other
applications
really
elegantly,
but
they
have
used
things
like
Penn
know
or
and
what
you
to
to
force
a
user
journey
if
the
workflow
is
predictable,
I
think
that's
one
challenge.
Let's
get
loud,
that
we
don't
necessarily
have
a
journey
that
we
want
to
shove
a
user
toward,
but
there
are
certain
actions
that
we
do
want
to
encourage
the
adoption.
K
So
I
think
that
if
we
look
at
it
at
a
per
stage
level
or
per
group
level,
we
might
be
able
to
find
some
events
to
trigger.
But
I
do
feel
like
unless
we
map
out
customer
journeys
that
we
want
to
encourage
that's
kind
of
like
the
precursor
to
then
effectively
encourage,
discoverability
and
understand
what
are
like
the
high
priority
flows
that
we
would
want
to
force
her
a
doctor
mandate
whatever.
Whatever
word
you
want
to
use
there,
yeah.
H
And
I
think
that's
a
great
point
that
the
growth
team
is
being
very
cautious
in
the
way,
and
you
know
we
have
a
dedicated
team
to
doing
that
thing.
So
it
does
not
become
the
Wild
West,
because
this
quickly
spirals
out
of
control.
If
every
designer
every
p.m.
says
my
things
important
and
we
all
push
toast,
then
we
get
lab
quickly
becomes
an
unusable
platform.
We're
the
biggest
requested
feature,
be
catering.
H
Disc-Off
I
never
want
to
see
this
again
right,
so
I
think
it'll
be
very
important
for
us
as
an
entire
CICE
team
to
prioritize
the
most
important
features-
and
you
know
wit
once
the
growth
team
gets
to
the
point
where
they
are
reaching
out
and
and
looking
to
expand
that
which
I
assume
will
happen.
We
have
a
strategy
in
place
of
you
know
a
holistic
strategy
right.
We
can't
all
just
say
our
thing
is
important
and
let's
surface
everything
we
need
to
have
a
prioritized
list.
I
would
say
yeah.
K
And
I
think
that's
what
I
mean
by
flows
like
user
behaviors
or
goals
they're
trying
to
accomplish
with
gitlab,
because
when
we
start
looking
at
feature
granularity,
we
miss
things
like
driving
active
users
over
a
consistent
period
of
time
so
like.
If
we're
not
aligned
to
accomplish
a
certain
action.
As
a
group,
then
we're
going
to
be
very
myopic
and
focused
on
executing
one
behavior
and
then
again
like
that,
could
be
a
really
jarring
or
disappointing
experiences
for
a
persona.
K
That's
typically
using
a
CLI
and
only
popping
in
to
check
out
the
UI
and
one
feature
or
is
typically
always
in
the
front
end,
is
trying
to
do
their
day
to
day
job.
So
it
might
be
interesting
if
we
take
the
time
and
our
next
think
bag
to
like
look
at
the
personas
that
CIC
Dee
wants
to
tackle
as
a
whole
and
kind
of
map
out
the
different
flows
that
we'd
want
to
work
toward
as
a
group
and
then
that
we
we
can
then
serve
this
back
to
the
growth
team.
F
I
was
just
gonna
point
out,
like
kind
of
going
back
to
Mike's
question
of
like
another
area
could
be
those
buttons
where
both
the
file
list
in
the
project
detail
I,
not
only
we
have
telemetry
on
these
but
like
when
you
have
a
fresh
new
project.
That's
one
area
where
out
of
their
objects
is
suggested.
So
I
don't
know
if,
like
there's
a
lot
of
activations
of
out
to
DevOps
and
adoption
through
that
button
parade,
but
I
always
found
that
interesting
and
I.
F
Don't
think
we'll
never
reach
that
right,
and
what
I
like
about
that
just
is.
Is
that
it's
very
ad
hoc,
so
kind
of
like
from
what
jackie
was
saying
that
we
don't
want
our
in
our
impose
a
user
journey.
We
want
to
be
more
ad
hoc.
In
that
sense,
if
you
are
about
under
saying
enable
feature
flux,
you
know
that's
a
very
ad
hoc
way
of
telling
them
hey,
there's
a
new
feature
that
you
could
check.
You
know
so
just
an
idea.
A
Perfect
I'm
going
to
jump
into
this
little
lull.
That
was
great
everyone
I
think
that
was
really
exciting.
It's
time
for
the
meeting
to
end
I
II
am
really
excited.
Thank
you.
Everyone
again,
I
say
this
a
thousand
times
for
contributing
and
talking
through
all
this,
it
was
really
nice
to
get
perspectives
outside
of
my
own
stage
in
terms
of
what
people
are
talking
about
and
how
we're
working.
A
Unfortunately,
we
don't
have
time
for
release
management.
I
am
very
sad
about
this,
but
assuming
we
want
to
move
forward,
that
can
be
our
first
topic
for
our
next
think,
big
wrap-up
and
next
steps.
Everyone
please
go
through
the
agenda
and
if
there's
any
thing
that
could
be
turned
into
an
issue
and
started
to
plan
and
think
about,
please
make
sure
to
create
those
issues
and
add
the
think
big
label
it
was
created.
A
That's
our
way
to
track
how
much
these
meetings
impact
our
work,
it's
a
metric
that
we
can
use
so
I
really
appreciate
it,
and
the
other
thing
I'm
going
to
ask
which
is
super
annoying
is
if
everyone
could
please
visit
the
retro
issue.
There's
a
link
in
the
agenda
and
just
leave
your
feedback.
We've
asked
a
couple
of
questions
which
is
basically
was
this
beneficial?
A
Is
there
something
we
can
improve,
and
would
you
do
it
again
if
you
could
fill
that
out
and
let
us
know
that
would
be
great
sooner
is
always
better
I
think
that's
the
universal
truth
of
a
lot
of
things,
but
this
will
help
us
decide
if
everyone's
interested,
if
we
thought
this
was
productive,
we
can
schedule
out
the
next
one
and
start
turning
this
into
a
more
formal
session.
I
imagine
might
get
lab'
brain
saying
that
there's
an
Mr
to
the
handbook
coming
if
we
want
to
move
forward.
A
E
A
A
great
question
package
has
found
a
sweet
spot
in
the
monthly
cadence,
and
so
once
a
milestone,
we
have
lots
to
talk
about,
and
but
we're
still
respecting,
everyone's
think
time
is
being
very
precious.
I,
don't
know
what
everyone
else's
thoughts
are,
but
that's
just
the
the
perspective
that
I
have.