►
From YouTube: 2020-08-28 Package Weekly Retro
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
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
going
to
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
it
on
production?
Is
it
on
staging?
A
Is
it
going
to
make
a
certain
week's
release
a
certain
month's
release,
and
so
the
overarching
idea
is
that
it's
anyone
that
that
wants
to
know
the
status
of
of
a
given
issue.
You
should
just
be
able
to
look
at
the
issue.
A
On
gitlab.com-
and
so
that's
a
fairly
recent
change,
but
that's
sort
of
moving
forward,
at
least
what
I'm
going
to
be
following
and
what
I
think
we
should
be
following
as
a
team.
I
think
it
is
outlined
in
a
few
of
the
documents
that
I
might
have
linked
further
down
here.
A
So
really,
what
we'll
end
up
kind
of
going
over
is
more.
If
you
wanted
to
dig
in
a
little
bit
further
than
that
to
maybe
you
know
the
developer
side
of
things
and
understand
you
know,
we've
got
the
product
dates
that
we
go
through
that
have
the
milestones
of
you
know.
A
This
is
when
the
milestone
should
be
planned
by
this
is
when
we
have
the
little
kickoff
meeting
and
all
of
that,
but
there's
also
sort
of
a
set
of
dates
that
the
developers
and
engineers
are
following,
and
so
that's
what
I
figured
I
would
kind
of
walk
through
for
everyone's
information
and
hopefully,
it'll
give
an
idea
of
when
things
happen,
on
the
weekly,
roulettes
and
monthly
rollouts
and
generally,
how
that
that
flows?
Does
that
sound
good
cool
all
right,
so
I
linked
the
product.
A
Important
dates
that
you're
probably
pretty
familiar
with
that's
just
for
reference
and
then
in
the
engineering
workflow.
Those
dates
are
kind
of
mirrored
there,
as
well
with
a
few
additional
pieces.
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
is
expected
of
an
engineer
when
they're
working
on
a
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,
a
label
should
be
added
saying
that
is
in
development.
And
this
just
means
that
you
know.
A
Hopefully
someone
is
actively
writing
code
and
there's
there
could
be
more
than
one
merge
request,
and
so
that's
why
it's
important
to
also
have
those
labels
in
each
individual
merge
request.
A
The
label
will
change
from
in
development
and
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.
A
You
know
something
else,
that's
going
on
to
the
point
where,
like
no
one
more
work
can
be
done
and
and
we
need
to
wait
for
someone
or
something
to
happen
and
usually
there'll,
be
a
comment
linked
to
that.
I
don't
think
we've
seen
that
come
up
yet
on
the
package
team.
A
B
All
really
helpful:
we
should
be
using
these
labels.
I
actually
just
talked
jason.
My
boss
just
asked
me
today.
If
we
were
just
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
once
you
start
developing,
that's
when
you
put
it
in
workflow
in
dev,
okay,
right.
A
Is
there
a
sort
of
like
a
ready
for
development?
Already
I
mean
is
that
kind
of
what
the
deliverable
tag
sort
of
stands
for
is
that
this
is
sort
of
like
part
of
the
milestone
and
it's
ready
to
be
worked
on.
B
C
Are
those
two
meant
to
be
the
same
thing?
Are
we
gonna
go
to
some
standardized
workflow
tag
for
deliverable,
or
is
that
just
gonna
always
stay
for
your
understanding.
B
A
B
A
So
actually
I
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
and
so
on
from
there.
B
Okay,
yeah,
I'm
realizing
that
dan
and
john
were
just
going
through
the
new
milestone
and
there
were
some
labeling
like
things,
weren't
labeled
or
were
labeled,
and
so
I
think
this
is
really
helpful
for
me
just
just
to
agree
upon
like
okay.
This
is
what
we
should
be
labeling
issues
and
how
it
should
be
done.
So,
okay,
I
I'll,
stop
my
interruption.
Thank
you.
Oh.
A
No
worries
yeah;
no
thanks
for
putting
that
out.
I
didn't
even
realize
that
those
existed
yet.
So
that's
good
to
know.
C
There's
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
for
martin's
team
a
while
ago.
After
this
I
mean
they
might
be
getting
around
to
it.
My
suggestion
was
like
how
do
you
know
that's
ready
to
go,
so
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
it
get
there?
Did
it
get
there
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
to
change.
Add
these
workflow
labels,
the
new
ones
that
is
not
the
existing
ones
in
in
dev
and
then
in
review,
and
then
the
the
other
one
we
have
as
well
is
those
ones
should
all
be
pretty
familiar
and
being
actively
used
right
now,.
A
Yep
and
verification
is
also
one
that
has
been
kind
of
foggy
for
a
lot
of
people.
I
think
because
it
wasn't
fully
written
out,
but
verification
means
that
the
maintainer
has
merged
it
into
the
master
branch
and
it
will
show
up
on
staging
soon.
After
usually,
I
think
it's,
I
think
we
push
the
staging
daily,
so
it
takes
about
a
day
after
the
merge
and
then
once
it's
merged
on
master.
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
on
canary,
then
it
would
go
to
production,
and
so
then,
once
it's
on
production,
that's
the
point
at
which
the
issue
should
be
closed.
A
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're
up
to
date,
I
think
it'll
be
something
that
we
might
want
to
remind
the
rest
of
our
team
of,
especially
since
there
are
these
new
ones
that
I
mean
I'm
just
seeing
for
the
first
time
as
well.
A
Yeah
they
aren't
at
least
not
yet
I'm
just
I
mean
I
would
bet
that
there's
probably
an
mr
in
process
of
updating
this
documentation
if
those
are
brand
new,
but
we
can
point
them
out
at
some
point.
I
think.
A
Ones
are
certainly
in
dev
in
review
and
verification
for
right
now,
since
those
are
the
ones
that
are
listed
on
that
document,
all
right
cool,
so
then
digging
into
sort
of
the
different
dates
and
how
they
revolve
around
the
milestone,
as
well
as
the
weekly
releases.
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
out
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
gitlab.com
on
any
given
week
could
be
at
the
beginning
of
the
next
milestone
at
the
end
of
the
next
milestone,
and
it's
it's,
it's
prioritized
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
eighth
of
each
month
and
ends
on
the
seventh
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
seventh
there's,
nothing
preventing
you
from
continuing
work,
there's
no
hard
cut
off
anymore,
but
as
a
general
idea,
it's
suggested
that
all
work,
that's
not
yet
in
review
by
the
seventh,
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.0,
the
seventh
hits
and
there's
a
piece
of
it
that
you
haven't
started
or
that
you
haven't
gotten
into
review,
yet
it
should
get
pushed
to
twelve
two
there's
some
wiggle
room
there,
as
I
mentioned,
because
it's
no
longer
a
hard
date
with
these
weekly
rollouts,
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.
B
And
and
so
just
to
confirms,
if
something
is
not,
if
something
has
not
it's
not
in
review
by
the
seventh,
then
it
should
be
moved
back
and
if
something
is
not
merged
by
the
18th
yeah,
then
it
misses
the
milestone
and
for
gitlab.com
no
big
deal
because
it'll
go
out
in
the
next
the
next
week,
but
for
self-managed
yeah
it
will
wait
a
whole
milestone.
Okay,.
A
Exactly
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
the
17th
and
then
the
18th
and
it's
kind
of
switched
back
and
forth
on
what
is
the
actual
hard
cut
off
for
getting
into
the
self
managed
release,
and
I
think
that's
just
because
it
they're
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
So
from
the
development
standpoint,
there's.
A
Like
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.
A
So
whenever
a
whenever,
I
finish,
a
merge
request
and
it
has
been
merged
into
master,
so
it's
part
of
the
verification.
Workflow
now
there's
automatic
qa
issues
that
open
up
that.
A
A
A
Yep
and
for
each
one
of
those
anything
that
gets
checked
off
on
the
monday's
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
100
on
that,
but
I'm
pretty
sure
that
every
one
of
those
mini
releases
will
end
up
on
canary
and
then
they
all
get
merged
together
for
the
final
push
to
production.
On
monday.
A
I
don't
know
if
you
have
chat
ops
access.
I
just
requested
it,
but
really,
I
think,
when
it
comes
down
to
it,
if
you're
curious
about
one
of
these
things,
you
should
probably
be
asking
whoever
was
working
on
it,
and
then
I
should
be
the
one
you
know
pulling
up
my
commit
hash
and
doing
all
that
work
to
check
it,
at
least
in
my
mind,
that's
how
it
probably
should
work.
B
That's
a
really
cool
feature.
I
if
I
could
see
that
being
very
useful,
because
I
could
just
if
I
had
chat
ops
access,
I
I
could
just
look
at
it.
Then
click
on
the
link
for
which
commit
we're
on
and
then
see
if
our
changes
are
included
in
that
commit
yep,
if
possible
and
and
if
not,
then
that's
what
you
would
do
when
I,
I
ask
you,
if
that's
possible,
but
I
should
try
and
get
chat,
ops
permission,
maybe
even
if
even
if
they
don't.
A
Cool
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
will
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.
A
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
it.
It
does
make
me
think
that
myself
included,
I
haven't
really
been
using
the
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.
A
Yeah
I've
tried
to
keep
my
issues
up
with
those
three
labels
and
it
looks
like
we'll
be
able
to
add
a
few
more
to
to
provide
a
little
bit
more
visibility
on
where
things
are
yeah.
We
should
definitely
be
using
that,
and
I
think
I
did
add
that
to
the
actual
like
12.
A
B
Okay,
yeah
I'll,
because
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
they're,
not
ready
to
work
on
and
they're
they're.
A
Cool
okay,
one
other
thing
that
like
while
I
was
kind
of
going
through
this
and
coming
up
with
this
info
and
making
sure
I
kind
of
had
these
ideas
correct
was
it
it
almost
didn't
make
sense
that
you
know
I
mean
it
does
make
sense
that
we
have
these
sort
of
monthly
dates
to
do
the
self-managed
releases,
but
at
the
same
time,
like
that
whole
idea,
where
you
know
trying
to
end
work
on
the
seventh
that
isn't
yet
in
review
and
pushing
that
off.
A
If
you,
if
you
keep
just
like
you,
know,
falling
and
letting
things
slip,
week-to-week
eventually,
you
could
fall
an
entire
milestone
behind
if
you
just
kind
of
like
keep
pushing
it
back,
and
so
that's
why
the
idea
of
pushing
work
on
the
seventh
to
a
different
milestone
makes
sense,
but
it
was
kind
of
almost
making
me
think
that,
like
does
it
make
sense
to
be
doing
the
monthly
milestones,
as
we
do
now
because
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.
A
So
I
don't
know,
that's
just
something
I
was
kind
of
thinking
about.
Where,
like
you
know,
could
it
just
be
a
continuous
flow
of
work
and
then
every
month
on,
the
17th
whatever
gets
in,
gets
in,
and
you
just
continuously
prior
to
prioritize
a
list
going
on.
A
C
Almost
like
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
and
less
time
trying
to
wait
for
stuff.
I've
been
trying
to
work
forward
with
the
sense
that,
like
hey,
let's
prioritize
a
list,
make
sure
we're
like
working
towards
that
and
a
bunch
of
other
engineering
managers
are
sort
of
following
the
same
strategy.
C
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
are
we
going
to
say
is
tim.
B
Well
I'll,
just
echo
what
you
said
said
there
to
say:
jason
mentioned,
he's
the
same
thing
for
him.
His
teams
today
so
release
and
verifier
are
sort
of
using
it
sort
of
not,
and
it's
not
really
been
widely
adopted
throughout
the
company.
Yet
so
we're
not
we're
not
laggards
in
that
sense,
although
we
we
can
do
more,
I'm
sure
I
think
the
really
the
for
me.
B
The
goal
of
the
milestone
is,
you
know
when
we
met
with
a
big
customer
last
week
and
we
went
over
one
of
the
epics
and
it
has
all
of
the
issues
and
they're
put
in
milestones
and
they
could
they
could
follow
along
that
epic
and
and
see
that
it's
very
helpful
for
them
to
be
able
to
put
that
in
mind,
to
be
able
to
say:
oh
okay,
that's
going
to
launch
in
12
6.
that
that
looks
cool.
B
That
looks
good
even
though
those
dates
are
unreliable,
even
though
they
may
get
it
sooner,
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
then
we
use
it
for
the
kickoff
document
in
the
blog,
which
is
a
way
of
announcing
things
in
bundles,
but
really
if
we
could
solve
the
bundling
problem
and
maybe
skip
some
of
the
heavier
weight
planning
for
milestone
stuff.
Maybe
that
could
be
something
that
we
could
do.
I
don't
know.
C
Yeah,
I've
been
a
big
sort
of
you,
and
I
talked
a
bit
about
this
yesterday,
tim
in
terms
of
like
planning
and
I've
been
sort
of
tiptoeing
around
some
of
these
subjects,
because
I
I
feel
like
we
could.
C
We
could
easily
get
into
a
situation
where
we're
just
spending
a
lot
of
time,
doing
bureaucratic
stuff
and
not
as
much
time
writing
code
and
getting
results,
which
is
our
top
value,
which
is
why
I
think
a
lot
of
teams
kind
of
end
up
doing
some
version
of
this,
depending
on
the
team's
makeup
and
what
they're
working
on
and
how
well
defined
it
is,
and
we
get
a
fair
amount
of
autonomy
is
how
we
you
know
in
terms
of
how
we
plan
that
all
that
stuff
out.
C
So
I
would
just
say
I
think,
looking
at
the
labeling,
that's
the
biggest
thing
that
I
see
here,
I
think,
is
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
I
ordered
them
correctly,
based
on
your
explanation
and
the
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
in
jira
or
whatever,
where
it's
like.
C
Okay,
what
state
is
what
state
are
each
of
these
things
in
and
we
could
easily
add
some
other
things
to
this
to
limit
down
the
scope
of
this
actual
board,
because
it's
obviously
a
lot
of
stuff
right
now,
but
I
I
think
my
suggestion,
my
intent
here
has
always
been
to
sort
of
minimize
the
overhead
and
let
people
just
work
as
much
as
possible,
which
is
why
I've
said
to
steve
and
you
tim
just
like
hey:
let's
get
a
prioritized
list
of
the
stuff.
C
We
need
to
deliver,
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
workflow,
look
at
the
guidance
from
the
team
from
get
lab
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.
C
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
someone
stop
talking.
C
A
That's
all
really
good,
so
are
you
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
a
milestone
or
two,
so
we
just
kind
of
so.
Are
we
going
to
kind
of
keep
with
that
flow
of?
You
know
just
keep
working
on
what
we're
working
on
and
just
work
down
the
list.
C
I'm
good
I'm!
Actually,
I
think
it
could
be
worth
trying
tim
up
to
you
whether
you
feel
like
it
would
be
helpful
or
not
to
sort
of
instead
of
just
pushing
everything
into
the
next
milestone
to
actually
push
it
into
the
following
milestone.
C
I'm
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
gone
are:
okay,
we've
got
leftover
stuff
here.
What
do
we
do
with
it?
How
do
we
then
allocate
it?
C
I
think,
having
a
hard
and
fast
rule
here
may
not
serve
us
well,
but
I'm
happy
to
try
it.
I'm
happy
to
sort
of
look
at
stuff
that
doesn't
get
completed
for
whatever
reason
and
then
just
go
okay.
Well,
this
didn't
get
completed,
move
it
to
twelve,
four
or
twelve
five,
whatever
the
two
one
one
or
two
out
is.
C
I
don't,
I
think,
that's
kind
of
an
arbitrary
way
to
change
our
priorities,
though,
and
that's
kind
of
my
main
concern,
because
because
the
emphasis
for
me
has
always
been,
let's
figure
out
what
our
priorities
are
and
focus
on
those
and
those
priorities,
don't
change
because
we
didn't
hit
the
7th
or
the
17th.
C
We
still
are
supposed
to
deliver
that
thing
next
and
put
our
effort
into
that
thing,
and
so,
whilst
tim
determines
that
that's
our
next
most
important
thing,
that
should
be
where
we
spend
our
energy
right
and
that's
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
too
a
fault
left
to
tim,
to
decide.
B
What
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
with
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
in
a
given
milestone.
A
I'd
have
to
like
start
relearning
it
from
scratch
and
figure
out
what
I
did
previously.
But
there
probably
are
some
things
that
you
know
that
don't
follow
that
rule
and
obviously
stuff
that
haven't
hasn't
yet
been
touched,
is
sort
of
in
its
own
category
as
well.
So.
B
A
good
example
might
be
like
if
a
front-end
thing
that
nick
is
working
on
in
making
this
front-end
change,
but
then
you
finish
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.
C
Yeah,
so
I
need
to
bail,
I
actually
have
another
meeting,
but
the
thing
I
wanted
to
say
is:
let's
take
an
action
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
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
I
have
is
private.
C
I
don't
even
care
if
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
re-prioritize
it
and
maybe
maybe
steve
you-
could
sit
in
that
and
understand
it
and
give
feedback
on
what
you
think
is
not
making
sense
or
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
and
that
were
pulled
over
from
12-2
into
12-3,
and
so
I
still
need
to
do
that,
and
so
maybe
that
can
form
the
basis
of
it.
I
do
do
either
of
you
want
to
schedule
a
meeting
for
that
or
do
you
want
me
to
do
it
or
what
do
we
think?
Because
we
already
re-prioritized
them
right?
Tim.
C
So
I'm
I'm
concerned
that
we
don't
have
a
clear
idea
of
their
velocity,
so
I'm
still
gonna
go
look
through
all
the
issues
that
we
moved
and
tim
gave
me
a
good
rundown
on
what
they
were
already
and
we
have
good
explanations
as
to
why,
but
I
think
that's
going
to
be
something
we
need
to
be
looking
at.
So,
let's
schedule
a
meeting
for
the
end
of
next
at
the
17th.
Is
it
when
we're
supposed
to
stop?
Or
do
you
want
to
schedule
that
close
to
the
22nd
10.
C
B
C
C
B
Yeah
but
then
like
then,.
B
C
Yeah,
I
just
don't.
I
don't
want
to
keep
using
those
monday
meetings,
it's
it's
risky,
because
if
we
have
a
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.
Our
meeting
is
about
to
end,
so
we
only
get
over
and
that's
it
so
I'll
set
that
meeting
up
today.