►
From YouTube: CHAOSS Evolution Working Group 1/11/22
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
B
A
A
A
This
is
coming
back
to
me,
looks
like
the
next
metric
to
work
on.
We
identified
as
the
change
request,
commits
metric
and
change
request
reviews
I
recall
working
on
in
our
most
recent
meeting
in
november,
but
we
did
not
do
anything.
We
were
going
to
set
that
aside
for
now
and
um
work
on
this
change
request
commits
metric.
A
A
A
D
A
D
D
B
A
D
So
yeah
I'm
wondering
if
we
should,
uh
if
we
should
create
a
issue,
an
issue
for
all
of
the
metrics
that
so
I
mean
we
probably
want
to
keep
track
of
the
metrics
that
we've
gone
through
and
checked
and
edited
I
agree.
So
so,
maybe
uh
some
sort
of
checklist
that
says:
hey
we've
reviewed
this
one.
It
looks:
okay,
hey
we've
reviewed
this
one.
It
needs
attention.
F
D
A
um
I
know
that
there
was
a
process
proposed
for
reviewing
these.
I
I
don't
recall
since
it's
been
a
while,
if
there
was
a
process
defined
for
how
we
edit
or
review
existing
metrics
or
if
there's
a
s,
it
would
make
sense
for
there
to
be
a
status
like
released
and
under
review,
or
something
like
that.
D
F
A
Yeah,
I
mean,
I
think,
this
guidance
in
number
three,
so
the
first
thing
we
saw
under
change
request
um
wherever
that
was
change,
requests
accepted.
The
first
thing
that
we
saw
falls,
I
think,
into
this
category.
Three.
It's
really
the
first
sentence
makes
no
sense,
because
it's
missing
the
actual
name
of
the
metric,
then
I
would
call
that
a
grammar
or
a
spelling
fix,
um
so
it
would
not
yeah.
C
A
Yeah
and
so
maybe
maybe
we
should
step
back
and
I'd,
create
a
list
like
you
suggested
a
minute
ago,
kevin
and
open
an
issue
where
we
have
those
neat
little
check
boxes
that
george
created
for
the
release.
Maybe
you
created
them,
I
don't
know
the
for
the
release
structure
yeah
there
were.
There
were
three
of
us
that
worked
on
that
yeah
and
remember:
there's
like
a
25
item
checklist
for
metrics
release
and
we
could
just
create
a
checkbox
for
each
of
the
metrics
that
we
intend
to
review
this
year.
D
A
D
On
it,
if,
once
once,
that's
once
that's
created,
we
could
just
do
a
each
meeting.
We
could
do
a
read
through
one
of
the
metrics
go
through
the
checklist
uh
check,
everything
off
and
then
we
could
also
make
a
note
of
anything
we
we
identified
in
it.
That
needs
to
be
changed
and
then
from
there
we
could
assign
someone
to
to
do
the
pull
request
fix
that
might
uh
that
might
be
a
decent
process.
E
D
D
So
the
the
checklist
that
we
have
by
the
way
for
the
release
in
general
is
kind
of.
It's
got
two
parts
to
it.
One
is
about
the
release
process
in
general
and
all
the
things
that
need
to
be
ticked,
to
get
through
the
release
process
and
then
the
second
part
of
it
is
actually
about
uh
the
quality
of
the
metric.
So
if
we
are
creating
a
checklist,
we
just
need
to
grab
the
second
part
of
that
existing.
A
D
A
Spacing
markdown
is
usually
a
safe
bet,
and
hopefully
this
I
may
have
to
um
add
dashes
so
that
markdown
doesn't
I
don't
know
if
it'll
treat
this
as
a
line
delimiter
or
not,
but
we'll
find
out.
I
guess
so.
Does
the
check
box
mean
that
we've
reviewed
it
or
that
it
needs
to
be?
The
checker
like
the
check
box
means
that
we,
like
the
presence
of
an
empty
check
box,
suggests
that
we
intend
to
review
it
and
the
presence
of
a
check.
C
A
C
B
C
D
A
A
All
right,
so
I
dramatically
edit
markdown.
um
Do
we
want
to?
How
do
we
want
to
proceed
then?
Because
I
think
this
is
a
good
checklist.
You
know
a
good
set
of
goals
for
2022
is
to
review
these,
um
and
I
mean.
Does
anybody
have
a
thought
on
whether
we
should
move
things
to
mark
down
to
edit
or
if
we
should
do
this,
I
mean
it
sounds
like
kevin.
You
suggested
a
process
through
which
we
remove
review
or
do
pull
requests
and
review
them
on
the
metrics
checklist
each
week.
D
A
So
if
we
follow
the
release
guidelines
for
ones
that
don't
require
that
are
just
grammar
spelling
um
reference
updates
yeah,
you
know
anything
that
falls
into
this
category
three.
I
don't
think
we
need
to
follow
that
full
process
for
um
that
we
can
just
do
a
pull
request
edit
the
markdown,
and
then,
if
does
it,
still
work
in
a
way
where,
once
we've
edited
the
markdown,
the
website
just
pulls
it
in.
D
F
F
D
And
then,
and
then
when
we
go,
and
we
look
at
each
of
these
individually,
we'll
create
a
separate
issue,
that'll
run
through
all
of
that'll
kind
of
discuss.
All
of
this
stuff
that
we're
talking
about.
Okay,
is
the
quality.
Good.
Is
the
terminology
good?
Does
it
need
to
go
to
review
uh
it
doesn't,
but
it
needs
an
edit
who's
gonna.
Do
it
and
we'll
assign
it
to
someone
from
there.
F
D
A
A
D
So
I
think
that
so
the
the
uh
I
think
they're
the
same,
and
uh
basically
it's
just
a
it's
a
statement
that
says
uh
you
know.
Sometimes
privacy
is
a
concern.
Hey
check
out
this
document
that
we
created
uh
and
it
and
I
believe
that
goes
in
the
it
might
go
in
the
input
at
the
top
of
the
implementation
section.
D
D
D
F
D
A
I
I
think
this
is
this
is
like
a
good
setting
the
stage
activity
and
I
think,
if,
if
we
wanted
to,
we
could
identify,
maybe
each
each
of
us
could
claim
a
metric
that
we're
going
to
review
in
the
in
the
next
month,
so
not
necessarily
by
next
meeting,
but
maybe
for
two
meetings
from
now
or
four
weeks
from
now,
we've
each
reviewed
one
I
mean
at
that
pace.
We
should
be
able
to
get
through
these
all.
A
I
think
it's
hard
to
do
it
collaboratively
because
we
would
have
to
take
it
into
a
google
document
to
do
that.
Well,
not
edit,
it
uh
just
review
it
collaborate.
I
definitely
think.
Yes,
I
think
once
the
changes
are
proposed,
it
would
take
the
form
of
a
pull
request
and
those
would
be
reviewed
in
a
regular
meeting
would
be
my
thought
and
we
could
determine
then,
if
it's
just
grammar
and
clarity
or
if
there's
any
you
know
material,
meaning,
that's
been
altered.
D
Thinking
I
was
thinking
a
little
bit
more
on
the
front
end.
I
think
you
were
you're
you're
talking
more
about
a
review
on
the
back
end.
I
was
talking
about
more
of
a
review
on
the
front
end
where,
let's
just
let's
just
open
change,
requests,
real
quick,
do
a
read
through
and
point
out
anything
that
we
see.
D
A
D
So
what's
going
to
happen,
is
you'll
go
through
and
do
the
review
and
you'll
fix
half
of
the
things
and
then
it'll
it'll
come
to
the
meeting
and
we'll
look
through
it
and
then
I'll
see
I'll
see
a
few
more
things
and
sean
will
see
a
few
more
things
and
then
it'll
have
to
go
back
to
be
edited
again
more
than
likely,
so
I'm
not
sure
that
it
adds
more
work.
It
just
moves
the
work
around
to
different
places.
D
Yeah,
I
agree
that
that
could
be
a
little
burdens
burdensome.
uh
However,
if
the,
if
we
do
that,
if
we,
if
we
do
that
on
the
front
end,
we
can
look
at
and
say
hey
this.
This
metric
just
has
a
few
minor
issues.
These
are
the
these
are
the
small
things
that
need
to
be
done
and
hey.
We
don't
need
to
send
this
to
uh
to
review.
D
D
uh
So
we
just
assign
someone
to
do
the
pr.
Then
they
just
do
those
three
things
and
then
we're
good
right.
If,
uh
if
we're
individually
looking
at
it,
then
that
that
individual
has
to
determine
you
know,
am
I
doing
a
really
full
scale
edit
on
this
entire
document?
Or
am
I
just
changing
some
minor
things?
D
A
C
A
I
just
um
it
just,
I
think,
is
going
we'll,
find
the
process
flows
more
smoothly
um
and
can
be
executed
more
asynchronously
as
well,
which
which
I
think
will
make
it
easier
for
multiple
people
who
may
or
may
not
even
be
part
of
this
working
group
meetings.
This
working
groups
meetings
to
participate.
E
E
D
D
A
D
D
A
G
D
D
D
A
D
My
understanding
is,
you
use
you
use
relative
links
when
the
images
and
the
and
the
other
parts
of
the
website
are
on
the
same
server
and
you
use
absolute
links
when
the
images
are
on
a
different
server
and
technically,
what
we're
doing
is
we're
doing
it
on
a
different
server
for
the
website.
However,
when
the
when
the
github
documents
are
being
created,
obviously
that's
on
the
same
server
right.
D
E
A
B
A
Because
I
think
this
actually,
what
we've
kind
of
punched
out
here
is
sort
of
a
template.
I
think
other
working
groups
can
follow
honestly
yeah,
I
agree
like
this
is
none
of
this
is
rocket
science
and
we
just
took
the
time
to
think
through
it,
and
I
think
it's
useful
for
other
working
groups
to
have
this
as
a
thing.
A
D
A
A
C
A
D
E
A
D
D
A
We
were
gonna
review,
we're
gonna,
review
change,
request,
commits
and
then
change
request
reviews.
um
Those
are
the
and
I
believe,
if
memory
serves
the
change
request.
Reviews
is
the
one
we
spent
a
good
deal
of
time
on
in
the
last
meeting
and
we
were
setting
it
yeah.
I
think
we
were
done
setting
it
aside
for
a
little
bit.
D
Oh
for
language,
consistency
that
that's
right.
I
think
we
were
going
to
go
and
go
and
look
at
a
couple
of
the
other
change
request,
metrics
and
then
kind
of
come
back
and
and
look
at
this
one
again,
because
there
there's
probably
going
to
be
some
linking
so
we'll
need
to
we'll
need
to
link
them
together,
possibly
through
other
metrics,
and
we
need
to
make
sure
that
terminology
is
all
the
same.
Okay,
yeah.