►
From YouTube: Release Group Product & UX Sync • 2022-01-20
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
A
Our
first
first
topic
is
reviewing
the
updates
on
the
group
environments,
page
issue
and
discussion.
Chris,
maybe
makes
sense
for
you
to
share
your
stream
to
go
over
some
of
the
updates.
There.
B
Yes,
one
second.
B
Okay,
can
you
see
that
all
right
again
cool
okay,
so
yeah
a?
I
wanted
to
highlight
this
update?
B
There's
we've
gotten
a
lot
of
great
feedback
from
others
from
kevin
from
victor
alana,
jackie
will
and
so
on,
and
a
lot
of
the
feedback
was
helpful
in
sort
of
framing
the
issue,
framing
the
problem
and
the
job
to
be
done
that
we're
trying
to
achieve
here
and
from
prior
contacts
that
we've
we've
known
already
from
validating
from
validation,
research
and
other
efforts
to
make
sure
that
we're
building
in
the
right
the
building
the
right
features.
B
And
so
I
wanted
to
just
sort
of
corral
the
conversation
and
make
sure
that
we're
number
one
making
sure
we're
framing
the
problem
to
solve
in
the
right
way,
so
not
necessarily
using
gitlab
specific
concepts
but
rather
kind
of
focusing
on
the
end
user
and
what
they're
trying
to
achieve.
And
so
now
the
updated
problem
to
solve
is
as
a
release,
manager
or
a
platform
engineer.
I
want
to
see
the
status
of
my
multi-project
applications,
production,
environment
and
recent
changes
in
one
place.
B
So
I
can
easily
understand
everything
that
has
been
deployed
to
my
end
users,
and
so
just
a
few.
We've
been
iterating
and
making
slight
tweaks
to
the
problem
to
solve,
and
so
just
wanted
to
highlight
some
of
the
key
things
that
we've
changed
and
that
we're
thinking
about
now.
The
change
in
persona.
So
we're
adding
a
platform
engineer.
Who
is
the
the
person
responsible
for
managing
that
environments
and
the
application
platform
infrastructure
and
they
attend?
B
B
We
also
wanted
to
make
sure
that
we
specify
key
things
like
multi-project
application
and
production,
because
those
are
things
we
want
to
focus
on
for
this
mvc
and
there's
definitely
more
more
use
cases
and
different
types
of
project
configurations,
but
in
the
spirit
of
iteration
and
scoping
down
to
this
mvc,
we
wanted
to
point
that
out
explicitly
anything
else
to
add
daniel.
A
I
refer
to
this
issue
as
group
environments
page,
but
as
part
of
these
updates,
we
also
change
the
title
to
a
dynamically
populated
organization
level,
environments
page
as
to
also
make
sure
that
we
are
detaching
this
from
git
lab
artifacts
like
project
or
group
or
workspace
or
whatever
level
it
should
be.
It
should
be
at
the
level
where
the
the
user,
the
release
manager
or
platform
engineer
wants
to
visualize
their
organization,
which
might
not
be
the
whole
company
might
be
their
department
or
their
stage
or
whatever.
A
Also
mean
that
this
page
might
be
reproduced
at
different
levels
of
the
gitlab
hierarchy
as
well
in
the
future.
So
you
might
have
this
page
at
the
group
level,
but
if
it's
a
subgroup,
you
might
also
have
this
page
on
the
group
above
it
and
so
on
all
the
way
to
the
top.
That
would
be
after
the
mvc.
Of
course,
the
initial
implementation
is
still
focused
on
group,
but
we
should
we
should
frame
the
problem
to
be
solved
and
the
solution
has
to
allow
for
this
flexibility
to
grow
in
the
right
directions
in
the
future.
B
Daniel
actually
did
you
see,
I
actually
did
add
a
little
bit
more
to
the
description,
and
I
linked
it
here
about
sort
of
like
a
little
bit
more
justification
about
the
group
solution.
Now
that
we've
defined
the
jobs
to
be
done.
B
B
Yeah
happy
to
kind
of
walk
through
that
too.
If
that's
helpful,
yeah.
A
B
Yeah
another
thing
we
added
to
the
description
here
you
know
kind
of
starting
from
the
job
to
be
done.
We
we've
narrowed
that
down
and
refined
it.
We
also
added
a
little
bit
more
explicit
kind
of
points
as
to
why
we
believe
the
solution
that
we
do
have
proposed
is
is
the
right
one,
and
so
looking
at
this
mbc
rationale.
B
Groups
are
in
practice
the
the
closest
thing
we
do
have
to
an
organization,
and
so
it
does
make
sense
to
utilize
groups.
The
group
level,
the
group
level,
as
as
the
solution
for
this
organizational
level
kind
of
environments.
B
So
this
solution
works
for
that
and
then,
as
daniel
elliott
took
us
now,
subgroups
potentially
are
used
in
similar
ways
for
teams,
and
so
this
solution
does
extend
in
the
future.
If
we
decide
to
iterate
and
implement
for
subgroups
as
well,
I've
called
out
known
limitations.
We
do
know
because
we're
narrowing
the
scope.
There
are
some
limitations
to
the
solution,
but
want
to
call
those
out
and
make
sure
that
we're
aware
and
people
are
aware
of
those
and
some
things
that
we
might
try
to
address
in
the
future.
B
Organizations
use
subgroups
and
groups
in
maybe
different
ways,
and
that
we're
talking
about
and
that's
great
and
that's
okay,
but
the
solution
that
we're
defining
right
now
doesn't
immediately
may
not
immediately
address
their
needs,
but
something
again
we
can
do
more.
Research
on
and
iterate
in
the
future.
B
Second,
one
here
is
that
we've
we're
talking
about.
If
we
go
back
to
the
job
to
be
done
about
understanding
an
applications
sort
of
environment
in
production,
we
don't
really
have
kind
of
a
first-class
concept
of
what
an
application
is.
B
You
know
we're
sort
of
talking
about
groups
which
are
loosely
coupled
to
organizations
and
there
may
be
one
or
more
applications,
and
then
we
talk
about
projects
also,
which
are
which
may
be
an
application,
but
you
may
also
have
projects
multiple
projects
that
comprise
an
application,
so
we
don't
have
anything
really
in
between
to
define
it,
and
so
that's
something
that
we've
been
thinking
about
and
may
explore
more
in
the
future
and
figure
out
how
to
incorporate
that
into
our
platform,
and
then
kind
of
the
third
point
was
related
to
what
I've
just
said.
B
We
have
applications
that
may
span
multiple
projects,
but
also
multiple
groups,
so
this
solution
doesn't
really
doesn't
fully
solve
that
and
then,
of
course,
we're
relying
this
mvc
approach
relies
on
the
production
tier
to
be
configured,
and
so
you
know
if
it's
not.
This
solution
doesn't
really
work
as
well.
So
some
things
just
some
things
that
we
want
to
call
out
and
want
to
think
about
as
we
as
we
launch
this
and
then
work
to
make
it
and
make
it
even
better.
A
Yeah,
thanks
for
sharing
that
chris,
I
had
seen
you
updated
the
problem
to
solve
and
the
context
on
the
top
of
the
issue,
but
I
hadn't
seen
these
these
additional
acquisitions.
So
this
is
really
good
and
I
think
it
addresses
all
or
most
of
the
points
that
were
raised
in
the
discussion
tracks,
both
from
the
perspective
of
where
we
want
to
go
with
this,
and
also
why
we're
not
there
yet
right.
What
are
the
limitations?
Why?
Why
are
we
drawing
the
line
in
the
mvc
where
we
are
drawing
and
and
acknowledging
that?
A
Yes,
we
are
tying
the
solution
to
some
artifacts
in
gitlab,
because
that's
how
we
implement
the
mvc,
but
ideally
in
the
future.
That
would
not
be
the
case.
I
like
how
you
finished
mentioning
the
production
tier,
because
it
ties
to
to
what
I
wanted
to
show,
which
are
the
latest
streams,
so
I
will
take
over
the
spring
share
and
share
my
figma.
A
A
A
I
think
this
makes
sense
and
won't
introduce
any
confusion,
but
we
can
validate
that
as
well
of
course,
and
then,
in
terms
of
of
how
this
is
visualized
there,
there
are
a
few
options
right.
I'm
added
here
an
empty
state
that
says
to
view
all
the
production
environments
for
the
group.
In
this
page
add
production
tier
to
your
environments.
So
this
empty
state
assumes
that
you
have
zero
environments
in
any
projects
that
have
production.
Tier
does
there's
nothing
to
show
here
then,
once
you
do
have
that
configured
there's
different
ways.
A
We
could
show
this
a
very.
B
A
B
Dude
yeah
go
on
sorry.
Do
you
mind
if
I
I
have
a
quick
comment
on
the
last
screen?
Is
that
all
right
or
do
you
want?
Maybe
we
want
to
do
that
later?
Okay,
yeah!
I
wonder
if
it
may
be
a
quick.
B
A
Linked
did
this.
This
is
a
very
basic
empty
state.
We
can
definitely
improve
it.
Add
your
add
your
or
your
comment
on
the
on
the
dock
on
the
agenda
be
sure
to
to
get
back
to
it.
Yeah.
Definitely
thanks
for
that,
but
yeah
once
once
you
you,
you
do
have
something
configured
to
show
here.
A
There's
different
approaches:
we
could
take
the
the
most
simple
one
is
just
to
hard
code
production
and
then,
if
you
have
production
tier,
it
shows
this
this
header
here
that
that
specifically
says
these
are
environments
and
deployments
with
production
tier,
and
it
shows
everything
we
have
here,
there's
a
an
ordering,
so
you
can
order
like
which,
which
order
you
want
to
see
the
projects
on
which
is
important,
because
you
may
have
hundreds
of
projects
within
your
your
group.
A
So
that
helps,
but
maybe
we
want
to
you
know
have
this
is
a
search
block
similar
to
the
one
in
the
issues
and
boards
view.
So
essentially
you
choose
tier
and
then
the
production
tier
here.
A
So
in
theory,
you
could
also
see
everything
that's
going
to
staging
tear
to
you
know:
dev
tear
other
other
tiers
as
well,
and
then
the
the
actual
question
I
come
one
make
that
that
ties
to
your
to
your
last
comment
is:
do
do
we
have
enough
confidence
on
the
usage
of
production
tier
to
release
this
map
into
it,
because
it
might
be
the
case
that
so
little
customers
are
using
the
production
tier
right
now
that
this
won't
get
adoption
at
all,
and
maybe
we
should
really
focus
on
the
url.
A
That's
that's
the
question
I
have
and
and
then
on
top
of
that,
how
to
set
up
the
url.
I
I
use
the
same
the
same
design
pattern
here
from
the
boards
view,
so
you
could
define
the
url
as
whatever
you
want,
maybe
with
a
wild
card
and
then
you
perhaps
you
could
also
define
something
else
like
the
tier,
but
that
that's
a
big
question
for
me.
A
I
think,
technically
speaking
in
terms
of
of
the
product
using
the
tiers
is
the
right
choice
looking
forward,
but
I
don't
know
if
he
will
ease
adoption
or
maybe
we
want
to
use
the
tier
here
exactly
to
to
have
that
as
a
forcing
function.
So
our
customers
start
using
deployment
tiers
on
their
environments.
That
may
also
be
the
case,
but
it's
something
for
us
to
to
to
have
in
mind
when,
when
implementing
this
and
rolling
this
out.
B
Yeah
I
great
question
and
great
kind
of
thinking
ahead.
Also
I'm
still
inclined,
especially
for
the
nbc,
to
go
with
the
tier
it's
likely
easier
to
build,
although
we
want
to
you
know,
want
to
work
with
engineering,
to
double
check
that
and
to
it
is
pretty
it's
it's
very.
It's
a
very
strong
signal
of
of
what
how
the
how
the
users
are
using
environments
right.
So
you
know,
if
we're
using
wild
cards,
then
there's
we're
not
exactly
sure
of
how
you
know.
B
B
But
three
I
like
actually
your
last
point,
which
is,
I
think
I
think,
production
tier,
is
a
great
concept
that
we've
built,
and
so
this
kind
of
layers
on
and
makes
it
more
useful,
and
so
I
think,
there's
I
think,
there's
like
a
pull
for
the
user
to
make
there's
more
incentive
for
them
to
use
it,
and
so
I
I
think
that's
a
good
and
I
think
that's
a
good
thing.
Yeah
absolutely
and
we'll
see
yeah.
It
knows
we'll
sort
of.
I
think
one
to
you.
It
also
asks
you
a
question.
B
I
think
we
can
try
to
look
up.
We
should
be
able
to
look
up
what
how
how
widely
the
tier
is,
and
so
is
that
something
you
could
look
into
as
well.
A
Are
some
very
obviously
non-nbc
ideas
here?
Perhaps
you
wanted
to
filter
a
specific
list
of
projects
right
within
within
everything
that
you
have
for
for
easier
consumption,
and
there
were
some
other
ideas
as
well,
but
but
yeah.
I
think
this.
This
will
be
a
very
useful
like
first
pass
at
the
future,
especially
for
very
large
organizations
that
have
hundreds
of
of
projects,
but
I
think
very
quickly
would
get
feedback
asking
for
for
things
like
this
right.
Okay,
this
is
great,
but
it's
too
much.
A
How
do
I
narrow
down
to
what
I
need
right
like
so
so
it
comes
down
to
filtering,
comes
down
to
search,
comes
down
to
favorites.
You
know,
like
sure,
I
want
to
be
able
to
look
at
everything,
but
I
also
want
to
be
able
to
look
at
my
top
five
top
ten
applications
or
projects,
or
whatever
is
so
I'm
trying
to
keep
keep
these
options
on
the
radar.
B
A
Especially
because
this
is
this
is
exactly
how
how
our
boards
view
works,
the
filters
in
here
and
some
additional
stuff.
So
it's
it's
a
common
pattern
pattern
within
gitlab
as
well.
Definitely
all
right.
So
I
will
stop
sharing
the
screen.
A
A
Level
environments
is
the
deep
dive
with
jackie
so
for
context
for
anyone
who's
watching
jackie
porter,
who
was
the
previous
product
manager
for
the
release,
release
management
team.
I
think
it
was
the
name
at
the
time,
a
lot
of
a
lot
of
the
research.
A
Most
of
the
research
that
led
to
this
issue
was
when
she
was
on
the
team,
so
she
offered
us
to
have
a
deep
dive
and
go
over
some
of
the
previous
topics
and
previous
research
that
was
done
to
help
us
understand
it
and
move
forward
which
is
really
nice
of
her.
So
it's
scheduled
for
next
week,
we'll
definitely
record
it
as
well
and
chris,
I
think
it's
as,
as
you
mentioned
it's
worth,
coming
up
with
an
agenda
of
topics
for
what
we'll
discuss.
A
At
the
very
least
what
I
thought
was
starting
to
list
out
the
relevant
like
reading
list
right,
yeah.
What's
the
past
research
in
the
past
strategy
and
issues
and
epics,
they
want
to
bring
up
and
then
and
then
try
to
go
over
those
with
her
and
see
and.
A
What
do
we
want
to
know
from
all
this
best,
research
that
we
don't
know
yet
that
we
haven't
been
able
to
to
coordinate?
That's
the
right
word.
A
A
All
right,
I
can,
I
can
start
listing
this,
but
if
you
don't
mind,
I
would
prefer
for
you
to
to
leave
this
agenda.
If
that's
okay,.
B
Yeah
yeah
yeah
definitely
yeah
sounds
good.
I
can
maybe
yeah
sorry
go
ahead.
A
B
A
Thanks
for
that,
that's
good,
so
review
direction
pages!
It's
not
exactly
within
this
topic,
but
the
category
maturity.
It's
we
discussed
this
recently,
but
just
for
for
context
of
the
recording,
we
have
a
category
maturity
page
on
our
handbook,
this
one
not
not
in
the
handbook,
but
in
the
marketing
pages
and
the
dates
for
plan
category
maturity
for
release,
don't
really
make
a
lot
of
sense.
You
see
their
stuff
that
jumps
straight
to
2023.
A
So
it's
not
really
clear,
at
least
from
you
at
a
first
look.
What
is
the
priority
to
to
raise
maturity
and
that
maps
to
research
efforts
that
will
come
up
in
q1?
So
ask
us
to
look
this
up,
and
so
we
know
for
sure
if
the
focus
is
release,
orchestration
or
environment
management
or
something
else,
and
and
have
us
better
prepared
to
research,
the
right
things
to
evolve
the
maturity.
B
Chris
makes
sense,
yep
and
all
this
is
I
mean
we
were
also
talking
about
this
the
other
day,
but
sort
of
that
that.
A
B
I
did
yeah,
so
I
I
did
notice.
We
got
a
ping
from
lucas
in
the
link.
B
Yeah
sounds
good,
I
think
I
don't
think
I
can.
You
might
have
to
stop
first,
okay,
yeah,
so
we
got
a
thing
from
lucas
on
this
issue.
B
B
Usability
score
issues
next
quarter,
and
so
it
sounds
like
this
is
an
exercise
of
like
triaging,
a
lot
of
across
skit
lab
for
every
group,
all
the
all
the
usability
issues
that
have
been
surfaced,
and
in
the
past
I
guess
recently-
and
so
I
think
the
exercise
here
is
to
look
at
these
for
release
and
oh
and
also
these
are
these
are
in
the
list
because
they
haven't
been
assigned
severity.
So
yeah.
B
I
think
the
exercise
is
to
go
through
these
flag,
which
one
most
importantly
like,
which
ones
are
severity,
one
kind
of
the
most
severe
and
then
just
so
we're
categorizing
them
correctly,
and
then
we
could
also
make
progress
towards
completing
those
items,
and
so
I
think
I
haven't
really
done
this
exercise
before
daniel,
but
I
think
this
will
be
a.
I
don't
know
if
you
have,
but
you
know
I
think
maybe
we
could
do
this
together.
B
We
could
also
do
an
async
as
well,
but
I
think
it's
going
through
the
issues
making
sure
we
understand
what
the
issues
are
assigning
severity
and
then
next
quarter
when
we
start
the
new
quarter,
we'll
try
to
make
a
list
and
prioritize
which
ones
have
the
most
impact
for
for
our
users.
A
So
I
actually
got
the
same
ask
last
week,
so
it
was
a
similar
list
of
of
issues,
but
there
was
some
overlap,
so
some
of
these
have
severity
already
that
that
that
I
added
earlier
this
week
the
tricky
thing-
and
I
don't
know
if,
if
the
the
yeah,
the
handbook
link
is
not
added
so
I'm
gonna
add
here
the
handbook
link
about
issue
triage.
It's
on
the
agenda.
A
Essentially
severity
was
the
severe
labels
were
created
for
bugs
right,
there's
some
leeway
as
to
what
bugs
mean,
but
essentially
everything
that
is
a
bug
that
has
to
be
fixed
rather
than
an
improvement
that
could
be
done,
needs
to
have
a
severity
to
determine
the
slo
like
how
how
how
fast
it
has
to
be
fixed.
But
my
understanding
is
that
the
severity
labels
are
really
useful
for
exactly
tracking
how
fast
things
should
be
done,
so
they
are
starting
to
be
added.
A
In
almost
everything
from
the
design
side,
we
were
asked
to
add
severity
for
everything
that
had
a
list
of
labels
that
were
related
to
sus
yeah.
So
it's
it's
more
or
less
the
same
as
here
as
well,
and
a
lot
of
these
issues
are
not
bugs
at
all
they're
they're,
not
something
that's
broken,
they're,
just
improvements
like
add
a
functionality
and
a
new
capability.
A
So
it
was
tricky
to
to
determine
what
is
the
severity
of
a
new
issue
of
a
new
feature
right
because
we
don't
we
don't
have
it
yet
so
is.
Is
it
depending
on
the
impact
on
how
many
customers
are
asking
for
it?
So
this
was
discussed
in
the
ux
weekly
meeting
this
week.
A
So
and
essentially,
what
was
said
was
you
know,
rule
of
thumb
add
a
severity
form
for
a
new
issue,
but
but
that
can
change.
So
I
opened
nmr
to
add
this
guidance
and
there's
some
discussion
on
this,
so
this
page
that
I
added
soon
will
be
updated
with
with
more
specific
info
on
how
to
label
new
features
with
a
severity.
But
as
far
as
I
know
so,
for
now
like
just
adds
a
battery
for
that's
what
I
did.
I
I
had
it
for
most
of
them,
some
of
them
that
seemed
more
important.
B
Okay
sounds
good
looks.
This
is
awesome
that
you
took
the
initiative
to
create
this,
mr
because
yeah
upon,
like
the
first
review,
you
know
I
wasn't
sure
exactly
how
to
assign
you
know
think
about
like.
What's
what
what
should
the
criteria
be?
So
I'm
glad
to
see
that
we're
thinking
about
that
and
hopefully
we'll
have
some
more
more
of
a
perspective
as
well,
but
yeah.
It
sounds
good.
I
like
the
initial
approach
of
like
marking
sort
of
new
features,
the
things
that
aren't
really
broken
yet
right.
B
I
don't
think
I
don't
think
those
are
in
general.
I
don't
think
those
are
severe
issues,
so
we
could
mark
them
as
such
too.
B
B
A
Would
say
is
just
go
over
the
list
and
add
whatever
severity
you
think
is
relevant,
given
the
guidance
that
we
have
and
and
where
we
don't
have
a
guidance
just
just
go
to
whatever
you
think
makes
sense,
and
then
for
these
and
for
others,
where
you're,
not
sure
you
feel
free
to
tag
me
and
we'll
see
together,
exercise
like
most
of
them,
at
least
from
from
my
from
my
evaluation.
It
was.
A
It
was
easy
to
see
like
if,
if
something
was
very
three
or
four,
but
if
you're,
if
you're
in
doubt
about
any
of
them.
Let
me
know.
A
B
Okay
and
the
last
one
really
quickly
is
yeah
just
flagging
to
you
we're
in
the
new
milestone.
Now,
if
there's
anything
in
particular
that
we're
that
you
know
we
want
the
engineering
team
to
research
feel
free
to
just
add
it
to
the
needs
weight
issue
and
the
engineers
will
we'll
take
a
look.
A
Yeah,
I
think
the
I'll
take
a
look,
but
I
think
everything
that
that
should
be
looked
at.
I
already
added
to
the
to
the
planning
issue.
They
did.
This
needs
weight
issue.
They
essentially
pick
up
the
the
issues
from
the
planning
they're
assigned
to
them
and
then
and
then
go
over
the
weight
for
each
one
of
them
right.
B
Yeah,
it's
sort
of
like
another.
It's
like
part
of
the
plan,
my
milestone
planning.
I
think
it's
it's
things
that
are
likely
going
to
be
worked
on
next
milestone
or
even
beyond
that,
ideally,
and
so
it's
sort
of
like
trying
to
keep
the
train
moving
and
making
sure
those
things
things
that
we
want
to
work
on.
Next
milestone
are
ready
for
development
weighted,
and
you
know
all.
B
Yes,
sorry
yeah,
that
that
that's
that's
that's
the
intent,
yeah
yeah!
It
was
like
they,
so
it's!
These
are
the
issues
that
they'll
research
in
14
8,
but
we'll
schedule,
49,
14,
10
beyond
yeah.
A
Yeah,
no,
that
makes
perfect
sense,
I'm
actually
planning
to
to
start
looking
into
49
tomorrow.
So
that's
that's
a
good
time.
Yeah
I'll
try
to
match
the
list
of
whatever
I
think
should
be
worked
on
on
49
with
what
they're
waiting
whatever
is
missing,
sounds
good
and
yeah.
Perfect.