►
From YouTube: Plan Weekly Meeting 2021-10-27
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
B
B
So,
as
you
can
see,
we
have
a
new
route
called
work
items.
Currently
this
goes
under
the
projects.
As
soon
as
we
have
workspaces,
this
application
can
be
moved
under
the
workspaces
freely
because
it
uses
pure
router.
So
not
a
big
work
on
the
front
end
on
backend.
We
will
only
need
to
change
the
controller
and
that's
it
and
what
it
does
it
handles
the
work
item
route
completely.
So
we
have
a
wild
card
for
this
part
which
your
router
will
be
handling.
B
Currently,
when
we
have
an
id
here,
it
will
be
taking
this
as
work
item.
Details.
Currently
work
item
only
has
title
with
a
proper
study.
We
will
also
add
a
few
routes
here,
probably
for
create,
it
will
be
work,
items
create
again
handled
by
the
router,
so
we
don't
need
to
take
this
in
the
ruby
controller.
B
This
should
be
completely
fine
on
the
front
end.
It
implements
the
schema
that
we
discussed
on
the
engineering
discussion,
and
this
schema
includes
a
work
item,
connection
type
that
implements
our
work
item,
widget,
edge,
work,
item,
widgets
and
page
info
and
currently
again
what
we
have
for
the
query.
Here
we
are
fetching
the
list
of.
We
are
fetching
the
work
item
by
id,
not
fetching
the
list
of
work
items
and
every
single
work
item
can
have
an
array
of
widgets.
B
B
Let's
see
if
we
have
a
widget
type
title
and
if
we
do,
we
are
rendering
this,
which
is
a
title
widget
placeholder.
So
this
is
basically
it
for
now
and
next
iteration.
We
will
try
to
create
the
work
item
I
guess
with
which
will
add
the
work
item
with
invitation
to
this
list
again.
This
will
require
some
review
from
the
backend
on
the
mutation
because
we
will
be
adding
it
to
the
schema.
Even
so
it's
there
is
no
real
backend
implementation
yep.
Something
like
this.
A
C
Currently,
we
don't
do
any
back-end
calls
right
any
graphic
card.
No,
no!
No!
No.
Currently,
we
are.
B
C
B
C
Yeah,
because
that's
not
that's
something
that
we
don't
have
on
the
back
end
for
sure
returning
the
list
of
the
widgets,
so
that
will
be
nice
to
be
to
track
because,
like
we
were
stating
a
few
times
that
a
lot
of
the
things
we
have
on
the
back
end.
This
is
one
of
those
that
we
don't
so
it'd
be
nice
to
be
tracking
that
so
cool
awesome.
A
Yeah,
so
it's
using
mock
data
at
the
minute.
I
understand
like
do
you
envision,
that,
like
you'll,
continue
to
work
eventually
against
the
issues
api
until
we've
started
work
on
a
work
items
api
specifically,
or
are
we
kind
of
going
to
work
from
mock
data
on
the
assumption
that
they'll
be
very
different
in
the
future?.
B
To
me,
it
seems
that
it's
much
easier
to
work
on
the
mocked
schema
right
now,
because
widget
implementation
is
different.
We
have
a
hash
on
issue,
so
we're
fetching
assignees
now
the
properties
as
a
hash,
and
here
we
are
fetching
them
as
a
list
and
also
it's
super
nice
to
have
backend
validation
on
every
single
step.
We're
taking
on
this
schema,
so
we
will
be
opinion
and
we
will
be
in
vacant
engineers.
B
Everyone
is
aware
about
it
and
if
something
creates
more
questions,
we
can
go
for
engineering
discussion
meeting
like
we
have
discuss
it
and
have
it.
If
we
go
with
issue,
there
will
be
probably
lots
of
refactoring
work
in
the
future
for
work
items,
so
it's
easier
just
to
go
with
front-end
implementation
and
also
it's
easier
to
create
issues.
So
we
implemented
something
on
the
front
end.
We
create
a
mirror
integration
issue
that
back-end
can
handle
in
the
future.
So
everything
every
single
change
on
the
front
of
this
documented
in
these
issues.
C
Yeah,
I
I
vote
with
starting
a
work
items
graphql
endpoints,
rather
than
extending
the
issues
because,
like
a
lot
of
it,
will
be
a
copy
paste
code
but
also
like
we
don't
have
to
maintain
all
these
backwards
compatibility
with
what
issues
already
offers
and
and
all
that
like
weird
stuff
right,
like
where
you're
kind
of
afraid
of
changing
something
to
not
break
it
or
things
like
that,
so
like
starting,
fresh
copying
over
whatever,
whatever
needs
to
be
copied
over
and
then
eventually
deprecating
the
issues
endpoint.
I
think
I'm
leaning
towards
that.
D
Yeah,
I
agree
with
alexandria
that
it
might
be
safer
or
easier
to
start
with
a
new
endpoint
because
of
backwards
compatibility.
But
maybe
we
might
I'm
not
sure
if
we
have
discussed
this
in
a
technical
issue
or
technical
implementation
issue
or
not,
but
it
might
be
better
to
point
it
out
there.
So
everybody
is
on
the
same
page.
D
Regarding
the
demo,
I
had
just
a
minor
question.
It
seems
that
the
title
is
widgetized,
so
I
was
curious
if
people
separate
widget
for
title,
because
I
thought
that
title
itself
would
be
basically
mandatory
for
each
type,
but
it's
just
a
minor
detail,
because
I
think
that
at
this
point
is
for
demo
purposes
mainly.
B
Yeah,
it's
mostly
for
demo
purposes.
I've
been
reading
the
discussion,
but
unfortunately
we
don't
have
a
defined
decision
for
the
title.
If
it's
required
or
not
again,
the
change
will
be
super
minor.
We
will
just
add
a
title
property
to
the
work
item
type
itself
instead
of
widget
and
change
the
end
logic
so
yeah.
This
is
mostly
for
demo
that
how
we
define
the
widget
and
how
we
show
it
on
the
content.
E
It's
my
understanding
that
the
title
is
required
kristin.
Can
you
comment
on
that
as
well.
B
B
G
Thank
you
for
demoing,
sorry,
oh,
we
we
had
that
discussion
in
an
issue
somewhere
and
it
was
actually
decided
the
other
way
around.
So,
let's
just
that's
fine
if
we
want
to
switch
it
to
being
required
for
everywhere,
but
we
should.
We
should
document
that
in
the
issue
where
that
decision
was
made
the
other
way.
Okay,
let's.
F
Pull
that
out
in
a
decision
in
the
agenda
too
up
at
the
top
today,
just
in
this
agenda.
C
Even
if
it's
required
like,
if
it's
required
and
if
it's
a
widget,
I
don't
see
the
downside
of
keeping
it
as
a
widget
like
you
just
have
it
always
there
kind
of
thing
I
I
like.
I
don't
see
why
we'd
want
to
to
be
pulled
out
of
a
widget
per
se.
We
don't
know
eventually
like
yeah
anyway,
I'm
just
saying
like
I
don't.
I
don't
see
big
downsides
to
having
it
as
a
widget,
but
I'm
I'm
not
on
the
front
end.
So
maybe
there
are.
G
I
found
the
issue
and
I'm
wrong.
It
wasn't
a
decision
made.
It
was
something
I
made
in
my
head
to
just
treat
it
as
a
widget,
so
we
could
test
out
the
widget
version
of
it.
So
if
we,
whichever
we
we
decide,
let's
just
get
it
documented
in
that
issue,
then
I'll
apply
it
to
the
agenda.
H
Thank
you
natalia
for
the
demo
that
was
it's
awesome
to
like
see
stuff
coming
together,
even
though
it's
you
know
mostly
just
front
end,
it's
still
great
to
see
it
in
in
in
a
browser.
It's
awesome.
B
A
Actually
answered
a
ton
of
questions
for
me
as
well,
just
the
demo
like
how
are
we
going
to
handle
routes?
I
was
never
fully
sure
about
that.
Like
you
know,
are
things
gonna
have
their
own
roots
or
I
should
say
rights
or
whatever?
What,
and
you
know
like
is
the
view
app
going
to
own
all
the
rights
roots
like
it
looks
like
so.
The
apple
kick
in
on
that
work,
items
page
and
everything
will
be
done.
A
A
E
We
have
just
a
standard
core
work
item
creation
flow
outlined
in
the
designs,
but
I
think
that
some
of
the
overlap
between
the
different
types
is
still
being
discussed.
Is
that
correct
kristin
for
me
to
say
that,
like
it's
still
and
I
can
share
the
issue
that
that's
happening
in
in
the
agenda.
F
So
that's
still
in
flux
like
we're,
still
sort
of
deciding
on
the
rollout
plan,
but
that
would
mean
that
the
creation
would
be
a
shared
experience
that
would
be
used
by
all
issue
types.
Essentially.
Does
that
answer
the
question
is
that
what
you
you
meant.
E
Holly
yeah,
it
sounds
like
the
question
is
still
whether
or
not
work
items
are
going
to
be
a
sing
and
correct
me
if
I'm
wrong
john,
because
it's
early-
and
I
may
just
have
misunderstood,
but
it
sounds
like
the
question
is
still
is
a
work
item,
a
thing
in
itself
and
has
its
own
ui
versus
creating
something
as
a
work
item
that
has
a
type
associated
with
it
and
therefore
a
different
ui.
F
F
But
it
is
a
good
thing
to
look
at
and
just
see
kind
of
how
we're
trying
to
get
these
pieces
together
and
then
the
other
goal
of
it
would
be
to
make
each
team
more
autonomous
so
that,
like
product
planning
and
project
management
teams
can
both
feel
like
they
know
kind
of
what
they're
tracking
to
and
trying
the
goals
they're
trying
to
hit
and
how
it
all
comes
together.
A
F
F
And
they're
in
our
road
map
and
our
planned
in
the,
I
guess,
it's
kind
of
the
order
of
operations
but
like
split
split
up
by
teams.
A
Cool
well
sure,
let's
see
you
know,
there's
I
guess
no
rush,
but
it
would
be
nice
also
like
if,
if
we're
gonna
build
this
sort
of
work
items
api
layer
over
the
issues
table,
but
we
also
need
like
the
widgets
side,
which
is
completely
different
right.
It's
like
we
need
to
redesign
that
and
stuff.
It
might
be
good
to.
A
F
It's
going
to
require
more
communication
and
more
and
async
communication
on
the
issues
and
potentially
more
sync,
just
to
maybe
align
some
of
those
things,
but
the
more
we
can
do
to
kind
of
unblock
and
get
that
ready
for
the
front
end.
The
better.
A
Maybe
we
could
put
immediate
demands
like
in
the
work
items
channel
right
so
that
like
like,
not
to
make
it
too
noisy
but
like
if
there's
a
chance
to
get
a
jump
on
something
in
the
next
milestone
like
put
it
in
the
channel,
and
then
you
and
I
and
like
jake
and
gabe,
will
also
be
aware
of
that
as
well.
You
know,
I
think,
that's
the
problem.
The
thing
I'm
afraid
of
is
like
split
brain.
Where
you
know
the
project
management
team,
don't
know
what
we're
working
on
and
vice
versa.
F
Yeah,
I
think
one
of
the
hard
parts
for
me
even
is
just
how
many
channels
we
have,
though,
so
because
I
miss
things
that
that
aren't
in,
like
a
group
channel
or
one
single
source
of
truth.
But
I
agree
while
we're
doing
this,
especially,
we
need
to
have
a
single
point
of
contact
where
the
whole
team
can
see
it.
A
G
To
yeah,
seeing
how
the
user,
how
user
would
create
a
work
item
the
next
one
we're
going
to
take
on
that
natalie's
working
on
is
the
creation
of
feature
which
I
linked
there.
So,
hopefully
you
know
once
we
start
working
on
that,
we'll
be
able
to
visualize
it.
Similarly
to
how
we
can
now
visualize
the
demo
that
natalia
did.
G
A
All
right
all
right
yeah-
this
is
just
an
fyi
anyway,
like
we're,
trying
to
go
through
the
whole
backlog
of
security
issues
in
plan
and
group
them
or
close
them
or
prioritize
them.
So
if
you
don't
know,
create
and
manage
are
going
through,
I'm
not
sure
whether
it's
a
headcount
reset
or
what
but
there's
a
bit
of
a
focus
on
security
issues
in
those
two
stages-
and
this
is
just
a
chance
for
us
to
get
ahead
of
it.
We
have
roughly
50
security
issues,
but
some
of
them
are
very
old.
A
Some
of
them
are
security
features
which
maybe
aren't
such
a
priority
to
fix,
but
it
would
be
good
to
know
like
which
ones
are
related
to
each
other
could
be
clustered
together
and
solved
in
one
go
or
like
have
a
very
similar
root
cause
that
could
be
solved
in
sequence
by
one
or
two
people,
so
if
you're
so
inclined
to
like.
Please
take
a
look
at
the
issue.
A
There's
instructions
in
the
issue
for
a
while
today,
it's
very,
very
simple:
we
just
like
it's
a
chance
to
go
through
the
whole
backlog
and
kind
of
figure
out
what
to
do
or
what
next
steps
are
for
each
issue
and
yeah
feel
free
to
edit
the
description
if
you
want,
if
you
see
things
that
are
related
to
each
other,
don't
ask
just
go
ahead
and
group
them
and
put
them
in
the
description.
A
D
H
Thank
you
and
john.
It
may
be
actually
good
for
us
to
pull
out
any
of
them
that
a
republican
can
be
fixed
in
that
normal
workflow
just
so,
because
that's
a
little
bit
a
little
bit
less
arduous
to
get
through
yeah.
So
I'll
keep
an
eye
out
for
that.
Thanks.
A
For
that
tip,
yeah
also
castell,
there's
some
stuff
in
there
that,
like
there
are
issues
that
were.
We
would
have
considered
security
issues
like
over
a
year
ago,
but
we
would
know
no
longer
really
like.
A
For
example,
you
can
tell
how
many
confidential
epics
a
group
has,
even
if
you're,
not
qualified,
to
view
all
epics
by
subtracting
the
number
that
you
see
from
the
number
of
the
kind
right
and
we
decided
a
while
ago
that
we
don't
really
care
about
that,
and
the
only
way
we
could
solve
the
security
issue
is
to
change
that
behavior.
So
are
we
okay
to
go
ahead
and
close
issues
like
that
immediately
tag
you
and
if
you
want,
you
can
reopen
them.
D
We
did
we
decided
that
the
impact
as
a
security
issue
is
very
small,
since
it
doesn't
don't
get
a
lot
of
information
by
just
knowing
how
many,
by
just
knowing
the
number
with
that
without
knowing
the
content
but
yeah
I
mean
I'll
gonna,
take
a
look
and
see
if
there
is
anything
that
can
be
closed
from
that
list
or,
if
face
anything
that
can
be
fixed
in
canonical.
So
I'll,
add
comments.
Where
is
the
case
so
that
you
can
make
make
it
easier
for
you
guys.
A
A
H
I'll
just
give
a
quick
shout
out,
so
I
didn't
type
it
in
here,
but
we
are
like
painfully
close
to
having
zero
open
infradev
issues
in
plan,
which
is
awesome.
It
was
a
pretty
significant
backlog
that
we
had
a
few
months
ago,
and
so
lots
of
folks
have
you
know
dedicated
their
time
to
that.
So
thanks
everyone,
but
I
think
one
will
be
two
will
be
closed
out.
H
There's
three
remaining
two
will
be
closed
out
today
or
within
the
next
day,
and
then
there's
one
more
that
we
should
finish
this
milestone
so
that'll
be
that'll,
be
a
relief
from
an
em
perspective.