►
From YouTube: ENG/UX Progressive Delivery Meeting 2020-08-04
Description
Meeting to improve alignment between Engineering and UX for progressive Delivery
A
First
up
is
what's
in
progress,
I'm
currently
from
my
side,
looking
to
finish
up
group
deployments,
group
deploy
keys
issue
and
another
issue
that
I
need
to
look
up,
but
am
I
missing
the
boat
somewhere
else?
Do
you
need
some
direct
involvement
of
me
on
another
issue,
you're
currently
waiting
or
I'm
not
blocking
you,
then
I
would
love
to
know.
B
A
Ideally,
yes,
but
I'll
take
a
look
at
it.
If
you
can
post
the
post
the
link,
it's
I'll
have
to
talk
about
that
a
little
bit
later
in
the
meeting.
If
we
have
enough
time,
but
with
the
new
ocrs
for
products
and
ux,
but
mostly
product,
I
think
it
details
us
specifically
in
this
way
we
should
be
focusing
for,
like
all
newly
released
features,
should
use
git
lab
pajamas
design
system
components
going
forward.
A
If
not,
I'm
gonna
go
on
to
the
next.
I'm
gonna
skip
the
retrospective,
but
if
you
have
important
information
I
would
say
put
it
in
there.
I
know
we
have
some
discuss
some
timing
discussions.
I
know
that
this
doesn't
always
is
a
nice
time
for
nicole,
for
example,
but
she
already
put
it
in
here
some
questions
or
some
comments,
but
first
off
I'm
getting
over
to
chase
you
had
you
had
a
comment.
C
Yeah
thanks,
so
this
is
from
last
time
or
something
I
think
we
didn't
quite
get
to
this,
but
I'm
trying
to
remember
the
context
around
my
cup.
My
question
here,
I
think
mostly
like
we're
getting
better
at
our
overall,
like
asynchronous
planning
process
right,
making
sure
that
we've
got.
You
know
things
in
the
right,
hopefully
allocated
a
certain
capacity
for
the
right.
C
I'm
just
trying
to
like
want
to
make
sure
that,
like
things
are
getting
too
like
raising
to
your
visibility
level
and
how
we
should
best
do
that
if
it's
through
assigning
the
issue
to
you
or
using
some
other,
what
kind
of
trigger
are
you
looking
for
to
make
sure
that
you're
seeing
things
like
this
early
enough?
Does
it
make
sense.
A
Yeah
that
makes
fully
sense.
It
is
true
that,
like
I'm,
sometimes
still
assigned
to
an
issue,
but
like
it
doesn't
really
mean
too
much
for
me,
it
is
more.
I've
been
using
it
more
as
like
a
sometimes
some
some
kind
of
like
communication
device,
like
hey,
I'm
actually
dri
for
this
issue
or
I'm
a
messiah
like
I'm
doing
something
with
it,
but
it
is
losing
its
its
meaning
a
bit
with
me
using
my
personal
labels
and
like
those
I'm
actually
using.
A
So
if
you
don't
see
my
personal
labels
on
such
an
issue,
there's
a
big
chance,
I'm
not
I'm
not
seeing
the
issue,
which
is
a
bad
thing,
I'm
trying
to
like
what
I'm
doing
with
ori.
Every
week
we
have
two
one-on-ones
I'm
trying
to
stay
like
discuss
with
her.
If
she
changes
things
in
the
planning
issues,
then
I'm
updating
myself
based
on
that.
A
Basically,
of
course,
we
might,
you
know,
skip
out
on
a
few
or
miss
a
few
and
that
way
lose
out
a
on
the
other
hand
like
assigning
those
labels,
I'm
I'm
thinking
of
creating
a
new
label.
In
that
case,
that
can
just
be
a
sign.
Please
like
up
for
attention
or
something
like
that,
because
I'm
trying
to
safeguard
my
priority
labels,
preferably
I've
noticed
in
the
past
that
you
know
like
being
mentioned
all
over
the
place,
doesn't
mean
that
all
mentions
are
equally
as
important
or
that
some
things
are.
A
You
know
that
I
should
spend
my
time
on,
like
which
issues
am
I
actually
working
on
and
just
being
assigned
to
all
the
issues.
If
we
go
with
the
like
standardized
practice
of
being
assigned
to
an
issue,
then
hey
suddenly
you're
assigned
to
30
issues
like
no
like,
I
can
only.
I
can
only
work
on
a
few
issues.
So
how
does
it
sound
like,
let's
I'll,
create
like
a
dmi,
double
column?
Double
column
needs
needs
attention
label
and
you
can
assign
it
anywhere
you
want.
I
can
also
adjust
to
any
workflow.
A
C
Fine,
if
you
already,
if
you're,
already
working
from
a
set
of
labels
to
help
organize
all
the
ux
tasks,
then
I'm
I'm
happy
to
to
to
to
do
that.
I
just
want
to
make
sure
that
we're
that
we're
doing
the
right
things
like
from
my
side
that
I'm
I'm
behaving
in
the
way
that
we
need
to
to
do
to
make
sure
that
things
go
smoothly.
So
yeah,
I'm
happy
to
to
do
whatever
labels
label
sounds
great.
A
Yeah
and
if,
if
you
like,
anyone
can
should
be
able
to
sign
that
label,
I
just
just
put
it
on
there
and
I
will
check
it
regularly.
I
have
I
do
actually
the
same
thing
with
like
merch
quest
in
a
way
like
I've
had
set
up
a
dedicated
filter
of
my
to-do's
for
merch
quest,
and
I
check
that
basically,
almost
every
day,
like
hey
all
right,
I'll,
attend
two
merch
quests
somewhere
in
the
day,
and
then
I
don't.
A
A
Moving
on
to
the
next
point,
helping
out
with
the
department
of
okrs
I've
been
discussing
this
with
orit
and
nadia,
who
is
a
progress,
product,
design
manager,
of
course,
and
we
were
discussing
the
ocrs
that
come
down
from
departments,
as
said
before,
our
own
progressive
delivery,
okrs
are
in
progress,
so
feel
free
to
check
those
out.
I've
been
highlighting
them
any
feedback
is
welcome.
There's
a
proposal
in
the
issue.
A
The
merch
quest
basically
highlights
how
to
make
that
more
visible
and
more
standardized,
so
we
have
those
things
in
our
handbook
pages,
etc.
It's
more
of
a
a
nice
and
nice
thing.
The
issue
is
actually
around
defining
the
ocrs,
but
apart
from
those
we
have
our
own
department
okrs
right,
like
I
think,
from
an
engineering
perspective.
I
don't
know
if
they're
already
known,
but
for
q2
you
have
your
okrs
and
for
q3
there
should
be
also
ocrs,
which
we're
going
to
be.
A
A
So
here
are
the
product.
Okrs
here
are
the
ux
okrs,
and
here
we
can
see
like
all
right.
We
want
to
improve
gitlab's
performance
quality
velocity,
but
making
gitlab
developments
pajamas.
First,
all
right,
pretty
good.
There's,
especially
this
one
is
pretty
nice
to
know
about,
like
100
of
new
features
in
gitlab
added
in
q3
should
use
pajamas
components.
So
if
you
see
proposal
for
me
not
standardizing
on
components,
please
bring
it
up
to
discussion
I'll
try
to
do
the
same.
A
I
think
this
is
just
like
a
something
we
should
pay
attention
towards
and
then
we'll
flow
into
the
right
direction.
Anyway,
I
mean.
Ideally,
we
should
be
using
that
anyway,
because
it
should
improve
and
make
development
easier.
So
I
think
it
should
already
flow
in
the
right
direction,
but
just
to
keep
keep
track
of
it
and
then
the
other
ones
are.
This
one
is
a
little
bit
unfamiliar.
This
is
to
be
discussed
on
a
later
later
point
because
it
isn't
clear
exactly
what
it
is,
what
it
is
geared
at
or
whom.
C
A
Is
geared
at
but
the
first
one
is
actually
pretty
important.
Prioritize
engineering
work
to
complete
integration
of
eight
pajamas
components
across
the
product,
so
a
few
quarters
ago
or
a
few
months
ago,
we've
completed
the
build,
create
and
style
phases
of
certain
pajamas
components,
for
example
the
button
component
I
was
personally
involved
in
and
that
doesn't
include
the
integration
phase
of
that.
So
especially
with
a
button
component.
That
was
like
a
huge
nasty
task
that
we
weren't
sure
how
to
complete
and
basically
what
what
is
happening
is
like
all.
A
Existing
buttons
have
been
converted
as
much
as
we
can
to
a
gitlab
deprecated
button
component.
You've
probably
seen
it
across
the
code
base
and
what
we
need
to
do
is
there's
now
been
created.
I
know
like
250,
mrs,
that
we
need
to
change
them
individually,
test
them
see
if
we
break
nothing
and
merge
that
code,
I've
already
taken
on
a
few
myself
and
it's
the
same
for
pagination
buttons,
alert,
toolkits,
blah
blah
blah
and
icons.
A
So
I
was
wondering
and
discussing
with
urid
earlier
today.
How
can
we
put
our
best
foot
forward?
I
mean-
maybe
that
is
a
dutch
saying,
but
maybe
we
can
help
out.
That
is,
that
is
the
gist
of
it.
I
was
wondering
how
how
you
were
thinking
about
that
from
an
engineering
perspective.
Is
this
known
by
engineering
in
any
way?
Where
already
some
plans?
I
would
love
some
feedback
in
that.
C
Sense,
I'm
just
I
think,
I've
seen
like
an
epic
somewhere
that
has
the
list
of
button
or
gl
component
type
upgrades
like,
and
I
think
that's
it.
I
think.
That's
all.
I
really
know
about
from
that
work
and
been
like,
and
I
think
this
is
the
first
time
we've
like
I've
seen
okay
ours
from
a
ux
perspective,
which
I
think
is
really
good
engineering.
A
It
even
has
a
show
more
picture
link
inside
of
the
child
issues
list.
Inside
of
the
epic,
I
mean
that's
something
right
yeah,
so
what
I've
been
wondering
about,
or
at
least
discussing
the
word
is
saying
all
right.
Perhaps
we
can
take
care
of
a
few
of
them
like
this.
Epic
is
pushed
from
ux
and
product
perspective.
A
B
B
B
A
B
B
B
I
think,
at
the
very
least,
we
should
try
to
take
ownership
of
the
ones
that
are
that
are
under
the
the
no,
the
progressive
delivery
section
right,
like
the
the
anything
involving
environments
and
feature
flags
and
and
whatever
it
is
that
we
theoretically
own
and
then
once
those
are
done,
we
can.
We
can
look
at
maybe
trying
to
help
out
beyond
our
group.
A
Yeah
that
sounds
good
I'll,
propose
a
list
in
the
in
the
planning
issue
and
then
I'll
I'll
tag.
All
of
engineering
say
like
all
right.
You
can
schedule
it.
However,
you
want
see
how
it
fits
in
with
the
rest
that
is
up
to
you.
I've
taken
on
a
few
myself
battling
with
some
of
them
figuring
out
what
I
need
to
do
for
some
of
them
or
how
I
how
I
can
figure
out
where
the
button
is
located
or
summon
it
up
in
the
ui.
A
A
A
So
thank
you
all
for
joining
sorry
for
the
for
the
for
the
late
start
and
if
you
have
any
points
to
bring
up
for
any
next
meeting,
please
put
them
on
the
agenda.
I'll
make
sure
they're
prioritized
above
my
points,
because
I
have
always
points
to
bring
on
so
no
problem
thanks.
So
much
and
I'll
see
you
next.