►
From YouTube: Plan | Weekly Team Meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
I
do
indeed
so
next
week,
12th
of
july,
we'll
welcome
stannislav
to
plan
product
planning.
As
a
back-end
engineer,
you're
encouraged,
I
would
say,
to
reach
out
to
him.
Welcome
him
in
advance.
I've
shared
his
linkedin
since
we'll
be
publishing
this
video.
I
will
not
share
his
surname
or
linkedin
on
the
video.
B
I'm
not
sure
exactly
why,
but
if
you
saw
that
that
was
an
easter
egg,
so
yeah
please
reach
out
to
stanislav,
and
you
know,
welcome
him
and
tell
him
how
much
we're
looking
forward
to
having
him
on
the
team
on
the
same
day
next
week,
because
monday
is
in
fact,
family
and
friends
day,
we'll
welcome
nicholas
doolar
as
well
as
senior
backend,
engineer
and
you're,
of
course,
welcome
to
reach
out
to
nicholas
on
slack
and
organize
a
coffee
chat,
etc.
B
C
Okay,
gabe,
I
feel
like
I
have
too
many
things
on
the
agenda,
so
if
somebody
wants
to
add
other
things
go
for
it.
I
was
just
curious
to
get
a
quick
pulse
check
of
where
we're
at
with
work
items
and
thinking
about
what
we
feel
like.
We
should
prioritize
for
15.3
in
terms
of
the
that
whole
sort
of
work
stream,
so
love
some
input
from
y'all.
A
As
far
as
work
items,
I
was
going
to
write
a
follow-up
question
more
so
than
an
answer
to
yours
in
that
to
get
it
to
or
to
turn
it
on
for
all
of
gitlab.com.
A
Again
we
have
an
epic
which
I'll
link
to
in
here,
but
I
think
in
order
to
get
to
that
point
where
we're
turning
it
on
for
gitlab.com.
C
Yes,
I
think
it's.
The
more
context
is
the
most
important
thing
so
I'll
follow
up
with.
I
was
looking
at
that
issue
the
other
day.
I
can
go
track
down,
I'm
just
more
curious.
I
know
we
have
assignees
that
are
sort
of
in
progress.
We
have
a
weight,
widget,
that's
in
progress.
We
have
the
labels
widget,
that's
in
progress
like
after
those.
What
what
do
we
want
to
focus
on?
C
Do
we
want
to
focus
on
like
milestones
and
iterations,
or
do
we
want
to
focus
on
discussions
and
system
notes
and
that
sort
of
thing,
so
we
can
start
trying
to
get
parity
with
epics,
because
I
also
know
that
alexander's
started
the
work
to
make
move
issues
to
project
namespace,
and
I
have
an
open
issue
that
I
need
to
go
see
with
some
questions
about
migrating
epic
issues
and
or
migrating
epics
to
work
items
that
whole
transition
plan.
C
D
So
for
requirements,
the
two
things
that
come
to
mind
are
system
notes,
because
we
do
have
those
requirements
around
tracking
execution
and
change
of
basically,
the
verified
status,
at
least
in
my
mind,
that
would
be
system
notes,
and
then
I
know
discussions
are
also
a
huge
ask
for
requirements.
D
I
think
for
epics
right,
if
I
think,
of
the
epics
transition
that
work
is
more
like
in
the
product
planning
arena
in
that
I
think
we
need
to
build
out
the
depth
of
the
hierarchy
past
one
level
right
once
we
get
this
initial
like
version
out,
but
I
think
for
your
team
gave
discussions
and
system
notes.
I
think
advanced
requirements
more
and
like
build
a
path
for
issues.
C
Okay,
cool,
then,
how
do
we
feel
about
spinning
up
a
spike
for
that?
And
we
won't
obviously
get
all
of
it
done
in
one
milestone,
because
I
think
it's
a
lot,
but
at
least
starting
the
architecture
plan.
For
that,
because
I
know
we
want
to
start
using
subscriptions
instead
of
the
real
time
changes
endpoint
for
some
of
that
stuff
and
some
other
things.
So
I
will
schedule
that
out
and
maybe
we
can
get
started
on
it
in
153,
while
we'll
clean
up
some
of
the
stuff.
That's
already
in
progress.
E
A
little
note
on
this,
we
won't
be
able
to
reuse
the
existing
components
and
applications
for
discussions
from
issue
and
merge
requests
they're
very
tightly
bound
to
view
x.
It
was
the
case
with
design
management
too.
We
needed
to
build
our
own
design
management,
discussion,
design
management,
node
components.
E
F
C
Sorry,
go
ahead,
donald
no
go
ahead.
I
was
going
to
say:
do
you
think
we
should
go
ahead
and
do
some
of
the
design
work
or
I
guess
ux,
research
or
whatever
we
want
to
do
around
resolvability,
because
I
know
that
exists
in
the
design
notes.
It's
already
in
the
issues
api
or
in
the
notes,
api
for
things
to
be
resolvable,
and
that's
like
the
big
ask
too,
that
we've
gotten
lots
of
feedback
on
for
notes
within.
E
G
What
about
so
another
request
that
has
come
up
is
how
to
see
what's
new,
and
I
think,
there's
been
maybe
some
exploration
of
this
in
the
past.
I
I
would
say
that
should
be
a
fairly
high
like
if
we're
going
to
rebuild
something
like
we
should.
We
should
try
to
do
that.
Is
that
sort
of
the
same
in
terms
of
implementation,
or
is
that
does
that
require
a
little
bit
more
like
up
front
to
make
sure
that
it's
built
in
a
way
that
we
could
actually
somehow
show
like
you've?
A
Before,
yes,
I
think
we
should
think
through
that.
I
also
think
we
should
rethink
our
deep
linking
strategy
or
at
least
think
through
how
we
want
to
handle
deep,
linking
notes
right
now.
I
think
one
of
the
biggest
performance
or
front
end
at
least
performance
or
perception.
Perceptive
perception
performance
aspects
are
around.
A
Perceive
there
you
go.
Thank
you
is
around
deep
linking
a
note
that
has
a
lot
of
discussions
within
it,
so
yeah.
If
we
can
rethink
through
that
now.
I
think
that
was
the
opportunity
time
to
do
that.
F
D
Was
gonna
say
if
we're
talking
about
new
features
that
we
want
another
one
that
comes
up
often
especially
when
we're
thinking
about
okrs
and
epics
that
are
used
by
like
projects
is
the
concept
of
like
a
note.
That
is
a
check-in
right
like
a
status
update
blurb.
D
That's
meant
to
be
a
summary
of
what's
happening
with
that
item,
a
little
bit
different
than
a
comment,
but
it's
still
kind
of
like
a
text
thing
that
you
leave.
Maybe
that's
a
completely
separate
feature.
Maybe
it's
the
same
thing.
I
don't
know
if
you've,
given
that
some
thought
gabe
or
not.
C
Yeah
this
is
very
similar
to
what
respond
has
built
or
is
building
for
the
timeline
widget,
where
you
can
either.
If
you
go
to
the
timeline
tab,
you
can
add
a
new
event
to
the
timeline
tab,
which
is
the
same
thing
as
a
check
in
or
you
can
add
a
comment
and
then
you
can
click
a
button
on
any
existing
comment
to
add
it
to
the
timeline
with.
C
I
think
the
time
stamp
of
that
comment
as
well,
which
is
the
same
thing
as
a
check-in
in
my
in
my
mind,
because
it
will
show
you
everything
it's
it's
almost
like
a
a
fancier
system.
Note
that
gets
consolidated
in
this
one
little
view
up
in
the
top,
so
I
think
we
should
see
if
we
can
try
to
use
that
and
make
it
more.
Generic
there's
also
open
issues
for
things
like
pinning
comments
at
the
top
and
all
that
stuff,
and
I
think
these
are
great
things
to
explore
during
the
spike.
C
So
that
way
we
can
do
proper,
ux
kind
of
exploration.
Even
if
we're
not
gonna
build
some
stuff
for
a
while,
and
then
we
can
do
proper
engineering
kind
of
refinement
on
how
we
wanna
tackle
this
stuff.
C
D
Basically,
you
have
the
option
to
on
any
okr,
write
a
status,
update
and
say
like
where
each
person
that
owns
that
okr
every
month
has
to
go
check
in
on
the
item
and
just
write
a
quick
sentence
or
two
about
what's
going
on
with
it,
and
you
write
that
in
right
and
you
click
check
in
and
sort
of
like
a
comment,
except
that
is
shown
in
various
reports
along
the
way,
an
ally,
as
this
is
the
latest
status
from
the
person
that
is
working
on
this
item.
So
it's
not
the
description
right.
A
Yeah
so
making
sure
my
question
makes
sense,
but
I
think
it
does
because
you
answered,
but
so
yeah
discussions
seem
like
there's
still
a
few
questions
or
changes
we
want
to
make
to
the
way
they're
shown
or
from
the
way
they're
shown
in
legacy
issues
system
notes
seem
a
little
bit
more
known
around
how
we
want
to
display
those,
because
I
think
that'll
be
a
little
bit
more
similar
to
legacy
issues.
A
C
I
just
said
yes
and
if
we
can
get
system
notes
for
existing
widgets
using
graphql
subscriptions
and
like,
however,
we
want
to
build
front
end
and
think
through
just
like
the
api.
For
that,
I
think
it's
great.
I
know
there
was
some
open
discussions
about
if
we
want
to
like
nest
events
with
which
within
widgets
or
if
we
want
to
have
like
a
separate
events
attribute
in
the
graphql
api.
C
So
that's
all
good
stuff
to
just
like
hash
out
and
I
think
that'll
be
fine.
B
B
C
C
Discussion-
I
was
just
sharing
this
because
I
know
a
couple
weeks
ago:
you're
talking
about
how
to
surface
permissions
to
the
front
end
so
that
you
know
what
you
can
do
all
that
kind
of
good
stuff
and
yourself
across
google
docs
apis,
and
they
have
an
interesting
like
capabilities,
object
that
lists
all
the
things
that
the
the
user
can
do
based
on
their
current
permissions.
So
just
sharing
that,
if
you
wanted
some
inspiration
from
what
a
competitor
has
done,
it's
pretty
good.
C
We
don't
really
discuss
that,
so
it's
real
the
next
one
on
five,
I
got
some
rough
feedback
from
a
customer
last
week
and
it
wasn't
about
plans
specifically
that
it
was
more
general,
like
a
feeling
that
git
lab
has,
over
time,
continued
to
decline
in
our
ability
to
interact
successfully
and
respond
to
requests
from
the
water
community.
Specifically
noting
how
our
backlog
is
like
out
of
control
across
the
entire
product,
and
it
sort
of
is
like
there's
thousands
of
issues
and
lots
of
them
are
super
old.
C
We
just
can't
do
it
yet,
but
there's
also
a
slew
of
issues
that
never
get
looked
at
or
touched,
and
I
think
this
has
made
certain
people
like
just
stop
interacting
with
us
entirely,
which
is
a
really
not
good
thing,
because
if
people
no
longer
want
to
open
issues
and
report
things
or
provide
feedback,
it's
sort
of
it
will
hurt
us
in
the
long
run,
and
I
think
supporting
the
wider
community
is
like
one
of
the
most
important
things
that
we
should
keep
top
of
mind.
And
so
I'm
curious.
C
If
there's
any
ideas
around
some
sort
of
process,
we
can
do
like
once
a
quarter
or
something
where
everyone
on
the
team
sort
of
helps
out
clearing
out,
duplicates
or
won't
do
or
like
no
op
bugs
or
things
that
have
already
been
resolved
just
so
that
we
can
start
to
like
cut
down
on
the
number
of
issues
that
we
have
within
the
plan
stage.
I
think
right
now.
C
Last
time
we
checked
somewhere
in
the
five
to
six
thousand
range,
and
I
I
would
suspect
that
a
large
percentage
of
those
are
all
things
that
are
duplicates
things
that
just
we
won't
do
or
things
that
are
no
longer
relevant
because
we
fix
them.
So
does
anyone
have
suggestions
on
this
or
open
to
exploring
doing
this
as
a
team.
H
I've
got
I've
got
one
tangential
suggestion,
which
is
that
community
folks
raising
issues,
customers
and
so
on
can't
put
labels
on
the
issues,
and
it's
not
at
all
unprecedented
for
me
to
find
a
you
know,
have
a
bug
reported
a
ticket
find
an
issue
for
it.
I
H
C
A
C
But,
but
more
or
less
like
when
you
let
somebody
who
is
not
a
project
member
update
metadata
on
issues,
then
it
gets
really
messy
because
they
do
things
that
they
shouldn't
do
and
it
messes
up
workflows.
So
those
are
like
complaints
on
both
sides,
but
I
get
what
you're
saying.
I
also
know
that
I
believe
there's
a
triage
policy
that
and
where
quality
engineering
looks
at
all
the
issues,
with
no
team
label
on
them
and
assigns
one
or
takes
the
best
guess,
but
I'm
not
sure
if
that's
still
working
or
not.
B
Yeah,
I
like
the
idea
generally
and,
as
I
said
here
like
it,
worked
for
security
issues,
but
we
had
like
maybe
an
order
of
magnitude
fewer.
We
did
a
triage
exercise
just
as
back
in
the
m,
so
we
kind
of
grouped
them
together
under
like
similar
root,
causes
and
closed
eye,
duplicates
closed
out
old
ones
or
things
we
just
weren't
going
to
fix
and
we
got
the
thing
down
pretty
well
in
the
end
to
a
small
number
of
security
issues.
B
But,
like
I
don't
know,
if
it's
as
easy
to
do
that
for
bugs,
because
I
think
on
the
like.
Certainly
on
the
product
planning
side,
I
think
there
are
90
or
100
bugs
project
management
like
540,
open
bugs
something
like
that
and
like
when
I
was
trying
to
figure
out
like
what
percentage
would
be
closed
by
the
work
items
work.
There
was
no
way.
I
was
going
to
look
through
all
those,
so
I
just
took
a
sample
of
10
and
yeah.
B
Even
then,
like
it's
quite
a
lot
like,
if
you
did
this
cross
functional
prioritization
thing
where,
like
I
tried
to
reorder,
just
an
order
of
priority
are
tech
debt
issues
and
it
was
you
can
hold
it
by
10
in
your
head
and
then
after
that,
like
it's
very
hard
to
kind
of
sort
things
in
any
kind
of
order
or
keep
any
context
in
your
head.
So
yeah,
I
don't
know
how
to
approach
is
basically
what
I'm
saying,
but
I
suppose,
if
we
could,
like
you
know,
do
one
tenth
every
month
like
or
something.
B
Maybe
that
would
be
the
way
to
do
it.
I
don't
even
then
it
feels
like
a
pretty
incredible
exercise,
though,
but
I
totally
get
what
you're
saying
like,
certainly
like
looking
through
a
lot
of
the
issues,
a
lot
of
them
like
seem
like
they
could
be
duplicates
or
will
just
be
closed
or
could
be
closed
in
the
process
of
doing
work,
items.
A
Yeah,
I
think
I
think
that's
the
big
one
is
the
ones
that
will
be
closed
short
term
by
the
move
over
to
work
items
I
went
through.
We
did
as
part
of
the
prior
prioritization
work
or
the
next
prioritization
work.
I
looked
through
the
maintenance
issues
for
project
management
there
was
about.
A
It
was
like
a
little
bit
over
a
hundred,
and
I
think
that
at
least
I
don't
know
70
percent
maybe
or
either
stuff
that
we
could
close
or
stuff
that's
going
to
be
taken
care
of
as
part
of
feature
work,
and
then
I
was
looking
through
other
their
issues
because
I
think
we
went
through
recently
and
re-classified
our
issues
or
moved
them
to
either
type
bugs
or
type
maintenance
or
type
feature,
and
just
looking
at
project
management.
A
There
are
sixteen
hundred
yeah
over
sixteen
hundred
feature
issues.
A
I
wonder
if
that's
accurate,
I
feel
like
that's
like
some
of
those
have
to
be
bugs,
and
I
don't
know
how
we
would
go
around
go
around
handling
those
like
should
we
should.
We
include
those
like
if
we
go
through
and
try
to
clear
out
the
duplicate
bugs.
A
B
Yeah,
but
I
want
to
I'm
blanking
right
now
right,
but
I
I
know
for
a
fact
that
I've
seen
in
the
product
planning
backlog
like
two
feature
requests
from
from
the
community
and
they've
literally
asked
for
diametrically
opposite
things.
You
know
one
has
been
like.
Can
we
can
you
build
this
on
and
the
other
one
is
like?
Please,
can
you
stop
building
this
on?
Can
you
take
these
away
and
it's
like
so
maybe
you
know
we
need
to
be
like
more
kind
of
liberal
with
the
close
button.
B
I
don't
know
for
a
lot
of
features
like
maybe
we
just
have
the
won't
fix
label
and
to
take
a
take,
an
opinionated
stance
on
some
more
things.
D
Yeah,
I
think
we
should
do
a
backlog
cleanup,
so
thanks
for
bringing
this
up
gabe,
I
also
my
brain
immediately
goes
to
like.
Oh,
this
probably
is
a
problem
for
our
customers
too.
I
know
it's
been
a
problem
for
me
in
the
past
at
other
companies.
It's
not
just
to
get
left
thing,
sometimes
caused
by
me.
Sometimes
I
inherited
just
like
a
really
old
backlog
and
I've
had
to
go
through
this
given
a
much
smaller
scale,
but
there
are
sort
of
like
rules.
D
You
can
use
that
I
have
in
the
past,
and
I
do
wonder
if
we
can
build
this
and
to
get
that
triage
in
the
future
right,
like
the
things
that
I've
done
have
been
like
anything
older
than
x.
I
actually
just
like
have
closed
in
the
past.
It's
been
like
pretty
generous
right
and
again
it's
different
because
it
wasn't
a
public
backlog,
but
I've
done
things
where
it's
like
anything
older
in
the
year.
I
just
like
have
closed
it
anything.
D
I
also
had
moderated
a
forum
feedback
forum
before
that
was
public
and
anything
that
had
less
than
x
votes.
I
closed
right
and
just
had
like
a
it
wasn't
automated.
It
was
like
me.
I
had
a
blurb
that
I
just
left
that
I
was
like
okay.
This
is
older
than
x
and
didn't
receive
an
abstraction,
so
it's
being
closed
and
people
are
generally
understanding
of
that.
Surprisingly,
I
didn't
get
that
many
complaints
and
then
that
that's
the
easy
stuff
from
there
it
gets
much
harder.
D
You
have
to
like
search
by
keywords
and
try
to
cluster
finding
duplicates
is
very
difficult
for
a
human.
So
that's
where
I'm
like.
That's
where
the
automation
stuff
would
be
helpful,
because
that
that's
the
hard
part,
but
we
should
definitely
try
and
come
up
with
systems,
and
once
we
do,
we
should
write
issues
for
that
and
try
to
get
them
codified
so
that
a
pm
doesn't
have
to
do
that
again,
like
I
don't
want
to
do
this
more
than
a
couple
of
times.
C
Yeah
and
donald,
I
think
we
were-
are
experimenting
with
ml
to
do
auto,
labeling
based
on
I'm,
not
sure
what
we're
looking
at
in
terms
of
training,
algorithms.
There
I
can
ask
tanooki
stan,
I
think
that's
the
slack
channel,
maybe
how
it
works,
but
I
think
it's
just
for
applying
like
group
and
stage
and
feature
labels
and
stuff
like
that,
not
deciding
whether
or
not
something
should
be
open
or
closed.
I've
also
know
that
at
one
point
we
did
add
something
to
triage.
C
It
would
automatically
close
old
stale
issues
and
then
that
also
offended
the
water
community,
because
these
are
still
real
things,
they're
still
real,
like
bugs
that
you
haven't
fixed
yet
so
don't
do
that.
I
think
once
we
do
go
through
and
get
everything
cleaned
up,
it'll
be
easier
to
stay.
C
On
top
of,
like
that's,
how
I
felt
about
my
own
to-do's
right
like
because
once
you
you
get
it
down
to
a
page
or
two,
then
it's
easy
to
see
the
new
things
and
triage
them
quickly
and
then
I
also
dropped
a
link
to
vs
codes,
closing
guidelines,
and
so
I
think,
maybe
for
this.
What
I'll
do
is
I'll
open
up
a
discussion
issues
next
step
in
the
plan
project
issue
and
the
plan
project
to
nail
down
what
we
want
to
do
async,
so
we
can
kind
of
take
this
async.
C
I
don't
think
we're
going
to
come
up
with
a
perfect
thing,
but
I'd
like
to
continue
the
discussion.
If
that's
cool
with
everyone.
C
Next,
there's
discussion
going
on
in
the
retro
about
story
splitting,
and
so
I
linked
to
some
an
article
that
I
shared
there
as
well,
and
then,
when
I
was
looking
at
some
of
the
issues
that
I
had
authored
like
the
assignees
issue,
I
kind
of
just
noticed
that,
like
the
first
eight
or
so
acceptance
criteria
on
the
issue
could
have
been
split
out
into
smaller.
C
Discrete
issues
like
we
could
use
tasks
for
this
in
the
future,
or
we
could
just
like
break
them
out
and
issues
and
then
they
can
be
assigned
to
an
epic
like
they
are
today.
But
I'm
curious
like
if
this
is
would
would
have
been
helpful
for
engineering
if
there
were
like
more
discreet
things
like,
for
example,
let
me
share
my
screen
record
because
I'll
just
kind
of
show
you
what
I
was
talking
about,
like
search
for
an
assignee,
could
be
a
separate
issue.
C
Auto
paginate
could
be
a
separate
issue
being
able
to
add
an
assignee
could
be
separate
one
removing
one
a
separate
one,
so
these
all
could
be
there's
like
independent,
small,
discrete
steps
of
this
bigger
issue,
and
I'm
curious
if
that
would
have
been
helpful
than
engineering
if
I
had
broken
those
down
into
issues
ahead
of
time
and
if
so
also,
what's
like
a
good
signal
early
on
that,
we
should
break
something
down
further
if
that
makes
sense.
So
I'd
just
like
to
have
a
quick
discussion
on
this
sink.
That's
cool.
E
Absolutely
it
makes
sense
and
I'm
happy
to
see
that
you
split
it
on
stories.
The
way
I
split
the
mars
on
the
front
end,
it's
like.
Basically,
a
few
of
them
are
repeating
my
amores
and
the
way
I
absolutely
the
issue
when
making
merch
requests
so
yeah.
It
would
be
much
easier
also
to
track
progress
for
both
product
and
engineering
managers,
because
currently
it's
like
just
sleeping
through
the
next
milestone,
it
will
be
sleeping
15
to
2,
because
back
end
is
not
ready.
E
There
are
a
few
things
that
we
need
and
it
seems
that
we
are
doing
nothing
while
we
are
doing
a
steady
progress
and
splitting
these
stories
would
give
you
a
nice
picture,
and
it
would
also
be
more.
I
don't
know,
satisfied
look
for
engineers
because
you
can
see.
Okay
like
there
is
a
progress
made
there
and
also
we
could
estimate
it
better
in
terms
of
weight,
because
right
now
assange
is
estimated
as
weight
five
and
it
makes
no
sense.
The
weight
is
much
higher
and
it's
super
hard
to
estimate
when
the
issue
is
that
big?
E
Okay?
How
do
we
define?
When
do
we
need
to
split?
I
think
early
discussion
with
engineers
would
probably
give
you
some
picture
on
that,
because
normally
we
are
aware
about.
If
something
is
big
enough
or
small
enough,
for
example,
weight,
it
would
be
much
harder
to
split
on
stories.
This
way,
maybe
like
two
to
three
stories
only
so
I
think
the
only
way
is
just
individual
discussion
on
every
single
issue
that
we
plan
for
the
milestone.
I
Well:
okay,
I
agree
that,
like
splitting
helps
with
the
progress,
but
I'm
of
the
opinion,
actually
that
we
need
both
like
this
acceptance
criteria,
but
also
every
every
like
checkbox
here
would
point
to
an
issue
then
using
this
issue
itself
as
an
as
a
entry
point,
if
you
will
seeing
the
summary
what
what
worked
well
for
us
in
workspaces
was
making
use
a
lot
of
the
epics
actually
and
like
that
that
face
splitting.
If
you
will
war
embassies
or
steps
or
something
like
that,
and
then
you
can
easily
see
like
I'm
working
on
this
feature.
I
But
these
are
the
issues
that
I
can
specifically
work
on
or
like
we
can.
We
can
split
them
in
parallel,
like
I
I
didn't
find,
I
don't
find
it
very
easy
to
use
the
related
issues
if,
if
that
makes
sense
right,
if,
like
you,
have
an
issue
with
a
lot
of
related
stuff
to
it,
a
lot
of
the
time.
Those
related
issues
don't
actually
mean
sub
tasks
or
tasks
of
that
specific
issue.
But
there
is
a
lot
of
noise
in
related
issues
and
for
for
scope
for
like
breaking
down
scope.
I
It
feels
like
epics
works,
much
better
in
that
sense
that
you
can
have
some
issues
with
some
sub
epics,
which
really
encapsulates
the
work
that
needs
to
be
done
for
this
specific
item
so
yeah.
I
do
feel
that
we
need
both
like
at
least
within
one
place
and
then
splitting
down
as
to
when
to
split
the
down
and
I'd
really
like
the
way
that
you
have
broken
it
down.
I'd
really
pass
it
on
to
engineers.
Whoever
is
picking
it
up.
I
They
may
do
two
tasks
in
one
issue
or
every
single
task
in
in
a
separate
issue
or
mr
depending
how
that
works
out
on
the
on
the
technical
side,
but
maybe
in
this
sense
having
something
like.
Please
split
it
down
into
specific
issues,
or
some
note
like
that
for
the
engineers
I
don't
know
how
to
to
handle
that
message
to
let
everyone
know
that.
Well,
we
do
encourage
you
to
create
a
specific
issue
for
for
every
task
that
you
work
on,
or
a
specific
mri
and
link
it
here.
I
It
doesn't
have
to
be
well
yeah,
I
don't
know
if
it
for
some
engineers
it
feels
as
an
overhead
to
have
to
create
the
issue
and
the
corresponding
combine
right,
because
it
basically
does
the
same
thing.
But
I
don't
think
it's
a
big
deal
if
we
just
use
the
issue
as
a
placeholder,
if
you
will
have
the
description
of
the
issue,
be
the
same
task
and
link
to
the
mr,
whatever
just
to
make
it
easier
for
the
pm's
and
what
who
else
works
on
on
the
issue
level
to
track
to
track
progress.
F
D
I
Yes,
so
an
issue
of
feeding
into
a
milestone,
it
doesn't
mean
that
that
issue
will
be
a
deliverable.
Does
that
make
sense
because
sometimes
like
to
achieve
something?
You
need
to
do
a
lot
of
back-end
work
for
or
running,
or
what
I
mean
is
like
some
yeah
prerequisite
work
before
you
can
actually
have
a
deliverable,
if
that
makes
sense,.
C
Yeah,
I
think
it
could
be
a
deliverable
insofar
as
like
we
can
turn
a
feature
flag
on
and
test
it
somewhere
and
see
something.
I
think
this
sort
of
goes
to
donald's.
Next,
like
we
wouldn't
release
it,
though,
like
if
we
were
to
split
the
assignees
like
into
those
sort
of
things,
we
probably
wouldn't
release
it
until
most,
all
of
them
were
done,
but
we
could
still
see
the
progress
and
and
like
test
it,
and
I
think
that
goes
like
donald's
point.
C
It
technically
is
not
providing
customer
value,
if
you
like,
do
it
in
those
small
little
like
chunks,
but
it
is
like,
if
you
split
the
stories
around,
that
it
does
like
it,
works
towards
that
value,
and
it's
customer
facing
sort
of
right
like
I
think
that
most
they
will
all
provide
customer
value,
even
if
we
don't
enable
the
feature
flag
by
default.
Yet.
I
I
I
Perhaps,
to
make
it
something
more,
whereas
a
progress
for
these
types
of
issues
is
maybe
record
a
dmo
or
present
a
demo
of
what's
going
on.
What's
the
progress
again,
maybe
not
so
valuable
to
the
pms,
but
maybe
more
valuable
to
the
all
of
the
back-end
engineers
or
front-end
engineers
that
that
are
within
the
team,
so
they
know
what's
the
progress
of
the
thing
and
so
on.
So
maybe
that
can
be
one
point
within
this
acceptance
criteria
things
when
you
break
down
things:
okay,.
C
I
think
c
we
can
talk
about
next
time
or
to
get
async.
It's
just
now
that
we're
having
lots
of
folks
from
different
functions
that
are
kind
of
picking
and
maintaining
their
list
of
things
that
need
to
be
prioritized
from
like
the
issue.
Types
it'd
be
great
if
we
had
like
sort
of
a
process
that
used
boards
and
stuff
like
that,
so
we
didn't
have
to
like
talk
about
these
like
import.
These
giant
lists
into
comments.
C
Once
we
have
embeddable
queries
it'll
be
sweet,
so
we
can
do
that,
but
I
think
it
would
be
great
if
we
could
use
boards
and
stuff.
So
we
can
talk
about
that.
I
would
love
if
y'all
are
interested
to
take
a
few
minutes
to
let
me
demo
a
competitor
product
to
you
just
because
I
think
it's
interesting
or
we
could
just
talk
about
metrics
in
the
last
few
minutes,
y'all
have
preference.
C
All
right
cool,
so
today
I'm
going
to
show
you
fiverry.
I
think
this
is
sort
of
like
a
timely
thing
to
demo,
because
it
kind
of
gets
at
the
heart
of
some
of
what
we're
doing
with
work
items
and
sort
of
some
of
these
like
longer
term
flexibility,
things,
but
also
shipping
the
same
defaults.
So
when
you
onboard
into
fiverr
it
asks
you
what
you
want
to
use
the
proc
for,
and
in
this
case
I
selected
product
management,
so
it
pre-filled.
C
Basically
my
workspace
with
a
bunch
of
different.
You
can
kind
of
think
of
these
as
different
projects
or
whatnot.
What
have
you
one
with
like
a
product
portfolio,
one
with
strategy,
customer
feedback,
road
mapping
and
sort
of
people,
but
at
the
heart
of
these?
Each
of
these
little
things
are
all
of
the
same.
Under
the
hood
and
it's
sort
of
where
you
have
different
views
that
you
can
create.
You
can
create
a
table,
a
board,
a
list,
a
timeline,
a
calendar
report
or
feed
documents
and
whiteboards
or
different
things.
C
So
you
can
kind
of
group
them
into
folders,
and
these
are
sort
of
just
like
if
you
think
about
each
of
these
being
different
views,
they're
just
different
views
to
slice
different,
what
I
would
call
work
items
and
you'll
kind
of
each
of
these
work
items,
or
I
don't
know
what
they
call
them
in
vibrate.
What
the
core
thing
is
is
driven
by
these
like
kind
of
customizable
tables,
so
in
the
product
portfolio,
for
example,
we're
looking
at
a
portfolio
of
products
and
there's
a
product
called
cheering.ai.
C
You
can
name
it
whatever
you
want
and
it's
got
sort
of
these
different
widgets
on
it
like
state
description
objectives,
insights
and
this
little
arrow
means
that
it's
actually
a
relationship
to
something
else,
and
so,
if
we
think
about
down
here,
we
also
have
strategy.
This
is
where
the
okrs
live.
I'm
pretty
sure
this
is
the
objective.
You
can
look
in
this
data
table
and
see
that
this
is
actually
related
to
that
objective.
C
Now,
because
they,
through
this,
like
kind
of
neat
little
relationship
manager,
thing,
you
can
specify
relationships
to
other
data
tables
or
to
other
fields
or
like
workspaces.
So
here
you
could
say
a
product
has
one
relationship
to
many
objectives,
feature
milestone,
conversation
insights,
and
so
they
sort
of
treat
all
these
just
different
things.
As
sort
of
these
relationships,
I
can
add
a
many-to-many
relationship
which
would
sort
of
be
like
linked
issues
or
linked
items.
C
Right
now,
I
can
also
add
up
many
to
one
which
would
represent
sort
of
our
current
epic
to
child
relationship.
Epic
issue
relationship,
but
from
this
like
I
can,
I
can
connect
this
one.
This
products
table
to
all
my
other
things
like
whether
that's
objectives,
insights,
customer
conversations,
which
is
another
thing
where
down
here.
They
have
customer
feedback
and
they
log
each
specific
call
that
they
have
or
piece
of
feedback.
C
It
gets
mapped
to
a
specific
product
via
the
relationships
here
where,
if
you're
gonna
look
at
that,
you
can
kind
of
see
how
it
has
the
relationships
managed,
and
this
is
all
like
the
same
thing
under
the
hood
and
it's
used
for
all
sorts
of
things
from
product
playing
to
project
management,
to
like
issue
tracking
to
crm
related
features,
because
it's
sort
of
just
this,
like
configurable
data
table
that
maps
to
other
data
tables,
and
then
you
can
also
add
new
kind
of
custom
fields
where
these
are
sort
of
just
dumb
fields
like
multi-select
or
single,
select
or
number.
C
You'd
also
have
the
ability
to
do
formula
driven
fields
where
you
kind
of
as
long
as
the
fields
that
go
into
formula
are
numeric,
then
you
can
use
this,
and
this
would
be
like
something
we
could
use
in
the
future
for
like
prioritization
frameworks
and
models
and
that
sort
of
stuff.
But
it's
really
kind
of
interesting
how
you
they
have
the
same
sort
of
model
to
tie
all
these
different
spaces.
C
Together
and
all
these
different
things
and
it's
all
sort
of
powered
by
the
same
mechanisms
under
the
hood
and
the
same
sort
of
data
model,
and
so
I
think
when
I
think
about
work
items
in
the
future,
we
want
to
be
able
to
support
custom
fields
right
and
things
like
data
tables.
C
We
want
to
be
able
to
support
objectives
and
key
results,
and
we
and
all
these
sorts
of
different
things-
and
this
is
sort
of
a
pretty
good
example
of
a
product-
that's
farther
along
with
some
of
these
things,
but
it
also
doesn't
feel
like
it's
too
overwhelming
right
because
it
ships
by
default
with
all
these
things,
pre-configured
for
the
use
cases
and
that's
something
we
could
do
too
within
gitlab,
where
you
have
different
methodologies
that
you
might
use
we
can
you
basically
select
what
you
want
to
use
a
workspace
or
a
namespace
for,
and
we
kind
of
pre-configure
that
to
be
tailored
to
that
kind
of
use
case.
I
Yeah,
I
think
this
maps
fairly
well
with
our
work
items
model,
but
it
doesn't
map
to
me
at
least
to
my
understanding
to
the
projects
model
and
one
thing
that
I'll
note
without
knowing
how
it
does
it.
What
it
does
is,
is
there
any
way
to
set
different
permission
levels
on
product
portfolio
strategy,
customer
feedback?
Is
it
because,
if
not,
it
doesn't
really
map
to
the
project's
model
per
se
right
yep?
So
this
is
where
it
does
like
it'll.
I
It
feels
the
same
as
what
we
want
to
do
as
work
items
where
you'll
have
different
types,
so
portfolio,
product
strategy
and
whatnot
will
be
a
type
of
work
item,
and
then
you
can
create
relationships
between
those
which
we
just
discussed,
but
it
doesn't
again.
This
doesn't
feel
to
model
the
name
spacing
per
se.
C
Yeah,
I
can
do
that
as
a
next
step,
so
what
they
do
is
sort
of
interesting
too,
how
they
have
their
some
of
their.
I
think
git
lab
might
be
in
here
yeah,
so
they
have
a
project
emerge,
request,
branch
and
a
member,
and
you
can
it
basically
is
the
default
flow
that
you
can
import.
I
think
you
can
sync
so
I'll.
Do
that
and
I'll
invite
some
folks
it
can
get
really
complicated
too
in
terms
of
the
relationships.
So
that's
something
that
I
think
would
be
fun
to
explore
a
little
bit.
C
In
terms
of
like
your
question
about
permissions,
I
think
the
way
that
it
works
here
is
that
each
of
these
you
get
added
to
a
workspace
and
you
can
switch
workspaces,
so
maybe,
like
a
workspace,
is
more
like
a
project
or
a
namespace
in
gitlab,
but
within
that
you're
right.
These
are
sort
of
like
different
types
and
have
different
fields
on
them,
and
then
each
of
these
gets
shared
with.
C
Basically,
you
can
define
whether
they're
creators,
editors
contributors,
viewers
or
no
access-
and
this
is
like,
I
guess,
applicable
to
every
single
row
in
in
the
product
portfolio
area,
and
I
think
eventually
we
want
to
get
to
the
point
where
we
provide
more
granular
permissions
on
each
of
these
things
so
that
you
can
kind
of
share
them
across
like
workspaces.
C
We
can
figure
out
how
we're
going
to
do
that,
but
there
are
interesting
permission
controls
here
that
you
can
do
and
we
can
kind
of
look
into
this
a
little
bit
further.
But
I
think
once
you
get
added
to
the
space
and
let's
see
here,
if
we
add
people,
I
can
invite
people's
members
admins
or
guests,
and
so
I
think
this
is
sort
of
the
same
thing
as
being
a
project.
Member
yeah.
I
It
invites
people
to
the
entire
workspace
right.
It
doesn't
invite
people
only
to
strategy,
for
instance,
so
I
want
some
people
to
only
have
access
to
the
list
of
strategies,
because
so
why
it
will
not
work
in
my
opinion
is
because
they
will
not
have
access
to
view
the
relationships
that
you
create
within
within
the
strategy,
so
they
need
to
be.
I
They
need
to
have
some
permissions
within
the
entire
workspace.
I
would
imagine
I
I
don't
know.
Maybe
I'm
wrong
or
not,
or
maybe
there
is
some
way
to
do
that
and
then
the
next
question
is
you've
shown
the
workspaces.
I
wonder
if
they
can
do
relationships
between
items
in
different
workspaces
right
now,.
C
I
don't
know
I'll
look
into
that
to
see
if
you
can,
because
I
only
have
one
workspace
set
up
that
has
anything
in
it.
I
think
in
terms
of
how
it
works
with
the
access
and
permissions
like.
If,
if
I
invite
somebody,
let's
say
a
person
as
if
we
go
back
to
the
people,
I
invite
people,
I
I
make
them
a
member
right,
so
they
looks
like
this
can
can
be
out
of
space
with
any
role
from
viewer
to
creator.
So
this
adds
them
as
member.
C
But
then
I
can
also
go
up
here
and
it
like
strategy,
for
example,
if
I
mark
this
as
no
access
right
to
every
everyone
to
all
the
members,
they
can't
see
strategy
and
then
they
won't
see
strategy
like
as
a
relationship
and
things
like
customer
feedback
or
a
product
portfolio
and
similar
to
what
asana
does
like
if
you
have
access
to
one
project
through
the
custom
field,
but
not
the
other
project
and
the
issue
gets
shared
into
that
other
project.
C
I
Yeah,
I
I
I
know
yeah.
It
will
be
interesting
to
take
a
look,
how
granular
that
goes
it
does
it
go
for
like
every
single
roll
there,
or
does
it
go
only
for
a
type
of
these
rows
like
product
and
and
strategy,
and
so
on
because,
like
it
does
add
a
lot
of
overhead
when
you
need
to
compute
permissions
as
granular
as
every
single
record,
every
single
row
right
yeah,
then
they
go
like
when
when
you
have
when
you
need
to
handle,
we
talked
about
customers
having
millions
of
issues.
C
Yeah
we
just
had
an
issue
with
gitlab.com
because
one
of
our
larger
customers
unshared
one
of
their
groups
with,
I
think,
seven
thousand
people
in
it
and
it
took
gitlab.com
down
because
I
had
to
recompute
the
cash
permissions
for
that
many
people
at
once.
So
it's
a
it's
a
real
like
challenge,
it's
something
that
we
should
think
about
too
and
and
slow
roll
any
changes
on.
So.
C
Okay,
also,
I
think
we're
at
time,
but
I
did
leave
under
anything
else.
Metrics
highlight
update
for
this
month,
just
a
quick
snapshot
of
where
we're
at
growth
is
fine
and
great.
B
Super
quick
question
from
somebody
who's,
not
in
the
like
project
management
team.
We've
often
said
that
milestones.
Echolabs
should
be
milestones
and
not
a
time
range
so
like
what,
when,
when,
in
your
view,
do
you
think
we
would
be
able
to
switch
to
using
iteration
cadences
like
instead
of
having
and
have
milestones
as
a
milestone.
C
I
think
you
can
use
iteration
cadences
now,
if
you
want,
I
mean
in
production,
you
can
set
up
your
own
cadence
for
product
planning
and
you
can
do
your
own
scheduling
or
you
could,
and
that's
probably
what
I
would
recommend
doing
if
you
want
to
kind
of
have
discrete
things
where
you
don't
have
to
do
a
bunch
of
additional
filtering
or
you
could
share
the
one
with
that
we
have
going
on
with
plan,
but
I
think
that
you
can
use
them
now.
C
I
B
Yeah,
if
the
iteration
could
be
like
the
exact
same
length
as
what
we
now
call
a
milestone,
and
I
think
as
well
like
it's
already
pretty
hard,
I
find
it
already
pretty
hard
to
plan
each
milestone
just
using
the
tools
we
have
at
the
minute
so,
like
I
think,
it'd
be
good
to
go
through
and
do
an
audit
of
what
do
we
actually
need
to
do
what
we
do
currently
and
is
everything
there
in
iteration
cadences
like?
Can
we
use
them
on
boards?
B
The
way
we
need
to
easily
all
this
kind
of
stuff
and
then,
if
so,
then
maybe
we
should
consider
it.
C
I
also
think
that
if
we
do
like
a
month,
long
iterations
are
long,
but
whether
you
do
a
week
or
two
weeks
if
we
can
get
in
the
habit
of
planning
that
way
and
then
just
assigning
the
milestones
after
the
fact
for
everything
that's
going
to
make
it
into
the
milestone
like.
I
would
be
cool
with
that
right,
because
that's
it's
basically
what
we're
doing
and
that
way
we're
not
signaling
a
bunch
of
stuff
ahead
of
time
that
may
or
may
not
be
done
already,
and
it's
sort
of
like
we're.
A
C
Longer
time
period,
so
that's
why,
if,
if
we
like,
I
can
I
can
wing
the
like
product
stuff
that
you
have
to
do
for
kickoffs
in
in
a
way,
but
it
sort
of
gets
the
point
like
if
I
just
sort
of
don't
do
anything
for
a
release
or
two
or
announce
anything,
and
then
we
switch
to
planning
iterations,
then
the
things
that
are
like
almost
done
or
I
know,
will
be
done
in
the
next
iteration
before
the
end
of
the
milestone,
like
you,
almost,
are
like
pulling
it
forward.
C
I
I
If
you
can
pull
into
into
milestone
or
releases
stuff
from
from
basically
closed
iterations
already,
that
is
the
ideal
way
to
do
it
right.
You
already
know
that
you
are
releasing
that
stuff.
You
just
need
to
announce
it
basically
yeah.
So
then
there
is
no
risk
of
planning
and
not
delivering
it.
Just
you're
just
pulling
it
and
stuff.