►
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
Does
have
a
link
to
the
meetings?
Doc
wait
a
minute,
I'm
in
the
wrong.
A
A
Place
all
right
so
january,
11th,
please
go
ahead
and
she's
bought
grammarly
over
the
break.
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
work
on
this
change
request
commits
metric.
A
If,
if
I
go
to
our
let's
just
check
and
see
if
we
have
any
open
pull
requests,
okay,
that's
just
the
change
requests
and
issues
reaction,
one
that
we
have
discussed
and
need
to
revisit,
and
then,
let's
see
I
know,
matt
was
planning
to
kevin.
Do
you
know
if
matt
cleaned
up
the
spreadsheet.
D
I
do
not
know
I
I
haven't.
I
haven't
chatted.
A
A
Change
request
commits
all
right,
so
this
is
the
one
that
we
are
in
planning
to
work
on
today.
A
D
E
Been
it's.
A
Yeah,
that's
a
good
idea,
I
think,
and
what
better
place
to
go
than
chaos.community
and
metrics.
D
D
Would
like
to
remind
the
evolution
working
group
that
we
are
also
taking
this
year
to
clean
up?
Oh
sorry,
to
clean
stuff.
B
A
D
A
So
we
can't,
we
can't
do
that
collaboratively.
D
So
yeah
I'm
wondering
if
we
should,
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
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
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
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,
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
Yes,
yeah.
That
makes
sense
so.
A
E
Yeah
we
could
like.
D
Yeah
yeah,
I
don't,
I
don't
think
we
need
to
move
them
to
google
docs,
but
we
may
want
to
have
we
may
want
to.
We
could
maybe
go
through
the
checklist
together.
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
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
that
might
be
a
decent
process.
E
D
Right
so
then,
if
we
do,
if
we
do
one
of
these
a
meeting,
that'll
that'll
that'll
move
us
through
them.
I
suppose.
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
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
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
D
A
All
right,
so
I
dramatically
edit
markdown.
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,
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
Yeah
and
then
so,
maybe
we
we
make
a
metrics,
we
make.
We
make
a
metrics
checklist
issue
for
each
of
these
as
we
go
through
and
then
in
that
issue
we
also
collect
notes
on
what
needs
to
be
edited,
and
then
we
assign
the
and
when
then
we
assign
the
edit
to
someone.
A
So
if
we
follow
the
release
guidelines
for
ones
that
don't
require
that
are
just
grammar
spelling
reference
updates
yeah,
you
know
anything
that
falls
into
this
category
three.
I
don't
think
we
need
to
follow
that
full
process
for
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
So,
but
we,
but
we
do
kind
of
need
to
have
kind
of
a
formalized
way
of
deciding
whether
or
not
it
is
it.
It
does
fall
into
that
that
level
three
that
doesn't
need.
So
we
do
kind
of
need
that
formal
way
of
saying
hey
this
actually
does
need
to
go
to
review.
No.
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
it
doesn't,
but
it
needs
an
edit
who's
gonna.
Do
it
and
we'll
assign
it
to
someone
from
there.
F
And
we
also
have
things
like
dei
and
personal
information
to
look
at
as
well
right.
That
would
go
in
that
in
that
checklist.
D
D
A
A
D
So
I
think
that
so
the
the
I
think
they're
the
same,
and
basically
it's
just
a
it's
a
statement
that
says
you
know.
Sometimes
privacy
is
a
concern.
Hey
check
out
this
document
that
we
created
and
it
and
I
believe
that
goes
in
the
it
might
go
in
the
input
at
the
top
of
the
implementation
section.
D
D
Okay
yeah.
I
like
I
actually
like
that,
like
that,
maybe
at
the
bottom
of
at
the
bottom
of
the
document
right
after
right,
after
is
what
this
contributor's
the
last
thing.
D
Yeah
a
last
a
last
reviewed
date,
or
maybe
we
call
it
something
else,
rather
than
reviewed
so
to
encompass
the
fact
that
it's
not
just
part
of
the
metrics
release
review
process.
But
it's
part
of
a
reoccurring
review
process.
F
I
think
that
would
be
also
very
helpful
for
people
using
these
metrics
just
to
be.
You
know
aware
that
it's
a
recent
metric
and
that
we're
you
know
it's
not
just
like
some
old
stale
document.
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
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
And
just
create
a
just,
create
an
issue
and
anything
that
you
see
in
the
metric.
That
needs
to
be
edited,
just
add
it
to
the
issue
and
just
kind
of
see
how
that
works.
That
way,
that
way,
we
have
a
a
few
pairs
of
eyes
on
the
review.
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.
A
If
well
it
the
more
work
that
it
adds,
I
think
that
armstrong
and
I
are
seeing
are
the
administration
of
an
issue
in
each
case
and.
D
Yeah,
I
agree
that
that
could
be
a
little
burdens
burdensome.
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
to
review.
D
D
So
we
just
assign
someone
to
do
the
pr.
Then
they
just
do
those
three
things
and
then
we're
good
right.
If,
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
D
Okay,
if
you,
if
you
both,
feel
strongly
about
it,
I
won't,
I
won't
argue
further.
Okay,.
A
I
just
it
just,
I
think,
is
going
we'll,
find
the
process
flows
more
smoothly
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
Just
looking
for
all
right,
I
guess
I'll
look
at
evolution.
E
D
And
one
of
the
metrics
metrics
candidate
release,
so
your
contribution
attribution
should
have
it.
D
All
right
there
we
go
so
content,
quality
and
technical
requirements
are
the
are
the
parts
that
that
we
would
pull
out.
We
don't
need
that
top
part.
Okay,.
D
And
then
maybe
you
want
to
add
the
the
stuff
from
the
at
the
top,
where
you,
I
think
you
do.
You
mentioned.
A
D
So
for
the
the
message
in
the
markdown
file,
so
that
only
that
the
technical
requirements
that
first
one
that
only
needs
to
be
done
if
the
metric
is
being
sent
through
the
review
process
right.
So
if
it's
not
part
of
the.
D
That
decision
process
of
is
this
going
to
be
a
metrics
review,
or
is
this
just
going
to
be
an
edit?
D
D
A
G
D
D
I
don't
understand
the
handbook,
yes,
so.
D
And
then
for
that
and
then
add
some
language
to
that,
the
technical,
the
technical
checklist
down
at
the
bottom?
Okay,
if,
if
necessary,
for
that
top
one
message
in
the
markdown
yeah,
if
necessary,.
D
So
we
we
need
absolute
links
for
images.
That's
second
check
marks,
so
those
do
need
to
be
absolute
links.
A
D
That
one
has
been
a
an
ongoing
headache
for
me.
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.
D
Okay,
do
we
want
to
real
quick
decide
what
we're
going
to
do
for
the
the
agenda
for
the
next
meeting.
A
A
I
am,
I
am
happy
to
take
an
assignment
to
review
one
of
the
metrics
before
next
meeting.
A
D
A
A
Later
I
laid
it
out,
I
laid
it
out
so
that
four
weeks
like
so
you
have
not
next
meeting
you
don't
have
to
show
up
with
it,
but
the
meeting
after
that
would
be
sort
of
the
timing,
so
not
okay.
So
far,.
C
A
I
have
the
four
week
window.
Two
weeks,
of
course,
will
be
tough
for
me
because
of
my
semester
starts
next
week.
Okay,
do
we
wanna.
D
E
D
And
since
I'm,
since
I'm
making
that
statement,
I
suppose
I
could
volunteer
to
take
the
one
in
two
weeks.
A
D
D
D
So
just
set
the
you
know,
we
just
set
the
agenda
then
so
review.
D
So
next
next
session
we
will
review
change
requests
and
then
I
suppose
we
can
also
we
can
work
on
change
request
commits.
A
We
were
gonna
review,
we're
gonna,
review
change,
request,
commits
and
then
change
request
reviews.
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.
D
And
that
that
would
be,
I
think,
that's
gonna,
be
that'll,
be
a
concern
when
we
are
reviewing
these
existing
metrics
as
well
correct.
So.
C
A
All
right,
I
think
we
got
a
plan,
I'm
pretty
happy
with
what
we
got
accomplished
here
and
I
think
it'll
be
helpful
to
share
it
with
the
chaos
community.