►
From YouTube: 2020-04-09 Ops Cross Stage ThinkBIG!
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
Hello,
everyone
welcome
to
our
second
installment
of
the
cross
stage.
Think
big
for
some
of
us.
This
is
our
second
trial
and
for
some
of
us
is
the
first
time
we've
been
here.
So
thank
you.
Everyone
for
coming
to
join
us
for
those
of
you
who
haven't
gone
through.
One
of
these
I
wanted
to
give
a
high-level
overview
of
what
we're
doing
today
here
at
this
think
big
a
little
bit
of
the
history
and
then
I'll.
Let
the
designers
jump
into
their
topics
for
conversation
now.
A
Do
you
have
a
really
good
idea
to
start
with
the?
Why?
How
and
what
circles
and
so
I
figured
that's
the
perfect
way
to
walk
through
this?
The?
Why
that
we're
all
here
and
we're
all
discussing
this
we've
heard
from
our
users
that
the
experience
between
stages
is
often
disjointed.
I
know
I've
heard
that
from
user
interviews
we
heard
it
in
the
sauce
testing,
where
they
kind
of
do
an
overview
of
the
entire
thing,
and
so
we
know
there's
opportunity
here
for
us
to
create
really
powerful
experiences.
A
How
are
we
going
to
try
to
solve
for
this?
The
idea
was
to
bring
together
product
managers
and
designers
from
cross
stages
to
overly
discuss
opportunities
that
could
bring
the
cross
stage
experience
for
our
users
to
be
better
and
what
what
is
it?
We're
actually
going
to
do.
That's
where
the
monthly
cross
stage
in
big
session
came
from.
We
did
it
one
session
before
this,
with
what
used
to
be
the
CI
CD
team.
We
had
a
really
good
time.
A
I
think
we
went
through
a
session
where
we
got
to
have
three
different
topics
of
ways
that
we
could
collaborate
across
our
stage
from
there
we
had
some
learnings.
We
also
had
some
great
results,
so
we
did
a
retrospective
when
we
learned
so
we'll
jump
into
some
of
the
things
that
we've
changed.
Like
I
mentioned,
we
originally
planned
for
four
different
areas
and
topics
to
talk
about
during
think
big.
We
managed
to
get
to
three
three
three
and
everyone
kind
of
struggled
that
was
really
really
quick.
A
A
One
thing
that
is
kind
of
important
that
I
want
to
call
out
is
to
make
sure
that
we're
accountable.
We
want
to
create
issues
or
label
choose
with
the
think
big
label
so
that
we
know
the
conversations
that
we're
having
here
today
are
turning
into
gitlab
friendly
async
issues
and
features
that
are
getting
into
the
backlog
and
whatnot.
The
exciting
news
is
that
we
have
six
of
those
issues
created
from
our
last
thing,
big.
So
in
theory,
that's
six
new
ideas
or
ideas.
C
D
A
A
really
great
question,
a
great
call
out.
The
schedule
we
put
above
is
just
the
cycle
of
what
team
is
going
to
be
presenting
for
the
that
think,
big.
So
for
the
9th
of
April,
we
have
release
and
verify
that
was
just
kind
of
an
assignment
of
when
people
should
talk
so
that
we
could
get
started,
that's
pretty
flexible
if
we
want
to
change
it.
The
idea
is
that
we
should
all
be
coming
as
best
we
can
to
these
sessions
so
that
we
can
cross
stage
collaborate
in
areas
of
opportunity.
F
This
may
be
a
subject
to
change
in
the
futures,
as
it
mentioned
in
the
comments
we're
going
to
learn
from
these
sessions
that
we
are
having.
Maybe
we
are
too
big
of
a
crowd.
Maybe
you're
gonna
find
a
better
way
to
communicate.
So
this
is
a
pilot.
We
are
experimenting
so
and
we
are
waiting
for
the
feedback
in
the
restaurant
sessions.
After
that.
C
All
right,
cool,
I'm
gonna
go
ahead
and
get
started
so
far
release
management.
We
want
to
discuss
a
little
bit,
how
it
can
make
environments
easier
to
use
in
manage
and
also
to
understand
what
challenges.
Audit
teams
or
not.
Our
designers
and
product
managers
have
encountered,
while
working
with
environments
for
now
represent
during
delivery
and
dashboard.
C
B
So
the
environments
job
to
be
done.
It's
something
that
I
learned
about
after
interviewing
interviewing
our
customers
and
users
about
how
they
navigate
through
get
lab
and
how
they
utilize
different
objects.
I
found
out
that
environments
is
a
really
wide
array
of
different
functionalities
that
people
are
using
it,
for.
We
also
learned
that
people
are
more
inclined
to
use
environments
if
we
could
offer
better
secrets.
Variable
management
if
we're
able
to
offer
things
like
advanced
deployments,
which
includes
roll
back
support
and
if
we
were
able
to
share
across
groups
and
projects
better.
B
So
when
I,
say
environments
being
shared
across
groups,
are
better
they're
expecting
to
be
able
to
administer
environments
at
a
group
level
so
that
the
that
is
a
resource
that
can
be
consumed
by
different
projects
rather
than
having
a
duplicate
environment
that
is
represented
as
the
same
environment
and
two
separate
projects
and
get
lab
with
variable.
That's
like
copy
pasted
over
right.
B
Some
of
the
respondents
from
the
survey
we
had
about
65
responses.
10%
of
those
responses
didn't
really
know
what
an
environment
was
which
is
okay.
If
we
were
to
extrapolate
that
out
to
all
of
our
customers,
that
is
a
pretty
large
base
right,
I
mean
it's
a
lot
of
our
customers,
really
don't
know
what
environments
are
or
they
understand
that
they
are
a
representation
of
a
deployment
but
may
not
really
understand
the
utility
or
value
of
using
them
as
a
get
left
customer.
B
So
this
means
we
can
do
something
to
make
environments
more
discoverable
and
perhaps
a
little
bit
easier
to
act
on
when
there's
something
wrong
with
an
environment
like
if
there's
a
failed
job
associated
with
it
or
if
there's
a
violation
of
a
regulation
from
the
compliance
side
of
the
house,
something
to
really
think
of
and
expand,
expand
on
and
then.
Lastly,
a
lot
of
the
people
felt
that
environments
were
secure
and
they
were
flexible
and
they
could
support
multi
cloud
deployment.
B
So
the
80%
of
people
really
90
percent
of
people
who
actually
knew
what
environments
were
for
felt
like
they
could
use
them
with
confidence,
which
is
really
great,
because
one
of
the
assumptions
that
I
was
going
into
the
survey
was
that
people
weren't
using
environment
they
weren't
pulling
with
git
lab
because
they
didn't
feel
like
our
solution,
was
secure
way,
as
that
is
one
of
you,
Google
get
lab
environments
or
how
to
set
up
deployments.
That
is
one
of
the
things
that
comes
back
on
the
community
or
Stack
Overflow
as
being
a
problem.
B
So
the
Hana
articulated
a
really
great
job
to
be
done
here,
and
that
is
that
is
absolutely
the
core
job
to
be
done,
that
we
are
untying
with
our
customers
and
it
started
with
the.
How
do
we
generate
visibility
across
all
projects
in
a
group
with
the
CICE
dashboard
and
now
we're
refining
that
for
in
our
validation
cycle,
the
product
side
and
design
side
for
environment,
specifically
when
I
look
across
all
of
our
different
activities?
B
Just
when
opportunity
canvasses
get
presented
to
Scott
and
then
post
it
in
the
product,
channel
I
realize
there's
a
lot
of
opportunity
for
me
to
hook
in
with
see
ICD,
dashboard
and
other
consume
metrics
that
are
coming
out
of
other
stages
or
redisplay
information
in
a
meaningful
way.
I'm
hoping
that
this
think
bag
can
be
an
opportunity
for
all
of
us
to
connect
and
think
about
what
is
a
way
to
to
really
make
that
something
powerful
for
all
of
our
customers.
C
C
G
G
B
That's
really
rough
to
hear
I
just
spent
a
lot
longer
talking
than
I
really
wanted
to.
So
here's
that
here's,
a
quick
recap
we're
doing
things
on
environments
and
we're
learning
that
people
don't
like
the
way
that
we
manage
environments,
the
project
level.
They
want
to
say
it
at
the
group
level,
something
that
progressive
delivery
has
on
their
docket
413.
Is
this
idea
of
typed
AWS
variables
at
the
group
level,
which
is
really
tied
to
something
that
we're
trying
to
do
over
in
release.
G
How
do
external
deployments
and
deployments
right?
That's
the
big
question
of
like
alright,
it's
out
there
it's
on
AWS
and
you
tie
it
back
to
get
lab,
and
it's
struggling
to
say.
Basically,
it's
that
it's
an
interesting
thing
that
what
exists
on
get
lab
in
that
list
of
environments.
Is
it
really
the
environment
right?
There's
always
been
that
confusion
that,
like
oh
I,
can
go
to
get
lab
and
manage
my
environments,
but
really
those
environments
live
out
in
AWS
right
there.
G
You
know
like
with
kubernetes
and
the
Google
DPA
stuff,
where
we
already
have
kind
of
a
tighter
integration.
It's
still
a
problem,
it's
less
of
a
problem
and
as
we
move
to
other
cloud
providers,
the
problem
is
going
to
get
worse.
Oh
you
know
what
exists
in
get
lab
is
just
pointers
to
environments
that
that
often
times
do
live
in
other
clouds.
So.
B
G
G
Think
that
the
end
state
for
them
needs
to
be
involved.
You
know,
honesty's,
we
were
doing
the
secrets,
kind
of
management
thing,
the
security
team
kind
of
came
back
with
you
know
this
isn't
AWS
a
preferred
way
of
storing
those,
but
what
we
do
know
right
now
is
people
are
using
them.
So
really
all
we've
done
in
that
issue
that
we
were
talking
about
was
was
give
a
convenience
people.
We
know
people
are
currently
inputting
them
by
hand
and
anytime,
you
type
a
long
string
by
hand.
Your
error
rate
goes
up.
It's
really.
G
All
we've
done
is
kind
of
an
autocomplete
for
them
to
give
a
user
experience
convenience,
but
really,
at
the
end
of
the
day,
we're
storing
them
no
differently
than
any
other
kind
of
variable.
Very
texty
texty,
but
you
don't
say,
there's
nothing
special
about
them
other
than
we
know
the
pattern
and
we're
autocomplete
completing
for
them.
Just
really
meant
that
she
was
about.
B
G
B
Interesting,
so
we
and
I
have
been
connected
about
this
issue
a
little
bit,
because
something
that
I'm
learning
or
secrets
management,
which
is
a
completely
different
topic,
is
that
users
may
not
want
to
use
vault
to
store
their
secrets.
So
if
that's
the
case,
we
need
to
kind
of
figure
out.
How
do
we
want
to
expose
endpoints
and
one
opportunity
for
us
to
kind
of
read
what
we
already
have?
B
G
Just
think
of
a
positive
thing,
so
I
threw
out
some
more
problems,
but
now
here's
another
possible
opportunity
right.
So
going
back
to
the
variable
thing
we
do
have
this,
like
you
go
to
the
settings
UI
you
put
in
your
variables
here
and
ultimately
they
do
relate
back
to
these
environments.
Right
like
this,
these
are
your
keys
to
the
castle.
To
get
to
this
environment.
It
would
be
interesting
to
build
a
loop
back
into
either,
maybe
like
just
through
a
link
or
maybe
actually
exposing
like
the
ability
to
configure
those
variables
from
the
environments.
G
Ui
right,
like
wait,
I
don't
have
the
credentials
right
for
this
or
I
need
to
update
the
credentials
and
I
know
it
relates
to
this
environment
rather
than
the
current
flow.
Where
it
is
now
dig
through
settings.
Hope
you
find
that
it
would
be
an
interesting
little
link
back
to
that
say.
Well,
we
know
you
were
using
these
variables
for
this
environment.
Here's
here's
a
LinkedIn
settings,
or
maybe
even
like
here-
is
those
variables
right
here
in
this
UI
and
fortunate
to
not
have
to
go
back
into
the
settings.
I
might
be
an
interesting
okay.
B
I
would
say
that
variables
when
we,
when
we
look
at
the
bifurcation
between
how
people
are
expecting
secrets
and
CI
variables
to
be
handled
differently.
There
isn't
a
really
great
distinction
in
our
UI
today,
they're
all
handled
in
the
same
place,
so
I'm
tackling
and
another
kind
of
topic
is
how
to
create
that
separation.
Inside
of
our
UI,
because
secrets
are
treated
inherently
different,
Lin
just
CI
variables
that
can
be
handled
with
any
job.
B
So,
going
back
to
up
top
I
know
that
we
kind
of
got
a
little
off
track
here,
since
we
wanted
to
bring
up
a
more
unified
approach.
The
CI
CD
dashboard
that
we're
building
Ayana
has
linked
that
issue
there
and
how
I
see
that
you
have
a
bunch
of
issues
that
are
considered
environment,
related
scope,
I'm
interested
in
learning
about,
if
you
have
anything
like
a
conservative
vision
or
if
you're
coming
I'm
going
to
undergo
some
validation
around
environments.
B
F
I
Mike
mention
about
the
settings
being
like
this.
Basically,
this
is
no
ball
that
keeps
growing
and
growing
as
we
keep
adding
things
and,
of
course,
for
the
sake
of
for
like
environment
variables
and
secrets,
there's
already
kind
of
like
that.
I
don't
know,
there's
like
that.
Friction
to
find
things,
but
I
ID
doesn't
help
either
there
right.
Now
we
have
settings
at
the
different
levels.
I
What
get
love
yeast,
there's
even
settings
for
you
as
a
user
when
you
go
in
you're
clicking
your
profile,
you
know
and
where
you
have
your
access
tokens
and
your
SSA
ease
and
your
preferences
active
sessions
all
that
stuff
right,
so
yeah
I
just
bringing
that
up,
because
there's
definitely
a
lot
of
area
area
of
like
a
lot
of
surface
for
friction
here.
When,
like
we
keep
adding
things,
we
I
think
we
don't
have
a
great
mental
model
for
how
our
settings
are
displayed
in
get
lab.
I
A
Thank
you.
We
add
in
a
future
topics
down
at
the
bottom
of
the
notes,
so
we
definitely
bring
that
up.
I
did
kind
of
have
a
question
I'm
noticing
a
theme
across
some
of
the
stages
and
I'm
just
curious.
If
everyone
is
having
this
experience
a
lot
of
our
users
when
they're
talking
about
the
group
level
of
everything
so
at
the
container
registry,
they
want
to
know
like
the
most
recent
tags
at
the
group
level.
A
B
I
have
seen
it
being
an
aggregation.
Our
customers
are
expecting
very
similar
behaviors
at
the
project
level
at
the
group
level,
and
really
they
want
to
be
able
to
do
everything
that
they
can't
the
project
level
at
the
group
level.
So
some
of
the
experiences
that
are
jarring
and
we
were
watching
a
customer
go
through
releases
and
they
go
to
their
group
and
they're
like
I
wish.
I
could
find
my
releases
here
and
I'm
like
oh
well.
I'm,
sorry
I
want
to
go
down
I.
I
What
what
I
see
is
that
they
are
demanding
like
give
me
like
an
add-in.
You
know,
and
that
means
where
I
can
go
and
I
can
just
basically
create
all
these
things
involved,
manage
all
the
settings
for
all
my
projects,
so
I
feel
that
it's
my
impression
that
we're
using
groups
as
like
the
catch-all
for
anatomy-
you
know
she's,
there's
a
lack
of
a
nap
mean
in
calm,
I,
think
we're
using
group
groups
for
that
which
is
okay,
I,
don't.
B
Experience
I
don't
think
it
is
an
admin,
because
my
persona
that
typically
asks
for
those
groups
are
people
who
are
coordinating
across
multiple
projects
which
are
typically
the
developer
team
lead
and
the
release
manager.
Not
really
an
admin
like
they
don't
really
care
about
naming
or
changing
badges
across
groups
or
old.
E
B
I
I
It
okay,
so
that's
pretty
interesting,
because
the
cases
that
I'm
seeing
runner
is
like
I
wanna
also
see
everything,
but
I
also
want
to
be
able
to
manage
things.
You
know
so
yeah
turning
of
runners
seen
all
the
jobs
for
all
the
projects
and
maybe
rerunning
jobs
from
the
group
level.
While
having
the
ability
to
see
what
project
doesn't
belong,
you
know
so
I,
don't
know
it's
interesting.
It
tells
it
for
your
friend
personas
means
different
things.
I,
definitely
I'm,
seeing
that
in
runner.
Its
lot
like
group
is
the
admin
level
page.
A
Where
we
have
some
of
our
users,
they
want
the
group
level
just
to
be
the
combination
of
everything
that
all
the
packages
and
all
the
containers
that
are
produced
in
all
the
different
packets
are
all
the
different
projects
they
work
with
and
then
I
have
a
like
completely
separate
admin
that
just
wants
like
statistics
and
highlights,
which
is
a
very
different
experience,
and
they
want
that
at
that
group.
Maybe
they
are
both
saying
they
wanted
good
level
view
just
to
share
that
context.
It's
interesting
that
we
have
that
duality.
I.
B
Also
think
it
makes
it
more
problematic
whenever
we
start
adding
more
dashboards
and
more
analytics.
So
in
testing
right
now,
I
know,
James
is
working
on
a
testing
dashboard
for
code
coverage.
It
kind
of
leads
me
to
think
about
us.
We
need
to
have
concerted,
analytics
journeys.
So
at
what
point
are
we
expecting
someone
to
fall
in
this
analytics
page
and
how
do
we?
How
do
we
want
to
drive
them
to
a
certain
action
because
analytics
shouldn't
be
a
here's,
a
pretty
display
for
you?
B
B
I
Are,
oh,
it
does
it
for
me,
doesn't
show
up
at
it
today
right,
okay,
so
I'll
share
the
video
with
we
him
and
then
like
the
notes,
but
anyways.
So
the
topic
that
I
wanted
to
bring
up,
which
I
feel
that
it's
very
relevant
to
across
stage
of
cross
stage
interest
is
discoverability.
I
I'm
gonna
talk
specifically
about
testing
discoverability,
but
I
think
this
is
gonna,
resonate
with
people
with
other
people
in
this
fall.
So
what
we're
seeing
is
that
we
right
now
testing
has
a
lot
of
solutions
right.
It
has
built-in
CI
suites
that
are
that
you
can
set
up
when
your
did
lab
CI
ml
file,
and
they
can
do
they
can
show
you
code
coverage.
They
can
show
you
code
quality.
They
can
show
you.
I
Accessibility
now
we
have
accessibility,
there's
so
many
things
that
we're
doing
right
now
in
testing
so
well.
What
we're
seeing
is
that
testing?
It's
not
super
discoverable
I
mean
like
people
set
it
up
and
everything,
and
then
they
get
the
EMR
widgets
and
EMR,
which
it
seems
to
be
like
the
final
place
where,
like
the
experience,
finishes
for
them,
but
there's
more
to
see
for
for
testing
right.
I
So
I
put
a
couple
of
examples,
one
it's
an
issue
that
we're
working
on
that
it's
trying
to
actually
surface
that
pad
for
for
one
of
our
test,
Suites
and
then
the
other
one
is
something
that
seed
brought
up
on
this
project
that
he's
working
on,
and
he
said
that
he
couldn't
see
the
code
quality
results
and
he
was
kind
of
confused.
So
those
are
two
very
specific
examples,
but
I
think
this.
This
has
different
angles:
it
populates
from
different
point
of
views.
You
know
it's
it's
it's
big,
so
I
think
it
has.
I
I
I
I
You
see
when
there's
metric
reports
change
from
50
points.
Okay,
that's
interesting!
So
you
expand
these
right
and
then
you
see
these
in
your
oh
okay,
there's
some
change.
You
see
the
gem
size
and
whatever
that's
kind
of
one
good
example
of
something
that
basically
ends
here
right
like
at
this
point,
there's
nothing
else
for
you
to
do,
but
the
fact
is
that
there's
more
things
for
you
to
do
right.
So
another
example
is:
let
me
find.
I
I
There's
usually
when
you
get
tests
there's
when
you
get
that
when
the
Mr
run
runs
the
test,
it
basically
tells
you
like
the
changes
that
happen,
and
eventually
you
can
see
those
things
here.
You
can
actually
click
and
you
can
see
like
the
excerpt
of
the
test,
but
again
that
that
doesn't
give
you
the
full
context
right.
So
one
of
the
things
that
we
want
to
allow
people
is
to
see
the
beautiful
report.
I
So
what
we
want
to
do
right
now,
it's
kind
of
fix
these
by
you
know
adding
a
similar
bottom
to
the
one
that
we
have
security,
but
that's
for
me
that
still
feels
a
little
bit
of
like
a
bad
date,
because
I
think
there
should
be
a
better
ways
to
discover
what's
going
on
one
example.
So
this
is,
you
is
the
buda
we
want
people
to
see.
This
contains
the
full
report
and
apparently
from
what
we
see
like,
for
instance,
that
feedback
provided
by
seed.
He
couldn't
get
to
this
point.
I
I
If
you
go
to
his
to
his
commit-
and
you
see
this
thing
like
there's-
he
was
basically
going
to
into
the
into
the
job
you
and
he
couldn't
see
how
to
basically
see
those
results
for
doing
the
code
quality
to
the
code,
qualities
here
and
he'd
passed,
but
he's
not
seeing
the
test.
So
how
can
he
reach
here
to
that
place?
There's
nothing
like
you,
click
Dec.
Basically,
it's
like
a
recursive
thing
that
keeps
bringing
you
here.
So
that's
not
a
way
to
discover
it.
I
It
happens
to
be
that
if
you
wanna
see
your
code
quality
results,
you
got,
you
have
to
go
to
the
pipeline
view
and
then
code
fault,
the
code
quality
tab
is
there
and
then
you
see
it
here
right.
So
that's
that's
basically
what's
happening
is
that
many
things
are
combined
and
are
finalizing
this
pipeline
page,
but
I,
don't
think,
there's
full
a
full,
clear
path
to
to
reach
this
page
I.
I
I
Another
interesting
thing
to
see
here
is
usually
when
you
run
a
pipeline,
something
that
you
will
do
is
you
go
and
you
will
review
the
pipeline's
from
memory
here.
So,
for
instance,
in
this
case
you
see
that
let's
say
that
the
test
was
not
pass
was
failed
and
then
you
click
on
these
and
then
let's
say
that
you
wanna
see
the
real,
like
so
you're
on
the
test
stage.
We
were
reviewing
a
test
stage
and
then
you
wanna
actually
go
and
see
the
test
results.
I
So
it
seems
that
there
should
be
a
way
to
review
the
test
results
for
this
stage.
But
if
you
click
these,
this
is
just
gonna.
Take
you
to
the
job
which
again,
like
basically
locks
you
into
these
I,
don't
know
into
this
weird
recursive
state
and
you
it's
not
taking
you
to
the
right
place,
which
is
the
pipeline
view.
I
So
yeah
I
basically
wanted
to
just
open
that
up
and
see
if
this
is
an
issue
for
other
people,
how
we
can
improve
score
ability.
I
think
my
early
thoughts
on
this
is
that
it
seems
the
discoverability
of
features.
It's
like
a
generalized
problem.
Indeed
lab
I
collect
sometimes
hear
these
from
other
people
that
it's
like.
Oh
people,
don't
can
find
feature
flags
or
people
can
find
the
out
of
the
box.
You
know
that
type
of
stuff,
you
know
another
early
thought
and
inside
that
I
had
was.
Do
we
hide
too
many
things.
I
I
So
that's
kind
of
another
early
question
that
is:
do
we
hide
too
many
things?
She
wins
them
instead
show
those
things
to
disable,
and
the
final
thought
that
I
have
is:
are
we
hurting
our
own
adoption
of
our
tools
by
being
this
fake?
You
know,
like
sometimes
I
feel
that
testing,
who
have
way
more
adoption,
even
where
more
prescriptive,
about
the
way
that
we
show
our
features
like
upsell
these
opportunities
to
test
or
to
enable
testing
in
the
projects
and
I.
Don't
think
we
do
enough
for
that.
I
A
Was
great,
thank
you.
So
much
for
sharing
I
want
to
jump
in,
because
I
have
been
having
a
similar
experience
with
just
the
newer
features
or
different
features,
we're
kinda
struggling
to
get
users
to
use
them.
Unless,
like
you
described,
they
go
in
Google
or
look
at
our
documentation
about
how
to
do
it,
and
then
they
discover
it.
I've
had
users,
the
container
registry
is
usually
just
available
and
I've
talked
to
users
and
they
didn't
even
know
we
had
a
package
manager
even
though
they're
almost
like
equal
in
terms
of
features.
A
Our
package
manager
is
even
more
different.
Maturity,
level
and
they're
still
had
no
idea.
Was
there
so
we're
having
that
issue
too.
But
to
your
original
point
of
ways,
we
can
make
testing
a
little
bit
more
discoverable.
I
just
did
some
solution,
validation
with
users
around
the
container
registry,
and
we
were
asking
them
to
troubleshoot
a
problem.
We
gave
a
really
can't
be
story
of.
Like
your
manager
told
you
nothing
except
something
is
wrong.
A
What
would
you
do
and
a
couple
of
the
users
actually
said
that
if
the
tag
was
built
through
the
CI,
they
would
want
a
way
to
quickly
either
know
the
test
passed
in
association
with
that
image
or
some
sort
of
relationship
there
I
didn't
dive
in
I
should
have.
That
would
have
been
awesome
for
this
conversation,
but
I've
heard
users
want
to
have
a
connection
between
their
images
and
the
tests
when
they're
trying
to
troubleshoot
that
could
be
another
area.
We
can
explore
how
we
can
get
users
to
that
testing
screen
more
efficiently.
I
Yeah,
no,
that's
great
I,
think
I.
Think
you're
right!
That's
that's
that
point,
someone
something
that
we
have
to
also
consider
I.
Think
there's
some
I
think
the
tactical
concern
right
now.
It's
like
how
do
we
take
people
to
that
page?
You
know,
and
sometimes
I
have
like
this
little
concern
that
that
page
is
not
caught
in
it.
You
know
that
we
might
need
like
something
different,
but
God
basically
broadens
the
scope
of
this
problem
and
yeah
I,
don't
want
to
kind
of
like
go
down
that
road
route
I
think
I.
Initially.
I
What
I
want
to
make
sure
is
that
people
are
aware
that
we
have
robust
testing
capabilities.
Some
of
them
are
building
in
there
CI.
They
just
need
to
like
set
up
like
a
couple
things
under
you'd
love
to
see
IMO
file
and,
like
code
quality's,
a
great
example
that
one
is
like
so
easy
to
set
up
and
I.
Don't
think
many
people
are
adopting
that
us
as
much
as
they
sure
I
think
ya
have.
F
B
It
could
be
that
you're
that
we're
not
the
discoverability
is
in
the
problem.
It's
like
what's
the
journey
that
we
need
to
lead
people
to.
So
if
we
want
them
to
be
like,
if
it's
a
developer
that
we're
trying
to
encourage
you,
then
we
want
to
talk
about
their
build
process,
and
maybe
package
is
the
extreme
part
that
we
drive
them
to
then
really
release
being
just
as
useful.
In
that
case,
to
write.
I
This
is
kind
of
like
the
same
problem
with
two
different
paces.
One
is
how
how
do
you
drive
adoption
through
discoverability
right
like
so,
you
have
a
fresh
project
and
you
wanna
enable
code
quality.
What's
the
best
way
to
do
that
right,
that's
one
thing,
but
I
think
once
you
have
code
quality,
it's
not
super
clear
how
you
can
use
it
besides,
like
that,
mr
widget
tells
you
like.
Oh
your
code,
quality
drop
five
points.
I
You
know,
that's
that's
the
extent
of
the
quran'
discoverability
of
the
issue,
but
we
do
have
more
things
to
show
like
the
code
quality
tab
at
the
pipeline
level.
You
know,
so
I
think
it's
the
same
problem,
two
different
phases.
That's
why
I
open
up
with
like
a
more
generic
statement
about
his
discoverability,
an
issue
in
general.
You
know:
do
we
like
I
feel
sometimes
that
we
hide
too
many
things
right
and.
B
I
I'm
just
gonna
give
a
hypothetical
example
right.
Well,
y-you
have
an
MRI
on
mr
right
and
you're
with
a
pipeline.
It
runs
the
EMR
runs
the
pipeline.
It
shows
you
all
the
results
right.
Let's
say
that
you
don't
have
code
quality,
enabled
for
that.
I
think
my
question
when
it's
like
a
super
rhetoric.
Question
trying
to
like
elicit
a
conversation
here
is
schewe
show
dummy
mr
widget
that
says
like.
Oh,
it
seems
that
you
don't
have
code
quality
enable
do
you
wanna
enable
code
quality
right
or
is
that
too
much?
I
Is
that,
like
a
a
naps
all
that
pills
too
pushy-
and
we
shouldn't
do
that?
Oh,
I
that's
kind
of
what,
because
I
would
love
to
do
that,
but
that
also
feels
that
if
we
go
down
that
route,
like
many
of
you,
are
gonna,
adopt
the
same
way
of
you
know
pushing
their
features,
and
then
it
becomes
basically
at
work,
which
is
something
that
I
don't
want
to
happen.
Prickett
love
so.
H
It
depends
on
how
we
do
it
so
I've
seen
places
bread
is
done
in
a
really
nice
way.
Obviously,
if
we,
if
you
want
to
upsell
I,
know
premium
features
to
starter
user,
then
if
I
would
be
to
start
user
three
upsetted
guys
I
decided
on
this
package.
The
purpose,
on
the
other
hand,
if,
if
I'm
on
the
free
tier
and
people
actually
showing
me
paying
features
and
I,
came
in,
try
them
for
a
short
time,
then
that
can
that
can
really
drive
my
interest.
I
I
So
that's
another
consideration
right
like
if
I
don't
think
we
show
up
cell
necessarily
things
that
are
like
from
like
the
next
year
and
if
we,
because
that
feels
a
lot
like
ads,
but
maybe
the
experience
that
I
was
trying
to
maybe
the
experience
I
was
that
I
was
trying
to
paint
here
was,
let's
say,
if
you're
paying
for
gold
and
you
have
all
these
features,
we
should
try
to
be
more
prescriptive.
Wow,
hey!
You
have
features
that
you're
not
using
you're
like
gitlab,
is
way
more
powerful
and
you're
paying
money
for
these.
H
We
have
three
options:
one
is
when,
when
I'm,
paying
customer
and
I
think
we
agree
that
we
don't
want
to
sell
from
the
from
different
here,
but
I
agree
with
you
as
well
that
if
I,
that
be
definitely
would
like
to
encourage
using
the
features
in
your
current
here
that
you
are
currently
on
a
barrel
for
don't
use
them.
On
the
other
hand,
I
would
even
say
that
if
you
are
free
user,
I
would
be
happy
to
kind
of
invite
you
like
the
pencil
right
after
the
to
that.
H
H
I
B
I
A
They're
also
really
great,
if
you
do
have
an
idea
of
a
way
to
like
not
cross,
sell
but
exchange
the
idea
that
you
could
better
utilize
gate
lab
they're,
really
excited
about
sharing
the
idea
and
will
offer
a
lot
of
tips
and
strategies
of
how
to
track
adoption
to
see
if
it
really
is
helping
so
like.
Should
you
continue
doing
stuff
like
that
or
not
so
that.
G
J
Do
we
do
anything
when
we've
launched
new
features
to
let
people
know
what's
new?
Is
there
any
components
to
get
lab?
That
does
look
anything
like
that.
Like
the
new
slack
just
came
out,
if
you
yeah
quit
and
relaunch-
and
it's
got
the
nice
package,
you
know
gift
box
thingy
what's
new,
do
we
do
anything
like
that?
I
think.
A
Component
that
I
think
is
specifically
designed
to
be
like
marketing
centric,
so
that
you
can
add
that
to
different
parts
of
your
UI,
so
we're
using
it
now
we're
gonna
try
anyway,
to
demonstrate
the
dependency
proxy
and
it's
definitely
saying
hey.
This
is
the
thing
now
you
can
do
it
so
that's
another,
but
you,
as
everyone's
kind
of
mentioned.
You
need
to
be
careful
with
how
many
of
those
vanities
yeah
yeah.
Of
course,
that's
a
problem
because.
J
I
see
this
is
there's
two
two
issues.
There's
one
is:
if
there's
something
new
people
don't
know
it
and
then
two,
if
you're
in
a
use
case
like
it's
been
weeks
since
that
new
things
been
released,
you're
doing
specific
use
case
and
you
should
be
using
this
thing,
but
you
don't
even
know
it's
there.
How
do
we
make
them
aware
of
that?
You
know.
There's
I
see
this
as
two
areas
of
improvement,
I,
guess
yeah,
that's
you
can
upsell
on
your
phone.
Sorry
thank.
A
You
everyone
we
are
at
a
time.
We
had
two
great
conversations
around
two
different
product
areas.
Hopefully
we're
going
to
be
walking
away
with
some
great
ideas.
As
always,
if
we
can
go
through
the
notes
and
whatever
new
ideas
or
new
things
that
we
should
be
trying,
you
should
break
those
out
into
issues,
let's
make
sure
to
add
that
think
big
labels
so
that
we
can
track
and
see
if
this
is
continuing
to
be
successful.
A
F
I
see
also,
there
are
some
comments
and
questions
in
the
know
in
the
chat
room.
If
we
have
read
through
each
should
we
do
and
I
want
to
just
link
it
leave
it
in
the
chat,
but
it's
also
somewhere
in
this
document,
and
if
you
maybe
can
help
me
to
highlight
that
and
also
leave
that
in
the
comments
and
also
would
like
to
encourage
every
p.m.
or
the
product
designer
for
that
manager.
Who
is
creating
any
issues
for
the
follow-up
of
the
sessions?
Please
leave
the
thing
big
label.
F
This
helps
us
for
future
accessibility
of
the
process
and
yeah
help
us
helps
us
to
see
what
outcomes
we
have
received
out
of
these
sessions
and
yeah
would
be
happy
to
see
any
feedback.
Positive,
negative
neutral
in
the
retro
sessions,
as
Ian
said,
be
sure
that
the
trials
and
the
experiments
or
what
we
would
like
to
improve
this,
please
leave
us.
Your
suggestion
did
I
mention
everything
in.
Are
we
forgetting
anything?
No.