►
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
um
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,
um
but
perhaps
we
did
not
um
was
it
commits
or
comments?
Am
I
reading
comments
is
what
I
wrote
check.
Our
goals
commits
is,
what's
there
and
um
there's
some?
Is
somebody
logged
in
as
the
chaos
user,
where
they
can
create
a
document
in
a
chaos
folder
for
us?
um
I.
A
C
A
D
B
E
A
A
A
Could
be
lines
of
code
lines
of
code
yeah
I
mean
that
would
be
the
only
measure
of
a
commit
size.
um
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
um
number
of
file.
I
think
number
of
file.
You
know
how
many
files
are
included.
A
A
A
A
A
A
G
E
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
uh
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
uh
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.
A
B
C
E
C
E
A
C
A
C
D
E
The
lines
of
code
is
just
uh
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
uh
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
uh
and
just
code
changes.
C
C
E
E
A
A
E
A
A
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
E
E
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,
um
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,
uh
ontology
or
taxonomy
for
communicating
about
these
things
and
what
these
things
mean.
E
E
A
E
A
E
G
A
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,
um
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
uh
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.
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
um
and
parentheses
commits
is
probably
more
clear
because
code
changes,
colon
commits
implies.
A
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,
um
and
so
what
is
the
right
way
to
put
this
change
back
under
review.
E
uh
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
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,
um
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
D
A
And
we
can
probably
add
some
updated
visuals
and
there's
things
there's
other
small
uh
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
uh
adding
parenthetically
commits
and
then
getting
rid
of
the
reference
to
a
reference.
Implementation
that
no
longer
exists
exists.
E
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
uh
data
and
library.
We
had
a
library,
dependency.
E
A
E
Okay,
however,
uh
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
uh
just
when
it
reaches
a
like.
I
said
when
it
reaches
a
certain
point.
E
C
A
C
C
A
E
C
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.
uh
What
do
we
call
the?
uh
I
don't
think
it's
an
umbrella
or
not
an
umbrella
metric.
What's
the?
uh
I
think
this
is
still
an
atomic
metric
yeah.
It
is.
C
A
G
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
um
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.