►
From YouTube: CHAOSS Evolution Working Group 4-14-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
C
Hello
yeah,
it's
I
have
my
chaos
community
doing
the
recording
in
my
internal
computer,
but
I
thought
I
would
spend
a
little
time
outside
at
the
very
start
of
the
meeting.
C
Range
of
nice
weather
it.
It
goes
from
cold
to
like
nice
and
then
all
of
a
sudden.
It's
like
really
humid
and
you
can't
be
outside
so
trying
to
make
the
most
of
the
opportunity
that
I
have.
B
C
C
A
C
We
could
start
to
talk
about
that
because
I'll
share
my
screen,
it
was,
it
was
a
pretty
good
pull
request.
Actually
I
went
through
it
and
georg
had
there
were
just
a
couple.
C
What
I
would
characterize
as
some
tactical
issues
related
to
it
like
colons
in
certain
places
and
dashes
and
certain
places
and
seemed
pretty
easy
to
pick
up
and
the
the
fact
that
it
was
really
easy
to
pick
up
was
it
made
me
think
like
it
would
be
a
really
easy
one
to
like
just
resolve
you
know,
but
and-
and
it
was
a
google
summer
of
code
student,
I
didn't
look
to
see
if
they
applied
ultimately,
but
often
they
have
an
incentive
to
make
the
changes
requested.
C
C
E
C
Actually,
I
would
actually
like
to
hold
off
on
that.
Okay,
because
you.
A
E
To
do
it
yeah
the
minute,
the
minute
we
merge,
this
it'll
it'll
break
every
evolution
metric
on
the
website.
Oh
I'm
is
that
what
happened
with
some
of
our
other
ones
is
that
why
that
oh,
yeah
yep?
That's?
Why
we've
been
dealing
with
that
all
right,
so
common
with
common?
We
actually
got
ahead
of
it.
C
C
This
is
a
new
thing,
so
yeah.
What
should
I
put
for
the?
C
Is
that
yash?
I
think
it
is
yeah.
I
think
yash
has
been
our
big
cleanup
guy
yeah
and
he
he
made
a
proposal.
E
Okay,
so
I'm
I
am
going
to
merge
this
within
either
later
today
or
tomorrow.
It's
just
I
I
have
to
there's
some
stuff
with
my
mother-in-law.
I
have
to
go.
Take
her
to
the
doctor.
I'm
not
gonna
have
time
to.
C
E
Yeah,
that's
a
lot
of
work.
I
yeah
it
was
a
couple
years
back
before
we
even
got
crazy.
I
had
tried
to
do
some
repo
standardization
and
it
was
a
ton
of
work
and
we
kind
of
got
some
pushback
from
the
other
working
groups.
C
So
yeah,
I
think,
we've
reached,
I
think,
there's
an
inertial
point
in
a
project
where,
like
at
first
standardization
is
like
when
you're
exploring
it's
its
standards
are
hard
to
really
know
what
they
should
be
and
I
think,
as
we've
matured,
we've
started
to
all
understand
what
what
standards
are
useful.
I
think
that's
a
fundamental
just
evolution
of
of
of
the
work
that
we're
doing.
E
C
E
I
think
we
anticipated,
I
think,
just
moving
moving
towards
the
fix
was
it
was
harder
two
years
ago
than
it
than
it
was
now.
G
C
F
Maybe
we
propose
this
as
a
metric
to
common
to
keep
whether,
like
open
source
communities,
are
keeping
a
standard
formatting
for
their
project
or
not.
E
Either
way,
I
am
glad
that
I'm
glad
that
we
are
doing
it
now
because
it
makes
it.
You
know
it's
an
interdependency
thing
right,
so
we
we're
using.
E
The
you
know,
metrics,
are
we
we
rely
on
when
once
we
start
connecting
metrics
together
to
create
dashboards
and
things
of
that
nature,
we
need.
We
need
standard
ways
of
of.
B
B
C
C
If
we
go
back
and
look
at
the
actual
pull
request
list,
we
will
see
that
we
only
have
three
remaining
so
there's
a
couple
from
georg
from
one
from
georg
from
last
fall
and
then
a
readme
to
add
a
second
requirements
text
that
I
think
is
going
to
be
closed
because
it
was
related
to
the
jupiter
notebooks
we
removed
yeah.
But
I
just
I
wanted
to
get
some
verification
from
the
poll
requester.
C
First,
so
really,
there's
there's
this
one.
We're
gonna
merge
shortly
and
then
I
need
to
correspond
with
georg,
but
I
feel
there
are.
There
were
like
lots
and
lots
of
pull
requests
that
were
old
and
outdated
and
not
relevant
anymore.
C
So
I
I
went
ahead
and
just
close
them
out
so
item
two
on
the
agenda
is
also
taken
care
of.
G
C
So
that's
done
and
then
the
next
thing
we
have
is
to
start
work
on
change.
Request
commits,
and
I.
C
C
C
No,
so
there
were
some
yeah
commits
so
we're
calling
it
commits,
but
we
don't
call
other
things
commits.
So
if
we,
since
they
are
change,
request
commits
that's
literally
what
they
are,
we
have
to
there's
some
kind
of
thing
we
have
to
do
with
all
the
code.
Changes
metrics
that
that
sort
of
is
a
cascading
effect,
and
I
didn't
land-
I
don't
I
don't
know.
Does
anybody
recall
that
we
landed
on
a
clear
path
for
that
particular
case.
E
E
C
C
E
C
E
The
only
part
of
that
discussion
that
we
don't
have
resolution
to
was
the
the
issue
that
I
had
brought
up,
which
was
the
some
sort
of
timer
that
would
basically
make
sure
that
metrics
that
have
been
released
at
some
point
are
looked
at
and
reviewed
again
right.
You
know
whether
it's
after
four
years
or
after
two
years.
E
And
I
think
that
was
part
of
the
conversation.
I
put
the
link
in
the
in
the
chat
by
the
way,
and
I
have
to
I'm-
I'm
gonna
have
to
leave
here
in
15
minutes
by
the
way.
B
23Rd,
I
think,
23rd
and
I
see
I
think
you
can
use
the
api
to
the
github
api
to
like
reopen
pull
requests.
So
maybe
there's
a
you
know
something
we
can
run
every
month
or
something
that
would
look
and
see
like
two
years
ago.
When
that
pull
request,
or
you
know
what
I'm
you
know,
I'm
saying
like
one
of
the
when
we
merge
a
metric
like
we
could
maybe
reopen
it
automatically
through
the
api
every
two
years
and
that
would
at
least
like
pop
it
back
up
to
the
surface.
E
E
E
But
the
but
the
information
that
sean
was
asking
for.
Oh,
what's
that.
E
So,
whenever
there's
language
or
terminology
that
would
affect
other
metric
references,
it
needs
to
go
to
review
changing
the
name
of
the
metric.
It
needs
to
go
to
review
any
changes
that
go
beyond
grammar
or
spelling
fixes
in
sections
question
definition:
objectives:
implementation:
it
needs
to
go
good
review
things
that
don't
require
review,
grammar
or
spelling
fixes
updates
to
sections
references
and
contributors.
B
Yeah,
I
feel
like
you
could,
if
it's
you
know
we're
changing
a
reference
to
something,
because
I
think
that
was
a
big
deal
like.
I
wonder
if
we
could
do
like
a
find
a
find
like
not
a
final
replace
but
like
a
find
and
reopen
the
prs
of
the
can
we
can
we
do
that.
I
mean
that
could
be
a
project
for
somebody,
someone
just
search
through
the
metrics.
You
know
even
the
pdf
and
like
identify
where
what
metric
it
is,
what
metrics
reference
the
one
that
changed.
E
C
B
Well,
I
was
saying
yeah
yeah
kind
of
I
was
just
trying
to
think
about
how
we
could
automatically
do
it
so
like
if
we
change
yeah.
If
we
change
the
metric
that
would
like
trigger
a
check
like
through
the
through
all
of
our
metrics
to
see,
if
that
name
previous
would,
you
know,
was
referenced
anywhere
so
that
we
could
reopen
those
pr's
and
make
those
changes.
E
Yeah,
I
notice
in
so
in
our
metrics
in
our
metrics
template
there
actually
isn't
a
so
I
mean
through
the
process.
Everything
is
dated,
however,
for
the
metrics
template
itself.
There
is
no
capture
date
for
when
the
metric
was
defined
or
last
edited,
and
that
might
actually
be
something
interesting
to
add
to
the
template,
because
that
that
could
actually
that
could
create
a
basically
a
tag
that
we
could
do.
An
automated
search
for
as.
E
E
E
So
I
know
that
stuff
is,
I
know
that
stuff
is,
is
just
captured
through
the
process
of
working
on
github,
but
there
are
more
explicit
mechanisms
that
we
could
use
to
add.
Add
that,
and
one
of
the
things
we
could
do
is
actually
add
it
to
the
template,
a
a
defined
date
or
a
revised
date
or
and
and
we
we
could
also
actually
we
so
when
we
do
the
release.
Currently,
we
do
create
a
release
tag
so
which
we
could.
We
could
just
automatically
search
for
the
release
tags
as
well.
F
G
E
E
But
that's
just
that's
just
a
text
document
right,
so
we
don't
have
any
sort.
G
E
Like
to
figure
that
out,
we
kind
of
have
to
scrape
it
a
little
bit
or
kind
of
do
a
manual
look
but
there's
once
again
we
could.
We
could
be
more
explicit
about
how
we
do
that
yep
and
and
on
the
release.
When
we
do
the
release
tag,
we
could
actually.
E
We
could
actually
add
some
a
date
tag
and
a
reason,
tag
things
like
things
like
that.
That
would
basically
mark
each
metric
at
that
time.
But
but
the
problem
with
that
is
this
is
that
this
process
stretches
across
all
of
the
work
groups
and
it
adds
it
adds
more
complexity
to
the
release,
which
is.
G
E
Don't
know
that
we
want
to
do
that,
it's
it
might
just
be
better
to
just
you
know,
look
at
the
releases
and
say
you
know
everything
that
was
released
on
release
number
four.
You
know,
2019
04
should
be
reviewed
in
2022
of
that
same
date
or
whatever
right.
E
Yeah
yeah,
I
think
I
think
that's
a
longer.
I
think
that's
a
longer
conversation
and
I
think
it's
one
we
have
to.
We
maybe
do
after
we
after
the
metrics
release
process
is
automated.
E
We
can
go
back
and
we
can
look
and
see
if
we
can
add
any
sort
of
extra
automation
to
it
or
tweak
it
a
little
bit
so
another.
Another
kind
of
related
to
this
thing
that
I've
been
contemplating
lately
is
actually
building
a
database
to
put
these
metrics
in
okay
to
help.
G
G
C
E
And
and
and
part
of
the
part
of
the
discussions
that
we've
been
having
about
displays
and
different
ways
of
kind
of
aggregating,
metrics
and
putting
them
together,
you
know
if
we
have
them
in
a
database,
it's
easier
to
create
those
those
sorting
and
the
sorting
and
filtering
that
that
we
would
want
so
just
something
I've
been
thinking
about
and
something
that
I
was
hoping
that
the
website
migration
would
make
easier
for
us
to
do
so.
E
E
Yeah,
I'm
actually
so
I'm
actually
kind
of
down
on
the
the
glossary,
because
I
I
kind
of
think
that
our
metrics
release,
like
the
when
we
define
metrics,
we're
creating
the
glossary
right.
So
having
a
having
another
document
that
that
points
at
metrics
definitions
and
tells
you
what
terms
means
yeah
seems
it
seems
like
too
much
work
like
if,
but
if
we're
doing
this
correctly,
when
we
define
metrics,
we
should
be
defining
these
terms
right,
just
like
by
defining
a
metric,
we're
defining
the
term.
E
F
Yeah
but
like,
for
example,
that
came
in
the
risk
working
group
that
interdepend
and
she
has
so
many
terms.
Similarly,
other
things
came
across
which
are
part
of
that,
but.
E
F
C
F
F
To
be
defined,
for
so
like
are
we
defining
the
transitive
dependency?
Do
we
have
a
metric
for
transitive
dependency?
Do
we
have
a
metric
for
direct
dependency.
E
So
we
don't
we
don't
yet,
but
yeah.
I
think
we
need
to
right
so,
rather
than
rather
than
creating
a
glossary
to
define
the
term,
I
think
those
are
if
it
needs
to
be
defined.
It
probably
needs
to
have
a
metric
related
to
it,
or
it
needs
to
be
addressed
within
a
metric
just
having
having
a
separate
glossary
document
for
work
that
we're
already
doing
seems
like
extra
work
and
something
that
would
be
really
really
hard
to
maintain.
H
F
It
was
just
suggestions,
or
maybe
oh,
no
yeah,
believe
me,
I'm
not.
No,
no,
I'm
fine
with
it,
but,
like
I
see
the
terms
which
were
not
clear
for
me,
that's
where
I
felt
this
need.
So
maybe
a
better
proposal
is
like:
let's
convert
those
terms
into
a
metric
first
and
then
it'll
be
obvious.
I
think
we
don't
need
any
definition
for
them.
E
Yeah
yeah,
that's
that's
all!
That's
that's!
My
only
point
is
that
well,
like
I
agree
that
a
glossary
would
be
helpful.
I
just
think
that
it's
it's
duplicate,
work
of
something
that
we're
already
doing
so
it
makes
more
sense
to
put
that
energy
into
defining
an
atomic
metric
rather
than
creating
a
glossary,
because
once
we
create
that
glossary,
we
have
to
maintain
that
glossary.
F
A
E
E
C
So
we
we
have
google
summer
of
code
students
this
summer
who
have
applied
to
do
work
on
the
website,
and
one
of
the
things
we
could
do
is
just
sort
of.
Basically,
we
have
a
table
in
auger
that
already
has
all
the
data
related
to
metrics.
C
We
just
don't
keep
it
up
to
date
or
show
it
anymore,
be
like
again,
because
I
said
the
the
act
you
know
getting
the
metrics
in
there,
where
we
put
metrics
how
we
stored
them
just
kept
changing
from
working
group
to
working
group
and
it
became
frankly
impossible
to
keep
up
with.
But
I
don't,
I
think,
we're
in
a
different
place
right
now
and
we
could
store
the
substance
of
all
the
metrics
in
a
in
a
database.
C
E
I
don't
think
that's,
I
don't
think
that's
at
this
summer,
google
summer
of
code
project,
but
I
think
that's
that's
a
maybe
next
summer
google
it
could
be
yeah,
projector,
yeah
or
something
we
do.
Definitely
it's
definitely
something
that
I've
had
on
my
mind.
Lately,
though,.
C
Yeah
as
we
as
we
started
talking
about
the
the
standard
reports,
examples
kind
of
replacing
community
reports,
I
signed
up
to
mentor
one
of
those
students
because
agar
can
automatically
generate
things,
and
so
we
can
make
that
a
regular
occurrence
with
very
little
effort
if
we
automatically
generate
those
basically
the
fundamental
pngs
behind
the
report,
and
then
somebody
can
just
paste
them
into
a
blog
post
yeah,
and
this
would
be
along
the
same
lines
like
it's
pretty
easy
to
get
a
metric
into
a
database.
But
I
agree
it
doesn't?
E
Yeah-
and
it
doesn't,
I
mean,
as
far
as
like
metric
content
goes,
it
doesn't
have
to
be
complete
right.
We
can
just
point
we
can
just
put
urls
in
there
to
point
to
where
it
needs
to
go.
Absolutely
it
can
be.
It
can
kind
of
be
a
higher
level
database
right.
H
C
Yeah,
we
could
even
add
a
we
could
even
add
a
table
to
the
the
the
wordpress
site.
E
Well,
so,
if,
if
we're
building
a
table,
then
I
would
actually
like
to
add
some
dynamic
content
to
the
website
where
metrics
displays
can
be
possibly
put
together
through
some
sort
of
user
selection
process.
Right
where
you
can
right,
you
can
select
collections
of
metrics
that
might
be
important
to
you
or,
but
in
in
this,
it's
probably
not
worth
talking
about
right
now,
but
no,
no.
A
C
Yeah
and
it
comes
up
because
we're
about
to
work
on
a
pull
request
commits
metric
that
will
immediately
force
the
issue.
C
No,
I
mean,
I
don't
think
it's
sidetracked,
because
I
I
don't
think
we
can
discuss
the
metric
that
we're
proposing
without
sort
of
having
a
game
plan,
and
now
we
have
that
so
goody
for
us.
C
Do
we
want
to
with
the,
and
I
only
got
about
seven
minutes
left
today.
Myself.
Do
we
want
to
look
at
the
the
full
request
commits
metric
and
see
where
we're
at
elizabeth
and.
C
D
Oh
okay,
let
me
let
me
take
a
look
at
our.
D
D
B
F
F
I
have
a
issue
with
the
like
question:
what
is
the
pattern?
Pattern
seems
to
probably
just
align
the
whole.
We
have
function
like
we
have
two
questions
rather
than
one
question.
C
So
anomalies,
are
I
basically
listed
two
anomalies?
I
am
happy
to
take
them
out
so
in
a
pull
request
or
commit
a
merge
request.
There's
how
large
is
are
the
commits
in
that
merge
request,
so
each
merge
request
will
have
x
number
of
commits
that
contain
x,
number
of
lines
of
code
changes
and.
C
Commit
sequence
is
sort
of
or
are
this
like?
Are
people
editing
one
file
at
a
time
in
that
order,
frequency
of
changes
in
the
commit
yeah
are
they?
Are
they
making
commits
that
overwrite?
Their
previous
commits
that
kind
of
thing,
and
then
merge
request
patterns
are
simply
really
how
many
commits
are
in
a
merge
request,
yeah,
but.
B
B
C
In
light
of
that
loss,
I
think
we
made
some
good
progress
this
week
in
the
evolution
working
group
and
I've
actually
got
a
pull
request
for
the
handbook,
and
but
we
were
just
supposed
to
wrap
up
because
we
lost
juvenile.
I
have
to
go
yeah,
so,
okay,
I
will
make
you
I'll
make
elizabeth
the
host
and
you
all
can
bid
us
ado,
probably
seconds
after
I
depart
all
right.
Talk
to
you
later
see.