►
From YouTube: Work Items Sync 2021-09-08
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
Thank
you.
I
have
the
first
topic
so
yeah
I
was
just
looking
through
some
of
the
some
of
my
to-do's.
There
were
a
couple
around
requirements
realized.
I
was
still
a
little
unclear
on
the
work
that
we
need
to
do,
particularly
for
the
front
end.
A
So
I
I
listed
off
two
options,
but
then
john,
you
have
an
answer
which
I
don't
know.
Yet,
if
it's
one
of
those,
but
you
want
to
just
go
through
what
what
you
think
the
we're
doing
with
requirements
right
now.
B
Yeah,
I
can
just
say
what
I
think
the
plan
is
so
far
subject
to
change.
I
guess
like,
but
we
were
planning
to
proxy
the
existing
requirements.
Graphql
api
through
the
existing
requirement
object.
So
we
still
need
that
object
for
the
iid
and
in
order
not
to
have
to
do
like
a
big
migration
of
all
existing
data
to
reduce
the
risk.
B
We're
gonna
sync
work
with
the
work
item,
version
of
requirement
and
the
canonical
old
version
of
requirement
for
a
while
and
so
they'll
be
like
identical
and
then
we'll
move
the
backend
graphql
api
to
use
the
new
requirement
work
item
type
with
the
existing
requirement
as
a
proxy
like
so
from
the
front
end
perspective
like
nothing,
should
change
at
that
point.
B
If
it
all
goes
well,
like
you,
won't
even
notice
the
difference,
but
in
the
background
we'll
be
using
the
work
items
table
instead
of
well
sort
of
like
we
can't
fully
get
rid
of
the
requirement
the
requirements
table
yet
at
that
point,
but
it
just
means,
like
you,
have
the
maximum
amount
of
time
to
like
to
basically
choose
when
you
want
to
move
to
the
new
api.
When
you
have
finished,
like
the
new
work
item,
view
just
gives
us
more
flexibility.
A
A
Yeah
and
then
we
can
at
the
same
time,
we
can
probably
create
any
any
widgets
that
we
need
just
for
requirements,
but
we
can
still
release
and
work
on
feature
before
we
work
on
requirements.
B
Ideally
we
get
past
this
point
and
we'd
get
through
the
syncing
code,
and
that
would
be
a
natural
breakpoint
for
the
backend
for
requirements,
because
we
don't
want
to
leave
that
syncing
code
in
indefinitely,
like
because
it's
costly
so,
but
it
is
nevertheless
like
it's
a
natural
break
point
at
that
point.
We
can
make
another
decision
by
what
we
want
to
do
next.
C
A
Yeah
we
should
we
should
definitely
create
more
issues
around
porting
the
requirements
front
end
over
to
work
items
I'll
take
on
creating
those
there's,
also
the
issue
around
removing
removing
requirements
or
removing
issues
from
the
old
issue.
Removing
issue
widgets
from
the
old
issue
view
four
requirements
that
doesn't
sound
like
it
is
going
to
be
necessary
anymore.
C
C
B
I
think
there's
only
one
additional
requirement
for
for
parity
with
requirements
like
currently
and
that's
the
satisfies
yeah
satisfied
state,
which
I
don't
know
how
much
work
that
really
is
other
than
that
they're
really
just
currently
titled
description.
I
think
there's
probably
more
work
involved
in
restricting
existing
features
like
assignees
and
so
on,
labels,
and
that
than
there
is
in
creating
a
new
widget.
D
Maybe
like,
instead
of
thinking
about
restricting
and
going
backwards,
we
can
we
work
forwards
and
think
about
allowing
so
like
that
way.
As
we
build
new
widgets
right,
you
can
make
it
allowable
on
the
work
item
versus
hard
coding,
a
bunch
of
stuff
say
like
in
the
model
level
that
said
requirements
can't
have
all
these
things
all
these
widgets,
because
I
think
that's
sort
of
the
flexibility
we
want
to
get
to
because
I'm
sure
eventually
somebody's
going
to
want
to
have
assignees
on
a
requirement.
Maybe
other
people
don't
right.
D
So
it's
that
sort
of
thing
where
I
would
build
it
up
from
an
allow
standpoint
or
an
enabled
standpoint
versus
a
disallow.
B
E
Problem
with
the
restricting
is
we
need
it,
because
we
want
to
keep
this
back
and
forth
capability
between
the
old
requirement
and
the
new
work
item
right.
So
this
is
why
we're
restricting
stuff,
because
if
you
move
a
requirement
to
and
if
your
work
item
address
in
ease
and
then
for
any
reason,
you
need
to
move
back,
you
cannot.
You
are
now
basically
losing
that
functionality.
E
E
Like
we
do
add
a
lot
of
the
code
just
because
we
need
to
keep
this
functionality
in
sync
for
a
short
period
of
time
hopefully,
but
but
like
I
don't
I,
I
think
there
is
no
other
way
to
to
do
it.
So
I
think
that's
the
main
reason
why
we're
doing
it,
because
if
we
were
to
like
okay,
let's
move
everything
we
don't
care
about
the
old
stuff.
E
If
anything
breaks
we
just
move
on
and
do
a
fixes
or
stuff
like
that.
We
deal
with
it.
Then
we
don't
need
to
have
a
lot
of
these
restrictions
and
on
and
then
syncing
things
and
so
on,
but
yeah
correct
me.
If
I'm
getting
it
wrong.
B
Yeah,
but
for
future
types
like
it
should
be
pretty
easy.
It's
just
the
fact
that
we're
migrating,
something
that,
where
there's
already
data
in
the
database,
it's
it's
safer
to
pardon
me
it's
safer
to
do
it
this
way
but
like
in
future.
If
we
just
want
to
add
assignees
to
a
work
item
like
it
should
be
relatively
straightforward
for
a
for
a
brand
new
work
item.
C
Just
so,
I'm
clear
too,
that
the
actual
work
item,
type
called
feature
would
need
to
exist
as
well.
Does
it
already
in
the
db
for
the
front
end
to
start
working
on
it.
A
Correct,
no,
it
doesn't
that's
just
another
thing:
we're
going
to
mock.
A
B
Yeah,
we'll
need
to
figure
this
out
like
because
it
affects
our
unique
ids
as
well,
because
they're
enumerated
by
like
they're,
you
only
unique
for
the
currently
for
the
type
of
object.
You're
working
with
like
it's
possible,
have
an
issue
number
one
and
an
epic
number
one
right.
So
what
they're
all
work
item
types
and
we're
thinking
about
urls,
we'll
also
have
to
think
about
that
like
how
that's
going
to
work.
E
Does
the
url
have
to
say
it
or
can
we
use
like?
I?
I
think
the
easiest
way
is
to
use
these
generic
urls,
where
you
can
access
any
type
of
work
item
through
the
same
url.
Basically,
and
once
you
land
on
the
page,
you
kind
of
visually
should
see
that
it's
one
type
or
the
other,
because
that
will
help
with
my
creating
one
type
to
a
different
one
and
still
keeping
the
old
urls
working
otherwise
yeah.
E
Otherwise
we
don't
have
a
way
to
do
it
to
be
totally
fair
like
if
we
had
something
like
some
sort
of
a
document
structure
that
we
could
have
went
through
the
database
and
replaced
everything
and
update,
then
it
would
have
made
some
sense
but
like
currently,
as
I
see
it,
I
think
we
should
try
and
and
see
how
we
can
move
off
of
specifying
the
type
in
the
url
or
I
think
we
may
actually
have
to
move
off
of
ids.
But
I'm
not
exactly
sure.
B
No
you're
right,
we
don't
have
to
move
off
them,
but
we'll
have
to
change
references
to
all
exits.
So
say
we,
we
moved
epics
to
be
a
work
item
type
we'd
have
to
they'll
all
have
new
iids.
The
existing
epics
will
all
have
new
ui
ids
and
we'll
have
to
update
all
references
currently
in
all
markdown
in
all
locations
to
point
to
the
new
id
through
the
work
item
link.
That's
fine
actually!
E
Yeah
or
or
we
could
use
some
sort
of
a
red
direct
like
keep
the
epic
stable,
all
the
epic
stable
as
a
redirect
endpoint
to
just
keep
backward
compatibility
with
the
old
urls,
but
then
yeah
probably
will
not
happen.
I
was
thinking
that
you
may
end
up
with
two
epics
having
the
same
id,
probably
not
possible,
just
because
epics
is
so
much
smaller
than
issues.
E
C
C
E
E
Yeah
yeah,
so
so,
basically,
I
think
what
I
think
we
can
do
is
when
you
want
to
autocomplete.
You
do
work
item
identifier
and
then,
when
it
gets
rendered,
we
can
try
and
and
kind
of
get
that
information.
I
don't
know
how
feasible.
That
is,
though,
because
that'll
mean
probably
a
database
called
to
get
the
type
of
this
work
item
and
display
it
in
the
ui
in
a
certain
form.
So
that
may
be
very
expensive
to
do
so
or
yeah.
E
I
don't
know,
actually
maybe
it's
actually
the
same
price
as
we
pay
right
now,
because
we
parse
everything
through
the
banzai
right.
So
I
don't
know,
but
it
might
be,
might
be
expensive.
So
so
one
way
to
do
it
is
probably
use
the
same
way
to
autocomplete
and
then,
when
you
render
it
to
try
and
identify
the
type
and
show
it
in
a
in
a
kind
of
unique
typeish
way,.
C
D
Yeah,
I'm
just
curious.
I
want
to
make
sure
that
I'm
not
or
christian's
not
preventing
us
from
moving
forward
efficiently
with
work
items
like
including
the
requirements
stuff
that
we
talked
about.
The
new
ui
front
end
like
what
do
engineering
and
ux
need
from
us
product
managers,
or
what
can
we
do
to
help
unlock
things
and
move
them
forward
like?
Are
there
specific
tasks
or
actions
or
issue
refinement
or
epic
refinement,
or
just
in
general?
A
From
the
front-end
perspective,
I
think
we're
pretty
good
right
now.
I
can
see
there
being
a
lot
more
movement
than
requests
from
you
all
once
we
get
the
front-end
architecture
in
place
and
we
start
having
conversations
around
how
the
api
is
going
to
look
like.
A
A
B
Same
here
like
just
be
active
on
any
questions,
ask
me
or
the
person
who's
working
on
it
for
clarity,
if
you
don't
understand,
what's
being
asked
and
also
keep
the
issues
like
top
of
the
ready
for
development
column,
that's
about
it
really
like
nothing
pressing
at
the
minutes.
We
sort
of
have
a
plan
and
we're
just
working
against
it.
F
I
don't
think,
there's
anything
that
I
necessarily
need
just
yet.
I
did
see
your
notes
gabe
about
the
test
report.
Widget,
so
do
we
need
to
factor
that
into
the
ui
for
requirements
becoming
work
items
as.
D
Well,
yeah,
yes,
sorry,
yeah,
okay,
yeah!
We
do
and.
F
From
a
documentation
standpoint,
should
I
create
a
new
issue
specifically
for
the
design
of
requirements
as
a
work
item,
since
there
are
some
unique,
like
ui
elements
related
to
this
particular
type
of.
G
Just
to
be
clear,
though,
that
wouldn't
be
a
blocker
for
an
mvc
since
today,
requirements
don't
have
that
right.
That
would
be
basically
value-add
after
that's
a
good
point.
D
Well,
I
think
the
problem
and
johnny
can
correct
me
if
I'm
wrong
once
we
do
move
requirements
over
the
work
items
table
and
use
that
won't.
We
have
to
then
use
the.
What
is
right
now
the
issue
view,
and
if
we
have
to
use
the
issue,
that
means
we
have
to
go
through
the
front
end
and
do
a
bunch
of
changes
to
hide
a
bunch
of
stuff
right.
B
No,
not
necessarily
because
the
issue
view
current
like
things
like
the
issue
list
work
through
don't
work
through
api
calls,
so
requirements
require
requirements.
Won't
accidentally
show
up
in
issue
views
if
we
do
the
back
end
work
to
automatically
filter
them
out.
B
On
the
other
hand,
the
requirements
view
itself
is
like
relatively
new
and
uses
graphql
exclusively.
I
believe
so
for
us
like
as
long
as
we
mask
that
right,
like
as
long
as
we
mask
the
existing
api
to
use
work
items
in
the
background
instead
of
the
requirements
table,
there
should
be
no
difference,
it's
not
great
like,
but
it
is
like
a
natural
break
point
in
the
work
that
we
can
aim
for,
like
it's,
not
the
final
state.
The
final
state
is
having
the
full.
You
know
brand
new
view.
B
It
uses
like
the
work
items,
all
the
view,
work
uses
the
work
items
table
and
the
new
api
and
everything,
but
this
is
like
a
natural
breakpoint
that
we
can
aim
for,
like
that's
relatively
risk-free.
At
that
point,.
A
B
B
Okay,
sorry,
yes,
that's
correct!
That
was
my
concern
a
couple
of
weeks
ago,
when
we
had
one
of
these
calls,
because
I
thought
we
were
aiming
for
that
and
I
thought
there
was
quite
a
lot
of
work
to
do,
but
so
long
as
I
mean
it
makes
sense
to
you
as
well
right,
I'm
not
oh
way
I
like
to
launch
here
like,
but
if
we
mask
the
requirements
api
entirely
like
it
should
make
no
difference
right.
B
We
just
have
to
be
really
careful
that
requirement
work
items
aren't
showing
up
in
the
places
that
issues
normally
show
up,
but
that
I
don't
expect
that
to
be
a
problem,
because
we're
already
doing
that
for
test
cases.
Those
are
issues
already
and
we've.
We
haven't
seen
those
crop
up
anywhere.
They
shouldn't.
D
Cool
okay,
I
think
we
have
some
clarity
so
to
circle
back.
Oh,
yes,
it
would
be
good
to
do
that
because
they
will
be
right,
and
so
I
think,
the
sooner
that
we
have
at
least
a
mock-up
of
showing
the
test
report
widget
on
the
work
on
view.
The
faster
front-end
whenever
they're
ready
can
then
implement
that
and
eventually
move
requirement
over
to
the
new
workout
view
and
which
is
sort
of
in
parallel
to
the
same
work
that
we're
already
doing
for
mpc
one.
D
What
what
test
reports?
Yeah?
It's
the
satisfied,
failed
little
indicator.
So
when
you
link
a
test,
basically,
your
requirements
are
in
fact
from
your
ci
cd
to
a
a
specific
requirement,
then
it
will
show
up
is
either
failed
or
passed
based
on
the
actual
test
reports
that
are
running,
so
that's
how
it
currently
works
now
and
current
functionality
and
all
it
really
is,
is
like
I
mean
there's
more
under
the
hood,
but
it's
just
a
little
indicator
that
says
satisfied
or
failed
like
that's.
G
B
D
Yes
manually
set,
or
it
can
be,
programmatically
set.
D
Yeah,
that
was
what
I
originally
thought
about
the
test
report
widget,
but
then
I
don't
know
if
we
want
to
tie
test
report
status
to
the
actual
requirement,
because
it's
like
is
your
test
passing
or
failing,
not
the
status
of
implementation
like
is
it
done
or
is
it
in
progress,
or
so
I
think
we
are.
We
have
to
figure
that
out.
I
took
that
into
consideration
when
I
was
looking
at
the
custom
issue-
statuses
if
we
just
treated
like
that
is
the
actual
status
of
the
thing.
D
E
There
will
probably
be
some
back
end
work
needed
if
we
do
have
different
statuses
for
different
work
items,
because
not
all
work
items
will
have
the
same
statuses
so
like
verified
or
whatever.
It
is
for
test
case
or
requirement
will
not
really
apply
for
other
issues
or
epics.
I
guess
so,
then
do
you
want
to
see
the
same
statuses
in
a
drop
down
or
wherever
you
you're
picking
the
status.
D
That's
where
I
was
thinking
about
the
test
report
being
its
own
little
widget,
because
there
could
be
a
future
state
where
you
might
want
to
include
a
test
report
right
right
right
now.
You
can
only
link
like
your
actual
code
to
a
requirement,
but
really
what
you're
effectively
doing
in
the
future
is
being
able
to
link
your
code
to
a
work
item
and
that
that's
a
separate
thing
of
like
then.
What
is
the
status
of
this
and
is
it
in
progress?
D
Is
it
like
you
know,
so
I
kind
of
see
them
as
two
separate
things
sort
of
like
what
you're
saying
alexander,
but
I'm
open
to
whatever
we
decide.
B
E
And
it's
as
long
as
you
can
fit
all
of
the
statuses
into
two
values
like
open
and
close
and
hyphen,
open
and
stuff
like
that.
But
once
you
you
have
to
have
more
statuses,
then
it
gets
trickier.
So
that's
where
we'll
need
probably
to
extract
the
status
into
a
separate
table
on
the
back
end
or
something
along
those
lines.
I
don't
exactly
know
about
those.
D
D
We
want
for
work
items
so
that
you
can
report
more
effectively
on
like
lead
time
cycle
time,
inactive
time
and
things
like
that
without
doing
a
bunch
of
extra
configuration
and
then
eventually
generate
sort
of
like
workflows,
if
you
think
about
the
value
streaming
analytics
reports
where
you
set
up
your
stages
and
boards,
where
you
set
up
your
list
for
your
different
workflow
steps,
it's
a
similar
type
thing
where
status
is
like
kind
of
the
core
for
that,
and
I
don't
think
like
you
would
want
to
measure
your
the
workflow
of
through
different
things
like
the
status
as
it
goes
through
workflow
and
that's
sort
of
different
than
like
health
right
like
you
could
be
in
progress,
and
it
could
still
be
needs
attention
because
it
might
not
finish
sort
of
thing.
D
So
that's
where
I
kind
of
view
like
health
is
its
own
widget
test
reports
is
its
own
widget
and
then
status
is
like
its
thing
that
all
statuses
apply
to
all
work
items
potentially
right
and
that
way
like
you,
have
sort
of
consistent,
behavior
across
work
items
with
the
widgets
that
you
do
have
enabled,
and
not
a
bunch
of
like
because
it'll
be
like
a
ton
of
cognitive
overhead
to
like
remember
what
status
can
apply
to
this
thing
and
like
and
then
when
you
want
to
view
them
all
in
a
board,
and
you
have
like
lists
for
different
things
like
it.
D
F
I
see
the
concern
there,
but
I
I
kind
of
feel
the
opposite,
where
I'm
a
little
concerned
that,
having
the
same
statuses,
applied
across
different
object
types
would
create
confusion
just
because
there
may
be
an
expectation
that
the
meaning
is
different,
because
the
object
is
different.
So
that's
something
I
would
want
to
explore,
but
for
for
mvc
for
requirements
do
we
need
to
consider
a
custom
status
or
a
status
that
is
unique
to
an
issue
type.
D
Well,
we
just
need
to
decide
if
we're
going
to
call
it
a
status
if
we're
going
to
call
it
like
test
report
you
know
like
or
because
that's
basically
how
you're
doing
is
you're
not
saying
like
the
is
the
thing
in
progress
is
somebody
working
on
it?
It's
is
it
passing
or
not
right
and
that's
directly
related
to
the
code
itself,
not
a
workflow
or
anything
else.
So
then
we
need
to
just
decide
like.
Are
we
going
to
put
created
like
test
report
widget,
or
are
we
going
to
actually
convert?
C
H
D
D
D
Yeah,
that's
sort
of
how
I
would
envision
it
same
with
requirements
where
you
like
every
time
it
runs
it
like.
I
think
it
saves
an
entry
for
a
test
report.
So
if
you
showed
that,
like
test
report
widget
like
let's
say
you
have
a
bunch
of
different
test
tests
or
test
reports
that
are
tied
to
a
single
requirement,
then
you
could
show
each
of
those
broken
down
right.
Instead
of
just
one
global,
like
here's,
the
overall
status
of
all
the
tests
that
apply
to
this
one
requirement,
which
is
what
we're
doing
now.