►
From YouTube: Plan | Weekly Sync 2022-09-14
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,
14th
of
september
right
plan,
weekly
meeting
right
yeah.
I
think
cool
at
the
first
item.
So
she's
not
here,
but
please
join
me
in
welcoming
yarka
as
the
new
engineering
manager
for
the
certified
team.
Yeah
jarka
will
manage
a
team
of
initially
three
temp
team
members
from
originally
from
the
joined
product
planning
and
certified
team
charlie,
philippe
and
richard
certify
is
now
like
a
completely
separate
group.
Has
his
own
designer
has
his
own
incoming
pm
as
well.
A
That's
dan
who's
designer
who
just
joined
by
the
way
and
we've
started
planning
for
15
five
but
that'll,
be
collaborative
between
everyone.
Who's
been
involved
in
the
group
so
far
and
we'll
start
planning
as
an
entirely
new
group.
Next
milestone
yeah,
so
she's
not
on
the
call.
But
you
know
please
welcome
her
anyway.
I'm
sure
she'll
watch
the
recording
any
questions
or
anything.
B
Cool,
so
I
want
to
demo
a
bit
the
new
itchy
creation
in
an
epic
and
before
we
do
that,
I
will
just
show
you
how
it
looked
before.
I
only
have
a
video,
but
I
hope
this
works
so
before
the
new
changes.
When
you
create
an
issue
within
an
epic.
What
you
do
is
you
add
like
an
issue
here,
you
select
the
project,
everything
reloads
and
then
you
add
the
title
again.
You
select
the
project,
everything
reloads,
so
quite
a
cumbersome
process
and
what
we
did
with
the
new
changes
that
gets
merged
shortly.
B
Today
is
so
when
we
create
an
epic.
Now
we
we
go
to
an
epic
and
we
want
to
create
a
new
issue.
You
see,
we
use
the
default
project
based
on
the
project.
You
have
used
the
most
recent
and
created
an
issue
in
so
use
the
events
that
we
store
there
and
when
we
create
a
new
issue
there,
like
subtitle,
we
can
now
press
enter
instead
of
using
the
button.
C
B
And
that's
basically,
it
new
experience
for
users.
B
On
the
button-
yes,
we
we
can.
I
I
tried
that
so
when
we
reload
this
epic
issue
tree
query,
it's
possible
that
there
was
just
some
error
in
a
test
and
I
thought
like
for
iteration
purpose.
I
will
not
do
that
for
now
and
yeah
so,
but
yeah
definitely
possible
to
not
reload
everything
already
like
remove
the
reloading
stuff
here,
so
it
doesn't
reload
the
whole
creation
form
yeah.
D
E
I
guess
the
error
handling
becomes
a
bit
more
difficult
in
that
case
right
because
you
kind
of
have
the
the
cards
or
the
the
issues
in
your
local
or
in
your
state
on
the
front
end.
But
if,
for
any
reason,
the
request
fails,
you
kind
of
need
to
show
that
somehow
on
the
card,
some
error
or
some
message
or
something
because
like
in
the
status,
you
have
the
issue,
but
on
the
back
end
it
didn't
save.
So
then
you
need
to
to
let
the
user
know
that
something
happened.
E
And
it
failed
like
as
a
user,
I
think
it
will
be
nice
to
show
it
to
show
an
error
on
it
or
something
or
something
because,
like
you,
have
it
in
your
front
end,
but
it's
not
actually
saved.
So
I
don't
know
how
to
handle
that,
because,
like
it's
not
very
helpful,
I
don't
think
if
you
show
a
message
at
the
top
saying
well,
some
issue
failed
to
be
saved
and
then
you
go
looking
for
which
wish
you,
which
issue
actually
didn't
save.
E
C
B
It
could,
it
could
could
happen
yeah,
but
I
don't
think
we
would
optimize
like
it
like
when
we
create
a
new
issue
and
we
prevent
creating
one
anyway
like
a
new
one
before
the
next.
The
one
is
saved,
so
you
can't
use
the
phone
before
the
other.
One
is
saved.
E
E
D
Yeah
yeah,
it's
it's
correct,
but
luckily
we
have
optimistic
response
option
in
apollo.
So
whenever
the
mutation
fails,
the
unexistent
issue
will
be
removed
automatically
from
this
list
and
an
error
will
be
shown.
B
Okay
yeah,
I
was
understanding
natalia
as
this
whole
thing
doesn't
need
to
reload
completely
all
issue
lists,
but,
like
just
add
this
last
issue
in,
although
it
refreshes
everything
again
actually
so-
and
we
would
maybe
only
block
this
create
button
for
as
an
exit,
iteration.
D
C
That's
a
good
question
from
for
me.
I
haven't
looked
at
that
issue,
yet
how
are
you
doing
with
the
docs
update
for
this.
B
Let's,
let's
check
if
there's
anything
that
we
need
to
do
yeah
thanks.
F
And
should
I
go
well,
this
is
being
discussed
before
in
other
places,
but
just
wanted
to
bring
some
awareness
in
cases
any
concerns
and
we're
getting
ready
to
start
working
on
epics
from
cross
groups.
Soup
epics.
That
means
we
go
to
an
epic
and
we
can
add
an
a
chow
epic
from
any
group.
We
want,
except
an
ancestor
epic.
These
could
mean
this
means.
We
have
to
check
permissions
for
every
new
group
in
that
collection
and
to
prevent
these
getting
too
expensive.
As
a
query,
we
consider
adding
a
limit
of
direct
children.
F
F
Alex
said,
I
think
I
agree
that
might
not
be
very
clear
when
you
get
an
error
for
that,
and
but
the
the
other
option
as
well
to
make
it
a
bit
more
flexible,
is
to
give
the
option
to
configure
this
yourself
or
remove
the
limit
and
but
from
product
perspective,
seems
to
not
be
any
issues.
So
I
have
created
an
issue
and
we're
gonna
schedule,
probably
for
fifteen
five.
F
Any
questions
or,
if
you
wanna,
add
anything
to
the
issue
because
I
might
be
missing
some
edge
cases
or
some
problems
that
I
haven't
considered.
So
I
just
wanted
to
bring
it
to
the
team
for
that.
C
E
And
I
cannot
have
more
than
100
children
within
it.
E
I
don't
have
to
to
constantly
keep
in
mind
that
well
here
I
have
the
limit
because
it's
coming
from
at
least
two
different
hierarchies,
but
here
I
don't
have
the
limit,
because
it's
just
from
a
single
hierarchy
and
then
I
don't
think
we
that
it's
that
easy
to
kind
of
understand
from
which
hierarchy
every
single
epic
is
coming
from
so
yeah.
If,
if
that's
not
an
issue,
I
think
it
would
be
nice
to
just
keep
it
as
a
single
limit.
B
And
I
was
wondering
if
we
need
to
implement
this
limit
at
all,
or
could
we
just
state
and
drop
like
we
only
have
two
epics
that
have
more
than
100
issues
as
children
should
we
maybe
just
state
like
after
that
amount
it
may
cause
performance
issues.
That
would
be
like
a
nice
duration.
We
don't
need
to
do
anything
except
for
adding
docs
and
it
actually
doesn't
affect
any
user.
Most
of
the
time.
F
Yeah,
I
think
my
my
concern
would
be
that
once
the
data
is
created,
this
error
will
will
not
remove
the
children
there
are
over
a
hundred.
They
will
just
show
an
error
every
time
you
try
to
add
a
new
one.
So
if,
in
I
don't
know
in
a
year
time,
we
realized
there's
many
epics
with
many
children
and
a
lot
of
patients
are
slow.
F
F
This
is
how
bad
you
could
get
with
these
queries
that
are
performing
so
many
permissions
check.
But
yeah.
That's
that's
a
good
question.
We
could
just
not
do
it
for
now.
G
I'll
voice
over,
I
think,
whenever
possible,
if
we
know
that
a
user
taking
a
specific
action
will
get
them
into
a
bad
state
right,
whether
it
be
performance
or
bad
data,
whatever
it
is
right,
we
should
prevent
it
as
much
as
possible
if
we
know
that
it's
gonna
have
a
bad
side
effect
in
the
future.
G
Documentation
is
like
as
much
as
we
would
want
users
to
read
it.
It's
not
something
that
they
read
all
the
time.
Sorry
martian
so
as
much
as
possible
right
if
something
as
simple
as
putting
a
limit
on
the
number
of
children
will
prevent
pain
for
themselves
in
the
future.
We
should
do
that
and
other
actions
like
that
right.
That's
one
example.
F
And
another
important
thing
that
I
didn't
mention
and
these
children
are
being
loaded
together
with
the
issues
of
the
epic
and
the
issues
of
the
epic,
are
just
changing
now
to
also
allow
issues
from
any
group
or
project,
and
so
that's
adding
a
lot
of
well,
it's
another
expensive
query.
You
know
many
other
permissions
checked
and
that's
no,
I
don't
think
that's
being
considered
to
be
a
limit
at
the
because
I
think
there's
more
use
maybe
to
have
a
thousand
issues
in
an
epic.
F
So
this
is
also
considering
that
the
whole
query,
the
query-
is
pretty
intense
already
because
it's
loading
all
issues
all
epics
and
a
lot
of
metadata
for
each
item
as
well,
so
yeah
it
was
mostly
preventing.
A
A
I
don't
expect
you
to
know
the
answer
off
the
top
of
your
head.
You
do
you
know
like,
but
is
there
like
a
kind
of
like
a
technical
solution
to
this
like
or
our
group
level?
Permissions
checks
just
always
going
to
be
expensive.
F
F
F
It
would
be
great
if
we
could
improve
group
that
also
affects
labels
and
other
stuff
that
are
at
the
group
level,
and
also
because
groups
inherit
permissions
from
projects,
and
we
not
only
check
the
the
groups.
The
new
groups
are
going
to
check
their
projects
as
well,
so
those
can
be
expensive
up
to
a
hundred
children.
For
now
it
seems
like
it
shouldn't
be
a
problem,
so
if
we
could
limit
to
a
hundred
children,
I
think
at
least
I
would
feel
a
bit
more
like
this-
wouldn't
be
a
terrible
problem,
but
yeah.
A
F
Maybe
you
can
optimize
permissions
there,
but
at
the
moment
that
query
that
gets
all
the
child
items
it's
a
bit
more
performance
from
epics
is
going
to
be
than
for
issues
and
the
limit
was
going
to
help
epic,
but
no
issues.
It's
it's
a
bit.
I
wish
there
were
only
one
type,
but
I
don't
know.
If
maybe
we
can
make
two
queries,
maybe
I
don't
know
but
for
now,
if
it's
not
a
problem,
we
don't
have
to
fix
it.
E
E
F
To
be
able
to
create
the
link,
you
need
permission
to
admin.
The
the
parent,
epic
and
admin,
the
child,
epic,
and
also
super
epics-
has
to
be
enabled
in
both
groups
as
well.
E
F
Yeah,
yes,
if
you're
only
in
one,
but
you
know
you
can't
see
the
other
group
you
couldn't
they
they.
What
it
means
is
some
epics
can
have
children
that
you
wouldn't
see.
Despite
your
role.
E
H
C
E
Is
more
of
a
question
to
the
authorized
group
in
the
sense
that
all
of
these
permissions
calculation?
I
think
it's
it
it's
very
much
related
to
how
like
we
share
groups
into
one
another.
So
there
is.
I
I'm
not
sure
if
there
is
any
optimization
going
on
with
that.
F
E
I
Okay,
so
I'm
gonna
demo
adding
a
start
date
and
due
date
onto
a
task
which
is
currently
in
a
review
in
my
mr,
so
so
on.
The
left
side
is
what
you
see
when
you
have
permission
to
add
and
edit
dates
and
then
on.
The
right
is
what
you
see
when
you
don't
have
permission
I
so
so
so
it's
read-only
so
right
now
there
are
no
dates
and
as
an
editor,
I
can
see
two
buttons
clicking
on.
One
lets
me
up
well.
I
And
and
we've
added
a
logic
here
to
mimic
the
gitlab
ui
date,
picker
range
component.
So
if
I
select
a
start
date,
which
is
which
falls
after
the
due
date
and
then
it
automatically
updates
the
due
date
to
that
same
date
and
prompts
you
to
select
a
new
date
and
then
again
selecting
that
updates
it
for
everyone
in
real
time
and
then
I
can
also
delete
these
dates.
I
Okay,
so
if
there's
no
questions,
then
I'll
pass
it
on
to
the
pica.
C
C
J
So
the
first
one
is,
I
think
everyone
must
have
seen
the.
J
J
So
you
can
see
it
here.
It's
added
and
the
other
has
that
I
worked
on
is
infinite
scroll
for
assignments.
So
let
me
just
show
it
to
you
one
yeah.
So
it's
on
production
items,
it's
a
very
small
feature,
nothing!
Fancy
we
just
so
right
now
on
production.
Before
this,
when
you
load
the
chinese,
we
didn't
have
infinite
scroll.
We
didn't
have
more
loading
users.
J
J
We
just
added
it
here
for
now
and
as
you
scroll,
you
can
like
load
more
assignments
here,
because
this
list
is
a
little
too
long.
I
can
show
it
to
you
in
my
local,
where
the
list
is
small
and
then
maybe
you
can
just
see
that
it
just
ends
and
yeah.
So
it's
just
yeah,
so
we
reached
the
end
of
the
list
and
because
it's
a
polo
once
it's
loaded,
if
you
focus
on
it
again,
the
list
is
pretty
much
loaded
and
we
don't
need
to
load
it
again.
J
Yes,
we
will
definitely
and
that's
another
so
so
the
footer
is
not
sticky
right
now.
Definitely
that's
another.
You
know
a
follow-up
issue
has
been
created
where
footer
has
to
be
sticky
and
since
it's
a
token,
selector
improvement.
So
that's
open
and
that's
that's
a
valid
point,
but
definitely
it
will
only
be
visible
when
we
reach
the
end
of
the
list.
Yeah.
That's
that's
something.
C
K
It's
actually
I
mean
I
I
I
think
I
know
that
issue
is
already
open
to
to
add
that.
But
if
you
actually
think
of
like
when
you
would
use
that,
I
think
in
most
cases
it
would
be
that
you're
like
searching,
and
you
don't
find
anything,
and
in
that
case
it
actually
will
show,
because
you
won't
have
any
results
in
that
list
like
most
of
the
time,
you're,
probably
not
going
to
start
by
like
going
to
invite.
So
it
would
be
at
the
bottom
of
like
your
short
list
of
non-results.
J
J
A
Okay,
awesome
who
got
next
julian.
L
All
right,
so
I'm
gonna
demo
a
feature
that
sort
of
got
deprecated
and
reintroduced.
Why
don't
I
just
demo
a
iteration
cadence
really
quickly,
and
so
we
have
something
called
the
iterations.
There
are
time
boxes,
they're
meant
to
be
short
compared
to
milestones
or
releases.
L
It
used
to
be
the
case
that
you
had
to
manually
create
them.
You
know,
delete
them,
manage
them.
If
you
think
about
it.
The
sort
of
tasks
that
you
have
to
do
at
the
start
of
iterations
are
a
sort
of
mundane.
You
know
you
create
an
iteration.
L
The
duration
remains
the
same
from
iteration
to
iteration,
so
there
was
a
case
for
automation
and
if
you
take
that
reasoning
to
extreme,
you
might
think
that
you
want
need
the
ability
to
manually
manage
an
iteration
right.
E
H
I
can
I
can
demo
it
sorry.
My
mic
wasn't
working,
I'm
just
trying
to
raise
my
hand
to
to
demo,
but
it's
it's
working
now,
yeah
sorry
brett
is
at
an
appointment.
He's
got
that
disappointment,
so
he
is
not
here.
So,
although.
H
Okay,
cool
dollar
math,
so
previously
in
order
well
here,
let
me
start
off
with
showing
what
math
looks
like
when
we're
not
using
math
in
markdown.
H
Preview,
all
right
just
don't,
show
anything
there
previously
in
order
to
render
it
in
math,
we
would
have
to
go.
I
believe
it's
or
it
might
just
be.
One
dollar
cent.
H
Okay,
cool,
so
that's
how
we
were
rendering
math
is
a
dollar
sign
and
then
the
backtick,
the
standard
or
other
markdown
renderers
have
been
using
instead
of
backtick
two
dollar
signs,
and
this
is
what
brett
has
implemented.
Oh
actually,
I
think
it's
just
one
dollar
sign
yeah,
one.
C
E
H
E
H
H
Yeah
that
works
okay,
so
yeah
we're
still
keeping.
I
don't
know
how,
if
we
have
a
deprecation
plan
for
removing
the
the
way
we
had
it
with
backticks
or
not,
but
the
way
forward
is
going
to
be
the
single
single
dollar
sign
without
backpack.
H
All
right,
let's
hold
off
then
until
after
just
so,
we
don't
have
to
make
the
whole
video
private.
C
A
And
we're
back
unless
natalya
would
like
the
verbalized
hardpoint.
I
know
you
marked
it
as
read-only,
but
it
seems
important.
D
No
wait.
I
also
have
one
last
minute
demo.
I
just
forgot
to
add
it
to
the
agenda
previously,
but
I
let
me
quickly
share
my
screen
and
show
this
really
cool
thing.
So
previously,
when
you
were
on
the
epic
list-
and
you
were
searching
by
author,
for
example,
the
numbers
here
didn't
update
only
for
the
active
tab,
which
would
be
open
and
rest
of
them
were
just
provided
from
haml
and
never
updated,
and
thanks
to
the
effort
from
stanislav,
like
it
was
really
nicely
implemented,
count
on
all
the
epics.
D
Now
we
have
everything
properly
updated,
like
all
the
numbers
on
any
kind
of
the
filter
are
updated
in
real
time
and
the
only
little
fix
is
now
when
you're
loading,
the
page.
We
don't
show
them,
because
otherwise
we
would
be
calculating
them
two
times,
one
from
the
hammel
and
one
from
the
graphql
query.
I
don't
think
it's
a
big
disruption
for
the
loading
moment,
but
I
really
like
how
the
updated
numbers
now
are
reflecting
the
actual
effects
count.
D
D
I
mean
we
could
we
could
do
this
with
hamel,
but
it
would
mean
we
count
them
two
times
and
performance
is
not
really
the
best
on
retrieving
the
epic
count,
especially
for
gitlab.org
group,
which
is
a
lot
I
just
prefer
to
page
them
from
graphql
and
again
it
was
suggestion
from
stanislav.
So
all
the
props
to
him.
D
D
It's
right
now
in
a
very
row,
drafty
state,
because
again
it's
high
level
and
I
only
managed
to
add
terminology,
motivation
and
some
goals,
not
all
goals,
definitely
and
not
all
problems.
So
if
you
have
any
ideas,
what
should
be
added
to
this
first
iteration
or
to
the
next
iterations,
please
jump
in
and
add
it
there.