►
From YouTube: CHAOSS.Common.August.6.2020
Description
CHAOSS.Common.August.6.2020
A
B
Now
it's
recording
okay,
so
welcome
to
the
chaos
common
working
group
meeting
for
august
6th
for
people
who
don't
have
the
link.
I
will
drop
that
into
the
chat
unless
somebody
else
probably
already
has
I'll
do
it
again
in
case
other
people
have
joined,
since
we
did
that
we
don't
have
a
ton
of
stuff
on
the
agenda,
which
partially
is
probably
because
I
missed
the
last
meeting.
B
B
C
B
B
B
B
D
D
B
Yeah,
okay,
well,
we'll
leave
that
one
contributor
location,
so
we
have
this
matt
broberg
likes
it.
So
so
I
think
we're
done
I'm
just
kidding.
Is
there
anything
for
the
ones
that
didn't
have
any
comments?
Is
there
anything
we
really
need
to
do
to
review
them?
Oh,
these
are
nice
visualizations,
cool.
B
C
B
B
D
B
B
E
E
C
B
B
C
E
F
B
B
C
B
B
E
E
B
E
B
D
D
E
Okay,
I
think
if
it's,
if
the
edit
is,
if
the
edit
is
a
response
to
comments,
then
I
think
it's
completely
fair
to
put
new
stuff
in
or
to
edit
the
metric
but
yeah
as
you.
As
you
said.
If
this
is
just
if
this
is
kind
of
off
base
kind
of
a
different
thing,
then
I
suppose
you're
right,
it
probably
needs
the
30
day.
Although.
B
I
actually
think
it's
kind
of
fuzzy
right,
probably
I
don't
think
in
this
case.
It
needs
a
30
day
because
we're
not
changing
anything
about
the
definition
of
the
metric,
we're
just
showing
two
additional
visualizations
for
how
people
might
want
to
look
at
it.
So
we
didn't
actually
change
anything
about
the
metric,
and
so
I
think,
if
we
change
definitions,
then
those
absolutely
need
the
30
days
so
that
people
could
look
at
them.
C
C
B
B
Oops
see
stuff
goes
on
the
call.
She
probably
just
noticed
that
I
merged
these
without
my
correct
email
address,
because
we're
trying
to
get
everybody
vmware
to
use
their
vmware
email
addresses
when
they,
when
they
do
things-
and
I
just
I
just
didn't
in
front
of
front
of
the
person
that
tells
tells
all
the
other
people
to
do
it
now.
A
G
B
B
Okay,
so
we
got
the
pull
requests
taken
care
of,
and
then
we
got
the
issues
that
we
could
get
done
done.
Do
we
want
to
review
any
of
these
other
issues?
Some
of
these
were
kind
of
big
long
ones
that
we
occasionally
talk
about.
This
one
looks
a
little
bit
newer.
Georg,
is
this
one
that
did
we
talk
about
this
in
the
last
meeting,
the
one
that
I
missed?
B
Or
do
you
want
to
talk
about
this
now,
because
the
next
thing
on
the
agenda
is
going
through
the
pr's
and
issues
so
I've
just
transitioned?
Let
me
let
me
do
a
better
transition
back
up.
Does
anybody
have
anything
else
about
the
release
that
we
need
to
talk
about
before
I
just
transition
into
other
other
issues.
C
B
B
G
I
don't
remember
talking
about
it.
The
metric
is
about
the
do.
We
have
consistent
activity
levels
or
are
there
bursts
of
activity,
and
it
was
just
something
I
found
while
doing
research.
You
know
two
years
ago,
so
I
don't
actually
have
any
insights
to
how
useful
this
metric
is
or
if
anyone
needs
it.
It's
just
something.
I
came
across.
B
C
G
B
Yeah,
I
don't
know
if
it'd
be
it's
not
certainly
not
at
the
top
of
my
list
to
track,
just
because
I
suspect
that
some
of
our
stuff
is
probably
less
bursty
than
other
other
projects,
but
I
could
see
this
being.
I
could
see
this
being
really
interesting
to
track
around
repositories
that
have
to
do
with
things
like
like
events
or
things
that
have
like
distinct
moments
in
time
where
there
might
be
real.
A
B
Bursts,
I
remember
putting
some
of
the
repos
for
the
config
management
camp
website
through
course,
and
it
was,
it
was
definitely
bursty.
There
would
be
like
a
burst
of
activity
when
we
released
the
agenda
burst
of
activity.
When
you
know
during
the
event-
and
there
were
all
of
these
all
of
the
stuff
in
that
project
was
extremely
bursty,
so
yeah
it
might
be.
It
might
be
interesting
for
some
projects.
F
C
B
Yeah
yeah,
it
would
be
interesting
to
look
across
yeah.
It
would
be
interesting
to
look
across
groups
of
projects
if
you
look
at,
like
I
don't
know
like
cncf
projects.
Is
there
anything
that
happens
right
around
around
kubecon
or
is
there
anything
that
happens
like?
Is
there
a
specific
thing
that
happens
during
the
year
that
might
generate
more
interest.
A
C
C
H
C
B
B
B
A
C
B
C
D
Okay,
yeah
and
burstiness,
like
in
the
language
of
what
auger
auger,
would
identify
burstiness
as
an
anomaly
like
if,
if
there's
like
periods
in
the
project
that
fall
outside
of
some
norm,
then,
and
particularly
if
it's
like
an
annual
event,
that
would
probably
just
show
up
in
an
anomaly
detection,
algorithm
yeah.
But
you
don't
even
need
a
fancy
machine
learning
algorithm
to
go
and
look
and
see
the
number
of
commits,
pull
requests
or
whatever
rises
at
one
time
of
year.
All
right,
like
you
know,
you
don't
need
no
fancy
computing
to
do
just
chat.
B
A
B
A
B
So
this
is
it's
all
around
email
addresses
and
organizational
affiliation,
which,
as
we
know,
is,
is
hard.
That's
the
hardest
hardest
one
to
get
right,
so
there
are
just
a
whole
bunch
of
comments
about
about
that
and
identity
management
and
that
that
sort
of
thing
I
know
I
have
next
on
the
agenda
to
review
the
action
items.
But
since
we
were
talking
about
the
spreadsheet,
maybe
we
just
quickly
do
a
review
of
the
metrics
spreadsheet.
Do
you
want
to
drive
that
matt?
Since
you
were
just
updating
it.
C
D
C
B
C
B
B
C
B
C
A
C
E
B
C
A
D
D
C
D
D
B
D
F
D
B
D
I
G
D
D
Is
there
another
group
that
is
looking
at
lines
and
files,
because
all
of
the
all
of
the
metrics
that
are
sort
of
directly
related
to
committing
code
exist
in
evolution,
and
so
this
was
more
of
a
question
about.
Do
we
include
it
in
this
working
group
or
does
it
should
be
an
evolution?
I
have
no
religion
either
way.
I
think
I
think
I
just
pointed
out
it
lots
of
this
kinds
of
stuff,
and
if
you
go
to
the
evolution
tab,
there
may
actually
be
a
metric
candidate.
D
B
Well,
I
think
you
know
we
haven't
started
this
in
the
I
mean,
there's
no
document
linked
to
it.
I
think
we
just
keep
talking
about
it
here
in
common,
and
I
would
say
that,
if
you're
farther
along
in
evolution
and
you've,
already
included
this
in
some
other
metrics,
then
it
probably
just
makes
sense
not
to
do
it
in
common
and
just
leave
it
in
in
evolution.
If
that's.
B
D
D
D
B
G
B
Yeah,
let's
do
that.
I
mean
I
think
daniel
was
involved
because
grimoire
lab
already
did
this
and
he
would
just
happen
to
be
in
the
discussion
when
we
were
talking
about
it,
but
I
don't
think
he's
actually
done
anything
on
it.
Okay,
it
might
be
worth
just
reaching
out
to
him
and
letting
him
know
that
we
moved.
We
moved
the
metric
to
evolution
so
that
if.
C
B
D
B
B
B
C
C
C
D
D
C
G
D
D
And
that
might
be
pull
request.
We
might
end
up
calling
that
poll
or
review
files
we're
still
in
discussions
about
whether
we
can
change
the
name
of
reviews
to
full-size,
merge
requests
and
and
the
real
the
thing
we're
discussing
in
evolution
as
you've.
All
we
talked
about
this
in
the
common
college,
making
sure
that
we're
conceptually
consistent
and
incorporate
garrett
appropriately,
because
it's
it's
code,
review,
request
or
code
change
request,
whatever
they
call,
it
is
kind
of
like
a
pull
request
and
kind
of
like
a
commit,
but
it's
only
ever
one
commit.
D
So
there
are
parts
of
it
that
are
conceptually
different
and
other
parts
that
are
conceptually
similar
to
a
pull
request.
So
we're
just
trying
to
figure
out
what
that
meant.
What
a!
What?
What
that
metric
pull
request,
merge,
request,
review
request,
means
in
garrett
and
if
it
means
something,
that's
the
same
or
different
or
whatever.