►
From YouTube: CHAOSS Common July 9, 2020
Description
CHAOSS Common July 9, 2020
A
A
I've
been
finished
mine
in
thawne's,
not
here
so
maybe
we
could
start
some
of
that
and
then
Daniel
I
are
both
here.
We're
talking
about
lines
and
files
and
I
think
there
is.
There
were
some
proposed
metrics
in
common
Daniel,
correct
me.
If
I'm
misremembering,
there
were
some
impose
common
metrics
on
lines
and
files.
C
Yes,
oh
it
was,
it
was
what
I've
done
has
to
check
the
evolution
working
group.
So
then
I
found
the
one
related
to
lines.
I
didn't
find
any
related
to
files.
Okay,
one
missing.
This
is
also
I.
Didn't
know
how
to
proceed
in
the
sense
of
should
I,
go
and
create
lines
or
should
I
create
this
one
in
evolution
for
files
as
well
or.
A
So
lines
does
exist
in
evolution,
files
doesn't
I,
think
it's
a
I,
don't
I,
don't
know
my
my
tendency
would
be
to
try
to
put
things
that
seem
to
me
to
be
obviously
similar
in
the
same
working
group.
However,
what
I
think
is
obviously
similar,
may
not
be
what
you
think
is
obviously
similar,
so
I'm
going
to
ask
what
others
think
so
that
the
question
is
there's
metrics
around
the
files
included.
You
know
is
this
at
the
commit
level
or
the
pull
request
level
Daniel
that
you're
thinking
about
this
are
both
I.
C
A
So
there's
there's
two
places
where
lines
of
code
and
files
included
in
a
code
can
be
counted
easily.
One
is
in
a
pull
request
to
review
requests.
The
other
is
in
the
commit
itself
each
commit
and
each
pull
request
contain
a
number.
Usually,
a
pull
request
rolls
up
a
number
of
commits,
but
each
of
those
you
typically
contains
a
number
of
lines
of
code
changed
in
aggregate
and
a
total
number
of
files
changed
in
aggregate
and
looking
at
the
trends.
A
For
you
know,
lines
of
code
changed
and
files
changed
over
time
is
a
metric
that
people
are
interested
in
and
we
measure
these
things
in
auger
and
tables
we
have
port.
We
have
commits
the
lines
changed
in
the
files
changed
or
in
the
commits
table,
and
the
pull
request
commits
are
in
a
pull
request,
commits
table
on
the
floor.
A
A
Okay,
good
all
right,
so,
let's
start
with,
if
things
seem
similar
in
general
to
metrics
that
are,
or
closely
related
to
metrics
that
already
exist
in
one
working
group
like
evolution,
yeah,
we
want
to
treat
a
keep.
Do
we
want
to
try
to
keep
metrics
like
that
in
the
same
working
group
on
just
that
principle
at
the
principle
level?
What
do.
D
A
Or
well
I
think
so.
We've
got
an
interesting.
So
there
are
two
cases
if
we
use
this
as
an
example
of
Daniel
and
I'm
providing
an
object,
lesson
or
question
to
the
community.
In
the
case
of
lines
of
code,
there
already
exists
a
metric
in
in
the
case
of
camels.
A
metric
doesn't
exist
anywhere,
okay,
so
around
I
guess
the
question
could
really
be
just
in
the
air.
C
Every
perhaps
trying
to
do
have
the
question
in
a
similar
way
to,
for
instance,
math
or
you
know
or
others,
so
we
have
to
deal
with
files
lines
of
code.
We
have
realize
that
lines
of
code
are
in
in
evolution
working
group,
but
we
are
now
in
the
common
working
group.
What
would
you
do
if
we
need
to
open
it,
because
we
need
to
open
a
new,
a
new
metric
files?
G
I
guess
the
question
is
that
it,
if
files
is
something
we
think
would
become.
This
is
my
opinion
anyway.
If
files
is
something
we
think
would
be
common
across
the
groups,
then
it
should
go
in
common,
but
if
it's
something
that's
going
to
only
be
specific
to
evolution,
then
I
think
it
should
go
in
evolution.
D
D
A
So
risk
Rick
risk
does
consume
metrics
from
a
lot
of
the
working
groups,
certainly
a
lot
of
evolution
metrics,
but
we
do
have
a
different
set
of
questions
that
were
asking,
so
we
might
use
the
same
metrics
to
look
at
a
contributor,
parameterised
or
filtered
edition
of
that's
that
metric,
so
risk
risk
is
a
big
consumer
of
common
and
evolution,
metrics
and
a
developer
of
lines
of
metrics
around
licensing
and
testing
and
code
quality.
Although
there's
some
Co
quality
metrics
in
evolution
risks
an
interesting
example,
though
I.
C
A
And
forks
is
actually
you're
right.
It's
it's,
but
Forks
is
a
little
bit
different
because
it's
not
from
the
git
repository.
Typically,
it
is
from
the
hosting
platform,
and
there
are
three
working
groups
that
are
interested
in
that
metric
risk.
Evolution
in
common,
so
Forks
is,
is
interesting
to
a
lot
of
different
working
groups
and
in
that
specific
case,
I
could
see
where
it's
it's
platform-specific.
A
G
C
G
Know
so
in
that
regard,
I
think
maybe
it
doesn't
belong
in
common,
because
I
feel
like
Commons
should
be
something
that
is
common
to
everyone
or
maybe
like
four
out
of
five.
You
know
so
or
I
guess
three
out
of
four
other
groups,
so
that
would
just
be
my
question
is
what
would
be
the?
What
would
be
the
motivation
to
move
it
to
comment?
I
think
Matt
asked
that
also
so
and
to
me
it's
not
super
clear
and
also
value
I'm,
not
I'm,
not
really
sure
how
that
directly
ties.
D
If
I
look
at
the
common
metrics
that
are
really
strong
to
review
at
the
moment,
just
the
focus
areas
of
what,
when
and
who
so
it's
pretty
high
level
things
like
time
to
first
response,
which
could
be
for
an
issue
to
a
pull
request
to
an
email
to
whatever
time
to
close,
which
again
is
applicable
to
a
variety
of
different
things.
Lines
lines
of
code
seems
pretty
specific.
E
F
D
D
Share
I,
don't
see
everybody
sorry,
so
each
of
the
working
groups
is
trying
to
identify
metrics
that
are
kind
of
appropriate
for
their
area
of
interest.
So
DNI
defines
metrics
that
are
important
to
diversity
and
inclusion.
Risk
identifies
metrics
that
are
important
to
risk
value
so
on
and
so
forth.
Common
is
a
slightly
different
working
group
in
that
we
had
found
that
across
the
working
groups
there
were
some
kind
of
common
characteristics
that
each
of
the
working
groups
shared
things
usually
associated
with
time
or
people's
location,
things
that
were
common
across
tall
working
groups.
G
H
D
D
Right
so
when
we,
when
we're
indie
and
I
and
we're
coming
up
with
DNI
metrics,
it's
usually
pretty
clear
that
this
is
a
diversity
and
inclusion
metric
specific
to
having
a
better
understanding
of
DNI,
whatever
that
metric
might
be,
but
common.
This
is
it's
always
it's
just
really
hard.
Sometimes
I
don't
know.
A
A
Yeah
I
I
do,
and
it's
like
I,
think
I
think
Commons
started
out,
because
we
had
these
metrics
that
didn't
really
fit
in
the
other
working
groups
and
if
we
think
of
it
that
way,
then
if
a
metric
logically
fits
in
one
and
mostly
one
other
working
group,
then
probably
goes
there.
If
it's
like
Forks,
where
you
have
interest
from
three
working
groups,
that
is
a
different
thing
entirely
right,
because
now
you
have
multiple
workers
that
are
interested
in
this
metric,
and
maybe
that
is
the
very
definition
of
common.
B
A
D
A
A
B
G
So
you
know
that
CMC,
those
are
in
case
you're,
not
familiar
with
that.
That's
those
are
metrics
that
we
relief
kind
of
in
between
the
big
releases
which,
which
is
what
we're
doing
right
now,
so
we're
getting
ready
to
release
a
big
chunk
of
metrics,
but
they
we
only
do
those
once
every
six
months.
So
in
the
middle
there
might
be
a
few
that
come
up,
that
we
just
go
ahead
and
kind
of
pre
release
like
a
soft
release
and
then
we'll
lump
them
into
the
big
releases
as
well.
I
A
A
D
A
I
F
D
I
We
just
say
the
review
period
stays
open
until
the
public
release,
because
that
may
be
eliminate
the
opening
and
closing
and
changing
status
back
and
forth
when
a
metric
is
ready
to
be
released.
At
any
point,
we
can
add
it
to
the
website.
We
can
start
the
review
period
and
then,
one
month
before
the
release,
we
closed
that
window
for
adding
new
metrics
to
the
website,
and
that
is
our
traditional
release.
Candidate
period
review
period,
one
month,
it's
only
reuse
known
tricks.
So
that
is
how
I
understand
the
process
can
work
in
the
future.
G
A
A
Kate
but
they
get
tagged
in
the
next
drill,
so
they're
sort
of
like
CMC
metrics
or
in
a
bigot
tag
in
the
next
full
release,
far
as
being
part
of
that
release,
but
they
don't
necessarily
have
to
go
through
the
like
I'm
gonna
treat
things
that
were
released
in
CMC
very
differently
in
terms
of
comments,
then,
then
I
will
things
that
are
brand
new
in
this
release
period,
like
I'm
gonna
as
a
participant
I
think
about
those
things,
that's
basically
being
released
and
reviewed
that
they
don't
require
attention
from
you
right
now.
I.
A
Yeah
yeah
I,
don't
know
it's
it's
it's
a
factor.
I
guess
we
need
to
understand
just
the
extent
of
what
are
we
asking
people
to
review?
Are
we
looking
at
continuous
metrics
for
leases
and
the
new
metrics
or
yes
Lee?
Then?
Yes,
so
a
continuous
metric
release
is
is
getting
reviewed
both
during
the
interim
period
and
at
the
end.
Yes,.
D
D
B
D
B
D
C
C
D
A
Then
there
was
a
question
about
the
next
thing
on
the
agenda
is
discuss
with
releasing
review
progress
on
the
metric
spreadsheet
and
a
particular
question
came
up
about
contributor,
employer
location
and
it's
very
similar
to
contributor
location
and
I.
Don't
know
if
we
want
to
discuss
that
or
we
want
to
sort
of
table
that
until
another,
so
it's
kind
of
I
guess
I
will
check
the
temperature
of
the
group
here.
Do
we
want
to
talk
about
that
or
not.
D
So,
maybe
again
for
stefka.
So
we
we
have.
This
metric
spreadsheet
and
you'll
see
the
tabs
across
the
bottom,
which
correspond
to
every
working
group,
and
this
allows
us
to
kind
of
keep
track
of
which
metrics
have
been
released
in
each
working
group
and
what
the
state
of
work
is
for
particular
metrics
that
we
might
have
an
interest
in
releasing
per
working
group.
So.
A
A
A
D
A
I
A
E
A
E
So
for
the
folks,
the
question
for
this
metric
is
what
are
the
number
of
folks
for
an
open-source
project,
so
the
focus
perceived
differently
for
the
different
groups,
but
mainly
it's
the
count
of
folks
that
is
evaluated
or
there
any
other
perspective.
Any
thoughts.
I
read
this
from
the
perspective
of
ok,
how
many
folks
for
an
open-source
project
or
a
repo
there
are
that
helps
to
assess
the
risk.
E
A
E
A
Like
I
mean
there's
Derek,
there's
kind
of
there
are.
The
project
is
interested
the
number
of
forks,
because
it's
looked
at
as
the
potential
number
of
future
contributors
or
people
who
are
interested.
It's
an
interest
level
indicator
and
then,
materially,
though,
those
forks
could
be
there
from
many
different
purposes
like
sometimes
I
create
a
fork
just
to
have
a
stable
version
of
a
project
that
I
refer
to.
So
I
refer
to
my
work
instead
of
the
root,
so
I
can
control.
One
change
happens.
E
C
F
C
Had
to
live
for
10
minutes,
so
maybe
you've
already
discussed
about
this,
but
there
might
be
a
specific
use
case
and
I
remembering
at
this
Christine
on
the
table
some
years
ago,
which
is
so,
let's
assume
we
have
a
prayer
than
that
I'm
sure
there
are
some
Forks
around,
but
then
that
specific
prayer
for
immigration
tends
to
die
or
to
decline
in
somehow.
So
what's
the
next
place,
I
should
go
to
keep
having
to
keep
working
in
this
project.
So
what
stay
just
for?
C
A
C
C
G
Can
also
say
from
a
value
perspective,
I
think
this
is
an
interesting
question,
because
I
know
there
are
some
like
projects
for
social
good
that
are
meant
to
be
fort
and
localized.
So,
like
it's
almost
like
a
template
where
they've
set
up
something
for
local
data
collection
or
local
local
good
that
they
say.
Okay,
we
were
doing
this
like
in
San
Antonio
or
whatever
take
this
project
and
apply
it
in
your
own
cities.
So
I
think
it
can
also
from
a
value
perspective,
indicate
something
that
is
is
useful
and
it's
meant
to
be
for
it.
A
So
and
and
so
I
guess,
the
question
is:
is
there
ever
an?
Are
there
two
other
two
main
use
cases,
or
is
that
an
oversimplification
to
say
that
sometimes
it's
Fork
and
you
you're
expected
to
do
different
things
of
that?
Never
returned
the
code,
and
sometimes
it's
Fork
with
the
explicit
intention
of
making
a
contribution
to
the
code
or
those
I.
A
G
I
Been
going
through
editing
this
with
the
idea
in
mind
that
what
we
are
talking
about
our
github
Fork
and
to
recognize
that
github
Forks
are
not
the
community
Forbes
or
the
hostile
Forks
they
could
be,
but
that
we
don't
know
if
someone
creates
a
fork
on
github.
What
their
intention
is.
We
don't
know
what
they
are
contributing
back.
I
want
to
contribute
back
right.
I
A
I
think
that's
important,
though,
because,
for
example,
with
pull
requests,
we
created
the
general
concept
construct
of
a
review,
an
evolution
way
back
when,
because
it's
a
generic
word
for
the
two
different
kinds
of
distributed
version
control
code
contributions
that
I
can
make
is
an
on-court
member
of
a
group.
I
can
do
a
pull
request
from
my
fork
or
I
can
do
a.
A
E
E
Gonna,
be
you
that
means
we
should
not
distinct
to
the
platform
and
generate
I
was
thinking
enough,
like
in
the
objectives.
We
have
my
reasons
for
for
as
a
separate,
like
explanation
that
people
do
for
this
to
three,
for
whatever
the
reasons
can
be,
which
is
like
copying
it
contributing
back
replicating
or
not
contributing
that.
A
I
A
We
can't
yeah
I,
know
yeah
I
raised
that
or
Danny
died,
so
I
went
and
looked
and
like
so
we
know.
Maria
DB
is
a
hostile
for
grey,
like
it's
a
prominent
hostile
Fork.
But
when
you
look
at
its
source
repository
it's
now
under
github
in
the
Morea
DB
organization,
as
the
project
server,
so
it
no
law
for
the
construct
of
a
fork
technically
doesn't
exist.
A
So
this
would
be
the
reason
for
your
technical,
Forks
right,
you're,
trying
to
narrow
the
scope
of
this
to
technical,
Forks
and
scope
out
the
hostel
Forks,
where
I
disconnect
from
head
and
start
again.
You
want
those
to
not
be
part
of
this
metric.
When
you
say
technical
Forks
am
I
getting
that
right
here.
I.
A
I
A
C
And
we
could
come
in
I
was
I
was
coming
to
look
at
the
at
Google
Scholar
looking
for
academic
papers,
because
I'd
remember
a
couple
of
them:
no
I
didn't
remember
a
cup
of
them,
so
I
was
looking
for
them
and
then
we're
looking
for
for
open
source.
It
was
interesting
to
see
some
keywords
related
to
this
sustainability
of
open
source
software
communities
beyond
the
park
and
then
long
long
term,
sustainability
of
open
source
software
communities
began
to
fork
which
are
both
related
to
LibreOffice.
C
A
C
That
in
academia,
people
were
using
the
concept
of
fork.
Trommel
is
sustainability
of
the
new
Ford
versus
the
previous
version
or
around
then
motivations
to
fork.
That's
another
another
area
and
those
motivations
may
bring
perhaps
some
more
questions
here
in
the
fourth,
at
least
for
if
we
only
focus
on
technical
works,
that's
a
bit
different
because
there
are
some
a
specific
wants
us
how
to
avoid
a
fork
or
think
before
you
fork,
which
is
interesting
as
well.