►
From YouTube: CI/CD UX meeting - 2020-11-18
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
The
things
from
them-
and
I
know
that
that's
not
necessarily
the
case
with
with
you
and
tell,
but
the
idea
is
that
we
need
to
go
back
and
either
look
through
the
research
to
verify
that
these
are
the
right
jobs
to
be
done,
that
that
are
appropriate
or
we
need
to
go
to
our
users
and
have
those
job
interviews
with
them.
Just
to
make
sure
that
we
didn't
miss
anything
that
might
be
critical
or
we're
putting
too
much
emphasis
on
something.
That's
not
so
critical.
Like
you
said.
A
You
think
that
things
have
changed
in
the
space,
so
just
just
to
put
that
down
as
an
idea
in
case
you
guys,
ladies
haven't
thought
about
it
yet
and
then
the
other
thing
that
might
be
helpful
is
to
consider
running
a
survey
similar
to
what
ian,
and
I
believe
james
is
doing
as
well
for
testing
to
get
a
sense
of
prioritization
for
the
jobs
to
be
done,
especially
because
ci
is
big,
and
I
I
see
that
you
say
end
to
end
workflow
you're,
going
to
really
need
to
get
you're
going
to
really
going
to
have
to
define
where
to
start
and
where
to
stop.
A
Because
you
you
shouldn't,
have
somebody
tried
to
do
it
more
than
an
hour
more
than
an
hour
they're
going
to
get
tired,
and
so
knowing
how
big
ci
is.
You
may
have
to
look
at
this
category
maturity
scorecard
as
several
score
cards
that
you're
going
to
have
to
go
through
in
order
to
get
that
entire
process,
just
because
I
know
how
many
variables
there
are
when
you
go
through
that
ci
process.
So
getting
the
prioritization
of
the
jobs
to
be
done
might
help
you
to
understand
which
ones
you
should
do
the
scorecard
for.
B
I
mean
I'm
not
sure
the
way
I'm
verifying
is
perfect,
but
I
just
mentioned
like
what's
the
process
that
I'm
following,
so
all
the
researchers
that
I
am
like
conducting
and
the
data
that
I'm
analyzing,
what
I'm
doing
the
process
is
that,
while
I'm
highlighting
and
tagging
information
there,
I
also
tag
anything
that
I
feel
could
be
relevant
for
extracting
our
jobs
to
be
done
and
later
I
go
and
revisit
that
and
like
create
something
and
log
it
in
a
spreadsheet
right
now,
I'm
maintaining
a
spreadsheet
which
I'm
going
to
like
put
all
of
this
information
in
our
handbook,
pretty
soon
so
drink
the
link
for
the
spreadsheet
here,
but
yeah.
A
A
You
don't
have
time,
but
it
might
help
you
to
kind
of
get
a
sense
of
what's
important
to
them
from
their
whatever
they
need
to
do
their
chat
tasks
at
hand,
and
it
might
also
allow
you
to
uncover
something
that
might
be
missing
or
give
you
a
different
sense
of
prioritization
than
you
are
getting
from
your
research
that
you're
conducting
great.
C
Yeah
and
I'm
I'm
also
curious
about
how
you
did
the
prioritization
work.
Can
you
just
talk
a
little
bit
about
I'd
like
to
learn.
D
Sure
we,
based
on
the
research
that
we
had
done,
we
had
created
a
list
of
the
main
jobs
to
be
done,
and
then
the
tasks
that
we
associated
with
those
jobs
to
be
done
from
there.
We
put
out
a
survey
first
internally,
asking
individuals
to
rate
looking
at
the
five
jobs
to
be
done
that
we
had
at
the
time
organize
them
based
on
topping
the
highest
priority
in
the
bottom
of
the
list
would
be
the
lowest
priority.
D
Then
we
asked
them
for
the
two
jobs
to
be
done
that
were
the
highest
priority
for
them
to
look
at
the
tasks
that
we
had
associated
and
provide
some
answers
to
there.
How
important
is
it
versus
not
very
important
and
if
there's
any
tasks
that
you
would
associate
with
this
job
to
be
done?
That's
not
there.
We
use
very
different
language.
Jobs
to
be
done
is
kind
of
a
structure
that
we're
familiar
with
now,
which
is
awesome,
but
not
everyone
is
so
instead
of
saying
jobs
to
be
done.
D
It
was,
I
don't
remember
the
phrase
now,
but
it
was
not
using
our
jargon
as
it
were,
and
then
once
we
got
the
details
back,
we
discovered
that
things
that
tasks,
especially
that
we
thought
were
incredibly
important,
were
less
so,
and
there
were
other
tasks
that
were
very
important
to
them.
One
example
is
that
if
they
were
troubleshooting,
they
want
to
be
able
to
see
the
errors
from
their
pipeline
quickly.
D
We
assumed
that
was
kind
of
in
the
middle
of
our
run,
but
it
ended
up
being
a
very
high
priority
and
the
results
of
that
helped
tim
and
I
structur
change
the
structure
of
our
strategy
to
make
it
more
important.
We
started
working
on
them
earlier,
putting
more
focus
into
them
and
because
of
the
research
we
did,
we
discovered
higher
priority
things.
We
then
followed
up
with
more
qualitative
research
of
we
heard.
This
was
really
important
to
users
like
you.
Why
is
it
important
to
you?
What
do
you
do?
D
C
Yeah
just
wanted
to
have
an
idea
of
like
what
you
asked
and
or
the
stuff.
So
that
was
super
clear
to
me.
That's
awesome.
Can
you
share
ian?
Can
you
live
here
like
if
you
have
an
issue
or
something
because
I
think
I
I'm
gonna
need
something
like
that
for
for
verify
as
well,
so
I'm
just
yeah.
I
want
to
to
get
some
inspiration,
awesome
and
yeah.
I'm
gonna.
I
can
also
share.
C
C
And
issues
perfect
and
just
a
feedback
vitica.
I
would
consider
moving
this
comment.
You
left
here
to
an
issue
or
epic
or
something
about
your
steps,
so
that
you
can
give
more
visibility
and
use
as
a
tracker.
You
know
for
what
you're
going
to
do
with
this
initiative
or
the
the
maturity
scorecard
for
for
continuous
integration.
C
C
Oh
next
one
is
it's
vindicas
what
you're
still
typing
so
take
your
time.
B
Oh,
it's
mine,
okay,
this
is
kind
of
resolved
because
I
saw
your
comment
because,
but
I
would
anyway
talk
about
it
that
I
I
kind
of
got
confused
about
the
boundary
for
our
ux
dod.
So
I
know
that
when
it
starts
like
for
the
entry
criteria
of
any
item
into
the
workflow
design,
it
should
first
of
all
should
have
successfully
exited
the
problem.
Validation
phase.
Right
I
mean
the
problem
should
be
well
validated.
B
The
description
should
be
clear
and
we
should
have
the
use
cases
listed
in
all
of
that,
but
when
it
goes
into
workflow
design,
that
means
if
it
is
coming
from
problem
validation
phase.
That
means
we
are
creating
prototypes
first
and
then
so
after
creating
prototypes.
The
next
step
is
to
validate
that
solution.
I
mean
take
the
design
to
our
users
and
kind
of
validate
with
them,
if
that's
in
fact,
what
they
are
looking
for
and
then
move
to
the
development
phase.
B
So
it
got
me
thinking
that
is
solution,
validation,
something
as
a
phase
does
it
like
is:
does
it
come
under
workflow
design
and
not
as
a
diff
separate
phase
altogether,
because
or
whatever
input
we
get
from
the
solution,
validation
phase
we
again
have
to
act
on
it
and
that
involves
making
changes
in
the
design
and
like
taking
design
decisions
so
that
again
falls
under
workflow
design.
We
can
couldn't
say
that
we
are
leaving
workflow
design,
entering
solution,
validation,
then
again
entering
workforce
and
so
on
so
yeah.
B
Should
we
make
this
change
in
our
process
like
in
the
documentation
that
solution
validation
is
in
inherently
a
part
of
workflow
design
yeah,
it's
kind
of
like
a
design.
C
Solution,
validation
altogether
right,
yeah
right.
I
think
it
really
depends
on
how
you're
applying
it.
I
see,
teams
that
they
have
a
very
structured
like
they
really
follow
the
handbook
and
they,
you
know,
go
through
all
these
steps
to
kind
of
enforce
the
iteration
enforce
the
the.
How
do
you
call
it
the
product
development
flow?
I
agree
with
you.
The
way
I
was
working
with
the
jackie
was
that
okay
problem
is
problem
is
validated.
Then
we
do
design
and
solution
validation
right.
C
C
I
feel
like
in
regards
to
the
ux
dod
is
that
we
should
just
apply
the
way
we
want
like
if
you
want
to
apply
it
to,
for
example,
workflow
design
and
just
do
the
prototyping
and
then
I
don't
know
validate
ui
text
talk
to
developers
you
can
and
if
you
don't
want
to
do
that
for
solution
validation,
because
you
were
gonna,
just
yeah
talk
to
people
and
kind
of
apply
the
feedback
on
the
fly.
C
I
would
say
I
don't
want
to
go
and
use
that
list
of
the
ux
dod
for
that,
but
I,
but
I
went
back
to
your
first
point.
I
agree
with
you
that
yeah
solution
validation
is
workflow
design.
So
when
you
try
to
follow
these
steps
one
by
one,
it
doesn't
make
sense.
So.
B
Yeah
and
like
you
said
that,
for
now,
the
version
of
ux
dot
that
we
have
is
for
ci
cd,
ux
team
right,
it's
not
something
which
is
very
specific
to
the
ci
uxd.
So
this
again
brings
up
the
need
of
having
a
separate
ci
cd
ux
page.
B
So
I
can
in
fact
keep
my
team
updated
about
how
I
work,
how
I
am
working
so
that
they
are
not
getting
confused
at
every
step
because,
honestly
for
solution
validation.
Until
now,
until
I
would
say
last
month
how
we
have
been
looking
at
it
is,
we
have
been
validating
the
developed
solution
and
not
while
it
is
in
the
process
of
detail,
and
so
when
I
speak
of
solution
validation
in
a
different
context.
B
It
really
confuses
my
team
members,
but
I
want
the
I
mean
treating
solution,
validation
as
a
part
of
workflow
design.
As
a
standard
I
mean
I
want
that
to
be
the
way
in
which
we
work
as
a
team,
and
we
look
at
our
designs
and
not
only
validating
it
when
it
is
developed,
it
has
been
rolled
out
so
that
later
we
have
to
do
something
with
a
feature
plan
to
roll
it
back.
If
something
goes
wrong
which
actually
actually
did
in
the
case
of
linters.
B
That
was
the
very
first
thing
that
I
worked
on,
but
I
came
to
gitlab.
C
That
makes
sense
to
me:
we
should
be
just
working
the
way
to
fit
best
part
our
teams
and
apply
the
way
you
want
and
follow
the
process.
As
long
as
you
have
results.
A
I
know-
and
we
talk
about
this
in
the
research
team-
sometimes
too,
how
we're
we
struggle
to
strike
the
balance
between
being
very
prescriptive
in
our
steps
to
tell
somebody
you
need
a
b
c
and
d,
but
we
know
sometimes
you
can
skip
from
a
to
d,
and
sometimes
it's
appropriate
to
do
that.
So
it's
it's
hard
to
strike
the
balance
between
wanting
to
be
very
prescriptive
in
the
handbook
to
say
you
have
to
have
this.
You
have
to
have
this.
This
is
part
of
that
workflow.
A
A
Let's
go
back
to
these
pieces
and
say
which
one
is
appropriate
at
this
point,
to
give
me
more
confidence
for
the
stage
that
I'm
in
rather
than
trying
to
continue
to
be
so
prescriptive
to
say,
if
you're
in
this
workflow
design,
you
have
to
do
these
things.
You
have
to
do
these
because
we
all
know
you
don't
sometimes.
B
It's
tough
and
I
kind
of
made
that
I
made
this
point
exactly
what
you
said
in
one
of
the
mrs
that
was
recently
opened
by
the
engineering
team,
because
when
I
mentioned
that
which,
if
we
are
outlining
our
process,
then
why
can't
we
also
make
a
mention
of
uxt
od,
because
we
are
following
that
and
it
they're
kind
of
like
apprehended
by
the
thought,
because
they
felt
that
when
I
mentioned
work
through
design,
that
means
no
design.
B
C
And
that's
one
of
the
risks
of
vedica
of
you
know
splitting
the
design
work
from
the
engineering
work.
We
had
this
conversation,
I
think,
with
tao,
I'm
not
sure
with
one
of
the
the
pm
ux
calls
where
I
don't
know.
I
think
it
was
one
of
the
pm
someone
suggested
creating
ux
issues
for
design
deliverables
and
just
applying
the
ux,
the
workflow
design
label
there.
I
think
that's
super
dangerous,
because
teams
that
are
not
as
mature
and
they
are
not
used
to
you-
know
working
workflow,
agnostic
or
product
design,
product
development
flow
agnostic.
C
C
C
C
I
don't
use
this
honestly.
I
I
don't
even
apply
this
at
the
the
issue
level
anymore.
I
only
do
the
ux
dod
at
the
epic
level,
so
this
is
too
it's
too
specific.
You
know
if
you're
yeah
trying
to
enforce
et
cetera,
anyways.
B
So
I
did,
I
mean
initially,
I'm
very
sure
you
also
tried
to,
and
so
did
I
because
we
were
part
of
the
pilot
that
we
copy
pasted
this
template
to
the
issues
and.
A
C
So
I
think
you've
been
for
the
sake
of
iteration
and
also
to
keeping
one
single
source
of
truth.
I'm
gonna
open
a
merge
request
to
remove
this
information
from
there
and
then,
if
you
have
a
ux
dod
or
if
you
have
like
a
ux,
verify
sorry
ci
too
many
things
page,
we
can
just
link
there
and
then
jackie
can
say
this
is
the
ux
process.
It
goes
to
your
page.
You
know,
because
I
think
you
have
to
define
that
and
be
able
to
keep
these
things
up
in
one
place.
B
That
gets
me
to
another
question.
Sorry,
oh,
we
are
going
to
be
about
time.
No!
This
is
not
the
right
time
for
that.
C
I
just
added
here
it's
a
fyi.
Actually,
I've
figured
today
that
we
have
the
opportunity
canvases
doc
folder,
so
I
just
want
to
share
with
you.
B
C
Problem
validation,
there's
probably
research
issues
created
for
each
each
of
these
opportunity
campuses.
This
was
from
my
congress.
Just
to
give
you
some
background.
I
had
my
pmux
sync
with
the
darren
and
james
today
and
I
asked
them.
Where
can
I
find
all
your
opportunity
cameras?
I
want
to
know
where
you
start
things
and
one
of
them
shared
this
folder
with
me.
So
apparently
this
is
where
the
pms
go
to
place.
The
opportunity
campuses.