►
From YouTube: CHAOSS Risk Working Group Meeting 1-19-21
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
And
how
do
they
interpret
meetings
related
to
dependencies
and
maybe
I'd
I'd,
invite
dwayne
or
or
kate
to
or
david
or
whoever
wants
to
begin
to
just
sort
of
help.
Think
us
help
us
think
that
part
through.
A
Okay,
like
who
cares
like
what
groups
and
communities
are
interested
in
the
dependencies
work.
B
The
the
primary
angle
that
I'm
I'm
coming
into
this
work
and
the
primary
interest
that
I
have
in
this
work
is
to
help
indeed
and
other
organizations
I
identify
which
are
their
most
important
dependencies
to
support
and
what
are
the
most
effective
ways
to
support
those
dependencies.
B
You
know
looking
at
it
from
the
the
lens
of
the
open
source
program
office
when
you're,
when
you're
handed
a
an
inventory
list
that
contains
tens
of
thousands
of
individual
dependencies
that
are
somewhere
in
your
software
stack
and
you're
handed
with
the
other
hand,
you
know
a
request
from
the
maintainers
that
they
get
more
support.
B
It's
it's
very
difficult
to
cut
through,
maybe
not
to
the
to
the
top
5
or
10,
but
the
middle
or
like
the
top
50,
or
maybe
the
top
100
dependencies
that
you,
you
really
should
as
an
organization,
be
paying
attention
to
and
and
figuring
out
what
kinds
of
help
those
dependencies
are
asking
for,
so
that
you
can
mobilize
resources
from
your
own.
That's
the
that's
the
angle
that
I'm
I'm
interested
in,
or
maybe
the
facet
that
I'm
interested
in
viewing
the
problem
through.
C
A
Yeah
and
we're
glad
you
here,
you're
here
and
you've,
had
a
lot
of
perspective
that
you've
brought
to
the
discussion
and
I
think
what
we're
trying
to
do
now
is
narrow
down
all
of
those
perspectives
so
that
we
can
drive
towards
accomplishing
the
development
of
specific
metrics
and
possibly
tools
related
to
those
metrics
and-
and
so
I
don't
know,
I'm
right
now,
I'm
putting
this
under.
Who
cares,
but
what
what
dwayne
just
shared,
maybe
maybe
more
around
the
meetings
and
related
to
dependencies.
But
what
would
be
your
take
on?
Who
cares.
C
I
guess
I
see
it
from
a
few
personas
there's
the
developers
that
wonder
whether
or
not
their
software
code
is
dependent
on
something
to
execute
and
run
and
build
so
sort
of
the
all
the
software
dependencies
that
we
discussed
and
whether
or
not
that
actually
is
functional
software
that
is
not
articulating
well
have
not
had
enough
copy.
Yet.
C
D
I
would
actually
add
one:
I
mean
it's
a
persona,
but
a
different
role,
and
if
you
don't
mind,
I
would
put
it
just
before
the
developers
wanted
to
understand
their
dependencies.
D
D
I'd
rather
help
reduce
the
amount
of
problems
coming
in
and
I
think
that's
actually
a
different
situation,
because
you're
typically
yeah,
no,
no
yeah,
yeah,
okay,
yes,
yeah,
proactive
yeah,
because
you're
typically
at
that
point,
you're
making
a
choice
and
so
you're
comparing
alternatives,
whereas
once
you've
made
the
choice,
it's
hard
to
undo
and
often
you're
going
to
try
to
live
with
the
choice
because
switching
is
pain.
A
C
There's
also
the
legal
and
compliance
component.
You
know
we're
a
large
company,
so
we
always
think
about
whether
or
not
we're
in
compliant
compliance
with
the
licenses
involved
and
that
we're
not
going
to
get
sued
because
we
use
something
improperly
so
understanding
what
you
depend
on
and
then
knowing
what.
What
the
legal
criteria
are
around
that
component.
D
Yep,
just
as
a
quick
note
sophie,
you
know
for
google
you're
worried
about
getting
sued
for
small
companies
who
might
want
to
get
bought,
they're
worried
about
m
a
because
this
is
this.
I've
heard
more
than
one
stories.
Kate,
probably
knows
more
of
these
than
I
do
of
m
a's
getting
torpedoed
because
of
serious
legal
problems,
which
you
know
if,
if
the
whole
point
of
your
company
was
to
get
bought,
that's
kind
of
a
problem.
A
F
F
The
only
thing
I
maybe
can
add
is
the
fact
that
we
need
to
have
it
be
able
to
be
any
type
of
metrics
and
so
forth.
You
know
if
just
having
a
number
isn't
sufficient.
We
need
to
be
able
to
drill
into
it
so
that
people
can
do
things
in
action,
reaction
and
action
them.
So
I
you,
you
know
you
have
a
certain
set
of
dependencies.
You
want
to
be
able
to
understand.
Okay,
I'm
running
this
container,
you
know
what's
in
it,
what
does
it
depend
on?
F
B
You
know
maybe
a
a
different
way
to
to
say
what
I
was
saying
in
the
beginning.
There
is
that
a
a
group
of
people
who
care
about
this,
you
might
call
funders.
B
They
either
are
coming
out
of
the
foundational
funding
space
or
they
run
grant
programs
or
their
organizations
who
you
know
want
to
mobilize
funding
for
open
source
dependencies
or
to
help
shore
up
dependencies
that
may
be
at
perceived
risk.
B
You
know
all
of
them
if
we
step
away
from
from
my
own
employer
here,
look
at
something
like
the
moss
program
right
like
if
the
moss
program
has
has
five
requests
for
funding
in
front
of
it
to
work
on.
You
know
five
five
different
dependencies
or
sets
of
dependencies
or
ecosystems
being
able
to
understand
how
important
each
of
them
are
relative
to
each
other
and
what
the
impact
of
that
funding
might
be
relative
to
the
other.
Grants
is
an
important
piece
of.
A
A
next
step
might
be
to
think
about,
since
this
has
become
a
vast
space
and
led
to
many
really
great
discussions.
One
way
to
focus
those
discussions
into
the
development
of
metrics
and
possibly
tools
is
to
think
about.
Are
there?
Are
there
different
focus
areas
right
now
within
the
working
group
for
risk
that
we
might
want
to
establish
so
we
have
a
spreadsheet
and
that
spreadsheet
has
focus
areas?
A
I
think
I
think
dependencies
are
kind
of
littered.
Not
littered
littered
sounds
negative,
but
dependency
oriented
metrics
as
we've
started
to
enumerate
them
are
in
lots
of
different
places,
and
it
may
be
the
case
that
we
want
to
call
out
categories
or
focus
areas
for
dependency
metrics,
so
that
we
can
group
them
specifically
and
distinctly
from
other
risk,
metrics
and
and
possibly
use
those
focus
areas
to
draw
in
additional
participation
to
the
development
of
metrics
and
tools
in
this
space.
G
So
this
is
what
it
looks
like,
so
basically
the
way
that
we,
if
you
scroll
all
the
way
to
the
bottom
sean
I
could
just
put
there's
some
placeholders
some
placeholders
in
there,
and
so
we
typically
have
a
particular
focus
area,
and
some
of
this
can
move
around
too,
but
a
focus
area
that
would
be
kind
of
the
higher
level
categorization
for
a
series
of
yet
to
be
developed,
metrics
and
so
the
I
think
what
sean
was
bringing
forward
was,
what
might
be
those
kind
of
meta
categories
on
row,
71,
77
and
83-
that
we
might
think
about
capturing
a
set
of
metrics.
A
I
think
the
question
of
dependency
can
relate
to
any
of
these
existing
categories,
and
this
is
more
about
what
are
you
know
looking
at
dependencies
as
a
first
order
category
to
focus
on
instead
of
having
it
sort
of
mingled
in
with
sort
of
tangentially
to
other
specific
concerns,
so
we
might
leverage
existing
metrics.
But
if
we
were
to
say
if
these
are
the
three
focus
areas
that
are
really
metric
oriented,
what
would
we
call
them.
C
A
B
B
Risk
assessment:
can
I
restate
sofia
what
I
what
I,
what
I
what
I
heard
when,
when
you
were
saying
what
you
were
saying
there
and
it's
going
to
be
completely
different
language,
because
I
was
thinking
in
another
thread
there,
but
we
know
that
we
know
that
a
project
with
zero
dependence
and
that
there's
not
with
zero
dependence
and
zero
installed.
It
has
a
risk
of
zero
right
like
if
no
one's
using
it
and
no
one
depends
on
it.
If
it.
B
Away
the
the
odds
of
it
causing
some
kind
of
problem
are,
are
very
difficult.
The
the
odds
are
very
low.
B
We
we
know
that
if
a
project
has
250
million
dependents
that
that
project
going
away
the
risk
is
there's
very
high
risk
that
if
that
project
suddenly
went
away
or
if
it
was
a
problem,
that
it
would
have
a
wide
impact,
the
problem,
I
think
that
you're
talking
about
sofia
is
that
if
it
has
a
dependent
of
one
that
risk
could
still
be
incredibly
high
right
if
we,
if,
if
you
only
use
it
in
one
project
in
your
organization,
but
that
project
processes
all
financial
transactions,
the
the
chance
for
risk
there
is
very
high
and
that
that,
like
that
place
in
the
middle
of
how
to
assess
risk
for
things
that
are
just
beyond
you
know,
how
widely
is
it
used
is
what
you're
talking
about
when
you
say
you
need
to
have
a
compound
metric,
rather
than
just
something,
that's
flat
numbers.
C
It
does
and
the
problem
with
compound
metrics
is
they
would
also
be
context
dependent.
C
D
D
That's
a
completely
different
story
and
download
counts
actually
are
remarkably
not
helpful,
because
if
someone
sets
up
their
test
infrastructure
to
download
a
dependency
every
time
they
run
a
test,
you
can
get
huge
numbers
for
something
that
isn't
used
very
often,
whereas
if
somebody
caches
things
properly,
you
may
never
notice
something.
That's
widely.
A
D
Yeah-
and
I
see
one
challenge
here-
we've
we're
kind
of
mixing
two
different
kinds
of
metrics,
which
I
think
is
is
probably
innate
I
mean
for
any
dependency.
You
have
the
depender
and
the
dependee
right.
What's
the
what's
the
risk
of
the
defender
depending
on
something
and
what's
the
you
know,
risk
of
the
you
depending
you
have
risks
on
measuring
on
both
sides
here
right.
C
I
think
if
I
got
that
well,
because
I'm
kind
of
thinking
of
the
things
that
they
depend
on
and
then
if
everyone
has
a
metric
of
the
things
that
they
depend
on,
then
it
should,
in
theory,
have
all
the
above
versus
thinking
about
bi-directional
dependency,
which
I
think
is
valid
if
you're
thinking
about
say
full
system
infrastructure
and
how
everything
interrelates.
But
if
it's
just
an
individual
project,
then
I
guess
I
would.
If
I
had
to
pick
one
direction,
I
would
pick
the
dependee.
D
D
D
A
I
suppose
I
suspect,
there's
use
for
both
but
yeah.
Well,
I
suppose
from
if
you
take
the
personas
from
a
funder
perspective.
They
care
a
lot
about
projects
that
are
dependent
on
by
a
lot
of
organizations.
A
D
D
A
C
A
E
G
D
G
D
D
A
B
I
want
to
try
to
say
what
I
think
you
all
are
talking
about,
because
there's
been
so
many
depend,
asterisks
now
that
I'm
a
little
unsure
about
where
the
conversation
is
happening.
What
I
think
this
is
is
there
are
the
people
above
me
that
depend
on
my
project
and
the
projects
below
me
that
my
project
depends
on.
I
A
J
I
was
actually
I
was
actually
taking
this.
To
I
mean
their
risk,
for
dependers
are
the
the
risk
of
use,
and
then
the
the
flip
side
of
that
coin
is
the
not
the
risk
of
use
because
the
risk
of
use
can
be.
J
We
can
look
at
that
in
different
places,
but
the
ways
of
mitigating
risk
and
design
right
so
risk
is
kind
of
inherently
kind
of
a
a
user
issue
right.
We
try
to
avoid
risk,
whereas
the
the
designer
is
going
to
try
to
mitigate
risk
in
some
fashion.
J
A
D
J
I
At
least
that's
that's!
That's
how
I've
conceived
of
that's,
how
I'm
familiar
with
with
downstream
versus
upstream,
yes,
so,
would
number
seven
be
downstream.
A
F
C
I
know
we
moved
beyond
this
already,
but
while
kevin
was
talking,
I
was
thinking
about
our
personas
again
and
I
didn't
know
if
we
wanted
to
say
split
up
the
development
piece
and
that
there
is
distinction
between
the
engineers
and
the
architects,
but
that
might
be
too
granular.
If
you
want
to
just
bucket
into
those
who
build
things
and
whatever
role
they
have
within
it.
A
I
would
think
architects,
at
least
in
my
long
ago.
Experience
have
more
time
to
think
about
and
investigate
depend
things
like
dependency
risk
and
developers
are
making
fast
decisions
to
meet
their
deadlines
and
maybe
are
less
rigorous
in
their
evaluation
yeah,
and
so
they
they
want
the
same
outcome,
but
they
probably
the
developer,
needs
something
quick.
C
Yeah,
but
do
you
think
that
the
behavior
is
distinct
enough
to
have
them
separated
in
terms
of
persona,
because
I'm
assuming
that
would
be
articulated,
potentially
in
distinct
kinds
of
metrics?
But
if,
in
your
point,
if
they're
trying
to
reach
the
same
goal,
then
it
might
not
make
sense,
we
might
be
incurring
more
complexity
without
a
lot
of
value-add.
A
A
Unless
they're
well
managed
increasingly
that's
a
topic,
but
I'm
dwayne
josh.
What
do
you
think.
G
H
Totally
agree:
the
architects
I've
worked
with
tend
to
be
a
little
more
attuned
to
that.
C
A
But
it
might
be
an
there
might
be
like
a
folk
developer,
dependency
risk
and
architect
dependency
risk.
I
don't
know
if
those
be
those
those
metrics,
of
course
would
intersect
with
the
upstream
and
downstream.
D
A
A
A
I
I'm
not
sure
I
fully
understand
I
apologize
partially
yeah.
It
doesn't
help
that
I
was
late
because
I
don't.
I
don't
have
the
full
context
for
that
question.
So
it's.
A
A
Are
there
concerns
about
dependencies?
They
have
that
don't
fall
into
the
upscreen
upstream
downstream,
possibly
licensing
and
security
categories
focus
areas,
distinct
considerations
for
your
organization
that
aren't
part
of
those
working
groups
through
those
focus
areas.
H
B
A
there's
a
thing
that
I'm
I'm
kind
of
wrapping
my
head
around
here
and
it
is
it
calls
back
to
something
so
sophia
said
earlier
about
risk
being
context.
Specific
right,
like
as
I
look
through
the
list
of
metrics
here
for
the
most
part.
These
are.
B
B
Our
financial
transactions
totally
different
question
that
nobody,
but
we
can
answer
right,
you
know:
does
this
library
have
any
security
vulnerabilities
well,
probably
because
they
they
all
likely
have
at
least
one
unless
you're
really
running
bleeding
edge,
and
even
then
they
just
haven't
found
it
yet,
what's
the
risk
of
using
it
highly
dependent
on
where,
oh
god,
that
word
again
highly
context
specific
depending
on
where
we
might
be
using
that
dependency
and
that
that
that
question
of
like
what
is
the
risk
to
my
organization
to
to
using
this
or
pulling
this
in?
B
B
G
Yeah
so
I'll
make
a
comment
just
on
the
chaos
project
as
a
whole.
We
to
your
point,
doing
we
try
to
be
very
agnostic
on
the
metrics,
so
we're
value
free.
So
we
try
to
provide
metrics
that
give
you
those
those
numbers.
But
yes,
you
have
to
contextualize
those
to
your
own
organization,
so
the
same
holds
true
for
the
dna
metrics
we've
we've
developed
the
same
holds
true
for
the
value
metrics
we've
developed.
A
A
Metrics
oops
girls
have
rti
starting
at
10
50
in
case
you
needed
to
know
that.
C
I
would
I
would
agree
with
the
direction
this
is
going,
because
I
was
trying
to
think
of
examples
of
organizational
specific
dependency
questions
that
aren't
currently
covered,
and
I
think
they
are
all
related
to
your
existing
context,
say
the
people
in
your
organization
and
what
they
use,
what
they
work
on
and
how
that
relates
to
what
you
end
up
using
as
a
project
and
then
on
the
other
side,
your
the
context
of
your
existing
infrastructure
environment.
C
What's
it
going
to
be
able
to
run
on
and
are
there
any
physical
dependencies
that
you
might
have
in
terms
of
what
you
can
and
cannot
implement
on
top
of
your
existing
stack
and
that's
entirely
context
specific.
So
I
think
it's
too,
it's
too
prescriptive
in
a
way
that
we
would
never
be
able
to
see
inside.
C
So
I
kind
of
like
the
idea
of
discussing
the
applicability
to
an
organization
as
you
take
these
objective
points
and
contextualize
them
as
needed,
and
I
think
when
you
describe
matt,
it
seems
like
the
rest
of
the
project
has
approached
taking
that
approach
as
well.
So
I
think
I
guess
I'm
arguing
that
organizational
dependencies.
C
A
Yeah,
that
would
be
those
will
be
my
words.
A
Is
there
a
dependency
that
seems
to
be
losing
developers
that
that
once
looked
okay
and
now
is
starting
to
look
less?
Okay?
Do
I
have
a
dependence
which
is
kind
of
an
upstream
concern
as
well
so,
but
if
dependent,
yeah
dependency
is
becoming
less
well
supported
or
not
supported
like
and
the
node.js
environment
has
desupported
a
number
of
key
dependencies
over
the
last
several
years.
A
C
A
Kind
of-
and
I
I
think
I
could
say
from
upstream
project
perspective,
the
loss
of
resources,
loss
of
people,
interested
loss
of
organizational
commitment
could
be
expressed
that
can
be
expressed
as
a
similar
concern.
From
the
other
perspective,
maybe.
C
Potentially
a
silly
question,
but
is
that
something
that's
covered
in
any
other
chaos
working
group?
Would
that
be
something
that
we
nest
with
an
existing
metric.
A
A
J
I
actually
think
there's
going
to
be
a
fair
amount
of
overlap
from
the
evolution
working
group
and
the
the
number
seven
upstream
projects
focus
area.
I
think
there's
probably
a
lot
of
overlap
between
the
two.
A
A
How
do
we
want
to
use
that
time?
If
we
go
back
to
our
agenda
of
the
who
cares?
Is
there
a
minimum
viable
product
for
dependency?
Metrics
might
be
a
good.
G
Let's
try
to
organize
that
a
little
bit
just
in
a
like,
in
a
way
that
to
sophia's
point
earlier
that
we
can
all
articulate
it
clearly,
so
that
others
can
understand
what
we're
trying
to
articulate
so
maybe
trying
to
just
bring
this
discussion
together
so
that
in
two
weeks
we
have
something
to
go
off
of.
D
Yeah
having
struggling
over
this
particular
organization,
maybe
it'd
be
better
to
just
kind
of
identify
metrics
that
are
reasonable
and
then
back
up
to
what
are
the.
What
do
they
help
us
determine,
instead
of
trying
to
force
an
organizational
structure
off
on
it,.
G
D
C
C
D
D
This
attempt
to
separate
the
dependent
and
appendees
I
think
there
is
that
is
certainly
true,
but
indeed
I
think
a
lot
of
things
you
can
measure
for
a
project
are
also
things
you
can
measure
for
yourself
and
for
every
project.
You
depend
on
and
really
transitively,
so
maybe
that
we
started
down
that
path.
I
think
there
is
a
pony
in
there,
but
I,
I
think,
there's
probably
a
lot
of
metrics
where
it's
the
same.
It
has
uses
on
both
sides.
F
Yeah,
the
other
thing
I'm
sort
of
thinking
is
that
the
way
open
source
is
constructed
and
things
are
done
from
the
build
infrastructure
and
so
forth.
It's
much
easier
to
understand
who
you
depend
on
rather
than
to
understand
who
depends
on
you.
F
Agree
and
that's
all
right,
things
like
pop
counts
sometimes
help,
but
at
the
end
of
the
day,
it's
far
more
ambiguous
as
to
know
if
people
are
going
to
be
depending
on
you
or
not,.
B
F
B
This,
if
I'm
not
mistaken,
though,
was
the
original
problem
that
library
zio
sought
to
solve
was
to
help
people
figure
out
who
was
using
their
stuff,
not
just
so
that
not
just
so
that
they
could
figure
out
who's
going
to
get
broken
by
breaking
changes,
but
also
so
they
can
figure
out,
like
you
know,
should
they
be
charging
for
what
and
how
and
it's
subsequently,
I
know
for
sure
the
same
problem
that
depth
cloud
has
set
set
out
to
to
solve
figuring
out
who's
using
my
stuff
right
josh.
What
are
your
thoughts
there.
A
On
on
just
you
know,
the
original
purpose
of
libraries.io
and
understanding
dependencies
in
each
direction.
I
Yeah,
I
I
certainly
figure
out
who
was
using
what
was
was
sort
of
what
was
a
part
of
it.
I
confess
I
haven't.
I
was
an
adviser
to
the
project,
but
it's
been
a
while,
since
I've
been
in
sync
with
them,
so
I
I
don't
necessarily
even
trust
my
memory
or
what
I
claim
that
that
project
would
be
about
right
now,
but
but
I
think
that
that
was
certainly
was
was
part
of
it.
Yeah.
A
We
are
we're
at
time.
Is
there
anyone
who
wants
to
add
anything,
or
should
we
thank
each
other
for
an
organizing
discussion
of
many
of
the
things
that
we've
talked
about
and
thank
matt
for
taking
the
action
item
to
try
to
cohere
a
little
bit
go
hear
this
a
little
bit
more
for
a
subsequent
discussion.
A
Yep,
I'm
good
all
right.
Thank
you.
Sean
can.
I
briefly
say
that
there
this
may
not
be
the
best
time
for
kate
well
for
a
number
for
a
couple
people
on
the
call,
so
I
will
send.