►
From YouTube: Plan Stage Weekly Meeting 2021-08-19
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
B
A
It's
like
the
first
item,
yeah
as
part
of
a
emerging
engineering
allocation
plan.
I've
been
asked
to
take
part
in
a
three
month
head
count
reset.
That
would
see
two
back-end
engineers
from
each
group
move
to
manage
access
temporarily
teams
across
the
sub
department
are
taking
part.
Our
contribution
will
be
to
work
on
the
workspaces
project,
which
is
formerly
known
as
consolidation
of
groups
and
projects.
So
from
project
management.
A
I
believe
it's
alexandria
and
brett
will
take
part
from
product
planning,
charlie
and
I'm
hoping,
jan,
but
he's
currently
on
pto,
but
I'll
have
a
discussion
with
him
on
monday.
The
purpose
is
to
allow
the
access
team
to
focus
on
what
is
like
a
currently
unsustainable
number
of
incidents
and
a
growing
security
backlog
and
yeah.
So
if
there
are
any
like
questions,
concerns
discussion,
items
like
yeah,
please
hit
us
with
them.
I'm
realizing
this
isn't
the
wrong
part
of
the
agenda,
but
I'm
so
sorry,
if
it's
a
surprise.
A
Yeah
it's
three
months
I
mean
I
can
kick
off
like
my
main
concern
is
that
we've
already
started
work
items
on
the
product
planning
side
and
that
if
we
stop
now,
we
end
up
with
a
significant
piece
of
technical
death.
A
I
think
we
spoke
about
this
in
yesterday's
meeting,
but
it
would
be
the
number
one
concern
that
I
have
would
be
that
we
simply
do
a
hard
stop
now
and
we
retain
this
piece
of
technical
debt
indefinitely,
which
I
think
is
kind
of
against
the
whole
point
of
this
engineering
allocation,
which
is
to
reduce
technical
debt.
So
yeah,
I'm
not
clear
yet
on
like
this
literally
happened
in
the
last.
A
You
know
24
48
hours
like
so
I'm
not
clear
yet
on
whether
we're
going
to
roll
work
items
into
workspaces
and
consider
that
the
same
thing
and
then
we're
essentially
allocating
four
members
of
the
team
to
something
we
would
have
worked
on
anyway,
or
whether
work
items
is
going
we're
going
to
have
to
come
up
with
some
mitigation
for
that.
In
the
meantime,.
E
I
think
I
think
we
can
try
to
mitigate
this
risk
as
much
as
possible
after
our
empn
sync,
yesterday
sort
of
the
action
item
that
I
had
and
I
started
drafting
it
yesterday
was
an
issue
just
like
outline
the
three
options
and
figure
out
the
best
way
to
move
forward,
and
we
just
have
some
additional
constraints.
We
need
to
take
into
consideration.
E
I
definitely
think
the
the
since
this
is
just
back
in
there's
a
lot
of
progress
we
can
make
on
the
front
end
and
the
interim,
so
I
think
we'll
just
have
to
maybe
sequence
things
a
little
bit
differently,
but
I
don't
think
we
need
to
do
a
full
stop
on
anything
with
that
said,
we
also
have
taken
consideration
the
infradev
stuff
that
we
still
have
to
prioritize
first
above
building
anything
new.
So
that's
what
I'm
I'm
gonna
do
after
this
call
of
more
comp
this
morning.
D
I'd
like
to
keep
things
going
as
well,
I
do
feel,
though,
if
this
is
a
three-month
commitment
for
our
team
that
we're
probably
going
to
see
a
three-month
impact
or
more
on
category
level
maturities
and
things
like
that.
So
we
need
to
just
communicate
that
up
and
make
sure
that
we
just
move
our
timelines
and
everybody's
on
the
same
page.
A
D
D
E
Yeah,
I
also
well,
I
think
we
can
allocate
a
little
bit
of
capacity
that
we
need
to
do
based
on
how
we
want
to
sequence.
Things
out,
I
know
heinrich,
is
going
to
be
working
on
postgres,
full
text,
search
for
the
issue
list
and
filtering
so
that
we
don't
keep
returning
500
errors,
especially
as
issues
get
larger.
E
That's
going
to
be
like
beneficial
in
the
long
run,
either
way,
but
I
also
see
an
opportunity
for
us
to
sort
of
more
or
less
build
out
most
of
the
front
end,
even
if
we
have
to
like
step
out
some
of
the
data
mocks
from
the
queries
or
things
like
that.
So
it'll
give
us
a
lot
of
chance
like
if
we
can
focus
online
iterating
on
the
ux
and
the
ui
and
the
new
view
app.
E
Even
if
we
don't
have
all
the
back-end
support
and
everything
like
finished,
we
can
only
start
doing
better
validation
within
users
and
getting
feedback
and
kind
of
looping
through
that
stuff.
So
then,
as
soon
as
we
do
have
more
backing
capacity
like
we
should
have
a
pretty
clear
picture
on
what
exactly
needs
to
be
done
and
we
can
knock
those
things
out.
But
again,
that's.
I
was
going
to
propose
that
and
the
issue
that
I
write
up,
but
I
think
there
are
some
opportunities
that
we
can
still
move
forward
items
forward
and
we
should.
F
Yeah
one
other
thing
to
know
is-
and
I
learned
this
yesterday-
so
I'm
still
figuring
out
exactly
what
the
mechanics
are,
but
there
are
there's
a
way
to
basically
request
for
your
air
budgets
to
be
changed.
So
I'm
reading
up
on
that
there's
another
group
that's
going
through
that
which
basically
that
may
just
give
us
some
breathing
room
from
that
perspective,
right
of
not
having
such
a
high
budget
and
hopefully
being
a
or
rather
having
a
higher
budget
and
being
able
to
work
on
work
items
a
little
bit
more.
F
So
it's
one
thing,
the
other
is
that
there's
the
mr
in
progress
to
transition
projects
out
of
plan,
so
I
am
curious
if
that
were
to
go
through
what
would
that
mean
as
far
as
our
slas
and
budgets
go
like?
Where
would
we
fall?
So
that's
something
to
I
don't
know
how
we
do
that
math,
but
I
would
be
interested
to
see
that
and
I'll
ping
on
that.
F
G
Yeah,
that
is
what
I
my
next
point
was,
which
is
that,
like
we
still
have
a
fair
bit
of
project
stuff,
especially
within
like
the
performance
concerns,
and
it's
still
the
contribute,
the
biggest
contributor
to
error
budget.
So
I
I
was
previously
like
of
the
mindset
that
we
would
sort
of
finish
out
what
we're
working
on
before
you
know
kicking
any
of
that
stuff
over
the
fence,
because
I
don't
want
to
like
dump
more
hard
work
on
the
managed
team,
which
is
already
overloaded
right
as
part
of
this
whole
thing.
G
But
now
you
know
we're
losing
two
engineers
temporarily
per
team,
so
I'm
like
more
I'm
more
okay
with
like
kicking
this
stuff
over
and
getting
it
off
of
our
plate.
So
yeah.
I
think
you
answered
my
question,
which
was
gonna
be
like
what
do
we
need
to
do
to
kind
of
get
that
ball
rolling,
and
then
we
should
maybe
have
a
discussion
as
well
and
just
like,
should
we,
you
know,
drop
things
that
we
have
in
progress.
G
I
don't
I
don't
think
so,
but
and
mario
I
can
catch
up
with
you
separately
on
kind
of
the
project
stuff
that
you've
been
working
on
to.
You
know
to
see,
if
there's
a
good
breaking
point
where
we
could
like
pause
and
hand
off
and
not
have
to
keep
dedicating
capacity
to
that.
F
And
I
also
like
just
overall
wonder
how
much
of
this
stuff
is,
if
we're
consolidating
groups
and
projects
right,
I
think
this
will
be
a
conversation
within
the
workspaces
team
of
like
how
much
of
this
stuff
do.
We
need
to
fix
right
if
it's
gonna
theoretically
go
away
soon
sooner
than
we
expected
now,
because
we're
accelerating
so.
E
I
was
just
gonna
add,
I
think
right
now,
projects
are
the
biggest
vendor
from
what
I've
learned,
thus
far
about
air
budgets
and
slas.
I
checked
yesterday
and
over
the
last
28
rolling
days
we're
only
three
hours
of
our
budget,
which
is
a
lot
better
than
it
was
a
few
weeks
ago
where
we
were
like
20
hours
over
budget.
E
So
it
looks
like
I
don't
know
what
all
do
we
change,
but
at
least
maybe
we're
not
getting
hit
as
hard
or
something
on
gaylab.com,
but
they're,
not
as
bad
as
they
were,
and
so,
if
we,
if
we
shed
projects,
I
have
a
feeling,
you
know
they'll
get
a
lot
better
and
then
we
can
like
focus
on
the
things
specific
to
plan
like
issue,
search
and
stuff
like
that.
That
is
really
problematic.
H
I
think
I'm
next,
so
my
question
was
on
on
the
front
end
side
of
things.
I
think
it's
fine
to
keep
moving
forward
on
work
items.
I
mean
that
was
the
plan
originally,
when
we
were
saying
that
on
the
back
end
or
we
were
saying
reliability,
we're
going
to
spend
about
50
of
our
time
on
there.
That
was
primarily
going
to
be
a
back
end
thing,
so
I
think
we
were
always
going
to
be
a
little
ahead
on
the
front
end
of
work
items.
H
My
question
is:
are
we
still
dedicating
50
of
the
new
so
are
we
are
we
saying
50
of
50
is
what
has
to
work
on
the
reliability
stuff
or
is
it
50
of
what
our
old?
What
our
capacity
was
with
all
of
our
engineers,
so
essentially
all
100
has
to
be
on
or
should
be
on
reliability.
E
I
think
we're
originally
targeting
50,
but
I
think
you
know
like
we
can
look
at
percentage
or
we
can
look
at
what
are
the
most
important
things
that
we
need
to
do
right
to
actually
move
the
number.
I
care
more
about
actually
improving
air
budgets
that
do
how
many
engineers
we
have
working
on
it
and
if
we
can
basically
get
improve
our
air
budget
by
50
or
something
like
that
with
just
a
couple
wins,
then
that's
great
right.
E
We
don't
like
need
to
knock
it
all
out,
because
I
do
know
we
need
to
support
the
starting
effort.
So
there's
that
one
issue
for
removing
the
access
to
hackable
gym
from
projects,
and
then
we
have
a
couple
high
risk
areas
that
are
affecting
customers
like
the
issue
search,
and
I
think
it's
also
important
to
get
the
the
bonsai
stuff
in
at
least
the
observability,
so
that
we
know
if
we
make
changes
if
it
makes
things
better.
E
But
I
think
that's
something
we
can
kind
of
talk
about.
As
a
team,
like,
I
think,
if
we're
tackling
the
most
important
things
that
are
going
to
move
the
needle
the
most,
I
don't
think
that
management,
every
leadership
is
gonna
care
about
what
percentage
we
allocate.
That
makes
sense.
F
I
think
that's
true
in
theory,
but
I
do
know
like
at
least
I've
heard
right
and
that's
what
donald's
bringing
up
or
somebody
here
that
there
are
engineering
leaderships
like
asking
how
many
people
are
working
on
what
right
and
that's
how
they're
measuring
so
to
that
end,
I'll
check
with
david
to
see
if
this
still
applies
of
like
the
heavy
emphasis,
because
we
have
such
a
reduced
team
and
I
think,
there's
broader
understanding
that
work
items
will
move
the
needle
for
technical
debt
right
in
the
long
term.
F
A
Yeah,
it's
just
what
I
know
so
far
is
that
it's
not
officially
an
allocation.
Yet,
as
far
as
I
know,
I
just
know
there's
a
heavy
focus
on
it,
we're
kind
of
being
asked.
You
know
just
for
straight
count
as
a
as
a
simple
thing
to
feed
up
higher
up
the
management
tree
like
just
to
figure
out
how
many
people
are
working
on
reliability.
A
Currently,
I
would
say
it
like
kind
of
makes
sense
in
product
planning
because
improving
our
error
budgets
I
mean
besides
epic
boards
and
and
discussions
like
so
banzai
pipelines,
it's
extremely
fragmented
and
small
issues,
so
it
they
could
be
spread
out
amongst
the
team
and
on
the
certify
side.
It's
one
major
thing,
which
is
one
job.
That's
been
repeatedly
retried
so
and
failing
so
yeah.
D
D
We
don't
need
to
open
the
can
of
warns
right
now
as
well,
but
we
could
look
at
pushing
off
the
requirements
or
feature
work
for
three
months.
I
know
charlie
was
heavily
involved
with
requirements,
so
I'm
not
sure
how
that
transition
will
work
will
happen,
but
that
might
be
something
we
take
offline.
D
B
G
We've
I've
also
just
realized.
I
don't
know
if
we,
it
was
in
the
initial
what
john
said,
but
it's
I
think
important
to
remember
that
this
is
several
teams.
It's
not
just
plan
at
first.
It
was
like
very
hard
for
me
to
come
to
grips
with
the
the
change
here,
because
it's
like
it's
a
lot.
It's
a
big
impact
for
us,
but
it's
also
several
other
teams
are
being
hit.
The
same
way,
so
don't
feel
like
we're
planned
is
like
specifically
being
singled
out.
That's
a
reminder.
F
Yeah
kristen
gabe.
We
should
create
an
issue
to
capture
the
impact
right
and
we
can
update
it
as
we
go
right
as
this
thing
progresses,
but
I
think
it
is
important
to
have
that
all
consolidated
somewhere,
so
we
can
continue
to
communicate
and
also
look
back
on
it.
If
we
ever
wonder
you
know
for
historical
purposes
like
hey,
why
did
this
day
change
right?
It's
all,
hopefully
documented
in
that
issue.
G
Do
any
of
y'all
at
the
like
ic
level,
we've
been
doing
a
lot
of
manager
and
product
manager
chat
here,
which
I
understand
is
kind
of
it's
our
domain.
But
do
you
all
have
concerns
or
questions
or
anything
that
we
can
answer
while
we're
on
a
sink
call?
That's
it's
fine,
if
not
just
wanted
to,
like
specifically
probe
for
that.
G
I
I
think
I
think
it
makes
sense
to
keep
to
keep
pushing
forward
work
items
as
we
can
we're
going
to
lose
momentum,
but
shouldn't
come
to
a
complete
stop.
Hopefully,
so
that's,
I
think,
there's
a
lot
of
things
that
can
be
done
under
the
covers
and
the
ui
can
definitely
keep
moving
forward
and
maybe
even
pieces
of
the
back
end,
mario
and
the
rest
of
the
rest
of
the
team.
So
I
don't
think
we
can
sprint
towards
it,
but
I
think
we
should
at
least
keep
walking.
C
Cool
yeah
thanks
jake,
that's
a!
I
appreciate
you
asking
I'll
try
to
be
quick
because
I
might
have
to
dip
out
in
a
couple
minutes
to
one-on-one,
but
yeah,
I'm
just
looking
at
this
one
issue
around
duplication,
basically
of
issue
weights
and
I
apologize.
I
am
using
one
monitor
today,
just
my
laptop.
So
this
is
difficult
but
yeah
like
in
boards.
What
is
the
weight
of
an
epic
basically
and
then?
How
do
we
display
that,
in
a
column
on
a
board,
because
there's
two
items
there
that
are
different
hierarchy?
C
They
look
the
same
hierarchy
and
they
can
be
duplicating
weight.
So
I
want
to
ask
feedback
from
like
people
outside
of
plan
designer,
so
I
tried
to
visualize
this
in
a
friendlier
way,
so
it
probably
looks
really
silly
but
kind
of
thinking
about
it
like
okay,
we
have
this
big
backpack
full
of
stuff
has
like
10
things
in
it.
It
weighs
about
88
ounces,
and
this
is
like
the
overall
epic,
and
maybe
we
have
these
two
smaller
epics
child
epics
within
it
they
also
contain
stuff,
and
then
we
also
have
this.
C
This
thing
that
is,
has
a
weight
right
and
then
there's
things
underneath
it
that
also
have
weights,
so
maybe
they're
bottles
of
water
in
the
bags
that
are
in
the
backpack.
So
if
you,
if
you
visualize
this
in
a
nest
or
in
a
tree,
that
makes
sense
because
you
see
how
it
rolls
up,
but
when
you're
looking
at
a
column,
you
know
you
have
this
there's
three
things
here,
that's
obvious,
but
it's
not
obvious.
C
Let's
say
that
this
little
bag
has
three
things
nested
in
it
to
create
that
32
weight
and
one
of
those
things
that's
nested
within
this
bag.
Is
these
three
bottles
that
is
also
displayed
in
the
column.
So
just
thinking
about
this
and
like
what
would
it
make
sense
to
display
as
a
weight
here?
C
Is
there
any
scenarios
where
it
would
make
sense
to
kind
of
just
like
display
everything
all
at
once?
I
can't
envision
that.
I
would
think
that
we
would
want
to
basically
subtract
this
from
this
to
show
the
overall
weight,
but
there's
some
scenarios
where
it's
confusing.
Like
let's
say
I
move
this,
these
little
bottles
to
the
next
column.
C
My
overall
weight
will
not
decrease
like
there's
some
things
in
there.
That
can
be
confusing,
or
let's
say
I
have
the
backpack
in
this
column.
It's
always
going
to
be
that
overall
88
weight,
even
if
I
move
everything
else,
but
the
backpack
out
of
that
column.
So
I
know
that
sounds
weird
and
it's
early
here
for
me.
So
yes,
it's
probably
weird,
but
that's
what
I'm
thinking
through.
C
I
don't
know
if
you
all
have
any
off
the
off
the
cuff
feedback,
but
if
you
want
to
talk
asic,
you
can
also
do
it
in
this
issue
or
in
here,
but
I'll
leave
it
open.
If
anyone
wants
to
talk
for
a.
E
Second,
I
was
just
gonna
add
that
I
don't
think
we
should
duplicate
the
counterweight,
don't
really
know
what
the
ideal
ux
is,
though
I
would
almost
expect
to
not
have
different
epics
at
different
levels,
because
we're
going
to
deal
with
this
when
we
do
parenting
on
workouts
same
thing
to
be
on
the
same
board
at
the
same
time,
right
like
I
almost
wouldn't
want
to
like
zoom
in
and
out
of
my
hierarchy
right.
E
So
if
I
go
up
to
the
highest
level,
I
only
see
a
board
that
has
all
the
items
of
the
highest
level.
If
I
zoom
in
a
little
bit,
I
go
down
a
level,
and
I
see
only
those
issues
right
or
only
those
work
items.
If
I
go
down
again
so
that
way
like
you,
don't
have
to
mix
and
match
hierarchy
and
a
flat
flat
structure.
C
That's
it's
kind
of
where
my
brain
started
going
to
gabe.
Is
it
you're
almost
seeing
that,
like
the
let's
say,
the
backpack
is
the
epic?
Are
you
saying
those
bags
under
that
the
backpack
should
not
be
epics
they're
kind
of
another
thing,
or
maybe
that
the
backpack
is
not
an
epic
they're,
all
like
different
items
or.
E
Yeah,
that's
how
customers
are
going
to
be
using
it,
where
they're
going
to
call
each
of
the
levels.
They'll
call
the
backpack
a
backpack
and
then
they'll
call
the
bag,
something
else
and
then
they'll
call
whatever
it
is
under
that
something
else
right.
One
product
that
does
this
in
an
interesting
way,
I
think,
is
road
monk
worth
checking
out.
E
They
do
sort
of
like
the
zooming
idea,
where
you
go
from
like
this
high
level
roadmap
view
and
you
can
zoom
in
and
as
you
zoom
in
it
actually
zooms
into
the
lower
level
work
items
as
you
go.
That
might
be
an
interesting
way
to
look
at
it,
but
yeah
like
I.
I
wouldn't
because
to
me
like
a
backpack
is
a
backpack
and
the
bags
that
are
in
the
bags.
Backpack
are
not
the
same
thing
as
a
backpack.
F
I
have
the
next
point
allowing
a
direct
relationship
to
a
parent
when
it's
already
related
further
down.
The
line
is
a
little
bit
weird
to
me,
like
it's
an
edge
case
here,
and
I
could
see
it
being
an
edge
case.
Another
scenario,
so
I
think
that
something
I
don't
have
an
answer.
C
I
agree
and
it's
the
same
in
a
list
right
so
within
the
epic
list
you
can
see
epics
across
the
different
hierarchy
and
you
wouldn't
notice
or
like
there's
no
indication
that
summer,
child
epics,
which
is
also
the
same
kind
of
problem,
but
we're
not
calculating
weight.
So
I
guess
it's
a
little
less
painful
but
good
point.
C
Cool
otherwise
I'll
share
my
screen
again
and
then
disappear,
but
yeah
I've
been
trying
to
track
kind
of
what
I'm
working
on,
because
I
get
a
lot
of
to
do's
and
I
feel
like
I'm
working
enough
hours,
but
I'm
just
not
getting
to
some
of
the
things
that
I
would
like
to
to.
C
You
know
focus
on
and
I
feel
like.
I
can't
answer
all
the
to-do's
I
would
like
to
so
like.
I
want
to
help
all
of
y'all
and,
like
answer
all
the
questions
you
have
but
like
sometimes
I
just
feel
like.
I
don't
have
enough
time
in
the
day,
so
I'm
trying
to
figure
out
why,
at
the
beginning
or
just
you
know,
I
started
tracking
kind
of
a
milestone
and
weekly.
So
I
had
this
like
weekly
file
that
I
would
check
things
off.
C
C
So
I
started
also
tracking
this
at
a
milestone
level,
trying
to
get
a
little
higher
level
as
well,
and
then
I'm
gonna
zoom
back
in
and
I've
been
trying
to
kind
of
put
things
on
like
a
eisenhower,
matrix
and
think
about
like
what
are
the
things
I'm
working
on
that
are
impactful,
what's
urgent,
but
not
impactful
or
priority
things
like
that
and
labeling
them
that
way
and
putting
them
into
each
day.
C
So,
thinking
about
what
I
wanted
to
work
on
in
this
day,
what
I
ended
up
working
on,
where
I
focused
my
time.
So
I
just
started
that
last
week
and
I'm
still
working
on
it,
but
when
I
look
at
the
time
spent
for
me,
it's
like
mostly
in
this
like
urgent,
but
not
priority.
C
So
a
lot
of
like
reviewing
mrs
or
like
thinking
about
like
quick
designs
that
I
didn't
expect
to
account
for,
but
it
like
came
up
and
someone
needs
help
with
something,
and
I
need
to
mock
something
up
or
like
things
like
that,
which
is
obviously
not
ideal.
It's
like
not
urgent
and
urgent,
but
not
priority
or
not
urgent,
but
not
priority.
C
So,
probably
that's
not
where
I
want
to
be
focusing
my
my
time,
so
I
just
want
to
flag
it
up
to
y'all
and
if
you
have
like
ideas
or
it
you
know
like,
maybe
we
can
think
about
how
to
kind
of
change
up
the
workflow
if
that
needs
to
be,
but
I'm
I'm
ideating
on
it
on
my
end,
just
fyi
but
curious
about
y'all's
thoughts.
A
That's
incredible
like
so:
google
docs
is
going
really
slow
for
me,
so
I'll,
just
vocalize
them
yeah,
so
how
many
of
these
items
are
directly
related
to
that
you
have
in
gitlab
like
a
gitlab
to
do
as
in
not
something
you're
tracking
yourself
like
do
they
all
map
one
to
one
or
many
to
one,
to
a
to-do
that
you
have
there.
C
So,
each
of
those
items
it's
more
like
I'll,
be
like
review,
mrs
that
I
didn't
realize,
were
priority
or
mock
something
up
for
this
to
do
so,
it's
not
one
to
one,
but
I
tried
to
kind
of
like
put
them
into
little
themes
and
then,
like
anything,
that
could
be
labeled
as
a
certain
part
of
kind
of
that
that
matrix
and
thinking
about
also
like
tactical
versus
strategic
work.
But
honestly,
if
I
accounted
for
all
my
titties
there'd,
probably
be
more
work.
C
A
C
A
Right
and
there's
no
currently,
there's
no
difference
between
a
to
do
where
you're
tagged
in
an
mr
and
asked
for
a
review
versus
like
cc'd
in
a
comment
they
have
equal
priority.
We
don't
have
any
different
priority
in
our
to-do
system.
So
it's
up
to
you
to
like
figure
out
which
one's
more
important
or,
if
you
just
want
to
work
sequentially
through
your
to-do's
or
whatever.
That's.
C
Part
of
it,
and
mostly
also
like,
if
I
get
tattered,
if
I'm
a
reviewer
and
mr
that's
like
the
number
one
priority
for
designers
and
it's
so
unproductible
so
like
I
can't
kind
of
account
for
that.
In
my
capacity
that,
like
okay,
I
might
have
to
spend
this
many
hours
on
on
mrs
and
there's
also
the
community
contributors.
C
Some,
mrs,
are
more
like
pairing
versus
reviewing.
So
it's
just
kind
of
like
that
that
I
can't
really
predict
right
how
much
of
my
time
is
going
to
go
there
and
because
it's
such
a
high
priority,
it
just
kind
of
gets
a
little
volatile.
Sometimes,
but
I'd
say
it's
like
the
reviews
is
number
one
right.
That's
I
focus
on
that
above
all
else,
and
then
other
to-do's
that
seem
like
people
might
be
blocked.
That's
why
I
focus
next
and
also
my
priorities.
I
C
Yeah
and
like
so
honestly,
what
I'm
trying
to
figure
out
is
how
I
can
interact
more
with
y'all,
because
I
so
I
feel
badly
when
I
can't
like
respond
as
quickly
as
I
want
to,
because
I'm
like
focusing
like
on
a
bunch
of
stuff.
So
like
that's
what
I'm
trying
to
figure
out,
I
appreciate
the
asks
and
like
the
collaboration
so
like
that's
what
I
want
right,
so
don't
feel
bad
for
it.
But
yes,
I
I'll
try
to
figure
out
like
a
better
process.
C
So,
like
that's
more
seamless,
I
guess
that
makes
sense
but
yeah.
No.
I
appreciate
you
asking
for
feedback
and
collaboration.
D
Are
you
using
direction
labels
which
we
haven't
been
using
too
much,
because
we've
been
focused
mostly
on
work
items,
and
how
are
these,
mrs
skipping,
the
design
process
so
like
there's
a
lot
of
issues
that
get
opened
and,
ideally
in
our
workflow,
the
design
should
kick
back
to
workflow
design
the
designers
looped
in
but
like
it
sounds
like
the
majority
of
ours
are
in
the
mr.
In
the
final
hours,
design
is
brought
in.
D
C
Part
of
it
yeah
and,
like
I
said,
I
think
it's
just
that
unpredictable
like
I
can't
predict
how
much
design
will
be
needed.
Some
designs
like
they
might
be,
not
completely
finished,
and
it
might
need
a
little
bit
more
pairing,
maybe
because
I
didn't
realize
it
would
be
a
priority
like,
but
something
we're
working
on
that
I
didn't
realize
was
still
in
focus
things
like
that,
but
how
I
determine
priorities
mostly,
it
should
be
from
our
workflow
right.
So
like,
like.
I
said
mr
reviews
there's
some
stuff
in
here.
C
That's
kind
of
interesting
to
me
so
like
yeah,
like
feedback
requests
from
other
designers,
so
we
have
that
as
well
like
I
spend
a
lot
of
time
helping
other
designers
and
then
you
know
what
we
label
as
deliverable,
and
then
things
assigned
to
me
and
then
okrs,
although
I
feel
like
opr,
is
often
input
higher
because
it
feels
like
they
feel
like
they're
higher,
because
I
get
things
in
them
more
often
so
this
is,
this
is
our
workflow.
This
is
how
I
determine
priority.
That's
helpful.
C
But
okay
yeah,
I
think
it's,
the
mrs,
is
what
I'm
that
is
one
of
the
larger
things
I'm
trying
to
figure
out
and
some
designers
don't
get
asked
to
review.
Mrs
and
marcel
and
pedro
are
working
on
this.
They
have
a
little
more
capacity
to
think
about
it
like.
Why
is
that
like?
Why
are
some
designers
reviewing
a
lot?
Why
are
some
not
reviewing
at
all
like?
C
Can
we
share
that
a
little
bit
more,
but
I
think
that
is
one
of
the
largest
things
that
kind
of
like
throws
me
for
a
loop
capacity-wise
but
yeah.
This
is
these.
Are
the
priorities.
E
I
was
curious
how
many
of
those
like
tasks
are
part
of
our
stage
or
other
stages
and
then
also
versus
the
just
ux
department
as
a
whole,
because
I
think
we
can
definitely
iterate
on
our
process
at
the
stage
level,
but
I'm
interested
in
how
much
that
would
actually
impact
if
it's
stuff
outside
of
our
outside
plan.
If
that
makes
sense,.
D
C
C
It
seems
like
especially
probably
the
last
two
weeks
I
had
more
okr,
like
ux
admin
type
stuff
going
on
and
then
also
very
tactical,
so
like
tactical
work,
meaning
reviewing
not
like
a
lot
of
research
or
like
high
level
vision,
just
like
very
kind
of
tactical
answering
questions
things
like
that,
and
that
would
be
both.
That
would
be
more
probably
just
plan
as
a
whole
gabe,
but,
I
would
say,
least
at
least
like
last
week.
It
was
a
lot
of
ux
admin
okr.
C
That
kind
of
stuff,
then
like
tactical,
mrs
within
probably
product
planning
and
then
just
like
questions
as
a
whole
within
a
plan,
but
I
think
that's
a
good
thing
to
track
I'll.
Remember
that.
C
What
else
I
don't
want
to
hug
the
whole
meeting,
but
anyone
else
looks
like
donald.
H
Yeah
so
I
mean,
as
you
said,
like
mrs
probably
take
up
the
biggest
unplanned
time
from
you,
so
I
was
wondering
because
with
especially
with
maintainers
on
the
engineering
side,
a
lot
of
the
reviews
they
have
are
also
unplanned
and
while
we
don't
explicitly
say
it's,
the
number
one
priority
maintainers
have
an
slo
of
like
two
days
to
get
a
response
back.
So
I
don't
know
if
that's
the
same
with
design
like.
Is
there
an
expectation
to
get
a
review
back
within
two
days?
It
would.
H
J
J
You
can
still
say:
okay,
it
takes
more
time
and
try
to
time
box
it,
because
it's
really
hard
when
you
have
many
emerging
quest
reviews,
so
they
take
at
least
like
hour,
maybe
two
for
reviews
and
then,
if
you're
not
doing
it,
if
you
say
like
you
need
more
time,
I
believe,
like
any
of
front-end
engineers
will
be
very
receptive.
If
you
say
I
need
more
time,
I
need
it
one
day
more,
it's
better
to
have
a
better
ux
review
than
just
like
you
looking
at
them
or
like
okay,
fine.
I
approve
this.
J
No
don't
do
this,
please
and
also
one
more
thing
about
urgent
tasks,
sometimes
that
what
I
learned.
Sometimes
we
take
things
as
urgent
when
they
are
communicated
to
you
promptly
synchronously.
So
someone
brings
you
on
the
slack
like
alexis.
Please
can
you
look
at
this
and
in
fact
this
is
slow
priority,
but
we
consider
it
as
urgent
because
you
were
pinned-
and
in
these
cases
I
tend
to
do
the
same.
J
I
tend
to
do
this
to
the
to-do
list
at
the
end
of
my
to-do
list
and
say:
okay,
I
will
come
back
to
you
with
an
answer,
because
this
is
not
the
highest
priority.
This
is
just
synchronous
communication
and
I
know
it's
hard,
but
it
helped
me
a
lot
because
I'm
pinked
multiple
times
through
the
day
and
if
I
respond
to
everyone
immediately,
I
will
be
doing
no
work.
C
C
And
I
think
time
boxing
is,
is
a
good
idea
too
trying
to
think
I
I
feel
like
it
to
me.
It's
like,
I
feel
like
I
need
to
unblock,
and-
and
I
don't
know
it's
tough
I'll
keep
thinking
through
it
and
because
it's
such
a
high
priority
for
us
and
it's
because
also
it's
hard
for
me
to
kind
of
be
like
hey.
I
don't
have
capacity
for
this
like
so
so.
C
So-And-So
can
review
this
for
you
because,
like
we
don't
we
kind
of
may
be
more
siloed
in
ux
or
I
don't
know
what
it
is.
But
we
are
thinking
through
that
kind
of
thing
like
how
can
we
have
like
backup
reviewers
like?
Could
that
be
a
thing
to
kind
of
share
the
load
a
little
bit
more?
But
that's
a
good
point.
Thank
you.
H
The
majority
of
the
mrs
or
the
request
you're
getting
from
within
plan,
because
I
mean
it's
also
hard,
there's
eight
front
end,
seven
or
eight
front
end
engineers
and
you're.
The
only
you
and
holly
are
the
only
ux
reviewers
for
all
of
them.
We
kind
of
have
that
requirement
that
every
visual
change
needs
to
be
approved
by
ux.
H
How
would
you
feel
about
maybe
having
like
us
relaxing
that
requirement
a
little
bit
more,
especially
for
the
smaller
things
or
and
especially
for
the
things
that
have
that
were
not
requested
from
you
from
you
or
holly?
I
don't
know
how
we,
how
we
feel
about
that.
C
Yeah,
it's
it's
hard.
I
it's
like.
I
don't
almost
rather
be
pinged
and
just
be
like
nah.
This
is
kind
of
fine
like
all
right,
you
know,
but
it
still
does
contact
switch
and
then
I'm
still
spending
the
time
to
review
it
and
then
making
that
decision.
So
I
yeah
that
could
be
an
interesting
point
to
like
think
about
what
is
the
threshold,
but
I
feel
like
it
could
maybe
be
kind
of
a
slippery
slope.
C
Oh,
like
the
padding
is
you
know
whatever,
like
nothing
too
complex
like
if
it's
small
enough,
like
aiming
for
mrs
that,
like
any
designer
could
review,
could
be
something
to
explore
and
also
to
your
other
point,
I'd
say
this
milestone.
I
had
a
lot
of
like
plan
stage
specific
or
like
team
specific,
mrs,
but
often
I
also
get
community
contributor.
I
can't
say
that
word
today,
mrs
and
those
often
spend
I
had
to
spend
a
little
bit
more
time
on
them.
C
Just
because
one
I
want
to
encourage
just
people
to
contribute
and
then
two
sometimes
they're
just
kind
of
like
big
ideas
and
then
you
know
not
priority,
sometimes
because
they're
kind
of
like
out
of
left
field,
but
I
want
to
encourage
those
people
and
make
sure
that
we're
emerging
things
that
make
sense.
So
chris
said
I'm
looking
at
you
and
I
thought
I
was
frozen
because
your
face
wasn't
with
me
anyway.
C
C
A
Please
I
can
help
you
yeah,
so
I
watched
the
videos
that
you
made
about
like
where
you
demonstrated
reviewing
with
git
pod
and
with
gdk,
and
it
seemed
like
you
spent
a
lot
of
time
in
kind
of
spinning
up
those
environments
and
I'm
wondering
like
how
much
of
the
time
you
spend
reviewing
is
actually
like
debugging
and
setting
up
these
environments.
So
you
can
review.
Do
you?
Do
you
do
that?
Every
time
you
review
something
or
is
there
something
we
could
do
like
two
suggestions?
So
one
is
like
takes.
A
For
example,
eugenia
eugenia's
working
on
caching
issue
counts
in
the
groups
page.
We
could
just
take
screenshots
of
what
will
happen
there,
it'll
be
rounded
to
1k
or
anything
over
a
thousand
will
be
rounded
to
1k.
I
mean
we
can
take
screenshots
of
that
drop
it
in
the
description.
If
that
saves
you
time,
it's
the
second
like
possibility,
like
wacky
idea
like
we
could
make
the
responsibility
of
the
engineer
to
spin
up
the
getpod
environment
with
their
changes.
A
That
would
give
you
the
chance
to
just
basically
go
check
out
the
changes
with
instructions
from
the
engineer,
and
it
helps
us
as
well
because
it
keeps
our
work
unblocked.
So
I
don't
know
if
any
of
those
will
be
helpful.
C
It
could
be
interesting
to
have
like
an
instance
that
you
share
and
get
paid
I'd
say
like
it's
definitely
a
huge
huge,
huge,
huge
blocker
for
a
lot
of
designers,
especially
when
we
just
had
local
jdk.
A
lot
of
people
were
having
problems
with
it.
I
don't
have
as
much
of
a
problem
with
it.
I've
been
using
git
pod
a
lot
like
also
because
other
designers
prefer
it
so
like
kind
of
almost
like
you,
like
you,
said,
debugging
it
in
another
manner
like
just
to
kind
of
build
that
empathy.
C
I
don't
have
as
much
of
an
issue
with
spinning
things.
Up
get
pod
takes
longer
because
every
time
it's
like
a
new
instance,
it
doesn't
remember
future
flags
things
like
that
licenses,
so
that
that
does
take
a
little
bit
longer
than
local
gdk.
I'd,
say
they're,
not
as
big
of
blockers
for
me,
but
definitely
for
other
designers.
C
Yes,
they
are
somewhat
of
a
blocker
and
I
don't
I
don't
usually
like
to
rely
on
like
screenshots,
I
think
they're
really
helpful
and
like
especially
like
a
gif
or
something
I
don't
personally
usually
like
to
rely
on
them
unless
it's
a
very,
very
small
change.
So
again,
maybe
it's
like
really
small
and
any
designer
could
review
it.
That
kind
of
thing,
but
usually
I
still
review
it,
but
that's
that's
again
something
to
think
about.
Maybe
that's
just
a
me
thing
like.
C
A
Yeah,
fair
enough,
I
didn't
want
to
undermine
or
anything
it's
just
like
for
very,
very,
very
small
changes,
but
that
are
nonetheless
like
a
change
to
the
interface.
You
know
I
mean
like
very
small,
very
risk-free
and
predictable
changes,
but
yeah.
I
can
see
your
point
like
that.
You
may
see
things
that
we
miss.
A
I
think
I
remember
that
when
we
initially
talked
about
writing
off
these
kinds
you
mentioned,
like
some
people,
use
those
kinds
to
know
where
they
are
in
the
application
like.
If
I
see
a
count
rounded
here,
I
know
I'm
in
a
project
and
on
a
group,
so
if
we
run
them
for
groups
as
well
like
it
might
be
like
a
psychological
thing,
so
I
wouldn't
even
thought
of
that.
C
I
C
That's
a
really
good
idea.
I
think
we
are
thinking
about
that
like
how
would
that
work,
especially
because
some
designers
don't
review
often-
and
maybe
like
I
don't
know
this
not
might
not
be
right
to
say,
but
maybe
don't
know
how
to
review
so
we're
trying
to
figure
out
that's
kind
of
our
baseline
right
now,
like
not
that
they're
doing
something
poorly.
It's
just
like
making
sure
all
designers
understand
how
to
review
first
and
then
I
think
that
would
be
ideal.
I
think
that's
a
really
good
idea.
C
It's
a
good
idea
and
I'll
update
y'all
on
the
progress
as
we
work
towards
it's
part
of
our
okr
thinking
about,
like
the
the
state
of
mrs
and
better
design
reviews.
So
it's
a
good
idea
for
that.
I
And
I
just
had
one
other
one
other
question:
the
in
terms
of
setting
up
the
environment
and
stuff
are:
are
review
apps,
not
working.
Well,
for
that,
in
terms
of
I
I
would,
I
would
think
that
would
actually
be.
The
best
use
of
review.
Apps
sometimes
is
in
ui
changes.
Is
that
does
that
not
work
very
well
or.
C
I
barely
use
them.
I
don't
even
know
why
I
think
the
the
seating
of
the
data,
maybe
is
part
of
it,
but
I
mean,
I
guess
that's
kind
of
the
case
for
many
things,
but
I
don't
know
just
for
some
reason:
I've
I've,
always
I
mostly
prefer
like
local
gdk.
It
just
seems
easier
for
me
to
use
and
again
maybe
it's
just
like
a
personal
preference.
D
C
I'll
link
that
my
computer's
been
like
so
slow,
I
think
because
the
google
doc,
but
we
are
thinking
through
some
of
those
so
I'll
put
those
in
the
agenda.
I
don't
want
to
think
about
that,
but
better
design
reviews.
I
think
pedro,
is
kind
of
trying
to
lead
that
initiative,
probably
marcel
as
well
and
create,
which
makes
sense.
So,
but
that's
a
good
question
as
well.
C
Thanks
y'all
and
like
no
action
items,
necessarily
I'm
just
thinking
through
this
and
thinking
about
priorities
and
all.
G
We're
almost
the
time,
but
I
can
quickly
verbalize
merchant's
point
for
him
since
he
had
to
drop,
which
is
that
there's
some
updates
to
the
dachshund
style
guide
on
how
we
write
the
terms
issue
boards
and
epic
boards,
so
they're
lowercase
now,
which
mostly
applies
to
documentation.
But
I
know
I
have
at
times
struggled
on
whether
to
not
to
capitalize
these
things.
So
it's
nice
to
have
some
guidance
so
check
those
out
and
make
sure
to
adhere
to
them
and
provide
feedback.