►
From YouTube: CHAOSS Common Working Group August 31, 2023
Description
Meeting minutes are here: https://docs.google.com/document/d/1xsii5tfmmDwWpuhrFcBJMeYeT3RipJdiCdHrbi0NalQ/edit#heading=h.h5pckeqsolv8
Meeting summary is here: https://chaoss.discourse.group/t/common-working-group-meeting-summary-august-31-2023/260
A
C
A
A
B
C
A
A
C
A
C
A
A
C
A
A
C
B
A
A
A
F
A
F
Yeah,
so
people
have
expressed
interest
in
it
because
the
drive-by
contributions
where
people
don't
ever
come
back,
they're
a
phenomena,
an
open
source,
and
so
we
call
them
second
time
contributions.
The
different
projects
thresholds
them
differently,
so
it
might
be
the
third
contribution
or
the
fourth
contribution
where
you
see
people
are
either
continuing
to
contribute,
and
it's
usually
you
know,
we
know
some
research
based
on
their
experience,
trying
to
contribute
the
first
couple
times
in
a
project
and
whether
they're
responded
to
or
their
pull
requests
or
ideas
are
welcomed
and
accepted.
F
So
I
think
it's
a
good
trailing
metric
for.
Are
you
effectively
welcoming
newcomers?
You
know
if
you
can
see
improvements
in
second
time
contributions
or
fourth
time,
whatever
you
call,
but
let's
call
them
second
time
to
keep
it
easy.
Then
I
think
I
think
you
know.
If
you
see
changes
over
time,
I
think
you
can
know
that
you're,
some
of
the
things
that
you're
doing
for
New
contributors
are
are
more
effective
okay
than
than
in
others,
and
so
that's.
F
F
C
A
B
Not
really,
but
I
do
think
it's
really
important
it
is
it
is,
you
know,
I,
guess
there
are
different
ways
of
looking
at
this.
You
can
look
at
it.
As
kind
of
you
know.
The
like
core
contributors,
casual
contributors,
regular
contributors
but
I,
do
think.
I
do
think.
It's
really
good
to
look
at
the
people
who
come
back
versus
people
who
just
submit
once
and
then
and
then
never
never
come
back.
A
So
if
there
was
a
kind
of
a
downward
trend
on
this
over
time,
where
like,
where
might
you
look
I
I
mean
personally
I
might
look
at
like
Risk
time
to
First
Response
on
some
of
the
PRS,
because
it
was
one
of
my
first
thoughts
and
it
was
actually
based
on
a
discussion
that
kind
of
you
had
put
together
earlier
Don
just
places
to
look
like
if
those
go
down
then
yeah.
It's
a
really
bad
thing.
F
B
And
then
I
would
also
look
at
other
other
potential
issues
within
the
community,
so
so
this
can
also,
you
also
don't
see
people
coming
back
a
second
time,
if
there's
a
particular
types
of
toxic
behaviors
going
on
in
your
community.
So
maybe
the
poll
requests.
The
responses
are
not
particularly
kind,
for
example.
A
F
E
F
A
G
G
F
Yeah
then
there's
you
know
it's
want
us.
You
know
one
assumes
some
constant
number
of
that
around
a
project,
so
I
think
the
second
time
contributions
when
you
do
things
to
welcome
newcomers
like
work
of
being
more
responsive
or
whatever
those
things
will
show
up
or
not
show
up
as
effective
with
the
second
time
contributions.
You'll
always
have
people
who
they
would
I
just
want
to
give
something
to
the
Upstream
so
that
it
works
for
them
yeah.
That's
that's
a
certainty.
A
A
C
A
B
A
Like
what
you're
talking
about,
then,
an
organization
could
understand
how
employees
are
engaging
in
a
project
if
it
was
merged,
pull
requests.
It
might
be
a
little
bit
more
along
the
lines
of
like
understanding
if
our
our
employees
can
actually
get
things
into
the
project
which
would
be
kind
of
a
different
View
yeah.
F
F
F
But
if
I'm,
a
community
manager
and
I'm
trying
to
develop
a
group
of
contributors
around
a
project,
then
I
I
care
about
that
more
or
if
I
work
in
a
company
and
I'm
a
community
manager
for
one
of
their
products,
and
we
welcome
outside
contributions.
Okay,
you
know
I
care
about
that
I
care
about
that
more.
If,
if
I'm
like
running
Twitter,
bootstrap
I
care
about
that
last.
F
C
A
A
F
A
F
A
D
So
there
is
a
little
bit
of
a
break
one
of
our
project.
Managers.
Catherine
is
going
to
do
kind
of
a
walk
through
on
how
GitHub
projects
works,
because
a
lot
of
us
weren't
that
familiar
with
it
or
maybe
just
had
like
a
high
level
knowledge
of
it.
So
she's
gonna
walk,
do
a
walk
through
kind
of
tutorial
with
us
on.
G
D
And
we
also
decided
that
we
we're
gonna,
have
we're
kind
of
under
the
maintainer
role
that
has
already
been
defined
by
the
governance
doc.
So
we
didn't
have
to
change
that
or
mess
with
that
at
all.
So
the
project
managers
were
hoping
for
two
per
project.
Just
so
there's
a
backup
and
they
will
be
listed
as
maintainers
on
the
repo
where
the
project
is
happening
and
where
the
project
board
is
also
going
to
live.
D
And
then
we
also
decided
it
would
be
great
to
have
like
a
technical,
lead
and
or
a
knowledge
lead
for
each
project.
That
is
more
responsible
for
the
actual
implementation
and
the
work
that
gets
done.
And
then
the
project,
managers
or
maintainers
will
just
collaboratively
work
with
that
person
to
make
sure
that
things
are
flowing.
If
they
need,
you
know,
help
or
advice
or
whatever
you
know,
whatever.
D
They
need
just
to
keep
things
moving,
but
the
project,
because
we
were
very
concerned
about
project
managers
being
overloaded
or
overburdened,
and
so
that's
why
we
decided
to
not
only
have
two
of
them
per
project,
but
also
have
make
sure
that
each
project
does
have
like
a
technical
lead,
so
that,
and
also
so
that
the
technical
person
doesn't
get
overloaded
with
managing
the
whole
project
as
well.
So
the
project
manager
will
help
figure
out
like
what
tasks
need
to
be
done.
Maybe
help
them
open
issues
if
needed.
A
C
D
As
far
as
going
forward,
we
would
like
for
if
somebody
has
an
idea
for
a
project
to
make
sure
that
we
do
have
project
managers
that
are
able
to
assist
and
keep
that
project
going.
So
we
are
gonna
next
time.
We
didn't
have
time
to
talk
about
this,
but
next
time
on
September
20th,
hopefully
we'll
have
time
to
talk
about
what
a
process
would
be.
D
So
if
someone
has
an
idea
for
a
project
or
they
want
to
do
something
that
we
have
like
a
set
process
and
it's
very
organized
and
clear
of
how
we
can
kind
of
get
it
on
the
books
so
to
speak
and
and
integrate
it
into
all
of
chaos
and
make
sure
that
it
has,
you
know,
kind
of
the
attention
and
the
resources.
If,
if
we
have
them,
we
make
sure
that
they're,
you
know
supported
in
that
idea,
so
yeah
that
was
pretty
much
it.
That
was
a
great
meeting
and
we
did
record
it.
D
D
D
A
D
C
D
Yeah
that
so
Enix
badging
bot
event
badging
bot
the
event
badging
website.
Those
are
separate
projects
and
like
right
now,
Kingsley
kind
of
is
the
only
one
having
to
manage
all
of
that.
You
know
all
of
the
whole
event
badging
website,
so
it
would
be
great
to
have
some
support
from
for
him.
So
he's
not
overloaded
with
trying
to
do
the
work,
but
also
Point
people
to
different
things
that
need
to
be
done.
A
A
D
D
In
the
what
comes
up
with
a
new
idea,
for
instance,
okay,
like
Anita,
had
an
idea
for
a
landscape
project
of
you
know:
here's
everything
so
that
in
itself
is
a
project
right
and
so
like
at
the
beginning.
We
would
need
to
define
the
scope
of
okay.
What
are
we
trying
to
do
here?
What
who's
involved
who's
going
to
be
the
leads,
and
all
that.
A
D
Just
but
also
have
a
little
bit
easier
time
for
newcomers
to
find
where
things
are,
because
sometimes
projects,
people
working
on
the
projects
are
so
involved
in
the
project
itself.
It's
hard
to
step
back
and
like
create
all
the
issues
for
all
the
things
that
can
be
done,
and
so
you
know
people
we
have
a
lot
of
people
willing
to
help,
but
you
need
that
kind
of
mediator
that
can
take
the
work
and
then
split
it
out.
If
that
makes
sense,
it.
H
A
C
A
A
A
B
I
think
kubernetes
there's
an
infrastructure.
Everything
in
kubernetes
is
like
a
special
interest
group
and
so
there's
a
there's,
a
infrastructure,
special
interest
group
that
maintains
all
of
the
infrastructure
that's
plugged
into
GitHub
and
slack
and
other
places.
So
there's
a
there's,
a
whole
team,
that's
kind
of
responsible
for
that
within
within
kubernetes,
okay,.
A
C
A
D
Oh
I,
just
sorry,
there
was
one
more
quick
thing:
I
wanted
to
say
too
we're
hoping
that
also
by
keeping
things
on
GitHub
and
opening
issues,
even
for
non-code
contributions
that
we're
going
to
be
able
to
track
and
surface
those
contributions
a
little
better.
That
still
seems
to
be
something
we
struggle
with
well.
I
know
I
personally
struggle
with
how
do
we
identify?
How
do
we,
you
know
surface
and
recognize
and
highlight
those
non-code
contributions?
Okay,.
C
C
B
I
did
just
look
at
the
kubernetes
infra
special
interest
group,
and
they
they
manage
a
lot
of
it
as
sub
projects,
so
they
have
sub
projects
for
for
various
things.
I
don't
see
the
Bots
listed
as
a
separate
sub-project,
so
it's
possible
that's
somewhere
else,
but
I
suspect
that
it's
I
suspect
it's
somewhere.
In
this
thing,
okay,.
C
H
H
C
A
A
H
So
it's
kind
of
it's
it's
actually
very
much
related
to
what
you
all
were
just
talking
about
when
I
came
in
so
with
the
with
that
project
management
group
coming
together,
I
do
I
kind
of
want
to
make
sure
that
we
understand
what
the
the
Common
working
group
scope
is,
so
the
the
question
I
would
have
for
all
of
you
is:
do
we
need
to
adjust
it?
For
example,
we
have
we've
been
kind
of
we
we
do
have.
We
did
have
just
now
an
update
from
the
the
project
management
group.
H
A
Good
questions
because,
in
part
we
have
50
minutes
twice
a
week
in
this
meeting,
which
is
not
a
whole
lot
of
time,
I
mean
so
I
think.
Maybe
your
first
question
was
like
where,
where
do
these,
some
of
these
discussions
get
surfaced
and
how
do
we
share
them
more
broadly
than
just,
for
example,
Within,
the
working
group
or
the
the
project
manager
meeting
it's
a
good
question:
do
people
have
thoughts
on
on
kind
of
how
we
structure
that.
F
A
A
C
A
H
That
is
kind
of
what
I
was
thinking
when
I
when
I
had
brought
it
up.
So
maybe
maybe
we
we
add
so
right.
Now
we
have
we
in
our
meeting.
We
have
a
context
group
liaison
updates
section
where
we
jump
through
the
the
different,
maybe
maybe
in
the
community.
We
add
a
tab
that
is
project,
project
management,
updates,
yep
and
then,
and
then
we
update
through
each
of
those
individual
projects
in.
H
Knowledge,
yeah
yeah,
the
knowledge
base
would
be
one
of
those
project
management
right
so
like
so.
Maybe
if,
if
this
is
gonna,
be
ongoing
for
any
period
of
time,
maybe
we
try
to
add
a
project
manager
to
it
to
help.
Oh
I
see:
okay,
that's
not
in
that
team
out
and
so
because
it's
a
project
right.
So
it's
so
so
we
would
kind
of
fall
under
that
purview.
Okay,.
A
C
H
H
Which
would
leave
comment
to
then
focus
on
metrics
and
models
and
and
models.
Is
that
that
other
question
absolutely
so
and
I
I
would
I
would
like
to
include
models
in
the
scope
of
common
as
well
and
and
maybe
treat
the
metrics
model
working
group,
basically
as
as
almost
a
context
group
kind
of
for
our
purposes
anyway.
I
know
they're,
not
they're,
not
a
context
group,
but
that's
that's
what
I
would
like
to
do,
but
at
the
same
time
I
would
defer
to
the
group
okay.
B
I
think
what
we
found
is
that
the
metrics
models,
when
you
start
to
put
them
together,
are
almost
always
missing
a
metric,
so
I
think
they
they
always
end
up
coming
in
here,
anyways,
so
I
think
doing
a
little
more
of
the
development
of
the
metrics
models
in
here
wouldn't
be
wouldn't
be
a
bad
thing.
Okay,.
A
H
H
A
A
All
right
so
then
we
would
still
do
the
context
working
group
updates.
Here
we
can
work
backwards,
so
app
ecosystem
I
do
think
we
need
to
find
a
liaison,
or
this
I
think
we
are
including
it
as
we
aren't
I
think
starting
to
include
it
as
as
a
context
working
group-
and
there
are
a
lot
of
metrics,
like
I,
had
said
that
you're
going
to
need
to
be
developed.
So
we.
D
A
A
F
C
A
A
C
A
What
was
there
was
a
better
word
than
that
again,
my
brain's
not
working
real
well
right
now,
but
just
as
is
kind
of
a
way
to
to
have
a
conversation
around
what
metrics
and
metrics
models
can
do
for
scientific
software
communities,
so
I
think
for
a
while.
We
had
kind
of
been
spending
time
on
that
framework.
A
Thinking
about
what
the
functions
and
the
goals
and
the
questions
the
metrics
were
when
that
might
have
been
a
conversation
that
was
a
bit
too
early
and
in
fact
we
just
needed
a
metric
model
or
some
metrics
to
just
kind
of
show
what
a
conversation
could
look
like
and
and
how
they
might
think
about
that
conversation.
So
that's
I
think
something
that
happened
in
scientific
software.
So
thanks
to
Melissa
and
Don.
E
E
G
A
A
C
A
Time,
just
thinking
about
what
that
framework
could
be
and
ultimately
getting
to
metrics.
So
it
kind
of
appears
that,
at
least
in
a
couple
of
these
different
context,
groups
we're
not
going
to
get
to
metrics
that
need
to
be
developed
for
probably
maybe
a
month
or
two,
as
as
we
kind
of
settle
on
a
framework.
A
E
E
A
Okay,
my
my
big
takeaway
I,
think
from
from
University
at
least
for
common
working
group,
is
there's
they're
really
different.
Even
scientific
software
and
corporate
hospital
I
can't
speak
too
much
to
app
ecosystem
at
the
moment,
but
the
questions
they're
asking
are
just
really
different
to
me
than
what
are
being
asked
in
scientific
software
and
corporate
ospo.
A
There
are
I,
just
haven't
heard
a
lot
of
conversation,
yet
about
like
looking
at
the
health
of
communities
like
that
doesn't
seem
to
be
where
the
conversation
has
landed
too
much.
So
it's
things
like
how
do
we
support
the
research
promotion
and
tenure
process
with
respect
to
people
producing
open
artifacts,
so
yeah
play
a
role
in
that
which
is
just
really
different
than
like.
How
do
we
monitor
the
health
of
the
communities
that
we
rely
on
here
in
the
University
or
the
health
of
the
communities
of
things
that
go
through
the
tech
transfer
process?
H
That's
what
yeah
replacing
a
little
different
I
think
in
some
of
those
some
of
those
first
meetings.
We
we
kind
of
had
that
conversation
about
the
the
kind
of
the
distinction
between
Community,
Health
and
and
the
promotion
of
Open
Source
that
and
kind
of
that
organizational
level.
So
they
I
think
they
really
do
see
that
as
kind
of
two
different
things
mm-hmm.
A
F
H
C
H
Bad
yeah,
right,
I,
actually
I,
actually
think
it's
good,
because
there
there's
some
overlap
between
the
university
and
the
scientific
software
context,
groups
and
the
the,
but
the
the
differences
are.
Where
is
the
is
the
interesting
part
right?
So
the
scientific
software
group?
These
are
mostly
University
people
as
well.
However,
they
are
interested
in
community,
the
community
portion
of
it.
H
So
it's
it's
kind
of
more
a
matter
of
perspective
right,
so
the
the
university
group
is
is
coming
from
the
perspective
of
the
University
organization
and
the
the
scientific
software
group
is
coming
from
the
perspective
of
the
the
community,
so
I
think
it.
It
fits
well
and
prevents
prevents
too
much
overlap
in
those
two
groups,
so
yeah
I.