►
From YouTube: CHAOSS Weekly Community Call 3-23-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
Recording
welcome
to
the
chaos
community
call.
I
see
a
few
people
have
joined
us
since
I
first
posted
the
minutes
in
chat,
so
I
will
post
them
one
more
time
if
you
could
add
your
name.
That
would
be
great.
I
am
the
backup
facilitator
in
case
elizabeth
needs
to
take
off
her
daughter
is
in
labor
right
now,
and
she
just
shared
with
those
of
you
who
were
here
and
there
you
go
so
I'm
backing
up
revising
old
metrics
so
that
I'm
just
gonna
jump
right
in
here.
A
A
A
A
So
I'm
going
to
shut
up
and
throw
it
to
the
world
there.
What
do
we?
What
do
we
do?
We
have
any
thoughts
on
what
should
guide
when
a
metric
goes
back
under
community
review.
B
A
And
I,
and-
and
I
I
think
under
that
guide-
adding
some
kind
of
parenthetical
reference
to
the
fact
that
a
code
change
is
in
every
case,
I'm
aware
of
operationalized
with
the
word
commit
votermorelab
calls
it
a
commit.
Auger
calls
it
a
commit.
We
don't
call
it
a
code
change,
we
may
have
a
label,
but
ultimately
it's
a
commitment,
so
it's
labeled
at
the
the
lowest
level
that
way
on
both
pages.
A
I
think,
adding
to
the
name
or
you
know,
alter
maybe
altering
the
name
like
I
said
if
I
was
to
make
a
guide,
I
would
say,
if
we're
altering
the
name
of
the
metric
in
any
way
that
that
is
something
we
would
probably
put
under
review.
D
I'd
like
to
this
is
lucas,
hello
and
good
morning.
Good
morning
I
have
an
idea,
and
that
is
that
there
would
be
sort
of
an
informative
and
potentially
retroactive
notification
of
a
change
so
that
the
working
group
could
continue
without
having
to
stop.
But
the
community
could
comment
and
raise
a
flag
if
there
was
a
need.
A
Chance
yeah,
I'm
here
but
kevin
you
manage
this
process
right
now.
Does
the
idea
of
a
sort
of
retroactive
discussion
period
create
another
path
of
complexity,
for
you
that
you
really.
F
Can
you
describe
what
what
a
retroactive
process
would
look
like.
D
What
I
propose
is
that
when
you
make
a
naming
change.
G
A
D
D
So
let
me
start
that
again.
So
when
you
make
a
naming
change,
the
community
may
have
an
interest
in
participating
in
that
discussion,
but
it's
important
for
the
community
discussion
to
not
slow
down
the
working
group.
So
one
way
to
approach
that
would
be
to
say
that
you
do
a
kind
of
a
retroactive
notification.
D
We
made
this
change
and
are
open
to
are
open
to
community
feedback
on
making
improvements
to
this
naming
change,
for
example,
but
in
the
absence
of
suggestions
and
people
raising
a
flag,
we're
going
to
go
forward
with
what
we've
done,
how
does
that
feel?
As
far
as
a
productive
process?
It
doesn't
slow
you
down.
H
The
one
thing
I
would
add
to
that,
though,
is
a
a
naming
change
is,
is
could
actually
be
a
pretty
drastic
change
for
many
working
groups
in
the
project,
because
it
it
can,
it
can
affect
multiple
metrics
that
have
been
defined
where
we
have
referenced
this
this
other
metric,
but
in
general
I
think
what
you're
describing
fits
very
well
with
our
current
process.
H
I
guess,
as
far
as
a
potential
reason
to
go
through
the
community
review
again,
I
would
actually,
I
would
actually
just
add
age
to
the
the
list.
As
a
metric
gets
older,
the
visualizations
become
out
of
date,
the
the
links
start
to
disappear.
H
Our
general
understanding
of
that
metric
may
have
changed
because
we've
defined
other
metrics.
That,
and
so
I
think,
to
a
degree.
Age
is
a
factor.
A
So
do
we
it
would
that
be
a?
Would
we
call
that
something
different?
Would
that
be
like
the
second
edition
or
the
second
printing
of
a
book
he's
effectively
updating
it,
or
maybe
it's
the
paperback
version
we're
not
changing.
In
that
case,
it
sounds
like
we're,
probably
not
changing
the
taxonomic
substance
of
the
metric,
but
the
like.
For
example,
you
use
the
example
of
visualizations.
I
do
agree,
those
are
going
to
evolve
routinely
and
after
two
or
so
years,
most
visualizations
look
silly
compared
to
what's
available.
H
So
I
know
we
don't
we
don't
have
a
ton.
I
mean
I
guess
we
do
have
a
lot
of
metrics
now,
but
we're
at
some
point
we're
going
to
have
considerably
more
and
one
of
the
one
of
the
things
that
I've
noticed
is
that,
as
we've
been
going
through,
we've
started
to
define
metrics
that
are
very
similar
to
each
other
and
in
those
cases,
we're
having
to
establish
and
move
boundaries.
H
The
boundaries
of
what
those
definitions
are
right,
so
when
we,
when
we
start
talking
about,
for
example,
the
the
time
to
response
on
an
issue,
the
way
we
define
the
that
time
to
response
could
be
related
to
the
the
time
to
close
a
pull
request
or
the
many
other
metrics
for
example.
So
as
we
as
we
define
those
those
boundaries
for
these
metrics,
they
some
of
the
metrics
boundaries,
kind
of
change,
and
I've
noticed
that
the
kind
of
the
some
of
our
our
older
metrics
need
to
be
adjusted.
The
boundaries
of
those.
H
A
It
where
perhaps
there's
a
role
within
the
project
for
someone
to
garden
either
within
a
working
group
or
across
working
groups,
these
kinds
of
consistencies
on
a
routine
basis
to
you
know
if
you're,
if
you're
and
I
don't
know
if
it's
within
working
groups,
it
sounds
like
some
of
the
issues
that
you've
identified
are
across
working
groups.
Kevin.
H
I
think
we
so
we
we
often
catch
these
when
we're
trying
to
when
we're
trying
to
define
a
new
metric,
we'll
go
back
and
look
at
what
what
we've
already
done,
and
then
we
start
asking
the
question.
So
how
is
this
metric
different
from
this
other
metric
that
we've
already
defined
and
in
actually
the
I
think
a
lot
of
this
discussion
was
was
due
very
specifically
to
us
doing
that
in
evolution
right
we
were,
we
were
working
on
new
metric
and
we're
look
and
the
question
was
well.
H
How
is
this
different
from
this
other
metric
and
then
when
we
go
back
and
we
look
at
that
other
metric,
we
realize
that.
Well,
maybe
we
need
to
change
some
of
the
language
in
that
metric
to
reflect
that
these
are
two
different
things
right.
A
A
Using,
I
think,
is
from
the
discussion
of
changes
and
we're
adding
we're
discussing
getting
a
metric
called
pull
request
commits
yeah.
But
the
idea
of
linking
you
know
commits
to
a
pull
request
so
that
we
get
an
indication
of
the
size
of
a
request.
H
So
for
me,
ideally,
the
the
working
group
would
catch
that
right
and
in
this
case
we,
if
the
changes
are
substantive
enough,
we
can
send
the
the
old
metric
back
into
review.
If
it's
just
minor
language,
we
just
make
the
change
and
we
don't
worry
about
it.
However,
I
think
we
need
to
address
that
that
time
when
we
don't
catch
it,
and
I
don't
I
don't
know
if
that's
a
I
don't.
A
Think
that's
a
what.
H
H
A
A
H
No
they're,
I
don't
believe
the
the
structure
is
common
across
all
working
groups,
although
I
believe
there
is
an
effort
to
make
that
happen.
I
Okay,
currently,
they
are
kept
with
the
focus
area
like
within
that
focus
area
if
a
patrick
is
released
that
is
kept
within
that
focus
area
in
the
working
group.
H
It
depends
on
the
working
group
they're,
not
some
of
them.
Some
of
them
keep
them
elsewhere,
so
yeah,
maybe
the
maybe
to
think
of
it
as
a
metric
being
stale
right.
So
if,
if
a
metric
hasn't
been
edited
in
two
years,
it's
stale
and
we
just
send
it
through
the
comment
period
again
and
maybe
no
edits
are
required.
But
if
we
send
it
through
the
comment
period,
then
people
can
can
take
a
peek
at
it.
Based
on
what
we've
done
over
the
past
two
years
and
recommend
edits.
If
need
be,.
I
H
So
I
think,
making
the
making
the
working
group
actually
take
a
look
at.
It
might
be
just
putting
more
work
on
the
working
group
if
we
send
it
to
the,
if
we
just
send
it
when,
if
it,
if
it
reaches
a
staleness,
if
we
just
send
it
to
put
it
into
the
review
process,
then
the
working
group
could
look
at
it
in
the
review
process
and
comment,
just
like
everyone
else.
D
The
the
necessity
for
changes
introduced
by
changes
in
other
metrics,
whether
they're,
new
or
modified,
I
think,
puts
the
burden
on
the
creators
of
the
new
work.
H
In
in
general,
I
would
agree,
however,
because
the
working
groups
run
separately.
I
think
we
have
to
distribute
that
burden
a
little
bit
indeed,
so
I
I
wouldn't.
I
wouldn't
expect
the
the
common
working
group
to
to
completely
understand
what
was
going
on
in
the
the
evolution
working
group,
for
example,
sure
we're
gonna
look,
but
if
we're
not
taking
part
in
those
discussions
on
a
regular
basis,
then
I
don't.
H
H
H
I
guess
my
worry
would
be
that
the
this
process
becomes
too
cumbersome
to
manage
and
as
we
get
as
we
get
more
and
more
metrics,
the
the
the
process
is,
is
going
to
get
more
and
more
complex.
So
the
kind
of
the
laziest
easiest
way
to
do
it
would
be
to
just
take
the
metric
and
send
it
to
review.
A
A
A
But
sorry
I
have
all
my
dingers
on,
but
but
I
don't
think
we
have
to
answer
that
here
kevin.
I
think
we
should.
We
should
probably
maybe
put
on
the
agenda
for
for
the
monthly
meeting.
If
there's
a
structure
that
somebody
could
maybe
is,
is
there
anybody
willing
to
take
a
new
item
to
suggest
a
common
structure
for
where
released
metrics
go
in
a
working
group
repository,
and
if
we
had
that,
then
we
would
be
able
to
scan
a
directory
in
each
repository.
That
would
be
the
same
and.
A
Know
how
old
the
metric
was
or
when
it
was
last
released,
based
on
the
commit
date
and
the
repo
I'm
right
about
that
correct,
right,
kevin
that
there
is
like
you
know
where
right
now,
you
know
where
to
go
whenever
you
go
to
pull
the
release
metrics,
but
it's
in
your
head.
It's
not
consistent!
K
I'm
happy
to
update
the
proposed
template
for
the
working
group
repositories
and
the
only
change
I
see
we
need
to
do
here
is
move
the
metrics
not
yet
released
or
under
review
into
a
different
folder,
and
then
that's
the
only
change
that
I
see.
So
if
you,
if
you
look
at
the
google
doc
that
I
shared
in
the
chat
I
can
put
in
the
meeting
minutes
as
well
when.
A
I
would
not
personally
be
opposed
to
somebody
sort
of
just
making
this
so
with
the
consent
of
each
working
group
for
the
working
groups
that
I
participate
in.
We
don't
rely
heavily
on
the
repos.
We
only
use
them
when
we
publish
metric
so.
A
Or
yeah,
or
if
people
wanted
to
there
are
some
people
who
are
more
comfortable
in
markdown.
Perhaps
there
could
be
a
in
development,
metrics
and
development
folder
that
would
be
distinct
from
the
metrics,
see
that
focus
area
focus
area
name
and
a
directory
for
metrics.
Maybe
there
could
be
a
metric
or
directory
for
metrics
and
development,
or
something
for
people
who
prefer
to
work
in
github,
as
opposed
to
google
docs,
and
I
know
there
are
some
who
do
would
that
create
any
unnecessary
complexity,
key
or
kevin.
H
It
does
it
adds
it
would
add
a
step
in
the
release
process
that
the
working
groups
would
have
to
have
to
do.
Yeah.
L
A
A
I
I
I
gear
a
suggestion
that
we
just
don't
put
metrics
into
the
repositories
until
they
are
fully
developed
and
that
we
keep
them
on
google
drive
until
then.
That
seems
perfectly
reasonable
to
me
and
if
there's
a
working
group
that
wants
to
work
differently,
you
can
address
that.
But
as
long
as
you
don't
keep
it
under
the
focus
area,
it
won't
cause
you
any
trouble
kevin.
It
sounds
like.
H
So
that'll
that'll
probably
involve
going
through
and
doing
some
repo
cleanup
to
get
rid
of
some
some
markdown
files
that,
maybe
don't
don't
need
to
be
there
anymore.
A
Okay,
so
maybe
working
a
little
message
to
working
group
leaders
about
that
and
I'm
I'm
going
to
say.
A
Just
just
have
a
you
know,
put
this
on
the
agenda
right
off
the
bat
for
the
next
meeting
that
since
the
next
meeting,
I
guess
the
next
meeting
will
be
the
month
of
meeting,
but
for
the
next
for
the
monthly
meeting,
we'll
put
that
on
the
agenda
and
see
if
we
can
get
some
agreement
on
having
working
groups,
make
their
own
repositories
follow
the
structure
and
that
would
solve
some
of
the
aging
problems
that
kevin
brought
up
in
the
context
of
this
other
important
question,
and
we
do
now
have
some
guidance.
A
K
D
K
A
Demo,
oh
yeah,
okay,
that
sure
why
not
like
figure
out
how
to
stop
sharing
mine
boom
boom
do.
A
K
So
let's
say
we
want
to
go
here
in
the
community
section
to
metrics,
because
that's
what
we
currently
have,
what
we
are
discussing,
so
we
have
the
process
of
getting
metrics
approved
to
be
visible
on
the
website,
and
then
we
have
also
in
here
the
metric
contribution,
regular
release
where
we
describe
exactly
how
we
produce
the
the
website
and
the
pdf,
and
so
I
think
what
we
are
talking
about
would
best
fit
in
here
and
to
edit
it.
All
you
have
to
do.
K
K
K
K
H
So
what
is
the
the
preferred
working
group
or
repository
or
repository
structure
for
dealing
with
the
community
handbook?
Should
we
duplicate
some
of
this
stuff,
or
should
we
just
link
out
to
it
and
if
we're
creating
documentation
for
our
working
group,
repos
or.
K
I
think,
whenever
a
rule
criteria
or
something
spans
working
groups,
then
the
handbook
is
an
excellent
place
for
that.
If
it
is
something
unique
to
a
working
group,
then
yeah,
let's
keep
it
in
the
repositories
or
if
it's
unique
to
auger
or
gremore
lab
then
yeah.
The
repository
is,
I
think,
the
best
place
for
that.
K
H
Also
just
a
reminder:
this
is
not
really
related,
but
a
reminder
for
the
working
groups
that
the
the
metric
template
has
changed
to
include
a
header
at
the
bottom
for
contributors.
H
A
A
A
Probably
should
okay,
I
wanna
get
a
few
more
minutes
here.
Thank
you
for
the
tutorial
here.
I
don't
know
who
added
world
wide
web
consortium
accessibility
templates
of
the
agenda,
but
it
it
might
have
been
elizabeth
and
but
does
anyone
else
know
what
that
discussion.
H
That
was
yeah.
Elizabeth
did
add
that
to
the
to
the
dis
to
the
agenda,
so
we
are.
There
are
a
number
of
audits
that
we're
wanting
to
do
on
the
website.
One
of
them
is
a
diversity,
inclusion,
audit
information.
H
H
No,
no,
and
I
will
let
the
I
would
let
the
marketing
people
answer
what
a
marketing
audit
is.
That
is
not
my
area
of
expertise.
I
think
I've
had.
H
But
very
specifically
we're
talking
about
an
accessibility
audit
on
the
website.
We
want
to
make
sure
that
the
that
the
website
is
fully
accessible.
So
one
of
the
google
summer
of
code
potential
students
is
wanting
to
use
the
this
template
to
do
the
accessibility,
edit
or
audit
and
elizabeth
added
it
to
the
agenda
to
see
what
people's
thoughts
were
on
using
this
one
or
if
they
had
other
ideas
so
or
accessibility,
audit
templates
or
processes
that
they
were
familiar.
A
A
What
I
know
about
accessibility,
temp
on
websites,
is
that
I
choose
wordpress
templates
that
say
they're
accessible,
but
I
have
no
way
of
really
evaluating
that
or
I
don't
know
how
to
evaluate
that.
I
just
trust
when
they
say
that
they're
accessible.
H
So
we
because
we
do
because
we
do
a
mix
of
wordpress
and
mark
down
there-
are
there
kind
of
there
are
a
couple
different
ways
that
we
can
we
kind
of
make
mistakes
and
not
be
accessible.
A
H
F
F
H
H
Yeah,
I
don't
care
right,
so
you
know
yeah
in
in
markdown,
there's
a
way
that
we
can.
We
can
make
sure
that
the
alternative
text
for
for
images
is
added
and
then
in
wordpress
there's
another
way
that
we
can
make
sure
that
the
alternative
text
for
images
and
added
is
added
and
oftentimes
when
we
are
creating
the
the
web
pages
or
these
documents.
A
H
Wordpress
templates
themselves
should
be
so
those
should
be
colorblind
safe,
which
is
which
is
another
issue,
and
then
I
think
you
had
mentioned
in
a
prior
conversation
that
all
of
the
visualizations
that
you
do
for
auger
are
also
using
colorblind,
safe
templates.
So.
H
That
as
well
yeah,
but
the
the
fact
that
we
have
given
that
consideration
already
is
it.
It
makes
me
hopeful
that
that's
not
an
issue
for
us
yeah
and
then,
as
as
far
as
the
the
w3c
accessibility
template
goes,
I'm
I'm
perfectly
comfortable
with
that
and
I
think
we
can
kind
of
we
could.
H
H
A
A
Looks
like
the
next
item
is
a
google
summer
of
docs
review.
We
are
applying
as
a
chaos
organization
for
that
and
the
new
it
looks
like
you
may
want
to
speak
to
that.
D
K
Sure
no
problem
yeah,
so
we
are
getting
ready
for
the
application
deadline.
We
already
have
the
ideas,
three
of
them
for
possible
projects,
documentation
projects,
one
in
the
argo
project,
one
for
the
grimalda
project
and
one
for
the
just
chaos
community
as
a
whole,
and
so
if
anyone
would
like
to
help
we're
still
open
to
accepting
help
we're
still
working
on
the
application
itself,
which
is
the
the
process
google
requires
us
to
participate.
We
need
to
fill
out
a
form.
K
A
E
A
So
the
budget,
in
this
case
we
pay
the
budget
right-
is
that
how
this
works?
It's
a
slightly
different
program.
K
D
A
Does
google's,
I
guess
if
I
click
this
link
season
of
docs,
where
okay,
okay,
so
this
is
just
we're
interested.
A
Do
they
provide
any
guidance
that
anyone's
noticed
with
regards
to,
for
example,
if
you
have
a
project
that
you
estimated
x
hours
or
x
pages
or
whatever
the
thing
is,
then
here's
a
dollar
figure
to
multiply
that
by
or
I
don't
know
how
to
set
pricing
this.
You
know
most
of
my
google
summer
code,
students
have
been
in
countries
with
lower
costs
of
living
and
so
they've
been
paid
less
than,
for
example,
they've
been
paid
a
wall
street
investment
bank
for
the
summer,
which
is
probably
more
than
I
make.
A
A
A
A
K
Different
writing
projects,
and
so
we
should
split
the
fifteen
thousand,
probably
equally,
between
auger
gramolap
and
community.
A
H
I
think
then
you
I
think
venue
had
mentioned
that
we
were
supposed
to
identify.
We
were
supposed
to
identify
students
for
this
as
well,
but
this
isn't
necessarily
a
a
competition,
but
we're
supposed
to
identify
the
technical
writer
and
say
this
is
the
person
we
want.
Is
that
correct.
N
N
N
A
And
yeah
it's
10
before
the
hour,
and
I
I
think
if
you
need
any
assistance
or
if
the
projects
that
have
already
provided
proposals
require
are,
if
you
need
anything
from
those
folks.
You
know
where
to
find
us
and
thank
you
all
for
your
time
today.
A
If
you
have
anything
that
you
want
to
add
for
the
discussion
next
time,
please
throw
it
into
the
agenda
and
I
think
the
section
in
the
calendar.
Thank
you
all
very
much.