►
From YouTube: Plan | Weekly Sync 2023-05-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).
A
All
right,
you're
all
very
welcome
to
the
24th
of
May
plan
weekly
team
meeting.
Let's
see,
I
got
a
lot
of
read-only
items
today
is
putting
one
in
at
the
top,
but
it's
read
only
awesome
and
I
have
the
first
item
three
items
down
yeah.
So
I
just
wanted
to
highlight
this
because,
if
you
don't
know
probably
the
average
well,
probably
the
the
maximum
number
of
release
post
items,
I've
seen
the
stage
contribute
to
the
release.
A
Post
in
the
last
sort
of
five
to
six
months
has
been
six
sort
of
seemed
to
be
pretty
consistently.
Five.
Six
every
month
is
ten
this
month
and
even
then
that's
if
you
roll
all
the
AI
items
into
one
and
consider
it
as
one
feature
so
I,
don't
know
why
this
happened,
but
I
just
wanted
to
take
a
minute
like
to
recognize
it
and
celebrate
the
win,
because
not
only
that,
but
one
of
them,
one
of
the
items
is
the
top
item.
A
In
the
release
post,
we
have
tons
of
improvements
to
work
items
and
some
pages
improvements
as
well.
So
it's
really
like
a
whole
cross
stage.
Effort
like
so
really
really
nice
so
yeah
that
yourselves
on
the
back,
take
the
win.
We
didn't
get
team
day,
but
we
got
a
massive
win
on
the
release
post.
So
there
you
go
my
next
items
read
only
but
like
it's.
If
I,
don't
it's
been
it's
an
MR,
that's
been
open
for
24
hours.
If
I
don't
get
any
feedback
on
it.
A
I'm
gonna
just
merge
it
after
the
meeting,
because
I
think
it's
probably
a
positive
change
and
we're
into
demos.
So
do
we
have
Mario.
B
Yes,
hey
everyone.
Another
demo
just
wanted
to
share
with
you
all
I
guess
that
I
have
been
actively
working
on
removing
the
issue
type
column.
It's
a
lot
of
work.
B
It's
used
in
everywhere
in
the
application,
we're
at
a
point
where
we
already
have
the
work
item,
type
ID
column
in
sync
I
fixed
about
where
it
was
I,
don't
think
we
backfilled
again
for
the
incident
type,
so
I
think
we're
at
a
place
where,
where
that
shouldn't
be
getting
out
of
sync
again,
we
have
a
method
that
checks
at
least
with
the
Callback,
but
anyway
I'm
working
on
removing
the
last
Scopes
I.
Guess
that's
the
most
delicate
part
as
it
can
have
performance
implications.
B
So
all
of
that
is
going
behind
the
feature
flag,
at
least
the
Scopes
that
now
join
with
the
issues.
Sorry,
the
work
item,
types
table
and
yep
I
hope
I
can
I'm
already
working
on
an
MR
with
a
test
where
I
actually
removed
the
column
to
see
it
where
it
fails.
We
are
down
to
128
jobs,
failing
from
300,
so
that's
good.
So
it's
just
that.
I
just
wanted
to
share
that
at
least
at
the
stage
level.
B
We
should
definitely
not
use
the
issue
type
column
for
new
scopes
for
new
anything.
We
are
at
a
point
where
soon
we'll
have
to
ignore
the
issue,
type
column
and
just
focus
on
the
work
item
type
ID,
hopefully
in
this
release,
16-1
and
then
in
16-2,
we'll
be
able
to
drop
the
column
very
good,
hopefully
so
yeah,
that's
it
just
a
heads
up,
so
you
can
share
as
much
as
you
can
that
and
that
that
we
shouldn't
use
that
column.
B
I
have
played
some
pieces
of
code
that
will
safeguard
the
usage
of
the
column
in
some
places,
but
there
are
some
where
I
can't
I
would
have
to
write,
I
guess,
database
callbacks
and
things
like
that
procedures
to
to
prevent
it.
So
so
just
that
just
so
everyone
is
aware.
D
Okay,
I
have
the
next
item,
so
this
was
shared
a
couple
of
plan
meetings
ago,
where
we
were
considering
to
use
fine-grained
mutations
to
update
certain
aspects
of
work
item
rather
than
using
work
item
update
as
a
single
mutation
to
do
the
changes
earlier.
It
was
a
performance
problem
that
work
item
update
mutation
was
slower
because
it
was
doing
a
lot
of
validations,
but
now
we
have
ran
into
permission
issue
as
well,
so
we
noticed
it
for
with
Emojis
first
but
turns
out.
It
is
impacting
notifications
and
to
Do's
as
well.
D
So
if
you,
if
you
know
you
can
visit
an
issue
or
an
MR
or
an
epic
and
react
with
an
emoji,
even
if
you
are
not
a
member
of
that
group
or
a
project.
Similarly,
you
can
add
those
items
in
your
to-do's
as
well,
and
you
can
turn
on
notifications
from
the
sidebar
for
these
objects
as
well
in
case
of
work
items.
You
cannot
do
it
unless
you
are
a
reporter
on
that
project,
which,
which
means
that,
even
if
you
are
a
guest
user
for
that
project,
you'll
not
be
able
to
do
it.
D
So,
for
now
we
are
able
to
fix
it,
at
least
for
emojis,
because
we
have
a
mutation
available
which
is
more
of
a
generic
mutation
around
emojis.
So
we
can
fix
it
for
emojis
where
anyone
as
long
as
they
can
see
that
work
item,
they
can
add
an
emoji
reaction,
but
notifications
and
to-do's
still
do
not
work.
So
we
would
either
need
to
determine
whether
we
want
a
consistency
across
work
items
and
issues
and
Mrs.
E
It's
a
quick
thing.
Basically,
we
also
have
individual
mutations
to
perform
the
notifications
and
the
to
do
with
the
old
one
action
and
the
reason
we're
not
proposing
to
use.
It
is
because
there's
still,
we
haven't
agreed
that
we
can
divert
from
using
the
main
update
mutation.
E
So
if
we
agree
that
we
can
make
exceptions,
assumptions
that
we
can
just
fix
these
three
problems
with
changing
the
queries
we
use
in
the
front
end
and
we
haven't
agreed
and
I
think
this
is
something
we
should
agree
is
the
whole
team,
because
it
there
might
be
more
reasons
where
new
widgets
will
require
different
different
permissions
and
and
the
base
permission
for
this
mutation
is
update
and
work
item.
And
so,
if
we
want
to
include
any
widget
inside
the
mutation
that
requires
less
than
updating
the
whole
item
and
that
wouldn't
work
either.
E
So
we
would
have
to
agree
that
using
individual
mutations
for
some
Widgets
or
change
in
the
way
we
perform
permissions
in
the
update
mutation.
F
I
I
kind
of
thought:
we
already
made
the
decision
on
this
that
that
when
we
can
use
the
big
one
we
do,
but
when
we
need
something
specific,
there's
not
a
problem
with
that,
particularly
for
performance
or
permission
reasons,
or
anything
like
that,
so
yeah
I
would
say,
go
ahead
of
course,
on.
B
That
I
I
mean
I
did
get
involved
a
little
bit
on
the
issue.
Discussion
I
think
that
yeah
we
can
all
agree
that
separate
limitation
is
fine.
I
think
we
have
discussed
that
in
the
past
two
I
I
think
that
more
important
than
that
was
if
we
should
always
use
the
update
service
for
for
this
as
a
as
a
place
where
we
always
do
updates
on
a
work,
item
and
I
do
think.
B
That's
important
I
mean
I've,
seen
it
in
the
past
in
one
of
my
changes
where
I
change
something
directly,
then
just
to
realize
that
we
were
in
Grid
and
system
notes
and
sending
notifications
and
things
like
that.
So
that's
something
the
the
update
service
always
takes
care
of
and
I
know.
This
was
also
part
of
the
discussion.
The
update
service
can
be
slow,
so
maybe
what
we
should
be
working
on
is
on
making
it
faster.
B
Henrik
raised
an
issue
where
one
of
the
low
is
lowest
parts
of
it
is
update
services
that
we
always
fetch
old
labels
and
probably
lots
of
them.
So
maybe
we
can
work
on
improvements
on
those
things.
Probably
we
shouldn't
fetch
labels.
If
we're
not
going
to
update
them,
so
a
simple
check
on
the
params,
where
we
don't,
if
the
params
don't
include
label
updates,
then
don't
fetch
the
old
one.
Something
like
that.
So
I
still
agree
that
we
should
be
using
the
update
service,
but
yeah
smaller
mutations
should
be
fine
too.
B
I
mean
if
you
write
an
individual
mutation
that,
for
example,
changes
the
notification
status
directly.
So
you
call
something
like
work
at
the
word
item:
update
notification,
status,
I,
don't
know
the
name
of
the
method.
So
then
you
are
not
using
the
work
item
update
service.
That
does
a
lot
of
checks.
We
even
do
permission
checks,
I
mean
on
the
policies,
and
this
is
something
that
was
also
raised
before,
for
the
each
use
create
service,
for
example,
so
in
general,
I
think
we
should
use
the
services
for
for
many
things.
Also.
B
B
And
we
can
also
think
about
improving
the
update
service.
I
was
thinking
that
maybe
we
could
even
change
the
update
mutation.
The
update
work
item
mutation
to
not
check
the
the
permission
then
the,
but
then
we
have
the
the
service
check.
B
I
mean
do
permission
checks
on
some
of
the
attributes.
This
is
something
we
already
do
for
for
issues
in
some
places.
I
know
for
the
YouTube
type
we
check
if
the
user
can
create
a
certain
issue
type
and
if
not,
we
default
to
the
default
issue
type
things
like
that
and
that
those
are
things
that
the
service
handles.
B
So
I
can
imagine
with
the
the
framework
we
already
have
for
widgets
I
mean
we
can
probably
place
this
permission
check
at
the
widget
service,
something
like
that
and
then
not
check.
Do
a
general
update
work
item
check
on
the
mutation,
but
but
yeah
I
mean
I
guess
to
to
fix
what
you
were
saying.
Kushala
I
think
that
the
best
way
is
definitely
to
just
create
two
new
mutations
now
and,
if
possible,
use
the
service
foreign.
D
D
A
F
Anywhere,
we
should
document
it
in
either
in
the
park
items,
blueprint
or
yeah.
D
F
H
F
H
We
had
a
discussion
about
it,
I
think
around
a
year
and
a
half
ago
and
general
decision
was
opt
for
fine-grained
mutations
whenever
possible,
a
work
item.
We
have
a
little
bit
different
architecture,
so
course
create
implementation,
made
more
sense
from
the
start
and
we
just
diverted
from
the
Disco
performance
reasons
which
are
obviously
important.
But
overall,
if
I
recall
correctly,
we
decided
applying
great
mutations.
H
Yes,
exactly
we
had
one
huge
course
great
course
grade
limitations
was
for
issue
of
update
issue
and
it
did
those
a
few
performance
problems
back
in
times
and
it
was
very
different
from
Omar,
but
let's
check
a
little
off
top
sorry.
B
A
I
do
remember
the
conversation
that
I
think
you're
talking
about
that
I
think
it
wasn't
slack
and
I
wonder
if
we
ever
updated
it
or.
B
I,
don't
remember,
but
I
do
remember
the
outcome
of
the
discussion
being
me:
creating
a
mutation
to
step,
update
widgets
that
in
the
end
I
had
to
revert
but
yeah
I
I.
Remember
it
being.
We
prefer
finder
invitations,
at
least
when
we
started
working
on
work
items.
H
Because
we
have
very
different
front-end
architecture
on
the
work
item
comparing
to
other
applications
and
we
are
having
fine-grained
queries
and
most
applications.
While
work
item
has
a
core
screen
query
on
the
root,
so
updated
work
item
in
general
was
the
easiest
way
for
front-end
to
handle.
Honestly,
we
don't
need
to
do
any
manual
updates
for
the
front
end.
But
again,
there
are
performance
reasons
why
we
start
the
version
from
it.
C
If
you
need
atomicity,
for
example,
I
started
with
Hera,
he
repeated
as
the
first
one
and
I
had
to
opt
I
I
had
to
choose
the
generic
update
notation,
simply
because
there
are
use
cases
when
you
need
to
set
the
parent
when
you
create
create
a
or
kython
yeah.
So
you
cannot
first
create
work
item
and
then
try
to
set
some
attribute
a
parent
attribute
on
it.
You
need
to
do
it
together,
so
depending
whether
widget
needs
atomicity
if,
for
example,
create
action
or
update
action.
A
So
it
sounds
like
any
documentation
updates
going
to
be
more
complex
than
just
recommend
them,
one
or
the
other.
So
Kershaw.
Maybe
do
you
want
to
make
a
proposal
and
then
copy
everyone
in
to
make
edits
on
it,
because
it's
like
possible
that
we
shouldn't
recommend
one
or
the
other,
but
specifically
for
work
items,
give
examples
of
when
you
might
choose
one
over
the
other
and
then
like
Natalia.
If
you
want
to
weigh
in
with
performance
concerns
like
if
any
of
the
guidance
is
pushing
people
in
one
or
other
direction
like.
C
A
Know
weigh
in
with
concerns
on
you
know
why
we
should
favor
one
of
the
other
in
certain
circumstances,
and
we
should
get
to
something
roughly
that
everyone
can
agree
with
right.
A
Right
cool,
looking
forward
to
that
Mr
cheers
next
one's
for
me,
so
we
had
this
discussion
two
weeks
ago
about
Mr,
reversions
and
I
took
a
lot
of
feedback
in
this
meeting
and
I'm
thankful
for
it.
I
have
thought
about
it.
A
lot
and
I
think
like
measuring
Mr
reversions,
even
if
they're
like
it
does
have
some
positive
aspects
like
the
negative
ones,
are
just
too
kind
of
deceptive.
A
It's
not
something
like
it
gives
us
information
to
know
how
many
Mrs
are
being
reverted
but
I
kind
of
agree
with
the
critical
feedback
that
it's
not
necessarily
something
that
is
good
or
bad,
and
there
may
be
a
certain
amount,
that's
optimal.
That
is
not
zero
right
like
in
some
cases,
it's
the
right
thing
to
do,
and
so
on.
A
So
instead
of
targeting
Mr
reversions
for
efficiency
like
I,
think
a
better
thing
would
be
to
try
and
address
some
of
the
like
outcomes
of
certain
times
when
we
were
Mrs
and
the
two
I'm
going
after
are
first
of
all
regressions
that
cause
usability
issues
or
just
broken
features
to
have
some
kind
of
lightweight
RCA
process.
A
That
and
I
mean
lightweight
I.
Don't
mean
an
fcl
where
we
like
block
the
team
for
five
days
for
every
single
little
thing
that
goes
wrong,
but
just
to
try
and
learn
something
from
every
time
we
break
something
for
customers,
like
would
be
enough
for
me,
I
think
we
could
trial
something
for
two
to
three
months,
see
if
it
has
an
effect.
A
You
know
like
if
we're
I
don't
know
what
I
had
a
quick
look
through
our
backlog
and
we
generate
maybe
one
regression
per
month,
at
least
assuming
we're
following
the
process
of
labeling
them
correctly.
So
this
shouldn't
be
like
a
huge
deal,
but
it
should
like
if
we
get
it
right,
reduce
the
amount
of
breakages
we're
delivering
to
customers,
which
would
be
nice,
and
then
we
can
try
for
a
couple
of
months
and
if
it's
really
a
terrible
experience-
and
it
doesn't
do
anything.
H
A
Can
scrap
it,
but
if
there
are
improvements
to
make,
we
can
make
those
as
well
and
then
the
second
one
is
reducing
time
spent
in
broken
Master.
You
may
like
see
some
charts,
not
gonna
run
that
are
fairly
new
from
the
engineering
productivity
team.
This
month
there
was
an
issue
with
I
think
it
was
I
think
it
was
pipeline
stability.
A
So
if
you
just
look
at
like
the
last
months,
the
contribution
of
flaky
tests
is
very
low,
but
on
every
any
given
month
they
make
up
fifty
percent
of
broken
master
and
25
percent
I.
Think
of
those
are
flaky
tests
related
to
plan.
It's
not
something
that
anyone's
done
wrong.
A
I,
think
just
the
product
area
that
we
have
is
maybe
difficult
to
test,
or
maybe
it's
been
a
resourcing
thing
over
the
years
whatever,
but
like
we
all
know
what
broken
Master
does
right
like
you
can't
merge
anything
while
it's
broken
and
if
you
see
the
number
of
times
that
it's
broken
each
week
like
it
really
feels
like
something
we
could
be
improving
as
a
company.
So
I'm
not
really
sure
how
to
tackle
this.
Yet
I
don't
want
to
load
teams
with
feature
spec
fixes.
A
I
just
want
to
know,
like
other
tests
that
we
can
quarantine.
Are
there
things
that
we
can
do?
Can
we
rally
some
support
from
other
teams,
maybe
to
help
us
like
clean
up
some
of
the
tests
that
are
are
breaking
in
our
product
areas?
So
if
you
have
any
ideas,
please
like
weigh
in
on
this
KR
because
currently
I'm
a
little
short
of
ideas
on
how
to
improve
this
one
I
just
know
it's
something
we
probably
should
so
yeah
so
you're
very
welcome
to
feedback
on
either
KR
and
in
particular,
I'm.
A
Looking
for
suggestions
from
people
who
like
work
on
the
code
every
day
and
can
help
to
like
in
the
end
of
the
day
like
these
are
hopefully
going
to
make
everyone's
lives
a
bit
easier
like
if
you
don't
have
to
deal
with
like
reverting
Mrs
or
you
don't
have
to
deal
with
broken
Master
as
much
like.
Hopefully,
it's
a
little
bit
of
a
nicer
development
experience.
G
In
the
Periscope,
is
there
any
good
list
of
flaky
tests
related
to
plan
and
the
fixes
that
we
can
go
through
easily
because
I
think
this
is
what
we
probably
need
to
do
like
go
for
every
fix
and
see
like
what
happened,
but
then
maybe
categorize
it
like
throw
it
into
AI,
that's
what
they
do
now
and
then
categorize.
It.
D
So
if
you
look
at
a
subgroup,
specific
triage
issues,
you'll
be
able
to
find
a
lot
of
those
flaky
failure.
Related
issues,
I
mean
I,
think
the
triage
report
is
created
on
weekly
basis.
I
I
can
maybe
find
a
link
to
one
of
the
recent
issues
from
product
planning
and
it
will
have
a
few
of
those
flaky
tests.
E
A
Yeah,
there's
also
a
classification
there
as
well
things
like
unreliable
Dom,
selector
right.
So
a
lot
of
these
are
kind
of
already
classified.
So
if
a
certain
class
of
these
are
going
to
be
easy
to
fix,
like
unreliable
Dom,
selectors,
probably
hard
to
reproduce
but
quite
easy
to
fix,
I
would
imagine
so
like.
If
we
can
come
up
with
something,
then
all
the
better.
You
know
like
it's
a
classifying
kind
of
find
the
ones
that
are
that
are
kind
of
easily
dealt
with.
G
And
one
more
question
about
the
20:
how
much
of
the
tests
are
based
on
plan?
Because,
like
are
we
just
a
statistical
outlier
or
because
or
because
we
write
the
most
tests.
A
Maybe
that's
that's
a
great
question
and
exactly
why
I
caveated
with
that
it
wasn't
necessarily
something
that
we've
done
wrong.
It
could
be
something
we're
doing
right,
but
nevertheless,
like
nobody
else
is
going
to
fix
them.
So
well,
I
don't
know,
maybe
maybe
somebody
else
will
fix
them
if
we
could
rally
some
support
or
something
but
I.
Think
first
of
all,
like
we
I
just
need
to
understand
more
about
what's
going
on
here
and
why
so
many
of
them
are
attributable
to
our
stage.
B
Just
a
note
on
that
last
week,
I
reviewed
some
Mrs
on
an
effort,
I'm
not
sure
what
the
team
is,
but
they
are
working
on
trying
to
fix
flaky
specs.
So
one
thing
they
did
is
to
wait
for
a
request
on
on
methods,
like
click
button
click
link
and
they
actually
reduce
the
copy
wire
timeout.
So
so
we
might
actually
see
an
improvement
the
next
couple
of
weeks,
or
we
might
not
really
be
seeing
it
not
sure
if
anything
has
changed
since
last
week,.
A
Or
if
you
wouldn't
mind,
could
you
leave
that
in
a
comment
on
the
KR
phone.
B
Yes,
I'll
paste
a
link
to
the
Mrs.
A
We
started
with
three
read-only
items
and
we
finished
with
the
read-only
item.
I,
don't
know
if
we
should
be
verbalizing
these
or
not
so,
but
please
go
ahead
and
read
them.
I'm
gonna,
stop
the
recording.
Anyone
who
wants
to
stay
on
is
welcome
to
do
so.
We
did
I
mentioned
above,
though,
like
there
is
a
proposal
to
turn
this
into
a
social
call.
If
there
is
no
agenda,
don't
know
if
that
also
means
we
finish
the
agenda
early,
but.