►
From YouTube: 2022-03-16 Plan Weekly Team Meeting
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
All
right,
cool
plan,
weekly
meeting
16th
of
march,
should
be
16th
of
march.
I
have
the
first
item
awesome.
What
is
it?
Oh
yeah?
So
it's
just
an
update
on
what
we're
going
to
focus
on
in
1410
for
product
planning
back
end,
at
least,
which
will
be
confidential
notes
yeah.
So
eugenia
worked
already
to
break
this
down
and
the
feature
is
actually
pretty
much
already
in
the
code
base.
In
fact,
more
than
we
would
want
is
in
the
code
base.
A
So
most
of
the
challenge
here
is
going
to
be
to
kind
of
get
a
production
ready
so
that
we
can
start
rolling
out
the
feature
flag.
We
like
to
roll
out
the
feature
flag.
You
know
as
soon
as
possible
so
that
we
can
start
testing
it
internally,
because
the
main
risk
with
this
piece
of
work
is
that
they're
not
confidential
in
some
way
that
they're
leaked
through
activity
feeds
or
email,
notifications
or
rss
feeds,
or
some
other
place.
A
We
haven't
thought
about
so
yeah
we've
scheduled
the
technical
kickoff
for
tomorrow,
provided
everyone
can
attend.
Of
course,
I'm
not
going
to
be
there.
It's
in
patrick's
day
so
feel
free
to
move
it.
If
you
can't
make
it
what
else
yeah
so
like
just
just
quickly
on
the
feature,
the
the
idea
is
that
you
can
have
confidential
notes
and
issuables
specifically
issues
on
epics.
We
don't
want
confidential.
Mr
diff
notes
once
you've
made
a
note
confidential.
A
If
there's
a
discussion
underneath
it,
you
can't
make
it
public
anymore,
because
you
would
have
to
then
make
all
the
notes
public
in
that
discussion
item.
So
that
would
be
weird
right
because
you'd
be
making
other
people's
comments
public
anything
else,
yeah.
For
a
note,
that's
in
the
in
a
discussion
probably
doesn't
make
sense
to
make
that
public,
because
the
rest
of
the
context
won't
be
there
either.
A
So
it's
pretty
pretty
limited,
but
pretty
much
meets
like
90
percent
of
what
people
want
the
one
weird
thing
about
it
is
that
currently
in
the
api,
without
respecting
the
feature
flag,
you
can
flip
any
note
to
be
private,
including
mr
diff
notes
and
everything.
I'm
not
sure
why
that's
in
the
api
currently,
but
that's
what
the
rca
anton
finish,
features
was
supposed
to
help
us
find
out.
Okay.
So
that's
confidential
notes,
yeah
and
you
have
the
next
item.
B
Yeah,
I
was
just
wondering
if
we
need
someone
from
front
end
on
the
meeting
tomorrow
to
think
up
about
any
potential
missing
pieces
on
front
hand
side
or,
but
if
we
are
sure
that
front
end
is
already
finished,
it
may
not
be
necessary.
A
Yeah,
so
the
as
far
as
I
understand
it,
most
of
the
front
end
is
completed,
so
the
ability
there's
a
tick
box
when
creating
a
new
comment
to
make
it
confidential.
So
as
far
as
that's
concerned,
it's
completed,
there
might
actually
be
some
work
required
to
remove
that.
I'm
not
sure
we
need
to
really
interrogate
the
feature.
A
little
bit
eugene,
you
might
actually
already
know,
would
be
helpful
to
have
somebody
from
front
end
on
the
call,
though,.
C
C
The
the
top
note
confidentiality,
because
there
is
a
race
condition
when
maybe
a
a
reply
to
that
note
is
being
added
at
the
same
time
and
there
is
no
easy
way
to
ensure
that
you
kind
of
preserve
the
same
settings
so
to
say
to
the
reply
and
to
the
to
the
original
note.
So
so
I
think
there
was
a
kind
of
a
a
problem
to
solve
there,
which
I'm
not
sure
if,
if
it
was
addressed
or
if
it's
still
something
to
be
to
be
paying
attention
to.
A
Yeah,
that
would
still
be
a
problem,
because
the
idea
is
if
the,
if
you're
replying
to
a
note,
that's
private.
Your
reply
will
also
be
private
if
you're
typing
your
reply
and
the
author
of
the
original
note
flips
it
to
be
public,
then
there's
a
risk
condition
there.
Where,
when
you
submit
your
comment,
it
will
be
public
and
you
may
think
it's
going
to
be
private.
The
easiest
way
to
fix
that
would
simply
be
to
make
it
so
they're,
not
toggleable
at
all
in
the
first
iteration.
So
it's
either
private
comment
or
it's
not.
C
I
think
we
can
use
some
locks,
but
it
it
needs
to
be
tested,
because
I
think
I
think
we
have
an
index
on
the
discussion
id
or
something,
and
we
can
find
that
original
node
and
place
a
lock
on
update,
not
allowed
to
update
the
the
original
node.
Basically
in
the
meantime
so
yeah
I
don't
know
I
I
it's
something
to
be.
I
just
just
wanted
to
mention
that
that
may
be
one
of
the
kind
of
bigger
things
to
to
to
see
tougher
things
to
solve
so
to
say,
but
yeah.
D
When
I've
looked
at
other
tools
that
have
this,
you
can't
switch
it
from
private
to
public
and
public
to
private,
like
zendesk
is
the
one
that
comes
to
mind
once
you
define
whether
it's
like
private
or
public,
that's
pretty
much
it,
probably
because
of
edge
cases
and
potential
to
expose
data.
C
A
Let's
make
that
a
requirement,
then
melissa,
if
you
don't
mind,
because
it's
actually
just
easier
to
create,
create
it
that
way.
Anyway,
we
don't
have
to
look
for
the
special
case,
where
the
note
doesn't
have
any
replies.
We
just
make
it
so
that
it's
not
toggleable
at
all.
At
the
end
of
the
day,
it's
not
costing
any
usability
really,
because
if
you
want
to
make
the
note
public,
you
just
copy
it
into
a
public
note
right.
C
There
is
always
the
problem
where
someone
posted
a
note
and
then
says:
well,
it
should
have
not
been,
and
I
want
to
talk
about.
I
guess
you
can
then
sort
of
delete
it,
but
then
you
probably
need
permission
to
delete
the
entire
thread
so
like.
If
you
posted
the
note,
you
didn't
realize
it's,
it's
kind
of
private
sensitive
information,
someone
replied
to
it
and
then
you
don't
have
a
way
to
either
delete
it
or
even
turn
it
as
confidential.
D
Yeah
and
we
could
always
introduce
that
in
a
later
iteration
right,
the
first
duration
could
be.
You
can't
switch
it
and
then
later,
as
we
think,
through
all
the
edge
cases
and
all
the
scenarios,
we
could
introduce
toggling.
E
Okay,
so
I'm
making
sure,
but
I
think
I
get
it
from
the
discussion
when
you're
all
saying
notes,
we
mean
comments
and
threads
right
or
something
more
like
the
the
activity,
notes,
comments
and
threads
comments.
E
E
D
Yeah
the
next
item
and
it's
more
of
discussions
about
requirements.
D
I
know
the
product
planning
team
has
been
doing
a
lot
of
back-end
work
to
basically
get
requirements,
data
into
the
work
items
into
the
right
tables,
but
I
was
just
curious
to
hear
from
the
group
about
what's
next
into
having
this
be
more
of
like
a
user
facing
change
and
what
are
the
steps
to
get
there
to
basically
have
this
be
more
consolidated
from
the
front
end
perspective.
B
I
added
one
note
above
this:
I
think
that
so
far
front-end
still
uses
the
old
requirements
api,
so
I
would
expect
that
one
of
necessary
steps
would
be
switching
front-end
to
the
new
work
item
api,
but
I
suspect
there
are
still
missing
bits
for
requirements
in
this
api,
specifically
exposing
the
test
reports
for
requirements.
So
I
would
expect
we
need
some
widget
representation
of
test
reports
in
this
api.
F
F
As
you
said,
I
have
a
new
api
for
the
new
the
requirements
as
we're
kiting
it
still,
which
is
still
not
done,
and
deprecation
tasks.
D
G
I
think
one
thing
to
consider
we're
gonna
do
the
spiker
poc
for
the
widget
architecture
and
I
think
we
talked
about
having
the
test
reports
be
like
a
widget,
and
so
I
think
if
we
were
to
use
the
work
items
front
end,
we
would
have
to
have
that
sorted
out
first,
so
that
we
could
widgetize
the
test
reports
thing
and
then
we'd
have
to
add
description,
which
is
what
we're
sort
of
working
on
next
anyways.
So
hopefully
we
could
unblock
that
widgetization
of
the
test
reports
after
this
next
release.
H
I
think
that
makes
sense.
I
mean
I'm
not
very
familiar
with
requirements
or
test
cases,
but
I
think
yeah.
We
discussed
that
we're
going
to
push
wichita
a
little
bit
for
a
later
release
and
we've
been
talking
about
not
introducing
that
much
stuff
into
the
work
items
api
as
if
it's
going
to
be
widgetized,
it
makes
no
sense
to
to
have
it
at
the
root
level.
For
example,
I
mean
fields
or
anything
in
the
in
the
work
items
api.
H
I
G
It's
the
thing
that
it
basically
you
connect
it
to
well
actually,
john,
I
think
you
implement
it,
so
you
can
speak
to
it.
If
you'd
like
better
than
me,
probably.
B
Yeah,
so
when
user
defines
some
requirements,
requirement
could
be
so
my
product
matches
some
feature,
so
it
can
map
it
to
test,
runs
yeah
either
in
ci,
so
you
can
on
each
ci
run.
You
can
reference
that
that
requirement
was
met.
So
test
report
is
representation
of
meeting
or
of
succeeding
or
failing
a
requirement
at
some
time
yeah
or
on
crm.
If
it
makes
sense.
I
Gotcha,
okay,
so
thanks
yeah,
it's
like
a
pretty.
I
mean
from
the
widget
perspective,
like
it's
a
pretty
big
leap
from
description
to
test
report.
I
think,
like
it's
a
that's
like
a
more
if
I'm
kind
of
understanding
the
scope
of
the
test
report
functionality.
Looking
at
this
issue,
you
linked
gabe,
so
that
could
be
a
good
that
could
be
as
part
of
that
widgets
poc,
like
we,
I
mean
description
first,
given
that
it's
sort
of
straightforward,
I
think
we
had
talked
about
assignees
or
one
of
the
other.
I
Excuse
me
one
of
the
other
more
kind
of
deeper
like
functionality,
widget,
but
test
report
could
be
an
interesting
one
to
kind
of
prove
out
some
of
the
weird
things
we
need
to
solve.
For
that.
G
But
I
think
we're
already
capturing
all
that,
like
historical
data
that
we
can
kind
of
surface
too
eventually,
so
we
can
start
super
small
if
we
want,
with
it
and
just
surface
what
we
do
in
the
current
requirements.
Ui
is
the
npc
but
yeah.
It
would
be
a
fun
one
to
explore
and
I
think
help
us
push
the
limits
of
how
we're
thinking
about
building
widgets.
B
B
A
It's
interesting
that
there's
two
different
things.
So
if
you
list
requirements,
you
get
the
last
last
test
report
state
and
last
test
report
manually
created.
So
there
are
two
ways
to
satisfy
a
test
report.
One
is
through
the
ci,
in
which
case
it's
automatically
marked
as
passed
or
failed
or
satisfied
or
failed.
The
other
one
is
to
have
a
manual
check
and
that's
what
this
does,
but
also
it
returns
all
test
reports
which
I
think
might
be
not
even
necessary
for
the
list
page.
You
just
need
the
last
test
report
state.
A
C
I
I
have
one
comment
about
the
this
whole
widget
work
and
the
api
is,
I
feel
like,
and
we
don't
have
it
but
like.
I
sometimes
feel
the
need
of
having
some
sort
of
an
internal
api
like
a
graphql
but
internal
api,
so
that
we
don't
add
it
to
the
public.
Do
all
this
stuff
with
the
widgets
and
so
on,
and
then,
when
we
feel
it's
ready
to
be
promoted
to
a
public
api.
H
But
I
do
think
we
discussed
a
little
bit
of
that
and
well
everything
is
behind
the
feature
flag
right
now
and
last
time
we
talked
with
brett
and
gabe
and
jake.
I
think
we
will
agree
that
this
api,
as
we
are
moving
forward
and
we
improve
ups
concepts
and
everything
it's
actually
kind
of
something
like
what
you
just
mentioned.
H
C
We
are
hitting
this
problem
now
with
iteration
cadences
right.
It
was
behind
a
feature
flag,
all
the
way,
but
now
we
are
kind
of
having
this
problem
where
we
cannot
move
forward,
because
what,
if
it's
enabled
what
is
what,
if
it's
disabled,
back
and
so
on
and
so
forth.
So
so,
even
though
it's
behind
a
feature
flag,
it's
still
kind
of
like
public
facing
and
people
can
enable
disable
feature
frames,
or
even
us
can
do
this
tweaking
back
and
forth,
and
it's
not
exactly
the
same
but
yeah
again.
C
This
is
not
probably
not
a
discussion
for
this
session,
but
something
that
maybe
we
should
bring
as
engineers
to
the
to
the
engineering
group
and
see
if
we
can
find
a
something
that
that
would
work
for
us
and
just
like
make
it
easier
for
us
to
test
stuff
and
then
promote
to
to
a
more
public
and
maintainable
thing.
C
H
C
B
Yeah,
I
remember
that
previously
I
used
experimental.
B
A
A
God
all
right,
thanks
cool
in
okay,
so
the
next
one.
So
yes
at
this
point,
we've
merged
the
front-end
component
of
epic
links
and
enabled
it
for
gitlab.org,
our
gitlab
or
gitlab.com,
and
a
few
other
groups
I
think
as
well.
So
that
gives
us
roughly
24
hours
to
test
it
before
we
merge
the
mr
that
defaults
it
to
on
that.
Mr
has
already
been
reviewed
by
moi
and
needs
maintainer
review.
A
So
it's
pretty
much
ready
to
go
any
thoughts
on
how
we
should
test
it
to
ensure
that
it
works
over
the
next
24
hours
and
marching
in
the
comments
as
well.
E
My
comment
is
a
question
like
is:
are
we
expecting
any
more
features
related
to
related
effects
before
the
the
end
of
the
milestone.
A
E
What
I
mentioned
is
zuyan
has
an
image
request
for
that,
but
for
the
api-
and
that's
all
I
know.
B
E
A
What
needs
to
happen
for
those
to
go
in
today,
like
if
they're
docs
only
can
we
like
assign
multiple,
dris
and
then
march
and
have
you
do
maintain
a
review.
E
E
So
even
if
we
miss
this,
the
so-called
freeze
for
code,
it's
usually
no
problem
to
just
add
the
label
pick
into
whatever,
because
let
me
think
to
answer
your
question.
You
can
assign
me,
but
if
it's
outside
of
my
working
hours,
you
can
go
to
the
doc's
channel
in
slack
and
just
ask
whoever
and
whoever
can
can
do
it
but
yeah,
like
I
said
my
main
question
was
like.
Is
there,
for
example,
image
request,
adding.
F
Yeah,
I
don't
know
if
any
other
feature
for
the
any
additional
things
for
you,
why
I
only
see
things
like
displaying
related
epics
on
epics
lists,
but
I
think
this
is
for
another
release,
so
I
think
that's
it.
For.
E
A
Cool,
so
my
second
question
was
maybe
to
melissa:
what
can
we
do
to
assuage
your
concerns
that
this
might
have
some
faults,
or
what
can
we
do
to
test
it
in
the
next
24
hours?
That
would
reassure
you
that
we
can
release
it
in
14.9.
D
Yeah,
so
I
took
a
look
this
morning
and
I
found
one
small
bug
but
other
than
that
all
the
happy
path
stuff
looks
good
and
then
I
also
let
others
get
lat
pms.
There
were
a
couple
people
that
were
really
excited
about
this
feature,
so
I
let
them
know
that
it's
available
now
so
they'll
be
taking
a
look
and
if
nothing
else
comes
up,
we
can
probably
like,
by
the
end
of
my
working
day,
we
can
set
it
to
default
on.
D
Yes,
it
was
the
token
indicator
of
hashtag.
Basically,
when
you
put
it
in
the
text
field,
it
would
search
for
issues
to
relate
to,
but
then
it
can't
do
it.
So
it
was
a
front-end
bug,
but
charles
is
already
taking
a
look
at
the
work.
A
Can
live
with
that
cool
martial
need.
Another
comment.