►
From YouTube: Release Management ThinkBig #9
Description
Welcome to our ThinkBig Session! We discussed https://gitlab.com/gitlab-org/gitlab/-/issues/199739 and a few other top items for Release Management!
A
All
right,
everyone
welcome
to
our
ninth
release
management,
think
big
session.
We
actually
have
a
guest
here,
hi
Michael
from
the
Tech
evangelism
team,
he's
gonna
sit
in
and
watch
our
think
big
session
kind
of
go
down.
Michael
has
been
an
incredible
partner
when
he
was
a
customer
of
ours,
especially
in
the
early
expansion
section.
So
I'm
really
excited
to
have
him
kind
of
join
here.
A
Okay,
so
last
waiting,
we
were
very
focused
on
the
editing
of
the
release
page
and
building
out
that
UI
experience.
We
also
talked
a
little
bit
about
deploy
freezes
and
this
think
of
Accession
I
would
like
us
to
take
a
look
at
our
CI
CD
dashboard
issue.
So
I'm
gonna
go
ahead
and
share
my
screen
and
we
can
walk
through
a
couple
of
different
things
on
this.
So
first
I
had
a
call
with
a
couple
of
different
users
to
talk
a
little
bit
about
two
main
issues.
A
The
first
issue
that
users
are
citing
are
the
inability
to
manage
things
across
multiple
projects.
So
the
heart
of
this
issue
is
multi
project
users
that
are
looking
to
monitor
things
like
releases
pipelines,
quality
across
multiple
repositories.
So
in
today's
world,
a
lot
of
our
customers,
a
portion
of
our
customers,
are
using
the
environments
dashboard
to
triage
failed
issues,
but
the
environments
dashboard
for
people
who
have
a
lot
of
projects
and
a
lot
of
environments.
A
This
is
rendered
unusable,
so
they're
only
able
to
filter
on
seven
projects
with
three
environments
per
project.
So
what
we're
hoping
to
accomplish
is
a
simpler
group
level
view
for
somebody,
that's
in
a
management
position
or
potentially
a
release
manager,
who's,
coordinating
across
multiple
teams.
I
built
this
really
crummy
lo-fi
dashboard.
Please
don't
laugh
if
you're
gonna
laugh
at
me
hide
your
screen.
I'm
a
sensitive
person
and
I
spoke
with
hang
on
a
little
bit
on
this,
but
really
I'll
link
this
and
the
issue
as
well
or
in
our
think
big
session.
A
Oh,
you
already
did
the
Hana
thank
you
and
what
we're
thinking
is.
We
would
start
aggregating
metrics
that
are
currently
available
at
the
project
level.
So
we
have
a
lot
of
the
pipeline
information
already
available
at
a
pipeline
view,
and
then
we
would
start
landing
more
meaningful,
metrics
about
releases
and
then
I
have
this
tile
here
for
either
runners
or
code
coverage,
but
would
love
to
hear
your
guys's
thoughts
on
one.
That's
the
problem
statement:
I
am
a
user
that
is
managing
across
multiple
projects.
A
A
And
welcome
John
hi
Nathan.
How
are
you
we're
diving
into
the
CICP
dashboard
issue
that
is
currently
queued
up
for
13.1
it'll,
probably
be
13.2,
since
our
three
milestone
will
be
in
13.1,
but
I
wanted
to
kind
of
think
big
on
this,
and
this
can
be
us
looking
at
this
initial
lo-fi
and
kind
of
picking
at
it
or
thinking
about
future
iterations.
B
Let's,
let's
look
at
your
design
right
now
and
let's
talk
through
it
and
see
what
you
guys
think
like
is
this
useful?
Would
this
be
useful?
What
other
information
here
should
be
here?
What
information
shouldn't
be
here?
These
are
the
questions
we
ask
ourselves
and
this
exists
until
a
Tuesday
morning.
C
Putting
myself
in
later
in
the
director's
shoes
I
think
this
would
be
pretty
slick
to
come
in
here
and
get
a
snapshot
exactly
kind
of
what's
going
on
in
my
so
I
could.
Think
of
this
is
like
and
I
have
a
repudiation
I
could.
Think
of
this
is
like
this
is
my
group,
clothes
say:
I
have
a
group
created
with
a
few
projects
underneath
of
that
I?
Could
think
of
this
is
coming
in
and
seeing
a
snapshot
right
of
that
group?
Everything
that's
going
on
within
my
crew
without
having
any
more
detail.
A
One
thing
that
I'm
that
I'm
constantly
played
with
is
the
idea
of
visibility
versus
action
ability,
so
today,
I
wanted
to
display
things
that
would
give
people
one
a
high
level
view
of
how
things
are
today
and
then
provide
trends
over
time,
so
they
could
see
how
does
today
compared
to
how
things
have
been,
and
then
this
click
into
the
triage
moment.
So
my
current
state
is
on
fire.
I'm
gonna
go
down
to
this
view
here
and
see:
oh
my
gosh,
okay.
Well,
actually
I've
been
on
fire
for
the
past
couple
of
months.
A
Maybe
it
doesn't
matter,
here's
my
last
five
pipelines
that
have
been
failed,
I'm,
gonna
click
into
the
and
then
get
into
that
project
and
start
moving,
but
going
back
to
kind
of
like
Lori's
questions.
What
other
information
should
be
here,
if
you're
a
director?
What
do
you?
What
would
you
actually
expect
to
see
when
you
land
here,
even
as
a
developer,
because
we're
giving
this
would
be
a
default
group
view?
What
are
the?
What
are
ways
that
we
can
serve
multiple
audiences
within
the
same
group.
C
A
B
A
Think
John
you're,
probably
the
closest
thing
that
will
have
to
somebody
that
needs
to
manage
multiple
teams,
because
you
have
a
gitlab
project.
You
have
the
pages
project.
You
have
the
release,
CLI
tool
that
we
have
in
a
different
project.
What
would
be
the
most
meaningful
things
from
your
from
your
perspective?
You're.
C
That
could
be
cool,
yeah,
I'm
kind
of
I'm
thinking
trying
to
think
quickly
objective
like
what
else
would
be
really
helpful
to
come
in
here
and
just
get
a
snapshot
of
it
might
be
nice
to
see
like,
for
you
know,
for
each
I'm,
still
thinking
of
through
put
like
each
individual
project
that
I'm
interested
in
or
that
I
have
an
interested
in,
maybe
seeing
the
open.
You
know
a
little
more
throughput
details
for
each
of
those,
so
like
maybe
throughput
broken
down
by
project,
is
what
I'm
trying
to
get
it.
Something
like
that.
C
Yeah
it'd
be
nice
to
get
a
sorry
some
insight
into
like
this
is
probably
way
too
detailed,
but
it'd
be
cool.
To
get
some
insight
until
you
know
we're
kind
of
like
each
person
is
also
at
this
point
in
time.
You
know
like
I'm,
looking
at
Nathan,
let's
say:
Nathan
has
three
issues
in
dev:
it'd
be
cool
to
see
whoa,
that's
a
lot
in
dev
at
one
time.
Maybe
this
is
the
right
place
for
that,
but
that
could
be
a
cool
thing
too
sorry,
Nathan,
I'm,
picking
on
just
I,
saw
your
face
yeah.
C
A
D
C
Don't
know
if
it
would
be
helpful
to
you're
saying,
along
with
cross-linking
Jackie,
but
maybe
even
just
like
things
we
already
have
exist
exist
to
your
point
like
maybe
just
moving,
making
those
easier
to
smell
together,
separable
'ti,
yeah
yeah,
a
subset
of
the
you
know
current
functionality
in
this
dashboard,
something
like
that.
Okay,
that's.
A
Helpful
so
getting
kind
of
more
technical
about
this
view
here.
Are
there
some
issues
that
I
should
create
from
like
investigation
on
how
real-time
these
metrics
will
be,
or
are
there
things
like
I've
built
dashboards
before
that
weren't,
very
performant,
and,
as
a
result,
I
would
have
stale
dashboards
for
like
36
hours
before
they
refreshed?
Are
there
things
that
we
should
be
considering,
with
this
amount
of
data
being
pulled
into
the
single
dashboard
lever?
Your
thoughts
on
that.
C
A
C
D
A
E
Yeah,
it
actually
began
more
as
a
as
thinking
through
a
way
to
make
versions
or
releases
versions
more
than
they
are
today,
because
right
now
you
can
name
tags
whatever
you
want.
There's
no
like
conversion
requirement
and
there's
you
can
unlock
a
lot
of
things
by
enforcing
a
semantic
version
that
you
associate
with
the
release
and
then
that
got
me
thinking.
E
They
already
do
that
in
packaged,
for
example,
for
NPM
packages,
and
it
might
make
a
lot
of
sense
to
either
combine
or
at
least
show
content
the
from
packages
on
the
release
page
or
vice
versa,
because
really,
if
you're
publishing
a
package,
that's
kind
of
by
definition
to
release-
and
it
would
be,
it
makes
sense
to
show
that
on
the
releases
page
and
there's
like
a
lot
of
different
ways,
you
can
go
with
that.
You
could.
E
You
could
merge
the
pages
you
can
have
them
separate
and
then
list
packages
in
addition
to
the
releases
page
or
maybe
you
could
associate
releases
with
packages,
yeah,
there's
tons
of
tons
of
different
ways.
You
could
go
with
that,
but
that's
kind
of
just
a
really
high-level
thought,
but
there's
a
lot
of
crossover
that
were
not
really
really
exploiting
to
that
opportunity.
I
know
I.
A
Love
that
because
I
think
you're
completely
right
that
we
could
increase
the
adoption
of
both
the
releases
page
and
the
packages
page
if
there
was
at
least
even
minimally
cross
linking
between
packages
that
have
been
published.
But
I
do
feel
like
there
is
value
in
reducing
the
places
that
people
go
to
consume
the
same
thing,
so
it
might
be,
it
might
be
worth
combining
those
agreeing.
E
One
of
the
things
that
the
package
t
mentioned
was
just
that
the
audience
that's
looking
at
the
package,
page
or
Sevilla's
tape
page
might
be
different,
like
there
might
be
things
that
you're
going
to
the
package
page
for
that
wouldn't
make
as
much
sense
on
that
releases
page.
So
it
might
be.
It
might
still
make
sense
to
keep
them
separate
because
you're
thinking,
you're
kind
of
doing
different
work,
you're
looking
at
those
pages
but
other
than
that
I,
don't
think.
E
B
A
A
F
Sure,
let's
do
that,
maybe
we
can
yeah.
We
can
bring,
definitely
bring
this
to
the
cross-functional.
Take
a
big
session,
but
I
started
seeing
and
see
where
the
low-hanging
fruits
here
and
also
Demetri
the
mutilation
just
joined
the
verified
early
steam
UX,
and
he
has
some
experience.
I
think
would
be
nice
to
also
involve
him
because
he,
you
know
if
Rebecca
ch
before.
A
A
There
might
be
like
an
NBC
that
we
can
solve
for
sooner
before
adding
first-class
versioning
to
releases,
but
I
also
think
there
there's
a
problem
here
when
people
go
and
create
a
release
from
a
tag,
and
they
don't
know
what
to
name
it
because
they
don't
know
what
they've
named
previous
things
and
there's
are
tools
out
there
that
I
know
people
are
using
so
they've
created
scripts
to
populate
runners,
one
of
them
there's
a
there's,
a
couple
of
other
customers
that
have
done
that.
So
maybe
this
is
something
that
we
can
just
implement
easily.
E
Another
idea
I
was
just
thinking
is
that
for
certain
types
of
projects
like
NPM
package
or
basically
massive
packages,
if
your
project
is
a
package
we
could
for
common
types,
we
could
parse,
for
example,
the
package
JSON
and
pull
out
the
version,
the
current
version
and
suggest
that
as
a
tightening
and
that
could
cover
a
lot
of
a
big
portion
of
people's
these
cases,
yeah
a
way
to
give
that
to
a
lot
of
users.
It
wouldn't
be
foolproof
because
who
knows
you
might
be
using
some
packs?
C
A
A
And
then
Vlad
also
submitted
this
idea
of
adding
a
version
to
release
evidence.
So,
unfortunately,
Shaun
isn't
here.
Cuz
on
vacation
he'd
be
like
the
best
person
to
kind
of
iterate
on
this
with.
But
the
idea
of
this
is
there
could
be
multiple
release.
Evidence
versions,
in
addition
to
our
version
of
release,
especially
for
premium
customers
who
are
leveraging
our
on-demand
release,
evidence
collection,
something
to
think
about.
A
So,
for
example,
the
actual
release
landing
page
might
end
up
being
metrics
about
the
project's
releases,
with
a
list
of
all
the
tags
that
are
created
and
then,
when
you
click
into
that
tag,
that's
where
you
get
the
release.
Notes
like
this
and
the
source
code
and
release
evidence.
But
if
we
have,
if
we
do
choose
to
create
more
advanced
version
anchor,
these
evidences
and
releases
will
need
to
kind
of
figure
out
a
way
to
make
that
look
clean
inside
the
UI.
F
A
F
F
C
A
Okay,
so
from
an
update
to
you
all
this
call,
hi,
Ann
and
I
are
gonna
start
investigating
the
fork
of
release
project
views
group
views
because
we're
eventually
gonna
support
releases
to
be
associated
by
group
milestone,
so
we'll
need
to
be
able
to
support
releases
at
the
group
level
and
then
the
view
page.
So
I
don't
want
us
to
have
to
add
a
bunch
of
stuff
to
both
pages,
the
the
project
view
page
and
the
actual
release
view
page.
So
this
will
be
a
really
important
epoch
for
all
that
stuff.
E
E
A
Said
it'll
just
aggregate
the
information,
so
you
won't
be
able
to
create
or
release
at
the
group
level.
You'll
still
create
it
at
the
project
level,
but
you'll
be
able
to
associate
it
to
a
group
milestone,
which
I
think
is
the
only
thing
that's
actually
renderable
anyways
at
the
group
level
that
there
aren't
really
issues
at
a
group.
There
aren't
really.
The
only
thing
that
sounds
like
that.
E
A
I
do
feel
I
think
this
conversation
always
comes
up.
The
whole
tag
and
releases
relationship
Kenny
and
his
walk
through.
He
was
like
I
just
want
to
create
a
release,
and
he
kept
saying
that
over
and
over
again
and
I
was
like.
Oh
okay,
I
wonder
how
many
other
users
are
asking
for
that.
Just
I
want
to
create
a
release.
I
want
to
associate
a
bunch
of
things
to
the
release
and
then
I
want
to
commit
my
tag
to
it
as
an
afterthought.
A
A
E
A
Hannah,
do
you
want
to
talk
a
little
bit
about
any
of
the
the
findings
that
you're
collecting
on
the
maturity?
Scorecards
work
that
you're
doing
I
know
you've
been
very
focused
on
that
so
I'm
wondering
if
you
kind
of
want
to
like
walk
us
through
what
you've
been
seeing
any
trends
or
anything
like
that.
It
may
be
a
repeat
of
what
we
already
hashed
out
with
this
group,
but
that
might
just
be
interesting
to
share
from
your
perspective.
I'll
stop
sharing
my
view.
A
F
Don't
think
the
organization
of
the
to
make
a
lot
of
sense,
but
let
me
try
walk
you
through
what
we're
doing
and
why
why
we
are
doing
the
immaturity,
scorecard
I
think
that's
also
super
valuable.
Let
me
share
my
screen
folksy.
Yes,
all
the
steps,
my
god.
Well,
don't:
okay,
foreigners
who
don't
know
we've
been
test.
We
are
seeing
release
management
and
order
other
teams,
other
groups
or
task
with
validating
the
maturity
over
product.
So
if
I
go
here-
and
it's
here
yeah
this.
F
Opr,
where
we
need
to
pretty
much
validate,
they
could
get
the
maturity
of
a
product
based
on
user
insights,
and
these
are
findings,
so
not
only
on
the
offering
that
we
have
in
numbers
of
capabilities,
but
also
how
users
are
reacting
to
it.
Doing
user
interviews,
collecting
data,
and
then
we
follow
a
process.
I'm
gonna
go
over
the
whole
thing
where
we
give
a
score
to
our
maturity
so
for
Billy's
orchestration,
because
we
changed
was
from
minimal
to
viable
right
Jackie
from
like
last
year,
yeah.
F
So
our
test
to
do
this,
this
process,
where
we
talk
to
you
five
users
and
we
have
to
follow
a
bunch
of
steps
in
order
to
collect
this
data,
but
what
happens
that
we
already
doing
this
for
a
job
to
be
done
for
releases
so
which
is
create
a
released
and
updated
the
search
field.
Folks,
remember
if
you're
familiar
with
this
topic,
I
could
be
more,
doesn't
be
talking
about
it
for
cooking
for
five
months
now
and
we're
doing
all
these
user
interviews
together.
F
Designers
are
still
doing
it,
but
we
have
this
issues
this
one
right,
Jackie,
where
Jackie
evaluates
I'm
gonna,
add
this
here
to
the
chat.
You
don't
find
a
judge
here
where
Jack
Jackie
validates
based
on
the
trends,
and
you
can
see
here
that
yeah
releases
people
are
using
it
and
we're
getting
so
many
feedback
from
users
we're
using
internally.
F
But
what
I'm
doing
now
is
that
yeah.
We
know
that
people
are
using
releases.
We
know
that
they
love
releases.
They
know
that
there
are
improvements
that
we
have
to
make
and
we
have
enough
user
insights
but
in
any
case,
I'm
going
over
this
process
in
collecting
all
this
information
that
we
have
in
so
many
different
places.
As
we
conducted
interviews,
I,
don't
know,
Jackie,
40-plus
and
I
did
six
user
interviews.
F
D
F
Has
a
lot
of
yellow
marks?
That's
Laurie
was
great
and
left
her.
A
bunch
of
things.
I
can
work
on,
and
what
I
want
to
do
is
to
highlight
all
these
steps
that
we
completed
since
last
year.
I
think
since
October
November
last
year
until
today,
so
I
already
found
here
that
yeah
in
a
way
we
validate
this
in
three
different
phases
as
in
UX
scorecard.
So
we're
here
is
take
evaluation.
I
did
last
year,
then
we
reevaluate
the
job
to
be
done.
F
That
is
as
a
release
manager
when
track
important
deliverables
in
my
project,
I
want
to
easily
create
and
manage
releases
entries
so
that
I
can
provide
package,
software
notes
and
files
for
people
to
use.
This
is
our
main
job
to
them
or
tasks
for
all
the
personas
that
recovering.
So
we
validated
this
in
January
I
believe
and
this
course
status
is
as
a
mess,
because
back
in
January,
we
didn't
have
that
ability
to
create
a
release
through
the
UI.
F
So
users
can
do
this
through
the
the
CLI
and
they're
super
happy
with
the
API
capabilities,
but
then
yeah
before
we
had
that
what
button
there
there
was
a
lot
of
friction
and,
in
the
meantime,
we
did
some
validation
also
on
the
solutions
that
we
proposed.
So
this
is
the
prototype
phase,
where
we
also
talked
to
people
so
talk
to
Michael
right
yeah
for
these
interviews
to
already
collect
some
data
for
the
improvements
that
we
want
to
make
in
the
future.
So
what
I
am
at
right
now,
not
super
complete.
F
So,
for
example,
we
have
a
couple
of
questions
regarding
to
how
users
are:
how
did
they
complete
a
scenario
or
in
the
user
interviews
and
if
they
are
what's
the
name
that
they
use
for
this
yeah?
And
if
users
are,
you
know
how
difficult
or
easy
it
is
to
complete
a
task
so,
for
example,
creative
release
or
editing
villains.
We
have
this
data,
but
we
haven't
really
asked
those
questions
directly.
F
So
at
this
point,
I'm
looking
back
at
the
data
we
collected
to
identify
that
okay,
when
a
user
tries
to
create
a
release
with
it
lab
to
the
UI,
they
find
it
very
easy
or
very
difficult
and
wide.
So
with
this,
we're
gonna
have
this
documented
and
we're
gonna
be
able
to
look
at
yeah.
This
trends
here
we're
also
saying
cool.
This
were
all
the
data
that
we
have
plus
the.
F
A
Was
just
I'm
very
impressed
with
all
of
your
work
that
you've
done
on
this
high
on?
Thank
you
for
your
commitment
to
it
and
to
betting
out
the
UX
process.
Even
though
Kristi
has
like
accepted
our
move,
it
has
declared
the
Oh
care,
is
complete.
I
am
very
happy
that
you
are
validating
the
data
with
it
because
then
the
next
time
we
have
to
do
this
when
we
move
release
orchestration
to
complete
or
secrets
management
to
viable
it'll,
be
really
cool
to
to
be
able
to
apply
this
so
I'm
excited
exactly.
F
And
I
think
the
the
first
comment
Deloria
made
here
in
this
document
is
the.
If
we,
you
know
coming
back
six
months
and
he
wants
to
look
at
this
document,
it
would
be
nice
to
know
we
can
map
out
what
exactly
improve
them.
Based
on
specific
user
insights,
that
we
can
look
at
this
document
as
a
source
of
truth
for
the.
F
A
The
yeah
and
then
the
last
thing
before
I,
let
y'all
y'all,
go
and
give
you
some
time
back.
I
have
started
undergoing
an
environments,
job
to
be
done
research,
so
we
got
the
survey
back
and
we
found
out
that
people
are
using
environments
in
all
sorts
of
ways
and
I've
interviewed
about
six
users,
still
not
any
clearer
on
what
we
should
be
doing
with
environments.
It
is
a
really
big.
A
A
So
tomorrow,
at
11,
Central,
Time,
Lori
I
have
a
meeting
with
you
me
and
and
Hyuna,
and
hopefully
we
get
to
okay
nail
down
a
scenario
that
I
could
start
evaluating
with
users,
because
today,
I'm
kind
of
like
my
job
to
be
done
is
I.
Have
a
merge
request
or
a
release
that
has
been
approved
and
I
wanted
to
plate
a
production.
A
B
And
I
think
I
talked
with
the
UX
leadership
team
about
this
on
Monday
the
jobs
to
be
done.
So
the
whole
approach
that
we
have
to
the
problem,
validation
piece
of
our
UCD
process,
is
very
in
myopic.
I
know
what
the
problem
is:
I
just
want
to
validate
it
more
or
maybe
I
want
to
uncover
when
one
or
two
little
things
about
this
problem,
what
we
need
to
do
is
we
need
to
back
it
up.
B
So
we
have
a
wider
lens
and
I
think
you've
just
uncovered
something
around
that,
like
you,
went
in
with
a
very
sharp
view
of
I,
just
wouldn't
understand
stuff
around
this
thing.
But
what
did
you
find
out
is
like
oh
there's
so
much
more
around
it.
So
I
want
to
encourage
you
not
to
freak
out
because
you
haven't
become
able
to
coalesce
around
the
one
thing.
B
What
you're
actually
doing
is
jobs
to
be
done
interviews
and
it's
a
wider
lens
that
we
use
to
do
that
with
and
because
we
do
that
you
are
going
to
uncover
fringe
things
and
things
you've,
never
even
thought
of
before
that
people
are
doing
with.
With
this
thing
called
environments,
right
so
don't
feel
bad,
but
let's
talk
about
who
you
talked
to
what
are
some
similarities
across
those
users
or
the
companies
or
the
setups,
or
something
because
I
suspect
that
maybe
they're
just
different
enough
between
the
different
people.
B
You
talk
to
that
you,
you
haven't
had
a
chance
to
get
enough
of
the
same
messaging
yet
because
they're
coming
in
from
different
places,
like
you
said,
like
the
one
person
face,
building
up
and
destroying
things
they're
viewing
them
as
a
test
environment
right,
which
is
not
what
weird
thought
they
were
going
to
do.
So,
let's
chat
about
it
tomorrow,
but
I
just
wanted
to.
Let
you
know
that
you're
not
doing
it
wrong.
B
A
And
I
think
for
for
reference,
I've,
just
chatted
out
this
epic
and
I'll
go
ahead
and
share
my
screen
and
kind
of
walk
through
it.
But
it
looks
like
most
most
of
the
people
who
are
interested
in
environments
in
general.
Our
development
team
leads
or
leaders
in
their
organization,
so
I've
included
the
six
participants.
I've
picked
a
couple
of
different
industries,
so
I
can
see
if
this
was
a
consistent
industry
problem
and
you're.
Absolutely
right,
like
I,
was
able
to
distill
about
13
shared
insights
and
they
are
grouped
by
persona
like
naturally,
that's.
A
What
came
out
of
the
user
interviews
is
that
the
development
team
leads
shared
race.
Similar
pains,
the
software
engineer
and
platform
engineers
shared
very
similar
pains
people
that
were
in
aerospace,
energy
and
high
tech
share
different
pains
that
people
who
were
in
consulting
services
and
digital
signage
services,
so
I'll
be
excited
to
like
do.
You
can
pose
this
with
you
Laurie,
because
yeah
yeah
I'm
not
really
panicking
or
anything
but
I
hate,
I,
hate,
feeling,
stupid
yeah.
B
B
No,
please
don't
feel
stupid.
What
you're
doing
is
exactly
the
right
thing.
It's
just
let's,
let's
work
together
to
make
some
more
sense
of
it
that
you
can
actually
use
for
your
next
step
of
this
process,
but
you've
done
the
right
thing,
because
what
you
probably
have
done
once
we
get
into
there
is
you've
uncovered
other
jobs
to
be
done,
that
we
didn't
even
think
about,
and
that's,
okay,
that's
what
that
stage
is
for
now.
A
And
it
totally
makes
sense
why
we
have
weak
adoption
of
the
environments
dashboard,
because
if
a
majority
of
our
customers
are
just
spinning
up
environment
to
test
with
and
not
deploy
to,
production
monitoring,
those
environments
becomes
meaningless.
Exactly
I
love.
It
love
this.
It's
very
experience
very
cool,
any
other
questions.
Otherwise,
I'll.
Let
you
let
you
all
have
seven
minutes
back
to
your
direction.
Minutes
back
your
day,.
A
And
if
you
have
any
other
thoughts
about
what
would
make
this
think
big
better,
let
me
know
I
can
try
to
focus
on
one
topic
and
slack
everybody,
and
let
us
know
like
this
is
the
one
topic
that
I
want
us
to
deep
dive
on
or
if
you
feel
like,
we
should
be
focusing
more
on
current
work
in
flight.
Just
let
me
know
I
want
these
to
be
helpful
and
useful
for
you
all.