►
From YouTube: CHAOSS Risk Working Group 1/27/22
Description
Links to minutes from this meeting are on https://chaoss.community/participate.
A
A
C
B
D
Oh,
I'm
still,
no,
I
I'm
still
here
we
probably
call
them
gosh.
We
probably
call
them
bugs.
When
I,
when
I
I
was,
I
was
checking
for
reference
for
what
we
have
in
the
metrics
tracking
sheet,
which
has
bugs
in
at
least
three
fields,
and
then
you
called
my
name.
I
didn't
get
a
chance
to
search
for
defects,
but-
and
this
may
be
the.
A
A
So
the
thing
I
want
to
avoid
david
is
like
you
and
I
are
both
software
engineering
nerds
and
we
know
the
quantitative
meaning
of
defect
and
ieee
rules
like
I
teach
software
engineering
and
that's
the
word
I
use,
but
I
think
colloquially
the
word
in
practice.
People
who
are
not
as
big
of
software
engineering
nerds
as
we
are
pro
it
seems
like
they
might
use,
bug
and
recognize
that
term
more,
which
is
why
I
kind
of
asked
dwayne
what
he
thought
and
I
don't
know
I
would
guess,
kate.
You
are
also
yeah
and
use
defect.
A
C
E
E
B
Right
be
careful,
don't
issue
is
not
a
synonym,
but,
and
defect
is
a
synonym
well,
at
least
at
least
in
in,
I
think
they're
of
them
as
synonyms,
whether
or
not
other
people
think
of
them
as
the
synonyms.
But
I
would
prefer
defect
just
because
as
soon
as
you
enter
the
world
of
of
formal
stuff-
and
you
start.
F
B
B
F
F
B
A
A
C
I
don't
want
to
distract
the
writers,
but
I
think
dwayne
has
raised
a
good
point
in
the
chat
that
we
should
be
specific
to
software
defects
versus
other
issues.
That
could
exhibit
a
defectual
end
case,
but
whether
or
not
it's
part
rooted
in
the
software
versus
how
you
set
it
up
or
the
processes
and
integrations
you
set
around
it.
A
No,
I
mean
I
don't,
I
don't
think
so
like
when,
when
I
get
deployment
defect,
notices
regarding
auger
generally
they're
my
fault,
but
I
think
I
think
in
other
in
other.
There
are
many
other
cases
where
people
just
don't
actually
read
the
instructions
or
they
miss
a
line
and
don't
install
a
library.
So
I
think
that
that's
a
useful
distinction.
C
A
A
C
Yeah
we
leave
it
for
now.
Okay,
we'll
review
it
to
make
sure
that
it's
still,
it
doesn't
seem
like
there
are
any
issues
or
conflicts,
something
that
we
haven't
standardized.
Yes
in
this
approach,
I
guess
for
those
that
are
in
the
weekly
calls.
We've
been
trying
to
come
up
with
a
general
statement
to
encourage
people
to
notice
when
the
data
collection
required
to
generate
the
metric
could
be
potentially
putting
them
into
any
conflict
with
legal
policy
or
regulatory
policies.
C
So
we
have
a
general
disclaimer
now
and
given
that
a
lot
of
these
data,
the
data
required
to
collect
a
lot
of
these
things,
I'm
not
seeking
requests.
Sorry,
the
data
required
to
produce
these
metrics
could
increase
the
generation
a
lot
of
pii
and
additional
data
about
people,
in
which
case
you
are
in
sort
of
gdpr
land.
C
So
we
have
a
general
disclaimer
now
that
we're
sticking
into
metrics
and
we're
working
on
a
central
piece
of
documentation
that
will
provide
a
little
bit
more
suggested
guidance
without
being
overly
prescriptive,
because
clearly
we
are
not
lawyers.
We
are
varying
different
types
of
roles.
I
don't
think
we
have
any
lawyers
in
the
chaos
community
actually,
but.
C
Yeah
and
we're
actually
referencing
a
couple
of
lf
docs
that
have
come
up
already
in
terms
of
how
to
deal
with
export
controls
or
gdpr
within
the
contract
with
your
community.
So
we're
trying
to
again
again
try
to
generate
a
list
of
resources
available
and
just
encouraging
folks
to
have
responsible
and
ethical
metrics
practices.
B
Right
so
I'm
proposing
that
when
we
say
what's
the
defect
resolution
time,
this
is
this
is
basically
I
mean
for
our
new
folks.
This
is
kind
of
the
rubber
meets
the
road.
The
challenge
for
this
group
is
narrowing
down
exactly
what
you
mean
by
some
metric,
so
I'm
proposing
that
be
the
time
between
the
formal
report
of
a
defect
to
the
project.
B
B
A
B
D
B
We
want
it
to
be
fixed,
not
the
release,
time,
because
right
that
I
think,
is
too
way
way
too
coarse-grained
and
really
for
most
custom,
most
users
once
it's
fixed,
and
you
know
it's
going
to
be
in
the
next
version-
most
defects,
it's
okay!
You
can
live
with
it
for
a
little
while
and
if
you're
unhappy
you
can
wind
to
the
project
to
hurry
up
their
release
faster.
B
B
B
A
B
D
D
A
D
The
software
right
and
in
cases
at
least
in
cases
in
github,
where,
where
they're,
where
they've
tagged
it
and
it
automatically
closes
it
when
the
merge
lands
right.
Those
are
the
same
time,
but
if
they
haven't
there's
going
to
be
some
amount
of
time
that
elapses
between
a
merge
that
fixes
the
issue
and
the
verification
of
the
issue
actually
being
closed.
So
I'd
say
that
we
actually
are
pinned
to.
The
issue
is
closed.
That's
the
only
predictable
flag
that
we
have
that
says
it's
been
fixed.
B
Actually,
that's
not
true,
because
in
some
systems
yeah
this
is
the
this.
Is
the
joy
of
trying
to
nail
down
these
definitions?
We've
you
can
close
it
later
and
add
it
later
hey.
This
was
fixed
by
I've.
Seen
that,
and
in
that
case
a
tool
can
look
at
that
and
figure
out.
Oh,
it
should
have
been
closed
last
year
and
here's
the
evidence
for
it.
A
F
B
A
What
so
does
does
so
I
mean
this.
This
raises
a
question,
though,
if
because
we're
going
to
have
to
develop
a
metric
that
we
can
actually
measure
right
if
we're
hard
about
the
heuristic,
where
the
issue
has
to
be
tied
to
some
code
change
to
to
close
the
defect,
we're
going
to
have
defects
that
are
never
closed,
even
if
the
issue's
closed
and
on
the
other
hand,
so
that's
I'm
looking
at
the
rock
curve
here.
That
would
be
that'd,
be
a
false
negative.
C
Well,
I
mean
the
the
side
argument
here:
is
this
kind
of
up
to
the
implementer
how
they
designate
these
things
too,
because
we're
also
going
to
put
in
the
description
of
implementation.
That
really
depends
on
what
you're
doing
your
project
and
the
conventions
that
you've
outlined
and
within
that,
then
you
would
design
your
measurement
to
correspond
to
whatever
policies
or
automated
actions
are
being
taken.
C
B
A
B
A
B
B
A
A
A
A
B
B
E
A
Okay,
all
right,
and
so
thank
you
for
taking
care
of
that
vanad.
I
think
when
we
meet
again
in
two
weeks.
We
can
finish
this
metric
and
incorporate
some.
You
know
if
we
want
to
specify
example,
labels
or
whatever
I
do
have
a
couple
of
large
spreadsheets
that
apparently
google
won't
open
right
now
that
are
in
addition
to
the
old
ones,
so
I'll
make
those
available.