►
From YouTube: Plan | Weekly Sync 2022-11-23
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
And
I
still
haven't
figured
out
how
to
record
directly
to
YouTube
or
Google
Drive,
so
we'll
just
have
to
do
it
manually.
B
A
Yeah:
okay,
23rd
of
November
plan
weekly
meeting
times
the
first
thing:
yeah,
okay,
so
yeah,
I
guess
this
is
not
I've
forgotten.
What
I've
written
so
yeah
plan
will
hire
three
front-ended
team
members
in
Q4.
I
think
this
is
quite
Advanced
already
with
at
least
two
of
these
positions,
but
we'll
open
a
third
one
and
optimize.
A
If
you
know
anybody
I've
linked
the
procedure
for
referring
somebody,
that's
always
good
to
refer
people,
even
if
we
don't
have
a
an
open
role
at
the
time.
So
you're
very
welcome
to
refer
anybody
anyway,
on
to
demos,
Donald
you're.
Next.
C
Cool
okay,
so
I
wanted
to
start
giving
updates
to
where
we
are
as
a
team.
As
far
as
the
okr
as
a
feature,
I,
don't
know,
what's
the
official
name
of
the
okr
project,
not
okrs,
which
we'll
be
talking
to
as
a
team
talk
about
it,
but
anyway,
okay,
our
management.
D
C
Okay,
so
I
wanted
to
give
update
where
we
are
as
a
team
as
far
as
okr
management
I,
don't
believe
it's
just
like
is
no
okay
and
also
demo
for
for
the
folks
that
missed
last
week
or
wasn't
able
to
catch
the
video,
we
had
a
pretty
good
demo
around
where
we
are
at,
and
we've
added
I
think
a
little
bit
more
since
last
week,
so
I
was
going
to
demo
it,
but
kushal
you
actually
added
a
decent
amount
of
stuff
that
product
planning
is
doing
so
and
I
think
you
mentioned
that
you
wanted
to
that.
E
Yeah,
so
I
I
can
demo
it
directly
on
the
project
that
I
created
on
gitlab.com
itself
and
I
I
got
the
feature
flag
enabled
as
well
so
I'll.
First
summarize
the
very
first
point
from
the
agenda.
So
basically
we
started
out
as
basically
creating
objectives
from
the
issues
list.
Both
backend
and
front-end
support
got
added
within
15.6
itself.
E
The
idea
was
to
basically
create
an
action
next
to
new
issue
button
on
the
issues
list
where
the
user
can
select
new
objective
and
then
they
can
create
objective
right
from
the
issues
list
page
initially.
They
just
need
to
provide
issue,
titles
or
sorry,
the
objective
title
and
then
it
gets
created
and
shows
up
within
the
issues
list.
So
I'm
going
to
go
ahead
and
just
a
second
I'm
going
to
share
my
screen
and
foreign.
C
C
E
Yeah
so
I
I
checked
a
bunch
of
team
members
who
are
working
on
this
feature,
but
yeah
in
case
you
do
not
have
access
to
the
project.
Just
leave
your
name
in
the
agenda
document
and
I'll.
Add
it
right
away
after
I
complete
my
demo
yeah.
So
you
should
be
able
to
see
my
screen
and
the
project
here.
E
So
it's
basically
a
GitHub
okrs
under
issue
reproduce
and
what
you
need
to
do
is
go
to
issues
list
and
you
would
notice
that
in
the
header
section
new
issue
button
is
now
a
split
drop
down
button.
So
when
you
click
on
this
drop
down,
select
new
objective
and
then
you
click
on
new
objective.
It
asks
you
to
provide
the
objective
title,
so
we
can
just
set
objective
title
and
then
we
click
on
create
objective
and
it
basically
creates
in
place
and
updates
the
list.
E
And
now
you
see
that
objective
is
created
here.
There
are
a
bunch
of
things
missing
here
like
this.
Icon
is
still
pointing
to
the
issue
icon
and
not
the
objective
icon.
So
we
need
to
update
that
when
you
click
on
objective
it
takes
you
to
the
typical
work
items
page
and
on
the
work
item
page,
you
would
notice
like
it
has
a
bunch
of
other
details
like
the
title
assigning
is
status
labels
Etc
now
Donald.
E
Okay,
so
skip
directly
to
the
fourth
point,
so
the
next
feature
Set
from
the
product
planning
team,
was
to
basically
introduce
hierarchy
widget
on
the
work
items
page,
which
is
this
particular
widget
that
you
see
here.
So
we
added
the
front-end
support
for
basically
having
this
drop
down
button,
which
shows
bunch
of
actions.
We
are
using
the
same
shell
that
we
used
for
task
lists
in
the
issues.
So
when
you
click
on
this
drop
down
button,
it
shows
bunch
of
actions
like
new,
objective,
new
key
result
and
then
existing
objective
and
existing
key
result.
E
Currently,
when
you
click
on
this,
it
shows
the
form,
but
it
won't
allow
you
to
create
an
objective
inside
of
an
objective,
because
we
are
still
waiting
for
a
couple
of
backend
Mrs
and
the
front-end
Mr.
That
depends
on
the
back
end.
All
those
Mrs
are
in
draft,
but
the
idea
is
that
you
should
be
able
to
create
a
key
result
or
an
objective
inside
of
an
objective,
or
you
can
add
an
existing
object
to
as
a
child
item.
E
So,
as
you
can
see
that,
if
I
go
back
to
this
issues
list,
we
have
two
objectives
here,
this
testing
objectives
and
then
objective
title.
So
if
I
want
to
add
an
existing
objective,
I
can
just
click
on
this
drop
down
action
which
says
existing
objective
and
then
the
moment
I
click
here
it
auto
completes
all
the
existing
objectives.
E
I
can
search
by
title
if
I
want
to
so
currently
searching
only
by
title
is
supported,
so
you
can
basically
click
on
the
suggested
item
and
when
you
click
on
ADD
objective,
it
will
basically
add
the
item
here
and
will
show
the
tree
View.
Now
speaking
of
Tree
View,
so
the
design
for
the
tree
view
was
supposed
to
be
the
same
as
the
one
that
we
see
today
in
the
epics
page,
where
you
can
basically
attach
child
epics
and
issues
within
an
epic.
E
We
are
using
the
same
design,
but
we
are
not
quite
using
the
same
three
app,
because
the
current
tree
implementation
on
the
epics
page
is
using
view
X
heavily
and
at
the
same
time
it
is
also
reliant
on
the
rest
apis.
But
since
work
items
is
all
view
Apollo,
we
didn't
want
to
basically
change
the
tree
app
to
a
point
where
it
becomes
unmaintainable.
E
So
we
decided
to
reuse
the
shell
that
we
created
for
task
list
and
we
are
using
some
of
the
templates
and
logic
from
the
tree
app
to
recreate
the
tree
UI
within
this
widget.
So
that's
the
plan
for
now.
As
far
as
far
as
next
week's
goals
are
concerned,
we
want
the
tribute
to
be
functional,
so
yarn
has
already
created
a
pocmr
which
adds
support
for
creating
objectives
and
key
results.
Within
an
objective
and
flori
is
using
that
POC
backend
as
a
foundation
to
test
the
front
end.
E
So
once
we
have
the
tree
ready
that
Mr
will
get
merged
most
likely
early
next
week,
which
means
that
next
week's
plan
weekly
I
think
it
would
be
APAC
where
we
get
to
demo
the
tree
view.
So
that
is
about
both
the
features
that
we
did.
First
one
was
creating
objectives
from
issues
list
and
the
fourth
one
was
hierarchy,
widget
itself,
so
yep
any
questions.
F
Have
a
quick
question:
kashaw
just
a
confirmation.
Maybe
I
noticed
that
when
you
interact
with
the
split
drop
down
button
and
you
went
down
and
you
selected
objective-
yes
objective,
they
took
the
place
up
in
the
button
and
you
had
to
press
the
button
again.
Yes,
is
that
the
normal
pattern
for
a
split
drop
down
versus
saying
hitting
the
drop
down
yes
and
when
the
action
is
actually
triggered?
When
you
select
objective.
E
Yeah,
so
that's
a
common
pattern
for
all
similar
split
drop
downs
that
you
would
notice
across
gitlab.
It's
a
two
click
process,
unfortunately
for
now,
but
since
we
are
working
towards
MVC,
that
is
due
in
January,
so
we
are
dealing
with
this
earlier.
We
we
thought
of
other
ideas
like
having
new
objective
button
right
next
to
the
new
issue
button,
just
like
this
edit
issues,
but
then
it
would
have
cluttered
the
interactions
area
with
bunch
of
buttons
that
user
may
not
want
to
see.
So
we
are
dealing
with
this
two
click
process.
E
Also,
this
feature
is
going
to
be
internal
for
a
while
before
we
make
it
generally
available,
which
means
that
we
will
iron
out
all
these
usability
issues
like
having
multiple
click
paths,
to
reach
to
the
creation
of
objective,
so
yep.
F
Yep
as
long
as
that's
the
common
interaction
panel
pattern
for
the
drop
down
button,
that
sort
of
two
click
or
yeah,
maybe
even
three
click
interaction,
I
totally
get
the
visual
cluttered
thing
too
right
that
area
is
has
got
a
ton
of
buttons
already,
and
so
not
adding
to
it
is
is
great
as
long
as
that's
the
common
pattern
and
it's
accepted
everywhere
else
that
I'm
cool
thanks
for
clarifying
that
yep.
E
So
Amanda
has
mentioned
a
question
here
and
it
was
basically
based
from
design
discussion
so
right
now
we
don't
have
the
tree
as
you
can
see
that
we
just
have
an
empty
widget,
but
once
Tree
items
show
up
here,
user
will
be
able
to
click
on
those
individual
items
and
that
would
basically
open
a
model
dialog
and
then
that
would
show
all
the
details
similar
to
what
this
page
shows.
E
So,
if,
if
you
look
at
the
issues
list,
where
we
support
task
list,
you
can
click
on
individual
tasks
and
it
shows
the
work
item
UI
within
the
model
dialog.
We
want
to
replicate
that
same
behavior
here
as
well
that
a
root
objective
can
be
shown
in
its
own
dedicated
page.
But
once
you
are
inside
that
root
objective,
you
should
be
able
to
click
on
individual
items
and
that
should
open
a
pop-up
and
you
should
be
able
to
basically
drill
down
all
the
way
till
last
item
from
the
tree
while
remaining
on
the
same
model.
E
Dialogue.
So
Amanda's
question
is
more
directed
towards
Donald
you
and
myself
that
who
are
going
to
take
care
of
that
navigation
from
the
model
dialogue
perspective
like
once
three
items
show
up
here.
Those
items
need
to
be
clickable
and
once
user
clicks
on
them,
it
needs
to
open
a
model
dialog
with
the
work
item.
Ui
much
like
this
page
within
the
dialog
itself,.
C
Yeah
so
that'll
be
interesting,
because
what,
if
we
it's
not
really
a
use
case
for
okrs,
but
it
will
be
in
the
future
for
when
we
have
more
than
one
child
or
more
than
one
level
of
children,
so
yeah
once
we
have
grandchildren,
are
we
going
to,
especially
when
we're
doing
where
we're
talking
about
modals
and
models
and
modals?
C
G
G
F
That
I'll
link
the
issue.
Sorry
to
interrupt
you
Amanda,
you
go
ahead.
D
Yeah
no
worries
I
linked
the
issue
already
in
the
design
discussion
in
number
six.
So
for
okrs
we
already
made
the
decision
for
the
MVC
to
just
replace
the
child
so
you're
on
an
objective.
You
click
the
first
child.
You
get
the
pop-up
I'm
using
bad
terms,
sorry
and
then
you're
viewing
a
child
of
the
first
parent
and
you
select
a
a
next
child
or
a
grandchild
that
replaces
the
pop-up
with
the
grandchild's
pop-up.
D
That's
the
behavior
we're
going
to
take
for
MBC,
but
in
the
future
we
do
want
to
explore
potential
using
the
drawers
and
something
maybe
a
little
bit
that
provides
information
about
the
prior
information.
The
prior
parents.
F
F
That
Nick
is
also
involved
in
sort
of
how
that
works
in
general
as
a
work
item.
So
there's
there's
a
that
is
definitely
being
thought
out
right
there
and
we're
actually
making
some
good
Headway
I
think
some
very
logical
Headway
on
that.
C
Yeah,
so
there's
other
implications
too,
outside
of
just
the
just
deciding
what
to
do
with
the
model
in
like
the
URL,
if
we're
showing
multiple
descendant
key
results
or
objectives,
how
are
we,
how
are
we
showing
that
in
the
URLs
and
the
breadcrumbs.
D
Yeah
and
Alexis
has
that
in
her
design,
I'm
pretty
sure
it's
in
that
design
issue
I
know
that
she
started
thinking
about
okay.
Well,
what
do
we
do
with
the
URL
as
we're
popping
each
of
these
different
levels
so
definitely
contribute
to
how
you
would
like
to
see
that
I,
don't
I'm,
not
opinionated
in
in
what
the
URL
should
be,
but
I
do
want
to
buy
us
for
making
a
decision
moving
forward.
So
my
my
first
question
or
my
basic
question-
is
who's
going
to
own
the
actual
creation
of
that
that
child.
C
So
I
think
product
planning
has
been
doing
most
of
the
work
around
a
hierarchy
and
I
think
that
one
is
tied
more
towards
the
hierarchy
side
of
things,
but
project
management
and
the
work
that
Natalya
is
doing
around
around
switching
it
from
IDs
to
IDs.
That
she's
going
to
demo
later
on
is
on
the
project
management
side,
so
I
think
it'll
be
a
collaboration,
but
the
dri
for
any
of
the
hierarchy,
stuff
I
think
should
be
on
the
product
planning
side.
E
Only
concern
would
be
the
front
end
capacity
within
the
team,
because
Flory
is
currently
working
on
getting
the
tree
view
ready
and
she
won't
be
available
starting
next
week,
all
the
way
till
first
week
of
January,
which
means
that
this
model
would
need
to
be
developed
in
collaboration
with
someone
from
project
management.
Anyway,.
D
Okay,
I
wonder
if
we
could
also
consider
asking
abalash
to
help
I,
don't
know
if
he
has
brought
an
experience,
but
I
think
he's
looking
for
more
and
more
MBC
work.
E
Yeah,
so
abhilash
is
currently
taking
care
of
the
progress
bar
stuff,
so
he'll
be
working
on
getting
the
back
end
and
front
end
of
progress,
input
widget,
but
at
the
same
time,
model
dialogue
related
changes
are
not
simple
as
well,
at
least
not
on
the
surface
and
I
I
would
rather
have
someone
who
has
greater
awareness
of
the
front.
End
of
work
items
be
doing
these
changes,
because
otherwise
we
would
need
to
do
a
lot
of
hand
holding
with
regards
to
implementation.
C
Yeah
we
can
figure
out
the
details
around
there
worst
case.
If
we
don't
have
the
band
like
there's
workarounds,
we
can
do
on
the
UI
side
to
get
a
first
MVC
out
like
we
can
kind
of.
We
can
push
off
on
some
of
the
decisions
around
like
the
URL
and
the
breadcrumbs.
If
we
just
don't
have
the
bandwidth
on
the
front
end,
so
we'll
work
together,
I
think,
probably
all
the
teams,
all
the
groups,
will
work
together
on
figuring
out
the
the
distribution
of
front-end
effort
on
everything
hierarchy
related.
A
Okay
related
to
what
you
mentioned,
but
the
URL
when
you
open
a
modal
currently
with
a
task
in
it,
is
that
does
that
appear
in
the
URL
because,
oh
well,
my
main
question
is
like
if
we
do
this
hierarchy
thing
where
the
modal
actually
changes,
I
think
as
long
as
the
back
button
works,
it's
probably
not
a
big
issue
for
the
first
iteration,
but
if
it
doesn't
work,
it
kind
of
is
right
because
you
can't
get
back
there's
no
way
back
to
where
you
came
from.
E
So
when
you
open
a
task
list
item
in
the
model
dialog
it,
it
updates
the
URL,
but
it
basically
adds
work
item
id
as
a
query
pattern,
which
means
that
someone
can
copy
that
URL
and
then,
when
they
navigate
that
URL,
it
will
open
the
base
issue
first
and
then
it
will
also
open
the
model.
Dialog.
A
H
C
I,
don't
know
how
to
use
a
zoom
on
my
not
just
my
laptop
okay
I'm,
not
muted,
good,
all
right,
I'm,
just
running
through
Alexander's
question
around
the
filter
list,
and
we
can
also
test
the
back
button
here
in
non-modal
view.
C
Okay,
so
I
just
created
an
objective.
It
shows
up
in
the
list
here
and
then
his
question
was:
if
we
filter
it
by
label.
C
Do
we
see
it
and
yes,
we
do
and
Alexander
I
know
you
have
connectivity
issues
so
not
sure
if
you're
still
there,
but
does
that
answer
your
question.
I
And
actually
my
sound
will
be
okay,
but
my
question
is
like:
if
you
now
create
an
objective,
would
you
need
to
remove
the
filtering
in
order
to
see
that
new
objective?
So
if
you
were
Now
to
create
one
object
now.
C
Oh
I
got
what
you're
saying
yeah
I
know
it
showed
up
on
the
list
after
it
looks
like
we're
doing
a
hard
refresh
after.
I
I
I
C
Yeah,
okay,
so
you're
talking
about
similar
workflow
that
we
have
on
boards.
When
you
create
an
issue
within
a
list,
we
will
add
the
labels
and
everything
from
that
list
to
the
issue
which.
C
So
I
think
it'd
probably
be
something
we
want
to
add.
Maybe
down
the
road.
Is
that
ability,
but
then
it'll
be
interesting
to
Think
Through?
What
we
do
for
for
widgets
that
don't
for
differences
in
widget
or
filtering
for
the
different
for
the
different
work
item
types.
C
So
yeah
just
something
we
should
definitely
think
about
in
the
in
the
future.
I
did
notice,
actually
I
wonder
if
we
refresh
here:
okay,
it
does
go
back
to
new
issue.
C
C
E
At
least
have
to
reload
it,
it
didn't
Preserve.
C
C
Okay
I
think
that's
all
I
had
or
that's
all
we
had
to
demo
as
far
as
okrs
the
other
stuff
that
I
added
can
probably
be
read
only
unless
there
are
any
questions
but
I
just
listed
out
kind
of
the
top
level
or
the
high
level
issues
and
epics
that
we're
that
we've
kind
of
committed
to
getting
done
before
the
January
for
the
January
rollout.
C
So
that
would
be
for
a
two
which
is
around
the
system.
Notes,
quick
kind
of
summary
of
the
up
or
of
the
work
that's
been
done.
There
is
Alexandria's,
got
a
back-end
Mr
for
that
that
is
in
review
and
that
moves,
or
that
gives
us
the
ability
to
grab,
to
grab
all
notes
from
graphql
and
to
filter
those
notes
by
either
system
notes
or
all
discussions
and
notes.
C
That
is
there's
good
progress
on
the
review
there.
So
we're
hoping
to
get
that
in.
In
the
next
few
days,
the
front
end
there's
an
MR
and
it
looks
like
I
forgot
to
link
there.
I'll
add
the
link
to
it,
but
the
peak
is
working
on
that
has
the
back
end
for
that.
C
For
that
notes,
query
that
I
was
just
talking
about
mocked,
but
I
think
we
can
go
ahead
and
use
the
actual
either
Alexander's
Branch
or
just
go
ahead
and
or
just
wait
for
it
to
get
to
master
and
start
building
off
of
the
actual
back
end
I'm,
so
hoping
to
get
something
previewable,
even
if
it's
just
showing
the
system
notes
within
a
work
item,
unstyled
hoping
to
get
at
least
to
that
point
by
next
week,
and
then
three
four
was
it
four
four.
C
A
three
is
is
very
much
related
to
that
and
it's
more
around
discussions
and
notes.
The
backend
Mr
for
system
notes
is
the
like
I
said.
That
includes
the
discussions
and
notes.
Also
so
we
should
be
able
to
after
that's
merged
in
get
the
discussions,
and
we
may
be
able
to
also
get
that
viewable
within
work
items
again,
not
styled
and
without
the
ability
to
to
add
discussions
or
edit
discussions
through
a
work
item.
Yet
that'll
be
the
next
the
next
iteration.
So
in
the
next
couple
weeks
and
then.
C
Where
are
we
at
and
call
it
select,
this
sticks
and
seven
Milestones
is
globally
because
we're
adding
that
to
test.
Also,
that
is
both
the
front
and
the
back
end
is
done
there
and
ready
to
be
tested.
C
It's
in
work
items
nvc2,
which
means
it's
available
for
all
of
the
plan
stage
group.
So
please
test
there
once
we're
comfortable
with
moving
it
Forward,
we'll
move
it
to
probably
along
with
iterations
over
to
the
the
next
feature
flag,
which
would
mean
it
would
be
available
in
gaylaborgan,
getlive.com
and
then
last
one
is.
Labels
is
already,
of
course,
available
on
work
items.
H
Okay,
let
me
quickly
share
my
screen
and
Amanda
is
right
right
now
back
button.
It
works
for
me
in
some
cases,
but
it's
not
like
it's
not
working
consistently,
so
I
assume
it
depends
on
your
history
in
the
browser.
I
will
need
to
look
into
this,
but
let's
see
the
IID
at
least
so
hope
you
can
see
my
desktop
now,
and
here
is
how
do
we
fetch
work
items
Standalone
one
and
right
now
we
are
fetching
it
by
ID.
2
here
is
a
global
ID,
which
means
it's
GID.
H
H
H
H
We're
getting
the
same
work
item,
but
you
can
see
this
ID
here
is
different.
Now
we
just
have
a
feature
flag
and
you
cannot
test
this
in
product
production
because
it's
defaulted
to
false,
but
even
if
we
enable
it
globally,
we
will
still
be
able
to
be
flexible
between
the
two
using
the
IID
path.
Url
parameter,
wonder
if
I
click
back
right
now.
Well,
this
works,
but
it
doesn't
close
because
I
just
tried
to
fix
it
with
replace
history.
H
So
we
will
need
to
dive
a
bit
deeper
into
this
on
the
back
button,
but
it's
definitely
doable
and
while
we're
here,
I
just
demo,
one
more
little
thing
super
fast,
because
I've
been
just
diving
into
this
this
afternoon.
So
you
can
see.
This
is
our
typical
issue
list
and
normally,
when
I
refresh
the
page,
there
is
a
graphql
called
happening
and
getting
you
the
new
issue
list.
H
However,
like
I
said
this
one
is
cached,
there
is
no
graphql
request
and
it
was
quite
fast.
If
we
go
to
labels,
it
was
slow
one.
You
can
see
that
they
are
not
fetched.
There
is
this
little
blink
moment
that
requires
for
view
to
render
all
the
labels
and,
if
I
go
with
for
Runner
I
tested
it
previously,
you
can
see
that
there
is
no
loading
as
well.
H
It
just
show
us
the
cached
results
if
I
want
to
play
around
it,
I
go
with
label
right
now,
it's
not
for
if
it's
not
to
work,
because
it's
a
demo.
So
let's
refresh
it
again,
so
if
I
remove
Runner
and
go
with
label,
let's
say
and
funk
there
is
a
loading
state
and
reload
right
now,
it's
cache2!
So
if
I
refresh
the
page
now
it
will
be
cache,
there
will
be
another
fetch.
I
still
need
to
figure
out
how
to
refetch
and
update
the
cache
nicely
without
showing
the
login
state
to
user.
H
A
Yes,
one
question:
the
caching
looks,
awesome,
I,
don't
want
to
just
Breeze
past
the
huge
achievement
and
go
straight
to
the
previous
thing
you
talked
about,
but
so
so
that
sort
of
have
this
straight
like
at
some
point,
we'll
default
the
other
way,
so
that
the
new
work
item
IID
is
used
and
you'll
need
to
use
the
switch
to
use.
The
old
version
is
that
right
and
then
we'll
remove
it
completely.
H
I
am
not
sure
that
we
want
to
remove
complete,
is
searching
by
the
global
ID,
because
I
can
see
that
we
probably
will
have
cases
where
we
want
to
fetch
by
global
ID.
So,
for
example,
right
now
we
are
within
the
same
project
we're
using
the
same
issues
here
the
same
workspace
right,
but
imagine
that
we
have
a
sidebar
where
we
just
do
an
Explorer
and
we
want
to
show
the
work
item
from
completely
different
one,
maybe
related,
maybe
not
so
I,
don't
know.
H
If
we're
going
to
remove
ID
completely,
we
can
default
to
some
and
we
can
have
a
second
option.
So
the
most
used
option
will
be
probably
just
shown
with
the
default
one
and
the
second
one.
We
will
need
to
use
a
URL
parameter,
so
the
less
usable
one
will
need
to
overpower
any
kind
of
URL
parameter,
but
I
wouldn't
get
rid
of
any
of
them,
at
least
for
now.
B
We
discussed
before
I
was
just
going
to
say:
do
you
think?
Maybe
in
the
future
I
mean
we
discuss
about
having
another
route
for
work
items
that
use
a
global
ID
I
mean
that
way.
We
could
use
that
one,
but
I
do
think
it
makes
sense
that
at
some
point,
the
one
that
is
scoped
to
a
project
stops
using
the
global
ID
and
the
validation
you
do
on
the
front
end.
D
H
So,
yes,
we
do
have
work
items
API,
it's
a
graphql
one,
and
currently
we
have
both
options.
We
can
clarify
the
global
ID
of
the
work
item
if
we
want-
and
we
can
query
by
the
IID,
both
of
them
are
returned
in
the
response.
So
you
can
see
the
global
ID
and
the
IID
of
every
single
work
item
then
that
we
have
on
the
page.
H
A
Okay,
final
question:
will
we
be
overloading
URLs,
then
so
URLs
that
previously
included
the
global
ID
will
in
future
use
the
I
I?
Don't
know
the
name
for
it.
The
IID
that
scoped
to
the
project
like
so
so
somebody
could
have
a
bookmarked
a
URL
right
in
the
past
and
when
they
revisit
that
URL
there
could
be
a
collision
with
another
work
item
in
it
and
they
see
that
instead.
H
I
My
concern
would
be
on
like
two
different
IDs
with
the
same
work
item.
In
some
places
you
display
180
and
other
places.
You
display
the
internal
ID
or
whatnot,
so
that,
like
users,
usually
try
to
communicate
through
these
ideas,
like
verbally
for
instance,
so
then
it
becomes
confusing
when
you're
referring
to
I
did
not
a
lot
of
the
times
would
not
say
IID,
89
and
just
say
well,
see
that
issue
with
with
id89
did
he
mean
the
actual
ID,
where
the
IID
were
so
that
that's
that's
kind
of.
H
D
D
If
we
make
a
decision
for
ourselves
in
terms
of
defining
which
one
we
want
to
show
in
certain
views
and
document
that
in
the
blueprint
documents
and
that
way,
when
an
engineer
gets
a
issue,
they
don't
have
to
make
the
decision
they
can
go
to
the
blueprint
document,
see
the
guidance
and
we
move
forward
and
eventually,
if
we
want
to
migrate
from
one
to
the
other,
that's
fine,
but
at
least
it's
well
defined
and
documented.
What
we're
using
where
I.
H
Think,
eventually,
we
will
need
to
make
a
clear
separation
that
when
we
use
a
URL
without
the
project
path,
so
Global
work
items
a
number.
We
will
use
a
global
ID.
If
we
use
a
project
path
or
group
path,
we
should
detection
by
IID,
but
yeah.
We
will
need
to
reflect
this
in
the
blueprint.
Thank
you,
Amanda.
C
Yeah
I
think
that's
exactly
right,
though,
what
you
just
how
you
just
explained
that
Natalia
in
that
the
requirement
should
be
that
if
it's
at
the
root
level,
or
at
the
instance
level
or
I,
don't
know
when,
when
we
get
namespaces,
maybe
the
namespace
level,
like
we
showed
the
ID
everywhere
else.
We
use
the
IID
it'll
be
interesting
when
we
get
to
like
yeah
related
but
on
on
context,
work
items
where
we
have
like
even
for
like
the
issue
list,
where
we
plan
on
showing
a
a
work
item.
C
In
that
view
in
a
modal.
What
do
we
add
to
the
URL
there?
Will
that
just
be
a
query?
I'm
assuming
yeah
it'll
just
be
a
query,
param
and
then
we'll
have
to
decide
if
we
want
to
use
yeah,
there's
just
more
so
I
think
we
need
to
talk
through
this
a
little
bit
more
with
ux
because
it
does
have.
There
are
a
lot
of
implications
on
the
URLs
and
what
we're
kind
of
showing
to
the
to
the
end
users.
There.
I
So
the
maybe
we
need
to
make
like
separate
decisions
in
in
the
UI.
We
always
use
iids
or
something
like
that,
and
that's
not
necessarily
has
to
do
with
what
we
use
as
params
in
the
URLs,
maybe
I,
I
yeah.
It's
I
discovered
a
definitely
to
be
had
because,
like
on
the
list,
you
want
to
see
where
that
issue
is
coming
from.
Is
it
coming
from
this
project
or
this
other
hierarchy?
Where,
where
is
it?
Coming
from.
G
I
think
that
that
Eid
is
important
also
on
second
part,
because
I
wonder
if
and
how
it
it
would
work
when
we
use
Global
ID
in
the
URL,
because
now
I'm
used
to
copy
paste
URL
in
commands
when
referencing
other
issues
and
I
wonder
how
it
would
work.
If
we,
if
there
would
be
some
place
where
we
show
Global
ID
instead
of
internal
ID,
because
our
referencing
system
wouldn't
work
with
this
Global
ID
URL
I,
assume
on
it.
I
I,
it
depends
I,
think
the
vendorer
actually
fetches
the
item,
and
then
you
create
that
HTML
bandwidth
within
the
database
I
would
like
I.
Think
it's
doable
should
not
make
a
difference
like
it
depends
on
the
URL.
If
we
can
resolve
the
IIT
both
of
them,
you
can
create
the
the
cache
HTML
and
display
the
same
way
as
we
do
display
now.
G
Well,
it
depends
what
we
expect,
because
I
would
expect
that
if
I
refer
to
some
other
work
item,
then
it's
some
kind
of
stable
reference.
So
even
if
I
do
backup
of
the
project
and
migrate
it
to
some
GitHub
at
other
GitHub
instance,
then
the
reference
Still
Remains
yeah,
so
I
still
refer
to
the
other
issue.
But
if
there
is
a
global
ID,
this
will
be
broken
because
Global
IDs
are
not
persistent,
so
any
presence
of
global
ID
wouldn't
work.
Then
you
import,
export
or
migrate
your
project
somewhere
else.
G
C
Yeah
like
if
you
put
pound
one
two
three
in
a
discussion,
is
that
gonna
show
the
is
that
going
to
show
the
project
one
two
three
IID
or
the
one
two
three
Global
ID.
G
Yeah,
so
if
you
put
one
two
three
I
would
expect
that
at
least
on
backhand
side.
We
will
assume
that
this
is.
B
C
Okay,
I
want
to
move
on
to
entire,
like
how
you
just
dropped
the
the
the
little
demo
as
an
afterthought,
but
that's
a
huge,
a
huge
deal
as
part
of
the
snappy
GL
project
around
caching.
It,
and
just
that
instant
rendering
of
the
of
the
issue
list
is
it's
amazing.
So
that's
super
exciting
demo
also.
C
All
right,
Alexandria
read
only
you
know,
I
think
your
connection's
been
fine,
but
you
just
mentioned
the
discussion
on
the
work
items.
Widget
DB
table
structure.
So
if
you
are
interested
in
hearing
more
about
that
or
contributing
to
that
discussion,
please
do
so
in
that
issue.
C
The
workflow
yorka
is
not
available,
but
she
was
proposing
a
plan
meeting
time
change
left
a
couple
options
there.
Do
you
all
want
to
discuss
changing
the
time
or
you
just
want
to
discuss
it
in
the
agenda?
I,
don't
know
how
we
want
to
do
that.
A
If
we
went
on
our
an
IR,
our
layer
would
that
be
that
would
be
pretty
difficult
for
us.
Any
us
team
members
to
attend
right.
F
I
think
an
hour
earlier,
at
least
for
Nick
and
Alexis,
would
be
at
like
six
in
the
morning.
D
H
D
A
Yeah-
and
we
already
do
every
other
week-
paypac
as
well-
and
we
could
fragment
this
into
lots
of
different
times
of
meetings.
All
right
and
maybe
ARCA
will
be
dri
for
this,
but
I'll
take
it
in
the
meantime
and
open
an
issue
for
a
vote.
A
Right,
oh,
this
is
a
big
one:
okay,
so
maybe,
instead,
since
we
only
have
three
minutes
left
I
wanted
to
maybe
just
run
through
some
of
the
okrs.
That
I
was
hoping
we
could
accomplish
as
a
stage
in
Q4
we're
already
three
weeks
into
Q4
standard,
so
yeah,
maybe
instead
we
can
take
them
forward
to
like
next
week
and
they're
here,
for
anyone
who
wants
to
like
read
them
and
give
me
any
feedback
in
them.
If
you
want
to
get
involved
in
them
as
an
individual
you're,
very
welcome
as
well.
A
A
There's
also
in
case
it's
news
to
anybody.
We
will
onboard
free
contractors
on
product
planning
for
this
effort
and
there's
also
a
single
engineer.
Group
avalash,
if
you
haven't,
met
him
already,
I
think
he
attended
last
week's
APAC
meeting
yeah.
It
is
a
project
and
I,
don't
know
KR.
On
the
other
hand,
like
we
have
a
lot
of
things
that,
like
we
can
accomplish,
that
kind
of
make
it
like.
A
Okay,
are
like
from
the
engineering
perspective,
including
like,
like
most
of
this
is
process
related,
like
making
sure
that
we
have
a
backlog,
that's
appropriate
for
contractors,
making
sure
we
have
a
plan
and
how
we're
going
to
help
them
be
like
on
board,
quickly,
be
productive
and
so
on,
and
then
the
other
KR
is
like
the
bottom.
A
One
is
like
just
barely
also
an
okr,
but
just
something
we
have
to
do
like,
like
I,
think,
do
an
annual
Talent
assessment
isn't
something
you
can
do
to
like
70
percent
you
you
have
to
do
it
100,
so
it's
not
really
an
okr,
but
the
other
two
are
things
that
anyone
can
get
involved
in
I.
Think
so
yeah
take
a
look
at
them.
A
Have
an
issue
there
for
the
second
one
which
is
like
it
has
irritated
me
for
a
while
irritated
me,
but
it's
bothered
me
for
a
while
that
we
it
feels
like
we
should
be
the
team
that
push
up
more
updates
to
gitlab's
product
development
flow.
Given
that
we're
the
plan
stage
and
I
think
we
could
be
doing
more
of
that,
and
we
get
the
benefit
that
our
features
that
we're
building
are
being
used
by
our
colleagues.
A
So
there's
an
open
issue
there
and,
of
course,
I'm
taking
ideas
for
that
as
well,
and
then
we
have
the
performance
enhancements,
the
tip
of
the
iceberg
of
which
was
Natalia's
demo
earlier,
but
just
think
what
we
could
accomplish
cool
so
anyway,
give
it
a
look
and
yeah.
You
can
feedback
to
me
directly
or
take
it
Forward
even
into
next
week,
or
we
can
check
in
on
them
each
week.
Whatever
works
for
people
Alexander.
I
Yeah
on
on
the
our
user,
also
complete
suggestions
like
I,
don't
know
if
that's
something
we
can
work
as
much
on,
because
it
ties
so
much
into
authorization
with
the
memberships
and
group
sharing
and
and
that
all
ties
into
how
you
can
order
complete
from
a
specific
issue
or
a
specific
comment
or
Mr
or
stuff
like
that,
I've
opened
an
issue
to
kind
of
audit.
Those
endpoints
and
I
I
did
look
into
that.
I
I
didn't
do
too
much
progress
because
of
stuff,
but
yeah
it's
very
much
tied
into
how
we
want
to
handle
memberships
overall.
A
Yeah
but
I
think
if
you
look
at
the
pattern
of
usage
that
people
have,
they
tend
to
spend
time
in
a
small
number
of
projects,
and
if
you
look
at
the
what
this
endpoint
actually
returns,
it's
like
participants.
In
the
current
issue,
author
and
the
current
issue,
all
of
the
members
of
the
groups
that
you
have
access
to
Plus
members
of
the
groups
of
that
project,
so
for
a
given
project
like
it's
incredibly
static.
A
It's
also
like
very
fast
on
the
back
end,
I
guess
in
some
cases
and
all
we're
asking
in
this
this
quarter,
like
would
be
like
the
goal,
would
be
to
move
this
into
graphql.
That's
it
it's
currently
in
rest.
If
we
move
it
into
graphql,
it
can
be
used
in
multiple
parts
of
the
page.
A
It's
currently
using
the
sidebar
and
it's
used
in
the
comment
field,
but
those
two
things
return
a
different
set
of
users
which
is
like
without
getting
too
far
into
it,
like
you,
can't
currently
assign
a
community
contributor
to
an
issue
using
the
assignee
widget
in
the
sidebar,
but
you
can
do
it
using
the
comment
box
and
the
quick
action.
So
it's
things
like
that.
A
We're
looking
to
fix
like
it's,
not
really
a
back
end
issue
anymore,
like
that,
we're
not
looking
to
make
it
faster
in
the
back
end,
but
simply
like
cache
it
on
the
front
end
and
optimistically
render
that
list
of
users
in
the
same
way
as
Natalia
demonstrated
earlier
with
the
issues
list
like
we
render
it
first
and
then
we
update
it
in
the
background
when
the
request
completes.
A
So
the
experience
for
the
user
is
they're
not
waiting
around
to
get
an
instant
list
of
users
from
their
cache
on
the
front
end,
which
is
then
clarified
and
updated.
You
know
a
second
or
so
later,
but
instead
of
waiting
a
second
for
the
list
to
get
it
instantly
and
that's
the
performance
benefit.
I
I
You
said
you,
you
have
one
list
of
users
within
the
assignee
drop
down,
and
then
you
have
a
different
list
of
users
within
the
auto
completion
so
which
one
do
we
want
to
move
to
graphql
or
do
we
want
to
move
even
though
they're
we
know
they're
broken
right?
Do
we
want
to
move
all
of
them
to
graphql?
Just
because
this?
This
is
where
I
like
I,
think
there
is
a
more
base
question
that
we
want
to
figure
out
how
to
solve,
or
let's
decide
on
one
that
we
want
to
move
to
graphql.
A
Anyway,
we're
over
time
but
Blair,
he
had
the
last
point.
F
Real
quick,
then
just
going
over
usability
benchmarking
with
Melissa
and
Danika.
We
realize
that
our
jtbds
across
the
plan
stage
are
for
lack
of
a
better
term,
bad
they're,
really
wordy
and
hard
to
understand
and
hard
to
action
on
and
and
not
at
all,
consistent
across
the
entire
plan
stage
for
our
users.
So
just
a
heads
up,
we
will
be
taking
a
look
and
probably
rewriting
them.