►
From YouTube: CHAOSS.Risk.July.28.2020
Description
CHAOSS.Risk.July.28.2020
A
About
that
part
of
it,
okay
welcome
to
the
risk
working
group
meeting.
I
will
put
a
link
to
our
meeting
notes
in
that
I
have
a
separate.
You
know.
I
got
real
fancy
and
created
a
separate
tab
for
a
separate
browser
window
for
this
because
then
I'll
share.
The
notes
here
is
the
link
to
the
notes,
and
I
will
share.
A
These
are
the
risk
working
group
notes.
Now
today
is
july
28th
you
can
see
that
I
just
entered
a
fake.
I
don't
know
if
any
of
you
know
who
robin
yount
is.
He
was
a
player
for
the
milwaukee
brewers.
He
started
in
the
major
leagues.
The
age
of
18
was
the
mvp
a
couple
of
times:
one
lost
a
world
series
in
1982,
etc,
etc.
A
A
It'll
be
the
shortest
baseball
season
ever
but
enough
about
copied.
So
the
things
I
I
have
on
the
or
we
have
on
the
agenda
that
I
kind
of
carried
forward
from
last
time
and
are
take
classification,
work,
forks
and
some
discussions
about
pull
requests,
stakeholder
influence
and
code
complexity.
These
are
metrics.
We
might
be
able
to
work
on
during
the
meeting.
But
one
thing
that's
so
we
have
that
we
had
this
spreadsheet
of
that
labels.
How
many
times
labels
were
used
across
nine
different
collections
of
repositories?
A
I've
all
those
repositories
have
been
updated,
and
so
some
of
these
numbers
are
nearly
double
at
this
point.
What
they
were,
but
so
kate
went
through
and
did
a
classification
of
process
check,
solicitation
classification,
a
classification
called
classification.
Don't
confuse
me
affirmation
is
that
information,
yeah
affirmation.
A
Wider
while
it
seems
to
be
even
wider,
maybe
I
should
just
okay,
you
know
what
I'm
just
gonna,
wrap
format,
format,
text,
wrapping,
wrap,
okay,
and
so
this
was
kind
of
the
the
code
section
that
kate
developed
and
she
went
through
the
most
used
codes
and
and
put
them
in
a
bucket-
and
we
talked
through
this
at
one
of
our
prior
meetings
and
I
think
generally
agreed
with
the
classification,
but
one
of
our
questions
was
okay,
so
a
label
is
used
so
many
times,
but
sometimes
repos
are
dominant.
A
A
We
could
have
some
collections
of
repositories
that
include
a
small
number
of
overlapping
actual
repos
right,
so
more
than
one
party
might
be
interested
in
analysis
of
kubernetes,
throwing
them
out
there
again.
So
essentially,
this
is
on
the
collection
of.
I
have
to
look
really
quick
to
see
how
many
total
repos
are
in
that
collection.
A
I
believe,
there's
13,
000
repos
unique
repos
in
this
particular
collection
was
it's
just
a
sample,
and
so
these
are
the
ones
that
are
that
occur
in
the
most
distinct
number
of
repos,
and
I
think
I'm
not
sure
I
don't
know.
If
I
can
split
my
let's
see,
I
don't
know
if
I'm
able
to
split.
A
B
No
one
of
the
things
I
just
are
wondering
when
I
was
thinking
about
the
repo
pounds
is
you
tend
to
have
to
use
your
skin
cf
and
kubernetes?
They
tend
to
all
be
start
within
the
same
umbrella
and
I'm
wondering
to
what
extent
some
of
these
are
sort
of
like
those
umbrella
ones
in
the
same
umbrella
tend
to
share
same
cultures,
and
so
I'm
just
wondering,
if
that's
a
dimension
to
think
about
here.
A
E
D
A
A
And
to
kate's
point,
I
think
what
you're
suggesting
is
that
we
consider
which
of
these
buckets
well,
these
are
not.
These
are
so
these
are,
are
all
of
these
considered
cncf
projects
or
like.
B
Like
well,
cncf
isn't
quite
all
of
them.
I
think
I
think
these
are
you
know
parts
of
the
whole
ecosystem.
It's
an
ecosystem
mapping,
but
if
you
look
at
cncf
dot
projects
a
second
here,
let
me
give
you
the
link
in
the
chat.
A
I
think
they've
grayed
out
the
ones
that
are
not
cncf
projects.
If
I'm
looking
at
this.
F
B
E
A
E
On
that
page,
you
can
filter
by
their
relationship.
I'm
not
sure
if
that's
how
you
got
there
kate,
but
on
that
landscape,
there's
a
filter
on
the
left.
A
B
B
Yeah,
it's
basically
it's
been
put
under
the
cncf
and
it
has
incubation
which
is
what's
going
to
establish
the
set
of
cultures
around
it,
and
that's
why
I
was
thinking
that
there
might
be.
You
know,
common
behaviors
that
are
prescribed
for
cncf
and
then
therefore
the
tagging.
I
do
know
that
there
are
common
behaviors
for
things
that
are,
you
know,
being
packaged
for
debian,
and
you
know
working
inside
the
debian
ecosystem.
A
A
G
A
Yeah
and
yet
I
know
some
of
the
like
some
of
the
places
I
pulled
repositories
from
are
probably
is
that
for
undersea
cncf?
No,
no,
I
wouldn't
think
so.
Okay,
so
some
of
the
places
I'm
pulling
repositories
from
are
not
I
mean,
I
think,
there's
a
fair
number
of
them
that
are
not
cncf
projects,
but
also
a
fair
number
that
are
so.
A
I
should
look
at
that
for
sure
and
and
break
it
down.
I
guess
if
we
can
put
them
into
ecosystem
cultures,
that's
that
will
be
interesting
to
see
the
differences.
I
do
think
it's
useful,
though,
because
when
I
looked
at
when
I
looked
at
the
text
that
was
at
the
top
for
a
number
of
repos
using
these
things,
like
bug
enhancement,
I
don't
know
that
it
was
like
kind
bug.
A
A
How?
How,
because
the
questions
that
we
wanted
to
answer
with
these
labels,
kate
are
sort
of
they're
focused
on
how
you
know
how
effectively
they're
using
are
they
reinforcing
practices?
What
subsets
are
used?
Where
are.
F
B
B
A
B
B
You
know
the
next
meeting
all
right.
Just
I'm
sure
I've
got
the
links.
A
Yep
they're
in
the
notes
here
I'll
just
put
a-I-k-s
yeah
there
for
and
then
I
guess
maybe
I
should
put
that
under.
Like
another
bullet
that
says,
classification
of.
A
D
I
have
one
question
on
the
tags,
especially
the
bugs
and
criticals.
So
are
we
like
ascertaining
the
quality
of
quantity
like
more
bugs,
are
more
risky
projects,
less
bugs
less
risky
projects
or
the
type
of
bugs
that
stuck
in
the
riskiness
of
a
project
like
in
what
terms
are
we
are
thinking
in
those
categories.
B
A
B
H
I
have
a
question:
yeah
yeah,
it's
because
I'm
brand
new
to
this,
if
you
have
any
sort
of
documentation
methodology
and
how
exactly
you're
pulling
things.
I
know
you
mentioned
that
you're
counting
by
urls
versus
repo
names
like
that
was
just
one
little
thing
to
just
get
clarity
on
what
exactly
you're
looking
at,
because
that
might
help.
If
I
want
to
have
any
feedback
around
it.
H
H
I
was
just
thinking
as
we're
talking
about
what
could
be
indicators
of
risk,
assuming
I
guess
this
is
all
I
will
look
at
the
the
methodology
of
how
you
pulled
it.
So
I
can
know
what
to
ask
about,
but
I'm
assuming
there
are
certain
file,
types
or
branches
that
might
have
more
influence
than
others
in
terms
of
saying
where
the
bugs
are
like.
If
the.
H
Versus
something
that's
more
executable
than
that
potentially
has
a
difference
profile,
so
I
don't
know
how
much,
how
available
that
is
in
terms
of
what's
being
pulled
in
terms
of
file,
type
and
location
within
a
repo
and
functionality
of
what
that
thing
does
to
know
whether
or
not
it
should
be
of
higher
priority
or
not.
A
Yeah,
I
think
this
is
a
there's,
an
important
point
you're
making
actually
about
so.
The
the
methodology
is
we're
using
auger
to
pull
the
data,
and
so
we
have
and
what
I've
done
is
I've
taken
a
set
of
auger
repositories
and
I've
created
a
sort
of
a
meta
aggregation
database
that
pulls
them
all
together
into
sort
of.
A
I
don't
know
postgres
has
this
thing
where
you
can
make
tables
that
are
connected
to
tons
of
different
databases,
and
so
that's
how
I'm
doing
this,
and
so
that's
how
I'm
aggregating
the
13
000
in
this
set,
which
may
be
larger
when
I
go
actually
count
again,
but
I
think
making
that
transparent
is
really
important.
A
Yep
yep,
I'm
definitely
going
to
give
you
access
to
that.
I
think
providing
a
public
user
for
that
database
is
a
good
idea.
I
just
provided
the
first
public
user
for
an
auger
database
when
I
released
the
community
reports
project
earlier
this
morning.
So
where.
A
That
it's
in
the
chaos
organization,
okay,.
E
A
B
A
Yes
and
it's
it's
right
now,
it's
connected
to
k
like
the
I,
the
read-only
credentials,
I've
put
in
there
for
show
so
people
can
play
around
with.
It
are
just
two
repository
chaos,
databases,
but
as
so,
I
like,
I
might
not
publish
to
the
world
on
a
repository
the
credentials
for
a
read-only
user
on
a
metadata
base
that
spans
a
whole
bunch
of
auger
instances,
because
I
don't
wanna
have
to
buy
two
hundred
thousand
dollars
in
equipment.
A
But
I
think
sharing
it
within
a
working
group
is
something
that
can
be
easily
accomplished
without
sort
of
public
sharing
of
credentials,
make
transfer
and
publicly
available,
or
at
least
available
or
maybe
with
credentials.
A
And
so
I
mean
anybody
that
wants
the
credentials,
can
have
them
it's
it's
just
you
know
how
well
it
is
when
you
put
credentials,
you
can
read
only
stuff
out
there
on
the
internet.
Just
makes
me
nervous
and
so
there's
queries,
queries
that
I
I
use,
which
I
can.
I
can
share.
A
And
there's
also
yeah,
so
there's
some
other
things
we
do
with
auger
like
verify
that
we're
the
number
of,
for
example,
pull
requests
that
we
have
on
our
database
is
consistent
with
the
github
or
gitlab
metadata
about
the
number
of
pull
requests
or
issues
in
in
their
system.
You
know
so
we
kind
of
have
a
strategy
for
ensuring
data
completeness
as
well,
but
but
yeah.
I
think
I
think
I
don't
know
sophia.
Do
you
have
ways
that
you've
worked
that
make?
A
You
know
I've
worked
in
academic
settings
to
make
stuff
like
this
transparent
and
I'm.
What's?
What
do
you
think?
The
best
way
to
make
things
like
this
transparent
would
be
because
the
whole
auger
infrastructure
is
a
very
complex
data
collection
system
and
then
we're
pulling
data
out
of
that
complex
data
collection
system
and
the
complex
data
collection
system
is
transparent,
but
the
data
we
collected
is,
you
know
less.
H
Go
ahead,
I
think
I
mean
I'm
actually
working
on
a
similar
project
internally
and
it's
for
me.
I've
been
focusing
on
trying
to
just
sort
of
list
out
the
schema
and
sort
of
things
that
you
could
actually
look
at
within
the
database.
H
So
if
you
didn't
have
to
expose
the
tables
themselves,
but
knowing
the
types
of
tags
or
schema
or
categories
that
you
can
cory
against
and
then
generally
what's
in
it,
you
don't
necessarily
have
to
expose
the
database,
but
I
would
expose
potentially
the
query
so
that
you
can
see
how
you're
counting
and
what
you're
counting
and
then
knowing
the
query
itself
and
knowing
the
schema
and
schema
available,
then
I
can
ideally
extrapolate
what
else
what
other
things
you
could
run
on
top
of
the
same
database
like
I
think
for
me,
that
would
be
sufficient
to
get
an
understanding
of
what
it
is
and
how
you're
using
it
as
well
as
learn
from
that
and
potentially
expose.
H
H
Is
there
other
things
that
we
would
want
to
aggregate
into
it,
and
then
then,
I'm
less
familiar
on
the
limitations
of
whatever
could
support
in
terms
of
how
how
and
how
you
use
that
data
set
and
what
you
want
to
aggregate,
but
I'm
learning
so
I
got
to
start
somewhere.
D
A
B
C
B
Guys
offline
then.
A
And
so
the
other
things
is,
is
that
bernard
do?
Did
we
release
a
candidate
metric
for
forks
under
this
release
or
did
in
the
common
working
group,
or
did
we.
C
E
We
didn't
release
forks,
that's
that
one's
in
the
early
early
stages.
A
Okay,
and
so
another
one
that's
been
proposed,
is
stakeholder
influence.
A
C
F
A
F
A
A
A
A
A
H
Yeah,
so
I've
been
thinking
a
lot
about,
I
guess,
trying
to
think
about
privacy
lines
here,
but
mapping
out
dependency
points
within
a
project,
so
say
the
number
of
owners,
maintainers
approvers
that
are
getting
things
moving
forward
and
so
essentially
not
not
the
bus
problem,
but
more
looking
executionally.
How
many
people
are
in
that
path
and
how
much
that
changes
as
a
way
to
detect
whether
or
not
losing
that
person
will
disrupt
that
workflow
or
how
many
workflows
are
knowing
that,
I
guess.
H
Yeah
projects
slowing
down
or
getting,
I
guess
getting
hung
up
if
things
are
shifting
too
around,
but
maybe
this
is
just
a
hypothesis
that
I
haven't
looked
into
as
much
I'm
not
as
familiar
with
with
auger
and
the
chaos
tools
yet
so
I
think
for
me,
my
action
item
is
to
look
into
better
understanding
these
things
and
how
to
use
them.
I've
mostly
been
working
in
bigquery
and
github
data
sets
on
bigquery.
H
That's
what
I
have
accessible
and
that's
what
I
started
with,
but
I
realize
that's:
that's
not
the
only
point
of
information.
Actually,
your
comment
on
measuring
the
consistency
and
data
between
them.
We
know
that
the
archive
data
is
a
bit
lossy,
so
it's
not
necessarily
the
best
thing
to
look
at,
even
though
a
lot
of
my
initial
analysis
has
looked
predominantly
at
the
archive
event
stream,
and
I
I
can
tell
you
when
it
went
down
and
how
much
data
we
lost
recently.
So
I
know
it's
not
complete.
E
A
A
H
Yeah
going
down
is
not
the
biggest
problem,
I
think
it.
It
just
drops
things.
This
is
the
amount
of
requests
coming
in
sometimes
maxes
out.
I
guess
the
input
or,
however,
the
input
is
being
processed
by
the
server.
So
we
know
that
there
are
a
certain
amount
of
logs
that
are
dropped,
and
that
is
variable.
There's
one
point
in
time
when
some
of
the
analysis
on
it
and
found
up
to
20
of
logs
are
being
dropped
but
other
times
I
don't
think
it's
that
lossy.
H
So
we
just,
I
think
what
I've
been
mostly
looking
at
is
the
deviation
between
the
monthly
polls
and
the
yearly
equals,
and
we
are
seeing
deviation
of
the
hundreds
within
thousands
of
ratio
so
like
if
you're
looking
at
a
number
of
10
000,
then
in
the
monthly
database,
it
might
be
like
10
700.,
seeing
deviations
about
that
size.
Okay,.
H
H
A
I
think
those
are
very
risk
appropriate
questions,
because
there
are
some,
I
think
I
think
we've
historically
looked
at
what
is
the
likelihood
of
a
project
continuing
to
be
sustained,
but
there's
also
when
projects
are
very
important
and
evolving
quickly.
Are
you
know,
bottlenecks,
I
think,
are
another
risk
to
progress.
If
I'm,
depending
on
a
project,
continuing
to
make
forward
progress
and
it
doesn't,
then
then
that's
a
problem
so
yeah
I
can.
A
I
encourage
you
to
look
at
the
the
metrics
we've
released
just
to
see
what
what
kind
of
metrics
exist
and
also
I
will
I'm
trying
to
think.
A
Inside
of,
I
think
the
risk
notes
afterwards
I'll
just
include
them
as
part
of
the
risk
group
minutes,
even
though
they're
not
part
of
our
meeting
and
then
email
you
all
when
I'll
just
email
the
chaos
mailing
list,
one
that
that's
back
online
when
I
get
that
done
probably
tomorrow,
given
my
to-do
list
today,.
A
So
any
other
questions
that
anyone
has
on
risk
I
mean
we
have.
I
guess
code
complexity
is
another.
Is
the
final
outstanding
metric
that
we're
developing
and
that's
one
that
we
have
measures
for
it
in
in
auger,
so
we
have
a.
We
use
a
tool
called
scc,
which
is
a
which
employs
a
kokomo
algorithm
for
counting
complexity,
and
it's
in
a
table
called
repo
labor
in
augur
I'll.
Just
illustrate
that
really
quick.
A
It
would
not
be
a
lot
of
work
for
me
to
build
a
query
that
summarized
this,
but
essentially
it
goes
through
every
single
file
in
a
repository
and
calculates
the
number
of
lines
which
one's
our
code,
which
ones
are
comments
which
ones
are
blank
and
then
a
code
complexity
number
which
is
very
often
zero,
indicating
that's
a
pretty
simple
file,
but
some
of
some
files
are
more
complex
and
I've
seen
javascript
like
giant
javascript
files,
get
super
high
numbers
these.
A
These
complexity
numbers
can
then
be
used
as
a
proxy
for
calculating
relative
increased
labor
cost
of
maintaining
a
piece
of
software
or
developing
a
piece
of
software,
and
essentially,
when
you
find
a
non-zero
or
a
non-one
level
of
code
complexity,
the
more
of
that
you
have
and
the
more
lines
of
code
that
are
involved,
the
higher
your
labor
cost
for
maintaining
it
and
you
we
can
actually
store
that
as
well.
A
So
well,
if
that's
kind
of
where
the
risk
group
is
today
any
other
questions
or
topics
that
anyone
wants
to
bring
up
before
we
call
our,
I
mean
our
meeting
has
technically
eight
more
minutes
if
we
want
to
use
them
or
seven
more,
but
I'm
okay,
not
using
all
the
time.
I
do
not
feel
like
all
the
time
needs
to
be
used.
A
Yeah,
I
think,
with
the
to
do
items
that
I
have
here
and
that
kate
has,
I
think
by
my
you
know,
in
a
few
days
I'll
have
some
of
mine
done
and
by
the
next
meeting
kate
we'll
have
some
of
hers
done
so
we'll
start
to
develop
a
clear,
clear
picture
of
that
was
not.
A
That
was
not
mine.
That
was
a
develop,
a
clear
picture
of
yeah,
of
where
the
data
comes
from,
which
will
be
helpful
and.
A
Start
the
development
of
a
couple
of
metrics
and
try
to
move
some
some
of
our
metrics
towards
release
during
the
interim
period,
because
I
think
it's,
I
guess,
we've
got
three
more
days
left
in
the
current
review
period
for
metrics
and
I
don't
believe
we
released.
A
Well,
if
there's
anything
else,
I
guess
I'll
stop
the
recording
say.
Thank
you
and.