►
From YouTube: CHAOSS Evolution Working Group 4/5/22
Description
Links to minutes from this meeting are on https://chaoss.community/participate.
A
All
right
well
welcome
to
the
evolution
working
group
for
this
april
5th.
Whatever
year,
it
is
2097,
something
like
that.
Welcome
to
our
newcomers,
we're
hanging
out
vincent
nice
to
meet
you.
Maybe
if
you
want
to
take
a
minute
to
introduce
yourself.
Yes,.
B
A
A
And
mabel,
I
think
you
are
new
as
well.
This
is
the
evolution
working
group
meeting.
If
that's
what
you're
looking
for.
E
Yes,
hello,
I'm
working
I'm
intending
to
apply
to
the
conversion
rate
google
summer
of
code.
Oh
awesome,.
A
Yeah
awesome
welcome
great
the
conversion
rate
there's
also
a
meeting
this.
This
may
be
good
to
get
introduced
to
some
of
the
metrics
and
models
behind
it.
The
conversion
rate
metric.
We
have
a
metrics
model
meeting
a
week
from
today
at
6
p.m:
central
u.s
time
central
daylight
time
like
chicago
time
and
this
tomorrow
morning
at
8
a.m,
central
daylight
time,
chicago
time
we
have
an
asia
pacific
meeting
and
that
particular
metric
model
is
likely
to
be
discussed
at
either
of
those
meetings.
E
A
A
So
welcome.
Welcome
mabel,
welcome
yoush,
welcome
to
simon
so
like
I
said
this
is
the
evolution
working
group
and,
let's
just
get
started
then
so
the
things
that
we
left
to
work
on
the
last
time
were
work
on
a
change
requests,
metrics
model
and
a
proposed
a
metrics
model
for
code
complexity.
A
Wasn't
really
code
complexity?
They
were
after
it
was
more.
Is
the
code
robust
and
good,
so
they
I
think
they
were
looking
more
for
process-oriented
proxy
metrics
that
and
so
code
complexity.
I
don't
think
is
actually
what
the
people
who
proposed
this
metrics
model
were
thinking
of
specifically
actually
after
having
that
meeting
after
this
meeting
two
weeks
ago.
Okay,
so
we
may
just
like
table
this
for
now
and
come
back
to
it
and
armstrong.
You
were
proposing
what
was
the
metrics.
F
D
F
So
is
this:
are
you
recommending
this
package
as
a
place
to
look
or
not?
Well
it's
something
that
is
a
good
start.
Okay,
that
yeah.
D
But
it
you
know,
we
we
have
to
adapt
things
based
on
our
reality
and
how
we
could
inform
other
people
consuming
our
metrics,
because
the
entire
thing
it's
we
are
trying
to
measure
each
commit
the
significance
of
that
commit
against
the
code
base
and
the
prevalence
of
that
commit
on
the
changes.
So
it's
actually
a
process
on
that
commit,
rather
than
talking
about
the
the
complexity
as
a
measure
itself.
We
look
at
the
process
of
getting
that
end.
G
D
Yeah
I
mean
if
people
have
been,
there
are
a
couple
of
things
they
think
it's
people
don't
really
get
into
into
applying
this
concretely
in
project
yeah,
because
sometimes
kind.
A
D
Yeah,
I
know
there
are
a
couple
of
academic
papers
that
really
propose
these
things
and
companies.
I
know
companies
like
ubisoft,
mostly
they
are
not
open
sourced,
but.
D
A
Essentially,
the
entropy
is
greater.
Essentially,
the
the
rate
of
change
is
greater
if
there's
more
files
affected,
so
the
entropy
is
higher.
So
if
I've
got
a
commit
that
affects
12
files,
that
is
more
entropic
than
a
commit
that
affects
one
file
in
this
in
this
application,
would
you
apply
it
differently?
Would
we
be
interested
in
how
much
of
each
file
has
changed
in
a
commit.
D
D
D
They
introduced
an
error
where
things
were
working
well,
so
yeah,
but
bringing
it
down
to
this
kind
of
measurable
quantity
like
entropy,
you
really
now
to
see
how
dangerous
a
commit
could
be
or
how
good
a
commit
could
really
be
against,
and
then
one
thing
that
we,
I
was
also
thinking
it's
trying
to
propose
a
kind
of
predictive
model
before
you
make
a
pull
request,
something
like
your
editor
or
your
ides,
and
things
like
that
can
warn
you
that
this
commit
based
on
historical
fact
is
a
dangerous
community.
Don't
push
it?
Okay,
yeah
those.
A
Kind
of
things
yeah
so
we're
trying
to
get
some
of
this
down
on
a
google
doc.
Would
you
this
seems
like
a
metrics
model
because
it
seems
like
it
would
use
lines
of
code
yeah.
I.
G
I
I
D
A
D
Is
this
a
model
or
no?
No
entropy.
Is
it
the
this
concept
comes
from
the
champion
law
of
entropy
of
information.
A
A
The
pull
request
as
the
highest
factor
instead
of
the
commit,
because
a
full
request
can
include
100
commits
yeah
and
that's,
but
I
don't
want
to,
I
wouldn't
say,
commit
entropy
is
unuseful.
A
I
would
I
would
say
like
when
I'm
looking
at
like
when
I'm
evaluating
the
risk
of
accepting
a
change.
It's
almost
always
at
the
pull
request
level,
I'm
almost
always
looking
at
multiple
files
and
there's,
usually
maybe
I'd,
say
minimally,
two
or
three
commits
and
sometimes
50
commits
that
are
part
of
that.
One
pull
request.
A
So
would
we
like,
if
we're
thinking
in
terms
of
entropy
metrics
model,
more
broadly
construed,
then
I
might
want
to
take
a
look
at.
D
I
think
I'll
also
send
you
this
paper
to
look
most
of
the
papers.
Okay,
the
thing
is
that
when
you
want
to
measure
things
like
in
the
code
base,
you
want
to
get
a
lower
level
of
granularity
poll
requests.
As
you
know,
yeah
it's
like
an
abstract
quantity
of
this
individual
commit
they
don't
live
on
their
own
without
the
commit
some
commits
are
dangerous.
Some
are
good.
Some
have
more
in,
like
touching
bringing
so
many
changes.
Okay
yeah,
so
we
want
to
measure
this
individual
units.
These
component
blocks
to
see
how
that
pull.
D
A
D
A
A
I
guess
you're
right:
if
we,
if
we
look
at
how
much
code's
affected
by
each
commit,
then
we
would
have
all
the
granularity,
but
we
wouldn't
have
the
we
wouldn't
have
the
principal
unit
of
work.
So
I
would
so
I
would
think
if
so,
if
it's
a
match,
I
would
say
that
we,
I
don't
know.
A
It
sounds
like
we
want
the
matrix
model
at
the
commit
entropy.
We
want
a
metric
for
commit
entropy,
and
I
think
we
can
reverse
engineer
that
from
this
link
that
you've
provided.
A
But
then
the
next
question
is:
do
we
also
want
to
a
metric
related
to
sort
of
like
I,
I
guess
I
could
think
of
a
metric
for
for
pull,
request,
entropy
as
well
and
together,
those
two
would
be
the
foundation
for
an
overall
project
entropy
metric
model.
D
I
If
I'm
understanding
correctly
is
it
like,
we
are
first
defining
commit
entropy,
pull,
request,
entropy
and
then
from
those
we
are
creating
a
model
as
a
project.
D
There
is
one
blog
post.
Let
me
try
to
look
for
it,
because
the
other
papers
that
I
I
have
here,
I
I
mean
might
be
all
of
us-
cannot
access
it.
Since
some
of
them
are
in
the
ieee
explore
they
are
not
really,
I'm
not
sure
everyone
can.
D
The
time
I
did
some
research
with
them,
we
were
proposing
a
kind
of
this
sifa,
but
I'm
not
sure
it's
it.
It
went
through
a
certain
level
of
maturity.
D
This
thing
that
when
you
start
writing
your
code,
even
before
you
make
a
final
request,
it
really
wants
you
on
how
dangerous
or
how
successful
this
kind
of
thing
could
be.
So
you
really
before
even
waiting
for
it
for
reviewers
to
give
you
certain
feedback,
you
see
you
try
to
measure
against
the
code
base.
What
is
has
been
accepted
already,
you
try
to
see
it
and
all
of
them
were
rebuilding
from
the
entropy
perspective.
D
L
D
I
A
Code,
so
what
the
previous
metric
doesn't
provide
us
is
a
context
for
lines
of
code
changed,
so
we're
getting
commits
and
we're
getting
lines
of
code
changed.
What's
important
in
this
metric
and
missing
from
lines
of
code,
I
think,
is
in
a
across
the
project
how
many
files
are
affected
by
each
commit
and
then
within
each
file.
A
D
A
A
I
So
so
maybe
yeah
share
the
link
I'll
rewrite
the
question.
Maybe
it
says
how
much
code
is
affecting
a
particular
piece
of
software
or
particular
file,
or
something
like
along
that
line.
The
way
armstrong
has
described
now
now
I
can
see
the
like
its
impact.
A
F
Okay,
let
me
just
trying
to
locate
you
and
you
can
put
like
any
references.
You
have
you,
okay,
yeah.
A
G
F
A
D
I
A
I
J
J
A
The
p
I
was
able
to
download
the
pdf
okay
that
well
yeah.
I
was
that
was
I'd
gotten
that,
but
I
guess
you're
not
seeing
it
because
my
screen's
too
big
to
share
with
everybody.
If
people
aren't
laptops
it's
overwhelming,
so
I
could
share
that.
A
But
why
don't
I
just
I
just
put
it
up
and
I'll
give
you
a
link
to
it
in
our
drive.
D
So
when
you
visualize
over
time
now
you
you
could
easily
see
the
changes
over
time
and
measure
it
against
like
productivity
or
whatever
you're
measuring
pay,
100
percent.
So
no,
no,
no,
no
particular
file
structure
could
be
also
go
like
extremely
high
and
some
other
very
low
because
of
their
prevalence,
but
when
they
normalize,
they
really
have
a
standardized
form.
A
A
The
footnote
I
put
at
the
very
top
number
one,
that's
the
length
of
the
pdf
just
so
we
have
a
common
reference.
A
A
Yeah
they
talk
about
in
this
paper
the
possibility
of
evaluating
both
lines.
A
A
I
mean
I
I'll
just
come
back
to
beat
the
dead
horse
that
this
paper
was
written
before
github
and
pull
requests,
merge
requests,
change,
requests
became
a
primary
unit
of
how
people
make
changes
to
codes.
So
I
do,
I
do
think
the
commit
change
is
certainly
the
most
granular
and
it's
certainly
useful.
F
On
this
right
now
or
do
we
want,
I
mean.
D
A
A
A
A
A
A
Yes,
certainly
the
there's
a
paper
that
armstrong
identified
is
yep,
it's.
It
seems
to
be
the
canonical
definition
of
commit
entropy,
and
I
suspect,
if
I
looked
at
papers
that
cited,
I
would
find
current
state
of
the
art
or
thinking
on
this,
so
that
this
to
me
is
a
little
bit
like
a
literature
review.
A
A
That
we
could
use
to
sort
of
weave
our
way
through
okay
weave
our
way
through
the
process
of
determining
how
we
want
to
express
this
metric.
I
know,
in
my
case,
I'd
probably
want
to
read
at
least
this
paper
and
I'd-
probably
probably
search
for
a
few
more
on
my
own.
But
if
you
have
ones
that
you
recommend,
then
let's
use
those
okay
to
give
you
the
action.
A
Okay,
let's
see.
A
You
have
about
seven
minutes
left.
I
don't
feel
like.
I
can
make
any
more
contribution
to
this
before
looking
over
some
of
the
prior
work
on
it
getting
my
head,
I
mean
I
have
a
general
conceptualization
of
what
it
means,
but
when
it
comes
to
how
we
might
want
to
visualize
that
and
what
an
implementation
might
look
like
like
okay,
so
theoretically
I
mean,
I
think
an
implementation
would
go
from
get
log
to.
A
A
A
D
F
G
D
H
A
H
A
K
A
D
D
You
know
the
common.
The
common
misleading
thing
with
figos
is
that
if
somebody
tells
you
that
90
percent
of
the
commits
are
let's
say
harmful
without
knowing
the
population
that
they
are
talking
about,
that
could
be
so
misleading
statistic
to
present
to
somebody,
because
the
the
90
percent
may
come
from
the
fact
that
you
had
only
let's
say,
500
fights
in
your
whole
repository,
then
somebody
with
50
000.
G
A
A
Okay-
and
I
think
maybe
like
it
to
do,
is
to
try
to-
I
think
we
do
have
to
get
this
to
some
kind
of
some
sort
of
formula
representation
so
that
it
can
be
implemented
consistently
in
tools.
I
F
I
A
A
A
A
Anyway,
this
this
gets
back
to
our
our
knowledge
base
and
yeah
how
we
organize
information,
because
this
is
one
that
could
certainly
be
cross-listed
in
both
working
groups
and
I
think,
as
we
create
more
metric,
you
know
we're
at
the
point
with
metrics
development
where
these
this
is
a
really
useful
metric
that
we
haven't
conceptualized
before,
but
in
order
to
make
it
useful-
and
I
I'm
just
thinking
I'm
thinking
about
both
where
it
belongs
from
the
kind
of
work
done
in
a
working
group
and
also
where,
where
it
would
be
where
I
would
look
for
it
as
a
newcomer
to
the
community.
A
So
if
I
was
looking
for
something
about
commits,
I
might
not
initially
conceptualize
it
as
a
risk.
I
might
just
conceptualize
it
as
commit
entropy.
So
I'm
browsing,
I
don't
know
it's
like.
I
don't
have
a
strong
opinion,
I'm
just
sort
of
speaking
my
thoughts
out
loud
about
what
what
you
made
me
think
of
when
you
suggested
deploying
it
in
the
risk
working
group.
I
A
Is
it
criticality
is
that
I
don't
know
how
you
me,
I
don't
have
a
I'm
getting
really
super.
You
know
attentive
now,
but.
A
I
Silicon,
so
what
I'm
saying
is
like,
if
you,
if
you
look
at
the
first
example,
the
armstrong
provided
is
like
if
30
people
or
10
people
or
20
people
are
committing
a
code
and
they
all
are
changing
one
particular
line,
and
we
want
one
particular
file.
So
we
want
to
assess
the
riskiness
of
that
code
or
commit.
A
It
becomes
a
very
I
try
to
try
to
catch
it
before
I
run
tests.
You
know
obvious
logic,
errors
with
the
review
process,
but
this
this
would
be
a
really
good
measure.
That
would
tell
me
if,
if
yeah,
if
a
lot
of
code
or
a
lot
of
files
are
changing
regularly,
I
would
say
I
would
characterize
the
entropy
is
high
and
the
risk
of
the
project
is
higher,
so
to
speak,
so
all
right,
so
that
I
think
that
was
a
really
good
discussion.