►
From YouTube: Plan Weekly 2021-11-24
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).
B
Awesome:
okay
plan
weekly
meeting
24th
of
november
for
most
people,
I
think
cool
who's
got
the
first
item
marching.
C
Hi,
this
is
going
to
be
weird.
My
computer
is
not
recognizing
my
external
camera,
so
I'm
going
to
be
looking
here
while
reading
from
here,
so
I
finally
got
to
look
looking
at
a
doc
page
that
lists
everything
that
appears
on
an
issue.
C
All
the
different
parts
and
the
team
has
long
decided
to
get
rid
of
it,
because
it's
just
technical
that
you
know
piles
of
tag
that
with
with
the
screenshot
and
numbers.
So
I'm
moving
out
different
things
to
specific
pages,
and
I
found
a
thing
that
said
that
you
can
send
an
email
to
an
issue
that
there's
a
button
visible
to
guest
users,
and
I
couldn't
find
it
in
jdk.
C
D
C
E
B
D
Yeah,
that's
that's
correct,
yeah,
like
it's
the
issue,
it's
titled
issue,
email
and
then
you
have
kind
of
the
project
name
appended
to
with.
Let's
see
trying
to
find
an
issue
to
use
in
his
example,
all
right,
I'll,
dig
into
and
I'll
try
to
find
the
change
we
made
to
see
if
it
would
have
caused
this.
I
don't
know.
I
just
know
that
we
made
some
changes
to
these
issue.
Email
addresses
within
the
last
year,
so
I'll
find
that
and
see.
B
Cool
yeah
thanks
yeah,
so
something
that's
come
up
like
it's
top
of
mind.
For
me
at
the
minute
is
that
you
know
we're
starting
to
plan
separately
as
different
groups.
We
may
retrospect
separately
at
some
point
as
well,
so
I'm
interested
to
know
kind
of
what's
coming
up
ahead,
like
two
three
four
milestones
ahead
and
have
a
kind
of
continuous
design
process
for
that.
B
B
This
belongs
in
project
management,
but
my
attitude
would
be
like
whoever
needs.
The
thing
first
should
build
the
thing
first
same
with
parenting
as
well,
because
you
know
you
kind
of
create
the
first
implementation
and
then
the
team
that's
responsible
either
maintains
that
or
generalizes
it
or
improves
upon
it.
So
there's
a
discussion
there
that
I've
opened
like
an
issue
for
discussion
of
this.
The
idea
of
the
issue
is
to
capture
decisions
around
the
design
of
an
api
for
work
items.
B
I
know
we've
like
discussed
it
a
little
bit
in
the
overall
work
items
document
the
the
engineering
discussion
we've
also
touched
on
it
in
an
mr
and
natalya.
I
think
you
designed
some
of
it
for
like
what
the
front-end
would
expect
from
a
work
items
api
and
so
because
we're
doing
it
a
few
different
places.
I
want
to
get
it
all
in
one
place
and
it
seems
from
the
discussion.
That's
there
already,
that
both
teams
actually
need
this
within
a
matter
of
a
couple
of
milestones.
B
B
F
B
It
seems
like
we
could
start
with
the
requirements
of
the
front-end
of
our
own
front-end
client.
B
I
would
like
to
design
the
api
from
the
point
of
view
that
it's
a
product
on
its
own,
that
people
outside
we're
building
it
as
an
api
and
whatever
we
build,
especially
in
graphql,
it's
very
costly
to
change.
So
we
want
to
build
something
we
can
maintain
and
if
that
means
building
it
more
slowly,
then
that's
fine.
B
Yeah,
I
can't
think
of
the
other.
The
other
thing
I
was
thinking
was
that,
like
maybe
we
should
take
the
attitude
that
no
matter
what
reason
we're
building
it
for
we
build
everything
to
be
generalizable
for
all
work
items.
So
if
you're
building
descriptions,
a
descriptions
widget
for
task
work
items,
you
should
build
it
for
all
work
items
and
so
on.
D
Yeah
so
john,
my
I
guess,
like
the
comment
I
put
there
and
rereading
it
now,
it's
not
super
clear
what
I
was
talking
about,
but
I
was
thinking
like
with
the
we
we
know
on
the
project
management
side.
We
have
to
approach
doing
tasks,
and
we
know
like
the
prototype
that
natalia
has
showed
off,
is
includes,
like
create
work,
item
mutation,
that
we
will
need
to
create
a
task
right
and
so,
like
kind
of
a
bare
bones
like
minimum
thing
that
we
need
to
create
a
task.
D
D
Is
it
a
mistake,
I
guess
to
sort
of
dive
in
and
create
a
create
work
item
mutation?
That's
that
effectively
does
the
same
thing
as
create
issue,
but
with
fewer
fields
like
are
we
I
yeah
or
do
we
need
to
sort
of
like
step
back
a
bit
and
kind
of
do
a
more
like
abstract
design
and
then
move
into
doing
the
concrete
thing.
E
I'd
like
us
to
move
into
into
doing
stuff,
but
the
only
concern
that
I
have
is
we
need
to
add
documentation
and
also
around
the
thing
that
some
endpoint
or
some
graphql
thing
is
an
alpha.
So
it's
not
recommended
to
being
used
by
the
customers,
because
otherwise
I
don't
like
we
will
be
modifying
this
stuff,
a
lot
we
are
adding.
We
don't
exactly
know
how
to
handle
shape
in
the
future.
So
that's
really
something
that
is
usable
for
us
to
implement
the
ui
around
the
work
items.
E
You
are
all
work
items
and
all
that
stuff,
so
it'll
be
nice
to
mark
it
as
just
don't
use
it
or
something
like
an
internal
api
that
we
can
then
make
public
at
a
point
where
we
are
certain
that
some
things
will
not
change
as
frequently
as
we
know,
they
will
change
right
now
because,
like
at
least
mine,
I've
I've
been
disconnected
a
bit
from
the
work
items,
but
I
think
we're
still
evaluating
things.
We're
still
discussing
stuff,
so
it'll
be
nice.
E
F
I
agree
with
alexandra
and
on
top
of
this,
one
mutation
is
essentially
doing
the
same.
It's
not
returning
the
same,
not
in
the
same
shape,
at
least
because
we
still
want
to
stick
to
the
widget
architecture
and
create
issue
mutation
returns
as
an
object,
and
we
really
want
to
have
an
array
of
widgets
and
modify
and
create
issue
for
this.
It's
like
it's
not
possible
because
we're
consuming
this
mutation
a
lot
in
the
current
front
end.
F
B
So
is
there
a
reason
why
we
can't
just
design
it
that
way
up
front,
because
so
that's
what
I
was
thinking,
but
the
thing
about
requirements
is
that
they're
so
simple,
the
widgets
are
going
to
be
a
widget
for
title,
a
widget
for
description
things.
We
can
hard
code
in
the
first
instance
what
else
like
a
widget
for
state,
that's
slightly
different
from
issue
state,
but
it's
otherwise
pretty
much
identical
and
the
only
one
is
like
last
test
report
state
which
is
pretty
unique
to
requirements.
B
But
the
thing
is
like
that
we
want
to.
We
need
to
send
people
when
we
deprecate
the
requirements
api.
We
need
to
send
people
somewhere
and
we
can't
send
them
to
an
api
that
a
work
items
api,
that's
in
alpha
and
that's
not
stable.
So
I'm
wondering
is
there
somewhere
in
between
like.
Is
there
a
stable
first
state
of
the
api
right
I
mean
it
seems
like
a
two-way
door,
because
it's
an
array
of
widgets
anyway,
so
you're
not
changing
the
schema.
G
B
Well,
that's
three
engineers
tell
me
no
so
I'll
take
it
mark.
Maybe
we
want
to
push
out
the
deprecation
of
the
requirements,
api
and
just
forget
about
it
for
a
while,
then
we'll
support
it
indefinitely
for
now.
A
Sounds
like
it,
I
think.
That's
that's
the
plan,
if
you
hear
otherwise,
then
we
revisit,
but
I
think
for
now
it's
best
follow
the
the
lead
of
what
people
are
saying
here
so
yeah.
No,
I'm
good
with
that.
Thanks
john.
E
I
think
we
can
deprecate
the
requirements
api
once
we
have
the
the
task
in
place
and
and
workable,
if
that
makes
sense,
because
this
is
what's
going
to
allow
us
to
test
things
to
make
it
work
and
then
we
will
build
the
task
api
so
that
it
supports
multiple
work
item
types
and
then,
basically,
what
that
means
is.
We
will
redirect
the
requirements
api
into
this
task,
which
is
going
to
be
work
items
api
right.
The
thing
is
that
we
cannot
do
it
from
the
very
beginning
with
the
requirements.
E
We
cannot
point
it
to
the
new
api
that
we
are
developing,
because
it's
going
to
change
a
lot,
so
it's
going
to
just
break
the
requirements
api.
If
that
makes
sense
right,
so
we
need.
We
need
to
maintain
that
old
way
of
accessing
the
requirements
for
a
little
bit
longer
until
we,
we
kind
of,
are
confident
to
release
this
and
say.
Okay
from
now
on,
we
are
going
to
maintain
the
way
that
we
design
the
work
items.
Api.
B
F
Create
feature
feature
work
item
whatever
like
the
first
iteration
is
already
merged,
so
we
can
definitely
close
two
first
issues
and
I
asked
gabe
to
create
a
specific
new
one
for
the
task,
at
least
for
the
view
same,
I
believe,
for
create
because
they
they
just
updated
the
old
issues,
and
it's
not
really
correct,
because
we
already
implemented
the
code
for
these
two
issues.
F
B
F
Item
we
already
have
create,
we
will
be
creating
work
item.
This
is
basically
it,
but
we
will
probably
need
extend
the
beta,
create
work
item
mutation
because,
at
least
for
the
first
designs
for
the
task,
we
will
need
at
least
a
description.
Currently
we
only
have
titles
so
just
a
little
modification
on
our
side,
but
essentially
we
will
be
using
the
same,
create
work
item.
F
E
Let's,
let's,
let's:
let's:
let's
use
that
generic
and
then
somehow
note
that
this
is
going
to
be
first
for
tasks
so
that
we
don't
have
multiple
issues
like
can
we
I
don't
know
what
the
issue
is,
but
let's
call
it
graphql
for
work
items
or
whatever
and
then,
as
a
task
say.
First
is
going
to
be
task.
Work
item
type.
G
One
a
note
about
the
experimental
api
also.
I
think
that
the
api
should
be
experimental.
I
didn't
mean
we
should
wait
for
tasks,
implementation
or
I
don't
see
a
problem.
I
mean
the
proposal
to
start
with
implementing
we
start
using
work
items
api
for
implementing
requirements,
make
sense
or
I'm
not
sure
we
have
to
put
another
roadblock
of
waiting
for
tasks
which
are
because
it
was
already
two
years
ago
when
we
were
there
was
supposed
to
be.
A
sign
is
widget
or
something
like
that.
B
So
that's
why
I
created
that
issue
that
I've
linked
at
the
top.
I
thought
it
would
be
good
to
have
the
requirements
for
the
specification
in
one
place,
so
both
teams
could
work
off
it.
So
I
mean
even
if
it's
still
experimental,
but
we
know,
for
example,
natalia
said
there
that
we
need
an
array
of
widgets.
We
don't
want
objects
passed
back
then
we
should
have
that
somewhere
so
that,
like
regardless
of
who
builds
it
first,
we
build
it
that
way.
It
might
not
be.
B
The
final
thing
like
you
know,
the
the
widgets
themselves
may
change
or
whatever,
but
like
it's
decisions
like
that
that
we
can
point
to
like
one
place
and
say
so.
I
don't
know
like
I
can
close
this
issue,
but
if
it's
still
useful
I'd
like
to
keep
it
open,
just
even
to
gather
everything
in
one
place,
all
the
decisions.
E
B
B
Could
deprecate
it
in
14
6,
but
the
earliest?
Well,
if
we
duplicated
in
146
the
earliest,
we
could
remove,
it
would
be
15
0.
E
But,
like
we
mark
this
as
experimental,
we
do
a
breaking
change
that
gets
kind
of
released
to
the
home
premise.
There
is
no
easy
way
to
to
fix
it
right
on
dot
com.
Okay,
we
don't
patch
it
for
on
premise:
it's
more
difficult
if
we
still
keep
the
alternative
of
the
old
way
old
api
for
people
to
do
their
job
and
they
are
aware
that
they
are
using
an
experimental
one.
So
if
that
breaks,
that's
okay
with
them,
then
yeah
we,
we
can
pull
in
not
only
requirements
but
everything
there.
E
This
is
where,
like
the
problem,
is
that
once
you
make
something,
basically
public
and
and
disabled,
the
way
that,
like
you,
give
them
only
one
access
point
right.
That
is
experimental.
That's
not
okay
with
me,
but
if,
if
we
still
keep
the
development
one
and
we're
just
moving
everything
to
the
new
api,
that's
that's.
Okay!.
B
It's
actually
worse
than
that,
like
if
we
ship,
if
we
ship
the
api
and
a
front
end
that
relies
on
it
and
then
we
create
a
breaking
change
in
the
api
and
change
the
front
end
to
match
that
change.
We
would
create
a
multi-version
compatibility
issue
because
people
have
multiple
nodes
in
their
deployments.
We'd
roll
out
that
change
and
would
have
errors,
because
some
nodes
would
have
the
new
back
end
and
some
nodes
would
have
the
old
front
end
and
vice
versa,
and
so
you
have
to
kind
of
roll
it
out
like
that.
B
All
graphql
changes
are
backwards
compatible
at
least
with
our
own
client.
So
yeah,
like
I
said
at
the
beginning,
like
graphql
changes,
are
extremely
costly
because
they're,
not
versions
so
yeah
anyway,.
G
Yeah,
I
wonder
we
would
have
to
remove
the
experimental
flag
or
mold
when
we
remove
or
enable
implementing
this
behind
the
feature
flag.
But
as
long
as
it's
behind
feature
flag,
then
we
can
make
and
changes
whatever
we
need,
but
perhaps
we
should
settle
on
not
experimental
version
of
api
when
we
enable
enable
this
this
by
default.
I
assume.
G
B
Okay,
so
the
verdict
is:
maybe
we
keep
this
issue
open
for
now
and
maybe
I'll
try
and
pull
in
some
of
the
discussion.
That's
already
gone
on
about
the
schema
natalia
that
that
you
need
for
what
you've
built
so
far,
and
at
least
that
can
at
least
if
we
have
nothing
else.
We
have
that
documented
in
this
issue.
C
Sure
but
you're
not
allowed
to
comment
so
yeah,
so
this
is
a
scheduled
reminder
that,
apart
from
the
the
dog
style
guide,
we
also
have
an
a
to
z,
word
list,
which
is
growing
slowly
and
has
guidelines
about
many
specific
things.
C
So
go
ahead,
scroll
through
it
and
if
you
find
something
something
new
or
you
know,
or
you
stop
doing
something
you've
been
doing
or
the
other
way
around.
Let
me
know
so,
for
example,
one
thing
that
that
is
there
is,
if
you,
if
you
look
for
either
reporter
or
maintainer,
it
has
like
a
sentence
that
we
would
want
to
use
when
we
want
to
say
talk
about
the
minimum
permissions
required.
So
we
want
to
use
the
word
role
like
maintain
the
role
report
to
role.
C
But
if
you
forget
just
bookmark
the
page
and
you
know
you'll
be
able
to
refer
it.
Okay,
just
kidding,
you
aren't
allowed
to
comment.
D
It's
a
separate
point,
okay,
so
if
you're,
if,
if
there's
no
comments
on
your,
I'm
still
not
sure,
if
I
can
comment
on
what
you
said,
I
might
be
under
threat
of
violence.
If
I
yes,.
D
D
I
actually
it
just
occurred
to
me
that
I'm
so
I
talked
to
alexandria
about
this
before
I
guess.
There's
this
effort
to
kind
of
classify
how
we
use
storage,
object,
storage
in
gitlab
and
there's
a
google
doc
linked
in
the
top
of
that
issue
that
should
be
available
to
everyone
within
gitlab
that
sort
of
categorizes.
This
broad
category
of
project
and
group
uploads,
which
includes
things
like
images
or
pdfs
or
random
files.
D
It's
just
that
becomes
an
upload
and
then
I
think
some
of
those
like
things
like
the
project,
avatars
get
stored
in
the
file
system
and
then
other
things
become,
I
think,
lfs
objects
or
I'm
not
really
sure
if
that's
like,
if
once
if
it's
an
image
and
once
it's
in
git,
if
it
gets,
becomes
an
lfs
object
or
if
it
can
just
live
in
kit.
Otherwise,
so
I
was
just
kind
of
gonna
generally
ask
for
help
on
this,
especially
have
sort
of
a
holiday
through
the
end
of
the
week,
but
yawn
mainly.
D
You're
here-
and
I
know,
you've
done
a
lot
of
work
with
how
these
things
work.
So
I'm
not
entirely
sure
what
the
end
goal
is
more
than
just
kind
of
having
some
general
like
classification
of
how
these
uploads
are
stored
and
uploaded,
and
to
my
knowledge,
like
the
only
way
to
do
this
is
via
attachment
like
it's
either
attachment
to
a
note
or
attachment
to
a
discussion
but
yeah.
If
anyone
has
ideas
or
thoughts
on
that
be
helpful,.
G
Yeah,
I
will
be
happy
to
take
a
look
after
the
call.
One
thing
I
remember
where
is
the
difference
is
that
there
is
a
difference,
whether
you
upload
something
as
an
attachment,
for
example,
in
a
comment
where
it's
handled
as
sn
upload,
and
there
is
a
difference
if
you
upload
something
as
a
forum
data
in
that
case
it's
handled
by
rail
server
yeah.
So
there
are
two
different
ways
how
uploads
are
handled.
G
D
Okay,
cool
thank
you
and
I'll
try
to
document
what
I've
already
looked
into
as
well.