►
From YouTube: CHAOSS.GMD.March.6.2019
Description
CHAOSS.GMD.March.6.2019
A
A
A
A
Then
we
have
the
questions
and
metrics,
which
is
still
working
progress,
because
maybe
we
can
define
some
more
personal
metrics,
but
this
are.
This
is
the
current
proposal,
let's
say,
and
you
can
see
how
we
have
four
gold
activity.
Three
questions,
the
first
one
is
how
many
changes
happening
in
the
source
code,
the
second
one
it
will
with
respect
to
proposals
and
remember
that
proposals
is
the
name
that
we
are
using
for
code
abuse
or,
let's
say
change
it
subject
to
code
review,
then
how
many
proposals
for
changes
to
the
source
code
are
happening?
A
So
that's
what's
the
question
and
for
issues.
The
question
is
how
many
issues
are
happening
during
a
certain
time
period
and
then
for
each
of
these
questions
there
are
some
metrics
that
tried
to
quantify
them.
Remember
that
the
goal
question
metric.
The
idea
is
to
define
the
goal
then
to
define
some
questions
that
should
help
to
reach
that
goal,
which
usually
is
an
olive
oil
and
then
some
metrics
they
have
should
help
to
answer
the
question
so
for
four
changes.
A
Finally,
we
came
to
only
two
metrics
for
now,
which
is
the
row
number
of
code
changes
which
is
basically
the
row
number
of
needs
and
then
can
change
lines
the
number
of
lines
in
all
the
commits.
So
we
have
another
measure
of
the
volume
of
activity
so
for
proposals
and
for
issues
both
are
quite
similar
in
the
case
of
proposal
is
the
row
number
of
proposals
that
is
called
review
and
the
number
of
proposals
accepted
and
the
number
of
the
process
decline.
A
Obviously,
you
can
also
compare
acceptable
to
decline
and
proposals
to
accepted
and
whatever,
but
for
now
we
are
only
providing
the
three
basic
metrics
and
from
looking
at
the
three
of
them,
you
should
be
having
a
more
complete
view
of
the
code
review
activity
then
for
issues
it's
basically
the
same
thing,
but
instead
of
accepted
and
decline,
we
are
using
active
and
closed
active
means,
it's
open
doing
the
certain
real
and
closed.
All
it's
closed,
then,
for
call
efficiency.
We
are
setting
on
the
two
questions.
A
Sorry
yeah
question
one
is
related
to
proportional
and
the
other
one
is
two
issues.
The
first
one
is
basically
how
efficient
is
the
code
review
process
and
the
second
one
is
basically
in
how
efficient
is
the
plate
dealing
with
issues,
and
then
we
have
quite
similar
matrix
for
both
of
them.
If
you
look
at
them,
so
the
first
one
is
the
basic
and
iteration
matrix.
So
how
long
are
the
staff
open,
it'll,
pull
request,
all
four
issues
at
a
code
review
or
issue?
A
The
second
one
is
participants,
which
is
something
Bob
cases
for
how
many
people
are
participating.
The
idea
here
is
that
the
more
people
that
are
participating,
the
let's
say,
less
efficient
processes,
maybe
that's
good
for
the
reasons,
because
you
have
more
eyes
on
on
the
back,
for
instance,
or
more
eyes
on
a
code
review,
but
from
the
point
of
view
of
the
peer
of
efficiency.
A
The
rest
of
those
are
the
two
ways
to
the
port
in
the
sense
that
it
doesn't
lead
to
changes
and
the
proportion
acceptance,
radio,
which
is
basically
again
this.
How
efficient
is
the
pure
good
structure
which
fraction
of
proposals
are
finally
asset
and
for
quality
we
don't
have.
We
only
have
the
questions
we
didn't
work
in
the
matrix.
Yet
so
that's
probably
the
next
target
and
we
have
for
now.
We
have
quality
code
review
on
providing
testing
there's.
Something
here
is
that
we
are
dealing
with
processes
not
with
the
panel
result
and
the
bailer.
A
The
code
review
is
probably
the
other
product
is
and
the
better.
The
question
is
for
a
little
better
than
the
product
list,
and
and
that's
it
with
respect
to
this
file.
So
a
green
on
this
means
for
now
that
we
are
going
to
release
this
as
the
structure
of
the
focus
area
with
some
metrics
that
are
already
implemented,
that
we
are
going
to
talk
about
them
now,
where
they
didn't.
A
The
following
work
would
be
to
go
on
with
the
rest
of
the
matrix,
basically
mapping
them
to
the
matrix
that
we
have
in
legacies
or
those
that
were
already
defined,
but
maybe
we
need
to
change
the
name
or
to
redefine
or
something
later
and
some
of
the
metrics
on
you,
so
that
we
need
to
work
with
them.
Yeah.
B
I
think
it's
I
think
and
there's
another
pull
request
that
you
made
around
around
some
of
these
as
well.
I
think
so
there
are
like
I'm.
Actually,
candidly
I
was
confused
this
morning,
when
I
was
trying
to
go
through
and
figure
out,
okay,
which
ones
need
to
be
flushed
out
yet
and
I
didn't
notice
that
we
have
code
changes
that
we
did
that
a
month
ago,
but
there's
still
code
commits
in
their
code
commits
is
what
I
believe
we
merged
with
the
metrics
repository
so
there's
another
need
to.
B
We
have
to
align
those
two
with
each
other
and
I
actually
made
a
commit.
One
of
my
commits
this
morning
was
updating
code
commits,
but
now
that's
code,
changes
and,
and
so
I
think
it
is
keeping
keeping
like
aligned
with
okay.
These
are
the
metrics
that
we're
building
and
here's
their
files
and
their
names,
and
when
we
I'm
okay,
changing
the
names
because
I
like
that,
like
code
changes,
it's
clearer
than
well,
it's
more
abstract
than
code
commits,
but
I
assume
there's
a
reason
that
we're
using
changes
instead
of
commits
like
that.
A
B
No
and
I
I
don't
care
if
the
names
are
either.
But
if
we've
a
my
only
point,
I
think
in
one
of
the
comments
I
made
this
morning
on
the
pull
request.
A
different
poll
requests
that
we'll
probably
discuss
is
that
we
make
sure
that
if
we
do
get
rid
of
Burma,
if
we
change
a
name
that
we
create
some
sort
of
way
that
that
becomes
transparent.
B
So
if
people
have
been
starting
to
conceive
aligned
our
list
of
metrics
in
the
markdown
files
with
what's
now
in
in
the
metrics
repository,
which
is
the
one
I
look
at,
that
is
a
one-stop
shop
for
people
coming
to
chaos
to
consume
metrics.
And
if
we
change
the
name
here,
okay,
but
then
I
think
we
have
to
change.
They
get
to
do
two
things.
And
you
put
this
up
for
discussion.
B
We
have
to
change
the
name
back
in
the
metrics
repo
and
we
have
to
give
people
some
kind
of
list
of
the
names
that
we've
changed
and
what's
been
changed
to
what
over
time,
so
that
we
don't
have
people
who
start
to
try
to
consume
the
metrics.
And
then
we
change
the
name.
But
it's
the
same
thing:
okay,.
C
B
Constraints
not
from
the
metrics
repository
as
an
entity
unto
itself.
The
constraint
is
from
somebody
coming
to
chaos
to
consume
the
metrics
I
think
if
we've
named
metrics
have
a
certain
obligation
to
stick
with
a
name,
because
if
someone
started
to
consume
it
and
we
change
the
name,
then
they're
confused
well.
A
My
assumption
was
that
all
the
metrics
up
to
now
earliest,
in
the
sense
that
they
weren't
about
this
caste,
was
a
whole
in
a
detailed
way,
so
they're
the
first
metrics
that
we
are
really
releasing
are
those
that
will
release
next
week.
Better
still
I
understand
what
you
mean,
because,
even
when
they
are
not
the
tail
visual
many
people
may
be
consuming
metrics
from
nowadays,
so
anything
that
we
can
do
to
try
fighting
this
and
everything.
That's
a
good
thing.
Yeah.
C
So
the
keeping
it
aligned
with
the
metrics
repository
is
is
not
gonna,
be
a
problem,
so
all
I
would
ask,
is,
if
you
so
I
think,
there's
two
points
here.
So
all
I
would
ask
is,
if
you
change
the
name
and
the
working
group
just
post
an
issue
with
the
metrics
repository,
but
there's
been
a
name
change.
I
can
keep
those
things
aligned
SuperDuper
easily
and
then,
in
terms
of
of
consuming
kind
of,
you
should
post
an
issue
in
the
height.
C
And
I
can
change
it
in
that
table.
Really
no
problem
at
all,
so
that'll
allow
you
to
change
the
names
as
you
see
fit,
so
that
was
what
I
was
talking
about
the
constraint
from
there's
no
constraint
from
the
metrics
repository.
We
will
respond
to
the
working
groups
and
then,
but
only
tell
you
what
it
responds
you
correct.
If
you
don't
tell
me,
I
won't
make
any
changes
and
then
I'll
blame
you.
C
If
there's
a
disconnect
between
the
two
so
and
then
the
other
issue
is
that
if
the
name
changes
over
time
and
people
maybe
have
been
using
an
older
name
and
now
the
name
is
changed
to
kind
of
reflect.
The
more
current
state
of
affairs,
I
don't
have
a
problem
with
that.
I
mean
I,
think
this
gets
into
the
versioning
question
that
has
been
cycling
around
for
a
long
long
time.
C
I
sincerely
believe
that,
if,
if
over
time
and
over
talking
with
talking
to
people
and
trying
to
deploy
these
metrics
in
your
tooling,
if
that
the
original
name
isn't
appropriate
change
it,
if
it
doesn't
work
you
just
you
need
to
change
it
to
make
it
be.
What
is
the
most
appropriate
name
so
I'm
not
sure
how
to
resolve
that
with
the
versioning,
because
that's
still
wide
open
in
terms
of
how
we
actually
do
versioning.
A
C
C
A
Seems
we
are
I
agree
with
you
that,
since
right
now
we
are
in
the
process
of
discussing
diversion.
Maybe
we
can
wait.
I
mean
having
the
idea
that
we
need
to
track
this
on
how,
but
until
we
decide
how
the
diversion
in
is
actually,
then
maybe
it's
difficult.
It
is
not
how
to
do
this
because,
for
instance,
right
now,
when
do
you
open
this
issue?
A
D
A
C
B
And
I
think
I
think
where
this
was
triggered
for
me,
like
the
one
code,
changes
changed
from
code
commits
a
month
ago,
didn't
didn't
really
light
up
my
radar,
but
when
I
was
going
through
the
pull
request,
hey-zeus
opened
in
the
last
day
or
so,
where
there's
a
hole
and
I
guess
this
was
in
the
pull
request.
I
emerged
this
morning
and
I
didn't
really
recognize
what
what
that
all
meant,
we're
changing
a
whole
bunch
of
metric
names
that
that
we've
had
for
a
while,
and
you
know,
while
I
agree
that
they
are
a
legacy.
B
You
know
we
are
trying
to
define
things
more
clearly
now.
I
also
don't
know
that
we
need
to.
You
know
at
some
point.
If
we've
had
a
file
out
there
and
there
are
I
know
we
reference
these
a
lot.
So
if
all
the
names
change,
it's
like
a
mapping
exercise
it's
a
source
of
confusion
and
I
guess
my
question:
is
you
know
that
we
don't
have
to
change
the
name?
Maybe
we
try
to
not
change
the
name.
A
Well,
in
generally,
a
good
with
the
video
not
trying
to
change
the
names,
but
in
most
of
the
metrics.
My
my
view
on
this
is
very
personal,
because
you
know
I
was
not
involved
when
the
matrix
only
names
go
to
time,
but
my
personal
view
is
that
they
are
very
tied
to
a
specific
system
and
related
to
a
specific
systems
to
get
help
completely.
Yes
means
which
means
that
first
of
all,
in
some
cases
they're
there
they
may
be
a
bit
a
bit
misleading.
A
B
A
A
On
the
other
hand,
basically
we
need
to
decide
whether
we
say
something
like
come
in
and
then
we
explain.
This
is
a
general
name
for
changes,
but
we
are
using
commit
because
of
historical
reasons
or
wherever
or
we
change
the
name
on.
We
just
say
we
are
now
calling
these
code
changes
because
we
feel
smoke
clear,
but
this
is
basically
what
we
call
code
commits
one
month
ago,
yeah
right.
D
A
A
Let's
say
I
that
the
idea
of
making
these
changes,
for
instance,
watch
more
sensible
trying
to
be
a
general
as
possible
and
also
as
forward-looking
as
possible,
because
for
our
meetings
is
going
to
happen
once
and
again
as
time
classes
with
new
systems
implementing
changes
in
different
ways,
because
the
idea
of
chains,
each
one
is
always
going
to
be
there,
but
how
that's
implemented
in
a
source
code
management
system?
That's
going
to
change.
A
E
A
C
A
C
D
D
A
So
coming
back
to
this
file,
so
this
would
be
the
proposal
from
the
working
load
for
the
release
and
this
would
be
the
one
of
the
focus
areas
that
could
be
released.
So,
if
you
all
agree,
we
can
consider
this
as
the
conversion
and,
of
course,
in
the
next
iteration
they
are
going
to
go
through
it
once
again.
Okay,
so.
B
A
B
A
A
We
would
never
release,
we
need
to
have
some
kind
of
release
notes.
They
have
this
boom
to
basically
say
what
we
are
released
and
as
you're
thinking.
That
is
because
they
are
going
to
hear
if
we
say
a
name
here,
maybe
somebody's
suspecting
well,
this
should
be
implemented
on
and
you
guessed
you
have
to
explain
exactly
what
we
are
doing
and
it
would
be.
We
are
proposing
this
structure
for
the
trial,
which
include
the
names
of
the
metrics,
but
we
are
still
looking
to
make
it.
We
have
some
of
them,
but
not
all
of
it.
A
B
A
No
and
on
something
that
we
can
do
this
is
an
idea.
I
can't
remember
eight
years
of
romance,
including
a
table
at
the
end
of
the
document
saying
these
are
the
metrics
of
our
currently
implemented.
So
the
way
we
have
legacy
metrics
below
again
or
at
the
bottom
of
the
of
the
document
we
have
another
one
which
is
implemented,
metrics
or
defining
matrix
or
something
laden
and
have
the
list
of
the
metrics
that
we
are
actually
using.
That
would
be
releasing
the
file
with
the
structure
of
the
tutorial,
and
this.
A
A
Okay,
so
a
starting
by
the
oldest
by
the
end,
we
have
the
community
manager
this
case,
which
you
were
proposing
things
for
the
new
version.
I
was
commenting
on
it,
so
for
me,
I
basically
agree
with
it.
Only
to
me
no
comments,
one
is
what
we
already
discuss.
It
related
to
the
name
of
the
metric
and
the
other
one
is
related
to
the
metric
itself.
Maybe
we
can
just
have
the
use
case
and
we
move
the
madrigals
web
right
now.
The
metric
is
included
in
the
pool
voters.
Oh.
B
D
B
D
A
B
A
F
A
Is
a
proposal
for
the
code,
change
lines
metric
and
basically
need
the
feedback
or
acceptance
or
whatever?
So
this
is
one
of
my
proposals
for
the
next
release
and
what
I
try
to
do
is
to
keep
the
area
of
lines
change
to
commit,
but
trying
to
write
them
in
a
way
which
is
independent
of
the
underlying
system.
I.
B
G
B
A
A
Right
right-
and
that's
that's
because
for
code
commits
in
fact
it
is,
it
was
deleted
by
code
changes,
but
we
didn't
do
the
deletion
I
mean
that
the
equivalent
metric
is
code,
changes
that
we
already
accept
it
back
when
we
accepted
it,
we
didn't
delete
code
commits
from
the
repository
okay.
So
that's
why
I
included
it
here?
Maybe
I
should
be
doing
a
different
pull
request
but
I'm
sorry.
I
sorry.
B
I
mean
I
I
just
wanted
to,
and
as
long
as
we
kind
of
this
was
to
my
earlier
point
about
like
before
we
were
delete,
code
commits
and
code
lines
of
code
changed.
I
would
want
those
things
in
like
a
dictionary.
That's
linked
to
the
current
definitions
and
things
that
were
calling
things
in.
A
G
B
D
B
A
So,
to
be
honest,
I
just
kept
this
because
we
have
it
in
the
in
the
template
and
I
think
that
at
some
point
we
should
be
commenting
here
about
use
cases
that
we
have
I
mean
that
the
current
use
cases,
which
are
these
detailed,
the
daily
description
of
use
cases.
But
up
to
now
what
I
tried
to
do
was
to
adapt
to
the
idea
of
how
this
could
be
use.
A
It,
which
is
I,
think
what
we
had
in
the
previous
version
of
these
metrics
before
we
had
the
real
use
cases
and
so
on,
because
we
have
this
section
on
the
definition
of
the
metric
and
if
you
look
at
some
of
the
metrics,
apparently
it
was
for
discussion
how
this
metric
could
be
used
and
later
yesterday.
So
my
impression
is
with
time
we
should
be
migrating
to
just
side
in
our
use
cases
here
saying,
like
you
say,
this
is
related
to
the
code
containers,
if
this
case,
for
instance,
and
happening
to
the
use
case.
A
We
don't
really
have
a
birthdays,
but
I
think
that
at
least
we
need
one
review
alright.
So
maybe
we
can
set
it
on
more
than
that,
but
no.
B
D
A
No,
that's
fine,
because
I
know
that
in
many
of
these
cases
this
is
complex,
and
this
is
also
the
first
time
we
are
doing
this.
So
it's
very
important
that
we
all
are
on
the
same
page
and
we
devote
to
that
at
the
time
that
we
need,
because
this
is
going
to
be
investing
for
the
future
yeah
yep
agreed.
So.
A
A
A
So
once
we
agree
with
this
very
likely
with
do
the
same
good
issue,
so
my
idea
was
to
try
to
work
on
this
during
the
weekend
so
that
maybe
for
early
next
week,
we
can
have
issues
also
so
that
somebody
can
review
them,
because
if
we
have
a
general
agreement
in
this
issue,
some
pool
posts
are
very
similar
for
this.
So
I
was
reading
this
money
to
reveal
think
we
much
same
and
I
think
that
we
are
almost
on
the
same
page.
The
stats
are
kept
low
for
very
specific
things.
A
Yeah
I'm
not
now
talking
about
the
reference
implementation.
Well,
maybe
you
are
because
one
of
the
things
that
they
didn't
know
it's
exactly
what
you
would
do
you
want
to
mention
about
theater
and
because,
if
you
look
at
the
structure
of
the
template,
the
specific
description
is
not
exactly
from
how
to
compute
the
matrix
bad
for
describing
the
specifics
of
the
data
source
with
respect
to
the
metrics.
A
It
and
I
was
thinking
it
need
this
way,
but
I'm
happy
to
agree
to
that,
because
the
the
general
idea
of
the
of
the
matrix
file
is
to
include
all
the
details.
So
if
you
want
to
include
something
related
to
how
it
can
be
computed
from
theater
and
or
something
like
that,
I'm
happy.
But
I
think
that
we
need
to
see
how
it
fits
in
the
current
description
in
the
current
schema
of
the
of
the
file.
So.
B
A
B
A
A
B
A
This
is
something
that
they
thought.
If
you
remember
at
some
point,
we
decided
that
we
should
be.
We
should
sorry
we
should
be
mentioning
how
to
map
this
matrix
to
actual
data
sources.
The
directors
before
you
say
and
the
way
of
doing
that,
that's
what
I
thought
it
convenient,
and
it
was
specifically
for
that.
So
this
is
the
area
of
a
pool
report.
A
Sorry,
this
is
the
area
of
a
proposal,
but
how
do
you
make
a
proposal
in
the
case
of
a
github
or
in
the
case
of
curry,
and
and
that's
why
it's
called
a
specific
description,
because
the
idea
is
okay
in
the
very
specific
case
of
grid
lab.
What
is
a
proposal?
And
how
is
this
metric
computer
somehow,
but
not
I
mean
not
with
the
code,
because
that's
in
a
different
part
of
the
of
the
description,
repetitive
fashion,
just
to
let
people
map
the
general
idea
of
proposal
to
specific
things
in
github,
for
instance.
A
But
then,
if
you
go
below,
we
have
known
implementations
so
below
reference
implementation,
which
I
think
should
be
done
with
Remora
welfare
possible,
and
there
we
have
known
implementations
and
something
that
we
can
do
is
since
many
of
the
matrix
you
have
them
implemented
in
order
using
different.
Something
that
is
very
easy
to
do.
One
could
be
quite
convenient,
is
Al,
Gore
is
a
non
implementation
and
I
was
using
this
Koree
into
gay
torrent
to
participate
and.
B
A
B
A
Yeah,
no
I
completely
agree
with
that.
So
if
you
agree,
what
we
can
do
is
known.
Implementations
include
them.
One
second
program
model
have
another
one
for
Al
Gore.
If
it
is
implemented
in
these
systems
and
another
one
from
Kyoto
and
if
we
know
how
to
pour
it
to
zero
and
then
do
you
usually
now,
so
you
can
fill
that
part.
If
you
want.
A
B
E
A
A
B
A
Nom
you
know
in
in
any
case,
for
for
all
the
reference
implementations
I
think
that
if
we
succeed
these
people,
Summer
of
Code
internet
went
you
to
help.
Do
this
yeah,
on
the
other
hand,
and
now
talking
about
specifically
this
metric
proposals,
I'm
not
sure
that
they
want
that
they
were
referencing
from
algo
corresponds
exactly
to
base.
If
I
look
at
the
comments,
so
it's
not
a
matter
of
discussion
now.
If
you
look
at
the
comments-
and
you
can
decide
because
you
know,
I'll
go
much
better.
Yeah.
B
A
A
F
A
Other
hand,
it
should
be
simple
to
implement
for
you
if
you
want,
because
looking
at
the
SQL
query
that
you
are
commented
here,
it
could
be
just
a
matter
of
not
filtering
it
because
you
are
filtering
now
for
open.
So
if
you
don't
do
that,
my
impression
is
that
you
are
getting
exactly
this
metric.
So
I
have
to
look
at
that.
If
you
want
I
wrote
a
comment
about
that,
let.
G
A
A
A
Opened
exactly
because
it
is
mostly
related
to
activity
and
now
to
how
Detroit
is
dealing
with
backlog
or
something
like
that,
so
the
important
from
a
bunt
degree.
The
important
point
here
is
how
many
pull
records.
For
instance,
people
are
starting
in
the
project
which
is
going
to
give
you
an
overall
idea
of
the
activity
in
proportion
changes,
but
back
while
the
other
one
that
you
are
mentioning
here,
I
think
the
sort
of
corresponds
to
the
proportions
backlog.
So
how
many
proposals
we
are
still
didn't
applied
at
a
certain
point
in
time,
all
right.