►
Description
Package team conversation covering monthly milestone dates, how weekly releases work from the engineer's standpoint, and how they fit together with the monthly self-managed release.
A
All
right,
so
there
is
a
link
for
a
document
in
the
invite
or
the
calendar
item,
and
it
looks
like
Dan
you're
in
there.
So
today
we're
just
gonna
go
over
a
few
of
the
highlights
of
you
know
different
dates
and
things
that
occur
throughout
a
milestone.
How
that
fits
into
this
whole
weekly
release
system
and
really
how
you
can
tell
where
things
are,
you
know,
is
it
still
in
development?
Is
done
in
production?
Isn't
on
staging?
A
Is
it
going
to
make
a
certain
week's
release
a
certain
months
release,
and
so
the
overarching
idea
is
that
it's
anyone
that
that
wants
to
know
the
status
of
a
given
issue.
You
should
just
be
able
to
look
at
the
issue.
There's
the
workflow
labels,
which
we've
started
to
see
on
all
of
them,
and
that
will
give
a
sort
of
at
a
glance
status.
A
A
But
really
we'll
jump
right
into
the
workflow
labels,
which
is
also
part
of
that
engineering
workflow
page,
and
so,
if
you
click
on
that,
you'll
you'll
see
a
breakdown
of
the
overall
flow
of
what
was
expected
of
an
engineer
when
they're
working
on
our
merge
request,
and
so
the
idea
is
that,
when
a
developer
starts
working
on
a
merge
request
in
the
actual
issue,
as
well
as
a
merge
request,
the
label
should
be
added
saying
that
is
in
development.
And
this
just
means
that
you
know.
A
A
The
label
will
change
from
in
development
in
review,
and
this
includes
all
of
the
steps
of
the
review
process.
So
the
initial
reviewer
database
review,
if
it's
necessary,
the
maintainer
review
and
all
of
the
back-and-forth
with
feedback
in
between
there
is
one
additional
label
that
I
didn't
list
in
the
Google
Doc
here,
which
is
blocked,
and
so
that
would
come
up
specifically.
If
somewhere
along
the
line
in
any
of
these
processes,
something
happens
and
it's
completely
blocked
by
another
issue
or
another.
You
know
something
else.
A
A
B
All
really
helpful,
we
should
be
using
these
labels.
I
actually
just
talked
to
Jason.
My
boss
just
asked
me
today.
If
we
were
to
use
following
this
process
and
I
said
no,
but
we
should
be
doing
like
right
now,
things
that
are
in
12:4,
for
example,
should
be
set
from
my
perspective,
with
ready
for
review
or
ready
for
development,
or
something
like
that,
like
there's
other
and
then
as
you're.
If
it
once
you
start
developing,
that's
when
you
put
it
in
workflow
in
dev
right.
A
B
B
A
Actually,
I
wasn't
even
aware:
it
looks
like
a
whole
bunch
of
new
workflow
labels
have
been
created
recently,
so
ready
for
development
production,
scheduled
and
canary
are
all
pretty
new,
like
maybe
very
new
they're,
not
reflected
in
that
engineering
workflow
document,
yet
at
least
but
yeah.
That
totally
makes
sense
that
we
can
set
things
as
ready
for
development
and
so
on
from
there.
Okay.
B
Yeah
I'm
realizing
a
Dan
and
John
we're
just
going
through
the
new
milestone
and
some
labeling
like
things,
weren't
labeled
or
were
labeled,
and
so
I
think
this
is
really
helpful
for
me,
be
justice
just
to
agree
about
like
okay.
This
is
what
we
should
be
labeling
issues
and
how
it
should
be
done.
So,
okay,
I'll,
stop
my
interruption.
Thank
you.
No.
A
C
Work
as
well,
because
I
think
the
problem
comes
with
the
like
in
production,
sort
of
in
Canary
kind
of
labeling
I
think
I
had
an
issue
from
Aaron's
team:
oh
I'll
get
this
I
mean
they
might
be
getting
around
to
it.
My
suggestion
was
like
how
do
you
know?
That's
ready
to
go.
I
was
hoping
that
we'd
end
up
with
a
bot.
That
would
do
that
for
you,
so
you
wouldn't
have
to
be
like.
Did
you
get
there
to
get
their
group
and
then
change
it?
C
So
I'm
not
sure
if
that's
part
of
this
effort,
but
I'd
have
to
go.
Look
at
the
Week
in
Review
I
guess
to
figure
out
whether
there
was
some
effort
that
changed
had
these
workflow
labels,
the
new
ones
that
is
not
the
existing
ones
in
in
dev
and
then
in
review,
and
then
the
other
one
we
have
as
well
as
those
ones
should
all
be
pretty
familiar
that
and
being
actively
used
right
now.
A
A
Looking
at
these
labels,
we've
got
workflow
verification,
there's
workflow
canary,
and
so
that
would
be
after
it's
been
verified
on
staging
it
would
go
to
canary
and
then
after
it's
been
a
canary,
then
it
would
go
to
production,
and
so
then,
once
it's
on
production
that
that's
the
point
at
which
the
issue
should
be
closed.
So
it
looks
like
actually,
there
are
new
workflow
labels
that
will
help.
You
know
kind
of
help
understand
where
things
are
as
long
as
they
are
up
to
date.
A
A
A
This
is
kind
of
taken
from
the
developer
point
of
view,
so
sort
of
the
dates
that
I'm
kind
of
paying
attention
to
as
I'm
working
every
month,
and
so
when
it
comes
to
the
milestones
milestones
are
tied
specifically
to
the
self-managed
releases,
since
everything
else
I
mean
everything's
getting
rolled
that
week
to
week.
So
certainly
we're
tracking
issues
as
they're
going
through
a
milestone.
A
But
you
know
an
issue
can
be
pushed
out
to
get
lab
comm
on
any
given
week
can
be
at
the
beginning
of
the
next
milestone
at
the
end
of
the
next
milestone,
and
it's
it's,
it's
prioritize
to
be
within
a
milestone,
but
it's
a
little
bit
more
difficult
to
keep
track.
So
when
it
comes
to
the
specific
milestones
from
the
development
standpoint,
development
begins
on
the
8th
of
each
month
and
ends
on
the
7th
of
the
next
month.
That
was
previously
when
there
was
the
code
freeze
and
that's
no
longer
really
a
thing.
A
So
it's
kind
of
like
a
soft
end
of
work
on
the
7th
there's,
nothing
preventing
you
from
continuing
work,
there's
no
hard
to
cut
off
anymore,
but
as
a
general
idea,
it
suggested
that
all
work,
that's
not
yet
in
review
by
the
7th,
should
be
pushed
off
of
that
milestone
and
since
the
next
one's
already
planned,
it
should
go
into
the
one.
After
so
it
should
skip
one.
A
So
if
you're
working
on
12-point
o
the
seven
hits
and
there's
a
piece
of
it
that
you
haven't
started
or
that
you
haven't
gotten
into
review
yet
and
you
get
pushed
to
you
12
there's
some
wiggle
room
there
as
I
mentioned,
because
it's
no
longer
a
hard
date.
What
these
weekly
roll
loves,
but
that
the
idea
of
that
is
to
help
keep
things
organized
and
and
prevent
things
from
slowly
stacking
up
and
making
it
very
difficult
to
finish
any
given
milestone
and
taking
away
time
from
the
next
milestone
and.
C
B
A
And
yeah
and
I've
I
keep
like
not
understanding
whether
it's
the
17th
or
18th
I
think
it's
like
kind
of
over
the
last
few
months
it's
been
17
than
than
the
18th,
and
it's
kind
of
switched
back
and
forth
on
what
is
the
actual
hard
cutoff
for
getting
into
the
self
man.
They
just
release
and
I.
Think
that's
just
because
it
there's
still
kind
of
refining
this
process,
but
yeah.
That
is
the
general
idea.
Is
that,
like
technically,
you
could
keep
developing
all
the
way
up
until
the
17th.
A
But
that's
you
know
the
whole
time
of
that
is
you're
supposed
to
be
working
on
the
next
milestone
at
that
point.
So
if
something's
in
review
and
you're
just
kind
of
working
through
feedback,
then
that
makes
sense,
but
if
you're
just
kind
of
still
doing
the
initial
work
to
get
it
into
review,
it's
probably
the
best
to
push
it
off.
A
A
Hard
dates
involved
really
outside
of
those
final
release,
dates
it's
sort
of
just
a
lot
of
guidelines
at
this
point
because
of
the
weekly
rollouts
now
so
to
kind
of
dig
into
the
weekly
rollouts.
So
whenever
a
whenever
I
finish
a
merge
request
and
it
has
been
merged
into
master,
so
it's
part
of
the
verification.
A
A
A
And
for
each
one
of
those
anything
that
gets
checked
off
on
the
Mondays
issue,
it'll,
probably
end
up
on
canary
on
Tuesday
and
and
so
on,
and
so
forth.
At
least
that's
how
I
understand
it.
I
don't
take
my
word
for
100%
on
that
I'm,
pretty
sure
that
every
one
of
those
many
releases
will
end
up
on
canary
and
then
they
all
get
merged
together.
For
the
final
push
to
production
on
Monday.
A
A
A
B
A
B
A
Yeah
and
I
mean
it's
more
of
whether
or
not
it's
a
hassle
for
you
to
look
up
the
commit
hash
or,
if
I
happen,
to
have
it
on
hand,
but
either
way
yeah.
It
looks
like
this'll
save
a
lot
of
time
compared
to
the
previous
one
that
I
had
described
up
above
that
we
don't
have
to
go
through
of
where
you
have
to
kind
of
manually
go
through
that
process
to
see
where
it
is.
B
Yeah
that
I
think
this
is
really
helpful.
I'll
probably
go
back
and
re-watch
this
video
another
time,
but
yeah
I
think
generally
I
have
a
much
better
sense
of
how
it
works,
and
it
does
make
me
think
that
myself
included
I
haven't
really
been
using
the
workflow
board
that
we
have
and
I'm
not
sure
how
widely
adopted
that
that
is
now.
But
it
sounds
like
we
should
definitely
be
using
that
yeah.
A
B
Maybe
what
we
need
is
that
board
to
be
expanded
to
include
all
of
the
workflow
stuff,
and
then
this
way
we
could
see
I,
don't
know
I
guess:
I
need
to
visualize
it
first
and
I'll
test
it
out
and
send
some
stuff
around,
because
I
do
think.
It's
helpful
like
there's
stuff
in
12,
6
or
12
7
that
we're
not
really
then
I'm
ready
to
work
on
and
they're
there.
You
know
my
current
way
of
doing
is
assigning
them
to
me
and
I
could
add
in
that
product
label.
A
A
Well,
it
was
kind
of
almost
making
me
think
that,
like
does
it
make
sense
to
be
doing
the
monthly
milestones,
as
we
do
now,
cuz
like,
given
that
we
have
these
monthly
releases
and
I
know
that
that's
certainly
a
product
thing
with
you
know
you
plan
a
month's
worth
of
milestone,
so
I
don't
know,
there's
just
something:
I
was
kind
of
thinking
about.
We
were
like
you
know:
could
it
just
be
a
continuous
flow
of
work
and
then,
every
month
on
the
seventeenth?
C
That's
what
we've
been
doing,
which
is
like
you
know,
my
read
so
far,
has
been.
We
are
trying
to
adapt
our
development
workflow
to
give
us
more
time
to
write
code
in
less
time,
trying
to
wake
stuff,
I've
been
trying
to
work
forward
with
the
sense
that,
like
hey,
let's
prioritize
the
list
to
make
sure
we're
like
what
was
that
and
a
bunch
of
other
engineering
managers.
C
It's
sort
of
following
the
same
strategy,
so
I
think
I'm
happy
to
actually
try
being
very,
like
completely
do
exactly
what's
on
the
workflow
diagram
and
just
see
how
it
works,
but
given
how
small
we
are,
how
much
we've
got
to
do
and
all
those
sorts
of
things
I've
been
leaning
in
the
other
direction
for
the
most
part.
What
we
can
say
in.
B
B
Oh
okay,
that's
going
to
launch
in
twelve
six
that
that
looks
cool.
That
looks
good
even
though
those
dates
are
unreliable,
even
though
they
may
get
it
soon
or
even
though
it
may
change.
It's
like
there's
still
some
value
in
that,
but
if
we
could
solve
that
problem,
like
maybe
you
know
and
and
then
we
use
it
for
the
kickoff
document
in
the
blog,
which
is
a
way
of
announcing
things
and
bundles,
but
really
if
we
could
solve
the
bundling
problem
and
maybe
skip
some
of
the
heavier
weight
planning
for
milestone
stuff.
B
C
Think
looking
at
the
labeling,
that's
the
biggest
thing
that
I
see
here.
I
think
it's
super
valuable
is
like
this
workflow
labeling
I
just
set
up
a
workflow
board,
there's
like
two
seconds,
so
you
can
all
look
at
that.
I
think
them
correctly
based
on
your
explanation
and
they
guesstimate
on
some
of
these
extra
labels
that
are
just
appearing
I.
Think
that
this
labeling
is
generally
something
I've
used
in
the
past
in
India
or
whatever,
where
it's
like.
C
Let's
prioritize
that
work
and
make
sure
we're
delivering
what
we
commit
to
deliver
and
then,
as
we
realize,
hey,
there's
a
gap
here,
let's
go
look
at
the
work
flow.
Look
at
the
guidance
from
the
team
from
Gil
AB
and
like
go.
Do
that
so
kind
of
that's?
That's
where
my
head's
been
at,
but
I
think
this
is
very
helpful.
I
love
these
labels
and
I
think
we
should
identify
areas
where
we
think
there's
a
problem
to
look
for
solutions.
I,
don't
know
if
I'm
helping
send
them
to
stop
talking
I
think.
A
I
guess
like
are
we
leaning
towards?
Maybe
we
shouldn't
pay
as
close
attention
to
the
idea
like,
as
you
said,
we
haven't
been
paying
very
close
attention
to
the
idea
of
you
know
on
that.
Seventh
or
eighth
push
everything
up
milestone
or
to
you,
so
we
just
kind
of
sort
of.
Are
we
gonna
kind
of
keep
with
that
flow
of
you
know
just
keep
working
on
what
we're
working
on
and
just
worked
on
the
list.
C
I'm
happy
to
try
that
I
think
the
risk
here,
as
you
mentioned
Steve,
is
that
is
the
potential
to
end
up
like
a
whole
milestone
behind,
because
we
just
keep
missing
this
and
missing
that
and
so
I
think
I
think
that's.
This
is
the
maybe
the
second
Tim
correct
me
if
I'm
wrong,
I
think
this
is
maybe
the
second
milestone
that
we've
actually
kind
of
gone
through
and
going
our
okay.
We've
got
leftover
stuff
here.
What
do
we
do
with
it?
How
do
we
then
allocate
it
I?
C
We
still
are
supposed
to
deliver
that
thing
next
and
put
our
effort
in
for
that
thing,
and
so,
whilst
Tim
determines
that
that's
our
next
most
important
thing.
That
should
be
where
we
spend
our
energy
and
then
so.
That's
my
main
concern
about
having
this
like.
Well,
we
didn't
get
it.
So
it's
going
in
one
two
milestones
down
the
track.
It
still
may
be
our
top
priority,
but
that's
a
determination
that
I'm
sort
of
maybe
to
a
fault
left,
attended
aside.
B
B
I've
been
doing
is
saying
once
it
does
get
moved
I
then
go
into
the
board
and
move
things
around
so
like,
for
instance,
some
of
the
like.
If
Conan
slipped,
you
know,
I
put
Conan
to
the
top
of
the
list
in
12
3,
because
that
still
is
the
most
important
thing
to
finish
for
12
3,
so
I
think
if
we
move
it
over,
that's
fine
because
I'm
still
constantly
doing
this
like
ordering
and
reordering
process.
So
we
will
always
have
the
most
important
things
scheduled
and
given
milestone.
C
A
B
Example
might
be
like
if
a
front-end
thing
that
Nick
is
working
on
in
making
this
front-end
change,
but
then
you
finished
Conan
and
Conan's
ready
to
go
in
the
front
end
like
okay.
Well,
that's
gonna
be
more
important
for
him
to
do,
and
maybe
that
other
stuff
he
was
working
on.
Maybe
that
could
actually
wait.
Yeah.
C
So
I
need
to
barrel
actually
have
another
meeting,
but
the
thing
I
wanted
to
say
is:
let's
take
an
action.
My
action
item
item
out
of
this
to
say
at
a
minimum.
We
ought
to
be
looking
at
what
we're
moving,
what
we're
not
completing
in
a
milestone.
We've
just
had
a
conversation
about
this
actually
yesterday
evening
and
sort
of
followed
up
on
it
a
little
bit
more
so
that
we
can
actually
evaluate
it
and
Steve
you're
welcome
to
join
those
meetings.
I
don't
think
any
meeting.
C
I
have
is
private
I,
don't
even
care
of
people
in
my
one-on-ones.
To
be
honest,
it
doesn't
matter
to
me,
but
like
and
I'm
thinking
about
doing
that
by
the
way,
but
like
then
actually
have
a
look
at
okay.
What
are
we
gonna
miss
here
and
then
how
do
we
then
reprioritize
it
and
maybe
maybe
Steve
you
could
sit
in
that
and
understand
it
and
give
feedback
on
what
you
think
is
not
making
sense.
So
maybe
we're
just
you
know
it
might
be
good
to
get
some
feedback
for
both
of
us
on
that.
C
But
let's
schedule
I
meant
to
go
through
the
list
of
issues
that
we
have
open,
though,
that
that
were
pulled
over
from
12
to
into
12
3,
and
so
I
still
need
to
do
that.
So
maybe
that
can
form
the
basis
of
it
I
do
you
do
either?
If
you
want
to
schedule
a
meeting
for
that,
really
want
me
to
do
it
or
what
do
we
think?
Is
we
already
reprioritize
them
right?
Tim.
C
That
works
for
me
right.
We're
gonna
be
a
little
bit
more
prescriptive
about
the
use
of
the
mister
milestone
labels
by
the
way,
so
I'm
sort
of
made
a
request
of
Tim
that
we
don't
move
anything
and
if
we
miss
70%
of
what
we're
committed
to
then
we're
gonna
see
it
and
it's
gonna
be
in
everything.
So
I'm
I'm
concerned
that
we
don't
have
a
clear
idea
of
velocity
so
and
they're
still
going
to
go.
C
C
B
C
C
B
C
To
keep
using
those
Monday
meetings,
it's
it's
risky,
because
if
we
ever
ever
cut
other
things
we
need
to
cover,
then
we
just
end
up
like
rushing
everything
and
we
don't
do
a
good
job
of
any
of
it.
So
I'd
prefer
to
have
a
separate
retro
meeting
and
let's
just
trial
it
I'll
set
up
a
meeting.
Let's
just
trial
it
for
this
month
and
we'll
do
that
now
meeting
is
about
to
end
so
really
good,
then
that's
it
so
also
got
meeting
up
today.
Okay,
thanks
Tim,
bye,.