►
From YouTube: Release Group Product & UX Sync • 2022-02-03
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
So
this
is
a
little
bit
out
of
order,
because
today
we
had
the
first
release
from
brainstorm,
which
might
sound
a
little
bit
odd
in
terms
of
gitlab,
since
we
weren't
async
so
much
but
chris
and
I
were
feeling
like
we
wanted
to
have
a
little
bit
more
sync
feedback
from
our
from
our
developers
and
from
from
from
the
team
as
a
whole.
So
it
created
this
optional
meeting
for
anyone
to
attend
and
we
had
great
attendance.
A
A
few
of
our
developers
came
and
it
was
great
like
we
went
over,
we
did
a
ux
review
of
our
deployment.
Approval
feature
that
it
is
a
tricky
feature
because
it
spans
multiple
points
of
touch
across
gitlab,
multiple
uis.
So
for
me,
as
a
designer,
it's
it's
taking
a
lot
of
work
to
make
sure
nothing
slips
and
it's
a
very
broken
workflow
they're,
bringing
together
into
one.
A
So
we
went
over
all
of
the
steps
you
can
see
the
video
as
well,
we
posted
soon,
but
we
got
really
good
feedback
on
what's
already
happening,
some
some
in-depth
feedback
on
an
issue
that
isn't
growing
and
then
bring
some
future
ideas
as
chris
is
adding
here,
and
it
was
fantastic,
so
I'm
excited
for
the
next
ones.
But
what
did
you
think
chris,
I
think,
was
good.
B
Yeah
thanks
daniel
yeah
great
and
you
did
a
great
job
facilitating.
So
thank
you
for
being
the
first
one
to
do
that
for
the
for
these
sessions,
yeah
totally
agree
great
great
discussion.
We
ran
at
a
time
which
is
always
a
good
sign
in
terms
of
for
brainstorming
and
so
and
as
daniel
was
saying,
definitely
not
meant
to
replace
the
async
work
that
we
do
as
a
team
and
collaborate
on
our
issues.
B
Our
team
is
already
really
really
really
good
at
that,
but
meant
to
supplement
and
also
just
have
another
opportunity
for
the
team
to
get
together,
because
right
now
we
only
have
sort
of
once
a
week
meetings
and
so
yeah
we
went
really
well.
I
think
we've
got
some
positive
feedback
on
the
team.
At
the
end
of
the.
A
B
A
Yeah,
I
think
40
minutes
might
be
the
sweet
spot
and
then,
if
we
use
class,
that's
fine,
yeah,
40.,
yeah,
cool
and
yeah.
It's
interesting
because
our
work
and
our
communication
here
at
gitlab
is
so
structured
that
sometimes
during
discussions,
I'll
re
on
on
issues
or
merge
requests
I'll
refrain
from
from
from
adding
too
many
ideas,
because
I
don't
want
to
derail
the
conversation
and
then
some
of
these
ideas
end
up
getting
lost
right.
I
forget
about
them
or
they're,
not
documented
elsewhere.
A
So
having
a
less
structured
conversation
when
everything
is
so
structured,
I
think
actually
opens
up
more
space
for
for
a
different
kind
of
collaboration.
That
is,
that
is
also
valuable
and
that
that
that
happened
exactly
towards
the
end
of
the
meeting
and
started
discussing
like
a
a
more
upfront
idea
for
for
a
new
feature
that
we
don't
really
know
what
it's
going
to
look
like.
We
don't
know
exactly
what
the
scope
is
going
to
be,
but
you
know
everyone
has
an
opinion
on
it,
and
this
conversation
is
exactly
about
this.
A
A
A
On
your
recent
comment
for
us
to
deprioritize
our
category
materials
scorecard,
with
which
I
agree
when
I
don't
think
we're
in
a
great
position
to
to
do
this
kind
of
evaluation
in
our
product
and
and
the
link
to
your
comment
is
there,
so
this
was
a
huge,
huge
weight
on
the
next
milestone
right.
It
was
quite
some
bit
of
time,
so
it
opened
up
space
to
to
other
issues
that
were
important
as
well.
A
A
It's
not
that
packed
in
terms
of
capacity.
16
points
is
fine,
but
it's
a
lot
of
small
to
medium
issues,
but
I'm
actually
excited
about
that.
Because
then
that
means
there
will
be
a
lot
of
progress
on
different
fronts.
The
the
main
issue,
the
central
issue
that
I
added
here
in
terms
of
team
right
connecting
releases
and
environments-
is
this
first
one
part
of
the
job
here
it
is
to
scope
the
issue
and
potentially
separate
it
into
smaller
ones.
A
So
I
haven't
had
the
time
to
properly
dive
into
this.
Yet
that's
why
part
of
the
the
goal
here
is
to
to
dive
into
the
issue
and
explore
it?
Not
necessarily
have
it
design
ready
right,
so
this
might
break
into
smaller
issues.
We
might
need
to
start
some
problem
validation
on
this.
The
issue
itself
is
on
problem
validation.
A
B
Yeah
sounds
good
daniel.
Thank
you
for
that
overview.
Actually,
since
you're
still
seeing
the
screen
yeah
I'd
like
to
just
do
a
quick
walkthrough
of
the
what
we
have
right
now,
this
isn't
final
yet,
but
we're
working
on
what
our
engineering
team
will
be
working
on
for
14.9
and
so
just
a
quick
overview.
You'll
see
a
lot
of
feature
direction,
direction,
feature
work
which
I'm
really
excited
about.
So
one
thing
that
we're
working
on
is
we're
continuing
to
redesign
our
environments
pages
and
deployments
pages.
B
A
Chris,
let's
see
one
comment
about
this
one.
I
actually
think
this
should
be
down
there
in
ux,
because
it's
workflow
design,
yeah
the
the
ui
for
this
is
mostly
done
because
we
reuse
the
ui
blocks
that
we
are.
We
are
developing
for
the
environments
page,
but
there
might
be
one
one
adjustment
or
another.
A
B
Sounds
good
yeah
thanks
for
the
call
out
yeah.
I
think
I
I
sort
of
figured
that,
but
thanks
for
kind
of
calling
out
that
yeah,
it's
still
ready
or
sorry,
it's
still
a
workflow
design
so
but
yeah.
Ideally,
I
think
that
it
makes
sense
to
me
in
terms
of
just
general
priorities,
andrew
we're
excited
that
andrew's,
finishing
and
shipping
the
environments
redesigned
for
the
sort
of
the
high,
the
top
level
environments
page.
This
milestone
and
kind
of
a
you
know.
B
Yeah
the
next
you'll
see
the
next
few
are
additional
direction
features.
Similarly,
we've
been
talking
about
to
do's,
but
this
milestone
we're
also
working
on
the
deployment
api
and
the
deployment
approval,
ui,
mvc,
and
so
the
next
kind
of
in
the
next
order.
One
of
the
things
is
also.
We
want
to
provide
the
ability
to
do
notifications
for
users
to
make
sure
that
they're
aware
of
the
approvals
so
daniel's
showing
the
mock-up
here.
Something
like
this.
A
B
Make
sense
first
yeah
it
makes
sense,
yeah,
yeah
and
then
the
rest
of
the
issues.
You
can
see
there
again
kind
of
a
mix
of
sort
of
feature
work,
but
balancing
some
of
the
maintenance
and
security
work
that
we
want
to
do
for
our
features,
the
other,
the
other
one
is.
The
kind
of
call
out
at
the
moment
is
aggregating
counts
for
deployment.
B
So
alan
and
ali
have
started
work
on
improving
our
instrumentation,
which
is
very
important
for
our
kind
of
metrics
and
and
telemetry
and
tracking
feature
usage.
So
we'll
be
continuing
that
work
in
this
milestone
as
well
yeah.
So
yeah
still
in
draft
we're
going
to
make
a
few
tweaks
over
the
next
few
days,
get
these
ready
for
dev
and
then
and
then
we'll
have
our
milestone
plan.
B
B
Yeah
I
for
the
planning
issue.
I
use
it
to
call
out,
or
I
started,
to
use,
to
call
out
specific
issues
that
are
tied
to
features
that
are
part
of
our
vision,
part
of
our
major.
They
have
vision
direction
and
I
think
it's
useful
it's
useful
to
include
that
in
the
planning
issue
for
me,
because
I
kind
of
could
get
a
sense
of
like
well
this
milestone.
B
B
We
have
certain
filters
on
maybe
our
direction
pages
and
even
our
kind
of
public-facing
marketing
sort
of
roadmap
pages
that
automatically
highlight
those
specific
issues
for
our
users
for
our
customers
and
community.
So
I
think
when
we,
if
we
mark
certain
issues,
you
know
specific
issues
as
direction.
They'll
show
up
in
those
types
of
places,
so
I
think
we've
built
sort
of
a
system
for
highlighting
those
for
for
outside
communication.
A
B
Exactly
yeah
and
you'll,
you
know
you'll,
you
would
notice,
you
know
if
you
kind
of
look
at
like
the
past
three,
maybe
five
milestones,
not
a
lot
of
direction.
Work
well,
sorry
direction
work,
but
also
a
lot
of
security,
security,
reliability,
and
so
this,
I
think,
we're
sort
of
like
getting
past
a
lot
of
that
work
with
the
great
work
the
team
has
been
doing,
and
you
know
focusing
on
some
of
the
road
map
that
we
want
to
that.
We
want
to
execute
on.
A
We
are
getting
close
to
time
so
I'll
unless
you
have
something
specific
in
mind,
I'll
I'll
speak
very
quickly
on
on
the
design.
I
recently
finished
this
display
environment
here
on
the
environments
page.
It
was
a
quick
one,
essentially
updating
the
the
layout
for
this
issue
from
from
the
previous
environments
page
to
the
new
one.
So
what
that
means
is
just
adding
a
tier
badge
on
the
environment
card
right
here.
A
So
you
know
I
try
to
highlight
what
is
the
use
case
for
the
tiers
right
when
you
have
like
automatically
generated
names,
they
are
not
very
readable,
so
you
use
the
tiers
to
help
signify
what
is
production
or
staging
when
it's
testing.
So
I
think
that
works.
It's
a
short
one,
then,
as
this
as
we
discussed
quite
a
bit
on
the
on
the
brainstorm
updating
project
settings
to
set
approval
accounts
for
deployment
approvals.
A
So
that's
on
the
board
almost
being
wrapped
and
then
my
next
one
to
be
picked
up
is
either
this
one
or
this
one.
I
think,
will
be
this
one
at
the
bottom,
because
it's
more
related
to
approvals,
but
it's
essentially
reflecting
the
new
capabilities
of
approval
on
the
pipeline
interfaces
as
well,
because
right
now
all
we
have
is
the
play
button
that
approves,
but
we
need
to
have
the
proper
interface
to
either
approve
or
reject
from
the
pipeline
as
well.
A
A
B
Nothing
specifically,
I
think
what
I'll
do
in
the
next
day,
or
so
is
just
make
sure
that
we
can
I've
been
using
this
to
pull
in
work
for
into
you
know
the
design
work
for
the
milestone
that
you
and
I
will
collaborating
on,
but
also
for
engineering,
so
yeah
yeah.
I
think
I'm
good
on
this
one
all
right.
A
B
B
The
scenario
is
listed
here,
but
I
wanted
to
capture
that
in
an
issue,
so
we
could
figure
out
what
our
potential
solutions
could
be,
but
this
happened
recently,
and
so
I
imagine
if
we
have
sort
of
pipelines
that
are
using
manual
jobs,
some
of
our
skip,
outdated
deployments
functionality,
don't
might
not
work
as
expected,
and
so
what
happens
is
what
happened
here.
Is
that
an
an
older
job
overwrote?
What
was
in
production,
which
was
not
the
desired
effect?
B
B
Let's
see,
oh,
it
looks
like
some
error
messages,
popped
up
and
the
ability
to
use
certain
keywords,
weren't
working,
so
something
we'll
take
a
look
at.
I
think
the
first
iteration
that
we
did
is
actually
just
corrected
the
the
the
documentation,
but
that
makes
sense.
But
since
it's
not
working,
we'll
also
want
to
take
a
look
at
this
scene.
B
B
Okay
and
then
this
one
looks
like
ability
to
add
multiple
branches:
oh
operations,
dashboard,
which
the
release
stage
group
does
own
at
the
moment.
So
I
think
it
looks
like
a
feature
request
from
a
customer
to
be
able
to
you
have
a
view
in
the
operations
dashboard
to
see
different
branches
right
now
it
looks
like
I
think
we
only
include
main
or
default,
so
this
is
a
way
to
extend
that
functionality,
yeah
cool
and
then
okay,
let's
allow
skip
to
create
state
transitions,
deployment,
jobs
so
yeah.
B
We'll
take
a
closer
look
at
this
as
well,
but
exciting
to
see
a
lot
of
these
sort
of
custom
requests
come
through
as
always:
let's
let's
review
them.
Maybe
we
can
do
that
async,
I
haven't
even
taking
a
close
look
at
them,
so
maybe
daniel
and
I
in
the
next
week
we
can
take
a
look
to
quickly
triage
and
then
determine
how
we
want
to
prioritize
and
proceed.
A
B
No,
the
the
links
are
here.
I
also
shared
them
with
our
team
in
our
slack
channel
and
they're
also
available
in
gitlab.
So
I
mean
they
highlight
our
we.
I
did
an
exercise
of
reviewing
our
direction
pages
for
our
specific
categories,
adding
vision,
sections
for
each
one
of
them,
and
so
it's
kind
of
exciting
to
just
think
about.
Well,
what
are
the
future
of
these
categories
and
how
do
we
align?
How
do
we
align
the
work
we're
doing
and
so
from
there
like?
What
other?
A
It
out
yeah,
I
I
commented
on
a
couple
of
those,
but
there
were
so
many
that
I
couldn't
keep
up.
I
love
seeing
this
work
coming
out.
Thank
you
so
much
for
this
and
for
me
seeing
seeing
this
work,
especially
for
the
for
the
categories.
We're
not
focusing
so
much
on
like
future
flags
or
advanced
deployments,
really
helps
spark
new
ideas
for
hey.
A
Yeah,
so
my
last
point
on
research
needs
is
actually
bringing
back
to
to
the
very
top.
When
I
mentioned
our
decision
to
de-prioritize
the
category
much
movie
scorecard
will
our
researcher
for
for
ops
and
and
enablement
yeah
absent
enablement.
I
think
he,
as
part
of
the
research
group,
has
been
doing
a
longer
term
planning
of
his
research
capacity,
and
we
we
had
the
cm
scorecards
on
this
capacity
for
a
while,
but
it
took
us
some
time
to
be
able
to
de-prioritize
it.
B
Yeah
definitely
agree,
I
think,
we'll
we'll
definitely
get
there.
I
I
I
I
as
well
have
been
focused
sort
of
on
the
more
short
term.
We
have
a
lot
of
you
know
we
had
a
good
sort
of
tangent,
but
we
had
a
good
session
with
tyanna
and
jackie
yesterday
discussing
what's
already
been
validated
and
researched
and
ready
to
go.
So
I
think
sort
of
we
want
to
focus
on
that
and
make
sure
the
team
has
is
set
up
for
success
there.
B
But
then
I
think
after
that,
we'll
we'll
then
be
able
to
think
a
little
bit
more
ahead
and,
and
then
part
of
that
is
also
like
researching
working
with
will
and
researching
on
kind
of
future
needs
that
we
haven't.
Even
I
know
we
don't
even
know
about
yet,
but
yeah,
that's
a
that's
a
good
call
out.
We
definitely
want
to
be
efficient
with
this
time
and
because
he
also
covers
a
lot
of
ground,
and
so
we
want
to
make
sure
that
we
don't.
You
know
we
don't
waste
time
too.
So.