►
From YouTube: Work Items Sync 2021-11-02
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
C
Okay,
so
kristen
has
the
first
agenda
item
I'll
verbalize
it
because
she's
got
a
migraine,
didn't
sleep
well
last
night,
but
we've
been
working
through
like
sequencing
things
and
I'll
kind
of
share
my
screen
and
talk
through
this
real
quick
just
so
that
everyone
can
follow
along.
We
originally
we're
gonna
go
with
feature
first,
but
the
more
we've
kind
of
gotten
into
it.
C
There's
a
lot
we
would
have
to
build
before
we
could
release
it
and
it
would
be
able
to
add
any
customer
value
more
or
less
we'd
sort
of.
If
we
wanted
feature
to
have
parody
with
what
is
in
the
group,
epic,
we
would
have
to
have
parent
child
relationships
on
issues.
We'd
have
to
have
the
work
item
type
stuff.
C
We
would
have
to
have
descriptions
the
new
ui,
the
new
relationships,
widget
that
alexis
and
kristin
are
working
on
and
a
bunch
of
other
things,
and
so
we
kind
of
looked
down
like
if
we
were
to
take
the
route
of
getting
a
feature
as
fast
as
possible
that,
like
everything
else,
there's
still
like
a
ton
of
stuff
that
we
would
have
to
do
so.
C
We
sort
of
went
together
back
to
the
drawing
board
thought
about
like
how
can
we
get
to
where
we
want
to
go
like
the
ideal
vision
in
a
way
that
allows
us
to
provide
more
customer
value
sooner
if
that
makes
sense,
and
so
we
kind
of
played
around
with
this
idea
of
like
what,
if
we
kind
of
switch
things
up,
so
we
built
a
better
foundation
incrementally,
but
also
allowed
customers
to
kind
of
address.
C
Some
some
known
use
cases
that
customers
have
with
our
current
sort
of
like
structure
like
there's
no
tasks
under
issues
and
also
how
can
we
do
it
in
a
way
that
will
less
be
more
incremental
and
iterative
with
the
new
work
item
view.
So
our
our
goals,
I
guess
long
term-
aren't
changing.
We
want
to
have
a
new
work
item,
detail
view
we
want
to
move
to
work
items
we
want
to
eventually
release
feature,
but
just
sort
of
like
shuffling
around
how
we
get
there
a
little
bit.
C
One
of
those
would
be
you
know
we
need
to
show
issue
type
icons
and
lists
and
boards,
so
we
can
go
ahead
and
do
that
with
issue.
An
incident
now,
if
we
are
going
to
let
people
eventually
change
the
name
of
a
work
item
type.
We
need
a
settings
view
where
they
can
do
that.
So
I
think
these
are
things
that
also
will
allow
us
to
showcase
some
of
the
some
of
the
plans
that
we
have
where
we're
going.
C
We
when
we
reviewed
github's
new
project
view
it's
actually
not
as
far
along
as
we
thought
it
would
be,
but
they
did
a
nice
job
in
some
of
their
settings,
areas
of
showcasing
like
sort
of
what's
coming
and
providing
sort
of
a
teaser,
so
kind
of
doing
that,
and
then
the
goal
would
be
able
to
edit
the
issue
work
item
type
name
so,
instead
of
it
just
being
issue
just
changing
the
name
to
something
else,
is
sort
of
the
working
idea
there
and
then,
instead
of
starting
with
feature
and
then
going
to
issue
starting
by
adding
a
new
sort
of
dimension
to
the
relation
between
mrs
and
issues
and
adding
a
the
ability
for
mr
to
be
a
child
or
just
related.
C
But
the
idea
is
like
kind
of
starting
with
parenting
that
way,
and
then
after
kind
of
iterate
a
little
bit
and
we
would
put
like
the
new
parenting
widget
into
the
legacy
issue
ui
for
a
time
period
so
that
we
could
iterate
on
that.
But
then
the
next
step
would
be
creating
tasks
from
that
kind
of
relationship,
widget
and
then
iterating
on
the
work
item.
C
The
new
work
item
detail
view
within
the
context
of
a
task
and
the
task
would
be
opened
on
an
issue
in
a
modal
sort
of
which
is
a
pattern
that
we
want
to
have
anyway.
C
So
you
don't
lose
context
and
then
we
can
slowly
refactor
each
thing
like
assign
these
labels
due
dates
like
all
those
different
widgets
and
release
them
into
the
new
workout
detail
view
under
the
task
work
item
type
and
then
once
we
get
to
sort
of
like
relative
parity
with
what
exists
now
on
epics
chris,
the
product
planning
team
would
implement
the
feature
right
in
the
project
level,
but
it
would
probably
by
this
point,
be
better
than
what
is
the
group
level
epic
and
then,
when
we're
ready,
we
would
deprecate
the
legacy
issue
ui
with
the
new
work
item
ui
and
then
do
the
whole
thing
where
we,
like
you
know,
get
issues
at
the
group
level
migrate,
epics
to
work
items
which
we
can
still
sort
all
that
stuff
out.
C
So
that's
what
we
were
thinking
we
haven't
talked
to
the
engineers
about
yet
because
we
just
sort
of
got
a
line
on
this
iteration
path
for
work
items
and
I'd
love
to
get
initial
reactions,
feedback
things
that
will
or
won't
work
about
our
assumptions
that
we've
made
as
product
people
that
aren't
engineers
and
also
ux
challenges
or
if
there's
concerns
from
a
product
design.
Standpoint.
C
Yeah,
it's
a
it's
a
it's
a
bit
of
a
divergence,
but
what
this
also
sort
of
kind
of
would
provide
is
if
we
have
the
new
sort
of
relationships,
widget
that
we're
building
out
incrementally
and
the
legacy
issue
ui.
We
can
also,
then
solve
the
problem
of
relating
requirements
to
issues
without
having
to
go
deal
with
the
legacy
way
of
doing
all
that
stuff.
C
I
mean
we
could
still
do
it
that
way,
but
I
think
this
will
provide
a
cleaner,
more
scalable
way
for
us
to
relate
all
the
things
eventually
and
it
also
can
sort
of
be
like
an
independent
work
stream.
Apart
from
so
many
other
things,
and
the
other
benefit
is
that
this
sort
of
lets
us
do
things
incrementally
and
iteratively,
while
delivering
value
and
having
stopping
points
if
we
need
to
right.
C
So
if
we're
blocked
from
releasing
feature
until
we
get
all
these
things
done,
and
we
get
interrupted,
let's
say
to
prioritize
some
reliability
thing
or
a
temporary
headcount
reset
or
whatever
we're
not
sort
of
like
have
all
this
inventory.
That's
jammed
up
that
we
can't
deliver
to
the
customer
at
all.
E
F
There's
some
collapse,
detail
sections
you
have
to
open
under
options.
So
those.
D
D
A
There
does
seem
to
be
a
request
cycle
when
you
click
that
so
maybe
that's
it
like.
Maybe
maybe
I
wish
I
could
jump
into
your
developer,
console
there
and
see
what's
going
on.
F
D
F
So
my
just
like
initial
gut
reaction-
and
I
definitely
have
to
think
through
it
more
and
read
through
kind
of
the
the
way
this
is
broken
down,
but
I
think
that
sounds
good.
I
think
it
kind
of
hopefully
gives
us
some,
maybe
a
little
bit
more
iterative
way
to
ship
some
stuff
rather
than
trying
to
ship
like
somewhat
broken
parts
of
the
feature
feature.
I
guess
my
like
initial
concern
or
thing
that
I
would
want
to
ask
about
is-
and
it's
probably
for
donald
is
like
with
the
future.
F
F
My
you
know
feel
is
that
we
might
lose
some
of
that
ability
to
break
this
to
break
it
like
front
end
and
back
end
with
this.
So
I
guess
I'm
just
curious
like,
and
I
again
I
haven't
really
thought
through
it
at
all.
I'm
just
kind
of
going
off
the
cuff
here,
but
is
that
am
I
wrong
and
and
like
do
you
still
feel
good
about
kind
of
like
moving
the
front
end
forward?
If
we
don't
have
the
you
know,
the
back
and
support
keeping
up
with
front
end
on
this.
C
Yeah,
so
what
we
can
do,
we
can
keep.
We
can
keep
iterating
on
the
new
detail
view.
However,
we
want
the
the
idea
is
that
as
soon
as
we
do
have
back-end
support,
we
release
task
sort
of
is
the
thing
that
within
the
relationship
widget,
so
the
only
thing
that
we're
posing
at
least
right
now
that
we
would
add
into
the
legacy
issue.
Detail
view
is
the
new
parenting
widget
and
I
think
kristen
would
be
able
to
speak
this
more
than
me.
C
But
the
idea
is
to
also
move
the
the
showing
the
epic
parenting
and
that
for
the
time
being,
until
those
get
converted
work
items,
but
once
you
create
a
task
within
that
parenting,
widget
or
whatever
you
could
open
that
task
in
a
modal,
the
modal
would
be
the
new
work
out
of
detail
view.
C
So
it's
almost
like
just
think
about
opening
a
task
within
an
issue
in
a
modal,
and
that
would
be
the
detail
view.
So
we
can
keep
moving
forward
with
it
and
it's
not
any
like
throw
right
work.
If
that
makes
sense.
F
E
C
Yeah
I'll
kind
of
show
you,
when
we
kind
of
broke
this
down,
it
would
eventually
be
its
own
release
post,
but
not
right
away,
because
there's
this
is
a
problem
is
like
if
we
can't
have
any
release
posts
until
we
have
feature
it's
going
to
be
a
really
long
time
until
there's
really
supposed
right
and
so
kristin
sort
of
took
what
I
put
that
was
not
entirely
coherent
but
direct,
directionally,
correct
and
broke
it
down
into
sort
of
these
different
phases
and
the
rocket
pretty
much
means
that
we
can
have
a
release
post
item
for
each
of
these
things
right
and
so,
for
example,
a
view,
a
static
hierarchy
of
work
items
with
a
teaser.
C
So
this
is
like
work
item
settings
somewhere.
The
view
that
we
need
to
have
if
we
ever
want
to
allow
the
type
names
to
be
configured
eventually
statuses
will
live
there
or
other
sort
of
like
you
know,
work
item
settings
we
want
to
have
the
ability
to
edit
or
change
the
issue,
work
item
type
name
to
whatever
you
want.
C
That
could
be
another
release
post
and
those
were
the
two
that
she
was
thinking
about
doing
another
one
we
could
do
is
showing
issue
type
icons
and
listed
boards,
which
you
know
we
directly
could
already
do
now.
C
Another
release
post
item
would
be
showing
issues
on
the
roadmap
view
which
we
need
to
do
if
we
want
to
convert
basically
migrate,
fx
issues
at
some
point
anyway,
so
these
sort
of
can
go
off
anywhere,
they're,
not
really
blocked
by
anything,
and
then
this
is
sort
of
like
being
able
to
show
related
children
in
mars
and
branches.
C
This
could
be
a
release
posting
of
itself
right
because
right
now
we
would
if
we
did
this
we'd
sort
of
replace
what
is
the
current
mr
list
with
the
new
parenting
widget
that
shows
the
child
in
mars
in
it,
and
so
then
we
could
do
things
like
being
able
to
add
and
remove
the
signees.
C
I
don't
know
if
we
would
do
a
release
for
this,
and
we
could
probably
do
this
later.
Actually,
it
wouldn't
come
until
we
actually
were
able
to
then
create
a
task
from
an
issue
which
would
be
like
a
trial
task.
C
Then
view
the
task
detail
within
a
legacy
issue,
like
view
view
test
detail,
let's
say
we
have
title,
and
then
we
get
the
description
down
on
the
new
work
detail
view
like
front
and
back
end
or
whatever.
We
could
release
that
as
a
work
as
a
release
boost
item
you
know,
add
and
remove
labels
on
tasks
that
could
be
released,
post
item
because,
like
since
task
doesn't
exist,
and
there
is
no
no
feature
there
or
no
functionality.
This
sort
of
gives
us
a
way
to
incrementally
refactor
these
different
widgets
into
the
architecture.
C
We
want
and
then
eventually
like
add
that
value
into
our
customer
skin
then
add
remove
labels
on
tasks,
and
then
we
could
get
into
things
like
weight
on
tasks
right,
if
you
add
a
weight
on
tasks,
it
could
roll
up
into
your
parent
issue,
and
this
is
where,
like
some
of
these,
we
might
have
to
replace
one
of
the
widgets
like
the
weight
widget,
for
example,
in
the
legacy
issue
ui
with
the
new
one
that
we
were
building.
C
That's
also
in
work
items,
but
it
sort
of
lets
us
have
all
these
different
releases
and
then
at
some
point
I
think
it
was
down
here
sort
of
like
add
any
other
missing,
widgets
or
apps
that
we
need
to
have
parity
with
the
current
issue,
at
which
point
we
would
have
a
release
post
item,
saying:
hey
we're
actually.
C
Turning
on
this
new
workout
detail
view
for
everyone's
replus,
replacing
the
legacy
issue
ui,
because
we're
sort
of
able
to
like
build
this,
then
out
in
the
open
incrementally
under
the
guise
of
a
task,
instead
of
a
full
on
hey
switch
between
the
legacy
view
and
the
new
view,
and
you
have
the
option
to
switch
between
the
two:
we
can
sort
of
actually
build
it
all
out
incrementally
and
also
have
it
add
value
to
customers
that
doesn't
exist
today.
C
B
Them
I
don't
like
my
understanding
is
that
then
migrating
epics
would
kind
of
fit
after
the
task
hierarchy.
Prototype.
C
Right,
correct
yeah,
because
once
you
have
the
task
hierarchy,
prototype-
and
we
incrementally
add
some
of
these
things
that
exist
on
epics,
we
could
release
the
feature
at
the
project
level.
So
then
you
have
feature
issue
task
and
then
nmr,
right
or
sort
of
be
the
levels.
C
B
Okay,
so
then
there
is
a
chunk
of
work
to
do
with
the
epic
migration
yeah.
I
guess
the
requirements
would
be
even
before
we
start
on
this
thing
right,
because
I
think
we're
on
our
way
to
do
that.
I
just
I'm
trying
to
understand
how,
because
there
was
there
there
is
some
technical
depth
and
some
work
in
progress
in
this,
so
I'm
just
trying
to
understand
how
we
fit
whatever
we
have
in
flight
within
this
change.
Basically,.
C
We
could
do
that
earlier.
I
mean
it's
sort
of
the
same
idea
where
right
here
we
have
show
related
children
in
our
branches
in
mars
and
branches
like
if
we
wanted
to
and
this
something
chris
and
alexis
can
sort
out
like
a
requirement.
C
I
don't
know
if
mark
might
be
able
to
speak
this,
but
if
a
requirement
would
be
technically
a
parent
or
a
child
of
a
issue
or
just
related
mark.
What
would
you
say
to
that.
H
Because,
since
we're
not
we're
sort
of
getting
rid
of
the
idea
of
like
issue
hierarchy
with
like
epics,
not
that
epics
completely
go
away,
but
the
concept
is
that
some
issues
are
higher
level
and
break
out
work
below
them,
in
which
case
you
might
be
creating
numerous
requirements
to
satisfy
that
issue.
On
the
flip
side,
if
you're
implementing
a
requirement,
you
may
then
have
an
issue
below
it
for
implementation
purposes.
So
I
don't
know
if
it's
a
straight
parent
child.
C
Okay,
so
we
could
just
you
know
within
the
little
related
widget
you
know
the
idea
would
be.
You
could
have
you
sort
of
have
a
couple
different
relationships.
You
have
related,
you
have
parent
child
and
then
you
have
blocked
blocking
and
blocked,
and
blocking
is
meant
to
denote,
like
you're
blocked
by
another
work
item.
C
It's
outside
of
your
hierarchy,
your
roadmap,
roll
up
or
whatever,
and
so
those
are
like
the
kind
of
three
things
that
we
want
to
support
and
all
all
the
plan
objects,
and
even
mrs
and
other
things
should
be
able
to
conform
to
that.
Theoretically,
so
we
could
work
in
the
requirement
view
into
that
as
well
and
kind
of
only
have
requirements
there
or
if
you
wanted
to
go
ahead
and
move
forward
with
requirements
with
the
legacy.
C
G
But
that's
okay.
I
mean.
B
Because,
like
I,
I
think
john
is
saying
we
have
some
code
that
we'd
want
to
get
rid
of
some
technical
debts
and
some
things
that
like
to
keep
these
requirements
and
seeing
in
both
places.
So
we
want
to
at
least
finish
that
I
don't
think
we
started
anything
on
epics
yet
so
that
can
wait
up
until
we
have
the
hierarchy.
Widget
and
whatnot.
C
But
yeah
thanks
yeah,
I
try
to
find
an
issue
that
has
the
mr
widget
on
it,
but
the
idea
would
be
to
sort
of
right
now,
there's
a
couple
different
places
where
you
can
like.
Okay,
here's
some
related,
mrs
and
this
is
sort
of
the
problem
of
not
having
like
child
in
mars-
is
that
these
are
all
related,
but
they're
not
implementing
this
feature
right.
So.
B
Yeah,
but
that's
that's
that's
when
the
high,
where
yeah
I
see
what
you
say,
I
mean
for
the
I
think,
for
the
requirements
they
will
be
in
the
relates
to
box,
and
if
we
can
add
here
the
the
icon,
where
somehow
to
differentiate
different
types
of
related
things,
then
we
can
work
with
that
up
until
we
add
the
hierarchies
and
on
all
that
stuff
and
then
that
will
kind
of
make
it
easier
to
to
relate
things
in
a
more
hierarchical
structure.
C
Yeah,
the
the
working
idea
with
the
mr
stuff
is
get
them
treated
as
either
child
or
related
like
this,
and
then,
instead
of
having
this
separate
button
down
here
and
the
same
with
branches,
because
branches
are
completely
unsilent,
just
like
spit
out
somewhere
down
there.
But
this
little
create
merge,
request
button
or
create
a
branch
button,
it's
sort
of
like
when,
in
the
future
ideal
like
parenting,
relationship,
widget
type
thing
you
can
select
what
you
want
to
create.
C
A
branch
emerge,
requests
specified,
so
a
child
or
parent
or
child
or
just
related.
You
know
sort
of
thing
and
then
this
could
also
move
in
and
be
part
of
that
same
experience
instead
of
being
separate
unless
we
want
to
keep-
and
this
is
up
to
alexis
and
kristin
how
they
want
to
handle
visualizing
and
interacting
with
all
the
related
things
but
yeah.
This
is
a
proposal
and
if
y'all
want
to
push
back
on
it,
please
do
like
I
started
in
this
one
where
we
talked
about
sequencing
and
rolling
things
out.
C
A
Want
to
push
back
on
it,
but
I
just
do
want
to
point
out
that
most
of
the
benefit
of
pushing
forward
with
some
kind
of
parent-child
relationship
on
the
back
end
is
to
solve
the
problem
of
traversing
up
and
down
a
hierarchy
in
the
same
table
right.
So
if
we
go
with
the
option
of
working
on
that
parent-child
relationships
with
mrs
that's
a
separate
table,
it
won't
necessarily
get
us
any
closer
to
solving
the
problems
that
we
have
to
solve
in
the
back
end.
A
That
will
make
it
easier
to
implement
parent-child
relationships
for
work
items
for
work
items.
It's
a
kind
of
the
ultimate
problem
on
the
back
end
is
that
that
it's
a
hierarchy
of
end
depth-
and
you
may
be
at
any
point
in
that
hierarchy
right,
so
you
have
to
recursively
step
up
and
down
the
hierarchy
depending
on
you
know
until
you
reach
the
top
or
the
bottom,
that's
the
kind
of
tricky
part.
A
The
only
way
I
could
think
around
this
would
be
to
like
have
a
wrapping
work
item
around
existing
mr's,
but
that's
something
really
messy
like
because
what
do
you
linking
to
from
the
relationship
widget
from
the
parent
child
widget
you're,
not
linking
the
mr
you're
linking
something
else
which
you
know
joins
it
to
an
mr?
It's
just
it's
it
doesn't.
It
doesn't
feel
great.
It's
an
iterative
step,
the
rest
of
it's
brilliant.
A
I
think
that
the
task
I
get
where
you're
coming
from
and
that
you
might
want
an
mr
to
satisfy
a
task
to
satisfy
an
issue,
but
I
think
that
task
being
so
simple
that
it
would
probably
just
start
out
with
the
title
is
possibly
a
good
place
to
start
because
you're
going
to
have
to
solve
the
parent-child
relationship
for
one
layer.
First,
I
guess,
unless
you
want
multi-layered
tasks
to
begin
with,
but
let's
say
and
the
same
as
with
features,
it
was
only
going
to
have
one
layer
of
children
underneath
that
might
be.
C
Yeah
we
we
don't
have
to
start
with.
Mrs.
I
was
just
sort
of
proposing
that,
because
we
we
have
to
solve
that
problem
eventually
like
sooner
rather
than
later,
because
none
of
like
a
lot
of
things
aren't
right,
like
our
value
streaming.
Analytics
reports
aren't
right
because
we're
pulling
in
data
from
related,
mrs
that
don't
have
anything
to
do
with
implementing
it
from
a
compliance
standpoint.
C
A
lot
of
our
customers
are
complaining
because
there's
not
a
formal,
hard
link
between
an
mri
and
an
issue
in
terms
of
like
this
implements
that
and
it's
not
just
related
and
things
get
implemented
by
accident.
There's
no
way
to
tell
so
like
that's
that's
this
thing
that
we
will
have
to
that
problem
to
solve.
I
don't
know
how
we
solve
it
other
than
adding
another
dimension,
the
relationship
between
mrs
and
issues.
C
It's
the
same
thing
for
requirements
too
you're
going
to
want
to
know
for
if
an
mr
satisfies,
like
is
implementing
a
requirement
right.
So
that
way
you
can
see
and
like
eventually
do
what
like.
What's
all
the
code
changes
that
went
into
the
specific
requirement,
not
just
what
was
related
so,
but
that's
like
one
bucket
of
problems.
C
We
also
can
just
defer
that
and
just
start
with
tasks.
If
that's,
if
that's
what
you're
saying
is
probably
the
better
solution
so
that
we
can
do
that
recursively
kind
of
looking
up
and
down
a
hierarchy
within
the
same
table,
it's
sort
of
the
I
would
be
fine
with
either
I'm
sure
chris
would
be
fine
with
either
as
well.
So
just
knowing
that
we
will
have
to
solve
that
problem.
For
mrs
at
some
point
sooner.
A
Yeah,
it's
honestly
like
it's
kind
of
an
executive
decision.
I
mean
all.
The
only
point
I
want
to
make
is
that
I
think
on
the
back
end
doing
mrs
first
won't
necessarily
get
us
any
further
along
the
line
of
implementing
parent
child
for
work
items.
That's
not
to
say
it's
not
the
more
valuable
thing
to
do,
and
we
should
just
do
it
anyway.
I
just
want
to
make
sure
that
you
know
you
have
the
information
as
far
as
I
can
say,
of
course,
I'll
defer
to
alexandria.
B
Yeah
we
need
to
discuss
it
obviously,
but
I
I
think
and
not
going
to
technical,
but
I
think
there
is
a
discussion
had
where
we
want
to
move
this
kind
of
parent
child
hierarchy
even
now
out
of
the,
for
instance,
the
name
spaces
table
such
so
that,
just
when
you
have
to
compute
it,
you
don't
have
to
load
a
lot
of
the
other
attributes.
B
So
maybe
going
with
a
separate
table
is
actually
something
we
can
see
and
then
you
you
can
have
like
the
relationship
between
the
ids
and
the
type
of
the
item
and
solve
it
that
way,
but
yeah,
that's
something
to
be
thought
of,
so
perhaps
it
doesn't
have
to
be
within
the
same
table
which
and
what
I'm
trying
to
say
and
then
basically
that
doesn't
mean
that
we
need
to
migrate
all
of
the
on
mars
into
the
issues
table,
which
I
think
is
what
you
were
suggesting
right.
B
I
mean
which
I
think
you
kind
of
pointed
as
a
as
the
problem
with
the
mars
but
yeah.
That's
that's
something
to
be
discussed.
I'm
probably,
I
guess,
starting
simpler,
because
we
don't
have
the
hierarchy
between
different
types
anyway,
starting
with
some,
with
with
probably
building
the
hierarchy
between
the
issue
and
between
the
tasks
so
that
you
can
have
basically
two
simple
different
types
and
thinking
about
the
problem
in
that
constraint.
B
Kind
of
will
help
doing
a
magic
request
is
a
bit
more
difficult
because
it
involves
a
lot
more
changes
and
then
that's
the
object
that
is
used
in
a
lot
of
places.
So
it
is
a
bit
more
difficult
with
that,
but
yeah
open
up
for
discussion.
It
does
make
sense
anyway,.
C
Technical
implementation
for
this,
so
that
all
the
technical
decisions
are
there.
I
think
I
honestly,
in
this
case
I
defer
to
y'all
to
the
engineers
for
what
makes
the
most
sense
to
allow
us
to
be
as
iterative
as
possible.
So
we
can.
We
can
take
that
this
conversation
async.
B
Yeah,
I
can
start
the
thread
in
the
technical
discussion
of
the
work
items
in
regard
to
parenting.
We
have
something
there,
but
maybe
we'll
open
a
new
one
in
regards
to
to
related
items
and
parenting
and
so
on
and
see
what
we
can
do
with
the
magic
requests
task
and
and
what
not
an
issue
and
see
how
we
can
work
through
that.
So
maybe
it's
not
as
complex
and
complicated
as
I'm
thinking
but
yeah
I'll.
Take
that
as
an
action
item
here.
C
I
I
think
it
makes
sense,
it
seems
more
iterative
and,
like
you
said
it's,
we
can
get
some
value
to
people
in
people's
hands
sooner.
That
makes
sense
to
me.
You
can
also
get
feedback
sooner.
I
So
I'm
fine
with
that
and
I
think
I'll
have
to
like
continue
follow
up
with
y'all
on
some
of
the
use
cases
around
like
linking
mrs
things
like
that
and
expectations
there,
or
we
might
want
to
do
some
really
quick
research
just
to
better
understand
that.
Do
we
have
an
issue
for
that
game
like
some
of
those
more
granular
things
or.
C
I
C
There's
some
floating
around
I'll
try
to
round
them
up,
but
it's
I
hear
it
all
the
time
on
customer
calls
being
like
hey
like
they're,
not
really
related,
they're,
they're
related
loosely,
but
not
tightly
so
I'll,
collect
some
resources
and
pass
them
your
way.
I
Yeah,
it
looks
like
y'all
are
kind
of
creating
those
work
items
because
we
want
to
call
them
that
in
the
spreadsheet,
so
if
it
doesn't
get
into
get
lab
and
then
like
any
existing
issues
from
users
around
that,
like
just
attach
that
that's
kind
of
research
for
me
to
look
over
when
I'm
creating
this.
If
that
makes
sense,.
C
It
gets
us
the
long-term
goal
with
the
least
amount
of
technical
debt,
not
trivial,
but
I
really
want
to
rely
and
defer
to
the
engineers
and
the
product
design
on
what
that
means
like
how
to
show
something,
that's
usable,
how
to
do
it
in
a
way
that
makes
sense
and
even
swapping
things
around
like
not
doing,
merge
requests
first,
because
it's
more
complex,
I'm
totally
fine
with
that,
like
it's,
this
sort
of
like
lets
us
tackle
things
in
separate
chunks.
If
we
want
to
so.
A
Delivery
timeline.
You
have
there
lots
of
rockets
all
quickly
following
one
following
another
yeah.
It
looks
great.
C
Yeah,
I
I
had
a
lot
more
dependencies
mapped
in
that
was
noisy,
but
I
had
all
sorts
of
like
other
items
that
had
a
little
link
to
them,
which
means
there
are
things
we
would
have
to
do
in
order
to
get
to
the
rockets,
but
we
were
trying
to
think
about
how.
How
can
we
talk
it
about
it
in
a
way
that
our
customers
would
understand?
C
I
think
kenny,
the
director
of
ops
basically
chimed
in
on
our
epic
or
one
of
our
issues.
Like
I
don't
know
what
a
feature
is,
and
I
don't
know
why
we're
doing
it,
and
it's
not
clear
to
me-
and
I
don't
know
how
our
customer's
gonna
interpret
that
and
it
just
sort
of
made
us
both
questions
like
I
don't
know
if
we're
actually
doing
a
good
job
being
as
iterative
as
we
could
be.
C
So
it
means
like
we'll
have
to
touch
the
legacy
issue
view
just
a
little
bit
more
than
we
maybe
wanted
to,
but
it
does,
especially
after
talking
with
a
really
large
customer
who's
migrating
from
jira
to
gitlab.
They
said
their
biggest
problem
right
now
was
the
fact
that
we
didn't
have
tasks
because
they
had
to
use.
Then
ethics
is
their
user
stories,
where
you
can't
associate
a
milestone
directly
to
an
epic
order
iteration.
C
So
you
basically
can't
use
some
of
those
time
box
features
for
doing
their
user
story.
Team
level
planning
stuff
so
like
it
also
makes
sense
for
us
too,
when
we
go
to
weight
things,
you
know
breaking
it
down
into
tasks
and
then
be
able
to
wait
it
and
then
that
automatically
roll
back
up
to
the
issue
view.
So
there's
lots
of
reasons
why?
But
please
collaborate,
push
back,
ask
questions,
challenge
dissent,
which
is
awesome
and
under
the
premise
of
customer
value,
iteration
quality
and
also
usability.
So
one.
B
B
H
B
It's
a,
I
don't
know
how
to
call
it.
It's
it's
basically
a
directory.
It's
it's!
What
it
is
because
it's
not
related
like
a
a
branch
is
sort
of
related,
like
nmr,
is
related
to
a
branch
to
the
fact
that
you
are
doing
your
work
in
that
branch,
but
it's
more
like
a
tag.
It's
not
yeah,
like
a
branch
or
a
tag,
is
very
close
in
in
this.
B
In
that
sense,
so
I
know
that
we
have
the
create
a
branch
button
there,
but
I
think
there
is
a
lot
of
the
confusion
with
that
there
I
don't
know
like
I'd
rather
have
that
branch
created
automatically
somehow
then
have
a
create
wrench
button
there.
So
we
like
have
it
hidden
behind
the
create
merge
requests
until
some
branches
is,
I
think,
it's
better
than
anyway,
just
like
that.
C
That's
what
I've
got
too,
but
then
I
think
I
engage
on
this
issue
at
some
point
and
like
ask
some
questions,
and
this
is
like
one
of
the
most
uploaded
issues
in
plan
is
being
able
to
add
an
existing
branch
to
specific
issues.
So
before
you
have
the
mr,
you
have
your
branch.
I
want
to
be
able
to
associate
it
to
an
issue
right.
B
Then
how
does
that
work
like
and
we
can
we
can
take
it
to
another
yeah?
The
same
thing
is
true
of
tags,
though,
is.
C
People
be
like
a
tag
in
gitlab
is
just
a
release
like
when
we
create
a
release,
we
created
tag,
and
that
has
a
metadata
associated
with
it.
Lots
of
people
want
to
be
able
to
associate
a
tag
directly
to
an
issue
or
infer
that
relationship
from
an
mr,
so
I
know
what
what
basically,
what
tag
power
tags
this
issue
like
was
in
if
that
makes
sense,
so
it's
sort
of
like.
B
B
B
I
I
want
to
understand
what
it
means
from
the
user's
person
like
what
what
it
is
supposed
to
mean
that
then
what
I
I
will
filter
all
my
issues
for
a
specific
branch
and
the
branch
is
really
a
familiar
in.
In
my
understanding
like
you
create
them,
are
you
do
your
work?
You
remove
the
branch,
it's
not
something
that
that
stays
a
long
time.
It's
not
something
that
you
usually
do,
reporting
by
or
or
anything
like.
I
don't
understand.
B
C
I'm
not
saying
that
it's
the
right
thing,
but
I
do
know
that
is
common
and
when
I've
talked
to
some
larger
customers,
they're
not
happy
that
they're
in
the
spot
now,
but
they
maintain
a
branch
for
each
of
their
customers.
C
So
whenever
they
implement
a
feature
in
some
other
branch
and
they
need
to
port
it
to
like
five
of
their
customers,
they
integrate
that
branch
into
the
other
branch
right.
So
they
actually
have
long
running
branches
that
they
use
for
things.
That's
one
and
another,
is
a
lot
of
people
will
work
on
a
branch
before
nmr
and
there's
no
visibility
of
what
that
the
fact
that
it's
been
started.
So
instead
of
opening
an
mr
and
waiting,
they
create
the
branch
and
then
they
work
on
the
branch.
C
And
then
they
open
the
mr,
when
they're
ready
for
code
review,
and
so,
if
you're
doing
things
like
measuring
cycle
time,
for
example.
So
how
long
does
it
take
from
when
an
engineer
starts
working
on
this
thing
to
when
it
gets
merged
in
you
actually
have
to
measure
across
both
when
they
open
the
branch?
And
then,
when
the
merge
request
gets
merged
or
the
branch
gets
closed
and.
B
B
I
understand
I
just
don't
yeah,
I
don't
see
how
we
can
relate
one
to
another
in
a
kind
of
consistent
way,
so
to
say,
because
it's
not
a
an
object
in
the
database
probably
would
need
to
do
something
yeah.
I
I
get
that
I
don't
think
about.
C
Yeah,
that's
how
it
works.
Now,
it's
unstyled,
it's
under
the
I
mean
I
can
show
you.
Let's
see,
if
I
can
do
it
right,
quick.
A
Yeah,
I've
definitely
seen
it
recently.
It's
it's
pretty
horrible,
but
it
it
works.
C
C
This
is
why
I
think
all
this
stuff
is
too
complex
right
now.
We
can
defer
that
until
after
we
get
the
word
kind
of
hierarchy
thing
in
right,
but
I
also
will
say
like
from
our
direction
page-
and
this
is
something
that
melissa-
and
I
know
david
or
care
about-
is
this
idea
of
using
devops
data
guy
playing
so
eventually
being
able
to
pull
more
stuff
from
downstream
back
upstream,
whether
that's
like
dora
metrics
or
even
like
your
requirements,
traceability
matrix,
is
or
linking
all
of
your
code
changes
to
a
specific
work
item.
C
You
know
some
of
those
types
of
things
like
it'll
get
interesting
again,
that's
like
three-year
vision,
so
we
can
defer
some
of
this
stuff
if
we
want
for
as
long
as
we
need
to
I'm
just.
This
is
where
I'm
kind
of
just
talking
a
lot
about.
There
are
some
real
customer
pain
points
immediately
between
mrs
and
issues
and
not
having
a
better
defined
relationship.
A
C
A
hack
because
we
don't
have
tasks.
Let
me
I
can
actually
share
this
with
you,
because
somebody
wrote,
I
think
the
tam
or
somebody
else
wrote
a
really
good.
C
This
is
all
the
summary
notes
from
a
recent
call
with
this
customer
who,
when
you
see
their
name,
you'll
they're
one
of
our
largest
customers
so
number
four
down
there.
You
can
read
through
that
and
get
some
get
some
good
insights.