►
From YouTube: Plan stage 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
Cool
holly,
you
have
the
first
point.
B
I
was
just
going
to
do
a
quick
walk
through
which
I'm
going
to
try
to
be
better
about
doing
recordings
of
my
progress
and
sharing
those
regularly,
but
I
figured
since
we
were
all
in
this
call
today
and
I
knew
it
would
be
recorded
then
I'll
share
it
here
and
continue
to
update
you
all.
As
I
make
progress.
B
I'm
still
working
through
some
details
of
some
things
here,
but
this
is
where
I'm
at
so
far
with
the
prototype
for
the
mobile
version
of
work
items.
So
the
thought
here
is
which,
by
the
way,
I
don't
know,
if
you
all
could
do
it.
If
you
don't
have
the
figma
open.
But
if
you
are
a
figma
user,
you
can
get
figma
mirror
and
it
allows
you
to
pull
up
the
prototype
on
your
device,
which
is
kind
of
nice.
So
that's
just
an
fyi.
B
If
anybody
wants
to
kind
of
get
a
feel
for
using
it
on
a
phone,
that's
that's
a
good
way
to
do
it.
So
in
this
case
let's
say
we
have
a
brand
new
work
item
that
we've
created.
I
might
go
to
add
in
a
title
and
of
course
this
is
a
prototype,
so
I'm
kind
of
just
filling
in
the
gaps
a
little
bit
here
and
there
when
it
comes
to
typing
things
in,
but
now
I've
entered
a
title.
B
I
have
included
the
tip
tap
editor
functions
here
at
the
top
of
the
keyboard,
I'm
not
sure
what
all
we
have
in
terms
of
options
for
those
buttons.
I
assume
we
can
customize
it
any
way
that
we
want.
So
the
specific
buttons
that
would
be
here
would
be
something
gabe
I'd
like
to
talk
with
you
about
and
also
kind
of
analyze.
If
we
have
any
details
on
what's
most
used,
I'd
love
to
maybe
explore
that
I'd,
also
wonder
if
we
have
a
need
or
the
ability
to
do
like
an
expanded
version
of
the
buttons.
B
If
we
want
to
just
show
a
few
here
and
then
kind
of
open
it
up
to
show
additional
options
if
someone
needs
more
functionality
than
they
see,
but
nonetheless,
so
let's
say
that
we
have
put
in
a
title:
I'm
going
to
go
ahead
and
hit
create,
and
now
we
have
just
a
title
with
the
id
at
the
top,
still
kind
of
thinking
through
what
this
might
look
like.
B
So
here
now
we
also
have
title.
Of
course
we
have
the
ability
to
add
a
description
in
that
case
when
you
click
that
I'm
proposing
that
we
go
to
kind
of
an
overlay
that
fills
that
area,
so
that
you
only
have
the
description
as
your
focus
and
you
can
kind
of
go
in
and
manage
it
and
not
have
all
the
other
noise
of
the
work
item
view
on
the
page.
B
So,
let's
just
assume
that
I
have
taken
some
time
typed
in
a
bunch
of
details,
go
ahead
and
hit
save.
Now
I've
got
my
description
here
again.
I
can
also
expand
to
view
the
full
description
if
I
want
or
leave
it
truncated,
that
would
probably
be
based
on
a
character
limit
now
I
can
choose
to
add
an
assignee.
B
So
in
this
case
a
panel
is
coming
up
gabe
and
I
talked
yesterday.
I
think
it
was
about
maybe
bringing
this
further
up
so
that
you
don't
have
you
have
more
room
to
kind
of
work,
and
that
might
still
be
the
case.
I'm
kind
of
playing
with
ideas
surrounding
that
today.
But
let's
say
that
you
enter
in
a
search
in
this
case
because
the
keyboard
comes
up.
It
kind
of
bumps
up
so
that
is
kind
of
another
case
for
maybe
expanding
it
full
height.
B
B
If
you
hit
close,
then
it
just
closes
here
may
include
a
prompt,
but
for
now
I
think
it's
okay
to
just
go
with
this
until
we
determine
that
it's
a
problem
that
people
are
closing
them
a
lot,
and
I
think
that
was
all
that
I
had
yeah
for
for
the
initial
prototype,
any
feedback,
thoughts,
questions.
B
Oh,
yes,
actually
you're
right.
So
that
is
something
that
I
need
to
go
in
and
change
for.
If
you
enter
the
title
here
yeah,
so
we
could
just
remove
this
area
and
not
have
those
buttons,
but
you
would
just
have
a
create
function
because
we're
not
looking
to
add
bolding
or
styling
or
anything
like
that.
That
was
just
me
copying
and
pasting
the
keyboard,
I
think,
and
it
accidentally
got
left
in
so
I'll
update
that.
C
And
the
other
thing
I
was
going
to
say
is
one
for
the
description
in
terms
of
like
what
controls
and
the
editor
bar
just
use
our
current
one
center
current
markdown
editor,
because
it's
going
to
be
a
while
before
the
tip
tap
editor
is
ready.
So
we're
going
to
have
to
use
our
existing
controls
for
the
time
being,
and
then
that's
probably
what
I
would
do
to
start
with.
B
C
B
Yeah,
I
I
just
want
to
understand
if
the
engineers
have
any
concerns
with
the
amount
of
time
and
effort
involved
in
making
those
changes.
I
would
like
to
clean
up
the
ui
for
it
a
little
bit
and
make
it
look
a
little
more
minimalist
and
a
little
less
weighty,
I
guess
visually,
but
I
I
want
to
be
sure
that
I'm
not
adding
a
lot
of
extra
effort
by
just
proposing
that,
because
I
think
we
have
bigger
fish
to
fry
than
clean
up.
I'm
I'm
open,
though,
to
discussion
gabe.
If
you
feel
differently.
A
I
say
go
ahead
and
propose
it
we'll
have
to
think
through,
like
how
we
want
to,
because
right
now
all
of
the
issuables
share
the
same
code
for
for
editing,
so
we'll
have
to
figure
out
like
if
we
do
make
changes.
Do
we
want
to
also
make
those
changes
to
like,
mrs,
while
we're
in
kind
of
that
that
phase
of
having
work
items
for
issues,
but
not
for
other,
previously
issuables
items.
B
Yep
agree:
I've
been
tagging
pedro
and
jerick
and
a
couple
of
other
folks
and
some
of
this
and
awaiting
feedback,
but
I
do
think
it's
important
to
consider
that
as
well.
So
if
we
change
it
for
issues,
are
we
able
to
change
it
just
for
issues?
I'm
sorry,
you
may
have
just
said
this,
or
do
we
have
to
go
ahead
and
make
the
decision
for
like
when
we
change
that
code
base?
Are
we
changing
it
for
mrs
and
epics
and
everything
else
as
well.
A
Yeah
we
have
to
figure
out
what
we
want
to
do.
We
can
do
it
either
way,
though,.
C
B
A
Just
added
a
comment
in
there
it'd
be
helpful
like
once
these
get
closer
to
to
moving
on
to
the
next
phase
over
to
engineers,
it'd
be
helpful
to
have
like
annotations,
with
get
lab,
ui
components
in
there
so
like
as
you're
thinking
through
this.
If
there
were
any
components
that
you
said,
or
you
thought
all
right,
let's
use
this
from
git
lab
ui.
A
B
A
I
think
figma
is
okay
to
just
include
it
in
there
and
then
we'll
make
sure
that
as
front-end
engineers
are
working
on
working
on
these
things,
they're
looking
through
figma,
so
figmas
can
kind
of
be
the
single
source
of
truth.
For
for
the
designs.
B
That
is
all
that
I
had
so
I'll
stop
sharing
unless
anybody
else
wants
to
see
anything
else
or
has
any
other
questions
or
thoughts.
B
That
will
all
be
so
parts
of
it.
I
envision
going
into
still
kind
of
a
menu.
I
think
the
ellipsis
menu
is
where
I
was
considering
it.
Some
of
it
will
be
on
the
actual
issuable,
but
I'm
going
to
try
to
keep
that
not
issuable
work
item,
but
I'm
going
to
try
to
keep
that
pretty
simple.
B
However,
I
wanted
to
go
ahead
and
get
just
the
mvc
proposal
done
as
soon
as
possible.
So
I'm
not
blocking
you
all
and
that's
why
it
doesn't
actually
reflect
that.
But
that
is
something
that
I'm
thinking
about
and
again
the
most
important
things
that
we've
determined.
I
need
to
look
at
the
data
that
anna
created
this
morning,
but
from
what
I
understand
from
previous
research,
the
most
important
things
are
the
title,
the
status
labels
and,
I
believe,
assignees.
So
people
want
to
see
that
information
front
and
center,
but
everything
else.
B
I
think
we
can
find
more
creative
ways
to
hide
it
behind
a
menu
until
it's
needed.
So
I
envision
a
lot
of
that
living
kind
of
in
the
secondary
menu.
From
this
view,.
E
B
Yeah
labels
are
missing,
unfortunately,
and
I
have
done
some
exploration
surrounding
how
that
can
be
presented.
It's
not
in
this
prototype
view.
Let
me
see
if
I've
got
that
screen
here.
C
Why
she's
pulling
that
up?
It's
interesting
some
of
the
ux
research
that
andeth
said
that
people
use
labels
the
most
to
keep
track
of
status,
and
things
like
that.
So
we
want
to
add
sas
as
the
first
question,
which
means
we
can
probably
downplay
labels
being
so
prominent,
which
is
my
strategy
at
least.
B
B
I'm
still
thinking
through
that
there's
just
I
would
love
to
simplify
it
as
much
as
possible,
but
even
in
all
of
the
competitors
that
I
looked
at
it's
it's
kind
of
messy.
When
you
have
those
labels
factored
in
the
management,
I
think
we
can
simplify,
but
the
actual
display
of
them
in
the
work
item
view
tends
to
be
very
visually
heavy,
but
we
can't
really
easily
take
away
from
that
without
taking
away
from
the
value
that
they
provide
for
the
user
to
be
able
to
see.
A
C
Both
depends
on
the
repo
structure,
there's
some
that
organize
their
projects
and
groups
and
like
their
value
streams,
and
then
they
keep
their
repos
other
places.
There's
some
that
use
labels,
so
it
sort
of
just
like
depends,
but
I
would
lean
towards
most
of
them
use
projects
and
group
structure,
because
that
also
controls
access.
So
I
think
eventually
we
want
to
solve
for
that
with
how
you
kind
of
can
roll
work
items
across
different
groups
and
projects
and
have
them
show
up
in
multiple
places.
If
you
need
to
so
we're
we're
exploring
that.
C
F
Yeah
cool
holly
that
looks
awesome.
It's
I
think
it's
also
the
first
like
mobile
first
mock
that
I've
seen
at
gitlab,
which
is
cool.
So
it's
nice
to
like
see
that
I
just
mentioned
so
on
the
on
the
back
end
stuff,
there's
been
like
a
ton
of
really
good
conversation,
I'm
still
catching
up
from
being
out,
but
we're
a
little
bit
blocked
by
the
database
team
and
their
feedback.
They
had
some
sort
of
initial.
F
F
The
requirements
work
that
was
already
being
done
because
it
there's
sort
of
an
anti-pattern
at
glab,
around
single
table
inheritance
and
what
we're
doing
is
not
really
like
true
single
table
inheritance,
but
they
do
have
some
valid
concerns
that,
like
we're
intending
to
make
a
table
larger
in
a
time
when
we're
trying
to
make
tables
smaller
and
organizationally,
and
things
like
that,
so
I
set
up
a
sync
with
craig
just
to
kind
of
who's
the
em
on
the
database.
F
E
Could
be
actually,
I
don't
know
for
sure,
though
yeah.
F
I'm
not
I'm
not
certain.
I
didn't
have
time
to
look,
but
but
basically
just
to
get
him
caught
up
on
what
we're
doing,
give
him
a
high
level
overview
and
then
sort
of
like
get
on
the
same
page
that
we
have,
because
what
we're
doing
is
a
relatively
significant
database
architecture
set
of
decisions.
It's
going
to
be
important
for
us
as
we
go
forward
to
have
kind
of
like
expedient
back
and
forth
with
them
on.
F
F
You
know
combustion
because
we
didn't
plan
ahead
with
the
sharding
work
and
we
end
up
wasting
a
bunch
of
time
so
so
yeah
I'll,
let
you
know
how
that
goes.
I
think
there's
also
database
office
hours
which
tomorrow,
which
alexandria
has
brought
up
this
work
previously
there
and
then
also
added
a
note
for
tomorrow.
F
If
we
don't
get,
you
know
if
it
doesn't
get
resolved
between
between
now
and
then
and
yeah
john,
I
saw
you
being
a
time
zone
cop,
as
if
time
zones
aren't
difficult
enough
without
you
sort
of
correcting
me
on
no
I'm
just
kidding.
I
like
first
wrote,
4
30
my
time
then
I
was
like.
Oh
that's,
not
helpful,
then
I
wrote
est
and
then
it's
like
really.
F
It
should
just
be
the
utc
time,
so
so
yeah
any
questions
or
anything
that
if
you
want
there's
a,
I
can
link
the
agenda
here.
Let
me
find
it
if
you
have
things
you
want
me
to
bring
up
with
gregor
or
add
to
that
discussion.
I'm
happy
to
be
the
the
conduit
there.
E
Just
that,
like
I'm
kind
of
split
on
this,
like
I'm,
not
gonna,
get
into
a
big
philosophical
discussion
about
about
this
like
but
like.
If,
if
we
added
all
the
other
types
at
the
minute
like
epics
and
incidents,
it
wouldn't
come
close
to
the.
F
E
I
don't
think
we
would
choose
to
charge
that
table
by
type
my
opinion
that
obviously
could
change,
and
we
would
hope
that
it
would
change,
because
we
would
hope
that
people
would
take
up
test
cases
and
create
you
know,
millions
of
them
and
so
on,
but
just
as
it
is
at
the
minute
like
and
as
far
as
I'm
aware,
like
the
sharding
work
is
starting
with
the
ci
builds
table,
which
is
like
40
of
the
database
currently
and
that's
going
to
be
a
vertical
like
a
completely
separate
logical
database
and
then
we're
going
to
go
and
like
shared
horizontally,
probably
by
namespace
or
something
so,
I'm
not
sure
what
we
really
get
by
not
by
not
like
by
not
moving
everything
into
one
table,
especially
especially
just
because
in
most
cases
like
single
table.
E
D
Yeah,
I
think
more.
The
concern
is
about
how
further
down
the
line
we're
going
to
extend
the
issues
table,
including
new
types,
even
the
system
types
like
feature
or
whatnot,
and
then
also
the
customer
types
right
all
those
go
also
in
the
issues
table
or
we'll
create
a
one-to-one
copy
of
this
table,
but
just
use
that,
for
instance,
for
the
custom
types
right
that's
another
way.
I
guess
we
can
limit
the
size
of
a
single
table,
which
is
one
of
the
concerns.
D
I
guess
so
that's
probably
another
way
to
go
but
yeah
I
like
as
of
right
now.
I
don't
think
we
should
have
a
stopper
on
this,
but
because
the
question
is
not
really,
what
do
we
do
right
now,
but,
but
rather
how
do
we
make
it
so
that
we
don't
get
stuck
in
next
six
or
months
or
a
year,
or
something
like
that.
F
Yeah-
and
I
was
also
gonna-
I
was
gonna-
ask
craig
like
how
are
they
dealing
with
other?
I'm
sure
that,
like
every
team
has
to
be
thinking
about
this
to
some
extent
and
like
I'm
sure
that
they've
already
come
into
places
where
they've
had
discussions
about
like
how
sharding
is
going
to
impact,
you
know
future
future
development.
We
also
have
this
decomposition
discussions
happening
on
like
what
we
need
to
do
to
make
sure
that
all
works
properly,
so
I'll
just
get
his
perspective
on
that
and
I'll
update
y'all.
F
If
there's
anything
important
out
of
that,
the
other
thing
was
just
quickly
holly
we
could
use
your
eyeballs
on
this
delayed
deletion.
Merge
request
it's
kind
of
a
s1
piece
of
functionality,
so
there's
just
a
ux
question
in
there
for
you.
If
you
can
review
that.
B
F
E
Yeah
cool
yeah,
I'm
gonna,
try
and
set
up
a
chat
with
andrew
who's.
You
know,
I
think,
you've
probably
seen
the
the
thread
in
slack
by
now,
but
he's
based
in
australia,
and
it's
really
really
hard
to
get
a
time
that
suits
particularly
like
members
of
oh
europeans
and
americans
and
australians,
it's
just
there,
there's
no
part
of
the
of
the
day
that
really
suits
everybody.
So
it's
up
to
you.
E
I'm
gonna
continue
to
talk
to
andrew
he's
talking
about
maybe
moving
it
to
like
his
morning
or
something
before
he
gets
the
kids
ready
or
whatever,
but
he
tends
to
work
at
night
after
he's
done
a
day's
work.
He
works
on.
Gitlab
looks
amazing.
Alternatively,
like
I
think,
gabe
wants
to
talk
to
lee
so
whatever
way
you
want
to
split
it
like,
I
can
talk
to
andrew
as
that.
So
it's
my
time
and
then
leaves
in
in
the
uk
like
so
it
would
be
just
the
same
as
myself.
E
He
might
be
able
to
join
a
call.
You
know
in
his
evening
and
your
your
day
time,
if
a
couple
of
you
wanted
to
talk
to
him
but
they're,
two
like
really
prolific
contributors,
lisa
on
the
core
team
and
I
think
andrew's,
maybe
interested
in
joining
the
core
teammates.
Maybe
maybe
not
I
don't
know.
Maybe
I
just
made
that
up
but
yeah
it'd
be
good
if
we
could
just
talk
to
them
and
talk
to
them
about
the
kind
of
experience
of
making
contributions
and
what
we
can
do
from
our
side.
E
Yeah
just
make
it
better
improve,
take
on
board
their
decisions
and
yeah.
We
also
have
like
you
know
that
thing
in
the
handbook
that
says
that
contributors
like
don't
need
an
okay
from
the
pm
to
do
something.
They
can
just
cut
the
improvement,
and
you
know
if
it's
if
it's
a
valid
improvement,
we
ship
it.
So
that
does
raise
a
few
questions.
I
guess
like
whose
approval
do
they
need
and
why
are
their
mrs
being
blocked
as
they
are
at
the
minute,
so
cool
yeah,
I'll
post
the
times
in
slack,
and
you
can.
F
I
can
verbalize
for
gabe's
stuff.
He
wanted
to
follow
up
on
that.
Like
dri
and
john,
I
was
going
to
ask
you
because
we
had
talked
about
it,
but
then
I
was
out
and
alex
has
sort
of
emerged,
so
is
there,
like
is
alexandria,
sort
of
officially
that's
weird
to
talk
about
he's
sitting
here,
but.
E
Yeah
alex-
and
I
spoke
last
week-
this
is
a
classic
case
of
emergent
behavior
alexandria.
You
created
the
issue
and
yeah.
Well,
look
it's
like
this,
like
alex.
If
you
take
care
of
the
architectural
blueprint
yan's
on
the
poc
for
the
group
projects,
consolidation,
so
he's
going
to
stay
looped
in
on
this
work
because
that'll
obviously
affect
you
know
where
issues
end
up
so
there's
two
pocs
there
going
on
at
the
minute.
One
is
take
epics
to
the
project
level.
E
E
I
don't
personally
think
it's
going
to
affect
it,
because
they're
going
to
create
this
new
namespace
thing
and
they'll
still
be
at
the
project
level
and
so
on
right.
So
I
don't
think
it's
going
to
make
much
difference,
but
if
it
does
happen
to
jan
I'll
be
looked
in
and
then
if
you
could
take
care
of
the
just
steer
the
architecture
blueprint,
you
don't
have
to
be
responsible
for
asking
all
the
questions
just
making
the
final.
F
A
F
But
yeah,
I
think
important
to
remember-
and
this
is
probably
unlike
most
other
dri
type
relationships-
is
that
the
entire
team
is
ostensibly
working
on
this,
for
several
milestones
so,
like
don't
hesitate
to
ask
other
people
for
help
and
questions,
and
things
like
that.
So
it's
good
to
have
a
dri
and
decision
maker
and
you
should
feel
empowered
to
do
that.
But
you
know
don't
don't
feel
like
it's
the
burden
entirely
resting
on
on
your
shoulders
either.
D
Yeah
like
this
is
mainly
blocked
right
now
on
this
database.
Approval
thing-
and
I
guess
we'll
be
working
on
this
in
chunks
sort
of
will
have
the
partly
the
blueprints
regarding
the
issues
and
issue
types
and
then
that
will
be
evolved
into
custom
issue
types
and
custom
fields
and
and
so
on
and
so
forth.
D
I
don't
think
we'll
have
it
all
in
one
go
and
I
don't
think
we
it
all
in
one
go
because
there
are
quite
some
questions
to
be
asked
and
addressed,
but
at
least
laying
out
the
lines
along
which
we're
thinking
through
and
doing
stuff
so
but
yeah.
The
main
problem
right
now
with
really
starting
this
blueprint
is:
can
we
move
on
with
issues
table
usually
an
issue
stable
as
a
single
table.
E
Yeah
and
there's
we're
talking
about
an
actual
architecture,
blueprint
there's
a
whole
process
around
that
you
have
to
get
a
a
sponsor
who's.
I
think
staff
plus
sponsor
and
so
on,
for
it,
if
possible,
I'd
like
to
avoid
that,
because
I
don't
think
it's
necessary
for
something:
that's
almost
entirely
application
based.
E
It's
not
you
know
we're
not
bringing
in
a
new
framework
or
not
kind
of
you
know,
trying
to
you
know
whatever
like
set
the
foundations
of
a
new
api
or
something,
but
just
trying
to
answer
difficult
questions
about
a
a
piece
of
application.
Work
that
we're
trying
to
do
so.
D
E
If
that
means
like,
if
that
means
a
separate
page
in
the
handbook
where
we
had
the
decisions
to
just
make
a
bullet
list,
I
don't
mind
but
the
but
I'd
like
to
like
not
go
down
the
road
about
and
process,
especially
as
they're
like
it's
defined
that
it's
going
to
take.
I
think
a
certain
number
of
milestones
and
so
on,
and
it
just
seems
like
a
lot
of
overhead,
for
what
we're
trying
to
do.
A
D
E
I
think
when
we,
the
architecture
blueprint
process
wasn't
around
when
we
brought
in
websockets,
but
I
mean
we
did
something
pretty
similar,
but
without
the
process
just
creating
a
design
dock
that
linked
out
to
where
all
the
decisions
were
made,
because
the
thing
that
will
happen
is
like,
if
you're
answering
a
question
now
about
why
we
reused
the
issues
table
and
you're
defending
that
decision
now,
like
you'll,
have
to
defend
it
again
in
three
months
when
somebody
else
comes
on
and
says
like,
why
was
this
table
used
and
you
know
can
seem
counterintuitive,
but
you
know
it's
the
same
thing.
E
Why
did
we
use
action
cable
when
it's
so
high
memory?
You
have
to
go
back
and
say:
well,
actually
we
reasoned
it
out.
Then
we
we
looked
at
all
the
alternatives
and
there
are
multiple
reasons
why
we
didn't
and
so
on,
and
you
can
point
to
the
decision
and
they
can
self-serve.
So
you
don't
end
up.
You
know
you
know
justifying
the
same
decision,
but
also
like
explain
multiple
times
and
then,
like
potentially
down
the
line.
E
You
have
hindsight
bias
where
you
think
you
should
use
something
else,
but
you,
you
kind
of
had
the
information
at
the
time.
The
information
we
have
right
now
is
what
we
have
for,
whether
we
should
use
the
issues
table
or
not,
maybe
six
months
in
to
shard
in
the
database.
Maybe
it's
a
bad
idea,
but
for
what
we
have
now
like,
it
seems
like
the
right
thing,
in
my
opinion
like,
but
the
architecture
blueprint
might
find
something
different.
B
I
did
play
around
with
labels
in
the
work
item
mobile
view,
but
I'll
just
share
it
in
black
when
we
can
catch
up
facing.