►
From YouTube: Plan | Weekly Stage Sync - 2021-11-10
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
B
Cool
all
right,
welcome
plan
stage
weekly
november
10th
not
prepared
with
the
agenda,
yet
who's
got
the
first.
C
Point
so
it's
me
hi,
so
I'm
the
deck
writing
lead
for
13.5.
C
So
just
just
letting
you
know
and
and
like
if
you
have
anything
that
needs
docs
review,
send
it
to
me
when
is
ready
for
review
no
later,
because
I
I'm
gonna
like
clear
my
schedule
closer
to
the
release,
because
now
also
the
tech
writer
is
in
responsible
for
kind
of
like
publishing
the
the
docs
for
all
the
releases
to
the
dark
side
as
well-
and
I
haven't
done
it
before
so
it
might
be
messy.
D
Thanks
merchant
want
to
talk
about
a
slight
shift
in
the
implementation,
rollout
strategy
for
work
items.
We've
learned
a
lot-
I
guess
in
the
last
few
months
as
his
stage
and
as
his
product
group
teams,
and
also
kind
of
wrestling
with
the
temporary
headcount
reset
they
kind
of
I
felt
like
we
started
picking
a
momentum
on
work
items
and
then,
a
couple
days
later,
we
had
a
bunch
of
engineers
who
were
kind
of
asked
to
go
work
on
workspaces.
D
I
think
we
all
understand
why
and
that's
globally
optimal,
but
net
net
is
that
it's
it's
hard
to
iterate
on
the
original
road
map
and
also
it's
hard.
We
found
to
sort
of
like
just
share,
have
the
shared
initiative
without
clear
boundaries
and
clear
your
eyes
for
who's
driving,
which
part
so
longitude
within
products,
at
least,
and
I
think
we've
talked
to
the
engineering
rangers
already
and
one
bloop
and
the
rest
of
the
team.
Just
kind
of
fyi
opened
up
for
discussion.
D
We
still
want
to
reach
the
eventual
goal
of
work
items.
So
that's
not
changing.
D
I
think
just
the
order
of
operations
is
a
little
bit
and
what
we're
gonna
do
is
push
feature
sort
of
is
a
later
thing
to
happen
once
you
get
some
other
foundations,
foundational
stuff
in
place
and
then
kind
of
shift
to
doing
tasks
first,
as
a
child
of
ish
type
issue,
and
in
terms
of
like
clear,
I
guess,
swim
lanes
or
whatever
for
the
different
teams
product
plan
continue
to
own
the
relationships.
Parenting
all
that
good
stuff
project
management
on
the
new
work
item,
issue,
detail
view
and
iterating
on
that.
D
I
think
kristin
is
going
to
be
working
on
a
new
settings
view
for
work
items
where
you
can
be
the
hierarchy
of
your
work
items
and
all
that
good
stuff.
So
that's
just
an
fy
there's
a
lot
more.
D
Let
me
see
if
I
can
link
into
it
and
we
sort
of
refactored
the
the
kind
of
pair
epic
to
kind
of
show
some
of
the
high
level
critical
paths,
I'll
put
it
down
under
0.3
here
or
actually,
oh
there's
put
it
under
our
pass,
will
eventually
converge
and
product
planning
can
own
their
own
critical
path.
A
project
management
can
on
their
own
critical
path
and
then
certified
can
on
their
own
critical
path
to
eventually
merge
on
the
vision
that
we've
always
had
for
work
items.
D
So
what
this
practically
means
is
we're
going
to
figure
out
how
to
get
parenting
within
current
issues,
so
there
can
be
maybe
like
a
task
on
an
issue.
There's
a
couple
different
ways
that
we're
exploring
creating
tasks
kristin
and
alexis
designed
this
really
awesome
kind
of
new
parenting,
widget
that
they're
exploring
that
we
could
drop
into
the
legacy
issue.
Ui
they're,
also
exploring
maybe
dropping
in
the
existing
epic
kind
of
tree
type
thing
to
serve
in
that
capacity.
D
It's
totally
up
to
them
how
they
want
to
move
forward,
and
then
the
goal
is
to
open
up
a
child
task
on
an
issue
within
a
modal
on
the
issue
detail
view.
So
we
can
slowly
iterate
on
the
new
work
item,
detail
so
the
stuff
that
we've
already
done
for
a
feature
most
of
it,
I
think,
hopefully,
can
be
reused.
Like
the
title
description.
We
still
like
have
the
same
iteration
path.
There
we're
sort
of
switching
the
the
type
of
work
item
that
we're
going
to
iterate
on.
D
So
that
way
we
don't
get
to
this
point
where
we
roll
out
a
massive
new
workout
detail
view
that
hasn't
been
performance,
tested
or
kind
of
put
through
the
paces.
So
I
just
want
to
open
that
up.
If
there's
any
conversations,
if
kristen
wants
to
add
more
context,
she's
welcome
to
do
that,
but
it's
sort
of
just
in
fyi.
E
Yeah
thanks
for
the
the
extra
little
bit
of
context
about
like
why
you
know
why
it's
important
to
split
in
this
way
I
mentioned
in
the
agenda
like
that
from
a
backend
engineering
perspective
like
it's,
it's
perhaps
not
so
desirable
to
split
duties.
E
This
way
like
I
would
want
to
make
sure
that,
as
we
implement
new
work
items
that
that
there's
collaboration
going
on
that,
both
teams
are
fully
aware
of
what
the
other
team
is
working
on
and
so
on,
and
so
I'll
need
to
perhaps
have
another
touch
point
with
jake
and
donald
for
that
yeah
and
just
one
other
thing.
I
didn't
mention
the
agenda
but
I'll
I'll
I'll
fill
it
in
afterwards.
D
And
I
I
think
I
had
the
next
point.
I
highly
encourage
collaboration
amongst
the
teams,
especially
in
engineering,
we're
not
saying
don't
collaborate,
we're
just
sort
of
saying
we're
kind
of
splitting
this
up,
so
that
we
give
each
thing
proper
attention
and
sort
of
also
removing
dependencies
between
the
teams.
So
kristin
can
work
on
her
vision
for
parenting
and
like
hierarchies,
and
I
can
work
on
the
new
workout
detail
view
without
sort
of
cobbling
all
these
things
up
and
coupling
them
into
one
big
thing
that
has
a
bunch
of
dependencies.
D
They
can't
ship
until
all
of
those
are
satisfied,
so
it
definitely
lets
us,
be
it
more
incremental
and
iterative
and
a
little
bit
more
autonomous.
D
But
I
don't
take
any
of
this
to
say,
like
engineers
shouldn't
collaborate
like
please
do
or
else
we'll
end
up
with
this
like
weird
frankenstein
thing
which
we
want
to
avoid,
I
don't
know
kristen
you're
about
to
type
something
you
want
to
talk
about
the
kind
of
bringing
some
clarity
to
the
dris
for
the
different
things
and
we
can
sort
through
that
on
the
caller,
or
we
want
to
do
that.
Async.
F
I
think
one
of
the
things
that
we're
missing,
though
right
now,
is
more
collaboration
between
design
and
engineering
and
like
just
as
a
team,
because
the
the
way
these
calls
are
structured
and
because
we
don't
have
as
much
group
level
discussions
about
these
things.
I
think
we
may
actually
get
better
output
collaboration
as
a
team
if
we
move
to
these
smaller
groups
and
have
a
like
a
smaller
footprint
that
we're
responsible
for
every
roadmap.
F
But
I
do
agree,
we
have
to
get
really
clear
on
what
we
need
to
deliver.
What
each
team
has
where
the
crossover
points
are,
because
there's
still
going
to
be
them
and
then
really
double
down
in
our
groups
to
work
with
each
other
use
things
like
the
design
management
feature
to
bring
the
engineering
team
in
really
soon
on
the
designs
as
soon
as
they
go
up
and
have
really
close
collaboration
on
what
we're
delivering
to
our
our
end,
the
end
users,
our
customers.
F
I
think,
ultimately,
like
one
of
the
things
in
plan,
that's
been
difficult
for
me
because
it's
very
different
from
create
the
way
we
we
track
at
the
stage
level.
There's
a
lot
here
and
it's
very
broad-
and
I
sometimes
just
kind
of
get
overwhelmed,
even
on
calls
like
this
to
like
think
about
it
from
the
whole
stage
level-
and
I
forget
my
customers
when
that
happens
so
like
really.
What
we
should
be
doing
in
my
in
the
product
planning
group
is
we're
really
focused
on
portfolio
managers.
We
have
designers
as
end
users.
F
We
have
different
jobs
to
be
done
than
the
project
management
team.
I
think
we
should
really
be
thinking
through
those
really
high
level
needs
for
who
we're
building
for
and
that's
harder
to
do
at
the
stage
level,
because
we
have,
we
actually
have
different
goals
that
we're
going
after
and
different
jobs
to
be
done.
F
As
a
pm
as
well
to
my
customers
and
with
the
group
that
we're
in
but
still
contribute
back
at
the
stage
level,
so
it's
so
that
we
have
these
conversations
and
that
we
still
retain
a
good
level
of
communication
between
the
whole
stage.
So
that's
sort
of
just
off
the
top
of
my
head.
How
I'm
feeling
about
this?
I
think
it's
actually
really
exciting.
F
To
kind
of
separate
these
pieces
out
and
really
let
everyone
have
more
communication
as
well
about
how
they
feel
about
that
too,
and
just
what
we're
building
and
why
essentially.
B
Yeah
so
the
kind
of
the
thing
that
stood
out
most
around
what
you
said
was
the
collaboration
between
engineering
and
ux,
and
I'm
interested
to
hear.
If
anyone
has
ideas
on
how
we
can
improve
that.
F
F
Another
thing
I've
noticed
is
because
we
have
so
many
channels.
I
even
me
like
when
I
like
scroll
through
I'll
notice,
something
I
missed
in
like
an
fe
channel,
whereas,
like
in
my
last
team,
everything
went
through
the
group
channel,
so
everyone
was
aware
of
our
like.
If
there
was
a
design
question,
if
there
was
a
back
end,
question
front
end
like
the
whole
team
knew
you
didn't
have
to
kind
of
piecemeal
it
through
all
different
channels.
F
So
I
think
the
collaboration
could
also
simplify
if
it
was
in
one
spot
and
everybody
contributed
in
the
same
way
in
terms
of
how
they
asked
those
types
of
questions
to
the
team
or
it
could
reduce
even
to
a
few
spots.
Instead
of
like
there's
a
lot
like
three
or
four
and
then
similarly
like
just
having
a
more
direct
group,
calls
where
you're
discussing
your
customers
and
like
open
forum
for
sync
design,
questions
sync
between
the
whole
team
and
they
wouldn't
be
mandatory
and
they'd
be
recorded.
G
Yeah,
I
just
I
put
some
of
the
things
kristen
said
as
well,
but
yeah
just
making
sure
we're
aligned
on
requirements.
I
think
is
number
one
making
sure
we
understand
what
we're
building.
G
So
we
could
have
good
conversations
about
it
and,
like,
like
you,
said
chris,
and
not
just
what
we're
building,
why
we're
building
it,
who
we're
building
it
for
just
to
make
sure
we
are
discussing
kind
of
like
things
effectively
and
then
also
from
a
tactical
perspective,
like
kristen,
said,
make
use
of
things
like
design
management,
make
sure
we're
collaborating
intentionally,
which
I
think
you
know
we're
usually
good
about,
but
making
sure
we're
being
inclusive
and
doing
these
things
in
the
async
way,
as
well
capturing
feedback
in
a
consolidated
well
way
as
well.
G
E
E
Yeah,
no,
I
just
I
just
wanted
to
clarify
that
point
like
it's,
not
that
people
wouldn't
collaborate
or
wouldn't
want
to
collaborate.
I
think
quite
the
opposite.
It's
just
that
like
we're
addressing
this
by
splitting
further
our
planning
and
design
between
two
groups,
and
so
we
have
to
be
more
proactive
in
seeking
out
to
collaborate.
For
example,
if
we
were
to
design
something
completely
in
isolation
on
product
planning,
not
knowing
that
a
decision
had
been
made
in
project
management
that
implement
that
affected
affected
it.
H
H
I
think
that,
for
me,
one
of
the
challenges
has
been:
we've
been
working
on
so
many
big
ideas
that
it's
a
little
harder
for
me
to
get
all
the
questions
answered
that
I
need
to
get
answered
async
because
often
times
my
questions
will
spur
more
conversation
which
brings
more
questions
and
before
we
know
it,
we've
got
these
threads
that
are
just
massive
of
content
and
then
separately.
I've
got
a
folder
of
bookmarks
related
to
work
items
that
probably
has
like
30
different
issues
and
ethics
in
it.
H
I
feel
like
I
can
even
pull
in
an
engineer
and
then
I've
got
technical
questions
about
constraints
as
well,
which
is
when
I
usually
do
bring
engineers
in.
So,
if
there's
something
you
need,
I
summarize
to
say
from
me
for
sure.
Please
don't
hesitate
to
ask
and
I
will
try
to
over,
communicate
and
share
anything
that
I've
got
going
on
just
in
case.
That
would
be
helpful
and
if
it's
not,
then
feel
free
to
ignore
it.
J
Yeah
thanks
I've
been
trying
that
on
our
team
to
help
minimize
interruptions
just
jumped
in
here,
because
I
saw
you
had
a
meeting-
one
thought
is
what,
if
you
had
something
like
ux
has:
where
there's
they
have
those
periodic
ux
showcases
each
individual
team.
You
could
periodically
have
a
meeting
and
show
off
like
here's,
what
we've
been
working
on
and
that
will
help
minimize
those
feedback
loops
of
knowing
what
the
other
teams
are
working
on
and
how
it
might
impact
you.
G
Oh
no,
I
was
just
saying
that
sometimes
we
share
things
like
that
async
and
I
think
it's
really
helpful
just
to
kind
of
like
that's
something
I'm
trying
to
get
better
about
too
just
kind
of
review,
what
you're
working
on
async
periodically
and
send
that
up
go
ahead.
Chris.
F
F
After
taking
our
input
to
just
move
forward
and
move
fast,
we
can
always
especially
ui
stuff.
We
can
change
later.
If
there's
an
iteration,
we
need
to
make
that
works
better
for
product
planning,
and
maybe
we
missed
it.
So
we
can
always
still
adjust
those
things
and
the
goal
would
be
to
move
forward
faster.
I
do
know
with
engineering.
There
are
a
lot
of
really
right
now,
because
it's
a
shared
work
items,
architecture,
thing
things
are
more
permanent
and
those
discussions
probably
need
a
little
bit
more
time
and
overlap,
but
especially
with
design.
H
As
I
said
in
the
issue
the
other
day,
there
are
dozens
and
dozens
of
things
that
need
to
be
considered,
and
I
need
to
talk
with
the
foundations
team.
I
need
to
evaluate
patterns
in
the
product
so
that
all
just
takes
a
ton
of
time,
so
the
smaller
we
can
get
the
pieces
that
we're
working
on
the
faster.
H
K
Yeah,
I
I
I
totally
agree:
we've
definitely
been
focusing
on
big
pieces
and
it's
hard
to
make
real
progress.
Sometimes
on
that.
So
small
is
important.
I'm
just
a
little
worried
that
the
informations
and
the
decisions
and
the
architectural
pieces
are
not
going
to
get
going
to
flow
between
the
teams
and
not
because
of
anybody's
fault.
Just
because
you
put
your
head
down
and
you
work
and
that's
what
happens
and
it
doesn't
get
communicated.
Maybe
so
I
agree
with
john.
K
D
Yeah,
I
was
just
gonna
echo.
I
agree
with
that,
and
I've
found
personally,
I
haven't
been
involved
in
a
ton
of
the
topics,
some
of
them,
but
the
engineering,
technical
discussion
issues
or
use
discoto,
and
we
use
the
topics
and
things
like
that.
D
I
would
love
to
have
those
continue,
because
it
is
a
great
place
to
capture
those
sort
of
big
architecture
decisions,
and
I
also
think
we
should
continue
to
leverage
like
blueprints
like
architecture,
blueprints
and
things
like
that
as
a
canonical
source
of
truth
for
decisions
that
have
been
made
just
because
it's
a
living
document-
and
it
also
enables
any
team-
not
just
here
but
eventually
like
we
want
teams
to
be
able
to
self-service,
creating
their
own
widgets
right
in
a
way
that
works
in
the
way
that
we've
architected
them
to
work.
D
So
that
fits
it
nicely
with
kind
of
how
we've
approached
things
technically,
and
so
I
would
encourage
engineers
to
continue
the
discussions
and
then
also
capture
the
outcomes
not
just
in
the
threads,
but
also
in
like
architecture,
blueprints
for
how
how
we're
architecting
things
so
that
people
can
come
behind
us
and
and
contribute
and
not
like
recreate
the
wheel
and
have
the
same
discussions
over
again.
So
maybe
that
could
work.
L
Yes,
I
think
it
was
answered
it's
just
like
I
was
very
confused
what
to
actually
look
for
what
issue
or
epic,
where
the
discussion
was
happening.
I
was
looking
at
the
one
with
yeah.
I
think
it
was
technical
discussion,
but
yeah
I
lost
track
a
bit,
but
I'm
just
gonna
subscribe
to
that
epic
and
the
other
one.
I
am
aware
of.
F
There's
a
chance
we'll
break
the
hierarchy,
widget
implementation
into
a
different
location,
we'll
see
how
it
ends
up.
I
haven't
really
dove
in
yet,
but
that
should
be
the
place
for
the
full
release
of
work
items
for
sure.
E
In
that
case,
should
we
do
something
with
the
issue
that
alexander
has
been
the
dri
for
and
maybe
copy
that
into
the
design
dock
like
because
there
were
a
lot
of
decisions
from
that,
but
that's
my
go-to,
sorry
I'll!
Try
and
I'll
try
to
talk
more
lightly,
but,
like
that's
the
go-to
for
me,
for
if
I
want
to
see
where
things
are.
F
Yes,
and
I
think
that
yeah,
we
should
be
having
more
strategic
and
focused
discussions
around
actually
completing
and
where
we're
at
with
it
and
the
logistics
around
it
and
order
of
priority
which
we're
having
now
it's
just
a
little
more
all
over
the
place.
So
I
think
it
will
get
more
specific
when
we
talk
about
it
with
just
our
our
groups
on
how
we're
contributing
to
it.
F
B
Hello,
hello
is
that
better
yeah
that
works?
Okay,
sorry
about
that.
So
the
one
nice
thing
about
when
we
were
originally
like
more
intentionally
collaborating
on
work
items
as
a
stage
was
that
like
as
dependencies
as
we
come
across
dependencies,
you
know
we
just
know
that
that's
the
that's
the
work
that
needs
to
be
done
next,
regardless
of
who's
going
to
be
working
on
it.
B
I
do
have
concerns
with
us
splitting
in
that,
especially
on
the
product
planning
side,
we're
going
to
run
into
a
lot
of
like
core
architecture
blockers
that
we
need
to
finish
on
the
project
management
side.
B
D
Just
if
you
think
about
the
new
work
item,
ui
is
sort
of
like
a
dependency
for
feature
you
know
like
and
there's
these
these
it
has
to
get
used,
like
parody
with
epics,
in
order
for
us
to
migrate
to
epics.
D
There's
like
a
lot
of
dependencies
in
the
whole
thing,
but
we've
actually
sort
of
split
them
apart,
and
I
think
that's
what
I
was
trying
to
capture
a
little
bit
with
that
critical
path
on
the
epic
and
we
should
keep
that
updated
over
time
is
like
when
there
are
hard
dependencies,
let's
flag
them,
so
they're
visible,
and
I
know
for
me,
I
was
already
planning
on
prioritizing
all
the
things
that
we
would
need
to
eventually
have
feature
right
from
like
the
what
we
implement
in
the
new
workout
detail
view
and
things
like
that.
D
So
as
long
as
we've
we
flagged
them,
I'm
happy
to
prioritize
dependencies
first,
I
think
it
aligns
with
our
values
of
more
or
less
efficiency
and
helping
other
unblock
other
people
to
get
their
work
done.
So
I
have
no
problem
with
that
and
I
think
it
might
just
take
a
little
bit
extra
communication
here
and
there,
but
it
doesn't
need
to
be.
D
B
Yeah,
so
I
don't
think
that's
so
much
the
problem,
because
we
we
take
that
approach
now
like
when
other
teams
are
blocked
by
things
that
we
want
to
accomplish.
B
But
we
still
need
to
do
that
work
you
know,
and
if
it's
going
to
take
like
theoretically,
it
should
take
us
twice
as
long
to
get
some
of
those
blocking
some
of
the
blocking
work
done,
because
we're
working
on
it
within
a
smaller
team
for
just
project
management
side
like
is
that
is
that,
okay
or
are
those
places
where
we
should
pull
in
other
team
members
like
people
from
product
planning
to
help
clear
those
those
blockers.
D
I
I'll
leave
it
to
kristen.
I
think
we
should
just
discuss
it
on
the
case
by
case
spaces,
you
know
and
like
call
them
out
and
identify
them
and
discuss
how
you
want
to
handle
them.
So
I'm
open
to
also
sharing
engineers
from
project
management
with
product
planning.
If
there
are
things
so,
let's
just
discuss
it
and
make
a
decision
each
time.
F
Yeah,
I'm
agreed
with
that
as
well
case
by
case
and,
if
there's
something
eminent
right
now
within
the
next
three
releases,
let's
definitely
talk
about
that
as
soon
as
possible.
An
example
block
for
me
as
a
pm
gabe's
got
enabling
tracking
on
the
whole
work
item,
object
right.
So
if
that
doesn't
happen,
and
we
may
have
to
go
forward
and
build
a
bit
of
tracking
into
the
the
hierarchy
piece
but
not
get
the
whole
thing
and
wait
on
that,
but
that's
okay.
F
B
D
Yeah,
my
sorry,
I
just
lost
the
agenda
for
whatever
reason
my
I
think
the
next
thing
is
basically
can
be
read
only,
but
we're
splitting
out
release
planning
issues
as
well,
and
so
I
created
one
for
project
management.
If
you're
on
the
project
management
team,
please
hop
in
and
discuss
that
and
help
us
refine
it
break
down,
bring
ideas
or
things
that
you
feel
like.
We
need
to
prioritize.
D
I
also
pushed
up
a
team
handbook
page
for
project
management
and
eventually
we're
going
to
deprecate
the
global
plan
page.
I
think
that's
something
that
was
going
to
happen.
If
you
have
questions
comment
on
the
mr,
I
think
I'm
merging,
but
we
can
still
have
discussions
there
and
then
we
can
go
on
to
number
three
holly
read
only
nevermind
four
natalya
yeah.
M
Okay,
let's
have
a
quick
demo
on
the
current
progress
of
creating
a
feature
it
was
featured
at
this
point.
So
I'm
sorry,
that's
not
a
task,
so
I've
added
a
little
button
just
for
demo
purposes,
as
you
can
see
from
our
view.
Work
item
page
currently
we're
using
your
router.
So
this
immediately
brings
us
to
this
super
small
page
where
we
can
add
title
currently.
This
is
just
an
input
field.
I
believe
the
next
demo
will
be
shell
discussing.
M
Should
we
have
an
input
field
or
content
editable
here,
but
currently
it's
just
an
input
field
with
a
focus
and
we
can
add
whatever
title
we
have
and
on
create
click
on
real
life
application.
We
will
have
a
small
loading
time,
probably
with
little
order
on
create
button
which
is
sending
a
limitation
to
the
backend
having
the
result
and
then
redirecting
us
to
the
next
page.
Currently
this
will
happen
super
fast
like
this,
because
I'm
only
writing
down
the
invitation
to
the
local
cache
and
anyway,
the
navigation
will
be
as
fast
as
here.
M
So
basically
this
is
it
currently
we're
not
adding
description
or
something
else
for
the
sake
of
iteration,
and
I
requested
a
back-end
review
on
this
schema.
We
have
added
for
the
mutation,
so
any
input
from
the
john
henry
alexandru
would
be
very
welcome
before
we
move
forward
with
this
scheme
right
now,
thank
you,
super
small
demo
and
onto
the
shell.
N
Yeah
so
I
could
have
demoted,
but
I'm
struggling
with
gdk,
apparently
since
half
a
day
now
so
I'll
just
leave
a
link
to
discussion.
So
here's
the
thing
with
create
a
feature
title.
We
are
exploring
two
options.
We
basically
wanted
to
give
inline
editing
experience
where
a
user
can
click
anywhere
within
the
title
string
and
it
will
become
editable
and
user
can
just
type
in
the
title
text.
N
N
Another
alternative,
which
is
rarely
already
demoed,
is
to
use
traditional
input
field.
There
are
pros
and
cons
with
both
the
approaches
and
we
need
to
arrive
at
one
approach.
I
am
going
for
content
editable
unless
there
are
obvious
caveats
that
we
want
to
avoid
and
stick
to
input.
N
N
So
do
we
want
to
support
any
other
key
combination,
like
maybe
shift
plus
return
to
allow
user
to
put
a
title
text
into
the
next
line,
or
do
we
want
to
basically
allow
user
to
have
n
number
of
words
within
the
title
and
it
would
automatically
wrap
it
to
the
next
line.
N
So
there
are
a
bunch
of
interesting
comments
discussing
both
the
possible
approaches.
It
is
more
of
a
technical
discussion,
so
ux
designers
can
chime
in
their
thoughts
on
which
approach
we
should
go
with,
and
that's
about
that
and
yeah
next
is
kirsten
product
planning.
F
I
would
have
sorry
I
didn't
see
this.
I
was
up
last
night.
I
I
didn't
see
it
on
the
agenda.
So
I'll
get
this
for
the
next
week.
D
Cool,
I
you
can
kind
of
look
at
this.
Just
a
high-level
stuff
for
kind
of
pi
updates,
I'm
going
to
link
in
I'll
drop
in
a
link
to
the
plan
channel.
Whenever
I
do.
The
formal
pi
update
mr
for
this
month,
project
management,
good
month-to-month
improvement.
Four
percent
for
our
unique
users
that
are
using
plan
objects
continued
upper
right
trend
in
terms
of
iteration
adoption.
I
think
I
also
looked
up
epic
adoption.
Two.
D
It's
trending
up
to
the
right
as
well,
so
we're
gonna
get
a
good
uptick
and
there's
good
evidence
that
the
investments
we've
been
making
are
worthwhile
and
that
users
are
using
them.
If
you
wanna,
look
at
more
there's
that
kind
of
link
that
I
put
in
it
has
all
the
breakdown
of
all
the
interactions
across
issues
and
epics,
as
well
as
some
like
high
level
metrics
there,
which
is
pretty
great.
So
you
can
kind
of
check
that
out
questions
about
that
for
b,.
D
Okay,
cool:
this
is
just
a
discrete
discussion.
You
can
add
things
here
async
later,
if
you
want,
because
I'm
working
on
revamping
the
team
planning
and
planning
analytics
category
direction
pages
as
well
as
like
kind
of
breaking
it
apart
to
putting
some
content
and
include
so
we
can
generate
a
group
level
direction
page,
something
that
our
product
leadership
has
asked
us
to
explore
doing.
So
I'm
trying
to
be
a
good
team
member
in
that
respect,
but
I'm
curious,
like
I
know
I've
asked
this
a
few
times
like.
D
Do
you
all
look
at
the
direction
pages?
I've
heard
mixed
responses.
No,
never
sometimes
every
once,
while
and
they're
meant
for
communicating
our
strategy
and
vision
internally
and
externally,
and
so
I
wanted
to
understand
specifically
how
to
make
them
better
in
terms
of
what
content
is
there,
so
that
is
more
meaningful
and
useful
for
our
team
members
internally.
D
G
Yeah,
I
I
like
having
the
jobs
to
be
done
front
and
center,
just
like
to
build
that
empathy
and
like
understand
what
problems
we're
solving
in
plan
in
general
and
then
also
like
the
category
direction
is
really
important
to
me.
Just
because,
as
some
of
the
leadership
consumes,
this
like
that's
how
they
set
some
of
our
okrs
in
ux.
So
having
that
as
the
single
search
entry
is
really
helpful.
If
that
makes
sense,
holly.
H
What
do
you
think
I
echo
all
of
that?
I
completely
agree
and
the
having
the
jobs
to
be
done
may
be
enough
to
not
necessarily
have
to
always
put
a
problem
statement,
and
that
can
be
something
we
can
collaborate
on
together
as
well,
but
having
a
clear
understanding
of
the
problem
that
we're
trying
to
solve
and
then
also
if
we
have
any
data.
H
That's
helpful
one
of
the
most
common
questions
I'm
getting
because
we
are
introducing
a
lot
of
new
design
patterns
is
what
data
do
you
have
to
back
this
decision
and
it's
like
well
we're
trying
to
do
something:
innovative
and
we're
trying
to
keep
up
with
the
competition,
and
there
are
some
things
but
having
any
data
available
in
terms
of
validating
that
problem
and
kind
of
the
like
reasons,
and
why?
Behind
we're
actually
doing
what
we're
doing
is
very
helpful
for
me
to
make
proper
decisions
moving
forward
with
the
ux.
F
So
I
don't
think
that
the
direction
page
necessarily
would
take
up
a
lot
of
space,
but
maybe
having
a
really
short,
even
bulleted
list
of
features
that
you
cover.
That
map
to
feature
tags
in
the
backlog
and
some
kind
of
it
could
be
even
like
an
internal
scale
of
where
that
feature
is
at
or
how.
Because,
if
we're
saying
it's
minimal,
we
think
we
could
take
it
a
lot
further
and
that's
will
sort
of
be
lost
in
the
main
jobs
to
be
done.
D
That's
a
good
point.
We
also
need
to
break
up
the
jobs
we've
done
and
mapped
into
categories.
We
kind
of
held
off
on
doing
that
until
we
clean
up
the
categories
a
little
bit,
so
it
might
be
good
opportunity
to
tackle
this
kind
of.
At
the
same
time,
that's
a
good
co-op.
D
I
guess
this
is
for
proc
design
and
engineering.
I
guess
do
they
help
the
direction
pages
as
they
stand
help
you
understand
our
working
vision
and
strategy
from
a
product
standpoint
and
if
not,
why
not
so
any
thoughts
there.
A
I
didn't
type
this,
but
I
would
say
that
I
don't
regularly
look
at
it,
which
I
should
I'll
admit
that
I
should
more.
I
would
say
the
most
of
the
time
when
I'm
looking
at
a
direction
page
it's
when
I'm
trying
to
track
down
who
is
responsible
for
something
that
I'm
trying
to
you
know
run
down.
So
I
would
say,
like
it's,
not
a
it's,
not
a
thing
I
visit
regularly
and
I'm
I'm
happy
to
say
that
I
should
more
or
I
should
be
like
intimately
familiar
with.
What's
on
that
page.
D
D
I
don't
know
how
valuable
they
are
to
externally
we're
tracking
views,
so
I
can
see
how
many
views
they
get
a
month,
but
I'm
trying
to
if
I'm
going
to
be
asked
to
do
this
as
part
of
my
job
and
measured
basically
on
my
performance
of
how
often
I
do
it,
I
want
to
make
sure
that
what
updates
I
do
put
in
there
are
valuable
for
both
our
team
and
more
or
less
like
get
you
all
to
adopt.
D
It
is
my
challenge
that
I'm
trying
to
explore
so
I'm
sort
of
like
pming
our
internally,
our
team
to
make
them
better
like
this,
I
think
you're
next.
G
F
F
I
think
it's
really
considering
that
out
of
the
audience
and
other
people
who
just
show
up
and
need
to
like
grok
it
really
quickly,
so
I'm
going
to
be
moving
mine
to
a
more
tldr
format
as
much
as
I
can,
where
it's
more
a
little
more
scannable
and
have
more
detail
as
needed,
or
link
out
to
other
pages
that
explain
concepts.
F
Mine
feels
like
it
has
a
lot
of
jargon
in
it
currently,
and
I
just
need
to
make
sure
I
understand
all
that
as
well
and
that
it
does
align
to
where
we
want
to
go
and
what
we're
doing.
O
Yeah
I
mean
to
follow
on
with
that.
I
think
the
certified
ones
are
even
different
because
I
just
recently
went
through
the
exercise
of
merging
them
all
into
one
page
for
certify.
This
was
sort
of
an
exercise
that
was
presented
by
directors
and
products.
Saying
hey
give
it
a
try,
see
how
it
looks
any
feedback
on
that's
great.
I
think
we're
all
as
product
teams
trying
to
understand
the
best
way.
O
I
really
like
gabe
had
an
idea
of
how
to
sort
of
break
the
pages
down
and
then
have
them
roll
up
into
one,
and
I
think
that's
a
fantastic.
You
know
approach,
but
I
think
the
idea
is
we're
trying
to
really
work
hard
to
make
them
consumable
and
useful.
Because
again,
if
we're
graded
on
this,
I
actually
want
to
understand
what
the
who
the
consumer
is
and
what
they're
getting
from
it,
because
it's
very
hard
to
cater
it
to
the
right
audience
right
now.
O
It
feels
like
it's
basically
they're
being
updated
for
executives,
sometimes
because
they're,
the
ones
that
seem
to
care
the
most
about
them
being
updated.
But
I'd
like
to
change
that,
I
mean
I'd
like
them
to
be
a
working
living
document
that
helps
more
than
just
them.
So
if
there's
any
suggestions
there
on
the
single
page,
I
think
there's
a
feedback
issue
out
there.
I
can
try
to
find.
F
Yeah-
and
this
can
be
something
that
we
talk
about
at
the
group
level
as
well
more
around,
especially
the
jobs
to
be
done.
That
alexis
was
mentioning
if
we
achieve
those
things
and
we
have
goals
and
we're
hitting
them
and
we're
talking
about
whether
we're
really
serving
our
customers
we'll
do
right
by
our
users
and
we'll
feel
more
empowered
as
a
team
to
serve
them,
and
hopefully,
we'll
also
be
able
with
each
direction
page
and
with
aligning
as
a
team
and
going
after
it.
We'll
also
be
able
to
get
more
investment
as
a
team.
F
In
terms
of
like
how
we
could
add
to
our
team
grow
teams,
split
teams
like
keep
getting.
D
Last
last
talking
point
on
this:
we
can
skip
point
four
if
you
have
stuff
facing
at
it
please,
but
do
you
even
look
at
them
regularly?
If
not,
why
not?
That's
one
of
my
questions
and
right,
your
first.
K
I
admit
I
don't
look
at
them
regularly
and
and
kind
of
as
an
engineer,
I'm
looking
more
at
the
issue
level.
You
know
I'm
taking
direction
from
you
guys
and
with
issues
and
efforts,
you're,
creating
and
all
that
kind
of
stuff,
but
I
do
look
at
it
once
a
while.
I
think
it's
good
to
have
the
overall
direction
of
you.
E
Yeah,
similar
from
my
sides,
like
I,
have
this
kind
of
waning
trust
in
the
handbook
as
a
single
source
of
truth
on
the
plan
side
and
I've
been
trying
to
address
that
on
the
engineering
side
by
like
taking
the
attitude
that
something
isn't
like.
It
hasn't
happened
until
it's
in
the
handbook.
So
we
might
discuss
like
we're
going
to
change
how
we
apply
weights
every
month,
but,
like
the
discussion
might
happen.
But
if
it's
not
in
our
team
page,
it
hasn't
happened
like
the
decision
has
been
made
and
it's
it's
not
the
target.
E
The
direction
pages
like
specifically
it's
just
more
general
in
the
handbook,
like
we've,
changed
a
lot.
The
last
few
weeks,
I've
seen
a
few
different
roadmaps
for
where
we're
going
with
work
items
and
how
we're
going
to
do
it,
and
I
think
that,
like
I
don't
feel
like,
I
can
really
put
a
lot
of
faith
in
any
of
them
until
they're
in
black
and
white,
in
the
handbook
right,
like
somebody's
taken,
the
time
to
update
that
handbook
page
and
and
and
made
a
commitment
to
it
yeah.
E
So
there
are
parts
of
the
direction
pages
that
if
I
look
at
they
seem
to
me
out
of
date.
I
don't
want
to
pick
up
particular
ones,
but
like
no,
you
know
we're
saying
things
like
about.
You
know
service
desk
that
we're
not
going
to
do
like
at
least
not
according
to
how
we
see
a
service
desk,
for
example.
E
That's
just
one
example
like,
but
if
I
look
at
the
service
test
direction
page,
I
think
there's
information
there
about
private
comments
and
stuff
I
mean
we
haven't
worked
on
that
in
a
long
time
it's
been
community
driven
solely
so
yeah.
It's
it's
a
general
attitude
that
I
take
towards
the
handbook.
It's
a
feeling
that
I
have
towards
it.
I
feel
like
maybe
a
couple
years
ago.
It
was
very
much
more
like
if
it's
not
in
the
handbook.
It's
not
final
and
it'd
be
nice
to
get
back
to
that,
it's
great.
F
Feedback
yeah,
I
feel
like
a
broken
record,
but,
like
I
agree
on
that
as
well,
there
are
certain
parts
of
product
planning
not
in
the
portfolio
management
category.
We
should
talk
through,
but
the
plan
stage
calls,
I
don't
think,
makes
sense.
I
think
it
should
be
at
the
group
level
for
those
because
they're
really
team
focused,
but
I
think
it's
a
really
good
call-out
that
we
need
to
have
that
regular
review
and
at
least
codifying
things
in
the
handbook
awareness
where
needed.
E
F
The
only
thing
that
doesn't
change
is
that
there'll
be
more
change
as
well
with
the
roadmap
so
like.
If
this
s,
the
single
source
of
truth
is
gonna
have
to
be
the
issues
for
what
we're
actually
doing
in
the
epics,
but
agreed
especially
process
or
team
changes.
Things
like
that
should
be
in
the
handbook.
D
Cool
thanks
y'all.
I
really
appreciate
the
input
and
feedback
and
discussion
there.
I
think
we
have
a
couple
of
minutes
if
we
wanted
to
go
to
kashal.
If
you
want
to
facilitate
that
discussion
or
if
you
want
to
make
an
async,
your
call.
N
Yeah,
so
I'll
just
leave
a
link
to
slack
discussion
there,
so
this
was
brought
up
earlier
today,
where
in
the
roadmap,
when
you
expand
any
parent
epic,
which
has
for
the
children
epics,
then
the
the
top
level
epics
on
the
roadmap
follow
the
sort
order
that
user
has
selected,
be
it
start
or
due
date,
but
the
children
epics
do
not,
and
instead
they
show
up
in
the
same
order
as
they
were
added
in
the
epic
page,
where
you
add
related
issues
and
effects
to
an
existing
epic.
N
F
I'll
follow
up
in
slack,
but
I
would
say
test
our
embedded
roadmap
view
on
epics
make
sure
they're
doing
the
same
thing.
F
I'm
sure
you
already
checked
that,
but
I
do
think
it
should
go
by
date
and
if
we
already
have
manual
sorting
on
the
embedded
roadmap,
maybe
we
could
look
at
using
that
the
sort
order
sorting,
but
ideally
where
we're
going,
is
that
with
any
of
these
views,
you'd
be
able
to
set
a
sort
order
or
a
type
of
sorting
at
the
source
and
give
people
more
flexibility
in
how
they
use
that,
and
it
would
be
consistent
across
gitlab.
F
In
the
meantime,
though,
let's
make
sure
it's
consistent.
So
if
it
is
just
by
date,
let's
make
sure
both
views
are
doing
the
same
thing
and
we
know
we'll
just
leave
it
as
date
and
we
can
add
on
the
manual
later.
K
I'll
just
say
that
that
I
think
the
the
sorting
should
be
that
should
be
consistent
with
the
parent
sorting.
So
if
the
parent
sorting
is
manual,
then
the
children
should
be
should
adhere
to
the
manual
as
well.
You
don't
want
to
be
when
I
look
at
something
I
want
to
know
that
the
same
rules
apply
to
the
information
I'm
looking
at,
so
I
think
it's
a
usability.
D
Cool,
I
think
we
are
at
time,
sorry
that
we
didn't
have
social
stuff,
but
there's
a
lot
of
things
to
discuss
today
and
I
appreciate
everyone
being
open
and
transparent
and
honest
and
empathetic
with
each
other
and
kind.
It
was
cool
to
see
and
have
some
great
discussions
around
process,
changes
and
other
things
today.
So
thank
you
all
very
much.