►
From YouTube: CHAOSS.D&I.Feb.26.2020
Description
CHAOSS.D&I.Feb.26.2020
A
A
C
Yeah
sorry
now
I
have
never
joined
and
I
haven't.
I
haven't
even
joined
the
mailing
list,
yet
I'm
kind
of
lurking
to
learn
more
about
this
I.
For
those
of
you
don't
know
me
I'm
a
lawyer
I've
been
working
in
the
open
source
space
for
quite
some
time.
I
we'd
have
been
one
of
the
leads
that
SPX
legal
team
for
far
too
long
sandy.
Here's
I
think
and
I
currently
work
at
canonical.
C
D
A
D
In
the
comments
for
micro
tasks,
so
Rick
I
find
it
a
bit
confusing,
there's
a
term
which
has
been
used
and
question
0
or
B
micro
tasks
that
software
batch,
so
they
I
wanted
to
know.
If
that
software
Bassem
refers
to
an
independent
digital
batch,
which
has
some
metadata
associated
with
it,
or
does
that
batch
have
to
be
like?
Does
it
have
to
be
defining
and
DNI
metrics?
Something
like
that
so
was
I
I.
D
E
B
A
E
F
B
D
B
I
I
did
actually
on
slack
I'm,
not
sure
if
you
saw
it
or
not.
I
didn't
mention
that
me
and
Matt
that
do
sync
bi-weekly
and
we
didn't
sync
between
last
meeting
in
this
one.
There
were
a
couple
of
things
from
last
meeting:
I
just
want
to
get
possibly
we
can
get
everyone
up
to
speed
on
the
other
topic
is
the
issue
I
opened
about
the
badger,
songs
or
whatever
that
we
do
on
Sundays,
because
they're
not
really
hackathon,
but
they're
kind
of,
like
that,
it's
a
three
hour
work
session.
B
That
basically
includes
some
sync
and
async
components,
some
discussion.
But
you
know
we
don't
have
to
say
two
three
hours
and
obviously
everybody
is
welcome,
but
it's
it's
just
I
guess
a
convenient
way
to
you
know,
get
at
questions
and
answers
quickly
as
we're
working
and
yeah.
So
so
the
other
two
topics,
I
believe,
was
the
front
end
that
you
showed
for
badging.
B
I
can't
remember
the
name
of
the
project,
though,
but
you
kind
of
showed
that
there
was
a
way
for
people
to
on
the
Linux
Foundation
site
to
or
something
related
to
get
badged
and
the
idea
that
we
can
create
a
workflow
from
you
know,
starting
from
that
towards
the
ER,
without
without
requiring
people
to
have
a
lot
of
moving
parts
to
the
process
and
tail
end
discussion
about
presenting
this
upstream
I
believe
it's
you
know
up
the
chain
and
Linux
Foundation.
But
again
you
know,
I
will
look
at
the
notes
to
remember
what
you
know.
B
B
G
Appreciate
the
idea
of
having
people
on
those
hackathons
if
anything,
the
the
Bajorans
yeah
for
that
matter,
but
I
actually
really
think
it
would.
It
be
good
idea
to
welcome
everybody
possible
cuz
right
now.
They've
been
close
to
this
point,
but
I
think
I'd
be
just
as
well
even
more
productive
to
have
more
people
involved
in
the
development
process.
The
workflow
process.
B
B
Yeah
the
issue
I
kind
of
mentioned
on
it
that
we
might
want
to
add
this
to
the
shared
calendar,
so
people
would
just
have
access
to
that
and
obviously
there's
a
postponing
or
cancellation
or
you
know
those
are
details,
I
guess,
but
but
it
will
be
a
fixed
bi-weekly.
Unless
there
is,
you
know
a
reason
to
cancel
for
one
Sunday
right.
A
It's
not
in
the
Google,
Doc
or
ranked,
and
then
Amy
asked
if
there's
a
Kaos
slack
channel
and
the
answer
is
no
there's
no
chaos,
slack
Channel
and
Sally.
Just
slack
he's
like
me.
That
was
funny
different
comment
and
no
js'
community
chaos
itself
uses
IRC
and
for
the
diversity,
food
and
working
in
group.
We
have
a
separate
mailing
list
specifically
for
this
working.
A
B
You
know
it's
likely
a
good
idea
to
address
that
discussion
on
the
actual
issue,
so
I'm
just
gonna
post
a
link
to
this
issue,
so
I
think
it
relates
particularly
here
and
I
should
do
my
homework.
Obviously,
but
I'm
you
know
just
catching
up
to
the
issues.
Oh,
so
would
it
be
a
good
place
to
continue
the
discussion
here.
H
F
H
H
D
G
H
G
G
H
G
A
A
A
A
So
we
have.
We
were
discussing
so
now
that
we
released
the
last
version
at
the
end
of
January.
I
would
like
us
to
get
back
into
defining
more
metrics
or
revising
metrics.
So
if
you
have
any
feedback
on
already
really
metrics,
which
you
can
find
over
at
Kaos
that
community
slash
metrics,
these
are
all
of
the
released
metrics,
not
just
diversity,
inclusion,
but
all
the
working
groups,
then
that
feedback
is
welcome
and
we
can
work
on
that.
A
Otherwise,
I
would
like
to
have
to
continue
working
on
on
metrics
and
what
we
do
is
typically
here
in
these
working
group
meetings.
We
sometimes
spend
twenty
minutes
working
on
a
shared
Google
Doc
to
to
build
out
a
metric,
because
we've
found
it
to
be
more
engaging
if
we
can
all
work
on
the
same
metric
and
talk
through
it
and
revise
it
together,
then
try
to
do
it
asynchronously,
so
just
for
those
new
on
the
call.
This
is
a
little
bit
background
on
how
this
working
group
has
been
working
in
the
past.
B
So
it's
actually
great,
because
I
use
the
raise
hand
button
to
try
to
not
create
a
lot
of
like
acing.
You
know
anyways,
but
since
we're
getting
to
documentation,
accessibility,
I
think,
first
of
all,
it's
it's
maybe
a
good
idea
to
just
share
I,
don't
know
if
others
who
are
joining
us
for
the
first
time
want
to
go
through
how
the
document
is
structured.
Generally
like
like
how
we
go
about
working
in
the
Google
Doc
and
how
we
structure
our
metric.
A
You
can
never
find
it
it's
Roger,
okay,
so
in
the
chaos
project,
when
we
define
metrics,
we
have
a
template
that
we
follow
for
all
metrics,
where
we
have
the
name
of
the
metric.
We
always
have
a
question
that
the
metric
is
trying
to
answer,
because
we
are
following
a
goal.
Question
metric
approach,
which
says
that
looking
at
a
metric
by
itself
is
not
meaningful.
We
have
to
understand
why
we're
looking
at
a
metric
and
what
questions
we
want
to
answer
and
we
derived
those
questions
by.
A
We
build
out
a
metric
strategy
by
knowing
what
our
goals
are.
These
can
be
community
goals.
It
can
be
organizational
goals
for
them
for
reaching
the
goals.
We
have
questions.
So
let's
say
our
goal
is
to
grow
the
community.
Then
our
question
could
be
how
many
new
contributors
have
we
had
over
the
last
month,
and
then
we
have
a
metric
that
is
new
contributors
and
I'm
just
giving
that
example,
because
before
this
call,
I
was
working
with
the
evolution
working
group
on
that
metric
and
so
for
each
metric
we
describe
what
it
is.
A
We
have
objectives
for
why
someone
would
want
to
use
that
metric.
We
have
information
about
how
we
suggest
implementing
it.
There
may
be
filters
for
looking
at
the
data
in
different
ways.
There
may
be
visualizations
so
that
you
have
an
idea
for
how
metric
could
be
is
played
there.
We
have
a
list
of
tools
that
we
know
provide
the
metric.
Typically,
this
is
order
and
grimore
that
there
may
be
data
collection
strategies
if
there
are
no
direct
tools.
A
So
sometimes
we
do
interviews
or
survey
questions,
and
then
we
have
references
if
there
have
been
blog
posts,
websites,
academic
papers
that
have
talked
about
this
metric
or
the
topic
that
this
metric
is
on.
So
that's
the
format
that
we
follow
and
then
we
have
for
developing
a
metric,
a
typically
a
Google
Doc
that
we
can
all
edit
at
the
same
time
and.
A
So
please
do
join
this
document
and
then
for
the
next,
let's
say:
15
20
minutes
I
would
like
us
to
revise
this
metric,
so
at
your
own
pace
start
reading
through
it.
If
it
makes
sense,
you
can
directly
edit
it
or
if
you
have
something
you're,
not
sure
about
you
can
either
suggest
so
at
the
top
right.
You
can
change
from
editing
to
suggesting
and
then
we
can
talk
about
it.
If
you
have
any
question
along
the
way,
please
interrupt
you're
not
interrupting.
Please
speak
up
and
ask
the
question.
B
B
I
just
had
one
question
about
how
we're
framing
this
metric
I
understand
that
we're
framing
it
based
on
what
is
out
there
right,
but
then
the
question
is
how
much
documentation
is
actually
accessible,
I
kind
of
threw
that
tangent
at
the
end
of
last
night,
yesterday's
meeting
about
writing
styles
being
a
matter
of
how
accessible
a
document
really
is
that
there
is
a
dominant
style
to
writing
things,
and
that
doesn't
mean
that
it's
just
the
single
style
where
information
can
act.
You
become
you
know,
documented
and
related
to
every
member
of
a
project.
B
So
so
I
think
it's
fair
for
this
metric
to
say
that
there
there
is
a
missing
chunk
of
accessibility
in
documentation,
and
just
you
know,
how
do
we
go
about
measuring
something
that
is
not
even
you
know,
attempted
or
here.
Would
that
be
a
fair
place
to
bring
this
up?
You
know
I'm
I'm,
really,
just
not
sure
there
are
answers,
so
you
know
trying
and
correct
me
if
I'm
wrong,
I.
A
B
B
That
is
meant
to
be
read,
and
you
know
so
the
the
idea
that,
when
you're
relating
a
message
in
in
writing
that
is
read
as
intended
when
you
write
it,
you're
you're,
relying
on
this
medium,
so
I
believe
that
when
you
change
when,
when
you
translate
mediums
or
you
know,
the
audience
is
of
a
different
frame
of
reference,
that's
the
way
I'd
like
to
define
it.
You
not
know
you
sometimes
you
know
unintentionally
rely
on
contextual
or
rely
on
pace,
or
you
know
rely
on
a
way
of
looking
at
how
your
message
is
received.
B
That
is
disconnected
from
how
how
it
actually
is
received.
So
so
I'd
like
to
say,
yeah,
Neru,
divergence
or
neurodiversity
is
a
new
angle
for
accessibility,
but
the
concerns
of
dwell
pays
attention
span.
All
these
are
really
not
not
necessarily
just
because
of
the
ability
to
read
or
not,
but
but
rather
the
ability
to
somehow
consume
what
is
meant
to
be
read
in
a
way
that
is
accessible
to
that
individual.
So
so
I
think
the
dynamic
here
is
a
lot
more
intertwined.
B
A
Question
that
I
have
is
from
understanding
what
the
problem
is.
How
do
we
put
this
somehow
into
this
metric
definition,
because
that's
what
we're
working
on
right?
So
it's
good
that
you
bring
in
that
background
and
I'm,
not
that
knowledgeable
about
that
background.
So
how
do
we?
How
do
we
put
this
into
our
data
collection
strategy
or
in
our
metric
so
that
we
can
capture
this
so.
B
A
This
maybe
already
captured
in
this
multiple-choice
question,
for
did
you
face
any
challenges
related
to
the
accessibility
of
documentation
when
you
started
to
participate
in
the
project,
for
example,
because
of
language
barriers,
discoverability
of
documentation
or
structure
of
documentation,
etc.
So
this
gives
someone
who
has
challenged
understanding
the
documentation
to
say
yes,
there
have
been
issues
and
yeah.
A
B
You
know
I
would
like
us
to
come
up
not
necessarily
right
now,
but
but
eventually
to
try
to
break
this
down
into
tenable,
measurable
things
about
the
kind
of
challenges
and
the
severity
of
them,
because
just
saying
yes,
there
are
challenges,
it
does
not
really
get.
It
does
not
give
a
particular
indicator
on
what
kind
of
solutions,
or
you
know
what
kind
of
you
know
causes
are
there
and
it
kind
of
leaves
it
as
okay.
B
A
You're
you're
right,
especially
sin.
If
we
do
a
survey,
then
the
only
server
that
people
who
are
currently
in
the
community-
and
that
might
be
people
who
did
not
have
barriers
to
begin
with
and
so
I
think
it's
important
that
we
have
these
w3c
become
access
guidelines
and
other
resources
bring
down
various
subpoenas,
contribute
neurodivergent
individuals,
so
I
think
we
have
those
references.
The
question
is
so
you
also
said.
Maybe
this
is
not
something
for
right
now,
maybe
there's
something
we
can
improve
on
in
the
future.
Yes,.
B
Yes,
definitely
it's
kind
of
a
discussion
that
I
would
like
to
somehow
relate
to
this
metric.
Maybe
it
could
be
an
issue
that
we
can
open
in
the
repo
or
you
know
so.
I
just
would
like
this
to
be,
like
you
know,
put
a
like
an
anchor
point
somewhere
to
see
where
this
continues.
I
can
open
the
issue.
I,
don't
I,
don't
mind
that
it's
just
if
that's
useful
for
everyone
else
or
you
know
a
different
way
of
going
about,
it
would
be
more
recommended.
A
So
I
like
the
idea
of
improving
this
metric
in
the
future
and
taking
something
that
is
fairly
simple
to
start
with
and
then
adding
the
depth
that
you
are
describing
at
a
later
point
just
so
that
we
start
to
have
something,
because
something
is
better
than
nothing
and
moving
us
of
zero
is
better
than
trying
to
really
nail
it
down
to
the
most
perfect
version
and
you're
not
being
able
to
release
this
metric.
Let's
say,
for
example,
yeah.
B
I'm
with
you
100%,
so
so
I'll
just
open
that
issue
and
know
locking
this
metric
whatsoever.
Actually,
the
issue
will
be
like
future
revisions.
You
know
about
computer
revisions
of
this
metric,
what
what
the
challenges
are
really
and
then
everyone
can
be
party
to
that
issue,
and
so
would
I
do
this
in
diversity
and
inclusion,
the
repo
itself
or
with
this
okay,
perfect.
Okay,
sorry!
So
yeah!
Sorry
for
you
know
stalling
us
here.
Thanks
no.
A
F
A
A
F
A
D
A
A
C
Just
looking
at
the
objective
section,
if
I
was
starting,
a
new
project
or
I
was
trying
to
improve
the
documentation
in
an
existing
project
and
I
read
something
like
some
of
these
things
are
pretty
easy
to
measure
right
like
thanks.
You
can
do
this
screen
reader
test.
I
know
just
about
that's
what
you
know.
It's
more
concrete
thing,
but
when
I
read
something
like
documentation
is
easy
to
follow
and
structure
intuitively
intuitively.
C
How
do
I
know
what
that
means?
I
mean.
Obviously
anyone
who
writes
something
thinks
it's
easy
to
follow
instructors
intuitively
until
someone
else
reads
it
and
goes
I
wouldn't
have
structured
it
that
way
and
there's
probably
not
one
answer
and
the
kind
of
same
thing
with
like
the
documentation
uses
a
global
language,
I
I'm,
not
sure,
I,
know
what
that
means.
It's
so
it's
so.
If
you're
you're
trying
to
implement
this,
you
know
where
do
you
I
mean
there's
a
measurement
issue,
but
just
from
a
practicum
the
the
better
use
of
this
right?
C
B
C
A
C
Of
these
things
are
easier,
I
guess
I'm,
trying
to
see
if
there's
another
one
I
mean
document
some
smaller
on
the
topic.
Documentation
limits,
use
of
unnecessary
technical
jargon,
I
love
that
as
someone
who's,
not
a
technical
person,
but
that
is
also
in
the
eye
of
the
beholder
and
I
could
give
you
an
actually
about
personal,
great
example
that.
C
I
mean,
if
that
helped
it
helped.
I
was
setting
up
a
boon
to
on
my
on
the
personal
computer
before
I
start
well,
and
that
was
not
necessarily
easy,
because
I
didn't
go
the
easy
route
in
terms
of
buying
some
preinstalled
and
so
a
free
software.
A
friend
of
mine
who
you
know
very
technical
person,
said
I
said
it
was
really
heartening,
so
I'm
surprising,
it
was
hard
because
of
butea
has
such
great
documentation,
which
it
does
undoubtedly
and
and
the
answer
that
was.
You
know
he
was
curious
and
the
answer
was
like.
C
The
documentation
is
really
great,
but
it's
written
for
someone
who
has
like
some
level
of
understanding
about
Linux
clan
line
and
how
did
saw
operating
systems
wherever
and
and
so
I
am
kind
of
a
friend
of
mine
he's
who
is
helping
me
and
he
was
like.
Why
can't
you
know
I
was
like
I
can't
fix
his
problem.
He
there's
no
clearly
other
people
or
this
problem.
A
C
A
B
I,
don't
know
if
it's
on
the
overall
strategies
metric,
but
it
seems
like
documentation,
accessibility,
a
great
place
to
tell
people.
Okay,
you
identify.
There's
something
about.
Authenticity
was
a
metric.
Can
you
capture
this
when
you
create
like
a
like
a
a
study
or
something
like
just
to
somehow
capture
what
the
problem
looked
like
or
what
the
clever
suit?
Or
you
know
it's
not
part
of
the
data
used
for
the
metric,
but
it's
a
result
of
the
metric,
open
gun,
discontinuity
and
how
you
know
we
go.
F
B
Addressing
an
unknown-
and
you
know
very,
very
unclear,
dimension
of
the
next
few
years.
I
guess
you
know
making
things
accessible,
it's
going
to
be
very
hard
and
that's
because
the
answers
are
not
yet
there
and
the
questions
are
sometimes
it's
not
even
being
asked.
So
would
that
be
something
to
add
to
the
metric
or
would
that
be
like
a
meta
elsewhere?.
B
B
B
So
you
know
like
take
a
screenshot
with
your
phone
or
while
you're
removing
ads
when
you
were
on
Facebook
and
then
put
it
back
on
Facebook
that
kind
of
thing
so
so
they're,
if
they're
walking
through
documentation,
I
think
they
identified
like
a
slippery
slope
or
something
that
would
be
a
good
thing
to
be.
Like
okay,
I'll
take
a
screenshot.
You
know
capture
this
in
time,
along
with
the
with
the
with
the
discussion
that
took
place
so
that
both
the
interaction
of
the
walkthrough
and
the
resource.
A
A
C
Mean
another
thing
is
you
know,
I
was
thinking
like
to
be
fair.
You
can't
write
the
documentation
to
be
inclusive,
I
don't
mean
inclusive
in
the
diverts
you
a
bit
like
to
be
appropriate
for
all
loveable
right
like
it
would
be
silly.
It
might
be
unrealistic
for
some
of
that
documentation
that
I
found
for
someone's
there
AB
good
stuff.
That
I
would
need
because
someone
else
be
like
duh,
you
know,
but
you
could
also
maybe
practice
it
with
hey
in
order.
You
know
it
like
here
it's
some
background.
C
You
might
need
to
know,
but
this
you
know
you
want
to
reinvent
the
wheel
either
right
the
thing
it's
I
think
it's
fair
to
say,
hey
in
order
for
this
document.
You
know
in
order
to
do
work
like
someone
who's,
not
software
developer
isn't
going
to
start
like
myself
is
I'm
going
to
start
contributing
the
Linux
kernel
tomorrow,
just
an
extreme
example,
and
so
there's
no
reason
that
the
Linux
kernel
documentation
should
be
written
as,
like
my
level
of
understanding.
That
would
be
an
unfair
expectation
right,
yep.
B
B
You
know
the
current
demographics
or
breakdown
relative
to
the
format's
or
the
variations
or
if
they
just
use
one
variation
of
documentation,
so
so
I
think
it's
fair
to
say
it's
it's!
You
know
you
want
it.
You
want
to
allow
people
to
to
say
how
they
went
about
trying
to
cater
to
the
very
wide
spectrum
of
accessibility
that
you
know.
They
divide
it
in
a
way
that
is
pragmatic
to
their
own
capacities
and
ambitions
as
a
project
and
as
a
community,
and
there
are
no
standards
yet.
A
B
Then
it's
it's
really
a
relative
definition,
and
so
including
that
definition,
how
they
look
at
you
know,
version
X
or
version
Y
or
version
C
of
the
document
to
be
targeting
a
specific
segment,
how
they
define.
That
would
be
a
good
good
thing
for
us
to
to.
You
know,
have
them
include,
and
in
conducting
this,
so
that
when
you're,
comparing
the
results
of
this
metric
across
projects,
this
relative
aspect
is
stipulated
by
each
projects
on
we're
going
about
something
that
is
unstandardized
all.