►
From YouTube: Plan | Weekly Sync 2022-07-20
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
plan
stage,
meeting
20th
of
july
2022
have
the
first
two
items.
Yes,
so
welcome
to
plan
nicholas
doolar,
so
nicholas
joins
us
from
the
growth
team
and
he
joins
us
as
a
senior
back-end
engineer
on
the
product
planning
team
nicholas.
Why
don't
you
tell
us
a
little
bit
about
yourself
using
if
you
wish
the
headings
underneath
yeah?
I
will.
B
Try
to
stick
to
them
since
they're,
given
to
me
yeah,
hey
everyone
super
excited
to
join
you
it's
my
second
week
now,
so
it's
not
super
fresh
but
yeah.
As
you
ask
in
the
in
the
gender
I
was
in
at
gitlab
now,
I'm
with
like
now
for
three
years
and
last
year
I
was
a
manager
in
growth
and
I
moved
back
to
ic
and
yeah.
B
Now,
I'm
I
was
looking
for
like
something
that
is
maybe
more
user
facing
something
where,
like
I
see
myself,
using
features
of
kit
lab
itself
and
yeah.
Also,
my
girlfriend
is
using
gitlab,
so
I
can
also
get
her
complaints.
That's
that
was
also
one
of
the
parts
that
made
me
go
for
plan,
and
so
I'm
located
in
vienna,
austria
and
the
other
part
of
like
what
doing
outside
of
work
in
summer,
mostly
road,
cycling
in
winter.
B
If
kobe
isn't
there,
I'm
usually
playing
ice,
okay
and
otherwise
playing
drums
in
a
band
and
not
good
at
playing
piano,
but
like
doing
it
for
fun.
For
myself,
I
think
that
that
sums
it
hopefully
up.
A
Awesome
very
welcome
yeah
and
it's
a
twofer
which
I
understand
is
north
american
english
slang
for
a
two
for
one
offer
or
a
deal
involving
where
you
get
two
for
one.
So
we
also
welcome
stanislav
dub
revolt.
She's.
That's
please,
don't
you
can
correct
my
pronunciation
on
your
surname,
oh
thumbs
up
cool
and
you
take
stass
right
as
your
nickname,
cool
and
so
stash
joins
us
on
the
product
planning
group,
also
as
a
back-end
engineer
staff.
Why
don't
you
tell
us
a
little
bit
about
yourself.
C
Yeah
hi
everyone,
I'm
stass
yeah
like
originally
I'm
from
moldova,
but
I,
like
I,
moved
to
germany
like
five
years
ago,
yeah
and
since
then
living
in
germany,
berlin
yeah.
Regarding
the
my
work
experience
like
most
of
my
work,
experience
is
gained
on
the
backend
focused
positions
and
after
moving
to
germany,
I
was
working
mostly
in
like
local
berlin
startups.
C
So
gitlab
is
my
first
place
of
work
like
such
a
scale
yeah
and
regarding,
like
the
free
time
in
my
free
time,
out,
work
usually
like
I'm
cycling
or
spending
time
with
my
dog
or
doing
buff
at
the
same
time,
actually
just
pretty
small.
So
it's
easy
to
take
her
to
cycling,
trips,
yeah
and,
I
think
yeah.
That's
it
like.
I'm
really
happy
to
join
the
team
and
looking
forward
to
everyone
and
yeah
work
together,
build
cool
things
and
yeah
enjoy
the
process.
A
Awesome,
it's
awesome
to
have
you
on
the
team.
You're
very
welcome
cool
so
straight
on
to
issue
specific
discussion
and
demos,
then,
so
I
have
to
the
first
item
here.
I've
linked
the
feedback
issue
that
I
have,
I
think,
there's
also
an
epic
as
well
donald
you
shared
so
for
tasks
and
planning
hierarchies.
We
obviously
missed
the
delivering
this
in
the
last
milestone
got
some
robust
feedback.
A
So
my
main
concern
currently
is,
as
we
burn
down
tasks
in
this
issue,
how
can
we
ensure
that
changes
are
visible
to
all
stakeholders
as
they're
made,
and
should
we
have
a
single
source
of
truth
project
or
group
where
we
can
guarantee
that
both
or
all
feature
flags
are
switched
on
at
any
one
time?
For
our
internal
testing.
D
D
D
But
I
don't
think
that's
generally
what
we
want
to
do
with
feature
flags.
So
again,
my
question
is:
should
we
should
we
stick
to
projects
or
groups
when
we're
adding
context?
Personally,
I
feel
like
we
should
do
groups
just
because
it's
easier
to
turn
it
off
for
a
group.
But
if
there's
reasons
why
not,
then,
then
we
can.
C
D
Far
as
what
group
we
should
have
it
turned
on,
I
mean
we
should
probably
have
it
at
least
on
planned
stage
on
the
planet
stage
group.
If
we
want
to
open
it
up
to
another
group-
and
I
think
gabe
just
gave
that
a
comment
there
so
gabe
you
wanna
verbalize,
yours.
E
Sure
any
reason
not
to
use
gamelaborg,
you
can
get
upcom
all
the
ones
that
we
have
tasks
enabled
for
already.
We
we
decided
not
to
disable
it,
because
we
want
more
feedback
and
it's
already
sort
of
out
there,
at
least
within
the
company,
and
so
I
don't
know
some
of
the
feedback's
been
brutal.
But
it's
better
than
my
opinion.
The
weather
the
storm
would
get
that
feedback.
Then,
and
not
so
that's
just
my
two
cents.
F
Yeah
only
concern
I
could
think
of
if
we
would
enable
it
for
the
whole
developer
group
is
that,
for
example,
we
would
have
to
do
some
migration
later,
for
example,
if
we
enable
it
now
and
then
decide
later
that
confidential.
F
G
So
there
is
a
trade-off
that
we
can
potentially
expose
some
sort
of
a
confidential
issue
through
the
hierarchy
one
way
or
another,
because
we're
not
handling
confidential
tasks,
issues
relationship,
just
yeah,
which
leads
to
my
like
later
point.
That
feels
like
that's
the
major
blocker
in
really
releasing
this
tasks
thing
to
general
availability
like
it's,
not
a
concern
for
our
testing
group
like
we
can
definitely
have
that,
enabled
there
and
whatnot.
But
but
I
don't
know
if
we
can
do
that
for
gillab
work.
G
F
A
F
F
So
we
mentioned
three
feature:
flags,
I'm
not
sure.
If
the
null
mentioned
the
here
are
hebrew
flag
as
one
of
these
and
if
the
plan
is
to
release
the
hierarchy
feature
flag
before
or
together
with
tasks,
because
now
we
are
discussing
tasks,
release
and
in
previous
milestone,
we
decided
to
release
task
without
hierarchy.
F
D
I
both,
I
think
hierarchy
is
the
hierarchy.
Feature
flag
is
turned
off
for
gitlab.org
and
gitlab.com
right
now,
but
it's
on
for
plan
stage,
so
we've
been
testing
it
together
internally
on
plan
stage
internal
within
our
stage,
but
then
we've
been
testing
it
with
just
the
work
items
feature
flag,
so
core
tasks
in
gitlab,
common
klab
work.
G
D
G
Even
if
even
given
that
the
hierarchy
feature
flag
is
not
enabled
like,
I
can
test
it
after
the
meeting,
but
I
feel
like
we
may
already
expose
that
through
the
breadcrumbs
and
whatnot,
even
without
the
hierarchy
widget
enable
because,
like
we
already
create
behind
the
scenes,
we
already
do
the
linkage
between
the
task
and
the
issue
and
and
if
you
do
a
task
within
a
confidential
issue,
I
wonder
if
we
already
expose
it
in
some
way
or
another.
E
E
That
makes
sense,
and
I
think
that
you're
right
that
that's
all
we,
if
that
wasn't
a
problem,
we,
I
would
have
encouraged
us
to
release
tasks
with
15
to
2,
and
we
came
up
with
plan
b,
which
is
the
breadcrumbs
if
the
parent,
if
the
hierarchy,
which
it
wasn't
done,
but
it's
also
a
value,
add
if
we
can
ship
the
hierarchy
widget
with
tasks
it
like.
We
got
the
feedback
that
it's
sort
of
confusing.
E
I
would
expect
to
be
able
to
create
a
task
from
somewhere
else
and
see
the
task
somewhere
else
and
there's
like
two
primary
use
cases.
There's
the
one
where
you
have
description
templates
already
that
have
a
bunch
of
checklists.
You
want
to
convert
one
of
those
to
a
first
class
task
and
then
do
all
the
things
that
you
can
do
with
work
items
and
then
the
other
is
like.
E
I
I'm
I'm
sort
of
maybe
a
non-developer,
and
I
don't
like
description
templates
and
I
want
to
just
create
a
task
directly
on
an
issue
which
is
a
hierarchy
widget.
So
if
we
can
ship
both
at
the
same
time,
I
think
it
covers
more
personas
that
will
be
exposed
to
this
feature
and
it'll
help
it
get
more
traction
and
make
it
more
sense.
So
if
it's,
I
don't
know
where
the
hierarchy
widget
is.
E
H
Yeah,
I
I
think
like
going
through
the
the
feedback
and,
in
particular
the
feedback
from
the
ux
team.
A
lot
of
it
is,
I
think,
arising
from
the
fact
that,
like
there's,
nothing
right
now
on
on
gitlab
work,
that
explains
this
like
parent-child,
like
hierarchical
relationship
or
like
how
you
would
manage
this.
So
some
of
the
questions
we're
getting
are
really
just
like.
H
Oh
well,
that
would
probably
make
perfect
sense
once
you
see
this
other
component
that
we're
not
showing
you
right
now
and
you've
never
heard
of
so
you
know
the
more
we
can
kind
of
couple
those
I
think
the
more
it'll
sort
of
make
sense
to
people
when
we
roll
it
out.
A
So
currently
we
switch
the
parent-child
relationship
in
behind
the
work
items
feature
flag
right,
so
so
the
current
experience
is
that
tasks
don't
show
up
in
related
items
anymore.
They
show
up,
they
don't
show
up
anywhere
unless
you
have
the
hierarchy.
Okay,
cool.
So
regardless
of
whether
you
have
the
widget
or
not,
the
relationship
being
created
is
parent
child.
G
G
When
you
have
a
confidential
and
non-confidential
issue,
I'm
not
sure
if
our
group
is
public
or
not
but
like
basically,
the
test
would
be
create
a
confidential
issue
at
a
task
and
then
as
a
anonymous,
try
to
access
that
issue
and
see
if
you
or
try
to
access
the
task
and
see
what
you
see
so
basically
make
sure
that
the
the
hierarchy
widget
does
not
expose
anything
confidentially,
yes
and
and
then
we
can.
We
should
probably
be
okay,
enabling
you
for
github.
D
Yeah,
I
think
I
think
it's
already
known
that
it's
going
to
with
the
planning
hierarchy
widget
turned
on.
If
you
do
not
have
access
to
the
parent
issue.
Well,
you're
not
gonna,
see
anything,
but
you
should
also
like
there's
no
concept
right
now
of
a
confidential
task
or
work
item.
So
everyone's
going
to
see
it
that
has
access
to
the
parent
issue.
F
Yeah
I
took
the
confidentiality
just
as
an
example,
why
not
to
enable
it
for
github
work
at
this
point,
another
example
from
the
last
milestone
would
be,
for
example,
creation
of
parent-child
relationship
versus
related
to
yeah,
because
then
we
would
have
to
deal
with
both
relationships.
So
the
point
was
that
if
we
are,
if
we
are
not
sure
that
there
won't
be
any
such
changes,
it
would
be
better
to
use
a
smaller
group,
but
if
we
are
confident
it's
possible
to
enable
it
at
that
point,
when.
E
D
And
this
might
not
be
an
issue
now
because
we've,
I
think,
we've
done
a
decent
amount
of
testing
on
tasks
with
planning
hierarchy
or
with
a
hierarchy
turned
off,
but
my
only
hesitation,
with
turning
hierarchy
on
for
gitlab,
org
and
gitlab.com,
is
that
we
add
a.
We
may
have
a
hard
dependency
on
turning
on
hierarchy
feature
flag
at
the
same
time
as
the
work
items
feature
flag
where,
ideally,
we're
able
to
turn
on
the
work
items
feature
flag
for
all
of
gitlab.com.
D
A
A
I
think
the
remaining
tasks
with
that
are
cleanup
around
dux
and
creating
a
task
using
that
on
the
front
end,
all
the
all
the
back-end
mutations
are
done
and
most
of
the
front-end
design
of
the
widget
and
layout
and
everything
is
done,
and
then
we
can
just
focus
on
any
feedback
that
we
get
around
the
widget
as
well.
Since
the
parent-child
relationship
creation
has
been
moved
out
from
under
that
feature
flag.
A
I
don't
actually
think
there's
that
much
risk
involved
in
what's
under
that
feature
flag
anymore
like
it's,
not,
I
don't
think
we're
yeah.
I
mean
correct
me.
If
I'm
wrong,
I
don't
think
we're
creating
any
relationships
or
corrupt
data
or
you're.
Not
it
doesn't
enable
you
to
do
anything
that
you
can't
do
using
the
markdown
list.
You
know
so
you
can
create
non-confidential
tasks
currently
for
a
confidential
issue,
but
that
will
change
with
with
an
exchange.
So
I
don't
see
any
reason
not
to.
A
F
E
F
E
No
tasks
so
the
ability,
I
think,
what
john
was
saying,
the
ability
to
create
a
non-confidential
child
from
a
confidential
parent
via
a
markdown
checklist
is
is
still
live
on
gatelab.com
and
we're
not
gonna.
It's
not
defaulted
to
everyone,
but
it's
defaulted
to
our
group
like
gitlab
or
group,
and
we
decided
not
to
turn
it
off
just
because
it's
known
that
it's
in
alpha
beta
that
production
ready
our
documentation
says
it
right.
So.
F
So
for
hierarchy
feature
flag
itself,
I
don't
know
in
what
phase
of
testing
it
is.
So
if,
if
it
hasn't
been
yet
testing
tested
properly
on
a
smaller
group,
I
would
incline
to
enable
it
for
smaller
group
first
and
then
for
github
work.
But
to
answer
john,
your
question,
I
cannot
think
of
any
fundamental
threat
or
issue
with
any
blinking.
E
I'll
go
through
after
this
call.
I
have
a
little
bit
of
time.
I
think
and
put
it
through
the
paces
on
plan
sage
group
project
or
whatever
at
least
we
can
see
there
and
I'll
post
any
feedback
which
channel
do
you
want
me
to
post
to
be
back
in
that
or
issue
or.
A
A
Yeah,
I
just
added
a
link
there
to
an
issue
in
the
planned
stage
group
and
one
of
the
projects
they're
under
and
the
hierarchy.
Widget
is
visible,
so
we
have
it
switched
on
for
that
test
group
and
once
we're
like
satisfied
that
it's
you
know
ready
from
a
ux
standpoint,
it
does
everything
we
expected
to
do.
We
can
enable
it
as
well,
in
my
opinion,
for
the
same
groups
that
tasks
are
enabled
for.
A
E
Yeah
I
had
some
positive
feedback.
I
wouldn't
share
it.
I
just
put
it
under
anything
else.
I'm
really
proud
of
you
all
and
the
everyone
who's
here
and
not
here
and
just
like
playing
stage
as
whole.
It
was
really
cool
to
watch
everyone.
E
Collaborate
towards
the
end
of
the
last
milestone
definitely
a
little
bit
down
to
the
wire,
it's
always
fun,
but
the
it
was
just
amazing
to
watch
the
two
teams
work
together
and
everyone
contribute-
and
everyone
put
in
really
good
effort
to
try
to
get
task
watch,
and
I
totally
am
fine
that
we
didn't
because
there's
a
good
reason
why
we
didn't-
and
I
don't
hope
nobody
else
feels
like
upset
about
it.
But
I
just
want
you
to
know
I'm
proud
of
you
and
I'm
glad
to
be
on
the
team.
That's
it.
A
Yeah,
likewise,
it
was
a
an
epic
effort
last
week
to
get
everything
ready
in
time
and
everyone
made
their
best
efforts
and
it
was
out
of
our
control
in
the
end
that
it
didn't
go
out.
But
just
want
to
recognize,
like
everyone
who
stuck
around
on
friday
to
try
and
give
it
a
give
it
the
best
shot
of
making
it
in
and
in
15-2.
We
didn't
get
there,
but
you
win
some
and
you
listen.
G
We
had
next
meeting
in
two
weeks,
so
I
wonder
if
we
should
decide
like
today
to
do
a
demo
of
the
tasks.
For
instance,
then
we
kind
of
make
ourselves
get
more
prepared.
I
don't
know
just
an
idea
so
like
for
next
meeting
in
two
weeks,
demo
the
tasks
with
the
I
don't
know:
hierarchy
and
whatnot,
and
then
we
kind
of
put
ourselves
into
having
two
more
weeks
to
prepare
it
for
day
15
3.
E
Yeah,
I
can
do
that.
I
can
work
with
nick
and
alexis
and
melissa
to
do
that
from
the
parkside.
I
also
wanted
to
share
too,
while
everyone's
here
that
there
was
a
product
direction
meeting
with,
like
all
the
product
leaders
yesterday
and
there's
some
questions
about
like.
Why
are
we
building
tasks
and
all
sorts
of
other
things
anyways?
E
That
meeting
went
really
well
apparently,
and
both
ux
leaders
and
proc
leaders
were
there,
and
I
think
the
engineering
leaders
as
well
and
david
and
justin,
who
kind
of
are
the
leaders
within
product,
did
a
really
good
job
of
explaining
the
value
proposition
of
tasks
and
everyone
sort
of
got
it
and
there's
also
this
like
sort
of
aha
light
bulb
movement,
where
I
feel
like
our
leaders,
finally
sort
of
like
understood,
understood
what
work
items
and
like
why
we're
doing
what
we're
doing
and
we're
also
became
very
supportive
of
it.
E
G
G
E
It
was
a
genuine
curiosity
because
I
don't
think
like
I
did.
I
did
the
problem.
Validation
for
tasks
two
years
ago,
like
in
the
like
first
class
support
for
tasks
issue
or
epic
now,
and
so
I
was
able
to
link
back
to
all
of
my
notes
from
that
and
explain
some
of
it,
but
I
think
a
lot
of
people
didn't
understand
like
when
we're
working
on
an
issue
and
let's
say
where
we're
finding
it
either
have
to
promote
it.
E
So
you
can
break
it
down
to
have
like
different
issues
per
function
or
like
if
you
want
to
wait
front
end
and
wait
back
end,
we
right
now
we
just
pick
one,
and
so
I
was
trying
to
expose
like
well.
What
we
can
do
now
is.
We
can
have
one
issue
instead
of
like
promoting
it
and
splitting
it
out
of
issues,
you
can
just
create
tasks
and
you
can
assign
the
tasks
to
people
and
they
can
wait
the
tasks.
Then
it's
really
easy
and
I
think
they
finally
sort
of
got
that
aspect
of
it.
E
So
I'm
just
excited
about
us
being
able
to
dog
food,
and
I
think,
based
on
our
last
retro
is
once
we
can
show
tasks
on
boards,
then
I
think
it
might
be
palatable
to
use,
but
we
can
start
using
it
whenever
anyone
wants
to.
E
I
think
the
inverse
is
gonna
happen.
I
ran
some
data
on
that
and
like
right
now,
six
percent
of
users
have
the
plan.
Users
have
a
grandparent
relationship,
so
grandparent
parent
child
15
have
just
parent
child
and
79
percent
have
no
notion
of
parent
child
relationship
period,
and
so
by
introducing
this,
I
think
we're
actually
going
to
upsell
more
from
free
to
premium
because
tasks,
if
you
think
about
it,
are
still
the
parent
child
relationship
is
restricted
to
one
project.
E
The
epic
is
used
to
group
things
across
different
projects
within
a
group,
and
so,
if
you
have
those
three
levels,
that's
what
a
lot
of
premium
customers
that
I
talked
to
really
wanted
was
like.
I
need
to
have
three
levels.
Two
levels
is
not
enough
right,
but
we
don't
want
to
bring
like
do
weird
things
with
epics,
where
you
can
have
two
levels
of
x
and
then
immediate
for
ultimate.
So
this
provides
like
a
nice
like
a
breakdown
where
the
per
the
product
manager
persona
is
usually
going
to
be.
E
The
one
who
does
like
the
epic
creates
the
epic
and
then
the
sort
of
engineering
manager
or
the
product
owner
is
going
to
be
the
one
who's
working
with
engineers,
usually
to
break
an
issue
down
into
tasks.
E
E
A
That
was
an
awesome
explanation.
Thank
you,
yeah
just
I
want
sorry.
This
is
going
to
sound,
really
pedantic,
but
just
to
pick
this
thing
up
before
we
move
on
the
next
meeting
is
actually
next
week
in
apac
time
so
and
one
of
the
team
members
in
apac
is
working
on
this
feature.
So
there's
a
possibility.
We
might
even
have
a
chance
to
demo
it
in
the
next
meeting.
Those
there's
not
a
whole
lot
of
crossover.
I'm
sure
I'm
certainly
not
it's
at
5am,
my
time
or
4am,
something
like
that.
A
So
I'll
not
be
there,
but
nevertheless
there's
an
opportunity
to
to
demo.
It
then-
and
certainly
I
agree,
we
could
commit
to
demoing
it
again
in
two
weeks
and
see
how
it
progresses.
Nick.
H
Oh
yeah,
I
forgot-
I
should
probably
mention
this
yeah,
I'm
gonna
do
some
usability
testing
with
ideally
get
current
gitlab
users
and
non
gitlab
users
on
the
current
tasks,
experience,
probably
just
whatever
that
looks
like
when
I
test
it.
So
I'm
hoping
that
starts
maybe
as
early
as
next
week,
it's
kind
of
contingent
on
recruiting.
So
it's
hard
to
tell
how
fast
that's
gonna
happen,
but
that
should
also
sort
of
inform
like
how
usable
this
is
in
the
current
state
and
hopefully
calm.
Some
of
the
ux
concerns
there.
H
And
if
we
have
hierarchy
features
I'll
test,
those
too
kind
of
just
depends
where
it's
at
at
the
the
point
we
test.
A
So
quick
question:
what
do
you
use
for
running
those
tests
like
to
use
an
internal
group?
Do
you
need
it
switched
on
for
that
group
any
way
we
can
expedite
it.
H
That
part,
I
think,
is
okay.
I'm
gonna,
I'm
gonna
try
to
test
it.
Today
there
is
a
ux
sandbox
environment
like
a
basically
a
demo
instance
that
I
have
a
project
set
up
and
actually
just
like
five
minutes
ago.
Somebody
told
me
how
to
turn
on
feature
flags
for
that.
So
as
long
as
I
can
figure
out
how
to
do
that,
I
think
it'll
be
ready
to
go.
H
E
Yeah
it's
hard
to
use
gitlab.com
for
user
testing
because,
like
we,
I
know
that
ux
sometimes
does
unmoderate
user
testing
usertesting.com,
where
you
can
like
write
a
script
and
say:
hey,
go
to
this.
What
url
and
perform
these
actions
and
they
record
themselves
doing
it
and
talk
through
it
and
then
they
score
how
well
they
were
able
to
do
it,
and
I
ran
to
this
when
I
was
working
on
a
demo
for
a
customer-
is
that
if
you
created
a
test
user,
it
gets
disabled
in
three
days.
E
Unless
you
turn
two
factory
authentication
on
and
the
like,
using
two
factor,
authentication
for
a
usertesting.com
account
doesn't
work
because
then
they
don't
have
access
to
the
second
auth.
If
that
makes
sense,
so
we
have
to
like
resort
to
finding
some
sort
of
sandbox
environment
and
there's
like
customer
success
maintains
a
demo
environment.
I
think-
or
maybe
it's
sales,
but
it's
not
current
with.
What's
on
gitlab.com
the
future
flags.
So
there's
like
lots
of
interesting
nuances
that
get
it
to
get
into
some
of
the
stuff
which
is
annoying,
but
reality.