►
From YouTube: Release Group Product & UX Weekly - 2021-05-27
Description
Daniel Fosco (Senior Product Designer), Rayana Verissimo (Product Design Manager), and Kevin Chu (Group Product Manager) discuss strategy and ongoing milestone work for the Release Group.
A
There
we
go
all
right:
okay,
hi
everyone.
This
is
the
the
ux
product
meeting
for
release
and
today
we're
going
to
talk
a
little
bit
about
our
strategy,
update
as
similar
to
what
we
discussed
last
week
on
kind
of
prioritization,
and
last
week
we
talked
about
how
important
things
like
fixing
your
environments
are.
A
So,
in
the
background,
I've
been
doing
a
bunch
of
customer
interviews
looking
at
a
road
map
to
see
what
makes
sense
and
my
my
conclusion,
if
there
is
such
a
thing,
is
that
it's
obvious
that
release
is
a
really
really
important
stage
for
gitlab
customers,
especially
large
customers
are
able
to
adopt,
obviously
our
source
code
management
in
our
ci
and
often
our
security
features,
and
they
would
love
to.
They
actually
would
love
to
adopt
our
release
features,
but
our
release
features
are
simply
not.
A
They
can
adopt
continuous
delivery
via
gitlab,
as
it
is
without
a
problem.
The
real
problem
is
for
many
of
our
larger
users.
They
are
blocked
from
adopting
are
more
kind
of,
I
guess
advanced
features
in
being
released
because
there's
they
have
more
fundamental
problems
that
they
haven't
solved
yet
such
as
coordinating
a
complicated
release
working
with
a
lot
of
people
having
prioritizations
of
release.
A
All
of
this
point
to
the
importance
of
release,
orchestration
and
release
orchestration
to
me
is
also
very
highly
related
to
both
environments
and
secrets,
management
or
deploy
keys
and
things
of
that
nature.
So
in
this,
I've
linked
a
merge
request
in
our
agenda,
as
well
as
a
follow-up
issue
that
talks
about
the
alignment
between
groups
and
categories
and
daniel.
You
had
a
you,
had
a
thought:
can
you
voice
over
it.
A
A
A
A
A
But
the
reality
is
that's
really
hard
to
do,
because
yamo
is
not
really
extensible,
it
can
get
really
complicated
and
there's
we
don't
provide
any
tooling
to
manage
any
of
those
type
of
things.
So
platform
environments
has
to
do
with
that
set
of
problems
and
the
other
takeaway
is
like.
Where
are
we
going
to
be
focused,
we're
going
to
be
focused
on
kubernetes
management?
A
That's
nothing
new!
We
are
going
to
be
focused
on
release
orchestration,
which
is
new.
As
far
as
this
page
goes,
but
it
goes
in
line
with
what
we
were
talking
about
before
infrastructure,
as
code
goes
hand-in-hand
with
kubernetes
management
still
really
important
and
then,
lastly,
being
able
to
measure
success,
kind
of
our
investment
in
dora
management
continues
to
be
super
important,
and
so
this
is
going
to
be
our
focus
area.
A
Whereas
before
we
talk
about
focusing
on
cd,
focusing
on
progressive
delivery,
if
we
have
more
resources,
they
might
be
a
focus
area.
But
even
if
we
expand
the
team
today,
I
do.
I
think
that
would
be
too
much
and
I'd
rather
have
the
teams
be
focused
on
one
and
at
most
two
categories
at
most
at
in
any
given
time,
and
that
will
be
hopefully
our
kind
of
folk
of
war
or
how
we
implement
and
build
stuff
going
forward.
B
Thanks
for
that
kevin
you,
you
actually
responded.
My
my
first
question
partially
on
how
we
plan
to
to
break
down
that
this
conversation
and
prioritize
investment.
With
that
said,
two
questions
about
two
of
the
of
the
directions
you
appointed
the
first
one
kubernetes
management.
Today
it
has
a
lot
of
overlap.
We
can
figure
right.
How
do
we
plan
to
to
break
this
down.
A
So
when
I'm
talking
about
deployment,
one
thing
that's
important
is
a
basic
premise
of
why
we
created
this
new
direction.
Page
is
the
fact
that
the
line
between
configure
and
release
is
blurred
right.
So
I
am
when
I
talk
about
kubernetes
management.
I'm
not
referring
to
this
is
like
something
release
needs
to
work
on
I'm
just
pointing
out.
This
is
something
that
we
as
gitlab
need
to
work
on.
C
B
Organization,
this
is
where
your
services
live,
or
this
is
how
you
do
service
discovery
or
how
you
measure
service
health,
and
I
wonder
how
much
to
to
which
extent
we
should
make
an
effort
to
map
our
product
offerings
to
these
concepts
that
users
have
that
customers
have,
because,
of
course,
you
can
have
your
services
in
gitlab
right.
You
can
have
one
project
or
services,
or
maybe
you
know
a
bunch
of
services
in
a
monorepo
in
one
project,
but
we
don't
necessarily
make
that
clear.
B
We
don't
make
the
happy
path
for
that
clear
and
I've
seen
feedbacks
before
to
the
lineup.
Oh
gitlab
wants
me
to
do
things
on
the
gitlab
way.
Right,
which
can
be
useful,
can
be
depending
on
the
case
the
best
way.
But
then
I
wonder
what
is
the
sweet
spot
that
we
can
find
where
we
can
shape
the
product
to
to
the
use
case
that
the
users
have
also
taking
advantage
of
the
good
stuff
that
we
already
offer.
A
A
We
can't
drive
usage
and
adoption
of
our
features
as
a
result
and
a
prime
example
this
before
we
even
talk
about
services
is
when
we
think
about
door
metrics
right
now.
We
have
it
at
the
group
and
project
level,
which
is
great.
But
let's
say
you
have
you're
measuring
thorough
metric
for
a
project
that
exists.
That's
working
well
that
a
team
is
responsible
for,
but
that's
that
they're
not
working
on
it,
because
it's
built
it's
ready,
then
all
of
a
sudden,
your
door
metrics,
look
terrible.
A
What
you're
doing
there
is
incentivizing
teams
to
game
the
system
to
work
on
something
that's
not
necessary.
So,
as
I've
talked
to
customers,
many
have
pointed
out
how
we
draw
circles.
The
most
important
circle
is
the
concept
of
a
team,
but
the
team
does
not
map
cleanly
necessarily
to
a
group
or
a
project
you
can.
A
But
that's
not
how
they
set
it
up
in
the
beginning.
So
therefore,
like
two
they're,
not
gonna,
like
jump
through
all
sorts
of
hoops
to
redo
all
these
admin
setup,
which
is
a
problem
and
services,
perhaps
it's
a
it's
on
a
different
axis
altogether,
but
it's
another
one
of
those
things.
It's
it's
like
a
concept
that
exists
in
people's
minds
and
we
see
prod
projects
like
backstage
io
and
there's
actually
a
bunch
of
sas
offerings
out
there
too.
That
kind
of
looks
at
this
problem
like
it's
a
it's
a
it's.
A
It's
a
core
concept
of
people's
work.
People
align
like
instant
response
around
the
concept
of
the
service
people
align
metrics
and
health
around
the
concept
of
service
and
the
service
is
meant
to
be
a
reusable
component
and
when
you
get
really
large
becomes,
and
you
have
a
backlog
of
many
services,
he
becomes
something
that
needs
to
be
scaled
and
managed
in
some
fashion.
A
I
certainly
believe
there
is
opportunity
for
us
to
kind
of
jump
into
this
space
as
well,
but
that
said,
like,
I
think,
at
least
for
for
my
viewpoint-
is
that
more
important
than
say
enabling
enterprises
to
work
on
releases
be
a
gitlab.
I
don't
think
so,
because
I
think
that's
a
problem.
That's
we
really
solve
right
away,
whereas
service,
how
we
solve
that
feels
more
nebulous.
A
Perhaps
if
we
start
to
do
some
research
around
this
topic
will
change
our
mind,
but
today
you
just
feel
I
feel
unsure
about
it,
and
another
approach
could
simply
be
backstage
is
an
open
source
project.
We
can
take
it
plug
it
in
and
offer
it
as
a
service.
Is
that
a
possibility?
I
think
it
could
be
it's
something
that's
worth
exploring
in
my
opinion,
but
I
don't.
B
A
A
Awesome
we
can
move
on.
Another
thing
I
want
to
mention
is
you
know,
we've
been
talking
a
lot
about
environments
and
I've
been
hearing
a
different
perspective
from
from
specifically
victor,
and
I
love
for
us
still
get
together
and
talk
about
it
together
in
a
think,
big
section
on
june
10th,
so
I'm
going
to
propose
environments
to
be
the
topic
we
we
get
to
in
a
few
days.
C
C
A
A
Probably
early
next
week
on
this
topic,
14-1
nicole,
has
been
helping
me
she's,
been
starting
to
as
far
as
the
work
to
be
done,
she's
been
starting
to
move
things,
move
bugs
and
and
these
performance
issues
into
either
into
this
issue
or
taking
them
with
the
milestone
or
adding
release
or
or
candidate
14-1
candidate
labels
to
a
bunch
of
different
issues.
So
at
some
time
next
week
I'm
gonna
start
to
populate
this
issue
as
well,
though
I
haven't
had
a
chance
to
do
it.
B
So
from
the
design
side
on
fartino,
I
finished
working
on
the
smaller
issue
that
I
had
today
waiting
for
some
feedback,
but
it's
mostly
a
copy
issue,
so
I
think
you'll
be
able
to
move
forward
fairly
well.
It
is
also
scheduled
for
front-end
for
40-0,
so
it's
good
that
I
already
finished
it
in
case
nathan
was
about
to
start
working
on
it.
B
A
B
I'll
share
the
link
on
the
on
the
zoom
shot,
so
we
can
take
a
look
quickly.
Okay,
let's
just
add
it
on
the
agenda
as
well,
but
to
be
honest,
I
I
only
use
this
formal
definition
starting
on
41..
So
it's
where
you
can
see.
I
have
a
much
much
higher
weight,
but
also
because
141
is
a
bit
more.
How
can
I
say
daring
for
me
to
see
in
terms
of
capacity
but
yeah?
B
Essentially,
a
weight
of
one
is
a
really
small
thing
that
should
take
a
couple
of
hours
and
doesn't
take
a
lot
of
feedback.
Then
a
weight
of
two
you
know
requires
a
little
bit
of
more
work.
It's
a
bit.
How
can
I
say
arbitrary,
but
it's
a
good
guard
rail
to
define
how
how
big
of
a
design
work
you're
going
to
do.
B
B
B
On
this
topic,
I
also,
I
think,
both
of
you
on
on
an
iteration
that
hannah
suggested
me.
I
added
to
to
right
underneath
the
design,
the
design
backlog
of
the
milestones
a
table
for
the
ongoing
design
work,
essentially
making
it
clear
that
70
of
my
time
is
focused
on
milestone,
work
on
issues
and
design,
issues
that
are
assigned
to
me
and
then
the
other
10
and
20
percent
are
either
for
higher
higher
level
strategic
stuff
for
for
release
and
also
within
the
design
community.
A
But,
to
be
honest,
that's
sometimes
it's
really
hard
to
get
sucked
into
your
job,
but
anyway
that's
that's.
This
is
my
ideal
plan
for
this
quarter
and,
unfortunately,
for
me
it's
I
don't
know
if
it's
110.
This
feels
probably
more
like
150
percent
these
days,
but
anyway,
we'll
get
through
it.
Thanks
for
sharing
yeah
before
I
let
you
go,
I
I
asked
this
question
before.
A
A
A
I
want
to
give
you
ask
that
question
again
see
if
you
change
your
mind.
The
way
we've
been
doing
a
monitor
is
emilia
and
crystal
the
hiring
manager
team
up
on
a
on
a
single
session
of
interview.
So
you
know,
because
the
questions
I
think
can
be
very
similar
from
because
at
the
end
of
the
day,
it's
like
how
do
we
partner
with
this
person?
Is
this
partnership
going
to
be
successful?
A
B
Part
of
my
expectations
as
a
senior
designer
I
was
just
wrapping
up
the
final
final
pieces
of
onboarding
training.
So
next
stop
in
line
for
me
is
interview
training.
So
hopefully
I
can
do
that
next
week
and
estimate
that
that's
that
I
think
part
of
the
training
is
to
start
shadowing
interviews
anyway,
right
diana.
C
Yeah
but
then
these
are
la
peer
interviews,
so
I
really
appreciate
having
you
bringing
this
topic
was
the
back
of
my
head
thanks,
thank
god!
You're
here
you
you
touch
base
on
this.
I
would
love
daniel
if
daniel
could
join
off
in
these
interviews
same
for
vtk
and
nadia
in
verify
right.
We
are
also
hiring
a
pm
with
ci,
so
danielle.
You
would
need
to
have
that
interview
training,
at
least
to
finish
the
shadowing
part.
I
would
say
before
that,
but
kevin.
C
A
C
C
Okay,
as
long
as
danielle
didn't
finish,
the
the
training,
the
interview
training
process.
Yes,
if
we
had
finished,
I
would
be
comfortable
with
him
being
there
by
himself,
and
we
also
have
to
outline
on
the
questions
I'm
working
with
with
jackie
in
those,
but
now
that
you're
minding
me
that
you're
also
hiring
I'm
going
to
open
an
mr
and
helping
you
to
also
give
feedback
on
the
ux
questions
for
this
interview.
So
we
can
have
everything
in
in
greenhouse
standardized
for
everybody.