►
From YouTube: Manage Engineering:Product Biweekly 2020-04-30
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
Cool,
so
thanks
for
hopping
on
the
collar
everyone
I
in
terms
of
his
our
discussion
on
the
on-deck
label
and
such
from
last
week
that
most
of
my
notes
have
been
recorded
in
the
issue
that
I've
linked
in
magenta
point
thanks:
Dan,
no
one
wanted
to
bring
up
anything
else.
So
all
we're
gonna
do
is
discuss
workflow,
so
yeah.
A
So
thanks
for
the
conversation
there
and
so
continuing,
then
a
list
of
the
thoughts
I
had
in
terms
of
process
and
workflow
I'd
like
to
hear
people's
thoughts
on
the
priority
labels.
There
was
something
and
I
guess.
Maybe
this
is
more
for
Harris
to
kind
of
explain
to
us,
your
your
you
know:
rationale
behind
having
these
scoped
milestone.
Priority
labels,
in
contrast
to
the
existing
P
1
to
P
4
labels
yeah.
Maybe
we
can
start
with
that.
A
B
As
you
know,
I've
done
maybe
three
I
think
three
planning
sessions
with
the
team
since
I've
started,
and
you
know
we
tried
a
couple
different
things
and
you
know
finally
kind
of
started
settling
and
on
an
approach
that
seems
to
be
working
for
everybody
in
the
in
the
last
release.
So
one
of
the
things
that
we
discussed
in
some
of
our
meetings
and
some
of
the
perspectives
is
a
kind
of
priority
and
how
like
even
how
important
the
P
labels
are
inside
a
milestone
compared
to
the
order
of
things
in
the
in
in
the
backlog.
B
So
if
we
pull
ten
things
and
they're
in
kind
of
a
order
that
they
should
pull
and
should
they
look
should,
should
we
be
looking
at
the
order
in
the
have
in
the
column,
or
should
we
be
looking
at
the
P
labels?
I
know
that
there
was
at
least
originally
when
we
talked
about
it
across
more
than
just
our
group.
There
was
a
preference
to
actually
have
P
labels
on
items
so
that
everybody
can,
even
if
things
get
shuffled
understand
what
are
the
priorities
for
that
particular
milestone.
B
So
the
one
thing
that
I
came
across
the
third
first
time
we
planned
was
the
fact
that
all
of
the
issues
that
created
all
of
the
feature
issues
did
not
have
priority
labels.
The
present
labels
came
only
with
security
and
bugs
and
those
had
rules
as
far
as
what
priorities
you
know
they
should
be
so
you
know
next
time
we
planned
I
added
priority
labels
to
to
the
issues
that
I
wanted
to
get
done
and
and
change
the
priorities
in
a
way.
B
So
in
a
way,
as
I
was
kind
of
designing
the
milestone
and
thinking
about
these
are
maybe
20
or
30
issues
we
can
pick
from
and
I
wanted
the
team
to
be
able
to
take
the
items
into
into
the
milestone
sort
of
from
the
backlog
loosely
in
the
order
that
I
want
them
in.
But
you
know
they
can
take
it
probably
design
their
unlost
on
better
than
I
can
figuring
out
things
that
they
feel
like
go
together
or
they
can
do
quickly.
B
So
with
with
that
in
mind,
I
kind
of
prioritize
the
backlog
for
them
to
look
at
in
in
a
way
that
I
moved
I
created.
Four
columns
and
our
planning
board
and
each
one
happening
on
P
1
through
P
4
and
then
I
moved
items
that
I
really
had
to
have
in
that
milestone
that
were
more
of
directional
or
things
we
promised
or
they
would
they
driven
into
the
p1.
B
And
it's
in
some
of
the
less
important
thing
since
p2
and
things
that
could
slip
into
the
next
milestone
and
to
p3
and
so
on
and
I
got
pinged
by
a
few
people
from
security
and
and
triage
telling
me
that
hey
yeah,
could
you
explain
why
this
p2
became
a
p3
or
why
this?
You
know
p1
became
something
else,
and
then
I
realized
that
the
rules
that
govern
the
overall
prioritization
for
the
entire
backlog
for
gitlab
do
not
always
coincide
with
the
priority
that
I
want
team
to
work
on
and
within
a
particular
milestone.
B
So
you
know
last
time
we
planned.
We
decided
to
use
a
different
set
of
priorities
and
Pinilla
funny
enough.
I
looked
in
get
lab
and
there
was
a
there's
another
set
of
priority
labels
called
priority
labels,
there's
scope
to
the
milestone
and
they're
also
p1
through
p4.
And
if
you
look
at
the
description
for
them,
it
says
these
are
the
priorities
within
the
milestone
and
that
way
I
was
able
to
set
the
priorities
for
the
team.
B
I
was
able
to
set
the
order,
they
should
work
on
the
ice
and
for
the
priority
orders
work
on
items
within
the
milestone,
without
touching
the
overall
priority
labels
that
were
assigned
sort
of
by
security
and
I'd
be
take
the
P
1
2
P
4,
as
input
into
my
decision
on
how
I
prioritize
things
into
milestone.
But
you
know
everybody
knows
that
our
backlog
has
more.
B
You
know,
do
you
want
to
be
to
issues
then
we
can
handle
in
multiple
milestones,
and
if
we
just
did
things
in
those
type
of
priorities,
we
would
have
milestones
be.
You
know,
have
no
features,
so
you
know
we
kind
of
use
that
to
see
how
that
works,
where
this
is
the
first
time
we
did
it.
So
we'll
probably
look
at
it
at
the
end
of
this
Tremont's
them
to
see
if
those
were
useful,
if
those
were
confusing,
if
people
even
look
at
those
or
they're,
just
gonna
big
things
from
the
from
the
backlog.
B
It's
a
mixed
message:
I
think
they
do
exist
in
a
particular
way
for
security,
but
then
we
are
allowed
to
assign
those
labels
to
any
issues
or
to
all
the
issues
within
the
backlog.
So
that's
that's
okay,
but
then,
if
we're
really
paying
attention
to
those,
as
far
as
trying
to
figure
out
what
order,
we
should
work
things
in
then
I
don't
always
want
to
use
those
that
order,
because
for
PM's
many
other
dimensions
calculate
into
this
vision
on
what
is
a
real
priority
for
this
moss
on?
B
What
is
not
you
know
if
it
could
be
a
p3,
p3,
bug
or
or
p3
issue
out
there.
That
has
there
is
time,
sensitive
and
just
needs
to
get
them
right
now.
So
it's
a
must.
My
little
button
deliver
something
we
have
delivered
this
issue,
but
you
know
if
you're
looking
at
the
the
guidelines
on
what
should
be
a
p1
p2
p3
like
that,
should
never
be
a
p1,
but
I
may
want
to
have
that
be
the
first
thing
we
do
in
the
milestone,
so
I
feel
like
in
order
to
have
that
leeway.
B
I
needed
a
different
way
to
communicate
the
priorities,
and
these
these
priority
labels
are
one
way
to
do
it
and
we'll
try
and
see
how
that
works.
The
other
way
would
be
to
really
pay
attention
to
the
order
of
things
and
just
have
the
rank
order
of
things,
and
you
know,
try
not
to
messed
it
up
by
moving
things
up
and
down,
which
is
really
hard
with
our
UI.
D
So
Harris
I
think
actually
the
problem
here
may
be
that
security
is
applying
priority
labels
when
they
should
priority
labels.
My
understanding
is
that
priority
label
was
belong
to
the
product
managers,
so
security.
Those
are
engineers.
Engineers
should
be
applying
severity
labels,
so
there
there
should
be
no,
you
know
sort
of
interference
there.
D
B
That
would
that
would
probably
solve
it.
So
if
I
had
made
freedom
to
play
with
these
and
I
could
set
these
to
be
X
or
something
to
be
a
p1
in
this
milestone
and
then
p3
in
this
mouse
on
an
Appy
to
another
on
a
p1
like
I
could
even
escalate
the
priority.
If
we're
missing
fact
that
long
or
whatever,
that
is
so.
If
I
had
the
full
freedom
to
just
change
these,
and
there
wasn't
a
definition,
I
had
to
follow
then
yeah
that
would
solve
it.
Yeah.
C
And
if
what
they
want,
the
security
team
is
to
make
sure
things
get
done
right,
like
maybe
there
are
rules
around
the
severity
x'
instead
of
a
severity
plus
priority.
Combination
of
that
makes
sense
right,
like
maybe
we
say,
as
once,
are
the
ones
that
need
to
be
done
in
I,
don't
know
what
is
it
30
days
or
well.
E
I
think
those
rules
do
exist
and
I
think
it's
on
PM's
to
make
sure
that
they're
prioritizing
at
least
like
security
fixes,
but
other
than
that,
like
I've.
Personally,
never
had
anyone
give
me
flack
about
using
priority
labels
and
if
they
did
just
like
hey
Dan
fight
this
battle
for
me,
but
yeah,
I,
think
I.
Think
Dan's,
right,
I
think
it's
up
to
the
PM's
to
do
the
the
scheduling
the
prioritization
and
on
security
view
the
severity
and
you
should
be
taking
severity
into
consideration
as
you're
doing
your
planning.
C
A
Mean
you
could
argue
that,
even
though
it's
not
completely
broken,
you
know,
if
there's
a
big
customer
that
really
needs
this
fix,
then
the
prioritization
would
be
higher,
because
we
need
to
get
this
fixed
else.
We
lose
a
contract
and
even
though
there
isn't
work
around
right,
so
I
mean
you
could
argue
either
way
whether
or
not
the
SLO
should
be
based
on
the
priority
or
the
severity
yeah
I
think
at.
B
E
F
It
feels
to
me
that,
like
the
simplest
solution
is,
if
we
want
a
way
of
like
prioritizing
something
in
a
backlog,
we
do
create
our
own
way
of
doing
it
and
don't
try
to
cross
work
for
something
that's
being
used
elsewhere
like
to
me.
The
P
labels
don't
really
set
any
customer
expectation
or
any
customer
promises
to
when
something's
going
to
be
delivered.
I
think
milestones.
Do
that
I.
Think
due
dates
do
that,
but
P
labels
are
more
about
our
process
and
I.
Think
that's
true.
F
We've
kind
of
like
just
generally
see
about
what
P
day
was
something
answer
has
across
the
whole
of
gitlab
ie
security
issues
and
how
they're
prioritized,
but
also
within
a
specific
milestone
as
well.
I.
Think
priorities
within
a
milestone
is
surely
for
the
kind
of
people
who
are
who
are
working
off
that
board.
E
A
E
A
A
So
if
I
see
that
something's
in
next
1
2
3
those
priority
labels
already
kind
of
provide
that
sort
order
versus
the
list
of
issues
and
13
know
what
the
priority
label
is
already
so
I
don't
know
that
it
really
needs
an
additional
set
of
labels
to
indicate
that
priority
I
understand
the
pushback
with
regards
to
security
and
bug
issues,
but
I
think
that's,
ultimately,
something
that
we
have
to
be
in
control.
Anyways
too,
because
to
your
point
is
like
we
do.
A
My
understanding
is
that
we
need
to
focus
on
button
priority
and
performance
issues
above
deliverables
now,
I,
don't
think
we
want
to
go
overboard
with
that
to
the
point
where
we
don't
have
any
deliverables
or
like
directional
features
going
because
otherwise
we
have
the
problem
with
access
where
it's
like.
We
just
be
overloaded
fixing
bug
and
security
issues.
At
the
same
time,
we
should
be
in
control
of
defining
what
that
priority
is
because
yeah,
okay,
maybe
security
or
whoever
is
setting
priorities,
and
we
should
fix
this
in
30
days.
A
But
if
we
were
to
follow
that
religiously,
we
would
never
be
able
to
work
on
feature
work,
so
it
should
be
up
to
us
to
commit
to
when
we
actually
would
be
able
to
look
to
deliver
it.
And
if
that's
the
case
and
if
that's
something
we
want
to
educate.
You
know.
People
who
are
you
know
pushing
back
on
this
then
I
think
that's
okay,
because
it
makes
no
sense
to
leave
something
as
a
p1
and
pretend
a
little
attorney
in
30
days
when
we
won't
right,
yeah.
E
It
sounds
like
part
of
it.
I
think
to
Dennis's
point
is
just
setting
expectations
like
even
when
I
change
milestones,
I,
try
to
leave
a
comment
as
to
why
I'm
changing
it
from
maybe
a
concrete
milestone
to
a
directional
one,
and
in
this
case
like
if
it's
programmatically
assigned
to
P
label-
and
you
know
that
there's
folks
watching
it-
you
can
just
say,
hey
I'm,
moving
this
to
p3,
because
P
2
isn't
feasible
with
what
we
need
to
ship
and
it
doesn't
seem
like
this.
E
C
C
Right,
I,
just
stack,
rank
them
and
just
like
work
with
a
dev
team
and
say
hey
in
general,
take
from
the
top
and
work
your
way
down
right
and
that's
what
I've
done
it
simple
right
and
without
like
labels
and
like
categories
I
would
love
to
be
able
to
do
that
right,
taking
into
account
the
P
and
s
labels
without
like
bucket
icing,
so
much
on.
What's
in
the
milestone.
A
So
I
mean
I,
guess
what
are
we
looking
to
I
feel
like
we
should
be
able
to
change
my
priorities.
Do
change
right.
Like
you
know,
one
of
the
ideas
about
you
know
having
the
milestone
labels
to
indicate
that
it
is
a
different
priority
than
what
it
was
before.
But
if
that's
the
case,
then
I
think
I
feel
like
it's
a
natural
course
for
us
just
to
change
the
p12,
the
p4
as
it
goes
through
a
triage
and
prioritization
and
finally
getting
scheduled
into
a
milestone.
F
F
I
just
added
something
to
the
document,
and
you
could
probably
argue
that
some
of
these,
like
conflate
into
the
same
things,
but
there's
like
six
different,
like
meaning
sort
of
six
different
ways
that
you
can
use
P
able
to
the
moment
I
could
think
off
the
top
of
my
head.
So,
like
the
security
team,
use
and
I
think
there's
a
lot
of
overlap
between
how
kind
of
they
used
to,
but
how
we
triage
bugs
with
them.
F
Infrastructure
have
their
own
way
and
in
terms
of
kind
of
like
production
issues
that
we've
run
into
then
there's
kind
of
the
overall
backlog,
prioritization
thing
that
we
were
talking
about.
We
then
have
a
slightly
different
meaning
for
how
we
then
use
P
labels
within
a
milestone
because
kind
of
it's
specific
to
that
milestone
and
further
in
the
manage
part
of
handbook.
We
also
say
that
we've
been
a
milestone
in
P
day.
We
also
refers
to
the
predictability
of
something
being
delivered.
I,
this
I
I,
guess
I
live
with
this
whole
conversation.
It's
like
it.
C
A
B
A
D
B
Not
even
I'm,
not
even
pretending,
like
I,
can
deliver
any
of
these
s.
Ellos
they're
they're,
really
meaning
what
I
say:
Mike
Ross
other
than
like
I
know.
If
something
was
entered
four
years
ago,
I'm.
Actually
you
less
priority
right
now,
there's
something's
indirect
now
is
that
thank
me
and
just
gone
away
so
I'm,
some
of
it
like
PSLs,.
C
F
You
could
still
honor
something
that's
deemed
appeal
on
security
that
say
it's
a
p2
within
our
milestone
because
we're
confident
we're
gonna
we're
gonna
get
to
it
and
kind
of
hit
on
time.
I
feel
like
you're
right,
Dennis,
I
feel
like
we.
We
do
need
to
kind
of
like
define
who
that
the
owner
of
that
label
is
and
what
its
primary
purpose
is.
One
the
things
I
was
talking
to
Harris
about
in
a
one-on-one
the
other
day
was
how
much
autonomy
do
we
have
within
each
individual
group
and
I.
F
Think
some
of
that
depends
on
like.
Ultimately,
what
are
the
things
that
can't
change
you
all
the
things
that
are
fixed
outside
of
the
group
say
things
like
pee
tables
and
as
far
as
I've
understood,
that
pee
tables
are
primarily
for
the
purpose
of
security,
like
at
the
number
one
and
they're,
probably
for
bug,
purpose
and
infrastructure
afterwards
and
from
a
product
point
of
view
for
product
prioritization.
F
We
probably
come
right
at
the
bottom
and
and
if
that
is
the
case-
and
it's
like
that,
those
labels
are
not
movable
because
security
have
their
own
process
around
them,
and
then
we
would
seem
quite
reasonable
that
if
we
did
decide
in
each
milestone,
we
want
to
have
four
different
categories
of
priority
and
I
mean
creating
our
own
label
to
do.
That
seems
fairly
reasonable
to
me
and
yeah.
C
Was
gonna
head
to
the
autonomy
point
to
like,
even
within
our
groups?
Right
because
have
you
asked
me
my
preference
would
be
like
we
load
the
milestone
with
what
we
know
we
can
achieve.
We
stack
rank
it
and
I'm
done
like
I
personally,
don't
want
to
like
put
things
in
pee
buckets
and
like
if
other
people
want
to
like
that's
fine,
but
my
preference
would
be
not
to
do
that
right.
So.
G
F
F
But
we
decided
to
scrap
that
and
what
we
wanted
was
a
bit
more
predictability
to
say:
let's
schedule
what
we
think
we
can
deliver,
it
seems
that
our
documentation
around
those
pee
tables
then
kind
of
negates
that,
because
it
says,
if
something's
at
p4,
we
think
there's
only
a
50%
chance
of
it
be
engineered
within
that
milestone,
and
so
I'm
I
would
support
that
as
well.
Minister
I,
don't
completely
by
the
value
of
having
P
labels
within
a
particular
milestone.
F
G
We
should
commit
to
it
and
like
eventually,
we
should
commit
to
the
entire,
like
whatever
we
have
scheduled
in
the
mouth
soon.
Eventually,
that's
that's
what
we
gonna
ship
in
that
mouth
stone
and
it
should
be
probably
a
little
more
conservative
on
the
planning
side
and
then
we
don't
need
P
labels
at
all,
because
everything
has
to
say
priority
in
that
mouth
sooner
and
we
can
commit
to
that.
G
B
B
Four
things
are
done,
some
people
close
it
some
people
leave
it
open
with
a
label
or
whatever
like
if
there
are
reasons
for
us
to
standardize
on
things,
and
we
discussed
those
problems.
Okay,
in
order
for
us
to
be
able
to
I,
don't
do
X
or
CX.
We
need
to
have
visibility
into
this
and
therefore,
let's
come
up
with
the
reason
so
I
don't
know
if
we
are
solving
an
actual
problem
by
standardizing
on
this
process.
I
agree.
F
What
I
think
have
been
a
way
of
like
having
a
list
of
what
the
things
that
have
to
be
I
think
that
anything
else
you
can
have
alternate
to
autonomy
on
within
a
group.
So
one
of
the
things
that
has
to
be
is,
if
you
most
let
me
in
a
milestone.
The
issue
gets
the
sun.star
milestone.
So
it's
like
a
really
obvious
one,
but
everyone
agrees
to
that.
F
That's
one
of
the
things
that
has
to
work
no
group
that
get
that
would
just
whoa
you've
got
a
bunch
of
issues
without
assigning
any
milestones
in
your
ship.
What
they
want
and
but
I
think
there's
very
few
of
those
things.
I
think
you're
right
Harris
is
too
like.
If
we
do
have
those
it
would
be
good
to
know
why
and
at
what
sort
of
level
they're
they're
being
enforced
out
and.
A
That's
what
I
want
to
understand
is
if
we
have
a
global
constraint
as
an
organization
to
commit
to
some
degree
these
are
solos
and,
if
not
that's
been
that's,
let's
figure
out
what
works
for
us,
whether
that's
at
a
stage
or
a
group
level,
but
I
would
like
to
figure
that
out
before
we
have,
you
know
import,
maybe
doesn't
respect
vessels
at
all,
whereas
analytics
and
access
do
or
you
know,
compliance
has
their
own
way
of
listing
issues
without
P
labels
at
all
and
one
it's.
You
know
if
we
want
the
ability
to
do
that.
A
That's
fine,
let's
document
it
but
I
want
to
understand
what
what
we
look
at
in
terms
of
like
do
we
respect
those
at
all,
because
that's
I
would
imagine
you
know
if
we,
if
a
group
just
didn't
look
at
that
at
all.
Probably
someone
would
take
issue
with
that
from
from
senior
management.
That's
my
feeling
at
least
and.
F
Then
I
agree
with
that
as
well
goodness
I
think,
but
from
my
perspective,
like
the
P
labels
are
set
by
security
are
enforced
across
the
organization
as
far
as
I'm
aware,
like
I've,
always
respected,
and
that
doesn't
mean
we've
always
been
out
to
deliver
on
them.
Quite
the
opposite.
Actually
because
it's
a
big
box
of
weeds
that
we've
had
and
but
it's
not
clear
right,
it's
not
clear.
But
to
me
in
one
place
you
say
you
must
kind
of.
F
B
First,
but
not
as
a
stack
rank,
it
is
a
list
of
10
things
that
we
take
into
account
and
things
on
top
are
more
important
things
below
it,
but
it
is
not
so
that
everything
that
is
in
that
first
priority
sentence
has
to
be
done
before
we
ever
get
to
anything.
That's
in
the
second
part
of
the
list
and
that's
kind
of
where
you
know
so
that's
the
input
that
I've
taken
into
into
into
prioritization
and
definitely
if
I,
have
an
s1
or
a
p1
issue
that
is
going
into
the
next
milestone.
B
But
that's
a
you
know:
that's
input
into
prioritization,
one
of
the
inputs,
so
you
know
not
that
they're
not
being
respected.
Actually,
we
do
try
really
hard
and
we
manage
a
lot
of
times
with
new
issues
incoming
issues,
but
there's
a
lot
of
issues
in
backlog
that
have
been
missed.
So
we
don't
always
deliver
on
these.
That
just
has
to
be.
You
know.
We
need
to
be
able
to
say
that
and
you,
okay
with
it.
F
Yeah
and
I
think
that
is
largely
how
it
works
right,
because
we
all
have
stable
counterparts.
We
have
stable
counterparts
and
security
and
quality.
Who
are
there
to
kind
of?
Like
argue,
why
it's
important
and
to
try
and
hit
me
sort
of
SLO
that
they're
responsible
for
and
as
you
say,
that
does
full
member.
It
doesn't
dictate
exactly
what
gets
done
cuz
if
it
did
for
the
last
year.
We
would
have
only
worked
on
security
issues
in
access
and
I
think
everyone's,
obviously
far
more
pragmatic
than
that
I.
A
Right
now,
and
just
in
terms
of
following
up
on
this,
so
we
can
kind
of
keep
the
momentum
going
in
terms
of
because,
because
I
kind
of
just
want
to
understand
how
what
which
I
can
just
confirm
like
do
we
respect.
Ssl,
though,
is
only
for
bug
and
security,
and
then
at
that
point,
which
groups
do
we
align
at
all
on
how
we
approach
prioritization
after
that
or
not
what
I'm
trying
to
get
to
yeah.
G
F
We
want
to
discuss
workflow
labels,
priority
labels,
sorority
labels,
and
it
might
be
quite
interesting
if
we
can
get
a
list
of
the
things
that
we
know
like
are
like
label
constraints
or
stage
watch
constraints
each
product
manager
can
then
I
would
be
quite
interested
here
from
each
product
manager
in
terms
of
what
their
vision
for
their
group
would
be
like
how
they,
if
you
have
full
full
autonomy
on
everything
else.
What
would
the
process
look
like
and
would
that
be?
Scoped
prioritization
labels
are
different
from
P
labels.
A
Because
it
sounds
like
we
do
have
our
own
different
preferences,
so
I
would
like
those
like
actually
clearly
identified,
and
if
that's
the
case
then
that's
totally
fine,
but
we
also
do
need
to
be
cognizant
of
like
you
know.
What
you
are
doing
may
not
may
not
respect
the
SLS,
and
if
that's
the
case,
then
that's
just
something
we
have
to
make
clear
to
other
people
as
well.
That
you
know
security
has
to
be
aware
that
you
know
your
priority
mail
labels,
our
inputs,
but
not
you
know,
forced
guidance
or
things
like
that.