►
From YouTube: Plan | Stage Weekly Sync 2022-02-02
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
Okay,
cool
plan
weekly
meeting
okay,
another
day
2nd
of
february
2022.,.
B
Sure
hi,
so
I've
been
wondering
like
what
would
you
know
about
kristen's
move
to
foundations?
Has
it
happened
already
like
fully
or
like?
What's
up
with
like
product
planning
pm.
C
I
can
attempt
to
answer
that
and
then
maybe
we'll
have.
I
will
ask
melissa
to
to
update
the
doc,
but
yes,
the
move
has
happened,
as
of
I
believe
last
friday
was
her
was
her
last
official
day
on
plan,
but
she's
also
out
this
week.
I
think.
C
But
yeah
she's
on
foundations.
Now
I
mean
luckily
she's
she's
still
at
gitlab.
So
if
we
have
any
questions
or
need
anything,
we
can
reach
out
to
her,
but
for
the
most
part,
melissa
has
taken
over
pm
responsibilities
for
product
planning.
C
So
any
any
questions
you
have
that
you
think
don't
maybe
require
kristin
to
answer,
send
it
over
to
melissa
who,
I
think
is
still
out
and
if
she
is
feel
free
to
send
it
to
me
and
then
I
can
route
it
to
the
to
the
right
place.
The
plan
is
to
backfill
on
product.
I
believe
they're
actively
looking
for
for
that,
but
I
also
hopefully
will
get
someone
in
there
fairly
shortly
and
then
I
can
jump
unless
anyone
yeah
no
oh
alexis.
D
C
You
want
to
answer
b,
alexis.
B
D
Yeah,
I
think
we're
we're
figuring
out
like
how
much
I'm
kind
of
like
interim
backfill,
but
we
are,
we
do
have
a
rack
open
and
we're
like
actively
looking
right.
Now
we
just
hired
someone
for
compliance,
so,
like
things
are
happening
and
I'm
hoping
it
happens
fast,
but
we
do
have
that
role
open
and
we
are
backfilling
and
I'm
like
supporting
as
much
as
I
have
capacity
at
the
moment.
D
We're
also
getting
secure
designers
to
help
with
like
reviewing
mrs
and
things
like
that,
so
we're
kind
of
figuring
it
out
bear
with
me
as
we
do
that
but
yeah
we
are
looking
to
hire
and
then
hopefully,
at
some
point,
we'll
hire
for
certify
as
well,
but
first
project
management.
E
A
Yeah,
I'm
scared
to
say
yes
in
case
they
suddenly
get
rapidly
taken
off
office,
but
yeah
I'm
expecting
one
back
end
for
product
planning
imminently,
so
I
could
get
the
ping
from
glassdoor
any
any
time
we'll
have
two
hires
in
q1.
A
I
think
there
are
nine
roles
opening
throughout
the
year,
at
least
as
it
currently
stands,
and
I
linked
a
few
things
there
as
well.
The
fy
23
direction
item
from
eric,
which
says
that
we're
like
specifically
that
we're
gonna
ramp
up
hiring
across
the
company,
possibly
to
levels
we
saw
a
couple
years
ago.
I
don't
know
and
don't
forget
the
rules
around
referral
bonuses,
and
you
can
check
the
job
board
and
yourself
as
well
and
check
out
what
roles
we
have
available.
It's
likely
like
we'll
have
some
kind
of
pooling
system.
A
So,
even
if
you
refer
somebody,
you
know
we
might
have
a
role
elsewhere,
that's
more
suitable
for
them.
So
yeah
tom.
C
Yeah,
so
the
other
open
position
is
on
the
front
end
side
specifically
for
product
planning.
Also
so
yeah,
hopefully
that'll
be
open
this
week
same
thing.
If
you
have
any
referrals,
send
them
in
internally
too,
I'm
okay
with
poaching
people
from
maybe
not
within
dev.
C
Oh
yeah,
so
speaking
of
julian
is
I
don't
know
if
it's
official
official,
because
it's
not
changed
in
the
team
page
but
he's
been
working
on
converting
from
front
end
to
back
end
and
for
the
past
few
months
he's
been
doing
mostly
back
end
anyway.
So
I
don't
think
any
there's
going
to
be
much
change
to
his
capacity
or
what
he's
working
on,
but
he
is
officially
on
project
management
back
end
now
so
yeah
congrats
julian.
A
So
epic
dependencies
for
those
who
don't
know
we
have
a
large
customer
who
is
very
interested
in
this,
so
we're
going
to
try
and
deliver
this
quite
a
short
time
frame.
We
have
a
spike
issue
to
scope.
Item
weight
back
end
work,
that's
linked
there.
Eugenie
is
the
dri
the
due
date,
for
that
is
the
14th
of
february.
That
gives
us
enough
time
to
kind
of
schedule
or
refine
the
tasks
further.
A
If
we
think
we
can't
get
everything
done
in
in
one
milestone,
so
I
thought
it'd
be
good
opportunity
to
use
this
meeting
to
ask
what
are
everyone's
main
concerns
that
may
block
or
slow
down
the
work
so
that
we
can
get
ahead
of
any
of
these
and
maybe
even
resolve
them
in
advance.
So
alexandria,
you
had
a
couple
of
concerns.
E
Yeah
so
like
the
the
first
ones
that
come
to
mind
are
basically
how
do
we
handle
permissions
for
the
shirt
epics
and,
like
more
so
I
think
the
problem
is
when
you
share
between
different
hierarchies-
and
I
I
guess
initially,
I
thought
of
it
somewhat
differently,
but
in
the
light
of
your
comments
below
that,
you'll
localize
is
perhaps
where
maybe
this
is
already
solved
for
the
related
issues
and
and
we
can
borrow
the
logic
and
the
functionality
from
there,
so
that
that's
one
concern
the
other
one
was
regarding
the
performance
specifically
like
when
you
have
related
epics,
and
you
want
to
list
them
in
in
any
kind
of
listing
view,
be
it
lists
or
boards
or
where
roadblocks
or
not
whatnot.
E
E
Maybe
that's
not
a
concern
for
the
nvc.
If
we
stick
only
with
the
with
the
widget,
like
you
can
only
view
related
epics
within
viewing
one
epic
and
then
you
click
and
just
view
the
related
things,
but
eventually
that
will
come
up
as
a
question.
I
think
as
a
as
a
issue.
E
The
third
one
is
the
we
did
not
yet
migrate,
the
epics
into
work,
items
or
issues,
so
adding
the
related
items
is
kind
of
adding
to
that
pile
of
things
that
need
to
be
done,
but
yeah.
I
I
don't
think
there
is
a
way
out
of
that
in
the
short
term.
If
you
want
to
do
that,
we'll
kind
of
have
to
duplicate
the
code
and
then
clean
it
up
afterwards.
I
guess.
A
All
right,
let's
take
them
one
by
one,
so
the
first
one
was
permissions,
handling
permissions
between
shared
epics,
so
yeah
like
we're,
not
doing
hierarchies
shouldn't
matter
too
much,
because
currently
you
can
relate
to
issues
that
are
anywhere
in
the
in
the
whole
system.
What
matters
is
like
whether
you
can
see
them
or
not
afterwards,
so
we
and
when
you
you
know
when
it
suggests
issues
to
link
it
suggests
only
from
your
own
project.
So
it's
likely
when
you
it
will
suggest
epics
only
from
your
own
projects
or
groups
group
hierarchy.
A
E
E
Performance,
I
think
we
kind
of
run
this
permission
check
for
every
single
item.
So
if,
if
the
list
is
long,
then
you're
gonna
have
this
performance
hit,
I
don't
think
there
is
an
easy
way
right
now
to
say
give
me
only
the
linked
issues
that
I
have
permissions
to
read
or
something
not
like
in
one
simple
query,
I
think
what
we
do
is
we
load
them
all
into
memory
and
then
kind
of
filter
out
what
we
got
and
return
only
the
ones
that
you
have
permissions
to
do
to
view.
A
I
know
there
are
some
parts
of
I
think
it's
maybe
the
board
or
somewhere,
where
you
can
see
the
number
or
you
can
filter
an
issue
list
by
the
number
of
blocked
issues
right,
so
you
can
say
show
me
all
or
sorry
you
can
sort
them
by
the
number
of
blocked
issues.
So
show
me
everything
in
order
of
which
is
most
blocked
or
most
blocking,
but
like
we
won't
do
that
in
the
first
iteration,
at
least
for
epics.
A
E
Again
for
the
mvc,
that's
probably
not
an
issue
if
we
are
only
going
to
only
use
the
the
widget
within
the
show,
epic
page,
basically,
but
eventually
that
that
will
come
up.
A
E
I
would
actually
argue
that
maybe
just
simply
copy
pasting
like
really
duplicating
code
is
the
easiest
way
because
then
you
don't
have
to
think
of
how
do
you
split
it
like
how?
How
do
you
reuse
code
right?
You
can
simply
ignore
that
code,
while
like
handling
whatever
issues
is
doing
but
yeah.
That's
that's
up
to
up
for
a
discussion
because
then,
like
at
least
from
high
level
to
me
seems
like
that
stuff,
like
duplicate
code,
that
we
can
just
remove
right
because
it's
really
isolated
to
only
epics
and
so
on
and
so
forth.
E
So
we
can,
we
can
drop
it
and
not
care
about.
How
does
that
affect
the
issues
code
or
some
other
parts
of
the
code.
G
E
G
Yeah
we
can
discuss
on
the
issue
if
it
makes
sense
to
clone
it
or
just
share
the
code.
If
possible,
it
might
not
be
possible
or
might
not
make
sense,
but
we
should
just
make
sure
that
all
the
time
there
is
compatibility
from
user
perspective
about
the
behavior,
because
then,
if
there
is
not
compatibility,
it
will
be
very
hard
to
migrate
it
later
to
work
items.
A
Cool
I
had
to
sorry,
I
guess
we're
out
of
order,
but
second
concern
was
that
currently
the
the
related
issues
work
works
entirely
over
the
rest
apis
and
ideally,
we
would
just
recreate
everything.
So
I'm
fine
in
this
instance
from
my
opinion,
it's
okay
to
do
everything
in
rest,
but
I
have
a
link
here
from
a
query
to
the
customer.
I
don't
know
if
it'll
be
visible
to
everyone,
but
it
seems
like
they
prefer
to
use
the
graphql
api
and
they
have
quite
a
large
integration
with
their
current
provider.
A
I
mean
like
it's
a
substantial
piece
of
software
built
on
top
of
what
they
currently
use
for
agile
planning
and
there
seems
to
be
an
indication
they
prefer
the
graphql
api.
I
think
if
we
could
cut
that
out
of
the
first
iteration,
it
would
be
much
easier.
I'm
not
quite
sure
how
to
do
that.
I
think
we
have
to
clarify
it
with
the
tam
and
possibly
melissa
as
well.
E
E
I,
like
I,
don't
know,
I
guess
that's
something-
to
discuss
with
the
customer
themselves
like.
Is
it
acceptable
for
them
to
get
the
ui
functionality
first,
or
maybe
they
really
want
instead,
like
they
don't
care
about
the
ui,
because
they
use
these
custom
things
that
they
built
throughout
our
api
and
then
we
should
not
be
focusing
on
the
widget,
but
we
should
be
rather
focusing
on
the
api
right
so
but
like
obviously,
if
we
can
split
into
two
different
things,
then
it
will
be
like
we'll
narrow
down.
E
The
scope
will
be
easier
to
deliver
one
more
or
the
other.
The
thing
is
like
on
the
back
end,
the
main
functionality
will
still
be
done
in
in
services
like
related
epics,
finder
or
creator,
or
what
what
not
and
then
those
will
be
used
in
either
rest
api
or
graphical
api,
but
yeah
making
sure
if
like
if
we
can
deliver
things
incrementally
first
deliver
this
and
then
deliver
that.
I
think,
obviously
that
cuts
on
the
scope.
C
Yeah,
that's
a
great
sorry
eugenia,
just
real
quick
that
that's
a
great
point
now
it's
andrew
in
that!
That's
something
we
should
ask
the
customer
what
they
prefer,
because
I
don't
think
we
want
to
or
we
can
aim
to
get
both
done
in
refactoring,
that
widget
to
graphql
and
and
releasing
like
yeah.
I
don't
think
we
can
do.
C
A
No,
but
and
I'll
let
eugenie
has
done
more
investigation
than
me
on
this
like,
but
to
be
honest,
I
I
don't
even
think
that's
what
they're
asking
for,
because
I
think
what
they
want
is
to
be
able
to
quantify
the
actions
people
are
taking
in
the
ui,
so
people
will
relate
epics
amongst
teams
used
in
the
ui,
but
they
want
to
be
able
to
draw
all
that
data
into
their
system,
so
they
can
observe
it
at
a
macro
level.
So
it's
not
that
we
would
rewrite
the
whole
thing
in
graphql
on
our
site.
A
We
would
still
do
everything
over
rest,
but
we'd
need
to
add
something
to
the
graphql
api.
That
would
specifically
allow
them
to
say
give
me
all
related
epochs
to
this
epic
or
all
blocking
apps,
so
they
can
build
the
tree
in
their
own
product
as
well.
So
jc
want
to
say
so.
It's
not
like
we
would
have
like
a
create
relationship
or
create
epic
relationship
mutation
and
all
that
extra
stuff.
Just
that
we
would
have
a
way
to
query
it
using
the
graphql
api.
I
still
would.
Rather,
we
didn't
include
it
in
the
first
mvc.
F
F
But
what
I
was
saying
is
that
there's
no
existing
support
for
graphql
for
related
issues,
so
if
it
wasn't
needed
immediately,
maybe
even
if
we
could
wait
to
build
it
for
work
items
once
they
are
merged
together,.
A
Yeah
see
that's
what's
most
worrying
to
me
like
is
that
we
don't
have
a
precedent
for
it
everything
else.
We
have
a
precedent
for,
and
it's
quite
already
challenging
to
build
everything
in
one
milestone
night,
like
I'll.
Take
a
takeaway
from
this
to
clarify
it
over
the
next
couple
of
days
and
I'll
report
back
in
the
in
the
back
end
spike
what
the
outcome
is,
but
unless
it's
a
serious
requirement
like
a
hard
requirement,
I
would
hope
that
we
could
just
do
everything
to
just
copy.
F
E
I
would
assume
it's
ultimate
but
yeah,
given
that
sub-epics
are
ultimate
this.
These
are
not
sub-ethics
but
like
feel
somewhat
in
that
same
area
of
solving
the,
like,
it
kind
of
solves
the
same
thing
I
think,
like
you
know
in
a
slightly
orthogonal
way,
but
but
yeah.
It
feels
like
it's
like
again.
This
is
obviously
not
an
answer.
Announcement
question
that
I
would
answer
is
probably
a
pm
question,
but
no
yeah.
E
A
A
Can
somebody
else
take
a
take
away
to
clarify
this
with
the
pm,
because
we've
no
pm's
on
the
go?
I
have
a
takeaway
already.
G
Yeah,
so
my
expectation
would
be
a
little
bit
different.
I
would
expect
that
this
feature
is
available
on
the
same
level
as
a
pixar
and
the
additional,
and
I
think
that
for
issues
the
blocking
and
blocked
by
relationship
is
some
licensed
feature.
So
I
would
expect
that
this
would
be,
and
if
it's
ultimate
I
would
expect
this
would
be
ultimate
too,
but
I
would
expect
that
basic
relation
is
available
on
the
same
level
where
I
can
use
epics
but
yeah
as
mentioned
it
depends
on
product
decision.
C
Yeah,
so
the
I
was
just
wondering
how
we
expect
the
this
widget,
the
related
widget,
to
look
visually
next
to
the
current
epic
tree.
Are
we
still
planning
on
having
both
and
just
laying
it
next
to
it
or
just
yeah
alexis?
If
you've
had
an
opportunity
to
look
at
that
or
not
yet.
D
Yeah
I'm
going
to
look
into,
I
think
the
epic
dependency
issue
I
know,
or
maybe
talk
with
gabe
about
requirements
a
little
bit
more,
but
I'm
thinking
they'll
probably
coexist
at
least
for
a
bit
because
they're,
you
know
different
solving
different
problems.
So
that
could
be
the
case,
at
least
for
mc.
E
Like
it
feels
like
this
ties
a
lot
into
the
widgets
on
the
work
items
right,
because
we
will
have
a
lot
of
widgets
down
the
line
related
blocking
whatnot,
like
whatever
users
can
define
so
yeah.
This
is
something
that
will
pop
up
more
and
more
as
we
move
on
towards
the
the
work
items
I
are,
something
like
for
requirements
would
have
test
cases
or
related
requirements,
or
things
like
that
as
well
right,
so
you'll
have
multiple,
this
kind
of
sort
of
boxes,
widgets
somewhere
placed
on
the
page.
I
guess.