►
From YouTube: Work items weekly sync - 2021-08-03
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
Yeah,
I
was
just
curious.
I
saw
that
we
got
the
work
items
types
table
merchant,
which
is
awesome,
so
good
work.
Everyone
do
we
need
to
do
anything
to
better
break
down
the
I
guess
or
refine
the
nbc
zeros
for
the
front
end
and
back
end,
because
there's
still,
I
think,
there's
48
issues
in
the
front
end
and
five
in
the
back
end,
and
only
one
of
them
has
a
weight
on
it.
So
just
curious
how
we
want
to
track
would
work.
B
Well,
I
can
speak
a
little
bit
to
that.
Maybe
just
you
know
the
the
the
one.
That's
the
move
issue
type
to
separate
separate
table.
That's
actually
going
to
be
about
three
or
four,
mrs,
that
I'm
actually
tracking
within
that
specific
issue.
A
I
don't
I
don't
need
more
issues
I
just
if,
like
I
guess
it
will
be
helpful
for
me
and
kristin
just
to
kind
of
see,
and
if
so,
if,
like,
I
don't
care
how
many
mr's,
mrs,
are
per
issue,
but
is
there
any,
like
any
other
large
scale,
things
that
we
need
to
do
for
npc
zero,
besides
sort
of
adding
the
support
for
the
default
issue?
Types,
which
is
something
is
absolutely
like
customer
value
too
so
or
are
we
gonna,
add
support
for
default
issue
types
or
not
for
this?
C
Cool,
it's
all
right.
Well,
you
had
for
the
for
the
one
you
mentioned
the
moving
issue,
type
to
separate
tables.
Well,
you
just
add
kind
of
an
overall
weight
on
that.
I
get
the
sense
that
it's
sort
of
you
know
known
known
work
in
terms
of
how
you'll
approach
it,
but
just
so
that
we
have
some
sense.
For
that
sure,
and
then
the
replace
issue
type
with
work
item
types
table
is
the
one
that
was
just
merged
right.
C
Yeah
I
mean
I
would
I'll
leave
it
to
brett.
I
think
that,
like
mvc
zero
week
from
the
back-end
perspective
was
mostly
or
is
mostly
kind
of
the
decision-making
and
the
technical
discussion
which
a
lot
of
that
has
happened
and
has
been
successful
so
far,
but
I
guess
I
guess
the
my
point
would
be
like
brad
as
you
get
into
it.
If
there's
things
that
you
want
broken
out
into
more
granular
issues,
we
should
we
should
do
that,
so
we
can
keep
track
of
it.
That's
that's
my
perspective
on.
A
I
like
I'm
down
to
track
to
work
either
as
tasks
on
an
issue
or
different
issues,
just
trying
to
think
about
if
it's
like
a
joint
cross
stage,
effort,
there's
a
lot
of
back-end
engineers
and
there's
a
lot
of
front-end
engineers,
and
I
just
want
to
make
sure
that,
like
we're
focused
on
the
most
important
things
to
move
things
forward
as
quickly
as
possible
in
14.2
within
reason
like
I
know
that
holly
is
pretty
close
with
the
initial
designs
for
mvc,
one,
both
the
mobile
view
and
the
webview
so
like
we
should
be
able
to
get
started
on
that
at
some
point
and
yeah.
A
D
Does
it
make
sense
to
start
breaking
down
nbc
one
then,
because
the
end
of
the
end,
the
mvc
zero
it's
hard
to
kind
of
determine
like
what
the
actual
deliverables
are
going
to
be
from
mvc0,
where
mvc1
will
actually
should
accomplish
something
in
code.
D
A
Add
icons
to
cards
on
boards
and
there's,
like
a
bunch
of
fun
front,
end
work
we're
going
to
have
to
do
anyways
right
before
we
want
to
turn
this
on,
so
that
there's
a
clear
differentiation
between
the
feature
and
bug
or
issue
or
whatever
these
other
types
are
so
in
terms
of
mvc0.
A
I
see
the
thing
that
could
be
deliverable
if
we
want
it
to
be,
would
be
that
user
facing
support
for
default
issue
types
and
then
mvc1
is
building
on
top
that
with
the
feature
itself,
I
don't
know
if
we
want
to
do
that
or
not,
but
that's
what
I
would
recommend
at
least.
B
D
And
then
sorry
right,
the
work,
the
work
to
get
that
moved
over
is
going
to
like.
We
still
need
to
do
some
other
preliminary
work
before
we
do
that
right
or
is
that
something
that
can
happen
in
the
next
one
or
two
milestones.
B
No
that
can
happen
the
next
in
the
next
few
weeks.
That's
what
getting
that
table
in.
There
was
kind
of
the
first
thing
and
kind
of
the
thing
we
couldn't
do
anything
else
out
without
getting
that
in
so
now
I
can
start
the
putting
the
migration
code
in
and
then
getting
stuff
moved
over
and
that's
what
I'm
working
on
next.
D
E
D
Just
the
smaller
details
for
yeah
issue
types
within
like
the
current
list
view.
E
I
think
so,
I'm
trying
to
reuse
as
many
patterns
as
possible.
I
think
the
only
newer
things
might
be
for
badges,
I'm
talking
with
jeremy,
about
how
to
kind
of
tweak
the
design,
because
the
badge
and
for
status
in
particular-
and
this
design
is
going
to
be
a
button
and
so
we're
trying
to
kind
of
change
that,
since
currently
statuses,
are
not
buttons.
We're
trying
to
make
them
look
kind
of
like
buttons
that
still
like
badges,
but
it's
still
reusing
existing
iconography.
E
A
I
think
we're
gonna
probably
want
to
add
two
more
defaults
at
some
point
like
because
a
ticket
right,
which
is
the
issues
that
your
or
work
items
you
get
created
from
service
desk
and
then
another
one
for
task
which
will
be
we'll
work
on
like
after
feature,
which
will
be
the
child
of
whatever
the
issue
is
now,
but
we
can
add
those
later
right,
so
I
don't
think
we're
blocked
on
any
design
assets
for
actually
showing
like
a
type
icon
in
the
list
or
in
a
detailed
view
or
in
a
card.
C
I
was
just
typing
there:
the
currently
that
sort
of
adding
support
for
default
issue
types
that
layout
there
that
way
that
issue's
broken
down
as
it's
marked
as
blocked
by
the
hamiltonview
issue
list.
Is
that
accurate
or
like?
Is
that,
like
an
actual
blocker.
A
I
don't
know
I
didn't
write
it.
There's
a
blocker,
it's
close
kong's
been
working
on
it.
I
know
that
yeah.
C
Yeah
I
mean
I
noticed
it's
got
like
just
a
handful
of
tasks
left
in
there,
so
I
I
think
it's
probably
close.
I
just
didn't
know
donald.
If
you
know
that's
if
that's
gonna
be
turned
on
or
if
that's
a
hard
blocker,
for
I
don't
know
that
it
needs
to
be
necessarily,
but
I'm
not
really
sure.
On
the
front
side.
D
Around
the
issue
list
getting
the
issue
list,
refactor
done
yeah.
C
Is
that
a
hard
blocker
for
delivering
that
first
piece
of
user
value
on
the
issue?
The
default
issue,
types.
D
Not
like
we
can
go
ahead
and
do
this
on
the
old
code,
if
that,
if.
C
Yeah,
I
think
we
should
do
it
right.
We
shouldn't
double.
We
shouldn't
add
more
work
to
ourselves.
I
was
just
vocalizing
that
like
given
that
we
have
that
still
in
progress
and
if
we
wanted
to
then
add
that
add
kind
of
the
back
end
for
the
default
issue
types
and
get
the
front
end
user
functionality
done
in
the
next
three
weeks.
I
think
that
might
be.
I
don't
know
I'm
not.
I
don't
want
to
like
undersell
us,
but
I
also
don't
want
to.
C
I
don't
want
to
get
in
a
situation
where
we
have
this
expectation
where
we're
like.
Oh
yeah,
we'll
ship,
the
default
issue
types
and
then
we're
like.
Oh
wait.
We
still
have
like
things
to
clean
up
with
the
issue
list.
That
is
a
blocker.
D
Yeah,
let's
do
this
because
right
now,
julian,
I
think,
is
spending
a
decent
amount
of
his
bandwidth
on
this
on
the
back
end
of
this,
getting
it
over
to
graphql,
and
then
this
is
also
kong's
focus.
D
Let
me
talk
to
kong
and
get
a
better
feel
for
what
is
left
and
if
it's,
if
it's
even
feasible,
to
get
it
done
in
the
next
couple
weeks
to
get
the
refactor
done
in
the
next
couple
weeks,
and
then
we
can
figure
out
if
we
can,
because
to
get
the
issue
types
at
least
on
the
front
end
done
with
the
refactored
code,
is
not
a
huge
lift,
so
we
can
probably
get
that
done
like
really
shortly
after
we
get
the
refactor
done.
D
So
if
it's
feasible
to
get
the
refactor
done
in
next
couple
weeks,
then
it
should
be
reasonable
to
get
this
done
also
in
the
in
14
2.
But
let
me
let
me
just
confirm
where
we're
at
with
kong.
A
C
I
was
just
going
to
say
that
alexandria's
out
for
the
next
two
weeks,
brett's,
obviously
working
very
hard
on
the
stuff.
I
think
mario
and
heinrich
have
not
been
as
involved
in
the
work
items
type
stuff.
Yet
so,
and
I
expect
them
to
be
eventually
but
they've
been
just
kind
of
on
other
stuff.
C
The
delayed
deletion
stuff
is
done
or
awaiting
the
last
kind
of
like
technical
writing
review
before
it's
done
for
us,
which
is
great
that'll,
be
kind
of
a
big
weight
off
of
our
shoulders,
and
then
I
was
gonna.
Ask
you
gabe
about
having
heinrich
dive
into
the
search
stuff
next,
which
I
think,
like
isn't
directly
work
items
related,
but
for
us
to
be
able
to
effectively
search
work
items
issue
search
will
need
to
be
able
to
work.
C
So
I
was
thinking
that
was
probably
a
good
investment,
but
I
wanted
to
lost
the
reliability
and
scalability
stuff.
So
I
wanted
to
clear
that
with
you
before
I
sort
of
officially
point
in
that
direction,.
A
Yeah,
I
think
it's
important.
However,
we
ended
up
solving
for
it
if
it's
with
pg
full
text
search.
A
I
did
dm
heinrich
and
I
asked
him
I
was
like
I
wonder
if
we
can
use
like
ts
vector
for
things
like
you
know,
doing
the
complex
sorts
and
stuff
like
that
too,
because
I
was
reading
about
it
and
it
might
be
able
to
like.
If
we
treat
a
lot
of
that
stuff
as
text,
it
might
be
able
to
fix
a
lot
of
problems,
but
I
think
that's
the
right
thing
in
terms
of
our
overall
product
themes
of
sas
reliability.
A
That
can't
use
basically
like
it's
it's
way
more
broken
for
them
than
it
is
for
us
because
they
have
like
256
000
issues
or
something
like
that
so
like
they
can't
use
search
at
all,
and
I
think
it
would
tie
into
that
theme
of
of
kind
of
reliability.
A
I
don't
know
unless
you're
on
the
call
we
had
those
three
okrs.
I
just
want
to
make
sure
all
of
our
work
lies
to
the
okrs
too,
but
I
think
we
do
need
to
fix
that
either
way
because
it's
pretty
broken.
F
I
believe
those
are
covered
right
or
they
should
be
not
maybe
not
next
milestone,
but
within
the
next
couple
and
then
the
other
one
that
came
to
mind
was
workspaces
right
and
continuing
to
invest
in
that.
So,
okay,
john,
is
working
with
jim
ray
and
I
believe
that
would
continue
right
and
at
least
until
imrae
has
a
poc
and
then
we
might
shift
and
invest
more.
I
don't
know
that's
a
question
for
for
you
all,
because
per
where
the
ended
up.
F
A
I'll
speak
from
product.
I
think
we
because
it
supports
the
longer
work
item
things
strategy.
We
need
to
get
issues
or
work
items
at
the
group
level
more
than
we
need
epics
and
projects,
so
jan
is
working
on
the
issues
in
the
group
prototype
or
poc,
and
while
I'm
I'm
working
on
epics
and
projects,
I
think
we
need
to
basically
get
issues
at
the
group
level
and
make
it
and
make
it
generally
generally
available
and
then
reassess
bss
priorities
but
yeah.
A
Eventually
we
kind
of
need
to
have
that
and
as
an
ongoing
theme,
where
we
start
to
port
stuff
over
to
the
namespace,
like
you
know,
we'll
provide
a
lot
of
customer
value
as
well.
Like
labels
is
a
huge
one.
I
think
we
listed
out
a
bunch
of
different
potential
or
possibilities
so
having
a
couple
folks
work
on
that,
basically,
we
can
even
swap
out
who's
doing
which
objects
or
whatever.
So
everyone
has
a
chance
to
interact
with
that
part
of
the
code
and
learn
about
it
but
yeah.
I
think
it's
important.
A
Correct
so
it's
in
order
to
deprecate
epics
fully.
We
have
to
have
something
a
work
item
right
at
the
group
level
so
that
you
can
migrate.
Epics
onto
this,
like
workout
hierarchy,.
D
A
You
have
to
have
the
issues
that
in
the
name
space
and
then
we
also
have
to
have
parenting
on
work,
items
or
issues
and
then
once
those
two
things
and
then
the
types
is
like
kind
of
underpins
all
that
and
once
those
are
all
there,
then
we
can
migrate
epics
over
basically
to
to
work
items
that
will
also
unblock
the
ability
to
have
parenting
on
requirements
parenting
on
test
cases.
A
F
B
D
A
How
do
you
pronounce
the
emery
name
right
and
ray
they're
doing,
is
they're
doing
a
proven
concept
to
show
how
you
can
move
like
core
objects
like
issues
to
the
name
space
and
then
the
name
space
will
wrap
both
the
group
and
then
you
a
group
namespace
and
then
a
project
namespace.
So
that
way,
when
we
put
things
like
move
things
in
the
namespace
they're
available
things
below
them,
so
it's
like
a
class
or,
however,
you
say
encode
like
above.
Basically
that
would
wrap
both
the
group
and
project.
A
So
that's
like
how
they're
going
to
approach
consolidating
groups
and
projects
over
the
long
run
and
then
eventually
move,
I
think,
most
everything,
except
for
repos
at
least
that's
a
working
theory.
Last
time
red
move
everything
except
for
repos
out
of
the
project
into
the
namespace,
but
eventually
you'll
be
able
to
have
repos
in
the
namespace
too.
So
that's
part
of
that
effort
right,
so
we
won't
actually
be
like
linking
it
to
the
group,
we'll
be
moving
it
issue
to
the
namespace
and
then
project
and
group
get
the
namespace
so
that
they
get
issues.
A
C
D
C
I'll
say
that
it
like
currently,
we
can
compartmentalize
it
as
decoupled.
There
may
come
a
time
when
we're
like.
Oh,
we
like
this
is
moving
forward,
and
now
we
have
different
decisions.
We
have
to
make
on
the
work
items
work
because
of
that,
but
like
as
of
right
now
we
we
can
kind
of
not
think
about
it.
I
guess
is
the
the
current
state.
A
F
F
A
Yeah,
so
the
idea
is
you
can't
if
we,
depending
on
when
we
get
to
enabling
customizing
types
and
stuff
the
type
that
will
only
at
your
top
level
name
space?
A
I
guess
eventually,
that
would
be
the
workspace
for
self
managed
and
then
it
gets
inherited
down,
and
then
you
can't
change
them
anywhere
downstream,
yet
because
that
opens
up
a
lot
of
other
complexities
like
if
you
have
to
move
issues
from
one
project
to
another
that
doesn't
have
the
same
type
and
blah
blah.
So
we're
gonna
like
defer
that
as
long
as
possible,
maybe
never
do
it
if
we
can
get
away
with
just
having
them
it's
sort
of
the
highest
level
namespace.
F
F
A
In
six
minutes,
co
talk
with
kristen
who's,
not
here
I
think
she'll
be
in
the
actual
talk,
but
it's
we're
sort
of
highlighting
our
road
map
direction.
Talking
about
some
common
challenges,
customers
facing
20
21
minutes
in
length.
So
it's
not
that
long,
but
if
you're
interested
probably
won't
be
anything
new
to
you
all.
Since
we
talked
about
all
this
stuff,
but
it's
more
public
facing,
so
that
we
can
let
our
customers,
the
water
community,
know
where
we're
headed
with
the
plant
stage.
So
go
for
it.
A
Yeah,
so
I
put
the
presentation
together
and
legal
was
not
too
pleased
with
my
satire.
Put
it
that
way,
so
we
had
had
to
do
some
back
and
forth
negotiations
on
what
I
couldn't
include.
Unfortunately,
I
wasn't
allowed
to
use
the
safe
diagram.
A
You
know
from
the
safe
scale,
agile
frameworks
website
and
I
was
going
to
put
just
a
black
box
over
it
says
I
wasn't
what
legal
told
me
I
couldn't
show
this
picture,
but
I
wanted
to
keep
it
a
little
bit
professional,
not
quite
as
undermining
so
I
removed
that
to
keep
things
you
know
relationships
with
with
folks
outside
of
get
lab,
smooth,
yeah,
it's
great,
but.
B
We
we
all
want
access
to
the
unredacted
version
when
you
yeah.