►
From YouTube: CI PM/UX Weekly on 2020-06-23
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
B
Progressed
that
I
think
now's
the
time
to
start
thinking
about
1303
I
discussed
this
morning
with
Vida
God
issues
for
this
milestone,
ideally,
should
be
done
at
the
end
of
this
week,
kind
of,
as
we
discussed
earlier,
that
design
will
take
up
a
bit
of
the
time
of
engineering
this
release,
but
with
13.3
in
our
doorstep,
I
really
want
to
push
that.
We
make
that
known
right
now.
I
do
DC,
so
I
wanted
to
give
you
the
word
see
how
far
we
are
in
that
sense
and
what
your
plans
are.
A
Not
so
much
focusing
first
on
the
thing's
for
sure
to
add
that
may
need
UX
work
in
13.2
right
for
the
implementation,
whatever
I'm
adding
for
there
three.
It
won't
be
the
my
complete
draft,
but
at
least
I'll
try
to
focus
on
the
things
that
that
that
I
need
to
discuss
with
Vedika
yeah.
That's
pretty
much
my
plan
for
for
13.3
this
week.
A
B
B
I
have
one
recommendation:
if
you
can
and
see
if
you
can
prioritize
the
past
for
yourself,
I
just
did
myself
for
progress
delivery,
see
if
you
can
push
forward
a
new
except
and
or
UI
polish
issue
for
the
13.3
release,
so
tile
can
bring
that
along
in
inside
this
release,
it's
been
trying
to
make
that
a
standard
practice
across
CI
MPD.
Now
ci
is
yours.
So
it's
it's
up
to
you.
C
D
A
Now
I
think
the
thought
here
Whittaker
is
in
that
13.3
planning
issue
that
is
linked
in
agenda
item
one.
What
we!
What
we're
asking
you
to
do
is
go,
make
a
go,
make
a
comment
on
their
to
me
and
tag
me
and
and
give
me
a
what
your
recommendation
from
the
list
of
existing
UX
debt
and
UX
polish
go.
Tell
me
what
you
propose.
We
should
work
on
and
then,
if,
if
I'm
in
agreement,
I'll
move
it
up
to
the
description
that
that's
the
one
one
of
each
that
we'll
focus
on.
A
D
A
A
So,
just
to
be
clear,
Viveca
what
we're
asking
you
do
is
in
this
issue.
If
you
scroll
to
the
there's,
there's
a
list
of
UX
debt
issue
in
the
list
of
you,
UI
polish,
look
through
each
one
of
them
and
you'll
see.
There's
a
checkbox
of
our
goal
is
to
have
at
least
one
listed
per
category
of
debt
or
polish
and
I
I
rely
on
the
designer
to.
Let
me
know
what
they
suggest.
We
should
work
on
next
of
what
they
think
is
the
most
valuable
to
to
deliver,
and
then
just
add
a
comment
here.
A
A
A
So
on
this,
the
the
epic
therefore
UX
review
epic,
if
I
scroll
down
to
and
I
think
the
question
here,
and
you
also
have
an
additional
one.
So,
let's
make
sure
in
that
CIA
needs
UX.
Epic
I
want
to
scroll
down
and
make
sure
that
what
we
have
for
design
work
for
13.2
matches
up
with
the
actual
implementation
issues
for
13.2.
A
Linterna
error
message:
yeah
yeah,
those
those
are
all
correct,
hey
Demetri.
Is
it
correct
for
me
to
think
that
designer
will
move,
remove
things
from
this
design
work
table
as
it
completes
or
as
the
milestone
is
over
and
the
work
is
done?
Is
that
right?
Yes,.
A
B
A
A
B
E
A
A
A
A
That's
there,
but
instead
our
team
members
gave
feedback
in
the
thread
which
created
a
little
more
work
for
a
bit
to
go
and
I
to
kind
of
keep
up
with
that
and
I
I
suggested.
If
they
have,
you
know
they
didn't
want
to
use
the
feedback
thread,
for
whatever
reason
they
at
least
take
the
discussion
to
the
channel
for
discussing
the
dag
visualization.
A
But
even
as
recent
as
this
morning,
I
saw
more
comments
on
that
thread.
I
think
just
general
comments
of
they
liked
it.
So
that's
where
we're
at
I
did
add
just
through
your
awareness
to
our
team's
13.1
retrospective
issue
that
we
probably
want
to
coordinate
better
in
the
future
when
we
announce
this,
whenever
we
have
something
new
that
is
going
out
in
beta,
that
needs
feedback
coordinate
so
that
everyone
knows
when
it's
actually
turned
on
I
just
wasn't
prepared
for
it.
So
that's
for
right
now
that
being
said
kudos
to
the
tikka.
A
We
hadn't
updated
it
yet
because
you'll
recall
at
our
last
meeting.
The
idea
was
the
tikka
would
update
the
UX
research
issue
for
dag
visualization
or
just
dag
research,
and
that
work
would
drive
what
we
put
in
the
public
feedback
issue,
but
she
didn't
get
a
chance
to
do
it
all
in
that
order,
and
so
thank
you
for
reacting
so
quickly.
Vika
on
Friday
by
the
time
I
woke
up
and
was
online
I
saw
that
you
had
added
some
a
lot
of
instructions
for
how
the
usually
what
feedback
we
were.
A
Looking
for,
and
thank
you
so
much
Laurie
for
helping
us
refine
the
questions,
so
they
they
weren't
simply
just
yes/no
answer
type
questions.
It
actually
invited
the
user
to
give
us
more
more
feedback.
Does
that
help
everyone
get
on?
Have
that
context
of
what
was
going
on
with
the
dag
visualization.
B
E
B
A
Mean
the
converse:
there's
almost
40
replies
on
that
thread
of
different
comments,
and
one
reply
could
have
like
three.
Actually,
it
feedback
that
are
completely
different
areas
of
feedback,
we're
looking
for
so,
but
it
was
a
good
lessons.
Learned
I,
don't
think
anything
bad
happened
from
it,
but
it
did
reveal
to
me
that
I
probably
need
to
do
a
better
job
of
keeping
the
engineering
team
in
the
loop
of
what
pmu
acts
are
wanting
to
do.
A
Ideally,
I
wouldn't
have
necessarily
turned
on
that
flag
until
we
were
ready
with
how
we
wanted
to
collect
feedback
right,
it's
it's
one
thing
for
it
to
be
out
there
in
production
disabled,
but
we
have
the
luxury
of
deciding
when
we
turn
the
flag
on.
It
doesn't
have
to
be
immediately
released
day,
even
and
certainly
in
this
case
it
was
turned
on
the
the
business
day.
Even
before
release
yeah.
E
A
E
A
Agreed
when
I
on
my
weekly
meeting
with
with
the
CIA
leadership
team,
we
talked
about
doing
a
slow,
rollout
and
and
starting
with
something
really
small,
which
is
the
the
gate
lab
in
rather
than
all
projects,
including
customer
projects,
but
we
didn't
get
to
do
it
that
way.
So
it
was
a
good
thing
that
I
have
a
thread
started
to
talk
about
how
we
can
improve
on
that
in
the
retrospective
issue
feel
free
to
chime
in.
A
If,
if
you
want
to
add
your
thoughts
there
now,
luckily,
you
know,
even
though
there
was
a
little
bit
of
a
scramble
on
Friday
and
and
probably
a
little
more
as
we
have
to
monitor
this
thread
to
copy
the
feedback
into
the
issue.
I,
don't
think
any
permanent
harm
was
done.
It
was
just
a
little
bit
of
chaos,
we'll
get
better
at
it.
I'm
not
too
worried.
A
So
that
yes
agreed
and
the
good
thing
I
think
is
it's
out
there
and
it
has
so
much
interest
all
of
the
feedback,
and
so
it's
nice
that
we're
delivering
something
that
is
of
so
much
interest,
internal
and
I.
Think
externally,
as
well
for
our
users
I
think
this
week,
there'll
be
a
lot
more
made
about
it
in
our
I.
Think
our
one
of
our
developer
evangelist
has
already
posted
on
social
and
Twitter.
A
A
C
I
just
wanted
to
bring
this
item.
This
point
opted
for
everyone
attention,
so
this
is
coming
back
to
the
merge
requests.
Widget,
okay
are
that
we
have
been
already
giving
a
lot
of
attention
to
Oh,
for
which
I'm
very
thankful,
James
Ramsey,
who
is
from
the
product
department
for
that
machines
at
the
title
just
moment,
yeah
so
product
manager
for
create.
C
He
have
created
an
epic
that
I
linked
below
here
in
order
to
attract
some
of
our
attention
to
who
some
of
the
improvements
that
continuous
integration
can
do
for
improving
a
more
experienced
and,
after
his
opinion,
these
items
that
he
is
bringing
up,
one
of
which
was
already
prioritized
there.
So
just
talking
about
the
other
two,
he
believes
that
those
two
items
are
a
bit
more
important
and
comparing
to
what
we
have
already
prioritized
and
also
I
was
just
talking
today
to
Marcel
and
he
was
highlighting
to
me.
C
This
issue
also
regards
to
the
same
thing
theme
that
is
having
an
interest
from
seed,
but
I've
seen
how
you
are
on
the
second
one,
so
I
just
wanted
to
bring
the
items
from
James
Ramsey
for
attention.
Now
you
probably
have
seen
it,
but
just
like
making
sure
that
we
are
aware
about
that
and
maybe
we're
doing
the
approach
ization
accordingly,
I'm,
not
sure
if
there
is
anything
if,
if
we
can
like
switch
some
items,
if
we
agree
with
the
priority,
well,
information
coming
from
James
just
wanted
to
bring
those
items
up.
B
A
I
I
actually
asked
engineering
last
week
in
our
G
underscore
CI
channel
I
wanted
an
assessment
of
whether
or
not
some
of
that
we
can
achieve
in
in
the
current
milestone
because
Sara
when
she
went
to
size.
This
actually
said
that
let's
break
this
down
into
some
smaller
issues
and
we
didn't
end
up
putting
it
into
any
milestone
yet
because
on
Friday
I,
the
the
engineers
took
a
look
at
it,
Fred
volunteered
to
take
a
look
at
it
and
he
put
his
comments
in
there.
I
still
don't
understand
from
the
team.
A
The
answer
to
my
original
question
is,
which
can
we
do
we
want
to
pursue
all
of
this
in
this
issue,
or
just
one
or
two
I
can
create
separate
issues
on
so
I
asked
again
this
morning
for
the
EMS
to
help
me
figure
that
out
today,
and
so
by
end
of
today,
we'll
either
decide
to
do
a
small
part
of
this.
You
know
reduce
the
scope
to
a
separate
issue
and
I'll
put
the
milestone
on
there
either
current
milestone
our
next
milestone
or
will
be
decide
to
do
this
as
a
whole
in
the
next
milestone.
A
C
B
C
C
Have
we
like
assigned
any
of
those
to
the
milestone?
Is
it
still
is
it?
Is
it
too
late
to
switch
them
to
the
ones
that
Ramsey
and
James
story
is
asking,
or
is
it
still
possible
to
shift
some
of
the
priorities
because
I
know
we
committed
to
do
the
four
from
the
list?
According
to
the
issue
we
labeled
them
was
the
selected
four
priority
from
your
from
your
workshop
that
you
run
I'm
curious
if
we
could
replace
a
few
of
those
with
the
ones
that
changed
proposal.
A
B
A
E
E
A
A
So
I
am
in
that
one
I
made
a
comment
to
James
that
hate,
oh
with
the
EMS
help,
because
I
I
need
it's
gonna,
involve
front
end
and
back
and
work
and
we're
adding
this
after
the
milestone
stars
I
need
their
approval
as
well,
but
I
did
tell
James
in
there
will
make
a
decision
today.
What
can
be
done
in
13.1
s.
A
Apparently
mm-hmm
yeah,
so
there's
I.
B
A
I
agree,
and
at
this
point
the
only
thing
I
would
consider
from
his
list.
I
mean
number
two
in
this
list
is
already
in
13.2
I'm.
Only
considering
maybe
adding
that
misleading
message
display,
because
there's
a
CEO
interest
on
what
we're
gonna
do
with
that.
It
currently
doesn't
have
a
milestone,
but
his
first
one
in
the
list.
It's
gonna
have
to
go
through
our
normal
process
of
being
weighted
in
a
nice
weight
issue
and
considered
for
a
future
milestone.
A
C
A
B
B
A
A
Let
me
show
my
screen
so
we're
all
thinking
of
the
same
thing,
so
we're
talking
about
moving
these
two
sections
right
up
above
under
bug,
fixes
which
I'm
fine
with
but
I'm
curious.
Do
we
want
to
leave
this
one
where
it
is,
which
will
now
be
at
the
very
bottom,
once
I
moved
the
UX
that
then
UI
polish.
B
A
C
B
Now
the
user
experience
section
is
in
between
technical
depths,
use
experience
that
usually
yes
use
experience.
She
like
it
is
a
special
section
on
the
planet.
It
is
not
similar
to
bugs
it's
not
similar
to
UX
depth.
It
is
specifically
targeting
what
is
UX
working
on.
However,
for
now,
let's
you
know,
let's
make
that
section.
B
A
A
A
B
A
A
A
A
There's
research
that
links
just
to
the
needs
weight
issue
and
that
under
tech
debt
is
UX
debt,
and
is
this
a
debt
or
is
this
I
just
think
it
there?
For
now
this
is
some.
This
is
what
you
were
going
for.
B
B
A
E
If
you
guys
don't
want
to
run
away,
I
have
a
question:
that's
kind
of
general
doesn't
apply
here,
but
it's
I
don't
often
get
to
come
to
meetings
and
I
haven't
been
able
to
ask
in
person
it's
mainly
just
about
because
we're
adding
warnings
to
the
CI,
linting
and
I'm
just
wondering
if
anyone
has
any
experience
or
just
information,
they
can
share
about
how
users
interact
with
warnings
versus
error
messages.
So
up
until
now
has
always
been
a
big
red
error
message
and
there's
going
to
be
warnings
now
and
we're
taught.
E
A
B
E
Let's
say
you
get
a
linting
error
and
it
says
you
can't
do
this
with
the
pipeline:
that's
going
to
drive
a
user
to
go
in
and
fix
it
and
I'm
wondering
if,
in
the
same
situation
you
flag
a
warning
saying
that
you
shouldn't
be
doing
this
so
we've
got.
You
can't
be
doing
this
right
now,
but
now
we're
gonna
start
saying:
maybe
you
shouldn't
be
doing
that
and
I
just
have
no
information
and
no
experience
about.
E
A
E
D
I
think
Marcel,
if
you
are
providing
a
link
or
action
or
some
suggestion
on
how
this
should
be
doing
it
rather
than
just
telling
them
that
why
they
should
not
be
doing
this.
That
would
definitely
inside
a
better
response
than
if
you
just
flash
an
error
message
after
they
have
performed
the
action,
because
that's
kind
of
frustrating
for
the
users
I
don't
know
if
this
will
help
you
I.
E
Think
it's
going
to
be
in
the
same
place,
so
it's
gonna
be
after
they've
saved,
for
example,
they've
saved
the
ci
file.
They
could
get
an
error
that
says
you
can't
save
or
they
could
get
a
warning
which
says
they
did.
It
did
save,
but
you
probably
didn't
want
to
do
that,
so
it
feel
a
bit
like
just
unclear
how
people
would
would
react
to
the
warning,
but
it's.
E
D
A
A
One
thing
that
fabio
has
suggested
in
one
of
his,
mrs
is
he
would
like
to
as
one
of
the
iterations
on
this
actually
linking
to,
instead
of
trying
to
give
all
the
information
to
the
user
in
the
message
just
return
on
this
CI
lint
tool,
or
from
the
pipeline
error,
to
link
the
user
to
a
doc
somewhere
in
the
documentation
for
them
to
get
more
information,
and
that,
were
you
aware
that
that
was
what
he
was
proposing.
Yeah.
E
E
It
was
honestly
a
pure
curiosity
thing
if
people
had
experience
with
some
kind
of
differentiation
between
errors
and
warnings
from
user
focused
from
the
users
perspective,
and
it
is
something
we
talked
about
recently
within
documentation
linting,
because
we
we've
added
three
gradations
of
errors
and
warnings
and
suggestions,
and
we've
been
talking
internally
about
how
are
people
editing,
Doc's,
going
to
be
reacting
to
that,
and
some
people
are
seeing
a
suggestion.
Saying
I
must
fix
this
like
it's
been
flagged.
That
means
I've
done
something
wrong
and
we're
we're
talking
about
how?
E
How
do
we
make
people
know?
This
is
a
suggestion
versus
a
warning
versus
an
error
and
not
treating
anything
that
pops
up
as
an
error,
and-
and
it
was
just
due
to
my
inexperience-
that
I
was
just
wondering
yeah
if
there
was
any
research
or
any.
If
you've
heard
discussions
about
how
people
feel
when
they
see
warning
messages
versus
how
they
feel
when
they
see
an
error,
no.
E
A
This
could
be
the
topic
for
tomorrow's
UX
research
meeting
I'll,
throw
it
on
the
agenda.
We
might
circle
back
and
do
a
research
project
and
have
the
users,
because
the
errors
and
warnings
and
suggestions
will
already
been
implemented
and
just
have
them.
Take
a
look
at
those
and
gather
their
feedback
on
what
they
think.
They
is
the
expected
response,
how
they
would
respond
to
them
basically
and
from
that
Marcel
would
probably
drive
what
we
do
to
make
it
clearer
to
the
user.
What
the
expectation
is
for
them.
Yeah.
E
Some
of
the
warnings
like
if
it
saves
it's
clearly
not
a
deadly
mistake,
and
then
how
do
you
react
to
that?
It
was
honestly
curiosity
thing
and
not
not
suggesting
that
that
we
should
slow
down
implementation,
but,
like
you
said,
if
we
can
watch
how
people
interact
with
this
first
iteration
I
think
that
would
be
a
really
great
step
to
see
yeah
to
see
how
they
interact
with
messages
yeah.
A
That's
a
really
good
idea:
I'll.
Add
that
to
our
discussion
for
UX
research
around
this
and
the,
and
just
so
you
know,
Marcel
the
reason
we
even
had
this
story
was.
It
was
something
that
a
community,
a
user
from
the
wider
community,
had
created
the
original
issue
to
talk
about
hey
as
things
get
deprecated
and
new
features
come
along
that
maybe
use
incorrectly.
It
would
be
nice
if
this,
the
CID
link
tool
gave
the
user
heads-up
about
that,
so
they
can
improve
their
pipeline.