►
From YouTube: Plan | Weekly Stage Sync 2022-05-25
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).
B
Okay,
hi
everyone,
so
I
put
together
a
list
of
issues
you
might
like
to
be
aware
of
that.
Sasha
will
be
working
at
as
part
of
beautifying,
our
ui
for
15.1.
B
This
is
the
second
iteration
of
the
thing
and
it
has
one
product
designer
per
pair
up
with
an
engineer
to
to
deliver
stuff
fast
without
researching,
and
I
think
its
handbook
paragraph
says
that
the
merge
requests
description
is
the
the
main
I
don't
know
like
source
of
truth
for
it.
I
don't
know
like
help
me
if
you
remember
the
phrasing
as
in
it
doesn't
have
to
have
like
big
planning
and
research
yeah.
B
So
15.1.0,
I
called
a
couple
tech
writers
unawares,
because
delivering
dogs
wasn't
part
of
the
process,
so
you
might
have
noticed
like
something
is
moving
in
the
major
class
ui,
and
this
time,
whenever
you
know
our
stuff
is,
is
going
to
be
touched,
I
made
sure
to
say:
hey,
please
update
the
docs
as
well
and
so
yeah
nick
you
had
a
comment
on
issue.
Headers.
C
C
Oh,
we
can
just
do
this
with
issues
in
epx
and
then
pretty
quickly
kind
of
realize
that
the
structure
of
those
pages
is
not
quite
similar
enough
for
that
to
be
an
easy
change
so
like
that
started
in
that
process,
but
has
kind
of
got
pulled
out
of
that
for
more
deep
discussion
and
planning,
but
the
other
ones
I
think,
are
moving
along.
B
Cool
and
like
I
said,
I'm
bringing
it
up
here,
because
I
noticed
that
they're
all
labeled
with
group
compliance
which
is
such
as
group,
and
so
they
won't
appear
on
plan
issue
boards
and
I'm
never
sure,
because
you
know
how
to
use
these
stage
group
labels
because
you
know
like
I,
don't
have
my
own
group,
so
I
always
apply
the
ones
you
know
that
are
related
to
the
subject
area
of
the
change
being
made,
but
sometimes-
and
I
I
guess
like
plan
engineers,
do
it
as
well.
B
D
Yeah,
just
real
quick,
I
don't
know
if
we
have
it
in
our
handbook
as
the
process
around
when
to
apply
group
label
or
stage
labels.
D
But
what
we
have
been
doing
within
plan
is
groups
are
the
engineers
that
are
developing
it
and
then
the
stage
label
is
the
stage
that
the
feature
is
in
so
for
like
for
these,
it
would
be
devops
plan,
but
then
group
compliance.
D
Also
thanks
marcin.
I
appreciate
you
listing
these
out
because
in
the
last
milestone
there
are
a
few
cases
where
I
think
we
were
kind
of
surprised
around
changes
to
some
of
the
ux
on
the
plan
pages.
So
it's
nice
to
kind
of
see
what
is
coming
up
listed
out
here.
C
Yeah,
john,
just
to
kind
of
vocalize
your
your
question
about
ux
in
front
of
being
able,
I
know
the
last
time
I
mean
I
I
think
I
started
like
just
after
the
last
round
kicked
off
and
it
was
a
little
surprising
to
see
some
of
those
changes
come
through,
and
so
this
round,
like
I've,
been
involved
in
some
of
these
as
on
the
ux
side.
C
But
I
think
some
of
the
feedback
from
the
first
time
was
that
there's
probably
a
bit
more
of
a
need
to
involve,
or
at
least
make
aware,
the
the
impacted,
ux
teams,
I'm
not
sure,
on
the
front-end
side,
what
who's
getting
pulled
in
or
if,
if
there's
awareness
there,
I
can
bring
that
back
to
the
ux
team.
If
that's
an
issue.
B
There
has
been
a
recent
change
in
ux,
I'm
looking
for
building
that,
because
now
ux
designers
are
required
to
review
user
facing
changes,
but
also
via
roulette.
B
You
know
not
necessarily
the
person
assigned
to
the
group
or
to
the
feature
is
going
to
review
it.
So
the
change
is
in
the
ux
process
for
the
designer
that
reviews
the
thing
to
also
ping
the
dri
for
that
area,
when
they're
done
just
just
as
an
fyi,
so
I
hope
hope
it
helps.
B
A
Thanks,
I
think
it's
cool
that
we're
trying
to
like
reintroduce
some
agility
and
that
kind
of
thing
I
just
like.
For
example,
there
was
a
change
made
to.
I
don't
know
if
you
noticed,
like
the.
A
I
don't
know
what
you
call
it
like
just
underneath
the
title
of
mrs,
where
it
used
to
say
the
authors,
the
author
of
the
mr's
name
and
their
username,
and
now
it
says
someone
requested
to
merge
a
branch
into
another
branch
and
nowhere
on
the
mr
anymore.
Does
it
say
that
person's
username
so.
A
Yeah
so
I
mean
like
it's
probably
all
in
the
round:
a
good
change,
if
that,
if
the
username
was
brought
back
in
right,
like
I
said
I
like
that,
the
agility
that
it
brings
I'm
just
a
bit
wary
that
our
like
domain
expert,
ux,
aren't
involved.
C
Yeah
that
same
exact
change,
you're
talking
about
is
one
where
it
was
like
it's
coming
up
now
in
this,
like
other
headers
sort
of
refresh,
but
I
feel
like
had
we
taken
a
slightly
different
approach
where
we
looked
at
like
how
can
we
create
a
header
that
supports
all
of
these
types
from
the
start,
the
approach
might
have
been
a
little
bit
different
as
opposed.
Instead,
we
created
one
for
merge,
requests
and
then
tried
to
apply
it
to
issues
and
then
realized.
C
Oh,
the
issue,
editing
experience
is
not
the
same
as
the
mr
and
it
like
doesn't
quite
make
sense,
so
it's
cool
that
it
got
updated,
but
there's
a
little
bit
of
like
how
do
we
maybe
make
this
gel
a
little
bit
more.
But
you
know
this
is
the
second
round,
so
I
think
some
changes
already
happening.
B
Yeah,
so
we
can
move
your
beep
joan
then
I
will
add
what
he
has
about
feedback
and
we'll
link
to
the
the
retro
issue.
Awesome
thanks.
A
Yeah
b
is
mostly
resolved,
I
think,
on
slack
but
feel
free
to
weigh
in.
A
If
you
disagree
with
me
so
on
the
product
planning
side
of
the
team,
we're
looking
to
introduce
parent
hierarchies,
basically,
issues
can
have
tasks
as
children
or
as
child
items,
and
so
far
we've
built
the
empty
state
of
the
widget
on
the
front
end
into
the
new
work
item
view,
but
I
think
I
I
misunderstood
or
or
misunderstood
that
where
it
should
go,
so
I
think
this
possibly
also
is
because
of
like
project
management
is
kind
of
also
working
on
work
items.
A
So
I
think
a
result
that
sounds
like
that.
It
should
in
fact
be
in
the
old
issue
view
and
I
guess
we'll
move
it
at
some
point
in
the
future
to
the
work
item
view.
If
you
disagree,
please
voice
that
alexandria
indented
your
item
as
well
here,
otherwise,
like
you,
can
check
out
the
work
item
view
in
the
meantime
to
see
what
this
widget's
going
to
look
like
and
already
looks
pretty
good,
considering
it's
just
an
empty
state.
A
So
I
don't
know
if
we'll
be
revised
later
by
the
beautifying,
our
ui
thing
but
looks
pretty
good
to
me.
B
C
A
F
Hierarchies
within
the
issues
and
that
kind
of
appears
only
within
the
work
items,
model
or
logical
model.
So
to
me
it
sounded
that
we
will
add
that
to
the
work
items,
and
I
think
we
had
a
discussion
last
time
that
we'd
love
to
keep
work
items
as
separate
as
possible
from
issues
so
that,
like,
when
you
add
anything
removed
due
to
development,
it
don't
really
affect
user
experience
with
the
current
issues.
F
So
this
is-
and
I
might
not
be
following
all
the
latest
discussions
because
of
the
head
count
reset
so
correct
me
if
I'm
wrong
but
like
to
me.
This
is
slightly
news.
Although
I
try
to
follow
things
so
yeah,
I
don't
know
of
something
like
having
the
parent
or
the
hierarchy
widget
within
the
issues
page
itself.
D
That
discussion
we
have,
I
could
have
swore
we
had
that
discussion
somewhere
also,
but
I
can't
find
it
saying
that
for
the
most
part,
we
are
building
widgets
for
work
items
as
opposed
to
building
widgets
that
are
going
to
be
available
in
the
legacy
views.
D
But
I,
if
I
do
recall
there
was
also
we
added
a
little
bit
of.
I
don't
know
a
little
bit
of
flexibility
in
that.
If
something
is
like,
if
we
really
need
it
to
be
part
of
an
issue
they
need
to
be,
they
should
be
flexible
enough
where
we
are
able
to
use
it
in
an
issue.
D
But
there
has
to
be
a
really
good
argument
to
add
that
to
issues,
because
it's
going
to
take
a
decent
amount
of
effort
to
to
get
widgets
into
issues
and
we'd
rather
spend
that
time
working
on
getting
them
into
work,
items
or
progressing
work
items.
F
F
I
I'd
I'd
say
from
at
least
from
my
perspective
that
we
added
to
the
work
items
apis,
uis
and
so
on.
If
and
if
we
really
need
to
add
it
to
the
old
uis
for
and
and
apis
for
any
reason,
we
can
think
how
we
can
do
that,
but
otherwise
it
feels
like
we
are,
I'm
afraid,
we'll
get
into
this
situation
where,
like
everything,
is
intermixed
up
so
badly
that
it
will
be
hard
to
maintain
and
I'll
I'll.
Let
other
engineers
also
speak
up
to
that,
but
yeah.
A
Yeah,
I
think
the
the
plan
to
to
gradually
move
items
over
into
or
to
start
with,
adding
widgets
to
work
to
work
items
is
good
in
most
cases.
But
I
think
if
we
need
to
build
something
new
on
issues
like
we'll
be
waiting
so
long
for
parity
between
the
work
items
view
and
the
issues
view,
because
it
has
so
many
widgets
that
we
won't
be
able
to
release
that
feature
for
a
long
time.
A
While
we
wait
for
that
party
to
happen,
whereas
in
the
case
of
like
requirements,
requirements
only
really
have
like
title,
what
title
description
and
like
state
or
or
whatever
so
so,
like
it's
much
easier
to
go
from
a
task
which
just
has
like,
I
guess,
a
title
to
like
title
description
and
that
and
then
when
we
need
something
for
something
else,
add
it
and
gradually
fill
everything
in.
G
On
backhand
sides
it
would
be
quite
tricky
to
add
widgets
to
issues
too,
at
least
until
now,
I
thought
that
we
are
about
to
implement
widgets
for
work
items
endpoint
only
if
this
should
change.
It
would
be
good
to
clarify
this
now,
because
otherwise
it
means
implementing
widgets
on
two
different
places
for
backend,
and
I
don't
see
too
much
reason
for
this,
because
if
it
would
be
just
a
matter
of
making
a
widget
available
in
some
ui,
it
would
be
great
if
front
end
could
just
request
this
data
from
the
new
endpoint,
if
possible,.
D
Yeah,
so
would
we
be
able?
Is
the
plan
to
be
able
to
query
a
widget
outside
of
querying
the
work
item
that
makes
sense
like?
Can
we
are
we
going
to
have
in
order
to
get
the
the
widget
data
from
within
a
work
item?
Are
we
going
to
make
a
single
query
for
like
get
like
or
just
work
item,
or
is
it
going
to
be
widget
with
a
id
for
the
widget
and
then
getting
data
at
that
level?.
G
So
it's
going
to
get
which
data
for
a
work
item.
You
would
query
the
work
item
api
endpoint.
I
mean
there
is
no
some
witcher
generic
endpoints.
F
F
Does
that
make?
Does
that
answer?
Your
question,
though,
like
you
really
need
to
query
the
like
to
get
the
work
item
and
then
get
at
least
a
part
of
the
widgets
right
like
like
description
weight
is
really
linked
directly
to
the
to
that
specific
work
item.
Some
some
widgets
may
be
queried
separately,
but
those
are
more
like
associations,
but
then
again,
even
even
even
so.
You'll
need
to
to
get
the
work
item
or
or
the
issue
get
those
like.
F
Let's
say
we're
talking
about
assignees
right,
those
do
have
their
own
like
they
can
be
considered
their
own
things,
but
you'd
still
need
to
know
which
ones
do
you
want
to
to
fetch
like
you'll
need
to
find
the
ids
first
and
then
and
then
directly
fetch
those
widgets.
If
you
will
but
yeah,
I
I
I
don't
know
if
that
makes
kind
of
sense
to
to
query
the
widget
itself
directly,
although
yeah
I
know.
D
Because
on
the
mutation
side,
we're
going
to
want
to
we're
going
to
want
to
update
just
a
widget-
and
I
guess
even
at
that
point-
we'll
have
the
work
item
reference
more
than
likely.
But
would
it
be
possible
to
go
the
other
way
where
we
have
an
id
for
every
widget?
So
we
do
have
the
ability
just
query
at
the
widget
level
or
make
a
mutation
at
the
widget
level
without
having
work
item
reference.
G
Well,
so
for
mutations
we
are
discussing
whether
it
makes
sense
to
have
one
big
notation
for
the
work
item
and
you
pass
widget
data
and
call
the
create
or
update
notation
for
the
work
item
or
you
have
separate
widget
specific
notation.
I
think
this
is
what
you
mean
right.
D
D
Okay,
gabe's-
not
here,
oh
gabe,
is
here
okay,
gabe
question
for
you,
then
do
we
ever
plan
on
having
the
having
multiple
widgets
of
the
same
widget
type
on
a
work
item
page,
because
if
we
go
with
using
like
the
name
as
the
way
to
identify
what
to
get
or
what
query
or
what
mutation
to
get
on
the
widget
level
may
be
hard
if
we
have
like
duplicate
widgets
within
within
a
single
work
item
type.
H
The
only
time
I
could
see
having
duplicates
was
when
we
get
to
doing
custom
fields
or
something
like
that,
because
custom
fields
are
gonna
have
like
a
data
type
like
it
could
be
a
string
or
an
integer,
or
something
like
that,
and
you
might
have
multiple
widgets
that
are
of
type
string
right,
but
I
don't
ever
see
there
being
multiple
of
the
same
widgets
like
two
milestone,
widgets
or
whatever.
I
don't
think
that
that
is
what
happened.
H
I
there
was
a
thread
somewhere
in
maybe
the
original
work
item,
discussion
issue
where
we
talked
about
this,
where
there
would
be
duplicates
when
we
get
to
custom
fields,
but
not
for
anything
else.
Maybe.
F
H
H
G
D
Or
discussions
like
if
we
decide
to
have
like
issue
thread
as
a
widget,
as
opposed
to
the
entire
discussion
section
as
a
as
a
widget.
H
Yeah,
that
could
be
another
use
use
case.
G
Yeah,
I
should
also
point
out
that
now,
at
least
at
this
point,
mapping
of
what
widgets
are
available
to
what
issue
type
or
what
work
item
is
hard
coded
and
we
don't
keep
this
in
database.
So
in
future,
when
we
allow
some
custom
custom
widgets,
we
will
probably
have
to
make
this
dynamic
or
starting
database,
and
at
that
point
it
will
make
sense
to
have
id
for
each
widget
for
each
work
item.
G
G
Exactly
yes,
but
at
this
point
yeah
you
are
right,
but
now
basically
it's
possible
to
have
only
a
single
one.
Widget
of
the
given
type
for
one
work.
Item
yeah,
so
we
just
define
requirements
can
have
description
and
these
widgets
or
if
you
can
have
description
and
a
hierarchy
widget,
but
we
don't,
but
that's
all
yeah.
A
Cool
can
I
paraphrase
gabe's
point
because
I
originally
wanted
to
circle
back
to
your
original
question,
jan
as
well,
which
was
like
we'd,
ideally
have
them
on
both
views.
Right
so
start
with
the
issue
view
and
then
move
the
component
to
the
new
work
item
view
and
like
ideally
like
we'd
split
our
thinking
about
that
and
on
the
back
end
it
would
be
a
single
api
right.
The
work
items
api.
We
don't
want
to
produce
widgets
for
the
issues
api.
A
We
just
want
the
component
to
use
the
work
items
api,
whether
it's
on
the
issues
view
or
on
the
work
items
view.
So
this
is
maybe
a
question
for
donald
and
kasha
and
other
front-end
engineers
on
the
call.
Is
that
going
to
be
possible?
I
know
it's
probably
an
extra
call,
while
it's
on
the
issue
view
right,
because
we're
only
loading
the
issue
at
that
point,
but
I
think
it
would
be
an
extra
call
anyway,
even
if
we
somehow
did
build
widgets
into
the
issues.
Api.
E
E
I
think
there
were
mixed
opinions
there
and
we
didn't
have
any
consensus
on
how
to
go
about
it.
If
so,
here
are
the
scenarios
like
if
work
item
ends
up
replacing
issues
in
the
future,
one
or
two
years
down
the
line,
then
it
is
going
to
have
a
ton
of
widgets
within
the
single
page,
and
if
we
are
going
to
make
queries
for
each
widget
in
the
issue,
then
we
are
looking
at
10
20
queries
running
simultaneously.
E
That
may
be
a
problem
depending
on
whether
one
of
the
query
fails,
and
we
have
to
refresh
that
query
to
make
sure
that
the
data
shows
up.
Alternatively,
if
we
fire
a
single
query
for
all
the
widgets
combined,
then
that
ends
up
creating
the
payload
size,
much
larger
than
what
we
would
want,
especially
for
people
who
are
on
slower
networks.
E
And
if
that
giant
query
response
fails
to
arrive,
then
user
is
staring
at
a
failing
page.
So
that
was
basically
the
discussion
that
we
had
like
how
to
balance
this
situation.
D
Yeah,
so
I
think
we
can
like,
even
if
we
make
smaller
queries,
I
think
that's
fine,
because
everything
will
be
batched
and
it'll
only
like
we're
having
the
issue
john,
that
you
pointed
out
with
participants
where
that
query
is
taking
a
long
time,
but
it's
causing
all
of
the
other
like
on
the
sidebar,
there's
a
separate
query
for
essentially
every
component
there,
but
the
loading
of
all
of
those
components.
Are
you
know
it's
it's
the
the
slowest.
D
The
slowest
query
is
what's
causing
them
all
to
kind
of
load.
Slowly
so
I
mean
I
would
prefer
smaller
queries,
because
then
we
have
the
flexibility
to
like
with
the
participants
example.
If
we
wanted
to,
we
can
pull
that
query
out,
because
we
know
it's
the
least
performant
one
on
pages
that
have
a
lot
of
participants.
D
So
it's
just
a
bit
more
flexibility
there,
where,
if
we
just
had
everything
in
like
a
single
work
item
query,
I
guess
technically,
we
could
still
pull
it
out
and
run
two
queries
of
the
exact
the
same
query,
just
different
requesting
different
fields.
Just
a
bit
tougher
to
to
do
that.
E
D
Yeah,
that's
a
good
point
too
yeah.
It's
a
lot
easier
to
to
add
subscription
to
make
it
real
time
when
it's
a
standalone
query!
That's
why,
ideally
for
for
like
planning
hierarchy,
we're
just
making
a
like.
I
think
we
can
still
query
at
the
work
item
level,
but
if
we
were
able
to
just
have
like
widget
with
a
widget
id
and
then
get
the
data,
it
might
be
a
little
easier
on
the
the
front
end.
But
if
we
can't
do
that,
we
can't
do
that.
A
Just
a
quick
question,
so
tian's
point
like
in
the
short
term,
there's
nothing
like
in
the
framework
like
no
opinion
in
the
in
the
view
framework
or
anything,
that's
stopping
us
from
loading,
the
ish,
the
old
issue
page
and
for
this
widget
requesting
the
work
items
api
to
provide
a
list
of
children.
Right,
I
mean
we
can
use
that
work
items
api
on
this
view
and
use
it
in
future.
On
the
work
item
view.
D
Yeah
because
we'll
have
the
work
item,
I
d,
so
yes,
it'll
just
be
so
that'll,
be
two
separate
calls,
but
we're
already
making
two
separate
calls
like
where
some
things
are
rendered
in
graphql.
Some
things
are
rendered
in
through,
like
our
view
x,
side
of
things,
so
yeah,
no
there's
nothing.
Stopping
us
from
adding
another
query
to
the
issue
page
for
the
workout
data.
G
Oh
no,
no
problem
at
all,
so
just
one
concern
about
multiple
requests
versus
one
big,
big
one.
So
I
expect
that
many,
which
is
it
will
be
very
cheap
to
actually
load
its
data,
and
I
would
highly
recommend
to
actually
load
this
data
as
the
original
as
part
of
the
original
request.
G
G
So
there
is
a
schema
in
the
issue,
description
of
the
in
the
match,
description
and
you
can
just
run
a
request
and
pick
a
specific
feature
data
you
need
here
so
other
which
data
will
be
ignored.
So
you
can
easily
combine
our
big
query
together
with
a
couple
of
small
small
queries
and
I
would
recommend
not
to
strictly
run
a
separate
request
for
each
separate
widgets.
D
G
Yeah,
you
mean
multiple
queries.
G
So
yeah
you
mean
some
multi
multiplexing,
the
the
graphql
request
right,
yeah.
D
So
apollo
on
the
front
end
automatically
batches
all
the
queries
that
are
that
are
run
at
a
single
time
so
like
on
the
sidebar
of
the
issue
page
every
component.
There
is
a
separate
query,
but
it's
just
a
single
request
to
graphql.
G
G
G
Because
both
queries
will
be
processed
processed
separately,
but
I
don't
know
how
big
overhead
or
asian
time
there
is.
So
I
I
can
answer
now
how
big
penalty
there
is.
E
I
think
we
are
already
doing
similar
approach
in
places
like
issue
boards,
where
we
load
only
initial
metadata,
which
is
required
to
render
the
page
using
a
lightweight
version
of
the
rest
api
and
then
once
the
page
is
loaded,
we
get
the
additional
data
that
is
going
to
take
longer.
If
we
were
to
do
it
in
the
same
request
itself,
I
think
it
is
similar
to
like
downloading
email
headers
and
then,
when
the
email
is
open,
then
you
download
the
email
body.
So
I
think
that
approach
should
be
possible.
G
A
With
10
minutes
left,
we
should
squeeze
in
a
demo
here
from
kashal.
E
Yeah
I'll
try
to
make
it
quick
okay,
so
we
so
gabe
basically
found
an
issue
with
the
epics
bulk
editing,
and
this
was
pointed
out
by
one
of
our
customers.
So
the
problem
that
was
happening
with
regards
to
epics
list
bulk
editing
was
that
whenever
you
click
on
edit
epics
and
then
select
bunch
of
epics
and
then
try
to
add
or
remove
labels,
it
would
end
up
removing
or
adding
unwanted
labels
to
the
ethics,
and
it
turned
out
that
the
approach
that
we
were
using
was
incorrect.
E
Obviously,
and
so
then
I
looked
at
how
it
does
in
case
of
issues
and
even
in
issues
case.
Bulk
editing
is
confusing
there,
so
I'm
just
going
to
demo
the
fix
that
we
have
made,
and
I
just
wanted
a
wider
visibility
from
the
team
just
to
know
your
thoughts
like
whether
this
approach
looks
reasonable,
whether
it
is
acceptable
and
whether
we
can
go
ahead
and
merge
it
and
then
maybe
update
it
for
other
listing
items
as
well.
E
So
here's
what
is
happening
right
now,
so
I
have
so,
for
example,
if
I
select
these
epics
notice
that
the
first
one
has
only
one
label,
this
one
has
two
labels.
Now
when
I
open
the
labels
drop
down,
it
basically
fetches
the
labels
list
and
marks
the
label,
which
is
common
for
the
selection
as
checked.
It
isn't
showing
this
particular
label
as
checked,
because
it
is
not
present
in
this
particular
epic.
E
So
now
the
drop
down
will
only
show
labels
highlighted
as
marked
when
it
is
when
those
labels
are
applied
for
all
the
selected
epics.
So,
for
example,
if
I
want
to
remove,
if
I
want
to
add
this
label
to
this
epic
as
well,
I
just
need
to
mark
it
then
close
the
drop
down
and
then
do
the
update
tool.
It
will
basically
reload
the
page
and
now
all
the
labels
are
added.
E
E
In
case
I
select
the
epics
which
have
no
labels
in
common.
Then,
when
I
open
the
drop
down,
it
will
not
show
any
label
as
checked,
because
these
three
epics
have
distinct
set
of
labels
applied.
So
in
this
case,
if
I
want
to
add
a
label,
I
can
do
so
by
selecting
a
label
that
is
not
present
in
one
of
the
epics.
So,
for
example,
this
particular
label
is
present
in
the
third
item,
but
not
the
first
and
second
one.
E
So
if
I
just
select
check
on
it
and
then
do
the
update
all
it
will
essentially
apply
that
label
to
the
entire
list.
E
So
the
the
key
difference
here
when
it
comes
to
issues
list
bulk
editing,
is
that
it
highlights
the
label
in
this
middle
state
where
the
label
would
not
have
a
checkbox.
It
will
instead
have
a
hyphen
so
the
way
it
works,
I'm
not
sure
whether
we
are
communicating
this
behavior
in
the
documentation,
but
the
hyphen
here
means
that
do
not
touch
this
label
leave
this
label
as
it
is
for
the
issues
that
are
selected
in
the
list.
E
So
if
you
want
to
add
a
label,
you
can
just
select
that
label
and
then
click
on
update
all
and
it
will
update
the
selection.
But
since
the
hyphen
is
this
middle
state
and
from
the
ux
perspective,
it
is
confusing,
at
least
in
my
opinion,
and
even
alexis
agrees
to
it.
So
we
ended
up
at
least
changing
the
behavior
for
epics
list
and
see
how
the
users
take
it
in.
But
then
again,
if
any
of
you
feel
that
the
approach
that
we
are
using
in
issues
list
or
merge
request
list
is
a
valid.
E
B
Thanks
kashan,
so
what
you
found
first
was
your
work.
Yeah.
B
Yes,
so
I
like,
like
from
the
ux
perspective,
I
I
would
prefer
if
we
showed
the
intersection
like
the
what
currently
is
shown
by
the
hyphen.
I
do
agree
with
you
and
alexis
that
the
the
hyphen
is
awkward
because
it
looked
like
a
minus,
so
it
you
know
in
some
other
products
like
gmail,
for
example
it's
in
a
box,
so
you
can
see
it's.
D
B
Of
an
indeterminate
checkbox
so
have
you
thought
about
perhaps
you
showing
it
but
using
a
different
symbol
or.
E
Yeah,
so
the
thing
is
that
the
labels
drop
down
that
we
have
currently
available
in
gitlab.
So
there
are
three
variations
of
labor's
drop
down.
One
of
the
labels
drop
down
supports
this
hyphen
state.
Not
all
the
labels
drop
down
supported
yet
and
right
now,
be
it
issues
or
merge,
request
lists.
There
is
no
way
on
ui
to
communicate
what
hyphen
means
like
there
is
no
tooltip
or
a
pop-over
which
shows
on
hover
like
what
it
means.
E
So
if
we
were
to
show
in
the
indeterminate
state
for
the
items
which
are
part
of
the
drop-down,
then
I
think
that's
an
enhancement
that
we
need
to
work
on
and
be
replace
the
hyphen
with
the
box.
Like
you
mentioned
right
now.
As
far
as
the
epics
list
is
concerned,
we
are
fixing
a
bug
because
currently
it
was
reported
by
customers
that
they
are
seeing
unnecessary
labels
showing
up
in
their
items
when
they
just
updated
only
one
label.
E
So
this
is
more
of
a
fix,
but
then
again,
this
approach
may
end
up
replicating
in
other
parts
of
the
application.
The
issues
list
that
I
demoed
just
now
is
an
older
issues
list.
We
have
a
feature
flag
in
our
code
base,
which
has
basically
a
view
implementation
of
issues
list
and
within
that
view,
implementation.
F
I'll
raise
just
one
point:
I'm
wondering
I
understand
that
it
fixes
a
new
x,
I'm
just
wondering
if
we
should
lean
towards
consistency
first
and
then
implementing
the
the
the
ux
fix
were
or
not.
So
it's
just
like
raising
a
point.
It's
not
a
request
or
anything
just
my
point
of
view.
I
think
I
think
it
may
become
confusing
and
again
people
will
like
customers
will
start
saying.
Well,
why
is
it
behaving
one
way
and
the
other
way
in
the
other
place
and
it's
confusing
and
so
on
so
yeah?
E
Yep
thanks
so
I'll
update
the
mr
and
see
if
we
can
get
the
hyphen
show
up
again,
at
least
so
that
we
have
some
consistency
across
the
lists.
And
then
we
can
work
on
replacing
that
hyphen
with
a
box
with
a
proper
tooltip
representing
what
it
means
in
in
a
different
issue
on
a
different
one
request.
So
yeah
thanks
a
lot.
B
Also,
I
just
noticed
playing
around
with
my
inbox
that
actually
like
they
show
the
the
the
minus
in
a
box
not
on
individual
messages
but
next,
but
on
the
button
that
would
normally
check
or
uncheck
all
that
shows
that
it
contains
a
mixed
state,
but
it
never
appears
on
individual
items.
So
that's
why
that's
why
I
support
probably.
F
Yeah,
so
I
I've
realized
fairly
soon
that
I
have
an
mr
with
removing
some
of
the
deprecated
arguments
on
the
graphqlion
point
and
on
my
one-on-one
with
donald.
He
also
said
that
we
had
something
that
should
have
made
it
to
the
1500
application
removals
or
something
so
I'm
I
was
discussing
with
him
and
I'm
wondering
if
we
can
improve
the
process
and
how
we
can
track
that
stuff
easier.
F
It's
difficult,
because
we
don't
like.
We
only
do
removals
on
major
releases,
but
we
don't
really
have
the
milestones
so
to
say,
created
in
advance
happened
like
a
year
in
advance.
So
like
we
don't
have
we
not
have
an
issue
or
something
that
will
get
pinpoint
to
the
specific
milestone
that
so
that
we
we
would
know
in
advance.
D
D
D
H
I
don't
know
why
we
could
ask
product
operations
in
that
channel.
They
might
know,
I
think,
they're,
the
ones
that
do
it.
F
H
I
think
one
of
the
reasons
why
we
maybe
don't
do
it-
that
part
advanced,
because
that
one
time
we
had
the
11
release,
which
then
we
had
to
go
in
and
update,
like
12
other
milestones
and
change
their
dates
forward.
That
was
annoying.
It's
the
only
thing
I
think
of
I
don't
know
why
we
wouldn't,
but
if
you're
curious,
I
would
just
ask
in
the
product
operations
channel
brian
ray
and
farnesh
are
the
dris
for
that.
So.
F
A
Yeah
I
just
to
imagine
like
as
well
I
copied
in
the
deprecation
process
for
graphql
off
the
top
of
my
head.
I
think
you
have
to
remove
in
a
major
release
deprecate
at
least
six
months
in
advance,
so
anything
that's
not
deprecated
by
1506
can't
be
removed
until
17-0
and
who
knows
what
will
will
be
happening
in
17-0
in
the
world,
so
yeah.
A
I
think
it'd
be
interesting
to
go
through
our
apis
and
kind
of
see
what
we
can
remove,
like
michelle
mentioned,
that
we
used
to
call
due
date
on
epic's
end
date,
and
we
still
support
both
in
the
api
like.
We
could
definitely
remove
that
on
internal
notes.
Everything
is
still
called
confidential
when
it
should
be
called
internal
and
just
having
a
bit
more.
Consistency
would
be
good
so
like
bearing
in
mind
we're
already
in
15
1.
We
would
need
to
enumerate
and
deprecate
all
of
these
things
like
deprecation's,
not
hard.
A
F
Yeah,
I
think
the
problem
is
also,
and
I
might
be
wrong
there,
but
I
think
that's
how
we
document
it
is,
if
you
deprecated
it
in
advance,
but
you
failed
to
remove
it
in
one
major
release.
You
kind
of
have
to
wait
yet
another
year
or
what
not
to
remove
it,
because
we
only
allow
removals,
even
if
it's
deprecated
for
a
long
time
they
only
allow
removals
in
in
like
major
releases.
You
cannot
remove
it
in
the
minor
release.
F
So
that's
that's
where
this
point
comes
from,
because
the
the
amount
that
I
had
is
definitely
like
more
than
half
a
year
long
and
it
has
been
in
deprecations,
but
I
just
failed
to
remember
to
to
add
it
to
the
note,
because
I
think
we
notify
a
couple
milestones
even
before
the
major
release
or
something
like
that
yeah,
it's
a
very
complicated
process,
to
say
the
least.
B
I
think
for
graphql
yeah
attacked
by
0.6
release.
A
Cool,
I
don't
have
capacity
at
the
minute
to
be
the
dri
for
this
investigation
into
end
points
that
could
be
removed,
but
maybe
in
a
couple
of
weeks,
unless
somebody
else
wants
to
take
it.
In
the
meantime,
I
think
we
just
create
an
issue
and
start
stuffing
the
description
with
things
that
we
find
in
the
api.
F
The
issue
gets
lost
as
well.
If
you
put
it
in
the
backlog,
then
goodbye
issue,
but
yeah
I
can,
I
don't
know
I
can
probably
create
an
issue.
Should
I
create
it
in
our
plan
stage
group
about
like
discussing
what
we
want
to
to
do
about
this,
where
there
is
no
need
for
more
discussion,
we'd
rather
go
to
the
product
operations.
What
not
and
bug
them
about
that.
A
Yeah
I
mean
like
anything
really
like
if
we
have
an
issue
that
we
can
start
talking
about
it
in
honestly,
I
would
just
go
through
and
say
like
how
can
we
improve
generally,
not
even
just
remove
stuff
from
the
api,
but
in
the
case
of
like
internal
notes,
could
we
could
we
keep
it
where,
like
you
know,
it's
called
confidential
in
the
api
like
yeah,
probably
but
like
it's,
a
constant
just
extra
cognitive
load
that
we
don't
really
need?
A
So
you
know
in
that
case,
like
yes,
we're
deprecating
something,
but
we
also
have
extra
work
to
add
a
new
field
for
internal
things
like
that.
So
I
just
make
the
whole
issue
about
like
how
can
we
improve
the
apis
generally
from
that
point
of
view
like,
but
definitely
like
anything
that
we
want
to
remove
in
16-0
like
we
need
to
deprecate
by
15-6.
F
A
I
think
that's
us
martin's
items
read
only
and
we're
over
time,
so
yeah
thanks
everyone
for
coming,
see
you
next
week.
Hopefully
thanks
bye.