►
From YouTube: ENG/UX Progressive Delivery Meeting 2020-08-18
Description
Meeting to improve alignment between Engineering and UX for progressive Delivery
A
All
right
thanks
thanks
for
joining
again,
as
as
it
was
in
previous,
this
is
to
align
between
ux
and
engineering,
and
I
put
in
some
initial
notes
I'll
move
this
one
briefly
down,
so
that
if
you
have
something
you
can
put
it
in
there
below,
because
I
pre-filled
some
some
questions
I
had.
I
was
wondering
about
the
first
one,
and
let
me
I
see
this
one
has
already
been
resolved.
I
think
mostly,
let
me
share
my
screen
because
I
got
way
too
many
tabs
open
here.
A
I
don't
know
like
30
or
something
I
had
this
freaky
numbers
right,
yeah,
okay,
I
tried
to
keep
it
smaller.
This
seems
to
be
already
be
done,
but
I
I
this
kind
of
loops
into
like
a
later
point
of
mine,
where
ethan
gave
those
async
updates
on
like
that
are
kind
of
even
throughout
this
issue,
like
hey,
async,
updates
status
of
completeness
confidence
like
where
are
we
doing
merch
quest?
He
had
he's
noted
them
here
as
well,
and
I
was
wondering
how
we
are.
A
What
is
our
current
process
here?
Is
that
the
online
process
that
we
we
do
it
with
like?
How
is
merch
quest
scoping
decided
and
how
do
we
keep
ourselves
informed
in
that
sense,
because
on
on,
at
the
same
time,
with
with,
for
example,
the
let
me
see
which
one
was
that
with
this
one
like
allow
parent
projects
developers
to
create
pipelines
for
merge
quests
for
foreca?
Mrs
there's
a
whole
bunch
of
mrs
that
gone
in
through
this
and
got
merged.
A
But
I
I
wasn't
aware
that
we
were
already
like
things
were
already
well
that
well
developed.
You
know
like
I
was
I'm
a
little
out
of
the
loop
is
what
I'm
trying
to
say.
So
what
I'm
trying
to
understand
is
like
all
right:
how
do
we
do
merch
by
scoping?
How
do
we
keep
ourselves
informed.
B
Yeah,
I
would
just
have
to
I'll
just
chime
in
there
that,
like
the
async
updates
are
great,
you
know,
I
think
they're
super
hopeful
for
everyone
to
to
do
that,
that
one
thing
of
kind
of
be
informed
about
the
progress
of
where
this
this
effort
is
at
the
thing
about
the
process,
though,
is
that
we
have
we've
kind
of
left
it
up
to
the
individual
engineer
about
how
they
want
to
format
and
provide
that
that
update.
B
There
are,
like
you
know,
like
very
loose
suggestions
in
the
handbook
about
like
here's,
here's
some
examples
and
then
like
the
tool
telltale
can
give
you
like
some.
It
can
kind
of
basically
do
it,
for
you
too,
as
well
so
is,
is
like
the
thing
that
you're
asking
here
is
like
that.
Everyone
added,
mr
to
the
async
updates,
or
which
part
is
like
the
the
the
informative
piece
in
the
async
update
that
works
for
you.
A
So
from
from
this,
this
side,
where
ethan
here
gives
gives
async
updates.
I
like
that,
a
lot.
My
only
comment
there
is
like.
Please
give
us
a
mention.
You
know
like
you,
can
post
all
the
updates.
You
want
inside
an
issue,
but
that
doesn't
really
mean
that
everyone
is
aware
that
you
know
an
update
has
been
posted
to
an
issue.
I
don't
know
about
you,
but
I
work
with
a
to-do
workflow
instead
of
an
email
workflow.
So
I
only
get
notifications
when
I'm
actually
mentioned
at
an
issue.
A
So
things
go
past
me
even
though
I'm
dog
footing
application
to
some
extent,
but
but
the
other
hand
is
like
especially
for
this
issue,
this
got
merged
without
me,
even
knowing
that
we
were
at
that
state.
So,
like
hey,
I
pushed
push
the
designs
like
we've,
we've
discussed,
it
was
feasible.
Things
were
going
in
and
then,
if
we
look
at
dmrs
here,
we
see
there's
a
bunch
of
mrs,
but
let's,
let's
look
at
one
of
the
latest
ones.
I
don't
know
why
this
is
not
loading.
A
A
How
do
you
do
that?
Like
yeah?
Let's,
let's
look
at
this
one?
I
think
this
is
a
good
good
example
like
hey
show
security
warning
model
for
fork
pipelines
and
then
yeah.
We
can
see
here,
for
example,
an
approval,
not
that
it
needs
perfect
approval
from
for
me
or
so,
for
example,
but,
like
marcel,
is
in
there,
like
all
the
engineers
are
there,
but
I'm
not
there,
like
I'm
feeling
a
little
left
out
here
like
why.
Why
am
I
not
aware
of
this
at
all?
Like
I,
I
have
no
idea.
This
is
going
on.
A
On
the
other
hand,
if
we're
going
to
merge
things-
and
you
know
like
considerable
ux
that
or
bugs
are
created,
it
also
falls
on
my
plate.
So
and
there's
I
think,
like
I've
been
discussing
this
with
nadia
in
the
past,
it's
it's
been.
It's
been
a
little
bit
on
a
standstill
at
the
moment,
but
like
to
create
true
alignment
on
what
is
expected
from
each
side
regarding
the
merge,
quest,
creation,
approval
and
merge
phases
of
a
merge
quest
like
who's
involved.
A
And
why
and
what
is
expected
I
mean
ideally,
you
know
like
I
create
the
issue.
We
I
discuss,
involve
everyone.
We
got
to
a
solution
and
then
I
I
never
see
it
again
because
I'm
not
concerned
with
it
anymore.
That's
not
the
real
reality,
of
course,
and-
and
I
don't
want
to
approve
every
mr,
but
I
want
to
at
least
be
informed,
I
would
say
to
say,
like
hey:
can
I
give
it
a
look?
A
Can
I
give
it
at
least
some
kind
of
like
a
functional
walk
through
so
I
can
say
hey.
I
saw
this
or
noted
this.
Maybe
we
need
to
follow
up
issue
to
scope,
this
effort
out
and
follow
up
on
it,
because
I
don't
think
it
worked
as
well
as
we
initially
thought,
or
I
don't
know
something
like
that,
and
that
that
feedback
loop
is
what
I'm
looking
for.
A
B
I
think
that's
helpful
yeah.
I
mean
from
the
engineer
perspective
like
jason
or
andrew,
like
what,
where
do
you
like?
Is
it
just
a
matter
of
of
recognizing
what
pieces
need
to
be
like
how
to
loop
in
dimitri
or
is
there
some
other
kind
of
thing
we
need
to
put
in
place.
C
I
think
there's
like
a
balance
of
triviality
around
it.
I
would
I
would
agree
like
if
I
had.
If
I
had
implemented
that
modal
I
would
have,
I
would
have
pinged
ux
on
it
just
so
they
could
take
a
look
on
it.
That
might
be
that
might
be
bored
due
to
the
the
back
end,
people
taking
up
more
front-end
work
and
being
less
familiar
with
the
front-end
process.
C
The
the
the
reviewers
and
the
maintainers
can
sometimes
not
look
at
the
whole
picture
of
the
mr
and
realize
that
ux
hasn't
been
pinged,
because
there's
so
many
names
and
so
many
comments
and
so
much
discussion
going
on
that.
If
I'm
coming
in
to
review
nmr,
I
I'm
trying
to
stay
focused
on
on
the
code
itself,
unless
something
seems
really
really
wonky.
You
know
so
that
would
be
like.
C
That
would
be
why
and
it's,
and
it's
never
entirely
clear
if
you're
coming
into
an
mr
in
a
in
a
strange
section
of
the
code
who
exactly
is
the
the
ux
responsible
person,
so
we
kind
of
leave
it
up
to
the
individual
contributors
unless
it's
a
community
contribution.
A
Yeah,
I
I
think,
like
community
contribution,
I
have
a
point
on
that
later.
I
think
that
is,
to
some
extent
an
additional
process
that
I
think
is
a
little
bit
different
from
our
internal.
Mrs,
as
you
will
yeah
is,
you
know
like
it
is
a
less
of
a
groomed
state
where
dmr
is
created
from
the
original
concept.
Sometimes
the
issue
is
like
not
a
proposal
at
all
or
there's
not
alignment
on
what
the
actual
solution
is
going
to
be
and
etc.
A
So
I
would
like
to
scope
that
part
out
of
the
discussion
here,
but
on
the
other
hand,
I
I
do
agree
with
you
that
the
mrs
like,
when
I
see
him
often
they're,
like
full
of
like
conversation
like
there's
a
like
a
lot
of
it
like
I
often
feel
like
I'm
like
I'm
like
I
jump
into
the
deep,
and
that
is
that's
not
bad
per
se,
but
with
the
merch
quest
scoping
efforts
going
on
like
hey,
we
want
this
backhand.
We
want
this
front
end.
A
We
want
this
for
something
else
like
I,
I
almost
would
say
that
a
merch
quest
is
not
the
ideal
medium
anymore.
If
those
merchandise
scoping
is
going
on
in
a
certain
way,
because
it
doesn't
convey
the
complete
picture,
however,
like
let's,
let's
have
that
as
a
thing
that
is
noted.
If
there
is
certain
merch
quest,
scoping
going
on
and
a
single
merge
quest
doesn't
convey
like
the
end
result
of
the
feature
we're
trying
to
implement,
then
that
merge
quest
is
not
good
like
the
good
medium
for
conversation.
A
However,
in
an
ideal
world
you
would
have
some
functional
review
to
some
extent
before
optimizing
code
and
and
there's
no
room
for
any
small
nudges
or
fixes
anymore.
A
Then,
as
a
third
thing,
I
want
to
point
out,
like
hey,
say
that
we
have
that
merch
quest
scoping
on
going
on
and
things
are
in,
complete
format
are
going
to
be
merged.
Then
there
needs
to
be
that
feedback
loop
at
the
end
to
then
not
create
like
immediate
changes,
but
to
at
least
create
follow-ups
if
need
be,
and
that
we
have
a
follow-up
like
feedback
loop
to
say
all
right.
We
now
implemented
this.
A
C
Unless
you
go
and
and
set
up
your
gdk
and
everything
the
best
you
can
do
is
look
at
like
some
pictures,
or
maybe
a
video
and
a
lot
of
the
times.
These
larger
features
are
just
they're,
they're,
too
big
to
be
contained
in
one.
Mr,
so
do
we
need,
if
it's
like,
do
we
need
to
extend
the
verification
process
to
to
inform
you
that
it's
like
deployed
on
staging
or
enabled
on
staging,
or
something
like
that,
so
that
you
can
go
and
investigate
it
or
like
what
do
you?
C
What
do
you
think
would
work
here.
A
Yeah,
I,
to
be
honest,
like
I
think,
both
from
a
perspective
of
review,
slash
verification
or
validation,
as
well
as
evangelization
of
what
we're
actually
in
shipping.
I
think
for
both
of
those
causes.
I
would
love
to
see
a
message
posted
in
our
slack
and
say
we
just
shipped
this:
let's
go
into
the
review
phase
or
let's
go
into,
I
know
whatever,
so
we
can
see
like
all
right,
we're
shipping
all
this
amazing
stuff.
A
A
But
yet
like
I
would
like,
I
would
love
to
see
that,
like
I
don't
want
to
per
say,
jump
in
the
merch
class,
because
I
know
that
have
has
caused
friction
and
causes
friction
throughout,
like
the
the
the
review
process.
There's
another
another
person
to
wait
on
for
feedback,
blah
blah
we're
stretching
out
the
merch
quest.
But
I
do
think
that
the
follow-up,
the
feedback
loop
of
like
hey,
we
shipped
this.
Now,
let's
look
at
it
like
together,
I
think
that
is
currently
missing.
In
my
opinion,.
C
So
as
a
as
kind
of
an
initial
process,
what
if,
when
we
we
we
close
issues
once
they're
once
they're
deployed
on.com
right
as
as
an
initial
process?
What,
if
we
just
we,
we
ping,
maybe
you
and
ori
when
we
when
we
go
to
close
the
issue
and
we
can
be
like
this
is
deployed
on.com.
You
should
be
able
to
check
this
out.
If
it's
behind
a
feature
flag
we
can
have
like
we
can.
C
We
can
figure
out
if
it's
appropriate,
to
give
access
to
it
yet
or
not,
and
then
and
then
that
verification
can
can
happen.
Or
would
you
prefer
maybe
something
earlier
in
the
in
the
deployment
process
like.
C
C
Yeah,
the
big
issue
with
that
is
that
we're
not
really
notified
when
things
hit
those
environments
either,
because
what
happens
is
an
nmr
gets
like
a.
What
are
those
labels
called?
A
scoped
label
changed
on
it,
so
it
gets.
C
It
gets
buried
in
emails
right
and
then
there's
the
there's,
the
verification
to
do
issue,
which
I
don't
know
I
haven't
seen
one
in
in
a
little
while
I
think
I
I
heard
something
about
them
not
working
recently,
but
those
are
those
are
mostly
to
make
sure
that
things
aren't
completely
broken
before
they
hit.com
either.
A
I
I
think,
like
simple
simple
is
mostly
the
the
best
I
I
love
your
ass,
like
your
proposal
of
hey,
if
we
close
this
issue,
let's
make
sure
that
you
know
product
is
notified
of
that.
I
I
think
that
is
a
very
simple
thing
to
do
and
kind
of
works
right
like
it
puts
it
to
do
on
on
my
on
my
plate
and
on
or
it's
plate
to
make
sure
like
hey,
let's
walk
this
through.
A
Let's
make
sure
it
aligns
with
what
we
thought
it
was
and
we
can
scope
out
any
additional
things.
I
think
that
would
be
at
least
already
improve
improvement
like.
Ultimately,
what
I
would
I
think,
but
is
an
assumption
right,
is
that
it
needs
an
additional
workflow
label
to
say,
like
hey,
has
this
been
product
verified
or
something
like
that,
like
that,
does
this
break
prod
production?
No,
all
right,
pretty
cool!
Let's,
let's,
let's
push
it
I
mean:
does
it
solve
the
problem
fully
as
we
want
it?
Like
that's
another
thing
right.
A
A
A
But
if
we
close
the
issue,
the
issue
is
is
nowhere
to
be
found
on
any
issue
boards
and
not
every
issue.
Should
we
deem
worthy
to
be
solution
validated,
because
then
we
need
to
do.
You
know,
get
external
participants
in
there
and
make
sure
that
we,
you
know
test
it
thoroughly,
blah
blah
blah,
like,
I
would
say,
there's
an
initial
pre-solution
validation
phase
or
you
can
just
say
all
right.
A
B
B
B
C
A
A
By
the
way
on
that,
I
haven't
set
a
like
the
closing.
Mr
often
I'm
looking
at
an
mrs,
like
which
issue
is
this
and
like,
instead
of
saying
closing
this
issue
in
the
like,
mr
description,
there's
just
nothing
right
now,
it's
just
like
just
figure
out
which
issue
this
mr
belongs
to
it's
all
up
to
you
like.
If
I
can
make
one
request,
please
at
least
mention
the
issue
in
the
mr
description.
That
would
help
me
a
lot
because
I'm
I'm
out
of
the
blue,
like
I
have
no
idea.
C
I'm
pretty
I'm
pretty
bad
for
that.
Sometimes
it's
true,
it's
kind
of
there's
a
it
would
be
nice
if
I
could
just
put
them
in
the
commit
message,
and
it
would
do
it
all
automatically,
but
I
did
that
once
and
dangerbot
was
like
you
shouldn't
do
that
you
should
put
full
links
in
instead
of
just
the
references.
C
A
All
right
sounds
good,
so
I
think
we
have
some
kind
of
like
an
action
item
here,
I'll
discuss,
which
I
have
in
eight
minutes,
so
I'll
go
from
there
and
bring
it
back
to
the
slack
channels.
I
think
that's
good
yeah.
A
A
A
I
I
feel
the
pain
I
can
understand.
Let
me
see
because
this
list
has
been
going
on
for
a
little
bit.
There
is
a
new
product
design,
specific
handbook,
page
I've
been
throwing
merch,
quests
right
and
left
that
chase
here
and
there.
So
sorry
for
that
the
url
is
actually
let
me
grab
the
url.
A
So
it
becomes
a
little
bit
more
manageable
to
to
keep
aligned,
and
it
also
allows
me
to
how
do
you
say
to
get
better
ingrained
into
the
processes
of
engineering.
So
I'm
learning
as
I'm
like
trying
to
see
what
it
is
about
like.
Oh,
I
can
add
little
bits
of
information
that
I
already
had
documented
in
the
ux
page
or
that
I
see
as
like
improvements
from
other
stage
groups.
A
It's
a
small,
slow
process,
but
if
you
want
to
see
what
ux
is
about
or
product
design,
whatever
you
want
to
call
it
from
progressive
delivery
side,
here's
all
the
things
you
can
find
recordings,
opr's
job
to
be
done
like
it's
all,
work
in
progress,
but
it's
pretty
interesting
picture.
I
think.
A
You
said
like
hey
we're
in
this
workflow,
where
we
have
feature
flags
and
they're
turned
on
and
there's
this
iteration
cycle
of
like
hey.
How
are
we
scoping
out
the
effort
that
is,
you
know
needed
for
the
mvc
versus
what
is
going
afterwards,
like
as
a
follow-up,
and
I
have
a
little
pet
peeve
of
mine,
which
is
this
custom
emoji
issue,
which
I
still
need
to
spend
more
time
on?
But
what
I've
done
for
this
is
like
kind
of
make
it
visual
what
is
happening
for
like
what
is
the
mtc
scope?
A
What
is
the
work
that
needs
to
be
done
before
that?
What
is
after,
when
are
the
feature
flags
created
when
are
they
turned
on
versus
off
and
is
being
made
user
facing?
I
was
so
my
question
here
would
be:
do
you
think
this
is
helpful
and
b?
Is
there
something
similar
of
a
process
already
going
on
for
future
development.
A
Yeah,
because
currently
every
engineer
decides
by
themselves
like
all
right,
I'm
going
to
create
a
like
a
feature
flag,
yes
or
no,
I'm
going
to
turn
it
on
or
off
yes
or
no
like
how
like
what
is
it
included
in
the
mvc
like
this
is
going
to
be
a
like
multiple
milestone
effort,
which
is
going
to
be
a
three
mrs,
within
one
single
milestone
effort
like
all
these
kind
of
things,
I'm
I'm
kind
of
wondering
about
to
be
able
to
be
better
at
developer
handoff
when
I'm
pushing
my
information
towards
engineering
like
hey,
I'm
thinking
like
this
about
this.
C
C
C
C
A
Yeah,
I
think
what
what
what
I
envisioned
is
that
product
is
a
little
bit
more
proactive
in
this
as
well,
and
that
we
say
like
all
right
this.
We
just
don't
just
look
at
the
current
upcoming
milestone
but
hey.
How
does
this
relate
across
like
three
milestones
right
like
because
also
for
the
especially
for
the
future
like
stuff?
A
In
the
past,
I've
seen
like
all
right,
we're
gonna,
develop
this
we're
gonna,
develop
that
we're
gonna
develop
this,
but
there's
not
like
a
really
at
least
it's
hard
to
find
a
holistic
view
of
what
a
road
map
for
feature
flags
is,
and
I
think
be
helpful
from
a
product
towards
engineering
side
that
you
also
know
like
all
right.
I'm
gonna
develop
this,
but
this
is
going
to
be
next
so
better.
A
I
know
optimize
the
code
to
make
room
for
that
or
don't
don't
code
myself
into
a
corner
where
I
make
it
harder
for
myself
in
the
future.
At
least
that's
how
I
envision
it
or
assume
it
to
be,
but
yeah
decision
around
waiting
time
makes
sense.
It's
mostly
a
thing
that
I
was
wondering
about
so
I'll
see
if
I
can
include
some
of
that
in
the
future,
if
it
makes
sense,
especially
with
a
b
testing,
I'm
trying
I'm
going
to
try
this
out.
A
A
C
I'm
I'm
just,
I
think,
I'm
starting
to
wonder
if
a
lot
of
a
lot
of
these,
like
larger
features
that
we're
trying
to
build
out
should
be
should
be
more
epic
sized,
and
then
we
can
have
like
a
like
an
mvc
issue
and
then
easily
capture,
all
of
the
not
the
validation,
maybe
yeah,
the
validation
feedback
and
the
the
iteration
refinements
that
we
want
to
do
afterwards.
A
Yeah,
I
I
can
give
you
because
we're
almost
going
to
go
over
time.
I
need
to
go
to
another
meeting,
but
a
little
sneak
peek
of
what
I'm
trying
to
do
in
the
next
couple
of
months
is
convert
our
epic
structure
to
jobs
to
be
done,
and
then
under
those
jobs
to
be
done.
You
will
have
your
like
all
right.
This
is
feature
flags,
and
then
you
have
that,
and
this
is
a
b
testing.
Then
this
is
the
mvc
part
of
the
a
b
testing.
A
This
is
like
the
next
stuff
and
there's
this
thing
called
vertical
stacking.
I
believe
it's
called
where
you're
gonna
try
to
put
like
value
in
each
iteration
that
it's
like
doable
from
both
product
and
engineering.
With
this.
This
whole
thing.
Currently
it's
still
like
in
general
buckets
here
and
there
inconsistently
done,
but
it
is
something
that
I'm
working
with
auradon
to
make
to
let
it
make
more
sense,
I
would
say,
but
yeah
very
good
suggestion
thanks
for
that,
I'm
gonna
call
it
close,
because
I
need
to
go
to
the
other
meeting.
A
Thank
you
all
for
joining.
I
think
the
rest
of
the
things
are
not
super
important,
except
for
I
think
we
already
discussed
this.
Maybe
I
shouldn't
move
it.
Try
to
experiment
with
that,
and
the
community
contribution
merge
quest
flow
is
something
that
we
can
discuss
next
time.
I
think
this
is
pretty
interesting.
A
I
wanna
would
love
to
know
your
thoughts
on
on
how
this
currently
goes
and
those
kind
of
things.
So
thank
you
all
for
joining
and
if
you
have
additional
questions
or
thoughts,
please
leave
them
in
the
slack
thread
somewhere
and
we
can
discuss
async
cheers.