►
From YouTube: CHAOSS D&I Working Group Meeting 1-13-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
B
B
So,
let's
see
we
I'm
sharing
my
screen,
so
you
can
all
see
what
I'm
looking
at.
Let's
start
with
pull
requests.
22
days
ago
lawrence
opened
patch
2..
B
B
According
to
this,
commit
he
added
the
title:
question
description,
yeah,
but.
B
B
A
B
B
Here,
how
about
we
look
at
the
final
file?
Okay
files
changed.
D
It
looks
like
there
are
some
questions
that
have
been
removed
from
the
from
the
original
from
the
version
on
the
website.
Now.
A
B
B
A
Okay,
good
and
so
data
will
be
collected,
so
we
added
that
sentence
at
the
top
see
where
it
says
data
will
be
collected.
B
A
A
C
This
is
my
new
pet
peeve
of
old
issues
and
stuff
that
aren't
getting
merged
or
closed
out,
because
you
don't
know
if
things
have
been
resolved
or
not
yet
22
days
ago
I
mean,
could
we
have
done
something
in
the
meantime
check
the
logs
doesn't
look
like
it.
I
would
check
the
logs
itself.
It
might
may
be
that
most
of
his
comments
are
no
longer
valid
because
of
things
we've
done,
in
which
case
maybe
we
can
merge
any
changes
we
want
from
his
patch
into
what
now
exists.
C
Yeah,
so
maybe
he
just
has
a
really
old
fork
and
didn't
update
it,
in
which
case
I
would
maybe
explain
that
to
him
and
let
him
make
the
the
changes
again.
I
gotta
kick
a
chicken
out
of
the
house.
B
Fork,
it
looks
like
he
used
the
commit
that
we
had
on
november
11
and
then
added
his
own
comments.
I
see
and
then
where's
in
our
own
repository.
We
have
the
same
commit
from
november
11
and
we
have
one
more
from
december
16,
where
we
made
a
lot
of
changes.
A
A
A
C
A
C
C
E
B
C
I
just
think
the
process
really
sucks
and
I'm
so
into
how
garrett
does
it,
and
you
know
if
I
want
to
redo
it.
I
just
do
a
git
pull
master
origin
and
then
I
update
my
stuff
and
then
I
get
do
my
git
review
and
yeah
you're
installing
more
stuff
up
front.
But
I
think
the
whole
overall
change
process
is
a
whole
lot
nicer
than
doing
it
github
and
forks,
because
it
does
become
an
issue
and
he'll
never
know
that
his
fork
is
behind
when
he
goes
to
do
it.
F
B
F
So
if
I've,
oh,
if
I've
I've
created
a
brand
new
fork
in
my
if
I've
created
a
brand
new
branch
in
my
fork,
that
does
not
exist
in
the
github
forked
repository
you're
right,
you
github
will
not
create
that
same
fork.
You
have
to
merge
it
into
a
different
fork,
but
you
can
merge
it
into
a
different
fork.
That's
I
guess
so.
Okay,
sorry,
I'm
I'm
in
conversation.
I
had
school
pictures,
so
I'm
running
a
little
behind.
B
C
F
F
F
Yeah,
if
he
did
update
his
fork,
whatever
he
created
his
new
fork
off
of
he
created
it
off
of
an
existing
fork
in
the
main
repository
he
could
do
a
pull
request
from
whatever
fork
he
created
his
new
fork
from
and
then
do
another
pull
request
in
his
own
repository
to
update
it.
There
is
a
path.
C
A
B
A
D
Sorry,
I
was
totally
muted,
so
I
was
just
saying
in
different
focus
areas.
If
you,
if
you
go
to
the
to
like
to
go
to
file
or
like
the
search
for
file
within
the
github
repository,
you
can
find
metrics
that
are
kind
of
the
same
thing
in
different
places
like,
for
example,
if
you
search
issue,
you
get
issue
tracker
and
issue
label
inclusivity,
which
issue
tracker
looks
like
an
older
version
of
that
just
a
couple
metrics.
I
think
those
are
two
examples
that
I
found
quickly,
but.
D
Yeah
there's
just
I
I
noticed
I've
noticed
I've
been
noticing
them
like
left
and
right.
It
might
just
be
good
to
go
through
and
try
and
get
rid
of
the
ones
that
are
older.
B
D
A
placeholder
at
the
time
it
was
issue
tracker,
an
issue
tracker
inclusivity,
so
it
was
a
little
closer
to
duplicate.
In
that
case,.
D
Is
a
metric,
I
think,
still
yeah
under
project
and
community
documentation.
It's
just
it's
a
pretty
full
looking
metric
now,
but
almost
full.
A
So
hold
on
with
respect
to
issue,
to
guard
the
issue
issue
tracker
that
one
has
been
released,
so
I'm
cool
on
that
issued
tracker.
B
A
B
B
A
A
D
Is
there
a
way
we
can
avoid
getting
like
artifacts
from
migrating
to
from,
like
a
small
metric
like
a
template
to
like
moving
on
to
more
metrics
or
some
other
metric,
it
seems
like
the
old
one
seems
to
get
left
behind.
D
D
B
A
B
A
A
C
B
B
All
right,
I'm
gonna
reopen
the
issue
until
it's
executed.
A
A
B
A
A
A
It's
just
a
question.
I
don't
care
either
way
or
maybe
see
what
other
people
think.
D
B
C
B
Because
if
we
want
the
former
yeah,
we
can
create
a
markdown
file
with
ideas
and
link
to
the
issues
that
we
have
closed
and
occasionally,
if
we
go
through
the
issue,
track
and
move
things
into
the
markdown
file
and
close
them,
so
that
we
only
have
things
that
are
actively
being
worked
on
in
the
issue.
Tracker.
E
I
think
one
way
it
actually
might
be
helpful
to
have
these
ideas
and
things
that
aren't
fully
fleshed
out
in
in
the
issue
tracker
just
because
it
helps
make
some
of
our
discussion
a
little
bit
more
transparent
and
moves
it
out
of
the
google
doc
and
we
can
benefit
from
search
engine
boosts
with
the
discussions
and
make
some
of
the
stuff
that
we
just
talked
about
easier
to
move
and-
and
that's
also
something
that
we.
If
I
know
we
had
conversations
before
about
github
gitlab,
but
we're
not
necessarily
binded
the
platform
with
that
either.
E
I
think
it
might
be
a
helpful
way
to
get
some
of
our
work
more
out
wider
into
the
public,
and
maybe
we
can
look
at
using
something
like
a
project
board,
to
bring
better
clarity
into.
What's
being
worked
on
right
now
versus
the
things
that
are
more
backlogged
or
not
yet
discussed.
E
Yeah,
and
so
that
way
we
could
be
a
little
bit
more
free
free
wielding
with
the
amount
of
issues
we
have
open,
but
we
we
sort
them
and
organize
them
in
a
project
board.
So
it's
really
clear
like
what
are
we
actually
looking
at
week
by
week
or
what
things
are
coming
up?
The
usual
agile-ish
stand-up,
kanban
kind
of
workflow.
E
E
I
just
think
I
like
the
idea
of
trying
to
use,
use
the
issue
trackers
a
little
bit
more
as
discussion
points
just
because
our
notes
are
really
great,
but
sometimes
it's
like
when
I
try
to
think
of
things
that
we
talk,
we're
talking
about
like
in
a
meeting
two
months
ago
or
which
was
a
good
idea
or
something
we
we
had
in
discussion,
but
just
fell
off
just
from
the
holiday
or
whatever
it
is.
You
know,
might
be
a
good
way
to
keep
track
of
some
of
those
older
conversations
too.
C
G
For
the
for
the
column
headers,
I
believe
you
can
make
those
those
column
headers,
actually
the
tags.
So
if
it
gets
tagged,
the
issue
automatically
appears
in
the
column.
E
C
E
Something
that
gary,
if
you
want
you
and
I
want
to
workshop,
we
could
come
back
with
something
for
the
next
meeting
and
and
maybe
demo
it
do
like
a
proof
of
concept.
E
B
B
B
E
B
B
B
B
A
So
we
talked
a
little
bit
about
this
in
the
asia
pacific
call
today.
So
for
those
of
you
that
don't
know
we
we're
providing
chinese
and
spanish
translations.
A
So
what
were
what
we
proposed
in
the
asia
pacific
hall
is:
is
every
time
just
from
a
process
perspective
right
now,
all
of
the
metrics
have
been
translated
like
prior
to
december
1st,
so
any
metric
that
has
been
released
by
a
working
group
after
december
1st
has
not
been
translated
yet
see
what
I'm
saying
so
on
december
1st,
or
so
we
had
probably
55
some
odd
metrics
and
they
were
all
translated
to
spanish
into
english
and
those
are
going
to
be
part
of
the
release
in
a
pdf
come
march,
the
metrics
that
have
not
been
translated,
I'm
sorry,
the
metrics
that
have
been
released
after
that
initial
translation,
they
haven't
been
translated
and
I
think
that
the
aim
was
is
that,
because
they
are
whole
metrics,
we'll
still
use
the
service
that
we
have
to
do
the
translation.
A
We
wouldn't
ask
community
members
to
do
whole
translations
of
new
metrics,
and
I
wouldn't
do
those
translations
until
after
the
release.
So,
for
example,
just
because,
if
there's
any
changes
in
this
little
window
of
comment,
I'd
hate
to
do
a
translation
have
a
minor
change.
It'd
just
be
kind
of
a
hassle,
so
any
new
metrics
that
come
forward.
Basically
translations
will
always
lag
one
release
right.
A
So
then
that
I
can
handle,
irrespective
of
github,
that
doesn't
that's
not
what
this
repository
would
be
for,
so
what
this
repository
would
be
for
is
if
a
released
metric
has
a
minor
change
to
it.
So,
for
example,
a
sentence
was
added
or
a
description
was
updated
in
between
releases.
So
it's
it's
not
a
ton
of
change
that
occurred
on
the
metric,
but
something
subtle
that
needs
to
be
addressed,
and
this
does
happen.
A
A
B
B
G
Also,
is
it
a,
is
it
a
roadblock
to
release
if
we,
if
we
can't
get
the
translation
done,
do
we
not
include
that
metric
in
the
in
the
release.
A
To
george's
question,
I
guess
it
probably
makes
sense
to
do
the
lag
to
me
just
so
we
ensure
that
it
has
been
re-released
again
because
again,
comments
can
show
up
right
until
that
last
day
and
so
I'd
hate
for
a
group
to
do
a
pr.
A
B
A
For
that
next,
six
month,
window
yep
and
I
don't
think
we're
talking
about
a
ton
of
changes
here
right
I
mean
the
metrics
stayed
pretty
stable,
so
this
isn't
a
huge
amount
of
work
and
then
to
your
point,
kevin
if,
during
that
window
a
translation
didn't
occur,
so
there
was
a
an
issue
that
was
open.
That
says,
can
somebody
please
translate
the
sentence
in
this
metric
that
was
added?
A
A
G
Translation
that
just
hasn't
been
updated.
Do
we
do
we?
Do
we
just
say,
do
we
continue
to
release
the
previous
translation
or
do
we
just
say
nope,
not
until
we
not
until
we
get
the
the
new
translation,
even
though
this
metric
was
part
of
a
previous
translation
release,
I
would
just
say
it's
the
previous
one.
B
B
A
B
A
So
that
was
also
me.
We
can
start
next
week
with
this,
but
basically
what
these
two
points
are
is
you
know
we're
going
to
be
reaching
out
to
to
folks
externally
to
help
take
a
self-reflective
look
on
the
chaos
project
with
respect
to
our
own
dna
practices
and
then,
following
that
publish
the
methodologies
by
which
other
communities
could
do
the
same
right.
So
how,
as
a
community,
can
you
kind
of
reflect
on
your
own
dna
practices?
So
it's
kind
of
two
things.