►
From YouTube: Release Group Product & UX Weekly - 2021-06-24
Description
Daniel Fosco (Senior Product Designer) and Kevin Chu (Group Product Manager) discuss strategy and ongoing milestone work for the Release Group.
Agenda (internal): https://docs.google.com/document/d/1Enn_E0guWmRBpi_sl_0Kw0p7K8QQNF6SbXliGvMwvxI/edit#
A
A
I
I
don't
have
a
lot
on
on
the
current
current
milestone
work
that
you're,
not
aware
of,
I
think
I
focus
last
week
in
the
beginning
of
this
week
on
on
a
couple
of
merge,
requests
for
for
front
end
on
environments,
happy
to
be
contributing
to
the
front
end
and
git
lab
small
issues.
But
but
you
know
it's
good
to
unlock
our
developers
to
work
on
the
the
bigger
stuff
I'll
add
some
links
on
the
edge
end
as
well.
A
A
B
A
B
B
A
And
these
were
small
things
like
here:
you
can
see
like
the
the
environments.
Widget
is
poorly
aligned
with
this
text,
so
that
was
fixed
and
here
no
it's
not
this
one
yeah
here
there
was
a
misalignment
between
the
buttons,
it's
tiny
things,
but
it's
it's
ui
ui
polish
and
it
was
listed
as
as
not
exactly
sus.
There
is
a
kr
specifically
for
improving
the
merge
request
experience,
so
they
annotated
all
the
little
bugs
in
the
merge
request
page
and
then
divided
them
by
the
relevant
groups.
A
Since
this
is
related
to
to
review
apps
and
deployment,
this
fall
to
us
and
it
was
a
quick
fix.
I
I
took
longer
setting
up
the
whole
environment
than
doing
these,
but
then,
since
I
already
had
my
my
my
development
environment
set
up,
then
I
decided
to
pick
this
one
from
the
environments
page
which
which
looked
really
broken,
and
it
was
literally
one
class
that
had
to
be
changed.
So
I
was
happy
to
fix
that,
and
now
it
looks
much
better.
B
Very
cool
yeah,
so
I
I
would
love
your
help
in
setting
up
get
pod
to
work
with
me
too.
I
I've
tried
it
before,
but
I
failed
and
then
that's
what
these
things
go,
because
it's
not
a
priority
for
me.
I
yeah
it's
never
got
it
going,
but
I
would
love
to
contribute
to
things
like
this
as
well,
because,
like
there's
literally
millions
of.
A
A
Yeah
correcting
correcting
the
the
commit
messages
and
then
in
this
and
this
this
one
specifically,
it
was
a
very
simple
changing
a
class
from
like
section
10
to
section
100,
so
this
took
100
of
the
width,
so
it
wasn't
broken
anymore,
but
I
had
to
change
this
in
the
vue.js
templates,
which
I
had
a
little
experience
with.
So
I
changed,
but
then
one
of
the
developers
who
did
the
the
review
said.
Oh
these
changes,
you
didn't
are
really
nice.
Do
you
mind?
A
You
know
adding
another
test
here
and
doing
this
other
change
and
separating
this
into
a
function,
and
my
reaction
was
like.
Oh
no,
I'm
a
fraud,
I'm
a
designer,
but
I
asked
for
help
for
for
the
folks
from
the
team
and
they
they
jumped
in
really
quickly
and
helped
wrap
it
up.
And
then,
after
that,
I
had
to
go
into
staging
server
to
make
sure
everything
was
working
fine.
So
it
was
nice.
B
A
B
A
A
Yeah
yeah
that
works
as
well.
Okay,
cool,
sweet,
let
me
so
on,
so
that
that
was
wrapped
up
earlier
this
week.
After
that,
I
was
between
pm,
hiring
and
and
trying
to
to
work
up
some
strategy
based
on
all
the
research
we
already
have.
After
the
the
think,
big
session
we
recently
had
and
to
be
honest,
this
is
something
somewhere,
I'm
struggling
with
a
little
bit.
A
B
A
To
do
is:
go
over
the
the
opportunity
canvases
we
have
for
for
release
management
and
for
environments
and
then
extract
specific
problem
statements
from
there
right
and
then
from
those
problem.
Statements
try
to
focus
on
okay.
How
do
we
turn
this
into
designs
that
work
for
environments
at
a
group
level
or
for
different
ways
to
to
manage
environments?
The
discussions
that
we're
currently
having.
A
B
Frankly,
I
I
don't
know
if
I
I
don't
know
if
I
agree
with
all
so.
For
example,
like
we
talk
about
group
level,
environments
right,
should
it
actually
be
a
group?
That's
what
we
right,
but
it's
that
group
group
has
lots
of
assumptions.
For
example,
it
assumes
that
people
set
groups
up
in
the
way
we
expect
them
to,
but
it's
completely
open
and
also
groups,
don't
necessarily
map
to
what
we're
actually
interested
in,
which
is
an
application.
B
And
groups
shift
over
time
as
well
like
what
the
relevant
thing
they're
actually
working
on
today,
so
I
don't
think
some
of
the
things
I
think
we
should
ask
again
in
this
this
one
I'm
thinking
about
I'm
highlighting
now
is
what
should?
What
should
environments
be
tied
to
to
me?
Environments
should
have
a
map
into
an
application,
but
what
is
an
application?
A
So
I
borrowed
a
similar
map
like
this,
of
it's
almost
like
a
uml
map,
but
but
I'm
being
very,
very
loose
fast
and
loose
with
uml
here,
but
essentially,
okay.
What
is
the
environment
right
so
going
into
the
the
api
response
saying
everything
that
comes
back
and
then
okay?
What's
on
the
screen
right,
not
necessarily
things
are
there
on
the
api
all
right,
so
all
of
these
things
are
shown
about
the
environment
and
then
what's
on
the
yaml
file
that
relates
to
the
environment.
So
all
of
these
described
here
and
then
how?
A
How
does
the
environment
relate
to
to
deployment
as
it
is
today
and
to
the
release?
It
actually
doesn't
right
now,
but
right
they
are
similar
concepts
that
are
close
by
and
then
freeze
periods
which
actually
refer
more
to
the
project
itself
than
to
the
environment,
so
trying
to
understand
how
these
pieces
connect
to
each
other.
But
I
agree
with
you
that
I
also
have
the
feeling
that
there
is
like
one
extra
piece.
That's
that's
missing
here
when
you
mentioned
that
groups
are
not
necessarily
the
right
abstraction.
A
It
really
resonated
with
me,
because
we
were
having
a
discussion
earlier
today
about
a
request
that
was
similar
to
that,
to
have
one
project
that
you
know
encapsulates
other
projects
for
for
managing
releases,
but
but
I'm
not
even
sure
if
it
should
be
a
project
or
a
group.
It's
just
one
entity
that
has
boundaries
and
within
these
boundaries
our
other
projects
and
this
entity
regulates
the
deployments
for
all
of
these
projects,
but
again
these
boundaries,
not
necessarily
map
to
a
group
that
is
on
the
gitlab
instance.
For
for
that
customer
right.
A
So
that's
some
something
we
should.
We
should
understand
better.
We
have
another
think
big
session
that
still
doesn't
have
a
team,
but
it's
scheduled,
for,
I
think
one
and
a
half
weeks
from
now.
Do
you
think
it's
worth
it
to
to
dive
a
little
bit
deeper
into
group
level
environments,
not
necessarily
focusing
on
group
but
higher
level
environments.
B
A
B
A
B
A
A
A
Basically,
a
deployment
has
an
id
git,
commit
a
branch
and
then,
after
that,
it's
just
like
the
data
was
created
and,
and
the
user
and
the
environment
it
points
to.
But
then
the
kind
of,
like
the
the
middle
of
the
hamburger
of
the
deployment,
is
actually
the
deployable
which,
which
is
the
object
itself
that
is
being
deployed
right.
A
So
the
the
git
commit
in
the
branch
are
copied
here,
like
nathan,
mentioned,
probably
for
convenience
when,
when,
when
doing
api
calls
but
they're
in
here
as
well,
so
you
have
you
know
the
the
stage
name,
the
the
job
name,
the
pipeline,
the
artifacts
everything
is
listed
in
here
and
then
the
the
interesting
thing
is
that
the
deployment
the
deployable
is
created
from
the
ci
pipeline.
So
if
you
create
a
deployment
from
the
api,
it
doesn't
have
a
deployable.
B
A
B
A
A
A
Yeah
you're
welcome,
but
yeah
I'll
share
this
in
the
discussion
of
the
of
the
sorry
as
well.
It's
it's
interesting
that
we
already
reached
the
point
where
we
decided.
Yes,
it
makes
more
sense
for
this
glossary
to
go
into
the
docs,
so
we
can
close
this,
mr,
but
the
comments
keep
rolling
in
and
this
discussion
is
really
good,
so
yeah.
B
B
B
If
it's,
if
it's
like
changing
things
in
the
same
place,
then
it
becomes
really
nice
to
see
yeah
anyhow
in
this,
mr,
we
I'm
proposing
we
move
secret.
Spanish,
went
back
into
release,
release
evidence
back
into
release,
because
I
this
it's
been
funny
because
I
feel,
like
we've
still
been
taking
on
all
the
release.
Evidence
work,
even
though
it's
technically
a
package
category,
you
know,
but
in
practice
it's
not
that
way.
So
I
propose
to
move
it
back,
so
you
do
do
things
like
releases
input
to
a
pipeline.