►
From YouTube: CHAOSS.Common.Oct.29.2020
Description
CHAOSS.Common.Oct.29.2020
Minutes: https://docs.google.com/document/d/1xsii5tfmmDwWpuhrFcBJMeYeT3RipJdiCdHrbi0NalQ/edit#heading=h.n3rh3l1y6dv7
A
A
B
A
B
B
D
B
B
A
B
B
E
B
B
B
D
B
C
B
A
F
A
A
You
know
repeated
bullet
points
or
things
that
maybe
were
in
the
description
that
should
be
in
the
objectives.
You
know
what
I
mean
just
trying
to
create
a
more
cohesive
narrative
around
things.
So,
honestly,
the
question
I
had
to
rephrase-
I
don't
know
if
I
love
the
question
it
was
written
as
a
yes,
no
question
originally,
which
I
don't
think
is
what
we
want.
B
A
A
D
Yeah,
so
is
it
how
or
why,
like
reading,
the
description
feels
like
more
of
a
why
we
have
a
burst
in
it
because
of
the
release
cycle
because
of
the
global
pandemic
because
of
the
hackathon,
rather
than
how?
How
is
more,
on
the
like
procedural
way
that
how
this
happens,
but
the
answer
or
like
the
outcome,
I'm
observing
is
more
of
a.
Why.
A
B
I
was
just
gonna
say
I
feel
like
the
metric
is
a
is
a
how
metric
and
you
have
examples
which
are
sort
of
the
the
why,
but
I
feel
like
I'm
not
sure
throughout
the
the
document,
whether
we
focused
on
the
how
or
not,
but
it
seems
like
the
metric,
the
metrics
should
be
the
how
those
are
observed,
as
opposed
to
and
then
so.
The
metric
is
how
those
are
how
those
are
observed,
but
I
think
the
interpretation
that
one
would
make
after
you
gather
this
data
is
kind
of
the.
Why
does
that
make
sense?.
D
A
A
G
Well,
I
think
what
don
was
saying
is
that
we
are
just
observing
we're
not
really
trying
to
understand
them.
I
think
right
is
that
right,
because
it
feels
like
in
other
metrics
we
just
identify
like
we
identify,
increases
or
decreases
in
activity
or
diverse
people.
Groups.
Leadership
like
you
know
things
like
that,
but
we
don't
really
go
into
like.
Why
is
that
happening?
You
kind
of
leave.
B
A
A
Sort
it
out:
okay,
cool
yeah,
one
of
the
things
that
I
did.
If
you
see
that
okay,
so
in
description,
the
text
leading
into
those
bullet
points
as
examples
of
root
causes
are
these
things
and
then
the
first
bullet
point
in
objectives
is
tying
back
to
those
root
causes.
So
I
don't
know
if
that's
clear,
we
had
some
repetition
in
the
objectives,
and
so
I
just
rolled
all
that
repetition
into
this
phrase:
root
causes.
G
E
A
D
A
B
A
F
F
B
E
F
C
B
A
A
F
B
F
F
A
G
G
A
A
A
D
G
A
F
B
E
Well,
any
of
the
three
because
the
three
of
them
are
kind
of
interrelated,
so
the
first
one
time
between
iterations
the
time
between
each
of
the
cycles
that
we
may
have
in
a
code
review
process
and
then
the
other
two
are
kind
of
splitted
within
each
of
those
times
into
two
more,
which
are
the
time
waiting
for
a
reviewer
action,
which
is
when
someone
submits
something
and
the
time
waiting
for
a
submitter
action,
which
is
when
there
is
a,
for
instance.
Problem
with
the
testing
or
or
the
reviewer
is
requiring
improvements.
C
E
B
B
B
B
B
Yeah,
because
I
see
so
I
see
matt,
I
see
you
correcting
iterations
to
to
review
cycles.
The
way
I
was
interpreting
this
and
daniel
you
can
tell
me
if
I'm
right
or
not
is
that,
like
the
the
review
cycle,
is
sort
of
the
whole
thing,
but
what
you're
measuring
is
the
maybe
the
I
don't
know.
Maybe
daniel.
Can
you
talk
more
about
that?
Maybe
now
I've
confused
myself.
E
A
F
Well,
for
me,
the
review
cycle
is
when
it's:
when
you
ask
for
changes,
so
the
pull
request
can
be
issued,
it
can
be
reviewed
and
it
can
either
be
approved
or
the
person
reviewing
it
can
ask
for
changes,
and
that
would
constitute
a
milestone.
Starting
another
review
cycle
is
that
what
you're
thinking
of
daniel.
E
F
E
Okay,
so
the
the
vocabulary
I
was
using
is
code.
Review
process
is
the
whole
chain
set,
for
instance,
in
in
in
gary
or
or
the
whole
pull
request,
discussions
that
we
may
have
in
github.
Each
of
the
iterations
are
when
we
have
someone
sending
a
piece
of
code,
for
instance
me
sending
this,
and
then
you
are
now
the
reviewers,
so
you
are
asking
for
improvements
so
now
I
need
to
to
take
action
here
and
send
a
new
version
of
this
document.
Right
kind
of
so
that's
a
new
review
cycle
or
iteration.
A
C
E
B
B
A
So
there's
a
review
cycle
right
and
that's
where
some
work
gets
done.
Is
that
correct,
and
so
is
it
about
understanding
the
time
of
review
cycles?
So,
for
example,
if
a
first
review
cycle
took
10
minutes
and
the
next
review
cycle
took
40
minutes
as
part
of
a
part
of
a
change
request
and
the
next
one
took
an
hour
and
the
next
one
took
two
hours
I'd
be
like
you
know,
each
of
my
review
cycles
seems
to
be
trending
towards
longer.
E
F
E
B
B
The
time
before
review,
because
so
there
are
two
ways
I
can
interpret
this
question.
One
is
what
are
the
time
between
review
cycles
for
a
particular
contribution,
so
I
submit
a
contribution.
I
get
some
feedback,
I
resubmit
it
or
you
could
look
at
this
as
the
time
between
review
cycles
period,
so
I
submit
something
it
gets
reviewed,
matt
submits
something
else
completely
different
and
it
gets
reviewed.
You
could
look
at
the
time
between
those
review
cycles,
but
I
don't
think
that's
what
you
mean.
You
mean
for
the
same
contribution
right.
D
B
E
A
E
E
The
there
on
the
left,
like
close
to
the
end,
it
says,
files
finding
and
then
it
says
patch
set
three,
so
a
chain
set
in
garrett
is
based
on
several
patches
and
patch
is
an
iteration
in
this
case.
So
if
you
go
down
you
scroll
down,
please
then
you
have
the
all
of
the
history
here,
so
the
review
cycle,
or
each
of
iterations
would
be
the
time
between
the
line
number
three
and
the
line
number
one
so
mark
in
903
minus
the
same
day
year,
8
55.
So
this
is
eight
minutes.