►
From YouTube: CHAOSS Evolution Working Group 3-17-21
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Apparently,
the
person
who
put
this
here,
which
would
be
me,
did
not
recognize
the
year
had
turned
it's
really
like
the
400th
day
of
2020
anyway,
but
so
we
talked
about
reviewing
a
work
on
change
or
beginning
work
on
change,
request
commits
and
we
set
some
goals,
these
being
kind
of
our
top
seven
in
in
some
manner
of
order,
but
perhaps
not
canonical
for
metrics.
We
wanted
to
work
on
during
this
period.
A
Those
are
reflected
in
this
spreadsheet,
which
change
request
commits,
is
here
and
apparent.
I
thought
we
had
created
a
document
for
it,
but
perhaps
we
did
not
was
it
commits
or
comments?
Am
I
reading
comments
is
what
I
wrote
check.
Our
goals
commits
is,
what's
there
and
there's
some?
Is
somebody
logged
in
as
the
chaos
user,
where
they
can
create
a
document
in
a
chaos
folder
for
us?
I.
A
C
A
D
B
B
There,
it
is
it's
in
the
metrics
repo.
E
B
I
mean,
I
think
this
is
the
updated
one
because
georg
just
did
a
commit
to
it
last
month,
so
I
think
it's
up
to
date.
A
For
that,
so
we
have
handy
links.
Sh
do
you
need
to
create
it.
B
No,
I
just
I
just
did
awesome.
A
A
It's
sure
change
request
commits.
A
A
Could
be
lines
of
code
lines
of
code
yeah
I
mean
that
would
be
the
only
measure
of
a
commit
size.
I
think
we'd
go
back
to
the
commit
metrics
which
are
so
under
the
description.
We
could
maybe
talk
about
lines,
added
lines
deleted
and
number
of
file.
I
think
number
of
file.
You
know
how
many
files
are
included.
A
You
know
a
change
request.
Those
are
the
oh.
No,
no
files
is
a
separate
metric.
Never
mind
need
files
out
of
this.
A
A
A
A
A
So
kevin
you've
done
a
lot
of
thinking
about
change.
What
have
I
missed.
G
E
Just
a
second
I'm
gonna,
I'm
trying
to
log
into
my
computer,
so
I
can
have
access
to
the
document.
Okay,
I'm.
A
Sorry,
so
what
it
says
right
now
is
change.
Request,
commits
enumerates
each
commit
the
lines
of
code
on
average
and
provides
an
indication
of
how
a
general
repository
is
maintained.
For
example,
it
is
well
recognized
that
larger
commits
take
longer
to
review
and
merge
because
they
affect
more
parts
of
the
repository's
parent
function.
Maybe
functionality.
A
B
B
So
a
quick
question,
so
knowing
the
answers
to
these
questions
would
help
an
open
source
maintainer
in
that
they
could
gauge.
If,
if
there's
a
lot
of
like
complicated,
commits
a
lot
of
big
commits,
then
they
might
need
to
have
more
people
on
their
review
team
that,
with
like
deep
knowledge,
instead
of
like
going
for
like
the
new
contributors,
they
might
want
to
get
some
like
if
they're
trying
to
grow
their
community.
B
B
Make
sure
that
they
have
enough
people
that
can
handle
these
complicated
commits,
because
that's
you
know
where
it
turns
out
most
of
their
commits
land
is
in
the
big
side
or
if
they're
small.
If
there
are
a
bunch
of
little
tiny
commits,
then
they
can
maybe
grow
their
review
team
and
their
merging
team
people
with
access
to
merge
and
a
little
you
know
flatter.
They
don't
have
to
be
quite
such
deep,
have
deep
knowledge
as
much.
I
guess
so.
B
It
help
them
figure
out
how
to
build
out
that
team
to
adjust
them
in
time
length
in
a
timely
manner.
A
A
B
C
The
question
why
we
are
focus
on
the
lines
of
code
not
on
the
files.
E
Than
okay,
I'm
back
I'm
sorry
about
that
change.
C
Because
focus
on
the
lines
of
code-
and
the
name
is
name-
is
inclusive
of
the
files
and
the
lines
of
code.
Then,
if
we
are
just
focused
on
the
lines
of
code,
then
I
I
propose
like
we
should
change
the
names
of
the
lines
of
code
change,
request.
F
Submission
lines
of
code
we
do
have,
we
do
have
lines
of
code.
E
So
the
way
the
way
I've
looked
at
these
in
the
past
is
is
actually
lines
of
code
added
lines
of
code
deleted
and
number
of
files.
So
all
three
of
those
metrics
can
inform
the
complexity
of
a
commit.
C
E
A
C
A
C
D
E
Probably
makes
sense
yeah
this
code
changes
and
commits
is
probably
they're,
probably
very
similar.
E
The
lines
of
code
is
just
something
that
can
occur
within
a
commit,
so
the
we
can
count
commits
and
then
within
the
commit
we
can
count
the
lines
of
code
that
have
changed
added
deleted.
We
can
count
the
number
of
files
that
are
involved
yeah.
I'm
I'm
more
worried
about
the
difference
between
change
request
commits
and
the
and
just
code
changes.
C
C
Because,
like
I
see
the,
I
don't
see
the
difference
in
all
three,
I
see
the
wordings
are
very
similar.
Things
are
being
mixed
up
kind
of.
E
E
A
I
think
that's
commits,
I
think
I
I
think
that's
what
that
is.
Yes,
so
maybe
we
need
a
name
change
on
that
one.
I
wouldn't
object
to
that
because
I
think
code
changes
is
a
little
ambiguous.
A
E
A
So
this
is
commits
and
yeah
calling
it
code.
Changes
is
a
little
bit
it
doesn't
it's
not
as
helpful
as
is
calling
it
what
it
is
so
kevin
do
we
have
this
is
this
is
in
fact
the
markdown
that
will
is
used
to
generate
what's
on
the
website?
A
E
Actually,
the
the
the
ambiguous
nature
of
this
title
probably
makes
this
one
really
easy
to
change,
because
if,
if
code
changes
exists
anywhere
else
in
the
in
in
our
metrics
definitions,
it'll
just
be
kind
of
kind
of
a
high
level
it'll,
just
it
won't
necessarily
point
back
to
a
metric
it'll
just
be
so
I
I
agree
so.
A
Code
changes
is
it's
ambiguous
and
what,
if
we,
instead
of
changing
it
straight
up
to
commits
made
it
code
changes
either
parenthetically
or
colon
commits,
so
that
we
could
people
looking
for
this
that
have
known
it's
been
there,
because
I
think
this
metric
was
released
over
two
years
ago
would
still
be
able
to
identify,
would
still
be
able
to
find
the
metric
that
they're
familiar
with,
and
also
see
a
more
a
clearer
translation
of
what
it
is.
A
E
A
Guess
you're
I'm
just
thinking
about
I'm
not
right
or
wrong.
I
don't
think
I'm
just
asking
us
to
ask
the
question
about
creating
some
navigational
consistency
that
people
can
count
on,
especially
people
who
build
tools.
You
know
I
I
don't
know
what
I
don't
know.
If
petergia
calls
them
code
changes
in
their
software
or
not.
I
know
that
auger
calls
them
commits.
E
And
if
this,
if
this
was
created
two
years
ago,
this
would
have
been
created
during
the
time
that
jesus
was
kind
of
leading
this
group.
So
it
might
be
your
it
might
be
connected
directly
to
a
vitergia
naming
convention
right.
E
I
think
sometimes,
that
ambiguity
doesn't
do
us
any
favors,
though,
and
I
I
think
the
like
we,
we
got
burned
a
little
bit
on
the
well
the
the
code
reviews,
one
right.
E
E
The
potential
to
cause
confusion
as
well
people
call
it
a
commit.
So
so
there
are
three
other
metrics
that
use
that
same
naming.
Convention
yeah,
I'm
just
looking
at.
E
A
A
custom
label
commits
right
in
the
betergia
visualization
that
we
include
in
the
metrics,
so
I
don't
think
we're
like
out
of
line
right.
I
want
to
do
something
here
that
that
makes
it
clear
and
I
have
what
it
like:
we've
changed
review
like
code
reviews
wholesale
to
change,
requests
right
because
there's
a
whole
other
thing
called
code
reviews
right
or
reviews
that
our
people
think
are
code
reviews
in
this
case
code
changes
is
not
there's
no
sort
of
con
conflict
about
what
this.
A
A
Too,
that's
how
I
always
refer
to
it,
because
that's
what
it
is,
so
I
don't
I
have.
I
have
argued
against
changing
the
names
of
things
before
so
that
we
have
again
just
communicate
to
people
who
are
new
to
chaos
or
have
started
using
chaos
metrics
some
consistency
that
we're
not
changing
what
we
call
things
all
the
time,
because
we're
supposed
to
do
the
opposite:
we're
supposed
to
be
giving
people
a
standard,
ontology
or
taxonomy
for
communicating
about
these
things
and
what
these
things
mean.
E
E
Right
and
then
my
other,
my
other
thought
on
this
is
we're
still
in
this
phase,
before
widespread
adoption
or
widespread
use.
So
if
there
was
a
time
to
change
and
really
get
this
language
correct.
A
E
A
E
E
So
I've
been
in
this
working
group
almost
since
the
beginning,
you've
been
in
this
working
group
since
almost
since
the
beginning,
I
walked
up
and
and
both
of.
C
And
I
see
both
of
you
have
committed
in
that
document
on
the
github.
G
A
But
chances
are,
there
was
another
document,
since
this
just
starts
in
january
end
of
january.
2019.
chances
are
there's
when
we
did
reorganize
this
repository
a
lot
so
somewhere
in
the
olden
times
there
was
a
commits
document
as
well.
A
What
my
question
was
actually
it's:
it's
essentially
that
they
are
grouped
in
a
change
request
and
the
change
requests
in
practice
are
for
mature,
open
slurs
projects.
How
all
of
the
work
is
done.
There
are
not
many
pull
requests
or
change
requests
that
occur
or
not.
That
many
commits
that
really
get
implemented
outside
of
a
change
request,
but
there
are
some
right,
and
so
the
commits
alone
doesn't
the
commits,
don't
give
us
a
picture
of
the
way
that
work
is
being
done.
B
E
So
it
would
be
the
it
would
be
the
most
important
part
of
if
it
was
an
aggregate
in
there.
This
would
be
the
most
important
part
of
that.
Aggregator
would
be
very
significant
right
and
the,
and
to
what
sean
just
said,
the
rest
of
it
would
actually
kind
of
be
a
little
moot.
We
might
not
be
as
interested
as
as
a
matter
of
fact,
the
way.
The
way
you
described
it
code
changes
commits
if
we're
just
talking
about
commits
in
general.
E
A
Into
putting
up
for
it
could
be
useful
for
understanding,
individual
developer
or
or
category
of
developer
practices,
because
when
I
do
a
change
request,
that
is
the
accumulation
of
all
of
the
commits
I've
made
locally
before
I've
pushed
to
the
repository,
perhaps
or
before.
I've
issued
my
change
request
and
there
are
different
practices.
I
tend
to
commit
a
lot
just
so
that
I
can
go
back
and
return
to
a
previous
version.
A
Other
developers
may
not
commit
until
they've
finished
like
the
weeks
of
work
a
week
of
work,
so
I
think
there's
a
little
bit
of
individual
developer
practice.
That's
revealed
by
the
commits
themselves
and
not
by
the
change
request,
commits
the
change
request
commits,
I
think,
give
you
a
repository
level
view
and
the
commits
the
commits.
How
many
commits
are
happening
outside
of
change
requests
is
an
interesting
question.
A
If
it's
an
aggregator,
do
we
have
the
metric
change
request,
commits
and
simply
use
that
to
point
back
to
code
changes,
parentheses
or
whatever
commits
or
just
commits,
as
an
aggregation
of
how
code
is
brought
into
the
main
branch
of
a.
E
A
I
do
want
to,
I
guess:
I
want
to
change
the
name
either,
and
I
and
I
don't.
I
don't-
have
strong
I've
been
a
philosophical
reasons
for
not
wanting
to
change
it
entirely
but
just
to
add
commits-
and
I
have
other
parts
of
me
that
are
pragmatic,
so
the
to
change
it
all
to
commits
means
that
we
have
to
change
it
to
change
a
lot
of
of
the
language
on
every
sentence
in
this
document.
Right
to
add
parentheses
commits
or
colon
commits
and
parentheses
commits
is
probably
more
clear
because
code
changes,
colon
commits
implies.
E
A
The
process
right,
yeah
yeah,
commits
existed
before
change
requests,
and
so
I
I
suppose
what
I
would
suggest
is
we
make
so
this
when
we
make
a
change,
if
we
make
it
parentheses
commits,
then
that's
a
change
to
a
published
metric
is
the
like.
It
was
like
me,
I
would
just
edit
this
document.
A
Add
parentheses
commits
and
and
commit
it,
but
then
we
would
have
to
place
it
under
review
and
if
I,
if
we
did
that
right
here,
then
the
next
time
you
run
a
publication
of
metrics
which
might
be
before
the
next
release.
It
would
appear
so
does
this
this
does
this
change
go
back
under
review,
then?
Presumably
yes,
and
so
what
is
the
right
way
to
put
this
change
back
under
review.
E
So
I
I
think
I
think
we'd
have,
to
put
it
under
a
view
for
the
name
change
itself
and
if
that
goes
through,
then
we
would
have
to
then
we
would
go
and
we
would
edit
the
document
to
accommodate
the
name
change
so
perhaps
so
alter
alternately.
We
could
change
the
name
and
no
I'm
not
going
to
change.
E
I
think
I
agree
with
you.
The
problem
is
this:
this
will
have
this
will
be.
There
will
be
discussion
and
ultimate
like
if
we
say
we
want
to
change
this,
to
commits
right
now,
the
odds
of
it
actually,
the
odds
of
it
changing
to
commits.
Aren't
that
good,
because
it's
going
to
go
through
review
and
it'll
end
up
being.
A
A
Yeah
and
actually
this
reference,
we've
eliminated
the
reference
implementations
under
this
working
group
just
because
they
were
too
hard
to
maintain.
E
I
wonder
if
commit
code
changes
in
parentheses
would
be
more
accurate.
E
A
A
I
think
I
think
the
thing
the
question
for
the
general
meeting
is
when
we
want
to
change
the
name
of
a
metric
to
create
more
clarity.
What
practice
do
we
recommend
for
doing
that?
So
it's
I
mean,
and
it
might
not
there's
not
a
standard
answer,
because
in
cases
where
it
causes
confusion
to
have
like
reviews,
then
we
had
to
change
the
whole
name
in
cases
where
it's
not
causing
confusion,
but
it's
just
a
little
too
ambiguous
because
we
all
think
about
commits.
A
But
our
metric
is
cone
changes
and
we
just
want
to
parenthetically
state
that
it's
commits,
and
then
you
know
like
strikeout,
and
here
I
did.
I
struck
out
this
reference
implementation
which
no
longer
exists.
A
And
we
can
probably
add
some
updated
visuals
and
there's
things
there's
other
small
updates
we
can
make
to
the
metric
if
we're
going
to
put
it
under
review
as
well,
but
I'd
be
satisfied
with
just
adding
parenthetically
commits
and
then
getting
rid
of
the
reference
to
a
reference.
Implementation
that
no
longer
exists
exists.
E
I
have
actually
often
wondered
if
we
could
create
a
process
to
review
some
of
these
metrics
after
they've
been
released
for
a
period
of
time,
because
this
one
is
out
of
date
and
and
does
does
need
some
attention.
E
No,
I
just
like
that.
The
we're
not
doing
the
the
what
was
the
down
down
below
the
yeah
yeah
yeah.
E
A
It
was
under
implementations,
I'm
pretty
sure
we
got
rid
of
the
implementations
directory.
Yeah
we'd
have
because
it
was
again.
It
was
way
too
hard
to
keep
those
so
that
you
could
download
the
jupiter
notebook
and
still
run
it
really
mostly
because
they
relied
on
data
and
library.
We
had
a
library,
dependency.
E
A
E
No,
no,
not
me
not
anymore,
so
the
the
first,
the
first
two
reviews
we
did
every
time
the
metrics
were
released,
every
metric
went
to
the
review
process,
so
every
single
review
this
metric
would
have
been
reviewed
again.
E
Okay,
however,
obviously,
that's
no
longer
practical.
We've
changed
it
yeah.
So
the
only
metrics
that
go
on
when
we
change
to
the
continuous
review
process,
the
only
metrics
that
go
under
review
are
metrics
that
are
that
are
being
released.
So
there
is
no
process
currently
to
review
metrics
that
have
been
released
prior,
and
that
is
something
I
think
we
should
think
about
just
when
it
reaches
a
like.
I
said
when
it
reaches
a
certain
point.
E
You
know-
and
this
is
and
by
the
way,
I'm
I'm
sidetracking
us
completely,
because
this
isn't
what
we're
talking.
No.
C
A
C
Thing
because
a
similar
situation
happened
in
the
value
group
also
because
there
was
a
need
to
revise
one
of
the
metric
so
having
a
proper
like
outline
of
how
to
do
a
revision
of
an
already
released
battery
is
an
important
aspect.
I
think.
C
B
Put
both
of
those
issues
on
the
agenda
for
the
next
meeting,
the
spring
cleaning
issue
and
the
re
putting
a
continuous
release
under
review
before
it
goes
into
continuous
release,
changes.
A
Like
quite
and
really
the
like
things
like
adding
a
parenthesis
to
a
name
like
is
there,
we
probably
want
to
put
it
under
community
reviews
so
that
we
don't
appear
yeah
like
we're
taking
over
and
not
like
doing
things
without
community
review.
I
don't
want
to
create
that
impression.
Ever
yeah.
E
Yeah,
I
think,
right
now,
let's
just
treat
that
as
a
yeah
change
it
to
change
it
to
community
review
slide
over
here,
but
the
the
important
the
important
thing
that
we
came
to
is
that
it
is
a
separate
metric
from
change
request
commits,
so
we
can
work
on
change
request
commits
we
just
have.
E
And
then,
additionally,
we
want
to
reference
the
code,
change
files
and
code
change
lines
as
metrics
in
the
change
request
commits.
So
when
we
talk
about
the
when
we
talk
about
what
those
commits
can
look
like,
we
need
to
reference
these
two
metrics.
C
F
I
think
I
think
so
like
leaving
code
changes,
files
and.
E
C
E
D
E
E
We
can
count,
we
can
count.
Those
change
request
commits.
However,
those
other
metrics
can
be
used
to
describe
the
describe.
These
change
request
commits
right,
so
not
real.
I
wouldn't
call
it
a.
I
don't
think
it's
a.
What
do
we
call
the?
I
don't
think
it's
an
umbrella
or
not
an
umbrella
metric.
What's
the?
I
think
this
is
still
an
atomic
metric
yeah.
It
is.
C
A
So
I
I
added
a
basically
in
the
link
to
metric
issue.
I
put
a
note,
release
metric
and
proposed
change
to
the
google
doc,
so
that
I
mean
that
seems
useful
to
have
both
of
them
in
there.
G
E
Clean
up
the
language
a
little
bit
more,
do
you
think
proposed
language.
A
Post
change
march
21
so
to
actually
do
more
editing
on
code
changes
to
see
if
there
are
other
things
that
we
want
to
update.
E
Yeah,
I
think
that
there
are
two
things
one
we
need
to.
We
need
to
make
sure
that
it
is
differentiated
from
change
request
commits.
I
think
it
clearly
is.
There's
there's
no
mention
of
change
requests
in
here.
I
don't
think
okay,
but
we
so
we
could.
We
could
also.
So
we
could
also
reference
change
request
commits
in
here
as
a
you
know,
an
example
of
code,
so
that
would
almost
be.
A
Another
heading
of
related
metrics-
and
I
think,
we've
put
that
in
in
some
of
our
metrics.
If
you
I
feel
like
common,
has
done
that
has
specific,
explicitly
referenced
other
metrics
that
are
aggregated
or
used
or
like
that.
I
can't
remember
there
was
one
in
common
that
they
they
made
and
then
there
were
some
specific
implementations
of
it
in
evolution
and
we
referenced
the
common
metric.
E
C
A
E
And
then
add
the
add,
the
the
markdown
brackets
so
that
we
can.
We
can
add
the
url
link
to
this
when
yep
very
good.
E
C
E
C
Is
just
there's
just
this:
is
this.
G
A
Yeah
here,
the
type
of
it's
added
or
move
and
white
space
are
the
two
things
that
both
grim
or
lab
and
auger
measure.
Okay,
yep.
G
A
We
are
at
the
end
time,
so
I
am
going
to
say
I'll
put
this
on
the
agenda
for
discussion
in
the
next
meeting
and
thank
you
all
for
good
discussion
this
morning
and
talk
to
you
soon.