►
From YouTube: CHAOSS.Evolution.September.26.2019
Description
CHAOSS.Evolution.September.26.2019
C
B
A
B
D
E
C
C
So
I
guess
I
guess
what
I'm
saying
is
that
the
the
question
was
before
you
arrived
Matt
do
we
Kevin
was
saying
other
working
groups
have
one
metric
per
question
playing
out
of
it
and
I
was
remembering
that
risk
I
thought
we
didn't
and
we
don't
and
so
but
I
guess
the
other
work
groups
like
value
is
I
thought
value
had
multiple.
They
may
not
have
published
multiple
questions
or
multiple
metrics
per
question,
but
I
think
that
what's
his
name
and.
C
F
B
C
B
So
what
what
Carter
was
yeah
shut
up
now,
no
you're
good,
so
our
proposing
that
is,
you
know
so
like
we
have.
You
know
we
have
this
really
awesome
list
of
all
the
metrics
that
are
in
your
lab,
but
it
there
there's
a
lot
of
them,
which
is
great,
but
it
would
be
pretty
hard
to
go
through
I.
Think
each
of
each
one
of
them
individually
and
say
like
what
exactly
which
question
does
this
answer?
I
think
it
would
be
I
mean
we
could
do
it,
but
it
would
take
a
while.
B
So
what
might
be
more
effective
I
think
would
be
to
go
through
figure
out
what
focus
area
the
most
each
metric
lies
in
and
then
look
at
the
questions
that
are
already
in
that
focus
area
if
we
think
they
fit
under
one
of
these
questions.
You
know
if
we
think
we
the
metric
answers.
One
of
these
questions
we
can
sort
of.
We
can
put
that
as
the
as
the
question
here
and
if
it
doesn't,
then
we
can
make
a
new
one.
B
A
B
C
C
B
E
B
Okay,
so
will
not
do
you
want
it
for
at
least
once
so
like
issue
comments
mean
if
I
look
at
my
focus
areas,
code,
development,
community
growth
or
issue
resolution
issue
comments.
You
know
that,
could
that
could
go
under
like
how
efficient
is
it
doing,
which
is
undercut
development,
but
you
know
I
could
also
go
in
here
and
say.
Maybe
if
it's
more
under
issue
resolution,
I
did
not
mean
to
do
that.
Hang
on
I
actually
opened.
A
B
C
C
E
A
F
B
C
What
do
you
think
I
mean
I've?
Always
when
we
talk
about
goals,
questions
and
metrics
with
people?
It's
always
in
my
head
that
there's
multiple
metrics
that
are
likely
to
end
to
help
answer
a
question.
Those
oxygens
are
more
higher
level
than
they
than
they
are
represented
in
what
we
released
Mike.
When
we
talk
about
it,
maybe
I'm
thinking
about
it
wrong.
D
D
I
think
I
think
when
you're,
when
you're
defying
an
individual
metric,
the
question
should
focus
on
what
that
metric
does
I
think
it's
it's
okay
to
have
a
question
that
can
that
can
add
organization
to
multiple
metrics.
But
if,
but
if
we're,
focusing
on
the
definition
of
a
single
metric,
I
think
we
need
to
focus
on
the
definition
of
that
single
metric
without
including
other
metrics
that
may
be
in
that
same
category.
Mm-Hm
I
think
that
that
metric
categorization
is
maybe
another
step
which.
F
I
think
that's
right
and
then
the
way
that
we
think
about
multiple
metrics,
you
know
maybe
living
in
the
same
space-
is
that
kind
of
like
looking
at
what
you
have
on
the
screen
right
now.
These
metrics
answer
that
question
and
collectively
they
address
the
goal
right,
and
so
that's
where
you
get
the
multiple
metrics,
it's
aimed
at
the
goal,
not
at
the
question.
C
B
F
F
F
B
C
G
D
Yeah,
so
it's
so
it
is
in
here
as
well
right.
So
this
this
is
one
of
those
cases
where
metrics
can
exist
within
different
focus
areas,
because
they
they
can
answer
different
questions
based
on
the
the
contact
string
or
they
can
help
answer
different
questions.
So
this
is
going
to
be
more
and
more
common.
The
more
metrics
we
release
mm-hmm.
F
F
F
B
F
Should
so
I
should
theoretically
better
eyes,
but
I
should
use
your
computer
and
write
notes.
So
you
know
from
a
high
level,
if
you,
if
you're
in
document,
there
appears
to
be
one
focus
area
around
code
changes
one
focus
area
around
reviews
and
one
focus
area
around
the
issues
in
this
one.
It
sounds
almost
in
there
right
now
where
you
were
typing.
Oh
sorry,
go.
F
Those
are
the
focus
areas
like
what
is
the
goal
for
code
changes?
What
is
the
goal
for
reviews
and
what
is
the
goal
for
issues
and
those
names
might
change
a
little
bit.
Mm-Hmm
stronger
focus
area
than
you'd
like
then,
you
just
have
one
defined
goal
for
code
changes
whatever.
That
might
be
one
goal
for
reviews
and
one
goal
for
issues.
Mm-Hmm.
F
B
F
F
I
think
so
so
I
I
mean
I
think
it
can
be
about
defining
new
metrics
too,
but
I
think
there's
been
a
push
in
the
other
working
groups.
That
is
basically
saying:
hey.
Listen.
We
have
a
lot
of
these
things
already
deployed
right.
The
word
we're
doing
ourselves
a
bit
of
disservice.
If
we
don't
take
a
little
bit
of
time
and
define
those
things
that
are
deployed
right
right,
right.
C
D
C
F
D
Just
gonna
I
was
just
gonna,
make
a
comment
that
was
kind
of
related
to
yours
and
that's
that
there's
there's
years
of
research
behind
the
auger
metrics
that
have
been
deployed
and
we're
getting
to
years
of
research
behind
or
I'm.
Sorry,
the
the
grimore
lab
metrics
that
have
been
deployed
and
we're
getting
two
years
of
research
behind
the
auger
metrics.
So
it.
D
F
F
F
F
F
B
F
B
C
F
I
think
they
are
already
I
mean
I,
think
they're
already
yeah.
They
will
be
focus
areas
based
on
the
release
and
version
one
mm-hm
there's
a
lot
of
these
are
captured
and
scroll
down
a
little
bit
efficiency
quality
code,
review
testing
is
anybody
else,
seeing
any
focus
area
that
kind
of
jumps
out
at
them
that
isn't
one
that
would
be
defined
from
version
one
or
community.
B
Kevin
or
Georg
so
just
on
I
make
sure
I
following
so
we
would
have
the
changes.
The
code
changes,
issues,
reviews
contributors
and
maybe
that's
it
at
the
moment.
Yeah
I
think
those
would
be
I
think
those
four
would
be
a
pretty
comprehensive
set
for
for
next
release
and
just
to
start
focusing
I'm
differently
as
we
iterate
on
metrics
and
as
we
you
know,
whenever
we
get
to
to
this
this
list,
we
probably
would
be
able
to
come
up
with
a
couple
more
but
I
think
that
those
four
issues
so
changes,
reviews
issues
and.
B
F
C
F
For
us,
yeah
and
I
think
too
I
mean
part
of
if
I
think
about
the
working
groups.
So
if
I
think
of
laplace's
granny
of
them
I,
don't
think
the
goal
is
to
always
release
new
focus
areas.
I,
don't
yeah
we're
not
trying
to
achieve
like
four
focus
areas.
This
right,
yeah,
yeah,
honey,
I,
don't
think
that's
the
goal
ever
so
yeah,
even
just
having
four
is
kind
of
a
way
to
bound
things
at
that
highest
level.
That
might
be
sufficient.
Yeah.
E
D
H
A
D
It
would
be
nice
if
we
could
continue
to
work
on
the
focus
areas
and
metrics
that
have
already
been
released
as
well.
Mm-Hmm
see
from
from
gonna
come
into
some
of
these
meetings.
It
kind
of
seems
like
everyone's
really
ready
to
go
and
find
new
focus
areas
and
find
new
metrics
and
the
it
kind
of
feels
like
people
think
these
metrics
that
have
already
been
defined
and
published,
or
just
done.
Mm-Hmm.
B
You
know
especially
asking
me
to
release
them
in
deploy
them
and
we
get
feedback
on
them.
We
should
continue
to
iterate
them
interact
on
them,
I
agree.
So
maybe
that's
part
of
before
a
next
release.
We
make
a
specific
point
to
go
back
and
say:
well,
it
works
about
the
metrics
for
release,
one,
what
didn't
work
about
them
and
how
can
we
fix
those
is
that
kind
of
something
that
you
would
like.
Is
that
like
where
what
you
were
thinking.
A
B
Yeah
that
probably
wouldn't
take
me
started
be
long,
but
I
could
go
through
break
these
out
into
the
focus
areas
and
then
add
you
know,
update
this
page
accordingly
and
then
I
could
do
that
by
the
next
meeting
and
then
we
could
review
those
learning
point
or
we
could
sit
here
or
we.
It
might
be
helpful
to
write
the
goal
for
each
of
these
focus
areas
now
without
thinking
about
specific
metrics,
what
that
might
color
the
view
of
the
Gulf.
That
makes
sense.
Let's
do
that,
okay.
B
F
D
H
F
D
F
C
D
F
B
Broad
yeah
cuz,
then
I
think
the
other
question
would
be
so
activities
something
like
you
know
under
activity.
We
have
issues
so
with
these
go
under
the
activity
like
would
we
get
rid
of
the
four
that
we
we
just
talked
about
the
code
development
reviews
issues,
contributors
and
then
have
activity,
efficiency
and
quality
be
the
three
focus
groups
and
then
that's
where
we
put
these
metrics
or
should
we
or
is
it
more
pertinent
to
have
the
focus
group?
A
Where
Kevin
is
coming
from,
because
when
we
write
a
focus
area,
we
always
have
a
goal
and
because
we
have
a
goal
activity
and
when
you
go
up
at
the
top,
it
actually
there's
a
description
of
the
goal.
So
I
can
see
how
that
looks
and
feels
like
a
focus
area,
and
maybe
the
name
is
code,
development,
activity
or
activity
in
code
development,
and
that
is
a
focus
area
and
we
don't
even
have
to
change.
The
structure
would
be
just
instead
of
a
focus
area,
code
development.
A
F
A
C
C
A
C
I
think
whether
or
not
a
repository
performs
code
reviews
like
so
our
repositories,
for
example,
we
conditionally
accept
changes
to
people
have
to
review
any
proposed
change.
I
think
that's
a
different
thing
than
a
pull
request,
review
mmm-hmm,
all
I'm
saying,
although
I
guess,
if
you
think
about
it,
no,
it's
not
because
we're
requiring
it
on
the
press
right.
B
F
C
F
F
F
B
Would
argue
that
we
do
we
do
okay,
so
my
thinking
is,
if
I'm
concerned
about
the
evolution
of
a
working
group
or
ever
work
on
straight
right
and,
let's
say
I'm
just
like
I,
want
to
know
like
from
activity
standpoint.
Is
it
active
what's
happening
all
right?
Is
there
a
lot
of
things
happening,
but
it's
a
different
if
it's
a
different
story,
if
I
see
a
lot
of
things
happening,
but
maybe
the
things
that
are
happening
are
not
very
efficient.
B
They're
doing
a
lot
and
then
also
the
things
they're
doing
are
being
effective.
If
that
makes
sense
and
then
I
guess,
to
follow
through
the
same
train
of
thought.
Not
only
are
they
efficient,
like
maybe
they're
I
want
to
know?
Not
only
are
they
efficient,
but
what
is
they're
doing
actually
of
good
quality?
Maybe
it's
efficient,
because
they're
going
fast
and
being
sloppy,
but
wouldn't
this.
B
To
me
that
the
more
I
think
about
it,
the
more
I
more
agree
with
Kevin
that
having
that
activity,
efficiency,
quality
being
the
focus
areas
of
almost
kind
of
maybe
building
on
one
another
but
like
I,
think
viewing
them
all
together
viewing
a
metric
in
the
context
of
them.
That's
not
the
right
term.
I
want
to
use.
Ok,
sorry,
I'll
focus
area,
I
assume,
has
multiple
goals.
Typically
right,
no.
C
F
D
B
I
think
we
can
compose
how
you
would
use
these
different
goals
or
how
you
would
view
the
different
goals
and
focus
areas
at
a
higher
level
to
make
some
of
those
larger
questions
more
apparent
like
maybe
across,
and
we
don't
define
them
the
the
broad
questions
within
Funky's
areas,
but
sort
of
out
side
of
them.
If
that
makes
sense,
so
they.
C
F
The
moment
we
have
three
focus
areas
that
we're
proposing
code
development
activity,
irrespective
of
how
there
were
there
originating
from
or
anything
like
that,
code,
development,
activity,
code,
development,
efficiency
and
code,
development,
quality,
there's,
okay,
so,
and
we
have
this
contributor
down
there
as
well,
that
has
kind
of
it.
We
don't
have
to
address
that.
One
I,
don't
think
it's
so
with
respect
to
code
development
activity.
C
C
I
think
I
think
the
current
definition
as
it
stands
is
encompasses
the
things
that
we've
broken
it
out
into
separate
focus
areas.
So
we
probably
need
to
change
the
description
of
the
goal,
so
maybe
because
efficiency
like
the
efficiency,
also
talks
about
adding
and
removing
code
from
a
code
base.
So
this
is
really
about
measuring
the
volume
of
changes.
B
F
A
B
C
Think
actually,
I
think
that
what
what
do
you
mean
by
type
so
there's
you
can
there's
adding
lines
removing
lines.
Essentially,
some
code
evolves
where
you're
just
changing
existing
programs
or
adapting
them
and
refactoring
them.
But
the
fundamentals:
don't
change.
So
it's
a
slow
evolving
project,
there's
not
a
lot
of
new
code
files
being
added
we're
just
editing
existing
ones
when
a
project
is
being
created
or
evolving
quickly.
You'll
often
see
more
new
files
created
more
lines.
C
C
B
B
F
C
B
Better,
do
we
want
to
keep
it
at
how
officially
new
code
is
merged
into
the
code
base,
because
I
might
have
a
question
about
like
how
efficient
are
my
internal
developers
that
are
just
pushing
code
to
a
branch
regularly?
Not
necessarily
you
know
is
that
or
is
that
code
being
merged
age
of
the
company's
gonna
meet.
A
A
C
B
C
C
F
F
H
H
That
could
be
considered
saying
that
way
to
attend
useful
work
and
energy.
I
seen
it
as
the
useful
work
would
be
the
cold
melt.
I
mean
Dakota's
active
on
the
code
is
added
to
the
base
code
between
all
the
ratio,
with
the
amount
of
pull
requests
or
issues
or
whatever
they
are
open
it,
for
example.
So
basically,
the
energy
discussing
that
and
get
accepted
is
not
efficient,
so
I
mean
projects
that
are
not
active
at
all.
H
F
Currently
accommodate
that,
because
I
think
it's
that
last
part
to
get
resolved
part
indicates
that
there's
some
closure
too
the
activity
I'm.
Guessing
that,
sir,
you
were
writing
gay
work
when
you
wrote
that
that
there's
some
activity,
whether
it's
an
issue
or
a
pull
request
and
there's
some
resolution
of
that,
whether
it's
clothes
without
merging,
whether
it's
merged,
whether
it's
clothes
without
comment,
there
is
a
resolution.
How.
F
A
F
C
I
think
actually,
some
of
the
test
coverage
metrics,
that
the
risk
working
group
defined
could
be
cross
listed
with
evolution,
but
Kevin
alluded
to
earlier
is
a
likely
way
that
the
project
is
going
to.
Overall,
my
I
don't
know
that
there
needs
to
be
a
distinction
between
co-development
quality
by
working
group.
That
seems,
if
we're
going
to
go
to
a
matrix
kind
of
set
of
metrics
that
feels
a
bit
artificial
mm-hmm,
because
it
would
include
Bank
test
coverage
is
perfectly
valid,
as
an
evolution
metric
to
like
I
would
want
to
say
to
all
of
notice.
C
F
C
Mean
prata
mean
when
I'm
gonna
teach
software
hearing
quality
is
measured
in
two
ways:
one
is
the
quality
of
the
process
of
development
right.
So
if
you
have
a
good
process
that
tends
to
lead
to
good
code-
and
you
know
these
things
and
the
other
is
static
measures
of
code
quality.
Okay,
that's
of
coverage,
things
like
that.
So
if
you
want
to
cover
quality
as
a
whole,
you
take
the
word
process
out.
Okay
and
if
you
want
to
distinguish
between
tests
and
things
like
test
coverage,
sort
of
static
code
enough
and
it's
awful
process,
then.
F
B
B
F
F
No,
no,
no,
but
the
point
being
that,
if
we're
trying
to
measure
the
quality
of
a
process
in
open-source,
what
are
the
things
that
we
can
like
hold
on
to
like?
How
do
we?
How
do
we
know
that
it's
of
good
quality
is
that
what
you're
asking
whether
the
process
is
good
quality,
so
I
think
the
Eric's
point
with
code
quality
versus
code
process,
quality
is
code,
quality
incorrectly
room,
wrong,
Georg,
but
code
quality
is
about
the
code
base
itself
and
code
process.
A
F
F
F
H
H
I
was
just
curious,
are
the
how
this
is
has
been
written
and
I
am
lying
with
your
mindset
mad
about
this?
This
is
more
about
measuring
the
quality
of
the
precision.
Basically,
is
the
process
design
to
accomplish
what
his
one
has
been
designed
for?
Basically,
we
are,
you
know,
code
development.
Is
its
code
base,
develop
it
I,
don't
mind
about
the
quality
of
the
code
itself.
I
am
and
curious
are
okay.