►
From YouTube: CI/CD UX Meeting - 2021-08-11
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
So
this
is
the
cicd
ux
meeting
for
august
11,
my
goodness,
a
couple
of
fyi
items
have
a
look,
so
I'm
going
to
jump
to
the
announcements.
If
you
haven't
answered
to
this
survey
yet
about
merge,
requests,
design
reviews,
please
do
so.
Pedro
needs
your
feedback
by
the
end
of
this
week,
august
13th
compared
to
evaluation
feedback
as
well.
A
I
saw
that
this
one
is
assigned
to
you
because
you
you
took
part
of-
or
at
least
you,
you
conducted
a
competitor
evaluation,
less
less
quarter,
but
anyone
really
that
has
seen
the
process
or
that
has
a
that
was
curious
about
it,
that
I
think
it
could
have
had
any
improvements.
Please
leave
your
feedback
in
this
issue
here,
so
that
we
can
make
decisions
about
the
future
of
comparator
evaluations
and
we
have
a
q3
team
building
event
for
the
ux
department,
maybe
you've
seen
in
your
inboxes.
A
Some
placeholder
events
check
your
calendars.
It's
going
to
happen
in
31st
of
august
and
1st
of
september
trying
to
be
inclusive
of
all
time
zones.
So
there's
multiple
events
like
less
quarter
and
this
time
it's
going
to
involve
an
activity
using
the
q3
budget.
So
ux
leadership
worked
with
the
the
learning
and
development
to
pick
an
activity
still
pending,
but
it's
going
to
use
the
50
that
the
company
assigned
to
each
to
each
employee.
So
please
note
that
you
can
only
use
this
budget
for
the
ux
department
event
right.
A
So
if
your
team
buildings,
if
you
think,
if
your
teams
stage
groups,
are
organizing
something
you're
welcome
to
participate,
of
course,
but
just
make
sure
that
they
are
not
accounting
for
that
budget.
For
you
so
ask
and
any
questions
yeah.
Just
let
me
know
and
I'll
ask
around
as
well
to
see
what
what's
needed
necessary
and
my
last
announcement
142
ux
retrospective
is
here.
It
feels
like
it
doesn't
feel
like
it's
been
a
month,
but
just
a
heads
up,
it's
their
feedback
and
input
is
welcome
so
I'll
pause.
A
All
right,
if
not,
then
let's
talk
about
ux
that
so
I
was
going
over
the
the
ux
that
list
for
ci
cd
and
I
wanted
to
just
touch
base
on
you
see
if
there
are
any
questions
about
what
ux.
That
is
how
how
should
we
use
it
or
when
should
we
create
a
ux
step
issue,
mostly
because
when
we
have
these
issues
that
are
not
actually
classified
as
ux,
that
that
impacts
the
performance
indicators
right?
A
So
it
shows
that
we
have
too
many
open
issues
etc
and
add
a
couple
of
examples
here
of
what
is
ux
depth
and
what
is
not.
So
in
the
first
example
oops,
let's
see,
you
can
see
an
issue
that
it's
not
a
ux
depth,
because
mainly
it's
a
proposal
of
how
to
improve
the
feature
so
ux
app
is
it's
mainly
something
that
was
supposed
to
be
delivered
as
part
of
the
mvc.
A
That
was
part
of
the
agreed
scope
of
the
proposal,
but
it's
also
a
ux
related
change
of
feature
anyways,
a
thing
that
relates
to
the
design
system,
so
usage
of
the
components
of
the
the
pajamas
guidelines,
anyways,
anything
that
is
really
related
to
the
scope
of
our
design
system
and
in
the
second
link,
you
can
see
an
example
of
uxdap.
A
When
I
decided
we're
not
going
to
deliver
this
specific
thing
related
to
empty
states,
because
and
then
it's
a
ux
that
so
quick
overview.
I
also
linked
here
some
references,
but
I
kind
of
want
to
hear
from
you
if
there's
any
any
questions
about
what
is
ux
step.
What
is
not,
but
also,
I
want
to
know
how
you
identify
ux
depth
in
in
in
your
workflow
today
and
if
you
see
any
opportunities
for
us
to
improve
that
together
with
with
your
dev
teams,
so
I'll
pause.
B
This
is
a
not
very
common
case,
but
it
has
been
happening.
So
I
have,
I
know
of
two
instances,
the
first
one
I
couldn't
find
a
link
for,
but
for
the
second
one
I
put
the
link
here.
B
So
what
happened
for
this
was
that
in
pipeline
execution,
we
were
trying
to
optimize
the
space,
which
is
there
in
the
pipeline
index
page,
which
was
a
problem
in
itself,
and
so
we
made
this
decision
that
he
would
be
putting
a
kebab
menu
in
as
one
of
the
action
items
so
that
all
the
additional
actions
which
are
not
primary
in
nature,
they
could
just
go
on
to
that,
and
that
also
came
in
very
handy
for
us
when
we
faced
a
problem
where
earlier
what
used
to
happen
was
the
whole
page,
the
artifacts
for
the
entire
page.
B
It
was
kind
of
queried
at
the
same
time
when
the
page
was
being
loaded
and
that
used
to
cause
a
lot
of
delay
in
the
loading
time
so
to
reduce
that
we
place
the
download
artifacts
item
inside
the
kebab
menu.
So
unless
you
go
and
click
on
the
kebab
menu,
it's
not
going
to
query
for
the
download
for
the
artifacts
that
could
be
downloaded
so
that
saved
us
some
performance
problems.
B
Now
from
the.
I
think
this
is
from
the
testing
side
now
that
that
for
the
pipeline
index
page,
I
was
there
to
propose
a
solution,
but
this
also
had
to
be
replicated
on
the
mr
widget,
and
this
was
mostly
in
the
area
of
testing,
so
they
came
up
with
this.
I
mean
you
have
seen
this
in
the
chats
right
that
they
provided
this
option
to
place
an
empty
state
in
the
download
artifact
button
that
the
button
would
still
be
active.
B
I
wanted
to
know
if
this
kind
of
qualifies
as
the
ux
did,
because
for
my
earlier
proposal
this
is
a
deviation
from
that,
but
I'm
not
from
the
other
team.
So.
A
So
this
is
almost
like
a
a
bug,
but
also
a
change
to
how
they
call
it
like
a
roll
back
to
incorrect
state
right.
I
think
the
new
ones
for
for
ux
that
and
what
I
understand
right
from
this
problem-
is
that
the
ux,
the
ux
depth
is
when
we
consciously
generate
a
gap.
A
You
understand
so
this
could
be,
for
example,
classified
as
a
bug
right
that
someone
did
something
wrong
and
not
something
wrong.
Sorry,
folks
that
a
change
affected
a
specific
part
of
the
ui,
and
it
could
also
be,
for
example,
a
ui
polish-
is
it
only
related
to
yeah
the
drop
down
where
something
is
incorrect?
There
I
would
say:
ui
polish
only
covers
visual
improvements
or
visual
changes
to
the
existing
interface
and
the
depth
is
really
result
from
the
intentional
decision
to
deviate
from
that
design
solution.
A
So
I
would
a
bit
tough
to
to
make
that
decision
on
the
spot,
without
like
looking
at
everything
that
happened,
but
this
could
also
be
regression.
So
we
have
a
regression
label.
We
don't
use
that
as
much,
but
it's
a
bug
that
introduced
a
change
to
that
specific
part
of
the
product
and
we
use
that
for
ux
as
well.
So
here
in
the
in
this
link,
we
explain
how
to
use
the
regression
label,
so
I
think
in
this
case
it
could
be
something
that
is
not
ux.
A
B
That
does
make
sense,
so
it
definitely
doesn't
qualify
as
a
debt,
because
this
was
not
an
intentional
deviation.
It
just
happened
in
the
process,
exactly
okay,
okay,
so
all.
A
Right
daniel,
I
think
now
I
only
see
the
initials,
and
so
my
brain
has
to
work
a
little
bit.
C
There
you
go
zoom
just
also
warned
me,
so
I
write
vg's
description
and
I
really
like
well
the
first
part
of
it
when
the
implementation
doesn't
match
the
most
recent
proposal.
I
think
it.
It
fits
really
well
with
the
definition
of
the
depth
as
we
decided
to
have
this
depth,
but
then,
at
the
same
time,
how
do
you
differentiate
the
depth
from
a
party
breakdown
for
iteration
for
later
on.
A
A
My
experience,
creating
ux
depth
and
I've
seen
other
designers
doing
differently
is
that
I
will
identify
something
as
adapt
if
we
consciously
decided
not
to
build
it
as
part
of
a
merger
quest
discussion
that
that's
how
I
usually
do,
because
if
I
know
ahead
of
time
that
we're
not
going
to
implement
something,
then
it's
a
future
enhancement
right.
So
let's
say
that
we're
not
going
to
do
pagination
on
this
list
because
first
we
are
going
to
show
only
I
don't
know
10
items
at
a
time
right.
A
It's
not
adept
right,
it's
just
an
iteration
on
the
initial
mvc,
but
can
you
give
an
example?
Maybe
it
would
be
best
if
we
could
understand.
C
The
new
ones-
so
I
was
writing
it
down
here,
but
I'll
just
share
my
screen.
It's
it's
the
the
example
that
you
pointed
out
last
week,
so
you
know
if
you
can
see
it
already
so
essentially,
what
this
example
means
is
when
you
have
an
environment
with
a
broken
url,
let's
say,
like
you:
forgot
dot
com
at
the
end,
so
it's
an
invalid
url
or
in
the
case
of
environments,
any
url
that
is
not
https
is
considered
invalid.
C
C
So
what
the
system
does
today
is
it
just
hides
the
button
right
and
then
I
added
the
ux
depth
here
and
hyun
asked
me
to
remove
it
and
the
reason
why
why
I
was
a
bit
confused
is
because
I
don't
have
the
historical
context
of
why
this
decision
was
taken
right.
So
did
we
consciously
decide
to
have
this
as
a
as
something
that
we
will
do
later,
or
is
this
a
bug
in
the
code
that
is
based
on
on
the
developer?
C
In
my
view,
a
disabled
button
would
work
well
here
it's
a
small
fix,
but
then
I
don't
know
if
it's
a
matter
of
a
technical
bug,
a
past
decision
that
we
consider
that
or
a
past
decision
that
we
at
the
time
we
consider
to
be
the
right,
behavior
and-
and
maybe
it's
not
anymore.
So
I
feel
like
from
the
user
perspective,
if
it's
a
a
conscious
decision
from
us
or
not,
doesn't
really
matter
for
them.
C
If
they
see
something
as
an
as
a
usability
problem,
they
will
see
it
as
a
usability
problem
and
that's
fine,
but
then,
from
my
own
perspective,
just
joining
I'm
not
sure
which
which
of
these
parts
were,
were
active
decisions
and
which
were
not
so
makes
it
a
bit
harder
to
classify.
Does
that
make
sense.
A
Yeah
it
does
thanks
for
thanks
for
the
example.
I
think
you
really
touched
on
a
very
interesting
point.
Right
like
it
doesn't
make.
It
makes
no
difference
to
the
user,
but
that's
okay,
because
we
use
ux
depth
as
part
of
how
we
track
our
the
gaps
and
as
a
performance
indicator
as
well
like
are
we
shipping
things
that
include
a
gap
in
user
experience?
Are
we
shipping
things
that
are
incomplete?
Are
we
shipping
things
that
are
not
non-pajamas
compliant?
A
So
I
think
that's
also
a
good
a
good
way
of
thinking
of
what
ux
that
actually
is,
but
also
if
that
problem
did
not
originate
from
like
a
merge
request
right
or
you
don't
know
where
that
comes
from.
A
I
would
assume
that
it's
not
that
you
accept,
because
then
I
don't
know
for
sure
right,
so
it
can
be
a
feature
enhancement
in
this
case
it
can
be
especially
if
you
say,
there's
an
error
right,
there's
something
wrong
happening
here,
not
only
with
the
experience,
but
also
with
how,
with
the
workflow,
with
how
the
user
I
know
goes
to
that
deployment,
page,
etc.
A
I
wouldn't
consider
this
one.
You
accept
because
I
don't
know
if
there
was
a
discussion,
and
that
was
a
conscious
decision
right
so
that
that
already
yeah
it
doesn't
fit
in
the
in
the
description
of
that.
A
So
it's
tough
because
we
don't
have
that
historical
context.
So,
but
so
I
would
assume
you
know,
label
things
that
you
know
they're.
Where
are
they
coming
from,
and
you
can
usually
find
that,
for
example,
if
in
the
issue
description,
if
it's
old,
there
is
a
mention
to
a
merge
request
right
or
if
people
are
discussing
in
the
comments.
A
So
that's
why
I
go
once
a
month
and
I
go
over
everything
and
I
read
the
issue
descriptions
and
I
see
if
there
are
comments
and
discussions
to
understand
if
something's
at
that
does
that
make
sense.
C
It
does
make
sense
yeah
for
me
that
one
of
the
biggest
points
of
contention
is
going
to
a
page
and
seeing
like
a
very
clear
usability
problem
and
then
immediately.
Oh,
it's
a
usability
problem.
So
it's
a
ux
problem.
So
it's
something
we
should
fix.
So
it's
a
ux
that,
like
I
automatically
make
the
the
logical
leap
but
yeah.
I
think
separating
ux,
that,
from
from
like
a
problem
in
the
interface
and
seeing
it
more
as
an
internal
process,
is
what
makes
more
sense
to
to
properly
apply
the
label,
at
least
for
me,.
A
Yeah
and
again,
let's
go
back
to
thinking
it's
intentional
right.
Do
we
know
if
that
choice
was
intentional
or
not,
then
then
I
think
it's
easier
to
decide
when
to
apply
that
the
exact
label,
but
that
was
that.
C
C
I
think
this
is
a
really
good
discussion
and-
and
we
could
tweak
a
little
bit
the
definition
on
the
handbook
to
make
it
more
clear,
because
I
think
reading
just
reading
the
definition
of
ux
that
as
it
is
right
now,
it
bakes
in
a
lot
of
assumptions.
So
it
leaves
a
lot
of
space
for
for
these
small
misunderstandings.
C
A
Yeah
check
the
the
definition
that
this
one
that
I
linked
here,
which
one
here
because
we're
having
the
engineering
we
have
in
the
wax
label
and
in
the
performance
indicator.
But
this
is
the
source
of
truth.
This
one
here.
D
D
Sometimes
there
is
an
intentional
decision
to
deviate
from
the
agreed
upon
mvc,
which
sacrifices
the
user
experience.
What
if
there
is
no
agreed
upon
nbc-
and
it's
just
like
a
contribution
made
by
one
engineer-
and
there
hasn't
really
been
discussions
about
exactly
what
the
proposal
is
and
ux
hasn't
created
a
specific
proposal.
So
is
that
a
ux
step,
if
it.
A
Yeah,
that's
a
good
point.
I
think
that's
why
it's
so
important
right
that
we
are
in
the
merge
request,
review
phase
so
that
we
can
spot
these
inconsistencies.
So
let's
say,
let's
assume,
and
that
happened
many
times
before
engineer
or
person
from
the
community
open.
The
merge
requests
changing
something
that
impacts
the
ui,
but,
for
example,
that
person
did
not
add
an
empty
state
right,
so
our
jobs,
and
what
we
have
to
do
is
to
be
there
to
understand
that
context
and
say:
hey.
A
And
then,
if
we
make
a
conscious
this
conscious
decision
to
not
increase
the
scope
of
that
merge
request,
we
should
create
the
ux
that
as
a
follow-up
right
based
on
the
discussions
that
are
on
the
thread.
So
there
will
be
times
indeed
where
we
were
not
going
to
have
a
source
of
truth
for
the
design
proposal.
But
we
know
how
things
should
work.
We
know
how
things
should
look
like
in
in
regards
to
what
pajamas
is
dictating.
A
So
that's
when
we
generate
that,
but
again,
what's
hazing
here
in
the
handbook
is
that
where
it's
at
the
end
in
case
the
team
makes
a
decision
to
ship
an
npc
that
contains
a
ux
depth,
it's
recommended
to
create
an
issue
to
track
it
as
soon
as
the
change
has
been
released,
so
I'll
give
an
example
of
how
it
happens
in
package
and
I've
seen
them
doing
that
very
well
that
when
there
are
discussions
about
yeah,
something
whatever
empty
state
is
missing,
they
immediately
open
a
follow-up
issue.
A
They
merge
the
emergency
quest
and
they
start
working
on
that
follow-up.
So
I
think
it's
also
important
to
keep
that.
Keep
that
in
mind,
because
indeed
the
reference
right
source
of
truth
sometimes
is
not
going
to
be
provided
by
us
as
part
of
the
the
initial
the
initial
context
of
the
mercy
class.
Does
that
make
sense.
A
So,
to
recap:
you
accept
it's
intentional.
It
deviates
from
either
an
mvc
from
the
x
vision.
I
think
that's
also.
Maybe
that's
what
we
say
in
the
handbook
that
it's
not
really
kind
of
like
what
nadia
said.
Now,
it's
the
ux
vision.
Maybe
you
can
say
that
it's
related
to
the
ux
guidelines,
right
that
sacrifice
user
experience
intentional
addresses
a
gap
right.
A
If
we
don't
know
where
it
comes
from,
then
we
cannot
assume
is
a
ux
that
and
if
we
generate
that
debt
we
should
be
tracking
it
soon
and
we
should
be
well
in
a
way
pushing
for
the
implementation
of
this
steps.
So
we
don't.
We
don't
leave
these
things
hanging
because
usually
they
are
minimal.
When
I
look
at
the
ux
that
lists,
they
are
yeah.
A
Here's
a
typo,
here's
an
empty
stand,
miss
missy,
here's
an
ellipsis,
that's
not
working
and
those
are
the
ugly
things
you
know
in
the
in
the
usa
experience.
So
maybe
any
final
comments
or
questions
on
this
topic
before
we
move
forward.
A
Then,
thanks
for
the
chat,
it's
not
nice
that
we
could
discuss
this
a
little
bit
then
over
to
daniel.
C
Yeah
so
quick
update,
yeah
working
on
closing
the
design
side
of
143
planning.
There's
this
comment
right
down
there,
but
essentially
a
lot
of
the
the
issues
that
were
planned
for
this
milestone
were
blocked
by
the
problem,
validation,
which
is
almost
running
still
not
running
so
yeah.
Basically,
the
the
bigger
effort
to
redesign
the
environments
page
was
blocked
by
the
problem.
C
Validation
and
a
lot
of
smaller
issues
were
blocked
by
that,
so
I'm
aligning
with
with
my
pm
and
our
em
and
trying
to
unblock
whatever
smaller
issue
that
we
that
can
be
worked
in
parallel
with
that.
So
it
was
a
nice
exercise
in
transparency
and
and
delivering
bad
news
in
a
way,
but
it
was
well
received
by
the
team.
So
it's
new
needs
to
need
to
check
up
with
them
and
then
yeah.
The
the
big
thing
is
the
survey
on
the
environments
page.
C
D
Oh,
it's
me
now
yeah,
so
I
started
looking
into
improving
the
size
of
the
empty
states.
Let
me
share
my
screen
and
I
will
quickly
kind
of
give
you
some
context
around
the
problem
that
I
see.
D
So
currently
we
have
several
different
pages
under
cicd,
so
even
if
you
don't
have
ci
cd
set
up,
you
see
all
of
these
links
in
the
navigation,
except
for
the
artifacts.
I
think
it
doesn't
show
up-
and
actually
I
haven't
seen
artifacts
here,
and
I
only
noticed
it
today.
So
I
was
wondering
if
it's
something
new
or
we've
always
had
it,
and
I
just
never
noticed
it.
D
I
don't
know
but
anyway,
when
you
don't
have
cicd
set
up,
you
don't
have
artifacts
here,
but
you
have
all
of
these
different
pages
and
all
of
them
have
different
empty
states.
So
if
you
click
on
ci
cd,
the
parent
item
or
the
pipelines
page,
we
show
this
empty
state,
which
is
the
template's
empty
state
and
among
all
of
the
different
empty
states
that
we
have
for
the
cicd
pages.
D
This
offers
the
best
onboarding
experience,
because
it
provides
you
with
some
information
around
like
what
you're
supposed
to
do
that
hey
you're
supposed
to
use
a
file,
and
there
is
such
thing
as
gitlab.ciml
file,
so
it
kind
of
prepares
you
for.
What's
going
to
happen,
it
gives
you
an
idea
that
you
will
need
to
edit
some
file
to
set
up
ci
cd
and
then
you're
able
to
either
get
started
with
a
basic
template.
D
That
is,
that
has
like
some
scripts
that
just
just
like
echo
scripts
that
don't
actually
run
anything,
but
it
allows
you
to
see
how
pipelines
work
and
what
what
is
a
job
and
things
like
that
or
you
can
select
an
actual
template.
Based
on
your
framework,
then
for
the
editor
we
have
another
empty
state
which
looks
like
this
optimize,
a
workflow
with
csd
pipelines
and
then,
once
you
click
this
button,
it
takes
you
to
the
editor
for
jobs.
D
We
have
yet
another
empty
state
and
by
clicking
on
this
button,
you're
taken
to
the
editor
again.
But
to
me
it
doesn't
really
make
sense,
use
jobs
to
automate
your
tasks
because
a
job,
it's
not
a
feature,
a
job.
It's
it's
an
object
in
ci
cd
and
you
only
start
interacting
with
jobs.
D
Once
you
set
up
ci
cd
and
jobs
appear
here
in
this
list,
so
having
a
cta
here,
doesn't
really
make
so
much
sense
because
you're
not
setting
up
jobs,
you're
setting
mcicd,
so
it
would
make
sense
to
have
like
a
single
place
for
that,
then
for
artifacts.
D
I
guess
it
just
doesn't
show
up
when
you
don't
have
ci
cd
set
up,
but
it's
something
that
I
wanted
to
double
check,
because
again
today
was
the
first
time
I
noticed
artifacts
in
the
navigation
bar
and
we
have
schedules
which
just
has
this
empty
state
and
it
says
no
schedules
and
even
when
you
don't
have
cic
setup,
you
get
a
button
to
set
up
a
schedule
test
cases.
I'm
not
that
familiar
with
this
feature,
but
basically
you
can
create
a
test
case.
I'm
not
that
concerned
about
test
cases.
D
I
think
this
this
empty
state
makes
sense.
But
the
point
is,
I
think
it
it's
confusing
for
someone
who's
just
getting
started
with
ci
cd,
and
perhaps
they
know
nothing
about
cicd,
to
go
to
the
navigation
and
see
all
of
these
pages
and
all
of
them
have
different
empty
states.
And
it's
unclear.
D
Where
is
the
place
where
you
go
to
actually
set
up
ci
cd?
So
if
you
do
click
on
the
top
level,
page
you're
taken
to
the
temple
place
empty
state
great
because
it
offers
the
best
experience.
But
maybe
you
will
click
through
some
of
these
other
pages,
and
then
you
skip
that
experience
all
together.
D
So
my
proposal-
and
this
is
just
like
an
idea-
and
I
want
to
look
into
all
of
those
different
pages
and
really
understand
if
there's
a
use
case,
to
show
them
before
you
set
up
ci
cd.
But
my
idea
is
to
consolidate
the
pipelines,
editor
jobs
and
schedules
page
or
rather
like
hide
them
and
instead
show
a
getting
started
page
with
the
template's
empty
state.
So
it
might
look
like
something
like
this.
D
D
So
you
create
your
configuration
file
and
when
you
run
your
pipeline
for
the
first
time
like
when
you
commit
your
config.
That's
when
you
create
your
first
pipeline
and
you
create
jobs
as
part
of
that
pipeline,
so
that's
when
it
makes
sense
to
start
showing
the
pipelines
page
and
the
jobs
page,
because
we
will
have
something
to
show
there
before
you
set
up
ci
cd
like
one
might
argue.
D
This
is
something
that
don't
mention
that
hey
having
these
links,
it
kind
of
gives
you
an
idea
for
what
gitlab's
icd
is
is
made
of
like
hey,
there's
pipelines,
and
we
also
have
an
editor
and
also
pipelines
are
made
of
jobs,
and
we
give
some
of
the
information
in
the
empty
states,
but
I
think
it
creates
more
confusion
and
overwhelm
rather
than
helping,
because
this
information
is
spread
over
all
of
these
different
pages
and
we're
not
taking
the
user
through
one
single
onboarding
flow.
D
D
So
my
question
at
this
point,
my
main
question
is:
is
there
a
use
case
for
keeping
the
schedules
page,
for
example,
always
there?
Even
when
you
don't
have
a
ci
cd
configuration,
so
you
have
a
new
project,
you
don't
have
csd
and
you
just
want
to
get
started.
Is
there
a
use
case
where
one
would
want
to
create
a
schedule
before
they
have
a
config.
B
I
couldn't
think
of
anyone
from
the
top
of
my
head
so,
but
I
really
love
your
proposal
because
you
are,
I
think,
absolutely
right,
and
it's
not
just
with
your
proposal.
I'm
also
noticing
this
in
other
parts
that
we
sometimes
do
not
allow
users
like
we
don't
purely
focus
on
setting
up
something
and
start
showing
all
the
related
elements
which
kind
of
overwhelms,
and
it
also
like
cognitively,
overloads
them
and
it
affects
their
decision
making
strength
as
well.
A
And
another:
this
is
a
really
good
point,
because
I'm
not
sure
if
you've
seen
that
the
the
pajamas
the
foundations
team
is
working
on.
Okay
are
about
empty
states
in
q3,
so
they're
looking
for
this
four
specific
scenarios,
of
course,
but
we
need
two
empty
states
per
category
to
help
evaluate
the
existing
designs
and
make
sure
not
make
sure
and
and
provide
guidance
on
first-time
users.
A
And
you
mentioned
a
couple
of
times
right
that
someone
comes
to
this
page
and
then
that
doesn't
really
relate
to
them
to
say
it
doesn't
relate
to
the
to
the
action
or
to
the
context
so
look
into
the
kr
and
make
sure
that
you
are
contributing
to
it.
So
we
can
make
these
changes
globally,
and
maybe
you
will
find
other
scenarios
that
are
similar
in
other
product
areas.
By
contributing
to
this
to
this
they
are.
D
A
B
Okay,
should
I
move
to
my
items
all
right.
The
first
thing
that
I
wanted
to
share
with
everyone
is
the
recent
work
that
I'm
doing,
which
is
around
linking
pipelines
by
their
names
or
commit
names
that
they're
related
to
instead
of
making
the
id
clickable,
because
in
our
research
recent
research
that
nadia
did,
she
also
received
this
feedback
and
plus
I
did
something
the
previous
year,
and
there
were
some.
B
There
were
similar
responses
from
users
that
these
various
digits
that
we
show
in
relation
to
any
resource
when
it
comes
to
ci
they're,
not
as
helpful
in
identifying
that
resource
so
for
a
job.
We
recently
made
this
change
where
we
started
using
the
name
of
the
job
as
the
primary
link
to
navigate
to
the
job
on
the
job
index
page.
B
So
we
wanted
to
bring
a
similar
change
to
the
pipeline
index
page
as
well,
and
in
this
issue
I
have
added
design,
but
I
would
still
share
my
screen
to
kind
of
pinpoint
the
strange
challenges
that
I'm
facing
so
I'll.
First
show
like
what
kind
of
changes
we
made
to
the
job
index
page,
so
just
a
second
yeah.
It
used
to
be
like
we
had
this
column
that
was
mostly
indica
mostly
had
the
numbers
to
identify
jobs
as
the
primary
like
the
column
before
the
name.
B
Column
and
names
were
actually
placed
somewhere
down
here
after
the
stage,
but
it
was
a
really
good
feedback
that
jobs
are
not
a
collective
resource.
They
are
singular.
I
mean
a
pipeline
is
made
up
of
many
jobs,
but
a
job
in
itself.
They
have
their
name.
So
why
can't
we
just
call
them
by
their
names,
they're
more
recognizable
that
way.
So
this
is
how
the
change
that
we
made
and
we
wanted
to
replicate
that
on
the
pipeline
side,
but
it
was
not
so
easy.
So
this
is
how
the
python
page
looks
today.
B
I
hope
I
haven't
done
anything
to
this
and
there's
so
much
happening
around
that,
even
when
I
decided
to
move
a
few
things
here
and
there
it
was
very
challenging
because
something
or
the
other
was
kind
of
taking
a
hit,
but
I
started
to
notice
like
where
are
the
places
where
probably
we
can
save
some
real
estate
like
what
are
the
things
that
are
redundant
in
this
context?
B
For
example,
we
always
show
the
identity
of
the
author
of
the
commit
or
the
mr
to
which
the
firefront
relates
to,
but
is
that
as
important,
because
this
is
the
captain
index
pick?
This
is
not
the
much
request
index
page
and
we
have
this
whole
dedicated
column
for
the
trigger,
which
is
an
important
information,
but
can
we
somehow
kind
of
move
it
like
assimilate
into
one
of
the
other
columns
to
make
space
and
after
many
hidden
trials?
I
know
this
has
a
lot
of
links.
B
B
This
is
the
final
one
yeah,
so
I
detached
the
name
of
the
commit
from
what
just
happened:
yeah
of
the
commit
from
the
commit
id
column.
So
this
before
we
had
a
dedicated
column
just
to
talk
about
the
commit
and
the
merge
request.
So
we
had
the
title
of
the
comment:
we
had
the
id
for
the
merge
request
and
commit
id
as
well,
and
that
was
like
treated
as
a
separate
column,
but
I
learned
some
idea
from
the
job
index
page
as
well.
B
So
in
the
job
index
page
we
kind
of
mix
stuff
a
lot.
So
we
have
the
job
id
which
is
presented
along
with
the
commit
id.
So
I
thought
why
can't
we
take
a
similar
approach
and
it's
still
a
leap.
We
need
to
validate
this,
but
to
make
space
and
to
make
the
context
more
stitched.
I'm
trying
different
combinations
of
clubbing
data,
and
I
mean
we
can
use
the
name
of
the
commit
separately
as
a
name
for
the
pipeline
and
how
this
will
come
handy
is
the
pipeline.
C
I
love
this
vitica,
it's
it's
something
that
I'm
trying
to
do
with
the
environments
page.
That
also
has
a
lot
of
information
on
the
table,
and
I
think
you,
you
found
really
good
inflection
points
like
the
the
avatar
and
cutting
down
the
name
of
the
of
the
trigger
to
do
that
so
props.
For
that
sounds
like
really
good
work.
C
Do
you
do
you
have
in
mind
any
any
mitigations
for,
for
example,
if
a
name
was
really
large
or
if
you
need
to
add
even
more
information
on
the
page
like
where
would
you
go
or
is?
Is
this
where
you're
you're
stopping
for
now.
B
So
I
do
have
some
ideas.
I
had
a
meeting
with
nadia
yesterday,
where
we
briefly
discussed
this,
and
that
gave
me
some
more
ideas
about
what
improvements
we
can
make.
So
one
problem
that
I
still
see
us
facing
is,
of
course
what
we
just
mentioned
like
there
is
no
room
for
anything
else
like
it.
It's
too
two-pack
and
we
notice
that
we
are
kind
of
communicating
the
status
of
the
pipeline
in
many
different
ways.
For
example,
let's
look
at
the
second
one,
it
says
running
here.
B
If
you
look
at
the
mini
pipeline
graph,
it
is
pretty
apparent
that,
yes,
it
is
running
then
again
in
the
duration
column.
It
tells
you
it's
in
progress,
so
I
mean
do
we
really
have
to
reiterate
the
same
thing
so
many
times
so
the
duration
column
is
there
to
mostly
state
the
duration
like
for
how
long
did
the
pipeline
run?
B
So
if
the
pipeline
is
in
progress,
we
probably
don't
even
have
to
show
that
so
maybe
this
information
that
which
finally
appears
like-
let's
say
these
many
minutes-
your
pipeline-
ran
for
that
could
appear
somewhere
in
proximity
to
one
of
these
status
and,
above
all,
I
think
there
is
a
possibility
to
actually
merge
these
the
status
label
and
the
mini
pipeline
graph
altogether,
and
that
would
give
us
a
really
good
and
clean
and
breathing
layout
for
the
table.
B
C
Yeah
I
like
how
how
you're,
naturally
converging
towards
a
more
vertical
layout
like
stacking
formation
on
top
of
each
other
and
at
some
point
like
this,
stops
being
a
table
and
starts
being
like
rows
of
cards
one
on
top
of
each
other.
One
interesting
thing
that
that
I
want
to
explore
in
environments
is
allowing
users
to
to
expand
or
or
compress
information
so
depending
on
what
we
know
about
the
use
case
and
which
information
is
important
or
not.
C
We
could
provide
a
more
streamlined
view
and
then
they
can
expand
either
the
whole
page
or
row
by
row
like
okay,
show
me
everything,
and
then
we
can
just
dump
as
much
information
as
they
want.
But
if
we
really
know
the
use
case
and
what
information
is
important
and
what's
a
hierarchy,
then
we
can
provide
a
very
streamlined
experience
that
shows
only
what
they
need
and
it's
hard
to
easy
to
read
and
easy
to
parse.
But
then
we
can
users
can
expand
that
and
see
everything
if
they
want
to.
B
That's
a
great
idea
is
by
any
chance.
Is
there
a
solution,
validation
that
you
plan
to
do
for
that.
C
B
Yeah,
I
would
love
to
be
updated
around
that.
I
have
kind
of
suggested
here
that
since
we
are
making
some
substantial
changes-
and
I'm
not
very
sure
like
how
users
would
take
it,
because
we
are
in
fact
basing
like
we
have
data
to
support
that
this.
Yes,
this
is
a
valid
problem,
but
we
are
still
making
some
big
changes,
so
we
should
validate
it,
and
I
have
also
created
this
issue.
B
This
new
issue
around
the
same
thing
that
I
just
communicated,
which
was
remove
duplicate
status
indicators
on
the
pipe
index
page.
So
this
is
just
a
follow-up
and
because
in
pipeline
execution,
since
we
have
again
been
focusing
a
lot
on
infra,
dev,
reliability
and
availability,
so
that
means
our
like
our
backend
capacity
is
almost
kind
of
plugged.
B
So
we
are
mostly
working
on
I
like
as
a
designer,
I'm,
mostly
mostly
working
on
with
front-end
engineers,
to
make
the
ui
look
better
and
improvements
wherever
we
can
so
yeah.
It's
a
good
time
to
look
at
such
things.
A
Reach
out
to
annabelle,
I
think
she
did
some
validation
or
did
something
similar
insecure
about
this.
This
list
view,
and
then
you
touched
on
on
my
points
like
how
it
is
going
to
look
like
in
different
in
different
parts
of
the
product
right
because
we
reuse
this
table
view
and
we
mix
and
match
this
information
everywhere
and
one
of
the
things.
The
first
thing
I
thought,
when
I
saw
you
changing
the
information
around
or
moving
information
around
is
like.
Oh,
I
know
like
the
release
when
I
was
doing
validation
for
release
management.
A
You
know
in
in
other
product
areas,
because
I
I
from
what
I've
seen
there's
a
there'll,
be
a
huge
impact
in
the
cognitive
load
or
for
people
when
when
we
make
this
redesign,
but
I
do
agree
that,
having
an
option
to
move
things
around
or
move
to
a
second
level
in
the
list,
expand
collapse,
something
we
need
to
to
explore
that,
but
a
lot
of
personas.
So
this
this
might
be
something
that
we
require
yeah
cross-collaboration
just
to
understand
what
are
the
other
scenarios?
C
Yeah,
I
think
that
makes
a
lot
of
sense
diana,
especially
because,
even
though
even
if
vitica
finds
the
ideal
solution
for
pipelines-
and
I
find
the
ideal
solution
for
environments,
I
think
most
areas
at
some
point
will
reach
this
threshold,
whereas
this
should
just
too
much
information
for
the
table
to
hold.
And
then,
if
each
one
of
us
invents
a
new
pattern
that
goes
in
a
different
direction,
then
then
we're
creating
a
new
problem
while
solving
each
one
of
our
own
problems.
So
so
we
should
try
to
align
on
that
for
sure
yeah.
A
We're
empty
states
and
we
had
emerge,
requests
so
lists
and
we
will
have
the
environment.
We
have
so
many
of
these
kind
of
tabular
views,
but
not-
and
this
one
in
particular,
where
we
see
replicated
in
with
the
information
right
is
replicated
in
the
merge
requests,
view
the
list
page
and
we
have
environments
and
we
have
pipelines.
A
I
think
it's
it's
good
to
raise
that
flag,
so
we
can
also
get
their
help
to
coordinate
this
across
the
board.
So
I
don't
know,
maybe,
since
you
all
work
on
it,
gonna
start
the
conversation
start
discussion.
B
Does
the
name
in
the
table?
Does
it
link
to
the
pipeline
for
now
it
does,
but
I'm
thinking
to
remove
the
link,
because
there
are
just
too
many
links
the
status
badge
links
to
the
pipeline,
the
name
links
to
the
pipeline.
Maybe
the
number
can
discuss.
D
I
actually
thought
that
the
name
is
probably
good
to
link
to
the
pipeline
and
I
would
remove
the
status
badge
instead.
But
again
this
like
it's
just
an
idea,
but
to
me
it
seems
like
if
the
name
was
all
the
way
on
the
left.
It
would
be
a
very
clear
cta
that
this
is
this
is
the
pipeline.
So
it's
the
pipeline
name.
D
You
click
on
the
pipeline
name
to
view
the
pipeline
and
then,
if
you
know
to
use
the
mini
pipeline
graph
to
go
to
specific
jobs,
you
can
use
that,
but
but
also
I'd
be
curious
to
see
some
information
around
the
usage
of
items
in
the
table.
It
could
also
be
interesting
like
how
many
people
actually
click
from
the
status
page,
because
it
it's
not
really
to
me
it's
a
weird
component.
B
Yeah,
there's
a
room
of
for
a
lot
of
improvements
and
I'll
definitely
check
in
with
all
of
you,
because
this
is
an
ongoing
effort,
I'm
very
sure,
like
we'll
keep
on
creating
a
follow-up
after
the
other
yeah.
Thank
you.
A
A
No
problem-
maybe
I'm
not
sure
if
you
heard
a
video,
if
you
had
already
dropped,
that
we
are
discussing
that
this
is
a
good
candidate
to
bring
to
foundations
team
and
also
help
them
coordinate.
You
know
how
the
this
this
list
is
being
used
by
different
personas
in
different
product
areas,
so
that
we
don't
introduce
different
patterns
for
release
and
then
for
verify,
but
also
learn
how
other
people
are
consuming
these
lists
and
what's
important
for
them
in
different
contexts,
not
just
in
the
in
the
verify
or
the
release
context.
B
Yeah,
that's
a
good
idea.
I
know
that
we
very
recently
migrated
this
table
and
we
can
definitely
do
some
more
improvements
there,
but
going
to
the
foundations
is
a
good
idea.
A
We
are
a
bit
over
time,
so
I'm
gonna
power
through
the
testing
and
runner
points.
So
gina
added
here.
Some
amazing
comments
on
the
price
management
score
card
that
is
in
progress
so
kudos
to
vitica.
That
is
being
awesome.
Helping
out
this
part
of
the
the
kr
they
one
of
the
ux
department,
kr4
q3,
so
gina
started
looking
into
the
jobs
to
be
done
and
we
are
helping
set
up
a
discussion
guide
and
she's.
A
Also
in
the
discussion
we
started
realizing
that
okay,
the
jobs
we
done
for
runner
are
I'm
sorry,
but
they
are
they're
awful.
So
we
have
to
rewrite
them
and
gina
started
doing
that
as
well
for
the
runa
admin
views
and
also
project
quality
summary.
So
research
is
finished
up
last
week.
Also
thank
you.
Vitica
for
helping
out
and
gina
is
meeting
with
james
looking
at
the
dovetails
insights,
and
I
know
that
she
has
a
plan
for
learning
more
about
the
testing
categories
as
part
of
her
stage
group
onboarding.
A
If
you
have
any
comments
slacker,
so
we
can
continue
the
conversation
and
for
package
not
much
going
on
there.
So
the
stage
group
they're
working
on
the
the
milestone
deliverables
plan,
but
I'm
also
I'll
start
working
on
the
onboarding
plan
for
katie.
So
just
if
you're
curious,
her
focus
would
be
on
the
package,
metadata
dependency,
proxy
ui
and
perhaps
package
cleanup
policies
and
more
to
follow.
She
has
start
date,
I'm
sure
if
I
added
his
here
last
time
instead
of
september
the
6th,
so
it
starts
on
september
6
80..
A
I
know
we
are
a
bit
over
time.
We
don't
have
to
discuss
this
now,
but
I've
been
thinking
about
reshaping
the
sessions
a
little
bit.
I
think
today
was
not
not
the
time
to
do
that,
because
we
did
have
a
very
productive
conversations,
but
I
was
thinking
like
every
other
month
do
mostly
async
or
read-only
agenda
so
that
we
can
focus
on
what
we
did
exactly
today.
A
Talking
about
you
know
one
problem,
upper
stage
group
and
doing
some
sort
of
a
design
co-working
session
and
but
at
the
same
time,
do
some
team
building
or
ice
breakers.
I
think
this
would
also
be
interesting
now
that
we
have
gina
we're
gonna,
have
katie
joining
and
then
yeah
we
can
spend
the
10-15
minutes
at
the
end
of
the
call.
A
B
A
So,
let's
try
it
next
time
I'll,
adhere
ahead
of
time
to
the
agenda
or
maybe
depict
something
put
like
a
plus
one
here
and
then
we'll
see,
which
one
will
be
next
week,
the
one
that
gets
the
most
vote.
One
vote:
no,
how
many
votes
per
person?
How
does
it
work
like
two
votes?
Three
books
per
person.
A
Or
your
games,
if
it
always
has
a
so
many
boring
games,
yes
around.
C
A
But
later
I
want
to
see
daniel's
manga
collection.
I
wonder
if
it's
only
naruto
or
is
it
more
diversified.
A
Right
then,
let's
get
back
to
it.
I
see
the
votes
coming
in,
I'm
also
going
to
vote
later
and
maybe
ask
gina
as
well.
If
she
maybe
there's
something
that
we
can
do
async
and
then
we'll
make
a
decision
in
two
weeks,
we'll
do
something
fun.
Okay,
all
right
and
see
you
later
bye.
Everyone
later.