►
From YouTube: 2021-10-12 Work Items Weekly Sync
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
The
I'll
say
with
the
first
one
access
the
feature
be
the
api.
Do
we
have
is
the
issue
types
table
done?
A
C
Alex
would
you
I
don't
want
to
play
on
the
spot,
but
would
you
able
to
give
a
recap
of
friday's
discussion
in
terms
of
where
things
are?
I'm
sorry,
I
haven't
watched
it
yet
or
caught
up
on
this
stuff
since
being
out,
but
it
might
be
helpful
just
to
kind
of
go
through
that
and
that
would
help
enlighten
us
to
where
we
are
on
the
back
inside.
D
D
The
direct
direction
on
the
discussions
that
we
had
on
friday
was
kind
of
establishing.
How
would
our
graphql.
D
D
Basically,
as
as
we
need
on
the
on
the
queries,
we
also
kind
of
established
a
way
to
be
able
to
extend
it
further
down
the
line
if
well,
when
we
get
to
the
custom
widgets
again
that
this
was
mostly
discussing
things
in
general,
getting
down
to
the
actual
actual
queries,
how
that
will
look
like
how
we'll
be
naming
things
and
and
how
they
like
the
exactly
the
data
structure,
will
look
like
that's
to
be
implemented
and
to
be
like
gone
into
into
a
much
more
detail.
D
I
think
we
have
an
mr
that
front
end
is:
is
leading
right
now,
with
kind
of
putting
in
place
how
that
will
look
like
and
then
the
back
end
can
can
adjust
and
do
the
necessary
implementation
of
the
api
of
the
graphql
api
unsatisfying
kind
of
those
requirements.
Those
needs.
D
D
We
do
have
the
basic
types
in
there,
but
I
don't
think
the
types
are
yet
connected
to
the
specific
groups.
If
that
makes
sense
right,
so
we
have
the
whatever
types
we
have
right
now
issue
incident
requirements,
but
I
don't
I
don't
know
if
that
is
actually
used
like
we
have
the
data
in
the
database.
I
don't
know
if
that's
being
used
in
the
code
yet.
C
Sorry
go
ahead,
go
ahead,
oh
I
was
gonna
say
it
looks
like
it
is.
We
are
setting
it
so
we're
setting
like
the
work
item
type.
When
we
update
and
create
issues.
I
don't
think
we
have
the
the
featured
type
yet,
but
this
stuff
does
exist
to
like
it's
used
as
far
as
that.
As
far
as
setting
and
updating
goes.
E
Yeah,
but
I
I
don't
think
any
of
that
is
available
as
part
of
the
graphql
like
a
work
item
graphql
api
yet,
and
to
answer
your
question
gabe,
on
whether
we
decided
to
punt
on
that
on
the
back
end,
I
think
the
answer
is
yes.
E
For
now,
like
the
discussion
on
friday
was
primarily
around
the
poc
and
how
we
eventually
want
to
implement
it
on
the
back
end.
But
no
work
has
been
scheduled
to
do
that.
Yet
until
after
the
any
of
the
head
count,
resets
or
allocation
stuff,
they're
working
on.
E
So
I
wonder
if
we
I
think
we
decided,
which
issue
were
you
looking
at
dave,
and
you
were
talking
about
specifically
and
did
we
split
that
one
up
into
separate
current
like
front
end
using
a
mock
back
end
implementation.
A
Just
mvc1,
like
I
think,
our
goal
we've
had
a
lot
of
conversations
about.
You
know
future
vision
versus
what
we're
doing
for
mvc,
but
we
do
have
a
good
nbc
one
that
kristen's
kind
of
scoped
out
and
it's
sort
of
taken
a
few
turns
and
around
the
bend,
just
as
we've
talked
about
things
like
requirements
and
doing
that
in
parallel
and
all
this
other
stuff.
I
think
you
know
all
those
things
are
valid,
but
just
trying
to
get
like
it
nailed
down
from
a
front-end
standpoint
what
the
deliverables
are
for
nbc
one.
A
What
is
on
track?
What
needs
to
be
like?
What
do
we
feel
like
is
not
gonna
make
the
cut
for
14.4
and
then
how
like?
What
should
we
discuss
in
terms
of
goals
for
14.5?
Even
if
it's
just
front
end
from
the
front
of
the
standpoint
as
it
pertains
to
nbc
one
and
potentially
nbc2?
If
we
can
start
on
that.
E
Yeah
so
I
mean,
I
think,
that's
the
the
the
the
question
there
is
like
we
can
add
the
deliverable
and
count
it
as
deliverables
for
14
4
for
nbc
one,
but
it's
not
deliverable
in
the
context
that,
like
there
won't
be
a
back
end
associated
with
it,
it'll
just
be
for
us
to
like
using
a
mock
back
end
just
available
for
us
to
kind
of
play
around
with
maybe
locally
like
we
are.
Are
we
okay
with
defining
that
as
what
is
the
deliverable
for
for
now.
A
If
that's
as
far
as
we
can
get,
I
think
it's
sort
of
up
to
back
end.
I
think
this
kind
of
goes
into
the
one
issue
of
within
a
vc1
is
investigating
how
new
work
item
types
can
be
individually
rolled
out.
So,
like
is
it
possible
to
this
one,
I
guess
would
say:
is
it
possible
to
put
anything
in
production
behind
a
feature
flag?
A
A
E
Yeah,
so
I
think
we'll
be
able
to
do
that
even
with
the
the
poc
that
natalia
created,
which
is
behind
a
feature
flag
once
that
it's
an
mr
right
now,
but
there's
no
reason
why
we
can't
once
we
kind
of
made
some
decisions
or
answer
some
of
the
questions
that
we
had
on
on
friday.
There's
no
reason
why
we
can't
get
that
into
production
turn
on
the
feature
flag
for
us
and
then
play
around
with
just
that
mocked
front
end
there
exactly
you're,
whatever
you're
asking
me.
A
Yeah
just
trying
to
set
clear
expectations
around
deliverables
and
our
progress.
I
guess
I
don't
like
the
word
deliverables,
but
progress
towards
our
nbc
one
and
eventually
vc2
and
how
we
can
like
non-engineering
people
can
play
around
with
this,
so
they
don't
have
to
go
through
and
like
mess
around
with
gdk
and
all
that
other
stuff.
B
I
just
linked
to
a
comment
there
in
that
same
issue
that
you
linked
about
gradually
rolling
out,
and
I
did
I'm
number
four
also
is
about
that.
But
I'm
wondering
if,
if
we
get
more
formal
on
capturing
the
default
hierarchy
that
we
have,
which
is
like
epics
and
issues
below
it
and
requirements
on
their
own
or
whatever
else,
we
need
to
show
and
have
that
display
at
the
project
level
or
the
group
level
or
namespace.
B
B
E
Yeah
it
does.
We
probably
even
need
to
be
more
explicit
like
that,
because
it's
it's
like
a
level,
it's
a
level
before
or
a
step
before,
going
to
beta
or
having
it
really
usable,
because
the
data
will
be
mock
data
and
it
won't
have
any
type
of
state
or
anything.
So
like
you
could
you
could
create
a
work.
I
mean
create
a
feature,
but
it
won't
persist
so
like
once
you
refresh
the
the
screen,
you
won't
have
access
to
that
created
work
item
until
we
get
a
working
back
end
yeah.
B
D
Like
I
don't
know
how
this
is,
where
I'm
I'm
having
a
problem,
understanding
what
you
want
right,
yeah
like
I,
don't
know
how
you
want
it
to
be
viewed
in
the
ui,
because
if
we
are
talking
about
work
items
you
can
like
strictly
think
about
issues
and
and
in
issues
we
don't
have
epics,
we
don't
have
requirements
even
yet
we
don't
have
anything
that
has
any
kind
of
structure.
It's
everything
is
flat
right.
We
have
right,
yes,.
B
B
B
Do
you
have
that
it
gave
that
linear
screenshot
handy
that
you've
shown
it
a
million
times
that
one?
I.
A
Have
this
one
from
fibery
and
I
think
it's
basically
as
we
build
out
these
sort
of
the
hierarchies
like
showing
what
the
type
is
and
where
it
is
in
the
hi
the
relationship
and
not
like
messing
with
any
of
this
configurable
stuff
right
now,
like
just
omit
all
that,
but
it's
at
least
showing
the
different
thing.
Because
then,
if
it's
statically
visible,
then
you
can
sort
of
incrementally
iteratively
build
on
top
of
it
to
add
some
of
that
customizable
customizability,
which
will
definitely
come
way
down
the
road
for
sure
to
be
clear
but
yeah.
A
I
think
it's
just
a
sort
of
thing
of
visualizing,
the
current
state
of
the
system.
So
as
we
build
on
top
of
it
this,
even
if
we
just
start
with
this,
the
current
thing
you
can
have
a
bug.
You
have
you
know
and
they're
all
flat
right.
Eventually,
when
we
have
parenting,
then
you
can
show
that
what
things
are
apparently
features
apparent
of
the
current
issue
or
the
current
bug
or
whatever.
So
I
think.
D
D
B
C
B
Yeah
for
now,
for
now
we'll
also
people
will
want
to
upgrade
to
get
more
or
to
add
a
different.
Eventually,
this
screen,
we
can
show
different
ways
of
doing
products,
management,
different
types
of
frameworks
you
could
convert
to
or
like
move
your
objects
around
in
the
future.
A
Yeah
and
setting
like
the
lines
aside
across
these
eventually,
we
want
to
solve
that,
like
that's
part
of
the
roll-up
thing,
but
we
we
do
we'll
want
to
save.
Like
you
know,
a
test
session
and
test
case
is
not
part
of
the
same
work
item
hierarchy
is
necessarily
like
whatever
we
want
to
call
this.
I
call
it
in
this
diagram
temporal,
but,
like
your
feature
and
your
user
story,
your
bug
right
eventually
we'll
be
able
to
cross-link
all
these
things,
but
just
for
the
at
least
like
modeling,
the
current
system
as
it
stands.
A
So
then,
as
we
do
add,
these
different
things,
it's
sort
of
like
we're
incrementally
building
out
the
representation
in
the
product,
and
that
means
deciding
basically
where
we
want
the
that
view
to
be
this
sort
of
configuration
or
setting
view
if
that
makes
sense.
But
it
kind
of
gives
us
that
flexibility
to
kind
of
defer
all
the
customization
stuff,
but
still
provide
a
clear
experience
to
the
end
user,
about
how
the
hierarchy
works
and
which
things
are
where,
when
we
get
into
vc2
at
least.
C
B
A
Oh
here,
it
is
I'll
drop
this
in
here
I'll
just
share
my
screen
right,
quick,
no,
that's
not
doing
it,
but
basically
be
able
to
query
that
the
types
and
even
the
widgets
within
each
one
would
enable
us
to
like
use
that
same
api
to
do
a
lot
of
things
like
powering
the
token
token
I
search
powering
the
what
what
we
would
like
dynamically
render
and
bulk
get
it
in
the
sidebar
and
that
sort
of
thing
I'll
find
the
comment
that
I
left
that
talked
about
it,
but
I
think
there's
a
lot
of
things
that
are
worth
considering
in
terms
of
how
we
expose
like
what
the
sort
of
type
and
hierarchy
and
widget
schema
is.
B
So
coming
around,
we
were
seeing
what
would
be
enough
for
mvc
one.
I
do
think
we
should,
if
we
can
just
throw
bullets
up
somewhere,
where
we
at
least
show
the
objects
we
have
and
we
capture
this
may
not
be
need
to
be
an
nbc
one.
We
could
go
into
nbc2,
but
at
least
showing
how
legacy
ethics
interact
with
current
issues
and
then
all
of
the
other
hierarchies
that
could
be
created.
B
I
think
that
will
help
set
the
stage
with
mvc
2,
where
we
have
the
hierarchy
going
on
too,
because
all
of
those
hierarchies
are
going
to
inform
where
you
can
add
these
other
objects
it'll
be
a
free
for
all
to
start,
but
eventually
we
could
have
more
rules.
I
guess
around
what
we
expose
at
different
parts
of
the
hierarchy.
B
B
B
G
B
B
Yeah,
I
think
I
mean
we're
not
going
to
encourage
that,
but
probably
during
migrations
or
imports
or
things
where
people
make
mistakes,
things
will
happen
so
I'll
have
to
work
within
those
bounds.
But
if
the
imports
can
guide
them
to
choose
the
type
and
the
place
and
and
and
it
just
goes,
hopefully
that
what
scenario
wouldn't
pop
up,
but
I
have
a
feeling
it
might
be
an
edge
case.
C
I
think
donald
has
a
good
point
that
he's
typing,
but
I'm
going
to
sneak
something
in
right
before
that,
which
is
that
at
some
point
we
we
probably
will
need
to
just
sort
of
reevaluate
our
mvc
one
and
two
plans
based
on
the
head,
count
reset
timeline,
and
given
that
like
we're
now
now
we're
sort
of
hitting
the
point
where,
like
we
have
to
answer
questions
about
back
end,
that
we
just
don't
have
the
capacity
to
answer
so
we've
sort
of
pivoted,
I
think
smoothly
to
like
front
end-
is
stubbing
things
out
and
working
in
kind
of
like
a
backendless
mode.
C
But
our
mvc
plan
doesn't
necessarily
account
for
that
or
it's
like.
Not
it's
not
designed
that
way.
So
we
may
want
to
just
have
a
more
like
explicit,
like
here's,
what
mvc,
two
or
one
and
two
are
going
to
look
like
without
back-end
availability.
Given
that
we,
I
think
the
the
workspaces
work
that
alex
and
brett
are
working
on
is,
is,
is
gonna,
take
a
while,
and
so
we're
going
to
have
to
just
sort
of
continually
work
around
that.
B
C
Yeah,
just
so
we're
like
being
clear
about
the
expectations,
because
I
think
we're
trying
to
like
you
know,
maintain
as
much
momentum
as
possible,
but
we
just
have
to
be
explicit
that,
like
some
things
are
going
to
fall
through
the
games.
C
Take
me
a
couple
days
to
get
to
that
point
just
because
I
have
to
catch
up
on
what
the
head
counter
is
like.
I
don't
I
don't
know
if
you
have
good
insight
into
you
know
the
workspaces
stuff,
but.
H
D
Does
everyone
have
an
understanding
of
what
we
will
have
in
mvc1,
because,
honestly,
I
don't
like
I
would
love
to
get
this
workflow
frame
thing
like
this
is
where
I
start
clicking
issues
in
the
sidebar.
This
is
what
I
get,
and
this
is
what
the
other
pop-on
opens,
and
this
is
where
I
end
because,
like
I
don't
have
this
this
flow
vision.
If,
if
that's
only
me,
then
that's
fine,
but
I
my
understanding
is
like
I
don't.
D
I
don't
see
how
we
end
up,
how
we
go
from
starting
and
work
item
and
having
the
work
item
in
the
least
or
where
do
we
end
in
this
nbc?
One
like
we're
discussing
the
create
form,
we're
discussing
the
view,
the
view
work
item
or
something
that
I
I
just
don't
have
the
the
idea.
Where
do
I
start?
What
do
I
click
and
how
do
I
get
the
form
and
how
do
I
exit
the
form,
and
where
do
I
see
that
on
the
for
the
item
that
I
created?
Where
do
I
see
it?
D
Is
it
in
nbc
one
or
is
it
not,
and
it
will
be
like
super
nice
to
have
this?
It
can
be
like
hand
drawn
but
like
to
have
this
flow
for
a
user
that
goes
through
these
steps.
B
D
But
there
are
so
many
questions
on.
When
does
this
work
item
form
appear
when
I
click
on
new
issue,
or
do
we
have
a
different
button
when
I'm
on
list
page
or
when
I'm
on
on
a
different
page,
when
I'm
on
a
list
page
and
create
work
item
what
happens
to
the
list
and
so
on
and
so
forth?
We
don't
have
the
filters
to
to
show
that
item
and
like
there
are
a
lot
of
these
small
things
where
it's
it's
like.
I
don't
know,
I
just
don't
don't
see
it
like.
G
At
all
it
does,
I
think
what
donald
said.
I
think
we
brought
this
up
last
time
too,
and
I
think
holly's
working
on
kind
of
like
a
flow
or
a
journey
to
kind
of
show
some
of
those
aspects.
I
think
that
would
be
really
helpful.
I
I
don't
think.
D
G
E
Yeah,
it's
definitely
easier
if
we
have
something
to
visualize
that,
because
I
think
we
we
think
that
we
have
included
everything
under
that
and
we
see
one
epic
and
we
probably
have,
but
even
now
it's
getting
to
be
like
there's
a
good
amount
of
issues
and
ethics
under
that
epic
already.
E
So
that's
maybe
also
a
thing
that
could
be
helpful
as
part
of
the
product
too,
is
is
adding
some
type
of
flow
feature
within
a
within
an
epic.
So
yeah,
like
you,
said,
alexis
holly
is
looking
into
that.
I'm
not
quite
sure
where
she's
at
with
that,
but
it's
definitely
on
the
radar
to
get
to
get
a
visualization
up
for
that
real,
quick,
the
so
as
far
as
definition
of
done
for
nbc
one.
B
For
it
to
be
done,
we
have
to
be
able
to
use
it
or
test
it
or
try
it,
so
it
would
need
the
back
end.
B
E
B
E
H
E
Yeah
and
then
once
we
get
closer
to
that
point,
where
we
have
head
count
where
we
don't
have
the
allocations
to
deal
with
we're
still
going
to
be
we're,
probably
going
to
be
ahead
on
the
front
end.
So
are
we
okay
with
working
on
mvc2
at
that
point,
while
we
wait
for
the
implementation
side
of
nbc
one
to
catch
up.
B
I
think
so,
and
there
might
be
some
help,
that
the
back
end
team
needs
to
do
in
terms
of
hierarchies
and
just
making
sure
the
right
plumbing
is
there
to
do
them
like
more
conversations
around
parenting,
so
they
they
may
have
to
catch
up
on
nbc
one,
but
also
do
a
tiny
bit
of
unblocking
for
parenting.
B
Parenting
I
haven't
seen
as
much
discussion
on
it
because
we're
really
focused
on
nbc
one,
but
that's
something
where
we
in
these
meetings.
We
can
start
having
more
detailed
discussions
and
just
sync
on
what
the
whole
team
needs
to
make
that
work
as
well.
A
Since
we're
over,
can
I
just
recap
real
quick
decisions
made
we
can
keep
working
on
the
front
end
for
nbc.
One
done
is
when
customers
can
use
it,
but
that
doesn't
need
to
block
front
end
for
working
on
vc2.
A
We
really
need
to
get
the
kind
of
end-to-end
user
journey
at
least
flow
down
and
some
sort
of
diagram
or
visual,
so
that
everyone
is
on
the
same
page.
B
A
Okay
and
then
I
think
the
only
other
thing
is
what
specifically,
from
a
front-end
standpoint,
are
we
ready
to
start
on
anything
in
bc2?
If
we're
all
done
with
this
stuff
in
the
vc1
and
that's
to
decide,
I
don't
think
we
decide
on
that.
A
So,
who
wants
to
be
the
dri,
for,
I
think
largely
has
to
do
with
how
much
we
finish
in
mvc,
one
versus
how
ready
we
are
from
vc2
kristen?
Do
you
want
to
drive
that
from
the
product
standpoint
and
do
we
have
a
dri
from
engineering
to
collaborate
and
I'm
guessing
alexis
will
be
the
dri
for
product
design
since
she's
doing
the
nbc2
stuff.
E
H
I
didn't
get
a
good
sense
of
where
we
are
with
nbc
one
and
what
we're
going
to
prioritize
for
next
milestone.
So
can
we
also
take
an
action
item
for
that.
B
F
B
E
Yeah,
so
I
mean
to
your
point:
there
melissa
it's
also
because
this
is
not
like
our
traditional
to
get
out
in
14-4.
We
have
to
essentially
have
it
in
production
by
to
day
or
tomorrow,
with
the
feature
lock
like,
we
can
technically
be
working
on
it
until
the
22nd
and
if
we
get
it
like,
if
we
get
an
mr,
we
can
count
that
as
being
done
in
14
4..
So
like.
E
Let
me
go
through
as
part
of
as
part
of
looking
into
what
the
focus
is
going
to
be
on
14
5,
and
then
we
can.
We
can
jot
down
what
is
actually
what
has
been
done
as
part
of
that
process.
If
that
makes
sense,
so
essentially
what
kristen
said.
B
B
H
B
Do
have
tank
labels
for
that
a
lot
of
them
will
have
both.
C
We
could
put
it
in
if
you
want
to
view
it
from
that
epic
hierarchy
view
we
could
put
it
in
the
title
or
something.
If
there's
like
specific
yeah,
we
can
try
and
do
that.
B
We
do
have
reduced
capacity
this
week,
obviously,
with
the
thursday
and
friday,
I'm
sure
everybody's
excited.
It's
gonna
be
hard
to
focus
on
work.