►
From YouTube: CHAOSS Common Working Group 2/17/22
Description
Links to minutes from this meeting are on https://chaoss.community/participate.
A
All
right
welcome
to
the
february
17th
chaos
common
work
group
meeting.
So
if
you
could
add
yourself
to
the
minutes,
that
would
be
great
I'll
share.
My
screen
here.
A
So
hopefully,
you're
all
doing
well
got
a
couple
things
that
I'd
like
to
get
through
today.
So
first
is
I've
created
a
project
board
similar
to
like
what
we
have
in
dei
and
I'm
finding
this
pretty
useful
in
terms
of
kind
of
tracking
the
work
that
we're
doing
mm-hmm.
B
B
A
A
So
really
it's
just.
We
have
just
a
couple
metrics
in
progress
as
you
can
see
here,
and
we
have
one
that
we're
revisiting,
I'm
not
sure
if
the
knob
I'll
be
here
today
in
kind
of
an
open
discussion.
So
I'd
like
to
take
a
look
at
a
few
of
these
and
we
can
talk
about
these
metrics
as
well.
A
The
the
other
thing
that
we
did,
or
that
I
did
was-
I
aligned
our
label
structure
in
line
with
what
is
going
on
in
dei.
So
this
is
the
same
set
of
labels
and
we
have
now
in
dei
our
working
groups
had
kind
of
started
to
separate
in
terms
of
how
we
do
labels.
A
A
Okay,
one
of
the
things
that
was
a
bit
of
a
hassle
in
doing
this
is
because
I
was
trying
to
do
this
right
before
the
meeting
is
just
copying
labels
from
one
working
group
to
another
working
group
yeah.
A
B
A
Do
that?
Okay,
I'm
not
sure
we
can
have
issue
templates
in
the
dot
github
directory
and
pull
request
templates,
but
I'm
not
sure
if
we
can
have
labels.
A
B
B
I
I
was
making
a
note
to
do
it
but
yeah.
Let
me
take
a
look.
E
Matt
I
have
a
related
question
mm-hmm,
some
of
the
stuff
we're
putting
in
the
dot
github
template
so
like
that
will
also
apply
to
all
the
gremore
lab
repos
right.
A
Things
so
from
what
I'm
understanding,
as
I
played
around
with
it
more
this
week
too,
hold
on.
Let
me
just
finish
this
note.
A
I
mean
so
far
the
only
things
that
the
only
thing
that's
in
there
right
now
is
the
code
of
conduct
which
is
consistent
across
everyone
anyway.
E
Yeah
yeah
that
thinking
of
the
labels
and
making
them
standard
across
all
of
the
repos
also
was.
I
know
we're
not
doing
that,
but
that
kind
of
jogged
my
memory
a
little
like
oh
yeah,
that
will
also
apply
to
them.
So.
A
And
I
do
know
that
you
can
overwrite
from
the
dot
github
repo,
so
you
have
the
ability
within
your
local
repo.
But
if
you
have
a
document,
okay.
E
A
Is
coming
from
the
dot
github
repo,
but
I
don't
know
what
that
would
look
like
from
a
an
issue
or
a
pull
request.
Template.
A
So
I
maybe
I
should
play
around
with
that.
A
little
bit
like
have
a
few
issue
templates
in
a
repository
and
then
put
some
issue
templates
in
the
dot,
github,
folder
and
just
kind
of
see
what
it
looks
like
and
what
happens.
A
A
C
B
A
A
It
out
great,
thank
you
all
right,
any
other
questions
on
this.
A
No
all
good
all
right.
The
next
thing
just
kind
of
from
this
is
common
like
these
are
the
common
process,
things
across
the
group.
We
have
this
data
use
awareness
statement
and
I
had
pointed
out,
maybe
in
the
community,
call
that
we
had
like
five
elizabeth,
I
found
another
document.
There
were
like
six
documents.
Oh.
A
A
B
A
D
A
D
No,
I
I
guess
I
guess.
The
only
comment
that
I
would
make
is
that
the
the
individuals
that
are
creating
those
multiple
documents
probably
aren't
on
the
call
right
now,
so
we
might
want
to
table
this
and
tell
those
individuals
are
are
here
for
the
discussion.
A
Yeah
sophia
actually
was
one
that
recommended
the
merger.
Okay
and
then
lucas
has
been
following
this
as
well
just
kind
of
in
this
document
as
I've
been
trying
to
bring
them
together
and
we've
been
chatting
in
slack.
D
A
Yeah,
so
that's
I'm
trying
to
yeah,
I
see
point
well
taken.
There
were
more
people.
There
was
an
ethics
document
that
had
like
emma
was
on
it
and
I
think
george
was
on
it
too,
and
I
should
probably
ping
them
as
well.
A
All
right,
so
so,
okay,
so
with
respect
to
this
document,
could
y'all
take
a
look
at
this
for
a
second,
so
the
top
is
we
obviously
we
can
add
more
here.
The
top
is
just
a
lot
about
like
what
this
is
about
and
how
to
contribute
to
this
thing
and
who
we
are
so
then
there's
a
section
on
privacy,
confidential
data
and
metrics.
It's
a
like
why
privacy
cares
or
why
privacy
matters
in
this
case
things
to
consider
around
privacy.
A
So
then
we
have
a
section
on
ethics
and
I
followed
the
same
header.
So
this
is
bad
because
because
we
have
the
same
sub
header
twice,
but
so
we
need
to
differentiate
these
two
things,
but
confidential
data
and
metrics
just
talking
about
what
ethics
is
in
this
context,
guidelines
and
considerations.
So
you
see
I'm
just
kind
of
following.
I
would
like
to
call
this
things
to
consider.
A
A
E
B
B
I
haven't
been
editing
it
this
week,
but
last
week
I
I
made
some
edits,
then
you're
good
and
that's
been
been
captured.
Yeah.
I
noticed
when
I
opened
the
old
one
up
yesterday
that
it
was
a
pointer
to
this
document
now.
So
yes,
so
I
just
I,
we
need
to
get
everything
and
if
we
need
to
split
this
like
we
do,
we
don't.
B
A
I
was
not
clear
about
what
happened
there
all
right,
and
there
is
in
this
list
too
some
of
the
ethical
stuff.
I
do
think,
there's
some
privacy
components
in
here
as
well.
C
G
E
E
A
Probably
all
right
like
this
is
great
there's
comments
going
on
right
here.
My
other
thought
was
what
do
people
think
of
like
this.
B
A
D
I'm
not
a
I'm,
not
sure
if
we,
if
we
host
it
on
the
website
or
if
we
just
link
to
it
from
the
website.
I
think
that's
one
of
the
one
of
the
big
design
considerations
we
have
when
we're
revamping
the
website
is
kind
of
simplifying
things
and
making
clear
paths.
D
So
in
general
I
would
say
this
document
could
exist
on
the
website
kind
of
the
same
way,
a
code
of
conduct
or
a
mission
statement
could
exist,
but
until
we
get
into
the
the
design
of
the
website
and
what
the
kind
of
the
simplification
and
those
clear
paths
mean,
I
I
don't
know
if
it
would
live
on
the
website
as
a
as
a
document.
D
It
might
just
live
on
the
website
as
a
link
and
if
it
does
live
on
the
website
as
a
link,
if
it's,
if
it's
linked
from
every
single
metrics
page
and
possibly
linked
from
that
there
is
a
data
ethics
disclaimer
on
the
yeah
on
the
main
metrics
page.
So
if
we
link
it
there
as
well,
then
we're
talking
hundreds
of
links
to
this
document
from
the
website
and
at
that
point
it's
do.
We
really
need
to
host
it
on
the
website.
D
So
just
something-
and
I
don't
have
an
answer
to
that
yet
I
think
I
think
that's
an
answer
that
we
will
figure
out
when
we
start
to
simplify
and
revamp
the
website
cool.
A
So
then,
from
a
simplicity
perspective,
we
have
the
chaos
privacy
policy
document,
which
is
the
document
that
talks
about
how
we
as
a
chaos
community
handle
data.
And
then
we
have
the
document.
That
is
the
one
that
we
were
just
looking
at,
which
is
basically
telling
others
who
use
metrics
things
that
they
should
think
about,
and
then
we're
done.
D
A
A
D
A
All
right,
thank
you,
everybody.
The
first.
F
A
All
right
any
other,
it's
a
good
question,
any
other
comments
or
questions.
A
All
right
elizabeth,
this
next
one
is
one
that
you
had
put
in
here.
The
item
for
discussion:
do
you
want
to
talk
about
that.
E
Oh
yeah,
so
you
know
talking
about
the
handbook
at
in
the
community
meeting,
it's
kind
of
maybe
becoming
an
issue
when
we
do
have
google
summer
of
code,
students
or
other
mentor
mentored
students
that
work
on
really
crucial
stuff,
that
you
know
we
use
a
lot
and
we
love,
but
then
they
leave
and
we
never
see
them
again
so
like
we
need
to
maybe
have
something
in
place.
That's
like
a
sharing
of
knowledge
or
like
a
handing
off
or
something.
E
I
know
we
have
like
mentors
that,
supposedly
are
you
know,
involved
in
the
project
and
kind
of
know,
but
it
feels
like
maybe,
but
that,
like
those
mentors,
don't
necessarily
own
that
project,
so
the
project
just
kind
of
is
left
without
an
owner
or.
E
Of
yeah
and
like
you
know
just
that
person
really,
we
need
also
someone
to
step
up
and
say
I
will
take
this
on
in
their
place
if
they
should
leave.
D
I
was
going
to
say
documentation
around
the
code
and
process
is
probably.
We
should
probably
make
that
a
requirement
for
all
google
of
summer
of
code
projects,
if
it's
not
already.
A
D
Or
I
don't
so
I
don't,
I
don't
know,
what's
expected
for
all
google
code
projects,
so
I
know
in
the
in
the
google
summer
of
code
project
that
that
I
mentored
that
yash
was
on.
We
spent
a
considerable
amount
of
time
documenting
the
process
and-
and
I
believe,
josh
and
rutik
also
created
documentation
around
the
software
itself,
the
mars
mars
software.
D
So
now
I
don't
know
if
that
is
common
in
the
other
google
summer
of
code
projects
gotcha,
but
it
should
probably
be
required
for
all
of
the
google
summer
code
projects.
If
it's,
if
it's
not
gotcha,.
A
I
might
also
like
to
ask
we
could
ask
these
in
the
the
application
process
like
kevin
to
your
point
like
these
are
the
things
that
are
going
to
be
expected
of
you,
and
maybe
it's
your
point,
elizabeth.
We
could
ask,
maybe
maybe
not
quite
like
an
exit
interview,
but
you
know
one
of
the
things
that
you
need
to
do
as
a
mentor
and
a
mentee
is
think
about
how
this
is
going
to
be
handed
off
to
the
community
like
what
working
group
this
would
live
in.
E
D
In
general,
I've
found
that
things
that
have
utility
things
that
people
are
using
are
maintained
and
paid
attention
to.
So
if,
if
there
is
a
lack
of
interest
in
maintaining
it,
I
I
suppose
we
might
question
whether
or
not
we
need
it.
A
G
E
Yeah
and
you
know,
as
a
community
manager,
I
kind
of
feel
like
that.
Maybe
should
have
been
my
responsibility
to
kind
of
keep
track
of
that
and
I
did
not
at
all
so
so
whoops
my
bad
but
yeah.
I
think
you
know
and
I'm
you
know
even
thinking
of
things
like
the
dei
badging
stuff.
We
we
kind
of,
do
have
a
plan
in
place
now,
but
you
know
like.
C
E
D
No,
no,
I
think
that's
that's
a
good
comment,
though
I
I
don't
think
I
suppose
I
suppose
on
on
reflecting
reflecting
on
that.
We
aren't.
We
aren't
that
good
at
path
to
leadership
as
a
as
a
project,
and
that
that
is.
That
is
something
that
we
could
probably
do
better
all
right.
E
I
have
no
idea,
I
think
that
as
kevin
suggested,
adding
it
to
the
the
requirements
for
the
gsox
students
coming
up
or
any
other
mentorship
like.
If
we
do
the
she
code,
africa
would
be
the
same
and
in
the
meantime,
though,
the
one
project
that
kind
of
stands
out
to
me
is
the
handbook
so
I'll.
Take
that
and
just
kind
of,
as
like
the
maintainer
of
it
in
general,.
E
I
do
not
care
at
all
like
I'm
not
going
to
make
more
work
for
myself,
so
I'm
going
to
leave
it
just
right
where
it
is
for
now,
unless
we
want
to
move
it
in
the
website
redesign,
if,
if
you
want
to
put
it
somewhere
else,
totally
fine
with
me,
I
have
no
strong
feelings
about
that.
D
I
mean
there
there
would
be
some
value
in
in
presenting
it
on
on
the
website.
However,
I
I
don't
think
the
handbook
is
one
of
those
things
where
it's
useful.
If
people
continue
to
to
edit
and
add
things
so
wherever
we
wherever
we
keep
it,
it
should
be
very
accessible
and
open.
E
D
F
D
It's
this
it's
this!
It's
another
process,
we're
adding
that
that
kind
of
complicates
the
the
work
we
do.
E
F
Yeah
I
would
like
that
as
well.
Okay,
what
I
recalled
from
the
git
book
when
that
student
was
working
on
that
I
forgot
his
name.
Sorry.
E
F
I
just
got
that
the
goal
was
like
to
have
it
integrated
with
the
github,
because
we
we
do
all
our
work
on
the
github
and
kit
book
was
integrated
with
the
github,
so
we
make
changes
to
the
github
it
it
somehow
translated
to
the
git
book
automatically.
That
was
the
integration
he
did
it,
I'm
not
sure
how
he
did
it,
because
I
was
not
involved
in
that
project,
but
this
is
what
I
sense
it
like.
It
has
an
integration
with
the
github.
F
A
I'll
kind
of
second
kevin's
point
on
getbook.
You
know
if
I
think
about
the
technologies
that
are
used
for
the
tools
that
are
used
in
the
cast
project.
It's
largely
google
docs,
github,
slack
wordpress,
like
those
those
cover.
The
majority
of
how
we
operate
and
get
book
is,
is
the
one
a
little
out
of
band
on
that.
F
The
only
thing
that
I
was
suggesting
was
like:
we
just
do
the
work
on
a
github
and
it
gets
integrated
with
the
git
book
and
it
automatically
gets
updated.
That's
no.
D
I
understand
yeah
you're
correct,
I
think
the
and
I'm
sorry
to
interrupt.
I
can.
I
can
be
quiet
for
a
moment.
B
D
So
if,
if
the
documents
are
currently
completely
all
built
in
github
markdown
and
stored
in
in
markdown
repositories,
then
we
could
just
bypass
gitbook
altogether
and
in
the
website
revamp,
we
could
move
it
into
a
website
knowledgebase
so
which
would
eliminate
the
need
for
git
buckle.
This.
A
Great
thank
you
for
that
all
right,
so
we're
not
gonna
have
time
to
really
work
on
any
metrics.
At
this
point,
I
would
like
to
say
that
I'm
sorry
did
anybody
have
any
last
comments.
Elizabeth,
maybe
the.
A
Yeah,
the
one
the
one
last
thing
is
like
we,
there
needs
to
be
an
action
item.
I
think,
to
to
get
this
information
into
the
application
process
for
gsoc.
E
Hi,
who
would
that
be
you
sean
like
who
are
you
kind
of
yeah.
D
D
D
So
I
do
have
a
comment
about
the
since
we're,
since
we
are
looking
at
the
community
repo
and
the
handbook
in
there
and
we've
been
discussing
the
the
dot
github
repo.
D
D
Maybe
what
the
purpose
of
the
metrics
repo
is,
and
what
the
purpose
of
the
github
the
dot
github
repo
yes,
and
make
sure
that
we
know
exactly
what
those
three
I
think
those
three
repos
specifically
because
those
three
repos
would
all
be
kind
of
repost
that
support
all
of
chaos.
Right.
D
So
do
we
do
we
just
need
one
repo
to
do
all
those
things.
Do
we
need
the
three?
If
we
do
need
the
three,
we
need
to
be
very
clear
about
what
each
one
is
for
and
we
should
go
through
and
organize
them
to
accommodate
that
mission,
and
I
know
looking
at
the
community
repo
right
now,
there's
a
ton
of
good
stuff
in
there
and
there's
a
lot
of
templates,
but
it's
also
kind
of
noisy
and
hard
to
navigate.
D
So
I
would,
I
think
we
need
to
clean
it
up
a
little
bit
based
on
the
conversation
that
I
think
I
think.
H
D
E
H
A
Yeah,
probably
so,
did
we
do
it
via
slack.
A
D
D
A
D
So
I
kind
of
have
a
I
kind
of
have
a
thought
that
the
that
we
could
the
community
repo
itself
could
end
up
being
the
the
handbook.
D
So
perhaps
we
could
structure
the
community
repo
in
a
way
that
it
is,
would
match
the
the
headers
that
you
might
use
in
a
community
handbook
and
then,
when
we,
when
we
do
build
the
the
knowledge
base,
we
can
just
pull
these
documents
directly
in.
However,
the
maybe
the
the
design
of
the
community
repo
could
have
a
a
parallel
structure
to
a
community
handbook.
D
And
then,
eventually,
when
we,
when
we
do
actually
populate
and
create
the
community
repo,
then
most
of
the
work
is
already
done.
Okay,
just
a
thought.
C
A
It's
just
I
will
say
I'm
you
know,
I'm
I'm
happy
that
we're
able
to
talk
about
these
things
in
a
working
group.
So
I
know
it's
taken
some
time,
but
I
also
think
that
it
kind
of
shows
that
we've
got
a
backlog
on
some
of
these.
These
types
of
community-related
concerns
and
when
no
working
group
really
picks
them
up,
they
don't
get
done.
They
just
don't
get
done
yeah.
So
there
are
a
couple
metrics
that
are
out
there
right
now.
A
Occasional
contributors
is,
I
think,
pretty
much
ready
to
go
so
we're
just
kind
of
moving
forward
on
that
one
vanad.
You
had
had
one
on
organizational
diversity
that
you
are
revisiting.
I
don't
know
if
you
have
any
updates
there.
Well,
nothing
there.
It
should.
A
A
So
these
are
the
other
two
time
waiting
for
submitter
action
and
time
waiting
for
reviewer
action.
They
are.
These
were
ones
that
had
been
worked
on
quite
a
while
ago
and
they
seem
to
have
stalled,
but
they
have
quite
a
bit
of
stuff
in
them.
F
Why
I'm
not
seeing
that
document
for
the
this
organizational
diversity
I
created
it
and.
G
It's
there
yeah,
you
are
in
the
main
chaos
yeah,
not
in
the
working
group.
Oh
no,
I
know
I
just
I
was
okay,
it's
there
without
going
through
all
this
okay,
okay,
I'll,
take
a
look
on
all
three
of
these
and
before
next
meeting.
Okay.
A
And
just
enough
for
these
two
of
a
nod:
it's
just
kind
of
reading
them
and
just
kind
of
getting
us
back
into
the
mindset
and
if
you
think,
there's
any
like
gaps.
Okay,
maybe
you
could
just
you
wouldn't
even
need
to
fill
them
in
but
like
just
where
you
think
there
might
be
a
gap
and
then
collectively
we
could
work
on
it
next
time.
Okay,.
D
So
we
may
want
to.
We
may
want
to
look
at
these
in
relation
to
the
other
time
to
slash
duration,
metrics
that
we
have
okay,
we
have
several
change
request,
duration,
okay,
I
got
it
yeah,
there's
time
to
close,
I
think,
yeah
time
to
close
time
to
first
response.
I
think
yeah
issue
response
time,
issue.
Resolution
duration,
so
it
looks
like
some
of
the
language.
The
language
is
different.
Okay,
in
how
some
of
these
are
named
and
probably
different
in
some
of
the.
F
B
Some
stuff
yeah,
I
already
edited.
I
got
some
labels,
the
label,
one
I
didn't
get
to.
Oh
yeah,
fine,
you
have
labels
and
we
have
some
metrics,
but
the
google
summer
of
code.
I
made
a
nice
little
clear
statement
about
you
should
document
everything
I
think
it
sounded.
I
think
it
sounds
a
little
parental,
but
that's
fine.