►
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
A
C
Think
I
was
the
one
that
posed
that
I
brought
up
this
question
that
he
had
here
and
I.
Think
where
I
landed
was
I've,
been
using
writing
down
an
implementation
plan
as
a
way
to
like
flush
out
the
requirement,
so
to
speak
like
okay.
Well,
oh,
this
is
this
is
just
a
part
of
process
of
thinking
through
and
make
it
a
little
bit
more
concrete,
but
it
might
be
nice
to
make
it
concrete
that
it'll
likely
change
and
that's
acceptable
and
not
like
the
final
and
has
to
be
it's.
It's
an
example
right.
B
Yeah
I
agree
with
Daniel
so
for
now,
I'm
just
focusing
on
implementation
plan,
especially
finding
out
the
places
why
we
need
to
touch
because
the
requirements
may
not
be
clear
at
the
beginning.
So,
with
this
implementation
plan
the
requirement
becomes
more
concrete
over
time,
but
yeah
at
the
beginning.
It
is
not
the
final
version
of
the
requirement
placed.
A
Me
ask
a
follow-up
question
for
you
both,
since
you
learned
not
as
tenure.
Do
something
is
this.
Is
writing
an
implementation
plan,
a
reflection
of
unfamiliarity
with
or
a
lack
of
tenure
with
the
project
or
product
projects
that
we're
working
on,
or
is
that
your
preferred
way
of
working,
even
as
you
become
more
experienced
and
exposed
within
the
various
projects
for
parking
within
I.
C
For
one
appreciate
and
enjoy
coming
to
an
issue
that
has
a
solid
implementation
plan,
sometimes
those
get
really
stale,
though,
and
so
it's
like
you
start
going
through
your
lies.
Oh
things
have
changed
since
then,
and
so
that
that
can
be
tough.
But
it's
really
nice
when
you
get
to
something
you're
like
alright,
a
lot
of
the
upfront
thinking's
been
done,
I
can
just
get
into
it
and
like
really
solve
the
problem
and
move
forward
rather
than
I
mean
it's
kind
of
like
the
getting
things
done.
C
Approach
right
like
do
your
critical
thinking
and
planning
ahead
of
time,
so
that
you
have
clear,
actionable
work
when
you're
ready
to
actually
do
the
work.
So
that's
just
that,
but
I
think
that's.
That
can
definitely
be
a
personality,
and
you
know
a
preference
thing,
so
I'm
I'm
fine
going
with
other
approaches,
but
that
is
my
preference.
D
D
We
do
this
making
sure
that
there's
like
a
summary
comment
where
we
sort
of
summarize
whatever
the
threads
are
I
mean
even
this
issue
as
simple
as
it
is,
is
already
kind
of
hard
to
follow,
with
the
way
that
our
comments
work
so
I,
like
the
diverged,
consider,
argue,
etc,
but
then
like
if
you've
got
something
like
if
you've
got
this
issue
loaded
into
your
brain.
You've
got
the
context
on
it.
So
like
set
an
overview
of
like
a
proposed
recommendation,
moving
forward
and
I
think
that'll
help
us
really
sort
of
keep
issues
moving.
C
See
you
mentioned
summary
comment:
that's
kind
of
what
I've
been
doing
with
the
description
and
and
that's
kind
of
how
I
see
it
too
is
like
alright.
This
is
the
the
most
current
state
of
reality.
As
we
see
it,
going
forward,
yeah
and
I
think
that's
really
important
to
like
try
to
wrap
it
all
up
together
but
like
having
it
a
do
you
want
a
comment,
or
do
you
mean
like
in
the
description
know
how
we
both.
C
Right,
oh,
okay.
Okay,
so
you
add
a
new
comment.
Generally,
when
I'm
doing
the
thread,
I
wrap
the
cut
the
thread
up,
say:
okay,
this
is
where
we're
at
with
it.
This
is
where
I'm
going
with
it.
This
is
what
I
put
it
in
the
description.
Would
you
say
it'd
be
good
to
also
have
another
comment
at
the
bottom
saying:
I've
done
addressed
all
the
threads
or
you
think.
That's
sufficient
I.
B
C
On
some
of
the
hairiest
ones
where
it's
like,
there
are
seven
open
questions,
I've
created,
like
a
comment
thread
just
to
track
the
closure
of
the
other
thread,
I'm,
really
looking
forward
to
the
feature
where
we
can
mark
a
thread
as
resolved
in
issues.
That
would
be
just
a
killer
feature.
You
know
we
could
probably
have
a
pattern,
though,
where
we
react
with
the
checkmark
emoji
on
threads
right
on
the
initial
thread
kind
of
like
we
do.
B
So
a
really
good
question
here
so
related
to
refinement
responsibility.
So
whenever
we
created
create
create
an
issue,
and
so
when
should
we
split
the
issue
into
multiple
smaller
issues
like
it
should
may
be
very
big?
Maybe
it
has
a
starting
point:
wait
yeah!
It
may
consist
of
lot
of
things
to
change.
So
should
we
put
everything
in
the
same
issue,
because
the
benefit
of
that
is
that
we
can
track
the
issue.
We
don't
need
to
jump
into
other
issues
for
history
or
the
changes
to
be
making.
B
C
But
I
think
generally
the
smaller
the
better
but
like
we're,
gonna
use
a
term
that
I
haven't
heard
here
yet,
but
keeping
it
as
a
vertical
feature
slice
right
like
so
what
I
mean
by
that
is
generally.
We
want
to
organize
our
work
in
such
a
way
that
it
delivers
a
value
all
the
way
through.
It's
not
going
to
be
hey,
do
the
database
migrations
and
then
do
like
this
code
and
then
do
this
and
like
split
things
horizontally.
C
So
I
think
it
depends
upon
how
big
it
is
and
how
soon
it
is
to
actually
working
on
right.
There's
that
idea
of
adaptive
planning
and
as
some
things
further
out
in
the
future.
You
know
it
doesn't
make
a
lot
of
sense
to
split
it
up,
really
small,
but
then,
as
you
get
closer
to
the
time
where
it
works
on
it,
making
it
more
actionable
and
smaller
also
makes
sense
to
me.
C
B
So
that
may
be
something
like
this
issue
means.
One
issue
means
one
feature
that
if
you
may
contain
multiple
Amar's,
but
all
on
all
the
Amar's
are
related
to
that
particular
feature
implementation.
So
yeah
we
yeah.
We
can
practice
that,
like
I,
think
you
know
we,
we
have
already
practiced
that
so
everything
related
to
the
feature,
starting
from
documentation
on
code
chains,
maybe
database
migration
writing
other
scripts.
Everything
should
be
related
to
on
the
one
issue
and
we
can
create
multiple
immerse
right.
That
is
how
yeah.
C
I
think
the
only
nuance
comes
in
to
how
much
of
a
feature
you
do
right
because
a
lot
of
times
there
is
multiple
things
that
can
be
done
and
sometimes,
when
you're
getting
when
you
there's
a
balance
there
to
be
struck
to
with
like
how
long
you
work
on
something
versus
getting
feedback
and
iterating.
So
sometimes
you
can
realize
oh
what
we
could
do.
We
could
go
half
away
to
this
full
feature.
Get
feedback,
get
meaningful
insight
into
it,
and
it's
still
useful.
C
You
know,
and
sometimes
we
can
slice
things
in
that
way
and
say
well,
we'll
do
this
second
part
of
it
in
another
issue
and
that
doesn't
actually
degrade
the
value
that
it
actually
does
I'm
trying
to
think
of
a
good
concrete
example.
But
what
do
you
think
of
that
like,
for
example,
like
the
script,
I
think,
is
a
great
example,
like
maybe
a
script,
if
it's
hard
requirement
for
this
feature
to
be
useful
yeah
than
that?
C
That
probably
needs
to
be
a
part
of
that
issue,
but
if
that
just
makes
things
easier
and
there's
a
workaround,
maybe
you
ship
first
and
then
have
a
follow-on
issue
to
make
it
easier
in
the
future.
If
it's
proving
useful
and
people
are
using
the
feature,
I
think
sometimes
you
can
split
split
things,
but
certain
things
like
documentation
and
tests.
They
should
always
kind
of
be
included
a
thought
like
well,
you
know
if
this
thing
requires
that
looks
like
Thomas.
You
have
some
thoughts.
I
have
opinions,
oh
okay,.
A
Voicing
them
at
the
expense
of
possibly
squashing
conversation
and
I
love
the
conversation.
My
opinion
is
that
if
we
are
splitting
an
issue,
we
are
naturally
talking
about
affecting
the
scope
of
what
we
are
delivering.
If
you
think
that
you
need
to
split
an
issue,
that
is
a
clear
signal
to
start
talking
with
Taylor
I,
don't
think
you're
good
you
will
have.
It
will
I
predict
that
you
will
have
a
willing
participant
in
that
conversation,
but
as
far
as
too
entertaining
that
what
the
conversation
my.
A
My
recommendation
is
that,
if
your
intuition
is
saying
is
telling
you
that
you've
got
more
than
a
week's
worth
of
heads-down
work,
let's
start
talking
about
splitting
the
issue
apart.
The
reason
why
I'm
suggesting
that
is
that
our
cycle
time
for
going
through
them
our
process,
particularly
as
we
get
into
rails,
is
long.
That's
another
week's
worth
of
work.
On
top
of
that,
secondarily
you're
going
to
be
the
longer
that
this
goes.
A
The
more
change
is
going
to
be
that
you're
going
to
be
exposed
to
for
tuned,
because,
whether
it's
mr
reviews
or
community
contributions
or
other
issues
for
consideration-
or
it
just
exposes
your
surface
area.
So
if
we
think
that
if
you
think
that
you're
gonna
do
that,
it's
going
to
it
you're
gonna
be
heads
down
on
issue
for
longer
than
a
week.
Let's
start
talking
about
splitting
it
up
would
be
my
recommendation.
A
A
A
B
A
Scope
of
who
approves
those
changes
are
the
folks
that
are
in
this
call.
We
have
control
over
how
we
operate
as
an
override
as
to
how
the
stage
is
choosing
to
off
braid,
which
is
an
override
as
to
how
the
company
is
choosing
to
operate.
I
would
very
much
appreciate
someone
putting
forward
an
mr2
document.
This
conversation
there.
A
A
C
A
A
racist
that
got
because
it
sounded
so
my
eye
so
I'll
be
I'll,
be
blunt,
where
I
think
the
where
I
think
the
line
of
demarcation
is
as
far
as
what's
safe
for
us
to
do
internally
versus
what
is
not
safe
each
like
our
current
delivery.
Workflow
is
based
off
of
these
workflow
labels.
They
have
meaning,
if
we're
suggesting
we're
changing
the
meaning
of
what
those
labels
say.
As
far
as
what
work
we're
doing
within
them.
We
need
to
have
a
broader
conversation,
how
we
realize
the
work
within
those
states
that
we
have
control
over.
A
A
Basically,
you
get
three
response.
You
have
three
priorities:
number
one
community
contributions,
those
mrs
and
those
issues
triage
and
help
move
them
forward
and
hopefully,
either
to
to
some
form
of
closure.
Whether
that
is
acceptance
or
we're
not
going
to
accept
this,
because
we
need
to
go
this
other
direction
from
this
other
issue.
A
A
What's
in
our
backlog
is
just
that's
just
you
compelling
you
to
go,
try
to
figure
out
and
solve
you
you,
you
pick
what
you
work
on
and
the
idea
of
being
is
that
this
responsibility
for
a
community
manager,
you
do
it
for
an
iteration
and
then
we'll
rotate
it
to
the
next
person
to
the
next
person
to
the
next
person.
This
is
if
this
is
deemed
to
be
an
experiment.
That
is
something
we
want
to
continue
forward,
but
it
provides
you
with
the
slack
time
to
go,
be
experimental.
F
A
C
A
A
A
C
A
E
F
E
A
Go
for
yeah!
That's
what
it's
trying
to
go
for
it!
That's
why
this
way
you
see,
we
have
SL
A's
for
p1
p2,
p3
p4
in
the
30
60
90
120
days
now.
Actually
I
think
p4
is
a
hoping
that
they've
taken
the
SLA
off
because
we
typically
put
them
in
the
backlog
deal
with
them
until
they
reported
the
second
or
third
time.
A
But
it's
to
me,
P
ones
are
intrusive
and
they're
hard,
especially
in
a
push
based
workflow
cuz,
I'm
fill-in,
your
plates
and
I
got
to
figure
out
what
we're
gonna
take
off.
So
this
reserves
capacity
to
deal
with
them
because
we
don't
know
when
they're
going
to
arrive
or
how
or.
C
Yeah
I
wonder
what
the
Kanban
or
you
know,
automotive,
like
workflow,
pull
like
oh,
like
what
is
that?
What
is
a
p1
bug
in
that?
Is
that,
like
this
sorry,
that's
way
off
in
the
weeds?
But
is
this
an
interesting
thought
because
it's
not
so
much
I'm
ready
for
capacity?
It's!
You
must
deal
with
this
now.
You
know
it's
interesting.
You.
A
A
D
D
I
will
update
the
release
post
to
mention
a
future
deprecation
about
this,
but
I
think
will
be
good
from
where
I
see
this.
At
this
point,
okay,
big
thing
happening
this
week
next
week,
are
the
transitioning
of
these
Auto
DevOps,
insecure
CI
templates.
Auto
DevOps
is
currently
scheduled
for
three
four
five.
Thirteen
you'll
see
that
release
tasks
there.
We
have
our
own
release
task
but
of
course,
Lucas
is
out
this
week.
Those
two
things
need
to
shift
together.
This
is
probably
my
biggest
focus
is
to
make
sure
this
goes
right.
D
Okay,
I
will
chat
with
Thomas
about
that
offline.
Also.
If
you
saw
lots
of
notifications
over
the
weekend,
there
was
a
lot
of
stuff
moving
around.
We
now
have
epics
attached
to
SAS
secrets
and
malware
for
all
of
our
maturity.
Statuses
sassed
is
the
one
that
I'd
encourage
you
to
spend
the
most
time.
Looking
at,
don't
panic,
there
is
a
lot
of
scope
in
all
of
these,
and
in
fact,
a
lot
of
them
are
still
blank
as
well.
D
Basically,
I
tried
to
take
a
pass
through
our
entire
backlog,
all
of
our
planning
boards
and
tried
to
associate
anything
that
we
have
today
with
our
upcoming
future
milestones.
I'll,
then
be
building
out
all
of
the
issues
related
to
the
net
new
functionality
so
know
that
that's
there
feel
free
to
take
a
look
at
those
also
I'm
going
to
work
on
an
update
to
the
Direction
page.
D
They
sort
of
encompasses
all
of
the
stuff
that's
in
there
and
all
of
the
things
that
we've
been
talking
about
and
breaking
down
for
the
to
complete.
So
now
that's
coming
and
it'll
be
a
place
for
us
that
we
can
point
community
contributors
to
if
they're
doing
things
that
don't
align
with
the
direction
that
we
want
to
go.
So
there's
that.
A
All
right,
I'll
go
to
number
10,
which
I
think
is
the
last
one
that
we've
got
for
time
for
okay,
relative
sizing
for
bugs
good
idea
or
rank
smell
of
process
overhead
and
yes,
I,
wrote
that
let's
feel
it
punchy
when
it
did
so.
This
is
an
honest
question.
I'd
very
much
appreciate
the
discussion.
I
will
go
ahead
and
state
what
my
opinion
is.
If
it's
something
we're
scheduling
in
a
future
release,
we
should
know
its
size
or
have
an
opinion
of
its
size.
C
B
C
Opinion
is
no,
but
that's
me
and
my
path,
because
I
I
think
there
are
a
number
of
things
one
by
the
time
you
figure
out
what
the
weight
should
be.
You've
had
you've
solved
it
generally,
so
that's
number
one
and
like
so
then
it
really
just
puts
a
bunch
of
the
weight
and
the
responsibility
in
the
refinement
process.
C
The
second
thing
just
that
bug,
should
have
a
cost,
and
so
necessarily
your
velocity,
etc,
and
all
that
will
dip
if
you're
or
volatility.
If
you
have
dealing
with
a
lot
of
bugs
and
that
then
puts
a
lot
of
weight
on,
let's
not
ship
bugs
but
I
think
the
hardest
part.
Is
it
they're
really
hard?
A
bugs
are
generally
are
really
hard
to
to
do
that.
So
it
would
add
a
lot
of
overhead
and
yeah.
That's
that's
my
opinion.
Okay,.
A
C
Let
me
ask
you:
this
I
mean
the
that
philosophy
that
I
was
basically
espousing
to
also
puts
bugs
above
features.
So
if
you
have
bugs
you
should
work
them.
First,
that's
not
always
possible,
so
I
wonder
if
having
some
form
of
a
bug
budget
or
something
along
those
lines
could
help
with
planning
of
like
we
will.
If
we,
you
know,
always
slate
so
many.
You
know
in
terms
of
that
I
don't
know
I
guess
you're
talking
about
relative
sizing,
but
it's
just
really
weak.
In
terms
of
estimation,
okay,
I'm.
E
Alternate
could
be
to
just
put
a
oh
wait,
five
or
whatever,
on
every
bug
across
the
board
and
then
retrofit
a
wait
once
we
work
on
it
or
something
like
that,
because
because
I
agree
with
Daniel,
like
fixing
a
bug
like
figuring
out,
what
the
problem
is
is
most
of
the
bug
work
and
you
need
to
do
that
to
know
how
much
work
it
is,
and
it's
cart
and
horse
problem.
Okay,.
A
C
A
C
E
A
I
mean
I
mean
the
thing
is
about
it.
So
when
we
look
at
bug
so
we've
got
p1
p2,
p3
p4.
Those
are
those
are
worthy,
SLA
czar
against
so
p1
they're
going
to
interrupt
the
current
release,
and
so
the
s
always
for
those
others
are
calling
for
we're.
Gonna
schedule
it
for
the
next
release
or
two
releases
out
or
three
releases
out
as
far
as
when
we
need
to
have
it
realized
that
calls
for
how
big
is
it
that
calls
for
a
little
bit
of
a
triage
work
in
advance?
A
So
that's
that's
where,
but
that's
that's
the
logical
connection
that
I
made
I
am
NOT
one
to
hold
strongly
to
that.
I
just
need
to
make
sure
I
know
how
to
I
know
how
I
like
hate
capacity
for
bugs,
which
means
that
I
need
to
do
some
more
investigation
on
what's
their
discovery
rate,
which
I
don't
have
internalized.