►
From YouTube: Plan Stage Weekly - 2023-09-07
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
Foreign
team
weekly,
where
are
we
September,
7
2023,
so
I've
got
a
few
things
that
I
added
to
the
agenda.
First
thing
was
just
a
reminder
for
the
folks
attending
this
plan
weekly
that
we
have
dates
for
the
plan
team
day
for
this
quarter.
They
are
going
to
be
on
the
12th
and
13th
of
October
I've
linked
the
the
issue
where
people
are
suggesting
or
adding
themselves
to
to
what
are
they
like
hourly
sessions
throughout
the
day?
A
A
Cool
cool
all
right.
Two
big
picture
updates
I,
wanted
to
discuss
Melissa's
note
from
the
plan
Channel
around
issuables
or
Legacy
issuables,
which
are
primarily
issues
Legacy
issue
and
Legacy
epic
view
that
we're
concerned
with
how
we've
decided
as
an
organization
to
not
dedicate
dedicate
time
to
new
feature
development
for
those
Legacy,
those
Legacy
issuables.
A
Thank
you
for
turning
that
into
a
link
over
to
that.
But
I
did
link
to
the
update
in
the
handbook
around
that.
Essentially,
it
means
were
dedicating
all
of
our
future
Feature
work
to
forecast.
B
Like
how
or
where
will
we
be
enforcing
like
I
understand
us
not
picking
stuff
up,
but
if
there's
like
a
community
push
for
adding
stuff
to
issues,
do
we
just
try
to
tell
people
like
put
it
on
work
items
instead
or
maybe
not
important?
We
can
see
if
that
actually
happens,
and
it
won't
it'll
be
fine.
Yeah.
A
I
mean,
ideally,
ideally,
we
get
to
it
before.
A
lot
of
work
has
been
put
in
to
to
a
feature.
A
Think
there
was
also
some
conversations
around
updating
some
of
the
labels
we
have
on
the
Legacy
planning
objects,
issues
because
I
think
a
lot
of
them
still
have
like
I,
don't
know
what
the
Bible.
A
Yeah-
and
we
might
want
to
think
about
adding
a
note
in
those
issues-
also
saying
that
you
know
we're
not
gonna
stop
people
from
or
we
may
not
stop
people
from
working
on
features,
but
we
won't
help
well,
we
it
may
take
a
bit
longer
to
get
things
through
the
workflow
to
get
to
to
get
into
master
and
production.
C
D
D
D
It
hopefully
we
get
the
answer.
Async
is:
does
this
apply
to
ux
papercuts,
I'm
kind
of
hoping
it
does
because
it's
it's
kind
of
outside
of
our
team
processes,
but
it
does
impact
our
features
so.
D
E
Yeah
I
I,
really
I
would
basically
prefer
otherwise,
where,
if
it's
some
minor
ux
Improvement
like
something
that
doesn't
require
a
lot
of
effort,
then
we
should
probably
fix
it
rather
than
waiting
for
object
to
be
converted
to
work
items
and
wait
for
eternity
for
that
change.
E
D
So
yeah,
so
the
reason
I
am
sort
of
a
guess
like
if
it's
really
minor
things
sure
I
would
still
prefer
if
it
was
maintained
by
someone
within
plan,
because
in
my
experience
ux
papercuts
can
have
more
impact
than
initially.
D
E
Yeah
I
think
it's
it's
just
a
matter
of
identifying
like
how
much
effort
does
a
particular
change
require
and
if,
if
the
impact
is
higher
or
the
effort
is
a
lot,
then
we
determine
that.
It's
it's
better.
Not
to
do
that.
Change.
C
A
I
want
to
move
on
to
next
one
Trisha.
Can
you
finish
commenting
or
writing
down
what
you
said?
You
know
what.
A
Okay,
I
wanted
to
to
talk
through
the
the
designs
from
Emily
I
think
she
she
created
them
or
added
them
to
the
issue.
A
A
couple
days
ago
now
around
some
of
the
they
have
been
doing
some
research
around
all
the
different
flows
that
that
are
available
within
the
product
to
create
a
planning
object.
So
I
believe
she
was
just
looking
at
how
to
create
issues
epics,
maybe
just
issues
and
epics
and
tests,
maybe
with
the
idea
being
that
there
would
be
a
way
to
consolidate
the
creation
of
them
all.
Because,
right
now
we
have
like
to
create
a
issue.
You
can
create
it
at
the
Slash
new
route.
A
A
A
A
Okay,
so
this
is
from
within
the
list
View,
we
did
go
back
to
the
the
drop
down
button
here
to
create
any
kind
of
work
item
that
can
be
created
from
within
that
or
that
can
be
displayed
from
within
that
list.
A
So
once
group
level
work
items
and
epics
our
work
items
in
the
group
issue
or
in
the
group
list,
you'd
be
able
to
create
an
epic.
In
addition
to
the
issues
tasks,
objectives
here,
clicking
on
an
item
in
the
drop
down
would
take
you
to
the
modal
view
from
within
that
I
believe
the
list
view
is
still
behind
this,
even
though
it's
not
showing
here
I
think
that
would
be
the
idea
that
the
model
would
show
up
in
the
list.
View.
E
Yeah
so
screenshots
contain
model,
but
MLA
did
mention
in
the
video
walkthrough
that
they
eventually
would
want
to
go
with
the
drawer
approach
and
sort
of
model.
E
Yeah,
so
their
inclination
is
towards
a
drawer
instead
of
model.
It
is
just
that,
as
of
now,
only
model
is
available
as
active
implementation,
I
I
believe
since
Natalia
already
had
poc
in
place,
I
don't
know
whether
we
would
go
withdraw
or
approach
in
the
first
situation
itself.
A
E
E
A
video
yeah,
just
just
a
second
I'm
basting
bubbling
to
that
discussion,
which
contains
both
figma
file
as
well
as
video
walkthrough.
Here
it
is
in
the
agenda
I've
pasted
link
to
that
conversation.
A
A
And
then
kushal
can
you
watch
it
I'm
assuming
already
yeah.
E
I
watched
it
and
I
I
also
asked
a
couple
of
follow-up
questions
in
that
same
thread
when
I
noticed
some
things
different.
A
And
then
this
is
the
same.
The
same
crate
view
again
in
the
screenshots
it's
modal,
but
more
than
likely
it'll
move
to
the
drawer
similar
to
what
we
have
for
okrs
on
in
the
gitlab
project,
where
they're
active
or
where
they're
trying
not.
But
this
one
just
adds
a
location
selection.
A
A
That's
interesting
because
I've
is
moving.
This
moving
happen,
a
lot.
D
B
A
Yeah
I
think
there's
right
now,
just
we
want
to.
We
want
to
kind
of
clean
up
the
whole
moving
process
right
now,
because
there's
there's
different
discrepancies
like
like
sometimes
I,
don't
even
know
if
the
task
get
moved
along
with
it
or
there's
different
issues
with
with
authen
permissions.
A
D
You
say
clean
up,
you
don't
mean
fixing
it's
a
legacy,
probably
because
I
don't
think
we'd
want
to
spend
time
on
this.
But
what
would
be
super
useful,
though,
would
be
to
have
a
really
clear,
like
definitions
from
products
of
like
the
different
use
cases
of
moving
things
attached
to
it,
depending
on
permissions
and
I.
Don't
know
confidentiality,
parents,
children
related
and
like
sort
of
have
different
use
cases
and
a
description
of
the
expected
behavior
when
we
do
moving
because
I
think
that's
something
that's
missing.
A
Yeah
it'll
also
be
interesting
how
it
ties
to
like
we
want
to
get
away
from
the
idea
of
promoting
work
items,
but
how
it
kind
of
ties
to
promoting
of
of
work
items.
D
I,
don't
think
I
mean
I
guess
we
still
have
to
promote
to
quick
action,
but
also
looking
at
what
we've
done
recently
like
it's
more
that
we
update
the
type
like
we
can
change
like
an
issue
into
attack
or
task
to
an
issue,
and
it's
not
necessarily
a
promotion
per
se.
It's
more
like
just
a
change
of
type
I.
Don't
know
if
it's
a
wedding
issue,
if
there's
really
a.
E
Yeah,
that's
that's
correct,
Flory,
that
when
we
change
the
when
we
basically
promote
a
smaller
object
to
basically
a
super
object
like
say,
promoting
task
to
an
issue,
it
will
technically
be
just
a
type
change
and
additionally,
it
will
start
showing
additional
widgets
which
are
otherwise
not
supported
on
tasks.
E
Similarly,
if
someone
is
trying
to
promote
an
issue
to
an
epic
provided
that
both
those
objects
are
now
work
items,
then
it
will
behave
in
a
similar
fashion,
unlike
what
we
do
right
now,
where
we
close
the
issue
and
then
create
an
epic
and
copy
over
everything,
including
description
as
well
as
discussions
to
the
newly
created
epic,
which
won't
be
the
case
when
we
have
both
of
them
as
work
item
where
it
will
be
just
a
simple
type
change,
and
then
the
object
will
start
listing
in
a
different
place.
Yeah.
D
I'm
I'm
wondering
if
it's
a
question
of
wording
as
well,
because
I'm
kind
of
thinking
like
long-term
vision
for
work
guidance
where
people
like
sort
of
have
their
own,
it
doesn't
necessarily
have
to
be
like
features
at
the
top
epic
and
then
issue.
They
could
have
their
own
objects
and
then
promotion
may
not
mean
anything
anymore.
It
will
just
maybe
be
a
graph
of
things
that
can
relate
to
each
other
and
it's
just
a
type.
It
doesn't
matter
if
it's
a
promotion
or
a
downgrade
or
whatever
it's
just
a
change
of
type.
A
Yeah
and
then
also
like
once
we
get
to
like
it,
not
really
matter
ing
matter,
yeah,
whether
it's
a
group
level,
work
item
or
a
project
level,
work
item
that
they're
all
kind
of
namespace
level
work
items
so
switch
in
between,
like
an
epic
from
a
group
to
a
project
should
be
done
pretty
seamlessly,
and
there
shouldn't
be
any
issues
with
with
that,
with
switching
that,
with
switching
that
hierarchy
in
the
future.
A
Okay
cool:
oh,
we
got
here
for
three.
B
I
agree
with
you
earlier
that
that
location
has
like
the
second
feel
on
the
page,
feels
quite
front
and
center
for
what
is
probably
less
common,
like
reading
descriptions
more
often
than
I'm
moving
issues
to
different
groups.
B
A
I
wonder
if
there
will
also
be
less
movement
when
there
are
like
when
we,
when
hierarchy
is
less
tied
to
groups
and
projects.
A
I
guess
we'd
have
to
figure
out
like
what.
What
is
the
reason
people
are
moving
issues
or
moving
work
items
or
planning
objects.
Today,
we'd
think
they
would
be
doing
it
mostly
to
fits.
A
Okay,
so
here
we
have
the
edit
views.
E
Solve
all
the
biggest
changes
so
that
I
noticed
in
these
designs,
so
one
thing
that
particularly
stood
out.
So
if
you
zoom
in
one
of
those
designs
and
look
at
where
the
discussions
begin
right
above
that
activity,
header
notice,
how
that
related
items
and
child
items
are
no
longer
showing
as
a
as
a
container
widget,
but
rather
simple
buttons.
So
in
case
any
issue
or
an
epic
doesn't
have
a
child
item
or
a
linked
item
associated
with
it.
E
So
it
basically
saves
some
vertical
space
and
horizontal
space
within
the
page
and
I
I
did
ask
like
in
in
case
user,
is
adding
an
item
for
the
first
time.
Do
we
have
the
designs
of
where
the
form
would
exactly
show
up
and
how
the
ux
for
adding
items
as
related
or
child
would
look
like
now?
E
Currently,
they
don't
have
the
designs
yet,
but
that's
a
stark
difference
from
what
we
have
been
doing
so
far
like
having
a
widget
always
persistent
on
the
page,
regardless
of
whether
there
are
any
child
items
or
not.
It's.
B
B
E
B
B
List
has
been
left
blank
intentionally,
and
so
you
could
have
some
I
assume.
You
click
that
and
then
get
some
little
inline
form
for
creation
and
then,
if
they
are
related,
child
items
or
linked
items
or
designs
and
they'll
be
there.
But
we
don't
have
the
empty
States
holes
kushal.
You
said
that
the
modal
was
a
sidebar
for.
E
D
So
what
I,
what
I
do
know
and
watch
the
video
so
I,
don't
know
any
in
general
to
avoid
the
model
all
together,
because
workflow
issues
I
think
mostly
it's
not
an
experience.
We
want.
Overall,
the
drawer
is
the
way
to
go.
D
It
could
stack
I
think
there
was
a
conversation
where
we
could
have
multiple
drawers
stack
to
view
multiple
objects,
so
in
this
case
it
could
stack
potentially
with
the
sidebar
or
it
could
go
over.
It
can
imagine
that
the
thing
is
so
I
understand
how
a
drawer
would
work
for
the
create
rule,
but
for
edit
like
don't,
we
want
to
do
inline.
F
D
D
A
So,
okay,
with
the
form,
there's
still
being
a
question
on
the
design
of
the
form,
so
there
may
still
be
a
form
here
for
ad
child
item
that
shows
up
here.
We
haven't
decided
that
it's
gonna
show
the
same
modal
view
or
drawer
view
as
this
as
this
one.
A
Sorry
we're
so
it's
not
set
that
clicking
on
that
add
new
or
ADD
child
item
is
not,
may
not
show
this
View
to.
C
E
Mentioned
either
way
like
whether
it
will
be
within
the
model
or
not.
I
would
assume
that
we
won't
be
showing
as
many
info
items
in
edit
view
of
a
single
object,
because
we
don't
want
to
expose
all
those
widgets
at
once.
So
if
someone
is
say
viewing
an
issue
only,
then
we
will
show
widgets
for
adding
child
items
for
related
items.
But
if
someone
is
editing
the
issue
itself,
then
we
would
we
would
be
hiding
those
additional
widgets.
A
Users
wanting
to
or
wanting
the
ability
to
quickly
create,
like
multiple
work
items,
either
multiple
issues
or
tasks,
as
opposed
to
right
now
like
if
they
wanted
to
create
five
issues
even
from
within
an
epic.
It's
still
like
a
bunch
of
different
clicks
to
get
there,
but
there
was
also
comments
where
users
want
to
be
able
to
edit
more
more
than
just
the
title
when
they're
quickly
creating
a
work
item.
A
B
A
Okay,
so
I
guess
this
is
a
different
proposal
for
location
which
is
more
similar
to
how
we
did.
We
move
move
issue
to
the
drop
down
in
issues.
E
A
Is
still
part
of
sidebar
okay,
so
this
is
just
moving
it
to
the
drop
down
in
work
items
and
the
same
kind
of
sub
drop
down
pattern
here,
but
combined
with
the
design
on
that
she
had
in
the
other
move,
location,
design.
A
So
that
is
the
crate
below
questions
comments
that
we
didn't
talk
through
there.
A
D
I
just
want
to
give
a
quick
update
on
key
results,
I'm
leading
at
the
moment,
which
is
reducing
our
flaky
tests,
so
for
this
quarter,
we're
aiming
to
fix
and
on
quarantine,
25
quarantine
tests
across
the
stage.
D
I
want
to
thank
everyone,
who's
done
any
of
them.
So
far
we
fixed
16.,
which
is
pretty
good,
I,
think
like
even
how
early
we're
on
the
quarter,
I
I
think
I
was
very
conservative
in
setting
the
goal
probably
going
to
go
beyond,
which
is
great.
D
The
yeah,
like
the
goal,
is
to
increase
test
coverage,
reduce
regressions
and
such
So
yeah.
Thank
you
and
keep
picking
up
stuff.
Let
me
know.
D
So
if
you
want
to
pick
stuff
up,
I
I've
done
a
small
selection
in
a
comment.
So
there's
a
few
things,
it's
all
in
the
comments,
but
I
can
bring
things
up.
I'll
put
stuff
in
the
notes,
so
I
did
a
vague
initial
selection
of
low
hanging
fruits,
so
I'll
just
put
them
in
the
agenda.
D
Sure
a
lot
of
them
have
already
been
picked
up,
though,
and
there
were
they
were
mostly
front-end,
because
that's
I
know
that's
what
I,
what
I
know
it's
low
hanging
and
in
the
key
results
there
is
also
a
board
that
joins
shared
if
I
can
find
it.
So
this
is
yeah
I
got
it,
I'll
put
it
as
well.
So
if
there
is
nothing
in
the
list,
I
made
initially.
D
You
can
pick
up
from
the
board
that
productivity
engineering
uses
to
track
blicky
tests.
You
know
organized
by
severity
as
well,
which
is
a
good
way
to
go
about
it.
So
yeah.
A
No,
it's
just
that
chart
for
project
management,
flaky,
test
numbers,
I
was
hesitant
to
or
I
was
thinking
for
our
for
the
projects
or
for
the
group
KR
that
we
would
just
try
to
get
to
Net
Zero,
where
we
would
flying
out
this
chart.
So
as
we
get
new
flaky
tests
at
least
fix
the
ones
and
the
ones
the
new
ones,
but
we're
doing
better
than
that
and
we're
already
we're
already
less
than
we
were
last.
D
C
B
D
So
the
problem,
so
this
is
something
for
the
future
I've
had
some
I've,
given
some
thoughts
to
this
in
terms
of
like
more
of
a
global
process
and
the
way
we
collaborate
with
productivity
engineering.
D
The
issue
is:
when
there's
a
flaky
test:
it's
it
either
gets
retried.
If
it
passes,
nothing
happens
and
it
may
be
flaky
like
every
I,
don't
know.
Maybe
it
fails
every
three
months
and
it's
sort
of
like
pulls
through
the
cracks
or
it
just
gets
quarantined,
and
then
it
falls
into
a
backlog
and
it
takes
a
month
before
we
get
to
it.
D
So
there's
I
think
a
lot
we
can
do
in
collaborating
with
productivity
engineering
and
improving
our
processes
on
how
we
catch
flaky
tests
and
how
our
us,
as
product
focused
Engineers,
are
made
aware
of
it,
because,
like
a
lot
of
the
time,
we're
not
even
aware
they
just
get
quarantined
and
then
one
day
we
look
through
our
aspects
like.
Oh,
why
is
this
quarantine?
I?
D
Never
heard
of
this,
like
this
happens
to
me
all
the
time,
so
I
think
that
we
can
look
into
just
improving
communication
and
processes
around
this,
so
that
we're
sort
of
tackle
it
as
we
catch
them,
hopefully
for
the
future.
But
for
now
it's
more
like
this
quarter,
we're
just
exercising
our
skills
at
fixing,
aspect,
tests
and
learning
what's
wrong,
what
makes
them
flaky
and
how
we
can
improve
them
and
then,
hopefully,
we'll
have
a
strategy
more
long-term
Vision
to
tackle
them
as
they
appear.
A
B
Maybe
on
that
kind
of
depends
on
the
instructions
and
the
test.
So
it's
like
I'm
the
reporter
that
can
vary
a
bit.
There's
not
really
I'll.
D
There's
a
lot
of
things
that
can
make
a
test
fail.
Sometimes
it's
environmental
issues.
Sometimes
it's
selectors
that
are
not
specific
enough
and
like
the
pages
at
different
loading
States
depending
on
which
environment
it
runs
on
and
sometimes
it
will
pass.
Sometimes
it
will
fail,
because
the
selector
is
not
specific
enough.
D
So
my
recommendation
is
use
data
test
ID
for
testing,
obviously,
and
yeah
like
it
can
be
really
tricky
because
a
lot
of
the
time
it
will
cut
on
your
local
machine
as
well
in
the
pipeline,
because
there's
much
more
traffic
going
on
the
servers
so
yeah
like
run.
Sometimes
it's
good
to
run
the
pipeline
multiple
times
to
see
what
happens
I.
Do
that
when
I
try
to
fix
flaky
tests
yeah
other
than
that,
it's
really
trial
and
error.
A
Next
question:
oh:
go
ahead
for
John!
You
first.
B
I'm
pretty
sure
why
or
some
for
doing
the
like
Dev
tools,
Network
throttling,
can
can
often
help
for
reproducing
stuff
for
things
that
are
waiting
for
a
response.
Then
it's
less
likely
to
see
it
on
local.
When
you
have
very
fast
networks
versus
testing
on
an
actual
instance,
and
then
you
get
latency
and
stuff
for
updates
I,
don't
remember
how
to
do
it.
That
was
a
while
ago,
but
that
could
be
worth
digging
up
again
or
just
adding
weights
randomly
throughout
the
test.
B
It
kind
of
depends
on
what
the
failure
is
and
how
the
test
is
written
because
somewhere
like
like
for
filtering
search,
results
or
something,
then
it's
like
expect.
You
see
three
things
and
then
type
this,
and
you
should
only
see
one
thing
and
there's
like
depending
on
how
that
test
is
written
and
what
it's
waiting
for
fail
in
different
ways.
A
I
have
a
really
hard
time
following
shared
examples
within
our
feature:
specs,
that's
where
it
gets
difficult
for
me.
I,
don't
know.
If
that's
it's
probably
just
me.
It's
Universal,
yeah
yeah.
D
I've
noticed
these
things,
change
or
something
I've
noticed.
I
know
that
was
before
and
I
never
know
before,
but
like
I
I
had
a
thing
pointing
at
the
actual
shared
example,
instead
of
the
parent
test
recently
failing
in
the
pipeline,
and
that
was
really
good,
so
I
I
was
able
to
it
was
pointing
the
line
within
the
shared
example.
It
was
the
first
time
I
noticed
that
so
I
don't
know.
Maybe
something's
changed.
D
A
Yeah,
do
we
have
like
a
policy
or
rule
around
when
we
quarantine
a
test
like
if.
D
It
so
I,
don't
know
if
it's
well
defined,
but
when
I
was
looking
at
productivity
engineering
issues.
Basically
what
they
do
is
that
something
fails
every
try
it
passes
on
retry.
They
just
calls
the
issue
and
nobody
ever
hears
about
it
or
they're
quarantine.
If
it
fails
on.
Second,
try,
basically
roughly
like
like
finger
in
the
wind
type
estimation.
E
Yeah,
that's
the
author
of
that
test,
notices
that
Master
broke
because
of
that
and
they
offered
to
fix
it
for
good.
Then
productivity
engineering
would
basically
assign
that
broken
Master
issue
to
them.
Otherwise
they
would
just
quarantine
and
forget
about
it.
A
Has
the
new
process
around
broken
Master
alerts
within
project
stage
channels?
Is
that
helped
you
all
be
more
aware
of
broken
Master
issues
or
flaky
tests
or
I.
A
A
Oh,
no,
it
would
have
been
in
product
planning.
We
got
a
few
on
in
the
project
management
Channel.
D
A
A
A
I
I
did
realize
that
I
did
not
have
the
ability
to
as
a
non-maintainer
to
retry
retry
pipelines
in
master
for
those.
So
because,
most
of
the
time
like
you,
like
you,
said
flooring,
it's
just
a
a
rerun
and
then
ignore
and
I
wasn't
able
to
do
that.
So
I
wasn't
even
able
to
really
help,
but.
D
D
Have
happened,
there
is
a
dashboard
on
the
key
result.
I've
shared
about
I.
Think
it's
more
like
tracking
the
causes
for
broken
master.
C
D
No
I
can't
well
it's
on
the
key
reason:
I
can't
I
need
to
log
in
so
I,
don't
know,
but
it's
it's
in
there,
but
I,
don't
think
it's
more
like
it's
around
broken
master
in
general,
not
just
waiting
just.