►
From YouTube: Plan | Weekly Team Meeting (2021-07-21)
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
Cool
who's
hosting
who's
recording
I
am
and
john,
do
you
have
the
first
item?
Oh
I
do.
I
do
have
the
first
item,
so
this
was
already
resolved
like
a
week
and
a
half
ago
I
probably
should
have
put
it
into
the
ipac
meeting,
but
alex
graciously
agreed
to
be
the
technical
dri
for
work
items
and
for
coming
up
with
a
technical
plan
for
that.
So
thank
you
very
much.
B
And
yeah,
I'm.
I
think
the
next
item
is
also
mine,
I'll
be
taking
a
couple
weeks
off
in
almost
two
weeks.
So
if
there
is
anything
that
I
can
help
to
unblock
as
I'm
the
tri
for
the
technical
stuff
on
the
work
items,
if
you,
if
there
are
any
questions
or
anything
that
I
need
to
be
pushing
forward
faster
to
unblock
everyone
or
anyone,
let
me
know.
C
B
Technical
things,
I
think,
but
some
of
them
can
be
sort
of
respond
to
some
future
iterations,
but
just
work
to
be
done
like
how
do
we
map
each
work
item
type
to
the
widgets?
How
do
we
do
the
hierarchy?
Widget?
How
do
we
do
the
custom
field
and
all
that
stuff
which
currently,
we
don't
have
like
clear,
crisp
answers
to,
but
that's
something
to
be
worked
on.
B
Yeah,
if
we
don't,
if
we
don't
have,
I
don't
remember
what
we
have
in
the
embassy
one.
If
we
don't
customize
any
of
the
work
item,
types
in
the
sense
that
we
would
be
specified,
we
would
be
letting
users
to
specify
which
work
item
which
widgets
belong
to
which
work
item
types.
So
if
we
can
hard
code
that
that's
fine,
we
can
move
forward
with
that.
So
we
can.
B
B
So
that
so,
then
we
are
pretty
much
unlocked
on
the
nbc
one.
I
think
I'll
I'll
have
to
take
a
look
at
the
issues
that
we
have
there
and
dive
a
bit
more
into
details,
see
if
we
really
have
any
blockers
there,
but
I
think
we
should
be
fine.
C
B
The
assignment
will
we
will
need
the
front
end
as
well,
because
the
frontal
would
need
to
know,
I
think
at
some
point
which
was
to
offer.
So
you
have
a
issue
page
you'll
need
to
load
a
certain
amount,
a
certain
number
or
a
certain
list
of
widgets.
If
you
have
a
bug,
page
you'll
need
to
load
a
different
set
of
widgets
and
there
is
like,
in
my
understanding,
there
is
a
slight
difference
in
between.
Does
that
type
not
have
the
widget
active,
or
is
that
widget
not
having
any
data?
B
Yeah-
and
there
are
more
questions
on
how
do
we
handle
lists?
How
do
we
handle
table
like
lists
does
front
end?
Need
that
information
up
front
or
we
can
provide
it
once
we
provide
the
data
so
yeah
that
there
were
some
more
questions
to
be
honest
with,
but
I
think
that's
not
mvc1.
So.
D
I'm
just
going
to
vocalize
that
I
think
all
the
as
far
as
assignees
for
mvc1
all
the
work
item
types
will
have
them
except
for
requirements.
I
think
that's
what
mark
would
say
could
be
wrong,
but
we
can
double
check.
C
E
C
A
Well,
we're
going
to
solve
like
some
problems,
doing
that
it
doesn't
mean
like
we'll.
Do
everything
exactly
the
way
the
the
architecture
blueprint
if
you
like,
would
want
us
to
do
it?
I
guess
because,
because
like
the
number
of
features
that
requirements
have,
is
they
either
have
the
exact
same
features
as
issues?
You
know
what
I
mean
they
don't
have
anything
unique.
I
don't
think,
whereas
when
we
get
to
epics,
they
have
hierarchies
which
are
unique.
C
C
G
G
I
think
it
comes
down
to
where
we
draw
the
line
around
like
what
backend
architecture
means.
As
nbc
0
I
mean
once
we
get
into
like.
I
mentioned
this
somewhere
in
a
comment
that,
like
mvc0
and
nbc,
one
will
start
to
overlap
once
we
kind
of
get
these
initial
three.
I
guess
three
weighted
issues
that
are
in
there
done
and
we
kind
of
have
made
some
of
the
decisions
out
of
the
technical
discussion.
G
G
C
Looks
good,
it's
awesome
to
see
everything
in
already
and
the
plan
moving
forward,
so
we'll
continue
in
iteration
and
planning
breakdown
of
all
of
it.
So
just
let's
keep
populating
them
and
also,
I
think
that
front
end
team
is
going
to
be
kicking
off
their
architecture
now
that
they're
unlocked,
so
that
also
will
start
moving
along.
G
Donald,
it
may
have
been
right
as
you
were
joining,
but
we
were
talking
about
jan
brought
up
the
fact
that
we
haven't
necessarily
designed
the
api
for
how
it
will
change
from
issues
to
work
items
and
specifically
like
around
widgets,
and
things
like
that.
So
I
guess,
when
the
that'll
be
kind
of
that'll,
that
discussion
will
open
up
once
the
front
end
starts
kind
of
working
through
how
those
things
will
get
on
the
page.
H
Cool
yeah,
that
makes
sense,
are
you
primarily
talking
around
yeah,
because
it
is
the?
Is
the
graphql
api
design
going
to
change
depending
on
the
positioning
and
the
existence
of
widgets
in
a
work
item,
or
will
that
be
a
separate
api
being
able
to
get
the
get
the
widgets
that
are
that
belong
to
a
specific
work
item.
A
D
I
need
that
eventually
really
well,
if
you
ever
want
to,
let
somebody
create
their
own
work
item
type
right,
so
you're
gonna
have
to
have
a
cred
for
creating
a
type
and
then
specifying
which
widgets
you
want
to
use,
even
if
they're
all
like
not
custom
widgets,
but
the
default
widgets
right
you'll.
You
will
need
that.
I
don't
know
when
we
want
to
do
that.
Don't
don't
have
to
do
it
for
nbc
one,
but
I
don't
see
another
way
to
like
cred
work
item
types
for
as
an
end
user.
That
makes
sense.
A
Yeah
there's
some
strange
like
design
questions
that
are
raised
by
graphql,
like
if
I
ask
for
all
work
items
of
type
requirement.
I
ask
for
title
description
and
assignees.
Let's
say
I
ask
for
all
work
items
of
type
requirement
or
issue
and
ask
for
title
description
and
assignees
and
work
items
are
requirements.
Don't
have
assignees
what
happens
you
know
I
should
get
assignees
for
the
issues
right,
but
what
does
the
resulting
object
for
requirements
look
like
and
what
happens
if
I
just
do
that
for
requirements
right.
B
I
think
you'll
have
to
pre-load
the
widgets
available
for
a
specific
work
item,
type
first
and
then
kind
of
go
from
there.
That's
one
way
at
least
to
go
through
that
because
that's
where
you
need
to
decide
because,
like
otherwise,
if
you
ask
for
assignees
for
the
requirement-
and
you
get
null
you're,
not
sure,
do
I
display
the
widget
with
the
new
values
or
do
I
just
not
display
it
at
all,
so
you
kind
of
have
to
have
the
definitions
up
front.
I
guess.
B
D
F
Yeah,
I
think
I
think
that's
the
key
you're
gonna
you're
gonna
have
to
know
what
what
widgets
the
the
type
currently
is,
allowing
to
be
visible.
So
between
that
and
what
data
comes
back.
You'll
you'll
know
the
answer.
A
Yeah,
but
I
wonder
like
what
the
graphql
spec
says
like:
is
it
okay
to
request
an
arbitrary
thing
that
doesn't
exist
on
an
object
and
have
it
just
return
everything
else
and
ignore
that
you
asked
for
something?
A
B
So
you
basically
will
get
nulls
for
for
the
requirements
just
because
it
doesn't
support
it
or
it
will
just
not
have
data.
There
is
the
other
aspect
of
it
when
you
switch
types
right,
you'll
have
data,
but
you
don't
want
to
show
it
that
there
is
the
other
facet
of
of
the
coin.
As
well
say
you
had
an
issue
which
had
a
thing.
Is
you
change
it
to
the
requirement?
B
A
That's
weird,
though,
because,
if
forgetting
about
the
front
end
for
a
second,
if
I'm
just
the
user
of
the
api,
I'm
able
to
query
requirements
for
assignees
and
receive
null,
but
I'm
not
able
to
set
an
assignee
which,
like
maybe
that's
the
lesser
of
two
evils,
I
wonder,
does
graphql
have
an
undefined
as
well
as
a
null
yeah?
Probably
not
well.
I
don't
know,
maybe
because.
B
There
will
be
a
way
to
query
for
that
and
I've
pasted
this
sample.
I
think
there
are
better
ways
to
do
that,
but,
like
you
can
filter
out
some
of
these
values
based
offs
of
the
metadata
sort
of
that
your
story,
but
we
need
to
be
careful
also
how
we
store
the
column,
names
and
stuff
like
that,
especially
with
the
custom
companies,
so
that
we
don't
allow
for
sql
injection.
That
will
be
one
of
the
security
problems
that
we
need
to
face.
I
think.
G
I
remember
correctly,
null
is
graphql
has
null
only
like
there's
no
other
falsie
type,
it's
and
that
it's
sort
of
it
almost
sort
of
overloads
like
the
idea
of
what
null
is,
which
is
kind
of,
I
guess
part
of
the
design,
but
also
a
bit
annoying
for
this
specific
instance.
B
But
you
feel,
if
you
filter
out
that
attribute,
it
means
that
you
don't
want
to
return
those.
So
if
you
want
to
see
a
list,
for
instance
of
issues
and
requirements
that
have
assigned
alexandria,
then
you'll
basically
never
see
requirements
in
that
list,
because
requirements
doesn't
support
assignments
right.
E
Well,
so
if
you
would
list
issues
and
requirements
and
ask
for
assignee
where
sne
is
well
yeah,
if
you
would
filter
by
a
signing
yeah,
then
requirements
wouldn't
be
returned
on
the
other
side.
If
the
query
would
be
give
me
all
types
and
give
me
these
specific
fields
for
each
of
the
issue,
yeah,
the
returning.
B
B
A
E
And
we
don't
have
to
discuss
this
synchronously
on
call,
but
we
will
also
have
to
keep
in
mind
how
to
deal
with
rest
api,
because
I
suspect
that
if
we
make
some
changes,
how
issues
work,
then
we
will
need
some
support,
also
in
rest
api
unless
we
completely
deprecate
the
existing
issues,
api
yeah.
So
it's.
B
So
maybe
we'll
need
to
revisit
what
we
do
in
mvc1
then,
because
it
seems
just
just
piles
on
as
we
go
right
like
the
more
we
dive
into
it,
the
more
stuff
we
figure
out.
We
need
to
to
do
so.
I'm
not
sure
if
mvc1
with
the
current
nvc1
is
actually
the
mvc
one
that
we
will
be
doing.
F
I
don't,
I
don't
think
we
need
a.
I
don't
think
we
need
the
rest
api
straight
out
of
the
gate.
A
lot
of
this
is
gonna,
be
behind
a
feature,
flag,
etc,
and
I
think
we
probably
need
to
make
the
decision
that
rest
stuff
is
going
to
be
implemented
on
top
of
graphql
and
start
moving
in
that
direction
anyway.
C
C
A
Yeah
in
the
interests
of
privacy
on
a
recorded
call,
maybe
we'll
skip
that
cool.
So
that's
my
item,
then.
So,
I'm
not
sure
if
this
is
big
picture
updates,
neither
neither
it's
in
context,
but
I
thought
everybody
here
be
interested
to
know.
So
we
planned
this
issue
to
improve
the
performance
of
the
epics
discussion
standpoint
as
a
q30kr,
but
the
root
cause
is
the
same
root
cause
that
is
at
the
root
of
maybe
10
other
issues,
maybe
more
than
that.
A
That
span
like
a
wide
range
of
things,
not
just
discussions
but
api,
end
points
and
so
on:
api
endpoints
for
discussions,
but
also
api
endpoints
for
other
things
as
well.
The
point
is
like
that.
This
is
like
quite
different
from
a
lot
of
the
other
performance
things
that
we've
looked
into
recently,
which
have
been
database
related.
This
is
cpu
and
memory
bond
and
it's
two
with
the
bonsai
pipeline.
A
The
way
I
think
the
best
way
to
approach
it
is
to
try
and
come
up
with
a
single
metric
and
then
set
a
target
for
that
metric.
The
same
sort
of
way
we
did
with
the
test
efficiency
project
and
then
try
to
bring
in
contributions
from
around
the
company,
because
this
doesn't
just
affect
us,
but
it
also
affects
mr
loading
times,
and
you
know
different
parts
of
the
application,
so
brett
you're
on
the
call.
A
I
was
going
to
make
this
a
rhetorical
question,
but
like
maybe
since
you're
on
the
call
you
can,
let
me
know
like
so.
I
noticed
that
you'd
worked
on
some
benchmarking
tools
before
and
I
tried
them
out.
They
were
really
useful.
You
know,
maybe
there's
something
in
that
that
we
could
build
the
single
metric
from
around
the
benchmarking
tools
and
it
takes
a
long
time
to
run
the
benchmarks
and
that
kind
of
thing,
but
maybe
there's
something
there-
that
we
could.
A
We
could
draw
out
and
build
a
single
metric,
I'm
thinking
something
like
if
we
could
create
if
we
could
have
some
seed
data
where
we
could
run
the
pipeline
like
different
parts
of
the
pipeline
individually
on
that
seat
data,
then
anyone
who
wanted
to
make
a
small
contribution
to
this
for
any
size
of
an
improvement
could
test
it
against
that
test.
Data
and
see
if
it's
actually
an
improvement
in
all
conditions
and
then
include
that
on
their
mr,
I
mean
what
do
you
think.
F
I
think
that's,
I
think,
that's
a
good
idea
I'd.
Actually,
I
think
I
have
an
old
issue
out
somewhere.
I
actually
wanted
to
get
basically
daily
or
commit
level
runs
of
the
the
pipelines
to
see
what
the
performance
numbers
were
over
time
to
understand
how
they're
affected
by
different
changes.
So
I
think
that
would
be
useful
too
there's
also
grafana
in
our
plan.
F
Page
reporting
also
some
some
measurements
of
the
bonsai
pipeline
now
they're
now
graphed
out.
So
there's
some
there's
a
few
points
in
there
that
we
can
enhance
on.
If
we
need
to.
A
Yeah
that'll,
be
awesome,
actually
haven't
seen
that.
So,
if
you
ping
me
the
link
for
it
sometime
I'll,
try
and
find
it
after
after
the
call,
but
yeah
that'd
be
really
useful.
Sean
mcgivern
I
mentioned
in
the
comments
on
the
bottom.
You
can.
You
can
read
that
there
like
he
did
a.
I
don't
know
how
to
describe
it
like
a
topological
analysis
of
the
discussions.
End
point
as
it
is
across
all
this
sort
of
well,
there
would
be
percentiles
but
they're
like
durations
right.
A
So
as
you
get
higher
and
higher
up
the
durations,
the
the
least
performance
discussions
are
allocating
hundreds
of
megabytes
of
in
memory
and
taking
a
lot
of
time
in
this
cpu.
So
it's
really
interesting
problem
and
we
get
to
be
like
really
creative
about
it,
because
it's
like
not
a
common
problem
for
us
like
these
typically
ruby's.
Quite
I
think
quite
fast,
at
least
in
it's
not
as
slow,
usually
as
their
data
sources
like.
A
So
when
you
want
to
tune,
you
typically
go
to
the
data
source
and
start
there,
but
this
is
one
of
the
interesting
ones
which
is
actually
cpu.
Memory
binds
like
resource
bind,
and
so
there
may
be
lots
of
opportunities
for
fixes,
but,
like
you,
don't
have
to
be
particularly
technical
to
to
see
this
problem
any
time.
Just
you
go
to
a
deep
link
in
a
in
a
in
a
long
discussion.
A
F
Yeah,
well,
that's,
I
think,
most
of
that's
with
the
redaction
and
the
filling
inventions
and
stuff
like
that,
because
it's
not
it
shouldn't.
It's
not
re-rendering.
It's
not
re-rendering
those
comments
completely,
but
but
it's
also,
I
I
have
to
look
at
it,
but
I
don't
know
if
it's
completely
the
bonsai
pipeline
because
we're
we're
pulling
those
in-
I
don't
know
if
they're
separate
requests
or
from
the
ui
or
they're
pulling
them
in
like
in
one
shot.
F
A
A
E
A
Yeah,
I'm
not
sure
about
that
to
be
honest.
Well,
anything
over
a
second
is
pretty
a
pretty
horrible
experience.
With
regards
to
the
discussion,
so
yeah
I
mean
ten
thousand
out
of
maybe
you
know,
450
000
are
just
between
the
one
second
and
two
second
mark
there's
definitely
some
kind
of
higher
impact,
though,
because
those
those
issues
that
we
have
that
are
related
to
api
slowness
in
the
reference
architectures
seem
to
be
related
to
markdown,
rendering
as
well
and
those
relate
to
higher
memories.
A
So,
even
if
I
guess,
like
even
the
yeah,
so
even
even
the
requests
that
take
less
than
a
second
allocate
on
average,
like
seven
megabytes
I
mean
so
that's
still
quite
a
lot
and
then
between
one
and
two
seconds,
you're
up
to
70
megabytes,
the
ones
that
take
two
seconds
or
more
130
140
megabytes.
I
mean
it
grows
pretty
quickly
like
so,
even
if
we
didn't
see
that
much
of
the
way
speed
increases
we'd
see
like
quite
a
lot
of
improvements
on
our
reference.
Architectures.
A
Thanks
for
typing
kristen
yeah,
I
knew
for
the
next
one.
E
Yeah,
just
a
quick
update
that
there
was
with
vmware.
We
worked
on
pocs
related
to
project
group
consolidation
and
created
a
poc
match
request,
which
shows
how
to
convert
epics
to
project
level,
and
I
worked
on
poc,
which
tries
to
move
issues
to
the
group
level.
The
pocs
have
pretty
limited
scope,
it's
just
about
creating
resource
from
rails,
console
and
exposing
this
in
api,
but
I
hope
that
from
plc's
it
still
builds
the
overall
direction
or
idea
which
in
natural
is
basically
that
all
resources
will
be
moved
to
an
aim
space.
E
E
E
B
Yeah,
so
it's
this
one
is
more
of
an
fyi
about
capturing
the
developer,
docs
and
work
items
like
item
types
and
all
other
technical
discussion
or
developer
discussions.
So
I've
opened
nmr
and
pinged
front-end
and
back-end
engineers
in
plan,
so
please
do
contribute
and
help
to
refine
that
documentation.
So
we
can
measure
them
on
and
move
from
there,
and
then
I
have
the
next
item
as
well,
which
I
think
we
kind
of
discussed
in
the,
and
this
is
not
for
mvc1.
B
I
don't
think-
and
this
is
also
related
to
how
do
we
map
the
work
item
types
to
the
widgets
and
all
that
my
stuff.
So
I
think
I
think
the
first
iteration
can
we
can
just
hard
code
it
somewhere
somehow
so
that
we
know
that,
for
instance,
the
existing
work
item
types
like
issue
and
incident
and
test
case-
have
these
hard-coded
widgets
or
columns
to
make
it
clearer.
B
So
my
understanding
from
like
the
road
map
that
we
can
take
is
that
we
will
introduce
these
predefined
work
item
types,
we'll
hardcore
the
mapping
between
the
widgets.
The
next
step
would
probably
be
to
make
this
to
allow
kind
of
the
customers
to
customize
the
widgets
on
the
predefined
work
item
types,
so
they
can
like
if,
if
we
have
issue
that
has
a
due
date
and
the
customer
doesn't
want
due
date
on
the
issue,
they
should
be
able
to
remove
that
widget
from
the
issue
type
from
the
issue
or
kite
and
type.
B
B
Do
we
want
to
allow
due
dates
to
be
renamed
to
end
date
or
wait
to
be
renamed
to
story
points
and
so
on,
and
then
there
is
also
a
lot
of
other
stuff
that
can
be
added
to
the
same
to
the
existing
widgets
right
make
it
required
make
it
have
a
default
value,
make
it
a
lot
of
customizations
can
be
added,
and
I
don't
know
where,
on
roadmap
that
is
or
how
much
of
that
customizations
we
want
on
the
predefined
widgets
that
we
have.
D
My
perspective
is
what,
above
my
comment:
is
visibility
initially
then
being
able
to
create
like
because
we
have
to
do
parenting
on
issues
and
all
this
other
stuff,
so
that
we
can
get
the
feature
right
and
that's
like
the
first
thing.
But
then
it's
visibility
to
turn,
which,
on
or
off
that
already
exists,
being
able
to
create
a
custom,
work
item
type
and
pick
the
widgets.
C
Yeah
building
on
that,
I
think
you
at
ux
would
have
to
determine
for
each
individual
widget
if
it
would
be
editable
to
something
like
as
solid
as
due
date.
I
don't
think
we
I
could
see
letting
them
rename
that
doesn't
make
sense.
Other
things
will
build
off
that
date,
but
potentially
like
points
or
something
would
be,
but
for
now
for
the
nbc's
at
least
we've,
but
for
a
while,
I
don't
see
us
having
intense
renaming
at
that
widget
level,
although
the
plumbing
should
be
there.
D
We
also
thought
about-
or
I
was
thinking
about,
using
our
translation
tokens
and
letting
somebody
just
create
their
own
translation
if
they
want
to
change
the
language
everything
in
the
ui
right.
It's
probably
a
horrible
idea,
but
you
know
we,
I
think
that's
definitely
like.
I
would
put
that
as
the
cherry
on
top
way
down
the
road
to
let
people
rename
stuff
that
already
exists
or
whatever
they
want
documentation.
Nightmare
too,
for
users.
B
So
so
make
it
clear
and
to
clarify
I'm
sorry
like
we
don't
foresee
in
the
near
future
to
be
renaming
field
names
or
widget
names
to
give
them
like
different
titles.
Right,
that's
further
down
the
line,
I
don't
know,
maybe
somewhere
when
we
do
custom
fields,
is
that.
I
I
feel
like
we
shouldn't
necessarily
did
I
freeze,
or
did
he
freeze.
I
B
I
C
I
No,
I'm
thinking
in
the
example
of
health
status.
You
wouldn't
be
able
to
rename
help
status,
but
you
could
rename
the
indicators
the
labels
associated
with
health
status.
You
know
what
I
mean
like
so
help
status
of
like
I
would
rename
those
right
now
right
right
to
something
that
makes
more
sense
for
their
business.
That's
what
I
would
expect
the
core
widget
would
always
be
named
the
same
thing,
but
they
could
customize
the
the
values
the
values.
Yes.
Thank
you.
D
That's
a
possibility.
Another
one
is
like
a
likely
scenario
that
I
know
a
lot
of
customers
do
today
is
they
would
use
the
underlying,
like
members,
data,
whether
a
group
member
or
project
member,
to
create
a
new
field
like
owner
or
to
be
able
to
create
specific
roles
that
they
want
to
be
able
to
assign
and
specify
within
the
issue
like
designer
sort
of
like
how
we
built
the
reviewers
features
into
merge,
requests.
There's
like
a
lot
of
requests
for
that
same
sort
of
behavior
but
kind
of
different
ways.
B
C
B
K
B
Yeah,
I
guess
the
on
and
off
is
even
before
we
do
hierarchy.
I
I
think
that's
somewhat
easier
to
implement
now
than
implementing
the
hierarchy,
so
that
will
probably
end
up
sooner
on
the
road
now,
so
we
will
be
able
to
define
which
widget
belongs
to
each
work
item
type
dynamically
sooner
than
we
have
the
hierarchies.
I
would
expect.
A
I
Sure
go
ahead
is
somebody
else
about
to
speak.
I
I
had
created
an
issue
donald
asked
the
other
day
where
the
conversations
were
occurring
surrounding
the
design,
and
I
realized
that
I
didn't
really
see
an
issue
that
I
felt
properly
addressed
that
specific
conversation.
So
I
went
ahead
and
created
this
issue.
It
does
have
all
of
the
designs
posted
in
there,
although
they
are
changing
some.
So
I
noted
there
also
that
there
are
some
minor
changes
that
are
happening
to
the
designs
based
on
conversations
with
jeremy
about
design
patterns
and
sorry,
my
dog
just
whined
about
design
patterns
and
accessibility
in
particular.
I
So
this
includes
reducing
the
margin
around
the
page,
not
anything
major,
I
would
say
they're
just
making
it
a
little
bit
more,
a
little
less
white
space
so
that
we're
taking
more
advantage
of
the
real
estate
and
being
consistent
with
our
current
design
patterns,
also
adding
in
labels.
This
is
something
that
jeremy
and
I
are
digging
into
right
now.
I
Do
we
have
to
have
labels
or
can
we
get
rid
of
those,
and
the
concern
is
that
screen
readers
don't
have
a
way
to
properly
identify
what
these
items
are
without
the
labels,
primarily
when
data
has
been
added.
So
in
the
case
of
inline
editing,
if
we
have,
let
me
just
share
my
screen,
really
really
quick.
I
Okay,
so
in
the
case
of
inline
editing,
when
we
have
the
initial
title
here,
we
have
placeholder
text
that
gives
some
instruction
as
to
how
to
interact
with
that
element,
but
once
you've
added
in
data
there's
no
way
to
clearly
identify
that
this
is
editable
by
a
screen
reader.
It
doesn't
necessarily
know
what
to
do
with
it
and,
according
to
jeremy,
this
is
actually
something
that
we
could
get
fined
for.
I
C
I
That's
true,
but
that's
also
more
of
a
visual
indicator
and
the
screen
reader
is
looking
in
the
code
for
specific
instructions
to
to
give
that
guidance.
Something
else
that
I'm
still
trying
to
understand,
and
I
I'm
not
finding
a
ton
of
documentation
about
it,
unfortunately,
is
how
the
screen
reader
experience
differs
on
mobile
versus
on
desktop
and
what
those
tools
are
looking
for.
So
that's
also
something
that
he
and
I
are
digging
into
and
trying
to
understand.
I
So
that
means
that,
in
order
for
them
to
simply
read
the
description
of
the
page,
it
would
have
to
get
stuck
on
all
these
different
pieces.
So
that's
something
else
where
I'm
trying
to
understand
is
there
a
way
that
we
can
say
ignore
these
things?
When
there's
data
added
or
you
know,
how
can
we
reduce
the
friction
of
that
experience
as
much
as
possible?
I
We
can't
solve
all
the
things
I
think
early
on.
We
can
always
just
get
kind
of
a
base.
Here's
what
we
think
is
going
to
be
the
best
experience
and
then
iterate
on
it.
That's
my
goal,
but
I
do
want
to
at
least
have
understanding
before
we
dive
right
in
as
to
what
we're
up
against
and
if
there
is
any
way
that
we
can
kind
of
quickly
address
that
before
we
get
too
deep
into
the
coding.
So
that's
really
my
update.
I
As
far
as
all
of
the
changes,
you
can
also
see
some
of
the
things
that
we
had
talked
about
yesterday.
I
I
This
changed
to
an
existing
button,
so
it
used
to
be
a
little
circle
button.
Now
it's
a
square
button,
that's
using
one
of
our
existing
patterns
and
then
changing
the
color
and
the
weight
of
these
in
some
cases
so
that
they
are
compliant
with
503
and,
like
contrast
for
typography
and
colors,
he
also
recommended
adding
in
the
breadcrumbs
at
the
top
here,
but
we
I
want
to
truncate
those,
maybe
in
the
middle
at
some
point,
because
they
do
wrap
and
get
kind
of
unruly.
I
But
the
primary
benefit
here
is
that
there
was
no
way
to
from
again
more
so
an
excessive
accessibility
standpoint.
There's
no
way
to
let
the
user
know
where
they've
landed.
They
may
have
selected
to
create
a
new
work
item,
but
once
they're
here
there's
nothing
telling
them
that
that's
what
they're
actually
doing
so
having
the
breadcrumbs
there
does
provide
that
insight.
I
know
that's
not
mvc
the
breadcrumbs,
but
that
is
something
that
I
think
we'll
need
to
add
in
pretty
quickly
to
help
give
that
additional
insight.
F
I
I'm
not
sure
if,
if
you
you
said,
drop
down,
I'm
not
sure
if
you
meant
drop
down
or
pop
over,
but
we
have
been
talking
about
doing
like
a
popover
approach
where,
instead
of
having
you
know,
maybe
this
center
breadcrumb
here
we
could
just
have
like
an
ellipsis,
which
is
a
pattern
that
we
currently
have
in
some
places.
But
then,
when
you
click
the
breadcrumbs
you
see
like
an
overlay
or
a
little
pop
over.
That
shows
the
full
breadcrumbs.
So
you
don't
have
to
display
the
whole
thing
in
that
tiny
little
space.
C
D
C
I
just
was
coming
back
to
the
screener
screen
reader
part
can't
you
denote
the
primary
content
in
its
order
for
this
for
the
skipping
actions
of
the
screen
reader.
So
you
could
still
say
title
then
description,
then
the
assignees
then
the
labels,
as
long
as
they
have
the
ability
to
skip
to
next,
essentially.
I
Are
you
asking
if
you
can
programmatically
note
the
order
so
that
the
screen
reader
goes
in
a
certain
flow
sure
you
can.
I
think
that
you
can.
I
know
you
can
do
it
with
tabbing
and
I
think
some
of
the
functionality
there
is
similar
in
some
way.
So
I
think
that
you
can
and
that's
kind
of
what
I'm
thinking
too
is.
Can
we
can
we
tell
it
to
skip
certain
parts,
but
I
also
want
to
be
mindful
of
the
context.
I
So
if
you
don't
have
any
data
and
it's
probably
more
important
to
go
top
to
bottom,
but
if
you
do
have
data
and
then
you
might
be
less
interested
in
reviewing
all
the
information
but
also
if
there's
a
way
that
they
can
specifically
maybe
even
say
I
want
the.
I
want
to
see
just
the
description
I
want
to
read.
Just
the
description
only
give
me
that
information-
I
don't
know
if
that's
possible,
so
just
doing
a
little
bit
of
quick
research
today
on
this.
C
Yeah,
I
think,
as
long
as
you
group
them
up
well
and
name
them
well,
they
get
a
lot
more
ability
to
jump
around.
So
I
had
to
find
a
colleague
before
and
he
would
check
my
designs
and
as
long
as
they
get
denoted
as
sections
that
are
skippable
or
like
that,
it's
read
out,
then
it's
they
have
a
lot
of
power
and
they
can
navigate
really
fast.
That's
good
to
know.
I
don't
know
that
we'd
have
to
move
the
like.
Your
order
of
the
design
would
have
to
change
necessarily
but
the
tabbing
might.
G
Good
users
are
primarily
using
their
keyboard
to
navigate,
so
they
like
anything
that,
like
this,
the
normal
tab
index
that
sort
of
allows
you
to
tab
through
elements.
That's
how
they'll
navigate
down
the
page
typically
and
there's
you
can
there's
probably
some
videos.
You
can
find
that
folks
using
screen
readers,
it's
fascinating
to
watch
because
it's
like
they
get
very
quick
at
sort
of
interpreting
what's
happening.
G
No
no
worries
I
mentioned
also
the
for
the
for
the
issue
that
jeremy
raised
around
labeling.
For
specifically
the
title
like
there's
an
attribute
called
the
aria
label
attribute,
there's
a
lot
of
aria
attributes
that
are
specifically
for
helping
accessibility
and
assisted
devices
that
should
be
sufficient.
G
I
don't
know
if,
like
gitlab,
has
specific,
you
know
constraints
around
using
those
but
like
that,
should
solve
the
problem
that
you
mentioned,
of
not
having
a
label
on
the
title
field
and
it's
invisible
to
the
normal
user,
so
it
you
know,
maintains
the
kind
of
sleekness
from
a
visual
perspective.
So
I
think
most
of
those
problems
should
be
solvable,
but
again
like.
If
you
know,
I'm
not,
the
expert
jeremy
would
be
would
probably
know
or
some
of
the
front
end.
Folks.
I
So
that
actually
raises
a
question
that
I
have.
I
noticed
donald
just
tagged
me
in
the
work
item
channel
and
the
thread
about
accessibility.
So
it
could
be
that
that's
everyone
that
I
need
to
include
and
I'll
ask
my
questions
there,
but
is
there
anything
else
that
would
be
beneficial
from
an
engineering
perspective
for
me
to
ensure,
as
communicated,
is
there
anything
that
I
can
help
expand
on
or
help
anyone
understand,
because
obviously
the
way
that
we
build
this,
I
think
it's
going
to
have
a
large
impact
as
well
on
that
experience.
I
So
what
what
kind
of
information
do
you
all
being
beneficial
or
donald?
Would
that
just
be
the
focus
that
you
tagged
in
that
thread.
H
Yeah,
we
can
start
with
those
folks,
it's
mostly
the
other
way
around
like
as
we're
doing
the
research.
If
you
have
any
questions
on
like
what
what
we're
capable
of
doing
or
what
we
should
look
out
for
as
far
as
accessibility
on
the
design
side,
simon
and
kong
are
kind
of
the
experts
on
that.
But
once
we
get
to
the
point
of,
we
want
to
start
building
it
with
accessibility
in
mind.