►
From YouTube: Release Group Product & UX Sync • 2022-02-18
Description
Daniel Fosco (Senior Product Designer) and Chris Balane (Senior Product Manager) discuss the current and upcoming work for the Release stage
Agenda (internal): https://docs.google.com/document/d/1Enn_E0guWmRBpi_sl_0Kw0p7K8QQNF6SbXliGvMwvxI/edit#heading=h.3mopkvc0fgpx
A
Hello:
everyone,
I'm
daniel
fusco,
the
senior
product
designer
for
the
release
group
on
the
lab,
and
I'm
here
with
chris
balani,
the
senior
product
manager
for
our
group,
and
this
is
the
release
ux
and
product
weekly
chris-
is
sharing
his
screen
so
I'll
hand
it
over
to
you.
Chris.
B
Yeah
everyone,
so
we
have
our
staying
agenda
here,
so
we're
going
to
go
through
these
topics.
The
first
one
is
reviewing
the
planning
issues,
so
just
a
quick
check
for
14.9.
We
should
be
pretty
much
finalized
on
this
issue.
At
this
point
in
the
milestone
we
actually
recorded
a
kickoff
video
the
other
day
that
I
I
need
to
share
actually
out
the
channel,
but
we
walked
through
the
deliverables
for
the
engineering
side.
B
B
We've
been
going
back
and
forth
async
and
I
think
I'm
pretty
I'm
pretty
happy
with
where
we're
at
nicole.
This
is
more
for
the
engineering
side.
Nicole
did
flag,
like
I
think,
a
security
issue
that
that
we
might
need
to
take
on
engineering,
but
you
know
we'll
I'll
work
through
that
with
her
anything
else.
From
your
side,
daniel.
A
This
first
issue
here
in
the
design
work.
I
remember
us
discussing
it
and
I
actually
forgot
to
to
add
it
in
the
milestone.
So
I
think
you
just
did
here,
but
it
doesn't
have
the
weight
so
I'll
just
update
the
weight
accordingly,
it
shouldn't
be
a
big
big
thing,
because
I
remember
this
is
just
about
updating
the
the
single
single
environment
page
with
the
new
deployments
right.
So
it
shouldn't
be
a
lot
of
work,
so
it
should
fit.
B
Sounds
good
and
yeah
and
I'm
pretty
sure
I
think
most
of
the
I
was
actually
I
was
actually
telling
the
call.
I
think
you
already
did
that
or
have
that
done
in
some
way.
We
just
need
to
add
it
to
the
issue
or,
if,
if
not,
then
we
already
have
the
pieces
we
just
sort
of
need
to.
A
B
Cool,
okay
sounds
good,
so
that's
14
1410,
let's
open
this
up.
I
think
this
is
pretty
sparse
at
the
moment.
Oh
actually,
we
got
some.
B
B
The
engineering
side
actually-
but
this
is
definitely
not
final-
I
think
we'll
want
to
make
sure
we
incorporate
some
of
the
other.
I
think
forward-looking
product
work
that
daniel
has
been
working
on
and
that
the
engineering
team
will
be
waiting.
This
49
milestone
so
more
more
progress
there
and
then
design
anything
else
that
you
want
to
speak
to
here.
Daniel.
A
So
I'm
not
really
sure
what
to
schedule
on
them
beyond
just
a
continuation
of
our
current
work
of
the
issues
that
we
have
in
14.9,
the
the
ones
related
to
the
ux
okrs,
with
high
severity
and
ux
adapt,
and
even
outside
of
that
just
other
usability
issues
and
small
fixes
for
environments
and
deployments.
We
have
plenty
of
those,
but
I
wanted
to
make
sure
that
that
I'm
scheduling
the
right
things
to
to
also
aim
in
the
direction
we
want
to
move
towards
so
that
where
I'm,
I'm
feeling
not
lost.
A
But
I
I
I
wanted
like
stronger
direction
on
this
yeah,
so
yeah,
that's
something
we
can
discuss
and-
and
I
mentioned
the
delivery
team
because
we
talked
to
them
recently
and-
and
we
raised
working
with
them
directly
as
one
strong
team.
We
could
focus
on
at
least
from
the
ux
side.
So
yeah,
maybe
structuring
that
for
1410,
is
a
good
bet
for
us.
B
Yeah,
I
think
so
I
think
we
can
have
the
discussions
and
kick
off
those
discussions
in
14
or
continue
those
discussions.
I
should
say
in
49
and
that
will,
I
think,
give
us
some
source
of
problems
to
focus
on
yeah.
So,
let's
so
that's
I
think
that's
a
great
idea.
So
14
9
start
conversations.
B
And
then
the
other
source
is
now
yeah.
I
think
I
wonder
if
a
good
exercise
to
talk,
so
we
can
think
about.
B
1410
is
reviewing
the
planning
board,
so
maybe
we
could
take
a
quick
look
at
that
yeah
and
then
I
also
want
to
pull
up
the
road
map,
because
now
that
we've
skipping
topics
around
a
little
bit,
but
now
that
I've
put
together
a
road
map,
I
the
kind
of
the
goal
for
that
is
so
we
can
align
in
the
future
direction,
but
then
also
work
backwards
and
figure
out.
Well,
what
do
we
need
to
do
to
get
there.
B
Okay,
okay,
so
here's
high
level
roadmap,
so
this
is
where
we
are
today
february,
we're
still
continuing
to
work
on
redesign
approvals.
I
think
we're
pretty
complete
on
in
terms
of
design
for
these
epics.
Do
we
think
so.
A
There
are
a
few
a
few
improvements
and
iterations
that
I
have
in
mind
that
I
want
to
do,
but
they
like
scheduling
them
right
now,
doesn't
make
sense,
considering
there's
so
much
work
to
wrap
up
the
development.
So
I
also
don't
want
to
like
overwhelm
the
the
engineering
team
with
more
context
around
future
stuff
for
this
right.
A
But
it's
small
stuff,
like
I'm,
really
happy
with
the
way
it's
being
developed,
because
it's
really
like
exactly
what
what
the
design
was
sought
out
to
be
so
really
happy
with
that
and
then
in
the
approver
jack.
There's
few
there's
a
few
couple
things
yet,
and
they
are
here
in
our
agenda
to
be
discussed,
but
not
a
lot
like
it's
it's
minor
things
and
things
are
really
outside
of
the
mvc
right
yeah
in
terms
of
design.
We're
good
with
this.
With
these
two.
B
Cool
will
we
do.
We
think
we
can
include
one
thing
just
came
to
mind
the
approvals,
or
will
we
want
to
include
approval
actions
in
the
in
the
single
environments
page?
I
think
we
haven't
sort
of
a
related
issue
where
we're
talk.
We've
been
talking
about
the
manual
jobs
as
part
of
the
deployments
page
to
me,
those
are
pretty
simple.
A
B
Okay,
right,
okay,
cool,
so
as
long
as
yeah.
If
we're
good
on
that
one,
then
I
think
we
can
continue
through
the
mode
map.
Okay,
so
then
the
next
one
here
is.
This
is
error,
budget
improvements.
I
think
no.
This
is
more
about
back-end
like
optimization,
so
I
think
we
could
skip
that
one.
The
next
one,
I've
included,
is
environment,
deployments
cleanup.
So
really
the
high
level
for
this
epic
is
thinking
about
what
we
can
do
to
better.
B
I'll
enable
the
user
to
manage,
like
literally
manage
the
many
different
environments
that
might
build
up
over
time,
just
through
natural
usage
and
and
and
so
in
my
mind,
there
are
a
few
ways
we
can
do
that
we
can,
I
think,
probably
the
best
ways
to
automate
clean
up
as
much
as
possible,
and
so
we
did
do
a
recent
feature
where
we
auto
archive
kind
of
stopped
environments.
B
The
way
yeah
archive
and
technically
it's
I
think
it's
is
it
I'm
trying
to
recall
it
said
something
to
do
with
the
ref
the
get
ref
where
we
might
have
removed
the.
Let
me
let
me
actually
look
it
up
rather
than
trying
that.
B
Archival
deployments
is
what
we
called
it.
We
deleted
the
old
deployment
reps.
Specifically
that's
what
we
did
yeah
but
there's,
I
think,
there's
other
ways
to
potentially
clean
these
up,
and
so
there
are
a
lot
of
issues
here,
but
I
think
one
that
was
that
has
been
uploaded
our
like.
I
think
it
was
this
one
there's
you
know
in
terms
of
cleaning
up
this
one
was
pretty
sure
this
is.
This
is
uploaded
it's
another
one
of
steel
environments.
B
Was
the
one
yeah
that
was
really
highly
uploaded,
so
I
think
so,
potentially
some
of
these
issues.
B
Yeah
and
then
we
had
it
back
and
forth.
You
continue
about
this
as
well.
B
A
Yeah,
I
think
this
is
an
interesting
problem,
because
there's
different
different
vectors
for
solving
this,
like
one
one
important
vector,
is
like
just
reliability.
We
can
let
the
the
weight
of
all
deployments,
just
cause,
outages
and
and
just
degrade
the
the
reliability.
But
on
the
other
hand,
we
can
also
solve
solve
some
of
these
problems
from
the
ui
perspective
right.
Just
because
you
have
a
bunch
of
old
deployments
or
old
environments
that
you
don't
want
necessarily
delete
them.
They're
also
not
useful
being
shown
to
you
all
the
time
in
the
ui.
A
So
we
can
take
a
two-tier
approach
where
we
work
on
the
ui
to
just
focus
on
showing
you
what's
actually
useful,
but
also
work
from
the
back
end
and
and
reliability
perspective
to
let
you
remove
them
as
well,
so
they
don't
cause
troubles
troubled
online.
A
The
this
this
it's
interesting
that
this
specific
issue
that's
most
important:
the
provider
mechanisms
clean
up
stale
deployment
environments,
the
the
agreement
we
came
to
and
I'll
leave
the
comment
linked
here.
The
agenda
is
actually
to
just
not
do
anything
from
the
ux
perspective.
The
environment
should
be
cleaned
up
by
a
background.
A
Interesting
approach
because
there
had
been
so
much
discussion
and
and
ux
proposal
in
this
issue,
and
then
I
think
it
was
maybe
sheena
and
vlad
who
came
up
with
the
idiots
just
let's
just
not.
Let's
just
solve
this
on
the
background
and
and
assume
that
it's
the
best
and
users
really
don't
need
to
know
this,
and
I
agree
with
that
at
the
time
we
have
to
pick
this
up
this
this.
A
B
Yeah,
I
think
so
maybe
a
good
next
step
is
to
re-engage,
because
I
think
at
least
for
me
I
didn't.
I
wasn't
able
to
even
respond
here,
so
talk
it
over
with
shinya.
I
know
it's
marked
ready
for
development,
but
sort
of
in
with
a
lot
of
these
issues
that
I'm
finding
is
like.
B
Even
though
we've
you
know,
they're
sort
of
marked
ready
to
develop
and
we
want
to
a
lot
of
them
have
been
old
or
you
know
just
worked
on
part
like
for
a
while
or
a
while
ago,
and
so
we
want
to
just
make
sure
so
maybe.
B
Next
step
for
for
this
one
yeah.
A
Oh,
I
think
I
I
a
good
idea
is
to
bring
this
up
in
our
next
team
meeting
on
tuesday.
Let's
see,
we
have
like
a
quick
like
sending
check
from
everyone
in
the
room
on
this
and
then.
B
B
B
Yeah
yeah
agree,
agree,
yeah
sounds
good,
okay,
cool.
A
B
I
just
wanted
to
quit
check
this
one
really
quickly
to
see
if
there's
any
votes
just.
A
This
one
is
a
minute,
because
what
is
that?
Does
it
mean
to
delete
deployments
via
api?
Do
you
send
a
command
with
the
id
of
a
specific
deployment,
or
do
you
set
a
command
that
has
like
a
time
window
like
every
department,
every
deployment
older
than
x,
and
you
give
a
date
and
it
just
like
wipes
off
them
all
out?
I
think
it's
it's
an
interesting
detail
that
we
can
think
of
like
what
is
the
use
case.
It
is
deleting
like
specific
deployments
one
after
the
other.
A
It
is
having
a
sort
of
like
cron
job,
it's
something
that
runs
recurrently.
That
cleans,
like
the
you
know,
last
month,
six
months
back,
something
like
that.
Just
understanding
how
exactly
this
will
be
used
and
designing
against
that.
B
What
the,
what
the
real
the
problem
to
solve,
too,
is
you
know
if
it's
cleaning
up.
A
Right
I
mean
from
from
the
like
crud
perspective
right.
If
we
can
create
deployments
via
api,
it
makes
sense
that
we
also
can
delete
deployment
view
api.
I
guess
that
makes
sense
yeah,
but
from
the
perspective
of
this
epic
and
and
and
this
idea
of
cleaning
up
the
excessive
artifacts
that
either
you
know,
impact
the
ui
or
impact
the
reliability
of
of
of
gitlab.
A
My
my
main,
like
path
here,
is
just
making
sure
that
whatever
we
can
do
that
does
not
involve
like
users
is
the
best
and
it
sounds
counterintuitive.
Perhaps,
but
the
idea
is
users
shouldn't,
be
worrying
about
cleaning
up
their
artifacts,
to
avoid
outages
or
to
reduce
your
usage
of
gitlab
storage,
or
something
like
that
right.
It
is
something
that
we
should
solve
automatically
for
them.
Maybe
they
can
configure
like
how
how
specifically
they
want
it
to
happen.
A
B
Yeah
that
makes
sense
yeah.
I
like
the
idea
of.
B
Yeah
separating
that
as
you're
saying,
and
then
this
maybe
this-
I
don't
know
if
we
have
a
specific
issue
but
like
I
like
your
idea
of
like
focusing
on
this
epic
and
then
we'll
work
together
to
break
it
down
and
that
could
be
a
good
focus.
Yeah
yeah,
I
think
that's
perfect
for
14
10.,
sorry.
What
was
that?
Okay,
yeah
cool?
B
Well,
let's
see
just
continuing
down
here
in
the
road
map,
so
the
other,
the
other
epic
that
will
that's
next
here-
is
improving
environment
functionality
and
usability,
and
so
this
is.
This
is
more
of
also
a
parent
epic,
but
there
are,
I
think,
in
general
again
the
themes
are
continuing
to
enhance
the
environment's
page
and
what
you
can
do
there,
the
design
of
it
usability
honestly,
this
overlaps
and
probably
with
a
lot
of
the
work
we've
done
and
you
you've
redesigned
in
the
new
in
the
new
page.
B
So
I
think,
there's
probably
some
of
like
de-duping
and
like
closing
out
some
of
these
older
issues,
but
you
know,
maybe
that's
something
we
could
do
async
like
so
like,
for
example,
usability
improvements.
Some
of
these
are
like
ui
kind
of
problems
or
issues
like
default.
Sorting
we
already
solved,
but
maybe
these
are
some
some
things
that
we
consider.
I
think
the
one
for
me
that
would
be
really
high
impact,
is
adding
a
search
bar
to
the
environments
page.
A
B
I
think
that
would
be
a
kind
of
a
high
impact
feature,
probably
one
that
we
would
probably
a
fairly
straightforward
design
actually,
but
I
think
we
want
to
only
keep
that
one
on
our
radar
yeah.
A
There's
a
lot
of
stuff
here
that
can
be
closed
once
once
the
new
environment
goes
up,
but
it's
enough
enough
issues
that
that
we
need
to
like
take
out
time
to
go
over
them
and
make
sure
we're
closing
everything
that
we
can't
close,
but
only
things
that
should
be
closed
right.
We
don't
lose
any
information
in
this
process,
but
yeah
there's
a
lot
of
things
that
we
cleaned
up
here
and
I'm
excited
to
just
go
over
it
and
chop
it
down,
because
it's
been
a
long
time
coming.
A
There's
there's
a
lot
of
of
ideas
that
that
makes
perfect
sense
for
our
new
page,
like
the
search
bar
that
we
can
pull
out
of
here
and
work
on.
B
Cool
yeah,
maybe
it
might
be
a
good
idea
to
do
that.
Async
like
we
could
go
through
these
epics
yeah.
I
I
think
I
think,
from
sort
of
the
design
side
you'll,
you
would
have
a
good
idea
of
like
well
yeah.
Actually,
this
this
prior
proposal
doesn't
really
make
sense
anymore.
A
And
then
in
terms
of
timing,
considering
the
the
new
environments
page,
it's
almost
done,
I
think
there's
I
think
you
know
there
is
one,
mr
that
is
still
pending,
it's
related
to
alerts,
but
I'm
pretty
sure
with
all
the
others
closed.
The
corresponding
issues
are
also
closed.
Right,
like
it's
still
behind
the
feature
flag,
but
from
the
gitlab
perspective
it
is
considered
as
done.
I
think
yeah.
A
B
A
B
Yeah,
the
one
thing
I
think
we
can
talk
to
and
then
it
probably
makes
sense
to
maybe
keep
defer
the
rest
to
later,
or
at
least
for
just
interest
of
time
here.
The
next
one
is
I've
created
a
new
epic
called
org
level
environment
management.
Really,
this
is
what
we've
been
calling
group
environments
or
shared
environments.
B
I
just
created
a
holding
epic,
because
this
is
sort
of
a
side
note,
but
we
were
doing
a
road
map
exercise
for
the
sales
kickoff,
and
so
we
we
had
to
put
together
like
key
features
that
we're
planning
to
build
in
next
year
which
we're
excited
about.
So
this
one
is
obviously
to
me
is
a
huge
one.
So.
B
Yeah,
but
anyway
like
this
is
the
one
you
and
I
have
been
working
on
and
collaborating
on
with
tyanna
and
jackie
and
others
in
china,
and
so
essentially
yeah
anything
related
group
environments
that
we
want
to
think
about
for
design.
I
think
we'll
want
to
prioritize
that
too,
so
you
and
I
have
already
been
working
on
the
first
mvc
of
this
and
I
think,
we're
in
a
good
place.
B
I
actually
still
need
to
post
mark
my
comment
about
what
you
and
I
discussed
in
terms
of
shinya's
open
questions,
but
I
guess
the
question
is:
if
there's
anything
here,
that
we
want
to
slot
in
for
1410
for
design
to,
but.
A
B
B
A
Perspective
and-
and
I
I
it
is
planning
breakdown
because
the
design
was
done,
but
then
we
had
some
catch
up
and
I
do
believe
the
the
ui
can
be
updated
to
reflect
our
latest
discussion
and
and
regardless
of
of
anything
else
that
we
discussed.
I
do
believe
that
is
the
direction
we
should
go
and
just
implement
that
as
the
mvc
and
just
ship
it
and
see
and
and
then
further
build
where
it
goes
from
there
right
yeah.
A
A
I
do
want
to
go
back
to
the
roadmap,
to
ask
you
something:
yeah,
please
one
of
the
issues.
The
main
issue
that
I'm
excited
to
work
on
on
49
is
connecting
environments
and
releases
which
is
down
there.
So
my
impression
is
that
this
roadmap,
for
because
of
the
way
that
this
roadmap
ui
is
set
up,
reflects
more
engineering
than
ux
right,
like.
B
Yeah,
I
that's
my
intention
and
then
you
and
I
sort
of
work
backwards
from
there,
because
this
product
works
to
sort
of
get
it
ready
and
then
there's
design
work
to
get
it
ready,
but
yeah.
That's
that's
typically
my
view
for
the
roadmap.
A
Yeah
so
for
1410,
I
think
environment
and
employment
deployments
cleanup.
It
is
request
very
much
requested,
but
it's
also
it
shouldn't
be
ux
intensive,
not
as
much
as
the
other
two.
So
in
terms
of
focus
for
1410,
I
would
rather
put
a
little
bit
more
energy
into
order
level,
environment
management
and
connect
release
station
to
other
features
yeah.
I
think
those
will
open
up
the
space
more
for
for
like
more
ux
work
in
the
future.
The
cleanup,
like
will
solve
a
very,
very
real
problem
that
we
have
and
like.
A
A
So
I
will.
This
is
really
good,
because
it's
giving
me
the
structure
that
I
wanted
to
think
on
for
1410.
So,
thanks
for
for
making
this
road
map.
B
Yeah
and
by
the
way,
honestly,
I
know
dana.
This
has
been
a
long
time
coming,
and
so
I
I
literally
spent
like
the
whole
day
on
wednesday
like
putting
this
together
and
well.
Actually,
I
started
doing
it
a
few
weeks
ago
but
like
that
was
exactly
intense,
because
now
that
we
have
this
at
least
some
some
view
of
what's
next,
we
you
and
I
can
go
into
each
of
these
milestones.
We
could
slot
in
each
of
these
projects
right
and
then
we'll
have
our
flow
going.
So
yeah
glad
glad
it's.
It's
helpful.
A
B
A
Yeah,
I
think
I
think
likely
one
of
them
will
be
a
little
bit
pushed
up
off
up
front,
but
I
would
rather
have
more
on
our
plate
to
to
prioritize
and
then
push
out
than
very
little
and
and
not
feel
like
we
we're
aiming
in
the
right
things.
I
agree
cool.
So
do
you
want
to
we're
a
little
bit
short
on
time?
Do
you
want
to
go
to
the
triage,
or
maybe
I
I
showed
the
the
prototypes
in
the
latest.
B
A
All
right,
it's
it's
pretty
short,
actually
so
the
first
one
it's
both
are
about
environment
deployment
approvals.
The
first
one
is
the
project
settings
that
need
to
be
set
up
to
add
approval
counts.
I
had
already
a
prototype
of
this
but
got
a
lot
of
feedback,
so
iterated
quite
a
bit.
A
So
this
is
what
we
have
in
production
right
for
a
protected
environment,
environment,
you
choose
the
environment
and
then
you
choose
the
users
or
roles
allowed
to
deploy
and
that
deploy
here
is
clicking
the
run
button
on
the
manual
drop,
and
that's
it
that's
what
we
have
so
this
iteration
is
about
adding
the
number
of
required
approvals.
Then
there's
a
little
change
here
in
the
copy
to
make
sure
people
understand.
A
Yeah
and
the
interesting
thing
here
is
you
see,
there's
production
twice
and
that's
on
purpose,
because
you
can
have
multiple
sets
of
approval
rules
per
environment
and
I
think,
there's
a
comment
here
that
outlines
it
pretty
well
right.
A
So
for
the
same
environment,
let's
say
production
you
could
require.
You
know
two
approvals
from
developers,
two
approval
for
approvals
for
maintainers
as
specific
roles,
and
then
one
approval
from
the
ceo,
the
user.
That
is
the
ceo
of
the
company.
You
know
perhaps,
and
then
each
one
of
these
approval
rules
would
need
to
be
met
in
order
for
the
deployment
to
run.
So
it's
nice
that
we
have
this
very
flexible
way
to
set
it
up,
and
that's
it.
A
There's
there's
like
some
some
things
that
were
added
mobile
view
just
make
sure
the
ui
doesn't
break,
but
but
this
is
the
gist
of
it
and
then,
on
the
other
side
of
the
of
the
the
counter
we
have,
the
the
you
know
the
user
facing
ui,
where
the
the
deployments
that
need
to
be
approved
show
up,
and
this
this
is.
This
issue
was
created
because
the
core
of
the
plan
of
approvals
is
on
the
environments
page.
A
That's
where
we
design
the
mvc,
where
the
nvc
is
being
implemented,
but
deployment
that
has
to
be
approved
is
a
deployment
job
and
as
pipeline
jobs,
they
show
up
everywhere
in
gitlab
right,
so
we're
introducing
a
new
state
deployments
deployment
jobs
that
need
to
be
approved
now
go
into
a
blocked
state.
This
is
a
screenshot
from
the
proof
of
concept,
so
this
is
what
they
show
right.
This
is
how
they
show
right
now.
A
The
moment
we
ship
this
feature,
and
the
idea
is
to
improve
this
so
the
first
idea
to
improve
this
it's
to
improve
the
way
we
represent
the
state
so,
instead
of
showing
blocked
we'll,
say
we'll,
show
waiting,
needs
approval.
A
The
problem
here
is
that
there's
still
a
run
button
that
doesn't
give
you
the
the
approval
functionality
that
we're
implementing
the
environments
page.
So
we
have
two
approaches
for
this.
One
approach
is
to
change
it
to
the
thumbs
up
button,
but
then
just
redirect
the
user
to
the
environments
page,
because
that's
the
place
where
you
should
approve
or
reject
deployments.
A
A
Both
me
and
xenia
are
erring
towards
the
the
previous
version,
just
redirecting
the
user,
for
a
few
reasons,
one
just
not
having
to
maintain
the
same
ui
everywhere
from
the
technical
aspect,
but
also
because
we
believe
the
place
where
the
these
users
that
approve
deployments
use
the
page
that
they
use
is
the
environments
page.
They
don't
hang
out
on
the
jobs
page
that
much
if
they
do
it's,
because
the
functionality
is
not
available
in
the
right
place.
A
So
we
want
to
make
sure
we're
funneling
users
towards
the
right
place
on
gitlab,
the
right
page
to
where
a
page
that
is
focused
and
and
optimized
to
do
this.
So,
for
now
that's
the
direction
we're
going,
but
it
is,
it
is
a
decision
that
can
easily
be
reverted.
I
would
rather
have
the
simpler.
You
know,
link
and
then
maybe
iterate
towards
this,
which
is
a
more
complex
feature
than
doing
the
opposite
right.
Yep,
that's
another
reason
to
go
with
the
smaller
step.
Yeah.
B
Completely
agree,
I,
like
the
your
perspective,
I,
like
your
point
of
view
that
the
environments
page
is
where
we
want
to
drive
people
to
do
that.
I
also
like
that,
and
this
is
probably
why
you're
thinking
of
it,
but
one
of
one
of
the
reasons
I
think
that
makes
a
lot
of
sense
is
because
in
the
future
like
we
want,
we
want.
B
That
decision
right
like
like
they
with
in
the
environments
page
they'll,
see
the
other
they'll
see
it
sort
of
in
relation
to
the
other
deployments,
the
other
projects
in
the
case
of
group
environments
right,
and
so
I
I
like,
I
think,
a
thousand
percent
agree
that
that's
the
right
decision
and
and
then
yeah
and
then
we
could
always
iterate
if
it
turns
out
like
for
whatever
reason,
people
really
wanted
the
jobs
page
but
like
yeah,
I
think,
there's
kind
of
like
multiple
reasons.
It's
easier
to
build.
B
Iteration
environments
page
has
more
information
to
make
that
like
we
want
really
we
want
to
arm
them
with
the
right
information
to
make
that
decision
right.
I
think
that's
another
way
of
looking
at
it
and
the
environment
stage
is
the
right
place.
So
just
you
know
all
that
to
say
I
agree
with
you
great
great
call.
Yeah.
A
B
Yeah,
I
think
one
thing
we
want
to
do
and
we
have
been
doing
this,
but
I
I
just
thought
it
could
be
a
good
thing
to
add
and
discuss
in
our
sync
before
next
week's
team
meeting
so
like
every
week
we
discuss
an
align
on
well,
what's
a
good
topic
to
do
an
overview
with
the
team
and
have
a
team
discussion.
B
So
I
I
so
if
you
have
anything
that
great
like,
I
think
we
called
out
one
that
which
is
already
which
we
can
just
add
here-
is
the
cleaning
up,
outdated
or
cleaning
up
old
environments.
I
think
that's
a
potential
topic
just
have
a
quick
discussion
like
what's
the
right
approach.
Let's
use
that
time
that
synchronous
time
to
have
that
with
the
team,
because
it
is
more
of
a
technical,
like
part
of
the
big
driver
for
that
that
issue
is
a
technical
problem,
so
good
to
get
some
technical
feedback
makes
sense.
B
Next,
yeah:
okay
cool.
I
know
just
we're
running
up
on
time
here.
Anything
else
that
you
wanted
to
cover
with
the
team.
A
No,
I
I
think
there
there's
enough
technical
and
also
ux
perspectives
that
we
need
to
cover
on
this.
So
so
I
think
we're
good
for
next
week,
this
one.
B
Yep
cool
and
then
yeah
the
last
one
I
added
is
I
recorded,
and
I
you
know
wanted
to
share
with
you.
This
is
a
really
long
video
and
I
just
wanted
to
share
with
you
and
with
the
team
that
I
did
a
kickoff
video
for
essentially
for
the
new
year
and
for
the
new
quarter.
So
I
like
remind
ourselves
of
what
our
visions
are
for
the
categories
dive
into
the
roadmap
that
we
were
just
looking
at
before
so
to
give
more
information
about
why
we're
prior
to
seeing
one.
B
So
those
of
you
watching
definitely
recommend
it
if
you're
interested
links
here
or
we'll
we'll
share
the
link
more
broadly.
Actually
so
people
can.