►
From YouTube: Plan Stage Weekly - 2022-12-01
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
You
have
the
first
demo
around
the
as
part
of
okay,
our
management,
but
also
as
part
of
just
work
items
in
general,
the
ability
to
view
or
the
current,
the
next
iteration
of
the
ability
to
view
system
notes
or
activities.
B
So
yeah,
so
this
is
the
first
iteration
of
the
three
Mrs
that
I'm
planning
for
the
of
showing
the
activities
related
to
the
task.
This
one
revolves
only
around
showing
the
list
of
the
activities
which
activities
all
the
system-
nodes
that
are
related
to
a
task
here.
If
you
see
right
now,
I'm
fetching
the
list
to
First
hundred
at
this
at
the
straight
go,
and
there
is
no
pagination
involved
right
now.
B
It's
just
the
list
of
reactivities
Associated
and
what
I
found
out
when
I
was
working
on
the
tasks
is
no
one.
No
task
has
more
than
100
so
because
I
wanted
to
in
the
first
iteration
I
wanted
everyone
to
have
a
look
at
how
the
activities
look
like
it's.
The
first
hundred
we
will
be
planning
pagination
and
the
sorting
out
in
the
next
iteration.
B
So
if
you
see
there
is
a
so
what
I've
used
here
is
the
is
a
system
node
alert
system,
node
component,
that
is
reusable
so
there.
Currently,
if
you
see,
there's
two
system
nodes,
one
that
is
used
in
issues
and
the
other
one
for
the
alert
management.
The
one
that
is
used
in
issues
is
closely
tied
to
view
X,
which
I
could
not
use
the
other.
One
was
system
node
for
the
alert
management
which
I
could
use
by
just
you
know,
writing
an
extra
couple
of
extra.
B
You
know
copying
the
CSS
a
little
adding
classes
here
and
there
I
could
have
created
another
component,
which
is
a
very
small
thing,
which
is
fine,
but
I
could
use
that.
That's
hence
I've
used
that
just
adding
a
couple
of
extra
classes
there
not
in
the
same
component,
obviously
because
that's
a
shared
component,
adding
what
I
could
in
my
work
item
code.
So
if
you
see
it's
by
default,
it's
ordered
by
date
oldest
first,
and
but
there
are
some
things
which
are
going
on
here
in
like
here
five
days
ago.
B
That
is
a
bug
at
the
back
end
and
which
is
being
catered
by
Alex
in
a
separate
Mr.
You
can
see
the
same.
What
the
changes
involved
in
both
the
model
view
and
the
full
view
in
the
model
view
what
I've
done
for
now,
which
maybe
I
can
do
in
the
same
mrm
show,
but
I
wanted
to
push
it
more
forward
quickly.
So
if
you
look
here,
I've
made
the
modal
scrollable.
B
Yes,
the
header
should
be
fixed,
yes,
that
we
can
do
that.
The
header
should
be
fixed
while
we
scroll
for
the
activities
or
the
discussions.
That
is
one
thing
that
can
be
done
as
an
improvement
here
but
yeah.
What
I've
made
here
is
made
the
models
callable
to
make
sure
that
we
can,
you
know
scroll
through
the
list
of
activities
yeah
so
right
now
what
I'm
doing
is
here
if
you
see
I'll
just
inspecting,
so
we
are
fetching
the
work
item
and
I'm
fetching.
B
The
work
item
notes
as
a
separate
query
in
a
single
request,
because
it
might
be
the
case
that
it
is
like
when
we
merge
everything
that
nodes
are
heavy
already.
We
are
fetching
multiple
widgets
at
the
same,
go
in
the
work
item,
so
we
can
merge
it
as
well,
but
it
did
make
sense
because
there's
multiple
discussions
or
multiple
nodes
can
come
so
I
have
made
the
polo
query
as
a
single
request,
which
is
going
in
a
different
match.
B
Yeah
so
here
in
the
work
item,
I'm
only
fetching
the
is
the
widget
there
or
not
and
in
a
separate
query
what
I'm
doing
is
like
you
see,
I'm,
not
fetching
the
notes
here,
I'm
fetching
the
notes
in
a
separate
query
which
returns
like.
Obviously
this
will
turn
everything
else
and
then
the
discussion,
the
nodes
and
the
pagination
stuff
is
like
here.
So
it's
a
single
request.
B
B
No,
no
we're
not
touching,
but
if
all
the
type
and
type
name
is
there
for
all
of
them.
So
we're
not
fetching
everything
you
see,
we're
not
fetching
everything
else
by
default
type
name
of
all
the
widgets
does
come,
we're
not
fetching
it
yeah
like
for
here.
I
did
not
like.
If
you
see
the
query,
yeah.
A
B
Yes,
yes,
we
are.
Yes,
we
are
for
everything
else.
We
are
I
discussed
that
with
Natalia
in
the
last
discussion,
because
they
were
so
I
was
having
this
discussion
with
Alex
around
the
performance
of
the
notes,
and
the
best
thing
that
we
could
do
is
fetch
the
notes
separately
so
that
it
should
not
be
Cloud.
For
example,
it
is
taking
time
and
why
should
I
have
stop
fetching
all
the
other
things
you
know
stop
showing
all
the
other
things
just
because
notes
is
taking
time.
B
So
that's
the
reason
why
I
kept
it
as
a
single
request.
You
know
we
can
change
it,
but
I
think
do
you
have
any
points
regarding
this
that
if
we
merge
it
together,
I
can
do
it.
That's
a
simple
thing:
I
just
need
to
add
to
the
widgets
and
fetch
it
right
now.
I
specifically
have
a
work
item
notes
different
query
where
I'm,
which
I'm
fetching.
A
B
Because
the
notes
might
take
time
to
come,
it's
performance,
we
don't.
We
can't
see
that
thing
right
now,
because
they're
not
much
notes
and
everything
but
keeping
it
as
a
separate
request
for
because
we
don't
have
a
lot
of
hierarchy
anywhere.
We
don't
have
so
much
data
in
other
projects.
Honestly,
it's
only
the
activity
widget
that
has
so
much
data
inside.
So
we
can
do
that.
But
I
was
I
agreed
that
yeah.
We
should
keep
it
because
we
were
just
having
discussions
on
we
already
having
moving
on.
B
A
E
Ahead
yeah,
so,
basically,
when
it
comes
to
system
notes
and
discussions
in
general
I
feel
that
keeping
it
as
a
separate
query
would
be
ideal.
Because
if
you
look
at
current
implementation
of
notes
app,
we
do
polling
there
to.
E
A
real-time-ish
nature,
so
ideally
we
would
want
a
subscription
for
for
activity
as
well
as
system
nodes.
So
if
it
is
a
separate
subscription,
then
it
makes
sense
to
have
those
not
be
part
of
the
query
of
the
base
page
itself
so
that
we
can
subscribe
to
it
and
make
sure
that
any
new
activity
happening
elsewhere
is
reflected
immediately
much
like
other
visual
types,
be
it
labels,
assignees
or
descriptions.
C
I
I
think
yeah,
so
Donald,
where
you're
going
I
think
batching.
The
non-nodes
queries
does
make
sense,
because
otherwise,
then
you'll
have
a
lot
of
like
you'll,
see
seven
or
eight
different
loading
skeletons
at
the
top
and
then
that's
kind
of
more
flickering
for
the
sake
of
saving
50
milliseconds
whereas,
like
let's
say
the
main
query
takes
a
second
to
load
and
then
the
notes
take
another.
E
It
also
explains
well
with
the
issues
page
right
now,
where,
if
you
load
an
issues
page,
you
see
description,
title
and
everything
loaded.
First,
while
you
still
see
skeleton
loader
showing
up
for
the
discussion
part
and
once
the
nodes
are
in,
we,
we
may
jump
to
a
specific
discussion
depending
on
whether
a
permanent
was
used
to
navigate
or
not.
So
it
would
replicate
similar
Behavior
here
as
well.
B
C
C
A
E
A
C
D
A
We
should
change
that
yeah
for
every
everything
new
I
think
all
the
newer
widgets.
We
should
definitely
make
sure
that
they're
all
using
their
own
query-
I'm
gonna
Link
in
the
notes,
but
there
is
a
discussion
going
on
in
the
graphql
in.
C
A
Graphql
Channel
about
removing
batching
on
yeah,
just
removing
Auto
batching,
because
we're
using
HTTP
2.
B
A
Okay,
one
thing
I
wanted
to
talk
about:
I
talked
about
with
you
earlier
Topeka
was
the
the
sort
order.
A
For
activity,
we
are
I,
think
we're
just
getting
everything
from
that
discussions
Json
and
then
we're
ordering
it
on
the
front
end.
Yes,
it's
going
to
be
a
little
bit
more
difficult,
I
think
on
the
in
the
graphql
version,
because
we're
not
going
to
as
easily
be
able
to
grab
everything
unless
we're
doing
it.
In
the
background.
A
Yeah
so
I
think
Alexandria
had
said
that
it's
it's
gonna
be
difficult
to
optimize
that
query
or
the
ordering.
If
we
do
it
on
the
back
end
about
how
hard
we
should
try
to
get
that
done
on
the
the
back
end,.
B
C
D
A
B
I
mean
we
all
questions
for
issues
on
the
first
go,
so
the
Sorting
is
right
now
being
handled
on
the
front
end.
We
were
having
discussions
of
handling
it
in
the
back
end,
but
then
it
looks
like
we'll
have
to
have
to
do
in
the
front
end
only
because
we
have
to
load
all
the
discussions
at
one
go.
B
B
B
D
A
B
If
you
see
yes,
if
you
see
you
can
see
that
first
is
20,
then
we're
loading
in
batches,
the
purpose
13
we
send
the
N
cursor
there
as
well
in
the
rest,
API.
B
Desk
as
well,
because
it's
already
done
on
issues
I
honestly,
I
haven't,
you
know,
looked
into
quotes
so
much.
That
is
my
next
step,
but
yeah
we're
just
having
discussions
on
what's
best
way
to
do
it
for
tasks.
We
should
optimize
it
for
the
best
way
for
tasks,
no
matter.
What
is
done
for
issues
is
what
I
feel,
but
if
there's
no
other
choice-
and
we
just
have
to
do
that-
we'll
have
to
yeah.
D
E
B
A
B
E
A
Only
reason
we're
getting
all
of
the
like
we're
while
we're,
while
we're
getting.
The
only
reason
that
we're
getting
all
of
the
discussions
is
so
that
we
can
order
it
on
the
front
end
if
we
were
doing
like
like
now.
If
we
had
pagination
in
here,
either
infinite
scroll
or
a
button
to
load
more
discussions.
A
B
So
I
asked
the
same
and
it
I
have
had
the
same
thing
at
once
like.
Why
are
we
doing
that?
Why
it
was
the
same
thought
and
then
I
had
discussion
with
Natalia,
and
he
said
that
we
can't
do
that,
because
we
need
to
see
everything
when
for
for
issues
as
well.
Maybe
I
don't
know
about
how
it
will
behave.
B
I
have
just
told
you,
for
example,
first
50
and
then,
if
I
load
more
all
the
discussions,
the
next
50
are
loaded
I,
don't
know
how
it
will
behave,
but
it
is
not
a
good
ux
I,
don't
know
at
least
on
issues.
What
I
do
is
when
I
open
an
issue.
I,
don't
I,
see
everything
at
one:
go
I,
don't
really,
and
it's
not
that
bad
as
well
for
now,
but
it
may
be
for
bigger
discussion
or
something
but
yeah.
A
Yeah
so
I
think
doing
it
the
the
way
we
do
it
with
the
issues
is
a
fine
first
iteration,
just
getting
all
of
the
notes
and
ordering
it
on
the
front.
End
I
think
we'll
wanna
think
through
different,
possibly
different
ux
approaches,
especially
with
like
deep
link
discussions
because,
like
I
think
that's
the
thing
that
causes
performance
issues
right
now
when
we
are
linking
to
deep
linked
discussions,
is
that
we
have
to
load
everything
first
before
we
can
scroll
down
to
that.
That
note
that
is
deep,
linked
and
oftentimes.
A
It
takes
a
it
takes
a
while
for
it
to
for
that
to
be
loaded,
yeah,
so
I
think
as
the
first
iteration
yeah.
Let's
just
get
them
all,
we'll
just
paginate
in
the
background,
I,
don't
think
that's
the
highest
priority
right
now,
because
it's
going
to
take
a
while
for
tasks
and
okrs
to
get
more
than
a
hundred
100
system
notes
in
so
I
think
things
like
maybe
ordering
is
probably
a
higher
priority.
B
A
A
Yeah,
so
the
ability
to
go
news
first,
I
think
is,
is
a
higher
should
be
a
higher
priority
than
the
pay
attention
be
good
with
that.
A
Okay,
so
the
next
one,
then
for
anyone
else,
have
any
questions
or
anything.
On
this
note,
okay,
let's
move
on
to
the
commenting
one
I,
don't
think
we
have
anything
to
show
outside
of
what
the
Pika
showed
Alexandra's
working
on
adding
discussions.
A
I,
don't
know
if
there's
an
MR
already
for
it,
but
to
add
comments
to
to
that
same
graphql,
API
Simon's,
going
to
start
working
on
the
front
end
for
discussions,
possibly
probably
borrowing
the
code
from
discussions
code
from
design
management
or
at
least
using
that
to
start
off
with.
C
A
Yeah,
okay,
you
want
to
lay
out
a
we
want
to
try
to
get
done
by
next
week,
just
rendering
discussions
kind
of
dependent
on
what
we,
where
we're
at,
on
the
back
end
being
able
to
Adam.
C
A
Thinking
it
doesn't
even
have
to
be
styled
yet,
but
as
long
as
we
can
just
show
that
we're
getting
some
text
yeah
we're
getting
stuff
from
that
API
I
think
that'll
be
that'll,
be
good.
It'll,
be
good
to
show
that
kind
of
progress,
foreign,
okay,
cool,
all
right,
kashal
hierarchy,
widget
did
I
put
this
yep
I,
don't
know
if
I
told
you
no.
E
No
I
I
was
going
to
add
it
in
the
morning
when
I
started
so
I've
added
more
details.
So
let
me
show
my
screen
and
I
should
do
all
right
so
demo
for
hierarchy
widgets.
So
we
now
have
a
tree
view
running
so
I'll,
just
I'll,
first
demo,
how
it
behaves
and
then
we'll
do
the
demo
towards
adding
a
new
objective
or
a
key
result.
So
last
week
we
saw
how
this
widget
was
showing
up
within
the
work
items.
E
Queue
where
this
add
drop
down
button
would
show
a
bunch
of
actions.
Now
some
of
these
actions
are
functional,
which
means
you
can
see
a
key
result
as
well
as
objectives
with
their
respective
icons
within
the
preview.
You
can
expand
an
objective
and
it
will
show
you
further
objectives
and
children
key
results.
Again
only
objective
can
have
children.
E
Key
results
are
Leaf
nodes,
essentially,
which
means
key
result
cannot
have
any
more
children
inside
it,
but
you
can
continue
expanding
as
long
as
you
want,
and
if
an
objective
has
further
children
down
up
to
nine
levels,
I
think
you
can
expand
it
up
to
nine
levels
and
see
the
values
here
clicking
on
one
of
these
I
items
will
navigate
to
its
own
page.
We
did.
Another
fix
yesterday,
which
also
got
merged
was
basically
fixing
this
breadcrumb
so
earlier.
E
If
and
even
today,
if
you
go
to
gitlab.com
and
open
one
of
the
task
item
in
its
own
page,
you
would
notice
that
this
parent
button
shows
issue
icon
and
clicking
on
it,
takes
you
to
its
respective
issue
page,
because
that's
that
is
hard-coded
in
into
the
breadcrumb
logic,
so
we
opened
an
MR
yesterday.
I
have
linked
it
into
our
agenda
here.
E
So
basically,
what
we
do
now
is
we
we
identify
what
the
parent
work
item
type
is
we
show
relevant
icon
and
the
URL
also
points
to
correct
work
item.
This
will
act
as
a
good
stop
Gap
until
we
get
the
model
running.
So
our
end
goal
here
is
to
have
a
model
open
up
once
an
item
is
clicked
from
this
page
and
the
model
will
allow
you
to
navigate
between
all
the
children.
E
While
you
remain
on
the
page,
but
until
we
have
that
functional,
we
can
navigate
to
individual
work
items
pages
and
you
can
click
on
breadcrumb
and
it
it
will
take
you
to
the
parent
mode.
So
that's
how
it
works
now
going
to
the
create
part,
so
you
can
basically
create
a
new
objective,
so
I'm
going
to
just
say,
object
to
10
and
I'll
just
go
ahead
and
create
so
it
will
immediately
get
added
into
the
tree
list
and
this
form
remains
open
in
just
in
case.
E
Someone
wants
to
create
multiple
objectives
before
they
can
start
using
those
similar
for
key
results.
You
can
click
on
new
key
result
and
just
type
in
the
key
result.
You
need.
E
And
it
will
show
up
in
the
list
and
clicking
on
key
result
will
show
you
all
the
relevant
attributes
except
the
tree
view.
Widget
is
not
available
because
key
results
cannot
have
children.
You
can
add
a
bunch
of
attributes
here.
The
tree
view
doesn't
show
these
labels
or
assignees
on
the
tree
view
itself.
So
that's
our
goal
for
next
week,
probably
so
in
in
Next
plan
weekly,
we
will
start
showing
these
attributes
into
the
preview.
E
Similarly,
you
can
add
an
existing
objective
like
clicking
on
existing
will
show
you
list
of
all
the
objectives
available.
So
I
can
just
click
on
this
click
on
ADD
objective
and
it
will
get
added
here
into
the
tree.
View
and
yeah.
That's
about
it.
Any
questions.
A
E
Yes,
so
up
to
nine
levels,
you
can
do
so
if
I
go
to
objective
one
you
can
see
sample
objective
is
its
panic.
Apparently
our
breadcrumb
doesn't
show
all
the
levels
of
depth.
I
would
at
least
prefer
to
have
three
levels
of
depth:
much
like
our
top
level
breadcrumb
here,
but
that's
a
new
feature
and
I.
E
Once
we
add,
support
for
model
user
will
stay
on
the
same
page,
which
means
that
user
will
continue
to
see
sample
objective
as
a
page,
while
all
the
children
objective
will
be
shown
within
the
model,
dialogue
and
clicking
on
breadcrumb
view
within
the
model
or
the
tree
view
within
the
model
will
load
the
data
async.
E
It
will
not
navigate
the
page,
but
until
we
have
that
model
functional
because
that's
a
significant
front-end
work,
I
got
the
breadcrumb
working
so
that
we
still
have
a
workaround
to
navigate
between
objectives,
even
if
it
means
reloading
the
page.
So
so,
if
I
go
further
down,
so,
for
example,
if
we
are
in
objective
4,
it
doesn't
have
any
nodes.
E
So
I
can
basically
click
on
existing
objective,
and
it
will
show
me
the
objective
here
and
I
can
click
on
this
add
objective
and
then,
if
I
go
all
the
way
to
the
top
level
objective,
which
is
four
levels
deep
at
this
point.
So
if
I
expand
it,
you
can
basically
continue
to
expand
it
further
and
it
will
show
the
entire
thing
in
terms
of
limits.
E
Like
I
mentioned,
each
parent
node
can
have
up
to
100
items,
which
means
an
objective
one
can
have
directly
100
children,
which
could
be
a
combination
of
key
result
as
well
as
objectives,
but
in
terms
of
depth.
Nine
levels
is
the
limit,
so
an
objective
one
can
only
have
eight
more
childrens
because
one
level
is
already
there
by
the
sample
objective,
so
nine
levels,
deep
100
items
per
node,
that's
the
limit
for
now
yep.
C
C
E
E
So
user
was
not
seeing
both
the
breadcrumbs
but
yeah,
but
you're
mentioning
make
sense
that
we
need
not
to
have
work
items
here,
but
that's
a
separate
conversation,
because
I
personally
would
have
preferred
to
have
okrs
in
its
own
navigation
route
rather
than
part
of
issues.
Because
if
you
go
to
issues
list,
you
can
see
all
your
objectives
in
key
key
results
showing
up
in
the
issues
list
which
is
already
polluting
this
list,
because
there
are
a
bunch
of
other
types
that
we
support.
That
is
incident
test
cases
and
task.
E
So
I
would
rather
have
a
separate
navigation
item,
but
then
again
for
the
MVC.
We
are
not
enabling
this
feature
for
all
the
projects,
especially
not
for
gitlab
project
itself.
It
will
be
on
its
own
project,
where
there
will
only
be
a
bunch
of
these
objectives
and
key
results.
There
won't
be
much
issues
to
worry
about,
so
that
is
the
reason
why
we
haven't
thought
about
this
breadcrumb
yet
because
it
will
be
internal
use
but
yeah
before
GA.
E
We
might
want
to
look
into
a
way
to
combine
all
the
breadcrumbs
into
a
single
view
where
user
will
be
able
to
see
group
and
then
project
and
then
eventually
okrs
as
well
as
as
a
as
a
workaround,
though
this
can
be
renamed
via
Hamilton
view
it.
It
is
fairly
doable.
So
there
are
certain
variables
that
we
pass
on
to
the
layout
view
in
the
hammer.
So,
although
it
says
work
items
but
for
even
for
MVC,
I
can
just
go
ahead
and
rename
this
to
say
okrs
and
it
will.
E
It
will
work
just
fine
so
that
it
it
doesn't
confuse
user
that
this
is
work
items
but
then
again,
Urology.
E
E
You
okay,
so
if
there
aren't
any
questions,
then
we
can
move
on
to
the
next
one.
A
A
We
have
the
same
issue
with
the
double
breadcrumbs
back
then
so
Lexus
put
some
thought
into
it
and
I
think
we
just
deferred
the
decision
on
that
other
breadcrumb
on
that
page
here
I
have
I'll
link
to
the
discussion
on
it
on
a
closed
issue.
I,
don't
think
we
ever
created
a
follow-up
issue
which
we
should
to
continue
having
that
discussion,
because
yeah
I
agree
having
the
double,
especially
if
we're
going
to
use
that
page
I
think
we'll
use
it
all
the
time.
A
From
the
issue
list,
if
we
keep
objectives
or
if
we
keep
okrs
within
the
issue
list
down
the
road,
if
a
user
clicks
on
an
objective
in
the
issue
list,
are
we
going
to
want
to
show
that
objective
in
a
modal
or
are
we
going
to
want
to
always
show
it
on
the
dedicated
page?
So.
E
If,
if
user
is
on
a
issues
list
page,
then
whatever
objectives
they
are
seeing
here
depending
on
whether
that
objective
itself
belongs
to
some
other
objective,
we
are
going
to
take
user
to
its
own
view.
Ideally,
what
I
would
want
is
if
an
objective
is
directly
root
of
this
particular
project.
E
Only
then
it
should
show
up
in
this
list
right
now,
if
you
notice
that
there
are
a
bunch
of
children
objectives,
also
showing
up
here,
I'm,
not
sure
if
it
is
even
available
from
backend
perspective,
but
ideally
I
would
want
only
sample
objective
to
show
up
here,
because
all
the
other
objectives
are
children
of
sample
objective
and
if
we
want
all
the
children
to
show
up
only
in
model.
That
means
these
objectives
and
key
results
do
not
need
to
show
up
here.
E
Users
should
only
see
the
top
level
objective,
which
is
directly
at
the
root
level
for
this
project,
and
when
user
clicks
on
this
objective
only
then
they
can
see
all
the
children
objectives
which
belong
to
the
sample
objective
directly.
So
that's
a
separate
conversation.
I
would
have
to
discuss
it
with
Amanda
as
well
like
whether
we
want
that
functionality
or
limitation
in
any
way
where
issues
list
page
will
only
show
objectives
which
are
direct
children
for
this
project
and
not
grandchildren
for
this
project.
So
to
speak.
A
Gotcha
I
have
a
couple
of
questions
around
the
modal.
Then,
if
we
are
within
a
we
open
up
an
objective
and
then
we
open
up,
KR
or
yeah
key
result
we're
going
to
want
to
show
that
key
result
in
a
modal.
Yes,
now
what
happens
if
they
click
on
the
breadcrumb
for
the
objective
from
within
that
model,
yeah.
E
Yeah,
so
it
will
behave
similar
to
what
it
does
today
like
if
you
go
to
task
list
and
if
you
click
on
this,
it
basically
reloads
the
page
with
the
issues
page
as
a
base
page.
Ideally,
what
should
happen
is
if
we
know
that
this
particular
button
points
to
the
underlying
issue
itself,
then
it
should
be
similar
to
what
it
does
when
you
close
the
model
like
it
should
just
dismiss
the
model
and
should
not
do
anything
else
so
that
behavior
is
doable.
It
is.
E
It
is
fairly
easy
to
do
so
from
purely
front-end
perspective,
but
right
now,
yes,
clicking
on
Sample
objective,
takes
you
to
a
different
page,
because
model
doesn't
exist.
We
would
need
to
have
models,
show
up
for
pretty
much
every
item
when
user
clicks
on
any
item
from
the
tree,
but
until
model
is
available,
I
wanted
to
have
some
work
around
available,
which
means
I
got
this
breadcrumb
working
with
links
applicable
and
pointing
to
the
correct
page.
Okay,.
A
E
Yes,
we
should
just
replace
them.
It
will
basically
act
as
a
finder
window
in
your
operating
system
like
as
long
as
you
are
in
a
finder
window
and
you
click
on
a
path
bar
and
navigate
between
directories.
It
stays
the
same
right.
So
that's
the
plan
here
as
well
like
if
user
is
the
moment
user
is
on
a
root
or
objective,
which
is
part
of
the
project
directly.
E
The
moment
you
open
the
model
by
clicking
on
either
of
these
items,
and
then
you
start
navigating
so,
for
example,
imagine
that
clicking
on
objective
one
would
have
opened
another
model.
Then
user
will
see
this
whole
thing
inside
a
model
for
that
objective,
one
as
well
as
user
will
see
a
tree
view
with
these
three
items
showing
up
there
and
clicking
on
these
three
will
just
update
the
data
within
that
model.
Update
the
breadcrumb
as
well
as
the
information
value
model
remains
there
and
it
will
be
an
async
operation.
E
A
C
C
Which
one's
for
this
description
switcher,
so
we've
got
the
little.
There
was
previously
a
toggle
above
here
for
source
and
Rich
text
and
we'll
just
move
that
to
this
little
friendly
drop
down
to
switch
between
markdown
and
Rich
Text
views
and
for
Rich
Text
views.
Then
we
also
move
the
toolbar
to
the
bottom
and
made
the
button
a
little
bit
smaller.
A
Really
quick
I
have
one
the
what's
the
plan
to
default,
that
on.
A
D
C
A
Oh
yeah,
that's
what
I
wanted
to
ask
you,
so
the
toggle
you
have
now,
which
looks
are
not
nicer
than
the
button
is
that
are
we
doing
that
for
issues
too?
Behind
the
current
yeah.
C
E
D
E
I
I
just
noticed
that
when
you
edited
the
description
and
switched
to
the
rich
editor
view,
the
toolbar
was
on
the.
C
Top
and
the
toolbar
was
at
the
top.
Yes,
that's
not
the
case
anymore.
I
just
haven't
updated
this
Branch.
E
E
C
That
is
Rich
text
and
inline
notes.
Rendering
is
just
a
random
science
project
I
picked
up
for
when
you
hover
to
an
issue,
then
you
get
the
tooltip,
but
that's
less
useful
when
you're
hovering
to
a
note,
so
I
just
added
a
thing
where
it's
on
Hover
currently
just
adds
it,
and
then
it
waits
till
you
click
before
loading
it,
but
it
just
loads.
The
comment
in
line
inside
of
block
quote
so
I
need
to
figure
out
some
stuff.
C
If
anyone
has
UI
input
ideas,
we
kind
of
want
to
be
able
to
collapse
this
again,
and
we
want
some
clear
things
saying
that
you're
like
expanding
or
collapsing
the
note
within
this
issue.
We
want
to
be
able
to
handle
nested
ones,
because
this
is
linking
to
this
comment
itself
and
like
should
we
have
a
max
depth
or
you
can
just
kind
of
keep
expanding
comments
on
the
same
issue.
E
C
We
when
we
load
it,
then
it
just
does
a
line
break
with
any
adjacent
text,
because
it's
just
adding
in
the
inline
content.
There
I've
just
made
a
load
on
Hover
and
then
it
doesn't
expand
until
you
click,
but
we
probably
want,
like
some
separate,
expand
collapse
button
and
to
still
make
the
links
work
so
that
you
can
still
go
to
the
other
comment.
If
you
want.
C
It
isn't
currently
loading
on
the
Mr
Page,
oh
wait;
no,
it
might
be
now.
Let's
find
out.
I'll
tell
you
in
a
moment,
foreign.
A
C
B
E
Is
a
huge
usability
for
reviewers,
where
they
want
to
refer
to
a
certain
comment,
and
they
don't
want
to
basically
to
jump
around
between
comments.
C
Yeah,
that
was
that
was
the
main
reason
that
I
was
interested
in
it,
and
the
initial
discussion
was
about
adding
it
in
popovers,
just
so
that
you
could
view
it
like
you're
viewing
notes.
But
the
issue
was
that
for
a
lot
of
comments
like
this
one,
then
that's
way
too
much
content
to
even
try
putting
in
a
pop
over,
and
if
you
have
something
like
a
mermaid
diagram
at
the
top,
then
this
little
area
doesn't
show
you
anything
of
substance.
C
So
I
was
going
to
fill
out
some
kind
of
tool
tip
just
saying,
like
a
click
to
expand,
and
we
still
want
then
an
easy
way
to
click
to
get
to
the
issue.
So
that's
like
unsolved
problems
is
how
to
make
the
normal
link
still
work.
I
was
either
going
to
be
like
when
it's
expanded,
then
you
can
click
and
we
add
a
separate
little
button
for
collapsing
or
anything.
C
But
this
was
like
just
having
an
inline
and
in
a
regular
block,
quote
element
solved
most
of
the
issues
that
I
had
with
them
and
seemed
okay,
because
again
with
the
popovers,
the
tricky
thing
was.
Would
you
have
a
pop
over
inside
your
pop
over
and
should
that
be
smaller
and
we
just
scale
everything
down
by
75
and
the
text
gets
smaller
and
smaller
I
thought
that's
stupid?
Let's
just
do
nested
quotes.
C
B
C
C
C
Don't
work
yet
I
still
need
to
update
to
do
that,
but
yeah
the
main
thing
for
this
to
just
what
the
interaction
should
be
like
just
need
to
talk
to
Nick
or
Alexis,
or
anyone
that
has
ideas
just
of
how
we
want
to
do
yeah
how
to
expand
them
and
how
collapsing
could
work.
Yeah.
D
E
Yeah
I
think
having
a
visual
separation
between
a
proper
block
comment
that
someone
has
left
versus
this
expanded
comment
visually
like
maybe
a
different
style
would
be
super
useful
because
user
will
be
able
to
identify
like
okay.
This
was
expanded
and
this
was
a
block
coming.
C
A
Exactly
what
I
was
going
to
say
too,
like
how
does
slack
Do
It
when
you
link
to
it
when
you
include
a
link
to
a
another
slack
conversation,
there's
some
kind
of
visual
difference.
E
It
it
shows
the
commenter's
name
additionally,
so
maybe
that
is
something
we
can
leverage
like.
If
we
know
who
commented
this
particular
comment,
then
we
can
show
additional
information
like
if
you
form
a
link
to
a
slack
discussion.
It
shows
who
commented
that
in
which
channel
how.
C
A
Yeah
because
I
wonder
if
down
the
road
we
would
want
like
automatic
unfurling
of
it
to
like
slack,
does
I,
don't
know
how
that
would
do
performance
wise,
but
yeah
I
mean
that
might
be
an
option.
A
Okay,
we
are
a
bit
overtime,
John
had
another
comment
in
there,
but
it's
async
just
about
the
Retro
out
of
the
Retro.
So
please
read
that
and
comment
yeah
weigh
in
on
the
Mr.