►
From YouTube: CHAOSS + All In DEI Project Badging Coordination Meeting
Description
This meeting we meet with our first Pilot Project to talk about what will go into the DEI.md file.
A
B
A
That's
right:
okay,
so
yeah,
we've
kind
of
so
this
meeting
just
a
little
context.
This
meeting
has
been
a
little
bit
more
informal
to
date
and
now
we've
kind
of
formalized
it
and
it's
on
the
chaos
calendar
it's
open
to
whoever
just
like
the
rest
of
our
chaos
meetings
here
so
yeah.
So
that's
where
we
are
first
thing:
I
just
thought
it
would
be
nice
to
kind
of
go
around
and
introduce
ourselves
and
get
to
know.
A
D
A
Elizabeth
I'm
the
chaos
Community
manager
and
I've,
been
here
at
chaos
for
about
three
years
now,
I've
been
in
open
source
a
long
time
20
some
years,
I've
stopped
counting,
which
is
probably
good
because
it
just
depresses
me
anyway,
when
I
think
about
it
when
I
think
about
it.
How
long
I've
been
around
and
yeah
I
also
do
help
out
with
the
all-in
project.
So.
D
C
Hi
everyone
I'm
Sean
Goggins
I'm,
one
of
the
Kias
co-founders
maintenance,
auger
co-director,
been
here
in
chaos
from
the
beginning
and
I'm
just
excited
about
this.
All
in
Project
we've
been
talking
about
ideas
like
this
with
Demetrius
and
her
colleagues
for
a
couple
years
now.
So
it's
exciting
to
see
some
of
this
work
result
in
working
tools
and
things
I
will
pass
it
along
to
see
Mel.
B
E
B
F
So
my
my
position
in
this
project
is
leads
software.
Architects,
we've
had
a
discussion
in
the
past
with
I
I,
don't
know
if
I
can
say
with
with
chaos,
but
we've
had
a
workshop
where
we
invited
Don,
and
we
had
a
brief
introduction
to
to
chaos,
and
so
since
then,
I've
been
keeping
an
eye
on
on
what
you're
doing
I've
seen.
Also
the
all-in
project
and
it's
nice
to
see
both
project
kind
of
convergingly
here.
A
Awesome
well,
we
are
super
super
happy
to
have
you
here
and
just
so
you
know
you
are
really
the
first
one
to
kind
of
go
through
this
process
with
us,
so
we
appreciate
any
any
and
all
feedback
that
you
have
as
we
go
and
also
just
keep
in
mind.
It
is
a
pilot,
so
there
might
be
some
bumps
in
the
road,
but
that's
the
whole
point
of
this.
So
thank
you.
Thank
you.
Thank
you
for
agreeing
to
do
this.
A
Overview,
we
basically
develop
metrics
here
around
open
source,
Community
Health,
and
that
can
be
from
a
lot
of
different
angles.
Dei
is
one,
and
we
also
look
at
things
like
Risk
and
evolution
of
projects.
We
look
at
just
general
statistics,
General
metrics,
and
then
we
also
will
bring
some
of
those
more
Atomic
or
individual
metrics
together
in
what
we
call
metrics
models,
so
that
would
look
at
like
a
bigger
picture
with
different
pieces
put
together.
A
A
We
also
do
have
these
badging
initiatives
here,
which
is
kind
of
our
attempt
to
take
some
of
our
metrics
that
we
develop
in
in
theory
and
really
put
them
out
in
the
world
and
make
them
applicable
to
to
others,
and
so
we
have
our
Dei
event
badging,
which
is
where
this
started
actually
and
that
is
for
event,
organizers
to
just
fill
out
an
application.
We
look
at
some
of
the
the
things
that
they're
doing
at
their
event,
and
then
we
issue
a
badge
and
it's
a
very
manual
process.
A
The
volume
is
a
whole
lot
less
than
projects,
and
it's
you
know
it's
just
a
little
bit
more
clear-cut,
like
where
an
event
is
what
it
is
like
it
starts.
It
stops
it's
done,
but
projects
are
a
little
more
complicated
as
you
know.
So
this
is
why
we're
trying
to
take
kind
of
some
of
the
things
we're
learning
from
event
badging,
but
also
automate
a
lot
of
the
process
so
that
it
can
be
a
little
more
scalable
for
the
future.
A
A
Not
here
today
from
GitHub
we
had
been
chatting
about
like
open
sourcing
diversity,
Equity
inclusion,
because
a
lot
of
people
are
working
on
this,
and
so
we
kind
of
were
trying
to
bring
people
together
in
an
open,
sourcy
kind
of
way
and
then
Allen
kind
of
evolved
under
the
GitHub
umbrella.
So
it's
it's
right.
Now,
it's
it's
kind
of
owned
by
them.
I
guess
you
could
say
they
sponsor
it.
They
really
support.
A
Do
a
lot
of
the
like
financial
support
behind
it
and
the
coordination
of
it,
but
it
has
two
pieces
to
it.
So,
there's
all
in
for
maintainers,
which
is
what
we're
working
on
right
now
and
then
there's
also
all
in
for
students
and
the
students
piece
is
aimed
obviously
towards
students
but
I'm,
just
really
onboarding
folks
into
open
source
and
integrating
them
teaching
them
like
how
it
works
and
and
all
that
stuff.
A
So,
as
I
said,
we're
focusing
on
all
in
for
maintainers
right
now,
and
the
badging
initiative
is
just
one
of
the
they
have
a.
They
have
several
initiatives
under
the
all-in
for
maintainers.
So
there's
like
a
resource
Hub
around
Dei
resources.
There's
a
few
other
things
in
the
works,
but
this
is
really
kind
of
the
the
bigger
the
bigger
one,
the
bigger
project
under
the
all-in
umbrella,
I'm
gonna.
A
C
B
C
All
right
can
we
see
that
yep
okay.
So
as
far
as
we
are
right
now,
this
is
just
the
little
pink
dot
represents
the
project
badging
website.
This
fuchsia
dot
is
auger,
the
black
dots,
the
maintainer
and
the
yellow,
guys
GitHub,
and
so
there's
a
website
that
we
have
for
all
in
open
source
and
then
there's
a
link
for
project
badging,
which
Ruth
and
Enoch
have
shared
with
us
previously,
and
that's
the
sort
of
landing
page
for
learning
more
about
project
badging
after
a
person
or
a
maintainer
learns
more
about
it.
C
They
would
apply
for
a
project
badge
right
there,
where
Matt
is
hovering
or
where
it
was
hovering
right
here
and
when
they
apply
for
a
project
badge.
All
of
the
data
regarding
that
application
is
maintained
by
the
website
and
the
website
submits
the
repository
for
which
badging
has
been
requested
to
the
auger
system,
which
does
some
machine
learning
and
sends
back
a
report
and
then,
in
somewhat
parallel,
it
does
a
scan
of
the
dei.md
file.
C
What
we
discussed
earlier
this
morning
is
because
Enoch
was
explaining
last
week
how
he
doesn't
know
when
auger
has
the
report
ready
and
I
explained
to
him
this
morning?
That's
because
he
wanted
us
to
provide
an
API
with
the
report,
and
so
we
kind
of
arrived
at
what
the
website
application
is
going
to
do
is
provide
essentially
another
API
that
auger
subscribes
to
or
that
they
they
subscribe
to,
so
that
whenever,
whenever
the
report
is
finished,
auger
will
hit
that
end
point
and
notify
them
that
the
API
is
available.
C
So
that's
kind
of
the
new
Nuance
in
there
and
then
at
the
end
of
all
that
the
bronze
level
badge
is
complete.
So
the
website
maintains
the
repo
badge
date
and
badge
level
publishes
the
project
badge
on
the
website
and
then
emails,
the
Dei
status
auger
report
and
a
markdown
for
the
badge
to
put
in
the
readme
here
back
to
the
maintainer
and
then
the
silver
badge
level
is
what
comes
next
and
obviously
all
that's
TBD.
E
A
That's
really
the
central
piece
of
this
whole
thing
is
this
file
that
we've
yeah
we
might
as
well
go
ahead
and
talk
about
now
we're
calling
it
the
dei.md
file.
So
it's
it's
aim
to
sort
of
emulate
the
code
of
conduct
file
or
a
license
like
attributing,
like
all
of
those
files
that
are
centralized
and
visible
and
people
kind
of
know
where
to
go
to
see
that
information.
A
A
It's
right
here,
so
this
is
kind
of
the
template
that
you'll
use,
Hugo
and
you're
gonna
take
this
file
and
then
really
change
it
to
be
applicable
to
your
project,
if
that
makes
sense.
So
this
is
a
starting
point
and
then
these
are
the
four
areas
that
we're
going
to
ask
you
to
describe
project
access,
communication,
transparency,
newcomer
experiences
and
inclusive
leadership,
and
if
you
click.
B
A
Any
of
these
it
gives
you
a
little
more
context
about
what
that
is.
Maybe
there
we
go
so
essentially.
To
what
extent
does
your
project
provide
access
and
help
those
with
various
access
needs,
and
that
can
it's
a
pretty
broad
definition
right
now
of
access,
so
we're
looking
up
things
like
not
just
accessibility,
but
also
can
people
even
get
to
your
platform
and
tools
that
you're
using
you
know,
is
your?
Is
there
anything
that
keeps
people
away?
A
What
kind
of
non-code
contributions
are
you
supporting
and
recognizing
and
translations
things
like
that?
So
it's
pretty
Broad
and
there
is
really
no
right
or
wrong
answer
here.
We're
just
really
asking
projects
to
just
self-reflect
and
maybe
ask
these
questions
that
maybe
they've
not
asked
themselves
before
and
by
going
through
that
process
of
that
self-reflection
and
just
taking
time
to
really
think
about
what
you're
doing
in
the
project.
A
A
F
D
E
So
I'll
add
a
few
things
here,
Hugo
so
in
Elizabeth
said
all
of
this
before,
but
I
really
just
want
to
re-emphasize
a
few
things
so
for
the
dei.md
file.
If
you
saw
that
sample
had
like
a
b
c
d
e,
like
you,
don't
there's
no
number
that
you
have
to
have
it's
whatever
you're
doing
as
a
project.
So
we're
not
counting
that
you
have
to
get
to
e.
E
For
example,
it's
it's
whatever
you're
doing
as
a
project,
and
we
don't
evaluate
what
you
say,
because
whatever
you're
doing
as
a
project
is
something
that
you
are
reflecting
on
and
you're
sharing
it
with
your
community
members
and
really
the
evaluation.
A
lot
of
that
detailed
evaluation
is
meant
to
be
done
by
your
community
members.
F
It's
really
helpful,
I
think
it's
really
nice,
because
it
gives
us
a
framework
to
think
about
this
di
question
and
the
thing
that
I,
like
is
that
it
seems
more,
as
you
say,
like
more
personal
than
the
code
of
conduct,
so
I
think
it's
important
to
have
the
code
of
conduct,
but
lately
I've
had
the
feeling
that
some
project
tend
to
include
it
without
really
like
meaning.
What's
what's
inside,
so
it's
nice
to
have
something
that
is
a
bit
more
intentional.
F
Maybe
I
I
have
two
questions,
one
really
Technical
and
one
may
be
about
the
next
steps.
So
the
first
one
is
that
you
say
that
you
are
not
really
like
evaluating
the
content
of
the
file,
but
is
there
a
specific
format
that
we
should
follow
that
will
be
required
to
analyze
the
file
like,
for
example,
should
we
keep
the
specific
headers
or
I?
Don't
know
anything.
F
Okay,
so
just
I
I
should
just
keep
the
headers
and
then
the
rest
inside
can
be
free
text,
okay
and
then
the
other
question,
but
it
might
be
too
early
in
the
project.
To
really
think
about
this
is
that
I
would
assume
that
most
of
the
thing
that
we
write
for
a
specific
repo
is
probably
true
for
the
rest
of
the
repository
in
the
GitHub
organization.
So
some
some
some
of
these
files
on
GitHub,
like
the
code
of
conduct,
for
example,
can
be
set
at
the
organization
level.
F
F
E
B
E
F
E
A
I
I
think
so
that's
my
understanding.
I
know
that
Sean
and
and
Enoch
talk
about
this
stuff
a
lot
and
things
change
quickly.
So
I
think
that's
where
it
is
right
now,
but
yeah
like
I,
don't
think
I,
don't
think
they're
hoping
to
just
guess
where
it
is
so
I
think
that
for
now
yeah
you
would
have
to
tell
them
where
this
file
is
and
then
I'll
grab
it.
F
E
A
So
for
the
next
steps,
really
it's
just
you
taking
time
to
write
that
file
out
and
as
soon
as
you're
ready.
Then
we
can
take
it
in
we'll
scan
it
and
we'll
go
through
the
rest
of
the
process,
so
the
ball's
kind
of
in
your
court.
You
just
tell
us:
whenever
you're
ready,
you
can
send
me
an
email
and
if
we
do
have
the
badging
website
up
at
that
point,
we'll
point
you
to
that.
Otherwise,
we'll
just
kind
of
sneak
around
it
and
do
it
behind
the
scenes.
Does
that
make
sense.
E
E
Last
comment:
it's
just
so
you
understand
who,
on
that
report,
that
comes
back,
so
there
are
two
things
that
you'll
get
back.
One
is
essentially
a
check
to
make
sure
the
dei.md
file
is
present
and
it
exists
and
based
really
based
on.
That
is
what
provides
you
the
badge,
but
we
also
will
provide
you
a
report
based
on
a
repo
that
you
provide,
that
will
do
things
like
scan
for
inclusive
language
or
it'll
kind
of
give
you
insights
around
the
climate.
We
were
talking
about
earlier
this
as
an
example
of
your
community.
E
We
don't
pass
judgment
in
that
report.
We
don't
say
you're
doing
a
terrible
job
with
inclusiveness
or
you're
doing
great
with
just
be
again.
Every
Community
is
so
different,
it's
hard
to
know
what
is
good
and
what
is
bad
in
a
particular
community.
So
the
reporters
really
just
here
are
things
that
we're
seeing
and
it
may
be
useful
to
you
to
reflect
on
this
report
and
think
about
kind
of
what
you
see
in
the
report
and
how
it
might
be
improved
or
you're,
okay
with
it
within
your
community.
E
F
E
And
that
would
be
like
that's,
then
your
judgment
call
to
make
from
the
report.
Not
our
judgment
call
to
make
from
a
scan.
It's
just
trying
to
provide
you
more
information
where
you
can
and-
and
it's
part
of
that
report
too,
we
I
think
we're
intending
to
provide
like
here
are
some
suggestions
of
things
you
could
do
if
you're,
if
you're
not
liking
the
numbers
that
you're
seeing
with
respect
to
whatever
it
might
be
so
here's
some
some
data
that
might
help
you
and
here's
some
things
you
might
do
to
make
improvements.