►
From YouTube: CHAOSS DEI Working Group 5/18/22
Description
Links to minutes from this meeting are on https://chaoss.community/participate.
B
B
C
B
B
We
do
have
a
a
whole
kind
of
variety
of
open
prs
that
it
would
some
of
these
like
the
440
and
439
437.
These
are
in
responses
to
some
of
the
open
issues
that
we
have.
So
this
is
about
metric
revision
and
so,
for
example,
opening
the
issue
here
around
time:
inclusion
for
virtual
events,
event,
demographics,
family
friendliness
and
code
of
conduct.
B
B
A
F
F
B
Do
you
kevin?
Could
you
kind
of
go
through
them
really
quickly
if
they
are
just
copy,
edits,
yeah?
Well,
we're
just
sitting
on
this
call
right.
You
know
what
I
mean
like
oh
right
now,
yep
yeah,
I
mean
okay,
if
they're,
just
if
they're
just
like.
So
I
don't
know
that
I
want
to
like
share
my
screen.
Copying
pasting
links.
That's
all!
Okay!
It's
not.
B
F
D
F
B
A
A
B
A
A
B
A
F
F
A
F
A
F
B
F
F
No,
no
so
metric
revisions
like
this
if
they
are
just
copy
edits.
If
there's
no,
if
there's
no
kind
of
substantial
changes
to
the
metrics,
we
we
had
discussed
that
we
were
going
to
exclude
those
from
the
release
process.
So
this
is
just.
This
is
just
kind
of
maintenance.
If
we,
if
we
are
making
considerable
like
substantial
changes
to
what
a
metric
is
okay,
then
we
do
need
to
take
that
metric
and
actually
run
it
back
through
the
release
process.
F
Okay,
and
if
we
do
that,
then
we
do
want
to
add
it
to
the
release,
notes
and
create
a
release
issue
for
it,
but
if
we're
just
doing
copy
edits
and
fixing
some
of
the
language
so
that
it's
it's
current
and
then
then
we
don't
need
to
because
the
the
assumption
is
that
every
metric,
every
metric
we've
released
so
far
is
going
to
go
through
this
treatment.
So,
okay.
B
B
F
B
F
F
F
Can
revisit
it
and
go
through
this
kind
of
this
review
process
again
where
we
we
go
through
it
and
we
do
copy
edits.
We
make
sure
the
links
work.
Okay
and
we
decide
at
that
point
if
we
want
to
do
a
more
substantial
edit,
which
would
send
that
metric
back
into
review.
Okay,
that
makes
sense
cool,
oops.
B
A
F
B
F
Yeah
so
yeah
in
the
caveat
for
metric
candidate
release
that
they
we
need
to
add
that
caveat
as
well.
So
that's
once
again,
that's
only
if
we're
if
we've
made
substantial
changes
and
yeah
go
back
through
the
relationship
so
like
for
this
metric
family
friendliness,
we
would
not
add.
I
just
don't
check
that
you
know
yeah
and
maybe
in
the
the
template
that
we
have.
Maybe
we
should.
We
should
make
the
language
a
little
clearer,
yeah.
C
C
F
Yeah
it's
modified
a
bit
but,
and-
and
it
is,
it
is
appropriate.
Those
check
marks
are
appropriate,
but
only
if
we're
sending
it
back
through
the
through
the
review
process.
So
it's
just
a
maybe
we
add
a
an
optional
or
we
had
a
in
parentheses,
something
that
says
you
know
if
substantial
changes
have
been
made.
Okay,.
B
F
B
B
B
So
in
the
badging
repository
we
now
have
event
project
diversity
and
inclusion,
so
this
is
far
from
being
like
ready
to
launch
in
any
way
shape
or
form
yeah.
But
I
took
a
look
at
what
was
already
existing
in
there.
So
asta
had
done
some
work
and
matt
cantu
had
maybe
done
some
work
there
as
well,
and
I
took
a
look
at
it
just
kind
of
this
this
overview
and
I
think
the
same
you
know
it's
still
going
to
be.
B
I
think
this
will
have
to
change
a
little
bit
because
we
want
to
not
have
as
many
levels
for
project
vouching,
but
we
have
the
project
submission
guidelines,
and
these
are
some:
oh
wait,
not
that
sorry
submission
requirements
here
we
go
so
these
were.
This
is
holding
on
to
some
of
the
stuff
that
asta
had
put
in
there,
as
well
as
adding
some
of
the
new
components
that
we
talked
about.
So
I'm
curious.
B
H
H
H
H
H
I
would,
and
maybe
contributing
guidelines
would
need
to
would
need
to
be
like
a
contributing.md
file
if
you're.
If
she
has
those
listed-
and
we
had
been
talking
about
just
looking
at
the
type
of
and
so
that
we
wouldn't
earlier.
We
had
discussed
like
they
needed
to
have
these
different
file
types
so
that
we
weren't
reading
every
one
of
them
and
we
were
just
checking
for
file.
B
C
A
E
F
Yeah,
I
agree
with
that.
I
think
these
documents
should
follow
kind
of
a
standard
naming
convention.
Most
most
projects
do
follow
that
standard
naming
convention.
So
the
I
think
the
expectation
from
visitor
is
that
that
that
there
is
a
a
readme.md
file,
for
example,
or
a
the
the
license
dot
md
file.
So
if
the,
if
the
project
isn't
following
kind
of
that
standard
naming
protocol,
I
think
that
it's
probably
a
bad
thing.
F
Yeah,
I
think,
if
the
if
this
badging
is
about
the
best
practices,
then
having
a
separate
contributing.md
file
is
very
explicit
and
as
a
new
contributor
to
a
project,
I
can
see
that
document
in
the
file
structure
and
I
can
go
there.
Even
if
that
document
points
me
to
other
places,
I
mean
it
is
a
general
expectation
of
a
welcoming
project
yep
exactly.
B
Okay,
so
what
I'm
hearing
is
that
we
and
tell
me
if
I'm
running,
we
would
have
that
we
would
say
in
your
readme
file,
because
there's
an
assumption
that
they're
going
to
have
a
readme
like
they
all
do
in
your
readme
file.
You
really
need
to
have
a
couple
things
clearly
available
in
your
readme
of
which
includes
oh,
go.
H
B
F
I
think
the
the
readme
provides
an
overview
of
what
the
project
is
and
lets
the
lets.
The
new
user
know
exactly
what
the
the
software
does
right.
So
I
do
think
that's
important
if
you,
if
you
land
on
the
readme
or
if
you
land
on
this
project,
you
should
have
a
readme
that
tells
you
kind
of
gives
you
an
overview
of
what
the
project
is.
So
you
know
you're
in
the
right
place,.
H
F
F
I
F
Yeah,
I
do
think
it's
both,
because
we
are.
This
is
a
focus
on
the
the
projects
that
we're
badging
have
to
be
open
source
projects.
So
we
we
have
to
have
that
that
the
license
in
there,
because
the
license
is
the
proof
that
it's
an
open
source
project
and
then
to
elizabeth's
point
which
is
excellent.
Is
that
yes
license
licenses,
can
restrict
accessibility
and
even
how
open
a
project
is
so
yeah.
H
B
F
B
So
let
me
let
me
try
that
again.
So,
like
is
part
of
the
the
the
request
for
a
badge,
you
know
one
of
the
questions
that
people
have
to
ask
is
like
for
events.
Is
this
an
open
source
event
and
we
can?
We
can
take
a
look
at
the
license
file
and
that's
fine
kevin.
I
do
understand
that
having
a
license
file
is
an
important
indicator
as
to
whether
or
not
a
project
is
open
source.
I
I
So
I
mean
it
can
keep
people
out
if
we're
looking
at
it
from
that
lens,
it
can
be
ex.
You
know,
keep
people
out
and
not
be
as
welcoming
if
it
does
not
have
an
open
license,
but
if
we
don't
care
about
that
right
now,
maybe
that's
something
we
add
in
later
once
we
kind
of
get
the
process
down,
then
maybe
we
add
that
in
later.
A
B
F
H
B
B
B
H
E
E
The
core
reviewers,
which
are
anyone,
can
review,
but
a
core
has
plus
two
and
can
do
plus
workflow,
and
that's
how
we,
the
workflow,
is
what
merges
for
us.
So
by
saying
the
ability
to
merge,
I
think
you're,
covering
all
the
capability.
You
know
all
the
different
naming
type
situations
that
you
would
run
into
because
either
you
can
merge
or
you
can't
merge
it's
a
line
in
the
sand.
E
G
E
C
E
Trying
to
think
of
places
that
aren't
using
github
is
going
to
be
the
naysayer
on
certain
things,
because
of
that
because
some
of
my
projects
are
in
and
some
of
them
aren't
so
like
we
use
a
mix
of
two
different
bug.
Tracking
systems
in
each
project
like
I
could
apply
for
neutron
and
nova,
would
never
know
that
we
were
applying
for
neutron
and
things
like
that
by
doing
something
in
a
notes,
type
system,
a
lot
of
them
are
editable
by
anyone.
E
So
you
want
something:
that's
kind
of
static,
an
email
that
could
be
copied
is
if
the
project
is
using
eavesdrop,
you
know,
there's
a
reporting
of
everything.
They
say
you
can
look
at
it
there,
but
getting
something
that
is
static,
that
everyone
can
see
and
that
you
can
see
is
really
going
to
depend
on
the
different
project
if
they're
in
github
or
get
lab
yeah.
I
think
you
can
do
a
discussion.
B
E
B
B
B
H
And
when
applying
for
a
badge
or
when
doing
something,
people
are
more
likely
to
toss
it
aside
and
not
come
back
if
they
have
to
do
too
much
out
of
the
way
reading.
That's
when
so
like
already
clicking
on
the
osi
approved
licenses,
that's
already
taken
one
point
where
it
takes
them
away
or
they
might
leave
an
open
tab
and
forget
about
it.
Super.
H
B
I
E
I
Yeah,
I
just
set
it
up
a
couple
weeks
ago:
yeah
it's
on
the
chaos
calendar.
So
if
you're
in
general,
if
you're
in
the
slack
and
you're
in
general,
you'll
see
those
meeting
reminders
and
things
come
through
so
but
if
you
can't
make
that
and
you're
interested
in
being
a
badger.
Just
send
me
an
email,
elizabeth
chaos.community
and
I'm
happy
to
set
something
up
on
the
side
like
101.,
no
big.
J
Yeah
hi,
so,
with
the
last
application
we
had
the
applicant
asked
about.
So
it's
a
hybrid
event.
I
know
we
have
like
separate
forms
for
like
in-person
and
virtual
events,
but
the
organizer
asked
about
hybrid
events,
and
then
I
realized
that
we
just
have
like
forms
for
in-person
and
virtual.
I'm
not
like
there's
no
form
for
like
a
hybrid
event.
So
I
was
thinking
if
we
need
to
have
something
like
that,
because
I
think
these
days
I
see
a
lot
of
hybrid
events,
so
I
agree
like
yeah.
J
J
J
B
B
F
So
if
it
is
an
in-person
event,
it's
going
to
be
more
inclusive
if
there's
a
virtual
component
to
it
as
well.
So
that
may
be.
That
may
be
something
we
want
to
look
at
in
the
future
for
in-person
events
as
well,
where
we,
where
we
start
to
expect
all
in-person
events
to
have
some
sort
of
virtual
or
hybrid
component.