►
From YouTube: UX CI/CD meeting 15 July 2020
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
so
today
is
the
15th
of
July.
Welcome
everybody
to
the
CIC
Dux
meeting.
The
first
point
on
the
agenda
is
by
nadya,
which
she
wanted
me
to
talk
about.
So
this
is
about
UX
definition
of
tunnel
issues
that
she
had
started
in
which
there's
a
discussion
going
on
on
like
what
would
be
the
definition
of
ton
of
the
issues
that
we
take
up
in
CI
and,
as
you
can
see,
she
has
tried
to
break
it
into
four
parts
which
are
only
talking
about
two
workflows,
both
for
design
and
workflow,
ready
for
development.
A
So
the
first
two
parts
are
when
an
issue
enters
in
the
workflow
design
and
when
it
leaves
when
it
is
ready
to
exit
that
criteria,
and
similarly
the
next
one
is
when
issues
are
ready
to
get
into
the
workflow
ready
for
development.
And
then
when
should
it
be
considered,
the
role
of
I
mean
from
the
US
side.
It's
done.
A
So
there
are
many
conversations
going
on
the
engineers
with
designers
as
well,
so
they
would
love
to
have
everyone
drop
their
thoughts
there,
for
example,
there's
a
conversation
about
how
the
edge
cases
should
be
documented
and
then
there's
also
another
question
about.
If
there's
a
pajama
issue,
that's
related,
should
it
be,
should
we
wait
on
getting
that
resolved
first,
if
someone
has
encountered
encountered
any
such
problem
in
their
area
of
the
for
this,
and
they
can
share
their
experience,
it
would
be
great.
A
A
C
Don't
think
I
have
encountered
yet
the
situations
where
I
need
to
create
a
completely
new
component,
so
I'm
not
familiar
with
that
kind
of
workflow
like
going
with
pajamas
developing
the
component
and
then
moving
these
like,
like
some
blocking
yourself,
so
I,
don't
I,
don't
think
I
can
provide
a
good
perspective,
but
I
think
that
yeah
I
think
it's
important
to
know
how
I
personally
happen.
I
personally
have
been
able
to
do
everything
without
like
creating
new
components.
C
D
D
Management
always
runs
into
place
where
we're
implementing
they
get
lab
UI
component
asses,
and
then
we
have
follow-up
issues
to
implement
the
pajamas,
styling
and
requirements,
for
example,
or
milestone
picker.
We
actually
ended
up
instrumenting,
the
pajamas
component
for
it
and
contributing
back
to
the
to
the
design
spec
after
we
delivered
it.
You
know
I.
C
You
know,
I
just
feel
that
sometimes
I
need
to
go
and
ask
someone
from
the
foundation
team
like
hey.
Is
this
correct?
What
should
I
do
in
these?
What
type
of
components
should
I
use
for
this
stuff
or
not?
There's
always
that
conversation
with
them
I
just
haven't,
had
the
situation
where
I
need
to
actually
create
a
completely
new
component
and
contribute
back
to
the
jammas
on
what
we're
doing.
A
D
Out
of
kind,
this
kind
of
a
word
word
I
would
say
typically
two
milestones,
so
we
create
the
spec
confirm
that
the
documentation
has
been
updated.
On
the
pajama
side,
we
go
through
the
prototype,
updating
and
confirm
the
interactions
are
what
we're
expecting
it
to
be.
Have
that
issue
add
added
to
the
needs
weight
priority
list
for
our
engineering
team?
They
weighed
it.
We
drop
it
into
priority
for
the
following:
milestone
its
nearing
team
instruments,
the
component
deliver
the
component
and
then
in
the
third
milestone.
D
D
Yeah
we
used
to
and
one
really
so
it's
one
team
before
we
buy
fur
kated
it
between
progressive
delivery
and
release
management
may
be
Dimitry.
You
can
speak
to
the
cycle
time
between
design
and
engineering
like
how
quick
you're
working
on
stuff
for
engineering
to
deliver,
but
I
try
to
have
hi
Anna
as
a
p.m.
work
on
her
prototypes
to
milestones
in
advance
of
ended
engineering
delivering
it
so
that
we're
always
able
to
like
the
raise,
though
we
have
a
UX
definition
of
done
and
UX
definition
had
done,
has
to
be
done.
B
But
I
mean
that
is
that
is
I,
think
ideal
state
right
that
you
are
working
that
far
ahead,
that
you
have
time
to
to
see
in
advance
like
hey,
actually
in
order
for
us
to
deliver
this,
we
need
this
component.
We
schedule
this
new
milestones
ahead.
Is
there
time?
Is
there
space
to
develop
this
component?
B
I
mean
I,
want
I,
want
progressive
delivery
to
be
there
when
we
get
there
that
that's
gonna
be
awesome,
but
the
closer
you
are
developing
against
it
immediately
up
following
milestone
like
it's
not
gonna,
be
like
a
scenario
of
do
we
have
time,
it's
gonna,
be
scenario.
We
have
to
make
time
and
then
it's
going
to
be
that
debate
of.
D
C
That's
true,
I
think
that
that's
but
I
think
that's
coming
the
early
sacrifice
that
you
do
right
now.
In
that
sense,
it's
what
allows
you
to
later
go
move
faster,
those
components
and
like
a
componentize,
you
guys
way
easier
to
build
on
top
off
so
yeah.
D
The
pagination
component
that
we're
working
on
right
now
we're
gonna
leverage
on
the
releases
page,
we're
gonna
leverage
on
the
CIC
director,
dashboard
environments,
dashboard
index
page
like
there's
six
other
places
that
we're
going
to
be
able
to
just
just
slap
that
puppy
in
and
not
have
to
like
rebuild
it,
which
is
fantastic.
The
the
gains,
the
efficiency
gains
that
we
get
it's
awesome,
but
that
upfront
investment
is
kind
of
like
a.
E
E
It's
my
turn
already.
Alright,
sorry
I
was
just
coming
out
of
meeting
with
Darrell,
so
I
am
working
on
whatever
this
issue
is.
Why
didn't
it?
Whatever
I'm
having
issues
today,
19:22
it's
a
CIA
adoption
journey
research
with
Andre
he's
the
another
researcher
in
monitor.
E
We've
been
talking
with
Pam's
this
week,
sorry
PMS!
This
week
we
talked
with
or
a
towel
just
finished
talking
Darren.
We
talked
with
Tim
and
growth
as
well
to
understand
what
is
the
CI
adoption
journey
lots
of
different
answers:
lots
of
different
perspectives,
it's
kind
of
clear
to
us
that
everybody
thinks
of
it
in
terms
of
their
own
silo,
their
own
part
of
the
product.
So
that's
gonna.
Take
a
lot
of
my
focus
over
like
the
next
three
months.
Andre
and
I
are
going
to
work
together
with
that.
E
We
need
to
work
on
defining
the
box
that
we
need
to
play
in
for
this,
because
it
is
such
a
large
project.
So
that's
one
of
my
my
main
things
I
didn't
put
here,
but
I'm,
also
working
on
some
new
wax
research
curriculum
on
the
research
team
side
for
everybody
me
and
Adam
are
working
together
to
kind
of
try
to
repurpose
what
we
have
in
the
handbook
in
a
way
that
might
be
a
little
bit
more
meaningful
and
easy
to
consume.
E
Then
all
the
word
solid
that
we
have
up
there,
we'll
keep
it
in
the
handbook,
but
we
want
to
turn
it
into
something
that's
at
least
like
learning
modules
or
something
something
a
lot
more
easily
consumable
for
people.
So
both
product
is
InDesign
and
anybody
else
in
the
company
who
wants
to
learn
about
research.
E
E
Research
part
of
what
the
research
team
is
up
to
is
once
again
realigning
what
we
put
our
focus
towards
and
wanting
to
put
more
of
a
focus
towards
doing
the
deeper
problem,
validation,
stuff,
more
strategic
problem,
validation,
research
and
not
necessarily
saying
I
have
a
problem
about
this.
There
is
a
problem
here.
E
It
sounds
that
this
will
be
perfect
for
that
so
Jackie,
looking
forward
to
talking
with
you
on
Friday,
my
brain
will
not
allow
me
to
even
look
at
the
issue
until
then
and
of
course,
I'm
trying
to
find
more
people
who
hate
merge,
requests,
it's
kind
of
hard
to
find
people
who
hate,
merge,
press
and
even
the
people
who
say
they
hate
merge,
requests
when
I
talk
to
them.
They're
like
oh,
it's
not
that
bad.
Like.
D
E
E
We,
he
pulled
I
pulled
a
list
and
then
the
data
team
helps
me
fix
the
list,
and
now
we
have
32
thousand
people
who
have
just
created
an
M
R
for
the
first
time,
the
last
30
days,
so
I'm
gonna
try
to
get
our
recruiter
to
start
in
this
list
and
sending
out
invites
because
what
I
want
to
do
is
start
talking
to
people
who
are
new
to
merge,
requests
and
see
if
they're
in
lies.
Some
frustration
of
I
hate
this
thing,
and
this
is
why?
E
There's
no
lurking
beasts
that
I
have
found
so
far
in
talking
to
15
people,
so
I'm,
hoping
that
the
noobs
will
have
some
something
back
for
me
and
I'll
have
to
wrap
those
sessions
up
by
end
of
next
week,
because
I
have
got
to
like
that
stuff
up
my
name
of
the
mob,
so
once
I
write
that
out,
I
wrap
that
up
I
like
this
more
in
the
curriculum
and
693
and
CI
adoption
journey
as
well.
So
that's
what's
going
on
over
here
in
my
world!
D
B
B
The
quick
question
Jackie
on
the
solution,
validations
like
how
do
you
like
how
are
they
mostly
performed
like
they
use
a
figma
prototype
or
sketch
prototype,
or
is
that
with
the
product
effort
after
it
has
been
released
like?
What
is?
How
do
you
want
a
virtue,
proach,
the
solution
of
elevation
is
most
often
and
anyone
else
please
chime
in
you're
doing
them
quite
often
for
just
even
if
you
do
it
once
it's
also
value
yeah.
D
D
The
first
time
so
I
just
usually
use
either
like
lo-fi
mocks
to
then
inform
a
figma
implementation
and
usually
what
happens
is
I'll
go
in
with
these
customers
with
a
low
Phi
representation
that
I
felt
and
once
I
validate
that
like
the
problems
right
and
that
I'm
going
in
the
right
direction,
I'll
provide
that
hi,
Anna
and
usually
hi
honest
and
all
these
calls
with
me
anyways
but
she'll.
Take
that
low
Phi
and
build
it
in
figma
and
then
we'll
put
the
figma
in
front
of
customers
either
asynchronously.
D
G
I
could
follow
a
pretty
similar
structure
where
we
tend
to
do
high-level,
low
fidelity
testing
just
to
make
sure
we're
on
the
right
track.
Then
we
build
a
nice
polished,
figma
representation.
We
tend
to
do
kind
of
formal,
moderated
testing
where
it's
here's
the
problem
that
you,
the
user,
going
to
experience
here
at
the
tasks
you
need
to
perform
in
order
to
resolve
the
problem.
Please
perform
these
tasks
on
the
prototype
and
then
we
kind
of
evaluate.
Can
they
do
it?
Is
this
meeting
their
expectation
and
then
there's
a
high-level
conversation
of?
G
Did
we
activate
accurately
represent
a
problem
you
faced
before?
Does
the
solution
match
the
things
you've
done
before,
not
just
the
situation?
We
gave
you
stuff
like
that
and
then
once
we've
gone
through
all
that
process,
we
feel
really
confident
when
we
build
it.
So
it's
pretty
rare.
We
test
the
actual
product.
B
Yeah
thanks
in
terms
of
like
bringing
it
in
from
the
lace-like
customers
is
like.
That
is
one
of
those
things
right
like.
When
can
you
call
it
a
successful
solution?
Validation?
Is
it
more
of
like
you
know
like
if
you
test
it
normally,
you
know
like
a
like
a
problem
of
elevation
or
like
usability
research.
B
You
bring
them
from
the
VAT
least
like
five
five
users
at
minimum,
to
kind
of
have
that,
like
confirmed,
like
eighty
percent
of
80%
of
the
problems
kind
of
show
themselves,
if
you
do,
you
know,
walk
through
the
same
thing
with
at
least
five
users.
There's
been
like
a
scientific
thing
that
has
been
proven,
but
you
know
I
like
do
you
do
the
same
with
customers?
Do
you
pass
at
lease
it
across
like
five,
five
customers,
or
is
it
just
like?
How
does
one
customer
kind
of
thinks
this
is
cool?
Let's
move
forward!
G
We
send
a
run
with
a
minimum
of
five.
We
want
to
go
for
eight
people,
all
attempting
to
represent
different
user
types
and
then,
if
there
are
entirely
different
personas
that
are
also
going
to
be
utilizing
this
feature
we
might
even
double
it
at
that
point,
so
five
developers
and
then
five
system
admins.
If
it's
kind
of
a
broad
range
thing
I,
we
work
really
hard
to
avoid
one
person,
one
user
kind
of
validating
the
entire
idea.
Unless
it's
really
either
very
specific
and
they
have
exactly
the
problem,
we're
testing
or
that's
it.
D
Not
gonna
lie
I've,
definitely
built
things
for
customers
before.
In
my
past
life,
like
first
Pacific
customers
and
I,
really
I've
only
like
validated
it
with
a
specific
customer
get
laughs,
it's
a
little
bit
easier
to
solicit
feedback
from
wider
ranges
of
the
individual
contributor
up
to
an
enterprise.
So
we
have
like
a
good
pickin
of
whoever
we
want
to
screen.
We
can
screen
with
that
validation,
much
like
Anne
and
Tim.
E
And
I
guess
that
yeah,
that's
a
good
point.
Cuz
like
saying
talk
to
five
date:
users,
that's
like
four
segments,
so
if
you
have
different
personas
or,
and
that
can
even
be
like
a
person
who
could
be
an
on
github
user,
that
could
that
could
be
a
different
kind
of
dev
type
of
persona.
You
need
five
to
eight
percent
met.
It's
not
five!
Eight
total
and
you
have
three
different
personas
to
talk
to
you.
You
still
need
like
five,
at
least
from
each
segment.
So
that's
why?
E
When
you're
writing
your
hypothesis
and
your
goals
and
objectives
you
really
need
to
to
be
focused
on
who
is?
It
will
never
prove
this
for
me,
how
many
of
them
do
I
need
to
talk
to
you
know,
because
that's
that's
where
the
exponential
mists
of
research
can
hit
you.
You
know
very
soft
space
very
hard
to
be
hard
when
you
you
get
to
too
many
people
very
quickly.
Also.
D
The
benefits
of
dogfooding,
though,
if
you
run
through
dogfooding
prior
to
releasing
you,
get
a
validation
from
the
entire
employee
base.
So
typically,
you
can
refine
higher
quality
feedback
in
the
solution,
validation
outside
of
get
lab.
If
it's
like
an
improvement
you're
releasing
to
the
wild
after
it's
been
dog
food,
it
depends
on
the
order
you
go
within
right,
sometimes
see
me,
skip
dog
quitting
the
district
to
the
customer,
face
audience.
E
And
in
the
only
caution
I'd
have
around
dog
screaming
is
just
make
sure
you're
taught
your
dog
fooding
with
the
right
people,
because
we
are
get
or
get
I'm
get
lebas
ask
and
we
live
and
breathe
it.
And,
if
you're
trying
to
go
after
somebody
who
is
not
a
gitlab
user
or
is
using
something
different
and
we
don't
internally
use
something,
that's
different.
E
But
it
doesn't
have
to
be
done
with
personal
participants,
because
you
can,
if
you
have
customer
relationships
like
your
p.m.
has
customer
relationships
with
people,
you
can
use
them.
It's
just.
You
need
to
make
sure
that
you
don't
always
use
like
the
same
five
developers
for
all
the
things.
So
if
you
have
enough
people
you
know
so
you've
got
twenty.
You
can
rotate
them
through
that
be
okay,
but-
and
sometimes
it's
nice
to
have
a
mix
between
both
because
first
look
can
be
a
little
bit
more
wider
audience
Dan.
G
Some
works
pretty
hard
to
so
on
those
lines
of
what
Laurie
was
saying,
where
there's
a
customer
or
a
couple
of
customers
who
specifically
looked
for
our
feature
or
have
not
been
able
to
move
over
to
our
product,
because
this
feature
set
will
test
with
them
in
combination
with
some
people
from
first
look,
so
that
we
know
we're
satisfying
a
need
that
we
heard
in
the
first
place
as
well
as
this
works
for
a
broader
range
of
people.
So
we
try
to
mix
it
up
every
time.
F
D
From
my
seat,
I
I
used
always
a
mix,
I
would
say
sometimes
I'll
reach
out
to
the
enterprise
customers,
but
I
find
the
enterprise.
Customers
have
really
high
expectations
that,
if
you
show
them
something
and
they
give
you
feedback
the
instrument
it
even
if
it's
not
exactly
where
you're
wanting
to
go
with
it.
So
I
try
to
temper
that
expectation
record.
The
feedback
create
the
issue.
She
had
the
issue
with
them
and
let
them
know
that
this
is
an
iteration
that
we're
building
from
a
product
management.
C
It's
good.
You
brought
that
out
because
we
you're
bringing
that
up,
because
I
think
that's
something
that
when
people
buy
software
I
did
they
come
from
like
another,
completely
different
model
in
which
it's
a
lot
of
it's
more
waterful
right
like
for
most
people.
You
know
in
the
in
the
sense
that
they
kind
of
like
say:
oh,
we
need
these.
How
long
it's
gonna
take
you
know
like
they
show
ID.
C
It's
also
important
when
we're
talking
to
customers
to
explain
them
a
little
bit,
how
we
work
and
how
and
that
we
have
the
concept
of
like
an
MVC
that
will
ship
fast
and
we
try
to
bring
the
solution
and
I
think
what
most
customers
are
very
appreciative
of
that
like
when
they
understand
why
we
do
it.
How
we
do
it
then,
like.
G
C
A
If
not,
then
we'll
move
to
the
next?
So
the
next
topic
is
just
an
update
from
me
that
there
is
one
dog,
visualization
feedback
solution,
model
validation,
that's
underway
and
I've
also
started
off
working
on
the
design
guide
for
the
Jenkins
file,
dropper
solution,
validation
and
since
the
verify
area
was
almost
empty
in
ducktail,
so
I
have
started
to
log
all
of
the
validation
exercises
and
future
research
work
that
I
do
there
as
well,
so
yeah.
That's
all.
A
A
C
C
You
know
like
I,
think
that's
very
important
and
I
think
I'm
I,
don't
think
we
do
enough
of
that
and
I
think,
like
especially
when
you're
working
remote
I
think
it's
very
important
because
we
work
co-located
you
you
do
that
by
like,
let's
go
up
and
grab
lunch
and
then
you
talk
about
other
stuff,
you
know
but
yeah
we
I
mean
we
have
the
coffee
chats
and
we
have
all
that
stuff.
But
if
we
do
it
as
a
team
and
we
like
organics,
organize
the
activity,
then
it
makes
sense.
C
Like
this
thing
that
it's
basically
I
don't
know,
I
need
fidgets
with
these
one
is
for
featured
toys,
but
these
monies
for
basically
I,
don't
know
how
to
explain
it
like
it
was
a
table.
Then
a
phone
holder
got
it
yeah
exactly
yeah.
Let's
I
need
to
be
touching
all
this
stuff,
but
I
have
one
toy
here.
Let
me
find
one.
B
B
Is
like
one
more
squeaky
and
it
is
like
a
cube
with
six
switches
on
it
yeah,
but
it's
like
25
years,
it's
been
wondering
like,
should
I
buy
it
or
not,
is
it
worth
it
or
is
it
gonna
be
another
thing
that
I
just
laying
around
some
plastic?
I
don't
know
like,
but
I
think
it's
gonna
be
awesome,
but
I
didn't
order.
I.
C
A
C
I
think
we
should
do
it
next
next
week,
though
I
mean
like.
Usually
what
we
do
is
that,
after
the
milestone,
we
say
what
went
well
doing
the
release,
one,
what
didn't
go
well
and
what
can
we
improve?
It
just
spend
some
time
talking
about
those
things,
but
since
it's
not
the
19
year
so
like
this
release
is
still
on
it's
almost
finished
but
not
finished,
then
I
think
we
should
wait
until
next
week.
Great.