►
From YouTube: CHAOSS.Common.April.2.2020
Description
CHAOSS.Common.April.2.2020
A
A
A
Go
ahead
and
get
started
while
people
are
doing
that
we
have
so
for
the
agenda.
We
have
a
couple
of
things
review
comments
on
the
metric
that
we
have
in
the
continuous
metric
contributions
feedback
cycle.
So
we'll
take
a
look
at
that
first
and
then
we'll
review
the
action
items
and
notes
from
the
previous
meeting
and
then
continue
working
on
the
time
to
close
metric.
B
A
A
A
Shawn,
do
you
want
to
talk
about
your
comment?
The
code
review
comment
and
I'll
go
ahead
and
open
this
up
to
so
that
we
can
see
what
the
metric
looks
like
whoops.
D
D
D
D
A
Maybe
we
just
add
that
as
a
bullet
under
coding,
because
we
have
coding
is
sort
of
like
a
bucket
and
we
have
it
says
could
be
separated
further,
which
I
think
is
true.
But
I
think
your
point
is
that
you
have
you
have
coding,
and
then
you
have
code
review
and
even
though
coding
as
a
bunch
of
categories
and
then
in
code
review,
is
a
separate
skill.
D
And
I
it's
but
I,
don't
think
it's
the
same.
It
so
I,
don't
think
like
it's
a
subset
of
coding.
B
A
B
B
A
A
D
A
A
D
A
B
No
I
mean
I,
guess.
I
owe
my
only
thing
with
common
is
I'm,
always
just
wondering
how
we
go
about
identifying
metrics
that
could
live
in
common.
Is
it
Commons
responsibility
to
do
that
sometimes
I'm
a
little
concerned
that,
in
the
other
working
groups,
they're
like
well
we'll
just
toss
this
over
over
to
common?
It
really
is
just
this
like
catch-all,
and
the
intention
is
not
that
common,
we'll
simply
do
the
work
and
but.
B
A
B
F
B
A
Think
I'm,
okay
with
that
like,
if
somebody
thinks
that
the
metric
belongs
in
common,
then
I
think
you
know
I
think
that
in
most
cases
so
far,
that's
always
that's
always
made
sense
and
it
hasn't
been
hasn't
been
really
an
issue.
I
do
I
do
agree,
though,
that
we
we
should
also,
in
addition
to
that,
also
be
proactive
about
defining
some
metrics
that
we
think
are
important,
so
I
think
organizational
affiliation
was
kind
of
like
that
and
sort
of.
F
A
E
A
Ones
that
are
you
know,
common
across
some
of
the
working
groups
and
I
do
think
that
we
should
make
an
effort
to
start
to
define
some
of
those.
So
you
know
anytime.
Anybody
wants
to
have
a
look
at
some
of
the
tools
and
some
of
the
metrics
that
we've
implemented
in
the
tools,
but
that
we
haven't
defined
yet
I
think
we
could
certainly
add
those
to
the
spreadsheet
for,
for
things
to
look
at
look
out
in
the
future
or
look
at
next
I
think
that's
certainly
legit.
Okay,.
B
A
You
have
a
couple
that
have
sort
of
started
like
the
contributor
location
and
employee-employer
location,
Google
Docs,
where
those
are
started,
but
not
released
lines
of
files.
I
think
that
one
came
from
the
grimoire
lab
schema,
which
is
kind
of
what
I
was
talking
about
before
tools
that
have
implemented
things,
but
that
we
haven't
used
language
distribution,
which
was
the
one
that
shawn
has
the
action
item
to
look
at
mm-hmm.
A
B
B
A
F
A
B
A
A
So
my
thought
was
that
I
think
we
started
this
in
the
last
meeting
and
then
yeah
just
kind
of
start
start
working
through
this
because
we've
we
have
a
bunch
of
stuff
in
implementation,
but
we
don't
really
have
anything
in
the
objectives
and
we
probably
want
to
talk
about
whether
or
not
the
descriptions
right
so
just
kind
of
that.
That's
sort
of
make
sense.
It.
B
B
B
B
B
A
D
D
A
F
A
Component
of
a
pull
request
so
and
like
in
in
github,
you
have
a
pull
request
and
then
you
do.
You
have
a
review,
that's
a
part
of
that
and
then
so
so
I
might
review
a
pull
request
and
like
kubernetes,
it's
like
something
a
markdown
file
and
I'll
be
like
you
know,
maybe
change
this
and
this
and
this
and
that's
like
a
review
and
then
the
person
goes
in
and
they
add
more
commits,
and
then
they
resolve
my
my
review
and
then
somebody
else
submits
a
review
with
different
different
things.
E
C
C
C
D
A
B
C
C
C
A
B
A
B
Doesn't
link
out
to
the
could
we
is
this
a
released
metric
I'm
always
like
it's
not
the
right
word,
but
like
kind
of
conscious
of
hyperlinking
in
documents
took.
C
A
Don't
the
links
change
for
the
newly
released
metrics?
So
what,
if
we're?
Really
if
we
link
to
it
in
this
release,
which
is
the
v2
January
release,
whatever
we
called
it?
When
we
issue
the
next
set
of
released
metrics,
this
would
point
to
an
old
release
of
the
metric.
No,
those
links
persist
on
the
website.
So,
if
we
link
to
it
on
the
website,
it
would
be
good.
Yes,.
C
B
B
D
B
B
I
guess
a
couple
things
we
can.
Is
everybody
good
at
least
just
drift?
Acting
around
these
points,
mm-hmm
more
points
couple
things.
One
is
a
larger
question
for
metrics
in
general.
So
right
now
we
are
inconsistent
on
how
we
represent
objectives.
So
sometimes
objectives
are
on
paragraph
a
narrative.
Sometimes
objectives
are
bullet
points
and
personally
I'd
like
to
start
standardizing
one
way
or
the
other.
So
if
questions
always
look,
the
same
descriptions
are
always
narratives,
I
think,
but
objectives
go
back.
A
C
B
E
B
Perhaps
we
could
go
through
who
wrote
the
bullet
point,
maybe
describe
what
it
is
know
quickly.
So
Shawn
you're,
you're
I
wrote
it,
but
you
know
those
are
your
words.
An
important
way
of
determining
how
responsive
a
community
is.
Mm-Hmm,
so
is
that
does
anybody
have
questions
on
what
that
means
are.
D
Mm-Hmm
so
I
I
guess
the
wreath
we
might
get
to
the
reason.
So
it
why
we
want
to
understand
responsiveness
is
there's
a
pretty
good
understanding
that
the
faster
a
community
responds
the
more
likely
new
contributors
are.
Aren't
you
to
continue
to
participate,
so
responsiveness
is
a
metric
that
that
seems
to
affect
how
well
you
capture
new
contributors
as
ongoing
contributors,
and
that's
one
of
I
think
that's
probably
the
main
reason
that
we
want
to
measure
responsiveness,
an.
D
D
A
Oops
I
was
talking
on
me,
which
is
related
to
the
one
that
that
I
wrote,
which
I
just
moved
up
next,
so
they
could
talk
about
it.
Cuz
it's
pretty
similar
and
maybe
maybe
duplicative
I
also
feel
like
it's
a
bit
judgey.
Then
maybe
we
don't
wanna
like
it's
kind
of
a
judgement,
and
maybe
we
don't
want
that
as
our
objective,
which.
A
A
A
D
A
D
Doesn't
it
doesn't
sound
judgey
to
me
because
it's
it's
I
mean
it's
it's
essentially
it's
an
elaboration
on
the
point
about
retaining
the
contributors
generally
and
that
does
have
an
impact
on
inclusivity
because,
as
we
try
to
attract
a
more
diverse
set
of
contributors,
doing
things
required
to
retain
new
contributors
will
have
an
effect
on
diversity.
Like
that's,
I
think
it's
a
matter-of-fact
statement.
I,
don't
think
it's
I,
don't
think
it's
judgy!
B
D
C
C
B
E
B
B
So
we
can
understand
if
there
are
particular
organizations
involved
in
the
long
ones,
which
may
be
an
interesting
sign
that
there
may
be
particular
people
involved
in
the
long
ones,
which
might
also
be
a
similarly
interesting
thing
to
understand
that
some
of
the
long
operations
perhaps
include
many
changes.
So,
for
example,
a
very
large
PR
that
we
may
need
to
work
on
yeah
you
just
whatever
those
characteristics
might
be.
It
might
give
us
a
way
to
kind
of
identify
areas
of
interest
within
the
project.
C
Know
after
you
explain
it,
but
just
reading
identifying
characteristics
of
operations
that
close
quickly
or
slowly
miss
does
not
give
me
enough
information
to
know
what
to
do
with
that
information.
Okay
or
why
so
I
added
some
of
things
that
you
mentioned
in
parentheses,
I,
don't
know
how
to
incorporate
that.
C
B
C
B
C
Idea
is
that
we
have
a
tendency
of
responding
to
people
who
we
know
and
trust
and
like
faster,
wears
sweet,
sometimes
even
more
newcomers
or
people
who
are
alien
or
people
who
don't
write
the
issue
of
pull
requests
in
a
way
that
we
like
to
see
it,
and
so
it's
a
stronger
hurdle
for
us
to
engage
with
it,
and
so
just
try
it
in.
For
that
bias.
A
A
B
F
C
F
C
B
C
E
A
A
A
B
B
C
A
C
C
A
B
F
B
C
F
Thinking
is
that
it
should
be
contributions
or
post
types
or
something
along
those
lines,
because
a
leading
indicator
of
burnout
for
any
user
across
a
community
starts
primarily
with
a
narrowing
of
their
use
or
value
that
they're
getting
from
the
community.
So
their
posts
start
to
move
down
in
diversity.
They're
not
talking
about
as
many
things
they're
talking
about.
One
thing,
then
that
one.