►
From YouTube: Plan | Weekly Team Meeting - 2021-09-15
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).
B
Okay
september
15th
2021,
planned
weekly
meeting
mark
martin
has
the
first
one,
but
he
asked
me
to
vocalize
it
because
he
can't
make
the
call
so
I'll
go
ahead.
Yeah
so
he's
in
14-4
he's
going
to
be
handing
over
manage
optimizing
workspace
duties
to
another
technical
writer,
so
he'll
have
more
capacity
for
non-feature
work
and
plan
docs.
So
that's
just
an
update
from
him.
Gabe
is
the
next
one.
C
Oh
hey
yeah,
so
I
was
just
going
to
verbalize
that
I
had
a
call
with
a
one
of
our
largest
customers,
if
not
the
largest
customer.
That
is
also
planning
on
moving
from
jira
self-managed
to
get
lab.
Now,
I'm
just
going
to
touch
on
a
couple
different
things
from
the
conversation
just
passing
along
in
terms
of
things
they're
most
interested
in
is
flowing
work
across
hierarchies.
C
I
think
you
know
like
how
do
you
assign
an
issue
in
from
one
sibling
to
an
epic
another
that
sort
of
problem
they're
keen
on
workflows
and
more
so
for
their
business
process
teams
than
their
dev
developer?
Teams
like
they
want
to
move
everyone,
not
just
the
software
developers
into
gitlab,
which
means
that,
like
some
for
some
of
their
business
processes,
that's
where
they
wanted
a
little
bit
more
control
over
like
enforced
workflows,
which
is
something
I'll
dig
into
with
them
and
see.
C
If
there's
any
way
that
we
can
leverage
some
of
the
stuff
that
compliance
is
doing
for
that
enforcement,
while
keeping
everything
within
plan
lightweight
and
then
I
also
talked
through
with
them
work
items.
They
were
super
stoked
about
that.
So
that
was
some
good
validation
and
then
the
other
thing
was
a
more
robust,
geriate
importer,
and
so
they
actually
wanted
us
to
to
completely
hide
the
jira
integration
or
disable
it
for
their
instance,
because
they
don't
want
people
to
stay
on
jerry.
C
They
want
them
all
to
move
to
gitlab,
but
one
of
the
things
that
they
would
like
is
they
said
just
a
big
blue
button
that
just
moves
everything
over
all
their
existing
data
right
gitlab.
So
I
said
yeah
here's
where
we're
at.
We
can
maybe
work
on
the
button
part
of
it,
but
I
think
it
was
just
generally
good
validation
that
we're
on
the
right
track.
C
And
because
they
were
asking
about,
like
those
super
complex,
what
we're
not.
C
Enforced
workflows
and
things
like
that,
and
so
I
just
basically
said
hey
here
as
of
right
now:
it's
not
that
we'll
never
do
this,
but
we're
not
gonna.
Do
it
right
now,
it's
not
on
a
road
map,
it's
not
in
the
near
term.
So
if
this
is
like
one
of
the
things
that
you're
dependent
on
to
move
over
to
gitlab,
it's,
it's
not
gonna
happen
in
the
next
three
years.
Probably
it's
like
that!
Could
change,
but
yeah.
C
It
was
good
to
also
tell
them
those
to
some
things,
and
I
think
that
was
good
for
them,
because
they
sort
of
are
okay
with
that,
as
long
as
we
give
them
an
alternative
that
works
just
as
well
to
solving
their
business
needs,
if
that
makes
sense
and
they're
also
really
interested
in
custom
fields
as
the
other
one,
but
they
said
that
they
didn't
want
us
to
build
it
unless
we
could
do
it
at
a
performance
at
scale,
because
they
were
running
into
like
a
ton
of
problems
with
that
and
jira
where
they
have
like
3,
000
or
something
dust
fields,
and
you
have
to
re-index
it
every
like
12
hours.
C
It's
like
a
nightmare,
so
just
passing
that
along
it
was
good.
It
was
a
good
conversation,
though
they
were
positive.
I
think
next
year
they
want
to
they're
playing
on
next
year,
putting
together
an
official
program
to
transition
all
of
their
twelve
thousand
eighteen
thousand
users
to
give
up
they're
playing.
A
It's
a
good
validation
about
the
custom
field.
Scale,
though,
like
a
good
kind
of
reminder
to
that,
we
can
maybe
be
a
bit
more
opinionated
about
you
know
how
how
widely
you
can
scale
that,
because,
if,
if
they're
having
problems
with
it
now,
like
it
kind
of
validates
that
we
should
put
some
sane
limits
in
place,
I
guess
oh
yeah.
D
I'm
on
here
next,
so
I
just
wanted
to
make
the
team
aware
I'm
doing
an
opportunity,
canvas
around
saved
queries
and
views,
which
is
a
new
proposed
category
that
we
have
talked
about
with
melissa
for
plan,
and
so
basically
the
idea
would
be
to
consolidate
our
query
and
the
filtering
process
around
gitlab,
because
we
have
so
many
well
even
within
plan.
D
So
in
this
example,
the
main
query
would
have
been
that
I
want
to
look
at
issues
and
features
label
group
product
planning,
milestone,
14.3
right
now.
We
just
use
list
view,
or
we
use
this
view
like
in
boards
or
other
areas
around
get
lab,
but
the
ability
to
save
that
give
it
the
name,
product
planning,
current
release
and
then
switch
the
views.
D
We
could
have
a
switch
that
adds
an
additional
filter
of
in
dev.
We
could
switch
to
look
at
the
current
board
view
of
that
release,
switch
it
to
a
burn
down
road
map
and
there's
lots
of
other.
We
could
have
this
opened
up
to
value
stream
or
any
other
charts
or
graphs
or
views
that
would
want
to
the
teams
would
want
to
add,
or
we
could
build
or
contribute
to
the
ecosystem
so
just
kind
of
putting
that
on
there.
So
everyone
can
read
through
if
you
want
to
look
at
the
whip.
D
Opportunity
canvas
that's
happening
tomorrow
with
scott
and
then
hopefully
that
will
just
help
get
some
buy-in
for
for
either
more
resources
on
the
team
and
helping
them
understand
our
road
map
that
within
a
year
or
so
is
when
we
could
start
working
on
this
with
all
the
work
on
our
plate.
So
we
want
to
keep
showing
the
new
ideas
that
we
have
and
like
and
the
resources
we'll
need
to
do
them.
F
Yeah,
I
just
had
the
third
one
around
here:
controllant
recently
upgraded
from
premium
to
ultimate,
mainly
after
talking
to
them
they're
impressed
with
their
requirements,
management,
vision
they
like
where
the
the
concept
is
going.
They
believe
that
something
they're
going
to
use
in
the
next
year
and
a
half
and
they
want
to
be
there
on
the
ground
four
to
get
used
to
it,
and
they
also
really
like
the
product
or
project
planning.
F
B
Yeah
just
a
reminder
that
I'm
still
looking
for
issues
suitable
for
new
contributors
for
the
upcoming
hackathon,
so
please
label
any
you
see
as
such
or
add
them
to
the
issue.
I've
created
yeah
that
bucket
currently
includes
issues
like
the
one
I've
linked
there.
These
are
prioritized
actually
that
one's
prioritized
for
14
3
so
imminent,
but
it's
a
weight
one
and
if
a
community
contributor
picked
it
up.
We'd
of
course
be
happy
for
them
to
do
that
as
well.
B
But
if
you
do
pick
up
an
issue
like
that,
that's
scheduled
anyway,
yeah
just
maybe
remove
that
label.
So
it's
not
confusing
for
new
contributors
yeah.
I
don't
know
whether
to
go
down
this,
but
basically
anything
that's
a
weight
one
or
a
weight.
Two
or
the
description
is
particularly
like
it's
particularly
obvious
or
a
solution
is
already
present
in
the
discussion.
Something
like
that.
These
are
all
ideal
for
first-time
contributors
and
we
want
to
grow
the
number
of
first-time
contributors
to
plan
and
it's
a
free
market.
B
So
the
more
like
refined
our
issues
are
the
more
chance
we
have
of
grabbing
some
of
that
share
during
the
hackathon.
I
don't
know
martin's
not
here,
but
he
just
mentioned
that
he'd
added
some
documentation
issues
as
well.
Yeah
they're
also
ideal
any
questions
otherwise
kristin
you
can
take
over.
D
No
questions
from
me
just
note
that
I
and
I've
heard
from
just
a
few
people
as
well
everyone
everyone
would
love
to
see
more
from
the
designers
and
that
we
would
give
them
a
specific
spot
on
the
agenda
because
often
they're
below
the
fold,
and
then
we
don't
get
back
to
them
or
we
say
we'll
take
it.
Async.
D
G
Stage
yeah,
it's
pretty
interesting
because
I'm
just
looking
through
the
through
the
our
past
agendas
and
the
times
when
we
have
design
team
previews
are
for
some
reason
the
times
where
we
actually
have
stuff
in
one
and
two
and
team
updates
and
big
picture
updates.
So
I
don't
know
if
we
may,
if
we
really
need
to
change
anything
because
more
often
than
not,
they
should
like.
G
We
should
have
time
to
get
to
three,
but
I
agree
just
being
aware
that
maybe
we
get
through
the
other
stuff
a
little
bit
quicker
when
there
is
stuff.
So
we
can
get
to
everything
especially
number
three.
D
G
Okay,
cool
and
then
I
just
put
a
note
in
there
that
I
love
to
bring
back
engineering
demos.
We
haven't
done
any
of
those
for
a
bit
and
that
would
fall
under
number
four
anyway.
So
we'd
go
after
design.
Team
previews,
but
yeah
that'd
be
another
nice
thing
to
bring
back.
D
It's
not
super
relevant,
but
it's
just
kind
of
interesting.
I
just
put
a
note
in
the
design
team
preview,
but
I'm
trying
to
give
feedback
to
another
designer
about
the
applications
like
creating
new
applications
and
our
flow
right
now.
This
is
me
trying
to
sketch
something
really
fast
to
co-work
is
strange,
like
we
don't
have
a
application,
new
application
review
kind
of
area,
it's
just
a
list,
so
it
almost
seems
like
they
need,
like
an
application
page
like
a
new
application
page
that
they
can
go
and
edit
and
copy
and
review.
D
So
that
did
just
make
me
think,
like.
Oh,
no
there's
gonna
be
so
many
items
that
are
like
almost
look
like
issue
issue
pages
or
issue
issues
in
the
future.
We
already
have
also
like
vulnerabilities
that
have
they
can
create
issues
from.
I
was
looking
at
that
yesterday
as
well,
so
just
something
to
keep
in
mind
as
we
work
on
kind
of
the
the
model
of
creating
and
editing
work
items
like
we
can
apply
that
to
other
areas
in
gitlab
in
the
future,
as
well.
D
Nope,
okay
anyway,
someone
else
can
take
it
ahead
and
just
yeah.
This
is
just
fyi,
it's
kind
of
fun
in
product
design.
One
of
our
like
top
priorities,
is
helping
out
other
designers.
So
this
is
how
I
try
to
do
it
quickly.
I
just
kind
of
sketch
things
and
they
always
kind
of
look
ugly,
but
I
don't
care
so
just
so.
You
know
that
is
part
of
my
day.
I
guess
we're
on
workflow
right,
maybe
john.
B
Yeah,
I
can
take
thanks
alexis
yeah
another
one
for
marching
first,
so
the
guidelines
for
documenting
feature
flags
has
been
updated.
B
I
think
that
was
like
a
month
ago,
but
it's
pretty
detailed
docs
now
look
so
it's
worth
checking
out
and
then
yeah
like
so
this
this
next
one
I
just
kind
of
threw
in
last
minute,
but
I
thought
it
might
be
interesting,
so
I
can
share
screen
here,
so
we
often
say
that
we,
like
de-prioritize
a
category
but
as
an
engineer
manager
like
I'm
interested
in
knowing
how
well
we
stick
to
that.
So
this
came
out
of
the
last
retrospective.
B
One
of
the
follow-up
actions
was
to
try
and
figure
out
like.
Are
we
really
deprioritizing
like
in
practice?
So
I
think
the
chart
that's
interesting
to
me
anyway.
Is
this
bottom
one?
B
This
is
the
capacity
spend
on
internal
team
members
spend
on
features
that
we
have
de-prioritized.
So
you
can
see
that,
like
the
totals,
don't
really
add
up
and
that's
because
we
don't
add
the
category
label
to
mrs
as
a
matter
of
course
it's
not
mandatory,
but
you
could
assume.
I
guess
that
it's
uniformly
not
applied
and
that
the
proportions
are
roughly
correct,
so
you
can
see
that
in
august
2021,
mrs
from
the
team
against
deprioritized
categories
were
four.
B
B
So
that's
interesting
like
because
the
only
two
de-prioritized
categories
I
have
in
this
chart
at
the
minute
are
design
management
and
service
desk,
so
for
everything,
the
product
planning
front
and
back
end
teams.
Do
we
do
about
30
in
those
categories
and,
if
you
add
up
the
remaining
categories
like
that's
about
the
proportion
you
would
expect
if
we
hadn't
de-prioritized
these
two
categories
right.
B
So
it's
a
little
interesting
to
know
that
I
mean
you
could
say
that
since
we're
not
prioritizing
the
work,
this
really
is
like
critical,
bugs
high
impact
security
issues,
critical
tech
debt.
Things
like
that
that
we
can't
actually
avoid
doing.
B
We
still
end
up
spent
in
a
significant
amount
of
time.
In
these
categories,
some
of
the
other
charts
are
to
do
with
community
contributions.
So
this
first
chart
is
the
number
of
reviews
that
team
members
do
against
community
contributions
versus
contributions
by
internal
team
members,
and
this
one
is
time
spent
reviewing
mrs
to
de-prioritize
features.
B
So
you
can
have
a
look
at
these
charts
if
you're
interested
there's
a
couple
of
improvements
need
to
be
made
like
one
thing
would
be
to
go
through
and
make
sure
everything
that
we've
done
in
the
last
six
months
is
is
categorized
by
label.
As
I
said,
we
don't
really
make
that
mandatory.
In
fact,
we
don't
make
a
mandatory
for
issues
either
it
just.
It
is
in
practice
what
we
do.
We
add
a
category
label
to
all
issues,
but
we
don't
necessarily
deal
with
mrs.
B
We
might
get
a
better
idea,
then
so
gabe
yeah,
you
had
a
point
underneath
you
want
to
verbalize
it.
C
C
That
was
my
first
point
and
then
my
second
was,
I
think,
de-prioritized
categories,
first
and
foremost,
are
meant
to
be
an
external
signal
that
we're
not
actively
investing
a
ton
of
capacity
towards
moving
something
forward,
because
a
lot
of
times
when
we're
talking
to
customers
or
sales
is
talking
to
customers
or
tams
they're
like
okay.
Well,
if
it's
a
signal
to
them
that
we're
not
actually
moving
it
forward
so
that
they
can
set
expectations
with
their
customers.
C
So
I
think
that's
one
thing,
and
then
I
did
notice
that
you
have
those
two
charts,
one
for
community
contributions
versus
our
own
team,
which
sort
of
answers.
My
second
point-
and
I
think
it's
it's
still
important-
to
support
the
water
community,
pushing
it
forward
like
deep
prioritize
things
for-
and
I
was
just
going
to
give
the
example-
lead
ticket
I've
been
collaborating
with
them
a
little
bit.
C
I'm
working
on
a
crms
feature
where
you
can
like
actually
have
organizations
and
then
contacts
within
organizations,
then
that
can
be
eventually
linked
to
like
an
issue
right.
So
then
you
could
do
invoicing
and
things
like
that,
but
I
think
it's
super
awesome
and
strategically
aligned
with
their
much
longer
term
vision.
But
I
I
wouldn't
prioritize
that
for
a
long
time
right,
but
if
he
wants
to
do
it,
I
think
that's
amazing
and
I
think
we
should
support
him.
So
there's
like
a
lot
of
factors,
I
guess
is
tldr.
B
Exactly
so
yeah,
it
is
amazing.
We
have
a
couple
of
very
motivated
community
contributors
and
the
truth
is
like
if
we
quote-unquote
de-prioritize
the
category,
but
we
have
a
highly
motivated
contributor
who
wants
to
push
some
ideas
forward
for
that
category?
Then
we
have
to
put
capacity
around
that
both
your
capacity
as
a
pm
and
our
capacity
as
a
team
to
review
and
just
help
steer
the
dmrs,
and
so
it's
not
like
making
a
judgment
one
way
or
the
other
like
to
have
a
chart
like
this
is
purely
informational.
B
I
think
it's
just
to
give
us
an
indication
of
like
what
we
want
to
do
versus
what
we're
doing
in
practice,
and
we
maybe
it
helps
us,
make
better
engineering
decisions
as
well
like
about
capacity,
because
you
know,
if
we're
going
through
a
period
where
spent
a
lot
of
time
reviewing
and
not
so
much
shipping.
Mrs
towards
features,
you
know
what
I
mean
like
if
the
amount
of
reviews
we
have
to
do
is
larger,
because
we
have
highly
motivated
community
contributions.
B
D
D
B
D
Yeah,
I
think,
ideally,
I
should
right,
like
some
designers,
don't
I
don't
know
if
y'all
saw
what
I
posted
from
pedro
the
other
day.
That
might
be
interesting,
so
designers
kind
of
do
different
workflows,
but
yeah
me,
I
like
to
it's
ui
changes
back
end
changes.
Almost
anything
I
think
is
is
helpful
because
it
could
need
review.
So
yes,
ux
and
reviewer
alexis.
B
Yeah,
I
might
be
able
to
use
some
existing
filters,
then,
to
build
some
extra
charts
around
that
I
think
another
chart
that
would
be
interesting
would
be
like
there's
a
time
estimation
in
snowflake
for
each.
Mr,
I
guess
it's
just
based
on
when
the
umar
was
open
versus
when
it
was
merged,
could
be
interesting
to
sum
those
for
community
and
non-community
wider
community,
mrs
and
then
to
gabe's
point
as
well.
B
We
should
be
able
to
just
build
a
table
of
linking
through
to
mrs
that
were
for
de-prioritized
categories,
so
we
could
see
like
what
what
they
are,
but
I
would
say
that
they're
probably
like
I
said,
high
priority
security,
technical
debt
bugs
and
so
on,
or
application
limits
things
that
we're
working
on
for
reliability.
Things
like
that,
all
things
that
we
wouldn't
necessarily
choose
to
schedule,
but
it's
good
to
be
aware
that
we're
having
to
do
them
anyway,.
B
D
You-
and
I
guess
like
do
we
we
don't
want
to-
I
mean
I'm
assuming,
but
we
don't
want
to
focus
our
internal
time
on
the
prioritized
categories
as
well
right.
I
would
assume
like
engineering
effort.
B
B
We
have
to
close
that
we
can't
say
it's
deprioritized,
because
it
affects
the
wider
application.
You
know
so
it
may
be
things
like
that,
but
mostly
I
was
interested
in.
I
got
the
impression
that
we
were
spending
a
lot
of
time,
reviewing
mrs
towards
these
categories
and
a
lot
of
time
on
these
like
urgent
fixes
that
we
couldn't
get
out
of.
We
have
to
do
them
and
I
really
wanted
to
know
like
what's
the
truth
of
it
right
like?
B
B
H
Yeah
I'll
virtualize.
My
point
thanks
to
john
for
this
analysis,
it's
super
helpful
to
see
how
we're
spending
time
and
yeah
would
be
interesting.
Just
like
gabe
said
of
digging
in
on
these,
mrs
right
like
if
there
really
are
just
kind
of
like
the
cost
of
having
a
category,
that's
also
good
to
know,
and
it
would
be
good
to
kind
of
socialize
that
within
the
pm
org
right
that
it's
like
basically
having
stuff,
that's,
not
free
right.
H
You
have
to
account
for
some
capacity
to
just
sort
of
keep
the
lights
on
and,
of
course,
as
we
dig
in
into
these,
mrs
and
what
they
are.
H
B
The
only
thing
I
would
say
is
like
the
only
one:
that's
really
helpful
for
at
the
minute
is
the
top
chart
if
you
filter
by
other
teams,
the
only
recognized
d
prioritized
categories
currently
are
service
desk
and
design
management.
So
it's
meaningless
currently
for
other
teams,
I'm
going
to
put
those
into
a
single
source
of
truth,
filter
and
then
I'll,
ask
other
ems
to
add
their
de-prioritized
categories
to
it.
So
we
can
get
an
overall
view.
Okay,.
D
B
Filters
unless
you
pick
product
planning,
because
we
only
have
product
planning's
categories
in
there
at
the
minute,
but
I'll
do
some
work
on
that
today,
probably
like
add
all
the
categories
from
other
groups
and
stuff,
if
you
remove
all
filters
like
the
top
charts
still
relevant,
if
you
filter
by
any
team
top
chart
is
still
relevant
but
only
filter
and
by
product
planning.
The
bottom
two
charts
are
accurate.
E
B
D
Is
there
an
unlabeled
category
2
or
like
a
triage
bot?
We
could
do
that
would
just
check
in
if
an
mri
doesn't
have
a
product
category
to
remind
them.
B
You
see
we
don't
we
don't
actually
encourage
people
to
add
category
at
all.
To
mrs,
I
think
donald
made
the
point
before
that
like
if
it's
there
at
all,
it's
probably
imported
when
the
user
clicks
create
an
mr
within
an
issue
and
then
it's
copied
over
from
the
issue,
but
like
a
single
issue
towards
a
category,
could
have
three,
mrs
you
know
or
more,
and
they
may
also
may
have
to
label
some,
not
so
like
it's
probably
easy
enough
to
go
through,
like
as
a
team.
B
H
H
I
think
it
depends
on
what
they
are
right.
I
think
that's
the
the
next
step.
If
we
look
through
and
it's
all
security
performance
things,
then
it's
kind
of
like
that's
the
cost
of
having
the
category,
but
if
it's
new
features
or
things
like
that
right,
that's
where
it
would
get
interesting
of.
Is
there
a
communication
breakdown
or
like
what's
happening.
B
C
I
just
I
guess,
we're
going
to
social
time
curious
how
everyone's
doing
honestly,
I
will
say
for
me
personally:
it's
been
a
challenging
few
months,
just
because
all
the
stuff
going
on
headcount
resets
rapid
actions,
reliability,
problems,
incidents,
I
mean
it's
just
and
it's
probably
even
more
so
for
the
engineers,
and
so
I'm
curious
how
everyone's
doing
and
also,
if
there's
any
specific
feelings
or
thoughts
around
this
like
localized,
feature
change,
lock
policy
that
recently
got
implemented.