►
From YouTube: CHAOSS Risk Working Group Meeting 3-4-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
A
Let
me
offer
a
brief
introduction
to
where
we
are
I'll.
Keep
it
to
60
seconds
or
less.
We've
had
many
many
discussions
about
dependencies
over
the
course
of
the
last
couple
of
weeks.
We
came
up
with
this
list
of
needs
and
motivations,
as
well
as
resources
and
links
related
to
dependencies,
as
well
as
security
vulnerabilities,
which
are
interrelated
to
each
other
and
since
a
two-tab
spreadsheet,
you
can
find
it
in
the
working
group
meeting
notes
from
last
week,
which
I
will
copy
link
url
and
place
into
chat.
A
Well,
I
think
I'll
place
it
in
the
chat
and
I'll
also
sort
of
leave
it
at
the
top
of.
A
A
So
that
is
easily
accessed
in
the
future
and
through
the
course
of
that
discussion
we
started
to
enumerate
sort
of
what
we
consider
our
minimum
viable
product
metrics
for
writ
for
dependencies
in
this
risk
working
group
and
that
minimum
viable
product
sort
of
evolved.
A
It
is
down
here
so
repository
dependency,
enumeration
sustainability,
risks,
dependency
range.
How
many?
How
often
is
it
referenced?
There's
a
statistic
called
libya
that
is
in
that
spreadsheet
of
resources
I
shared
a
minute
ago,
enumerating
vulnerabilities,
osf,
scorecarding
and
then
a
matrix
of
the
same,
and
so
I
think
that's
another
piece
of
information,
maybe
to
keep
sort
of
at.
A
Yeah
forget
it,
I
won't.
I
won't
I'll,
just
use
bolding
and
underlining
to
indicate
that's
an
enumeration,
but
I
think
there
are
some
things
that
need
to
be
indented
in
the
translation
and
I'll
come
back
to
that
part
later.
Just
keep
it
here.
So
that's
that's
kind
of
where
we've
been
at
and
last
week
we
started
active
work
on
the
first
of
these
mvp
metrics,
which
evolves
to
language
level
upstream
dependency
enumeration,
and
we
so
upstream
and
downstream.
We
all
talk
about
those
words,
and
often
they
become
words.
A
People
are
confused
about,
and
so
these
are
projects
that
the
project
you're
working
on
depend
upon,
and
this
is
the
work
that
we
started
to
do
so
part
of
each
of
these
meetings
is
actively
working
on
some
of
these
mvp
metrics.
A
So
that's
that's
sort
of
the
introduction
to
where
we
have
been
and
what
we've
been
doing
up
until
you
know
over
the
last
several
weeks
for
folks
who
are
new
to
this
working
group
or
haven't
spent
a
lot
of
time
in
it
previously.
So
with
that,
I
think
we've
got
some
new
faces
and
I
would
welcome
you
to
introduce
yourselves.
I
can
call
you
out
individually
or
you
can
volunteer
or
matt
can
volunteer
you
based
on.
Perhaps
he
knows
you.
C
Well,
hello,
all
great
to
be
here.
I
I'm
coming
from
the
sustained
community
and
open
source
collective
and
we
have.
C
We
have
been
interested
in
building
dependency,
graph
tools
and
matt
and
georg
joined
us
last
week
and
we
realized
there's
a
lot
of
alignment
in
some
of
the
conversations
that
we've
been
having
and
what
you
seem
to
be
developing
here.
So
personally,
I'm
really
excited
about
combining
our
efforts.
C
C
You've
been
building
and
also
how
we
can
kind
of
combine
efforts
to
really
move
work
like
move
work
forward,
and
so
I
I
personally
am
not
a
developer
but
really
interested
in
how
this
this
influences
and
our
and
informs
our
understanding
of
of
community
community
health,
which
clearly
aligns
with
with
what
we're
doing
here
so
yeah
excited
to
be
here
and
and
I'll
pass
it
off
to
richard
who's.
Also,
coming
from
the
sustain
working
group.
D
Love
being
called
out,
thank
you.
So,
from
my
perspective,
also
from
the
same
community,
we
had
a
we
had
a
working
group,
that's
been
going
on
for
you
know,
past
few
months,
if
the
focus
has
really
been
dependencies
mapping.
D
How
do
you
know
what
dependencies
are
where
in
your
ecosystem,
and
I
think
the
reason
for
focusing
on
that
has
been:
how
do
we
get
money
through
those
projects
right,
if
you
give
back
to
your
dependency
tree?
What
does
that
look
like?
How
do
you
know
where
that
money
goes?
How
do
you
put
it
in
escrow?
How
do
you
make
sure
it's
portioned
fairly?
How
do
you
stop
bad
actors?
D
What
algorithms
do
you
use
and
we've
been
trying
to
figure
out
how
to
do
that
for
a
while,
but
it's
also
been
kind
of
ad
hoc
and
there's
a
few
different
stakeholders
and
it's
been
hard
to
keep
the
conversation
sort
of
flowing
in
a
consistent
way.
So
it
looks
like
the
risk
working
group
is
much
more
focused
on
risk
assessment
for
dependency
management
right.
D
How
are
dependencies
long
terms?
Are
they
stable
or
not?
Are
they
going
to
affect
upstream
usage?
Are
those
dependencies
actually
the
community
stable,
which
is
a
really
interesting
question?
That's
related
to
our
question.
I'm
not
sure
if
I
really
have
a
horse
to
pick
in
this
one
right,
I'm
kind
of
just
here,
because
I'm
interested
in
the
technical
problems
of
how
do
you
figure
out
who's
working
and
what
dependencies.
D
I
don't
know
what
that
looks
like,
especially
with
licensing
itself
being
an
ethical
issue,
but
certainly
I
want
to
see
what
approaches
you
all
are
taking
and
see
how
that's
going,
and
hopefully
I
didn't
just
get
too
far
into
the
weeds
with
my
own
personal
thinking,
but
that's
that's
kind
of
where
I'm
at
and
then,
as
far
as
like,
where
I
work,
who
knows
man
who
knows,
but
I
think
sustain,
might
be
the
closest
relevant
bucket.
A
A
No,
no,
no!
No
problem.
I
appreciate
it.
I
think
I
think
you'll
find
that
we're
not
really
thinking
about
dependencies
a
lot
differently
than
what
you're
describing.
I
think
we're
thinking
about
right
now,
at
least
where
we're
at
is
what's
the
minimum
viable
product
for
how
do
you?
What
are
the
names
and
descriptions
of
the
metrics
that
we
can
use
and
then
develop
software
for
to
keep
track
of
some.
D
Of
those
things
which
I
think
is
very
similar,
yeah
yeah
our
end
goals
might
be
slightly
different.
Given
the
name
of
this
working
group,
I'm
assuming
that
right
risk
is
not
really
what
I'm
thinking
about,
I'm
thinking
more
about
payback
or
give
back
or
something,
but
the
methods
are
identical,
so
really
yeah
really
great
to
see
this
work
happen.
Yeah.
A
Yeah,
I
I
think
the
I
think
the
framing
or
the
name
of
the
working
group
is
different
than
than
sustains,
but
but
ultimately,
we've
identified
dependencies
as
a
factor
in
risk,
and
we,
I
think,
we've
arrived
at
a
very
similar
if
not
pretty
close
to
the
same
place
from
different
points
of
view.
I
was
going.
B
To
say
for
what
it's
worth
richard,
we,
the
concept
of
dependencies,
was
existing
in
a
variety
of
different
working
groups,
so
risk
being
one
value
being
another
working
group
and
just
over
time
it
just
seems
like
the
conversation
kind
of
had
to
settle
in
one
place,
and
it
just
happened
to
be
here
so.
D
And
then
make
sense
to
me,
especially
given
chaos
is
customers
right,
like
the
people
who
are
stakeholders
in
the
community
tend
to
be
larger
corporations
which
are
more
interested
in
risk
assessment
at
some
level
than
give
back,
not
to
say
they're,
not
interested
in
both?
That's
just
been
my
perspective.
As
an
outsider,
I
may
be
wrong.
E
Yes,
yeah,
I'm
a
phd
student
from
the
university
of
gottingen
from
germany
and
well
I'm
interested
in.
We
are
a
risk
in
a
broader
sense.
I'm
currently
interested
in
software
quality
evolution,
and
I
got
invited
here
by
georg.
A
Repository
dependency
enumeration
is
the
metric
that
we
had
sort
of
concluded
last
week,
working
on
and
so
continuing
to
sort
of
spend
some
time.
Working
on
that
this
week
is
one
of
the
things
we
put
on
the
agenda,
looking
a
little
bit
deeper
at
sustainability
risk
and
how
they
might
how
that
might
relate
to
existing
metrics
and
other
working
groups,
and
then
some
of
these,
these
other
questions,
possibly
for
discussion.
A
Tell
me,
I
guess,
would
the
group
like
to
I
don't
where
would
like?
Where
would
folks
like
to
start
well,
would
let's
start
by
doing
a
little
bit
of
work,
or
would
we
like
to
start
by
having
some
broader
discussion
in
light
of
the
new
folks
who
are
here.
G
I
think
it
might
be
more
constructive
to
start
abroad.
I
think
for
the
the
new
folks
that
are
joining
this.
We
had
many
very
broad
conversations
where
we
let
ourselves
kind
of
go
in
and
out
of
all
of
the
weeds
before
we
settled
where
we
did,
but
I
think
forcing
you
to
get
into
our
narrow
scope
immediately
might
be
harder
to
have
a
producting
productive
session
immediately.
G
Because
I
think,
if
anyone
has
thought
about
dependencies,
they
know
how
broad
this
topic
is,
and
I
think
I've
heard
the
descriptions
coming
from
from
richard
and
alyssa
and
alex
that
this
really
can
go
to
the
number
of
directions.
I
think
we
have
gone
in
all
of
those
or
many
of
them
can
continue
to
do
that.
So
I
guess
I'm
very
long-winded
way
of
saying:
let's
start
with
number
two
or.
E
A
So
I
suppose
a
good
place
to
start
is
when
we
talk
about
sustainability
risk,
and
we
are
thinking
about
project
activity
issue
closure,
how
many
committers
the
stability
of
some
core.
Those
are.
Those
are
some
of
the
factors
we
think
about
that
that
have
metrics
that
exist
in
chaos
and
other
working
groups.
A
A
Support
support,
helping
you
know.
A
Like
his
sustainability
first
sustain,
maybe
maybe
take
a
maybe
from
a
from
the
perspective
of
either
that
list
of
sustainability
risk
or
when
we
look
at
our
accumulated
list
of
motivations.
This
is
the
list
of
motivations
that
we
came
up
with
for
why
we
care
or
different
parties
care
about
dependencies
and
what
chaos
can
do,
and
I
think
I'd
be
curious,
perhaps
how
some
of
the
new
is
it
sophia?
What
do
you
think
is
this
a
possibly
helpful
way
of
having
this
discussion.
G
I
guess
I
guess
where
I
interpreted
sean
correctly.
There
are,
it
sounds
like
getting
in
a
broader
perspective
on
areas
beyond
risk
that
factor
into
why
we
would
be
tracking
dependencies,
so
we
kind
of
went
through
a
use
case,
exercise
and
persona
exercise.
Earlier
I
don't
know
where
that
landed.
I
think
that's
I'm
looking
at
it
right
now,
groups
and
communities
why
they
might
care
or
not
care
about
it,
and
then
I
think
the
second
piece
is.
G
We
were
thinking
about
separating
the
distinction
of
being
able
to
enumerate
direct
and
indirect
dependencies
from
the
various
dimensions
that
you'd
want
to
track.
On
top
of
that,
so,
in
the
case
of
say,
something
like
the
project
is,
is
supported
or
not
supported,
or
it
has
an
active
community
or
doesn't
or
has
has
been
taken
over
by
a
bad
actor.
G
I
think
I
think
I
guess
for
us.
The
rationale
starting
at
this
level
is
that
when
we
start
to
pick
individual
metrics
by
having
a
comprehensive
list,
it
helps
us
to
be
a
lot
more
targeted
and
why
we're
starting
with
this
one
metric,
because
we
clearly
can
be
there's
so
many
things
that
we
could
do
so.
I
guess
from
the
sustained
folks.
We
started
first
with
this
kind
of
persona
conversation,
the
groups
and
communities
that
might
use
dependency
information
and
what
would
they
use
it
for,
and
it
sounds
like
richard.
G
C
I'm
going
to
pass
it
off
to
richard,
but
let
me
give
like
what
always
seems
like
a
really
simple
example
from
the
perspective
and
community
that
I
I'm
thinking
of
for
first
and
duane
pointed
this
out
to
me
that
a
number
of
you
know
how
there's
a
the
contributor
fund,
which
kind
of
activates-
and
you
know,
internal
company,
to
vote
on
where
to
where
to
give
financial
support
to
an
open
source
project.
C
The
there's
general
awareness
here
of
the
contributor
fund
right,
yeah,
yeah,
okay,
duane,
pointed
out
once
to
me
that,
within
like
the
within
the
first
three
months
of
voting
like
multiple
companies
gave
to
the
same
project
and
it
sort
of
spoke
to
me
of
like
there
are
open
source
projects
that
are
good
at
fundraising,
that
they
have
a
a
a
momentum
behind
them
and
that
and
that
there
are
there
are
stakeholders
that
are
aware
of
their
importance
in
in
their
work
and
that
it's
important
for
them
to
like
provide
support
for
their.
C
C
That,
like
may
not
be,
as
quote
popular
or
you
know,
have
the
same
facility
in
fundraising
that
are
are
nonetheless
like
there
and
may
not
be
voted
on
necessarily
because
they're
not
necessarily
visible
to
the
and
and
they're
the
the
I
hate
to
use
this
word
because
you
probably
have
a
better
like
grounding
in
it,
but
like
the
return
on
investment
for
certain
projects
is,
is
may
not
be
as
visible
and
so
for
me,
one
of
the
things
that
can
be
powerful
about
like
mapping
dependencies-
and
I
always
picture
like
you
know
a
supply
chain-
is
that
it
will
kind
of
bring
to
surface
and
bring
to
light.
C
Like
the
importance
of
these
smaller
projects.
I
get
missed
in
a
conversation
about
what
to
sustain
what's
important
and
also
can
lift
up
the
the
awareness
that
stakeholders
do
rely
on
on
certain
projects,
not
only
like
these
big
ones,
but
the
these
smaller
ones,
and
how
much
and
how
much
is,
is
the
importance
of
them
being
like
active
agents
in
their.
C
D
I'm
not
sure
that
it's
necessary
to
put
yourself
down
so
much
so
alyssa
is
really
great
at
back.
Your
stack,
for
instance,
which
has
largely
been
her
project,
which
is
a
really
interesting
use
case
here,
because
it's
not
funders
is
covers
all
manners
of
sins
right.
There's
all
types
of
funders,
there's
like
large
large
funders
like
sloan,
which
want
to
give
back
to
fund
the
digital
infrastructure.
D
Then
there's
funders
like
back
your
stack
or
open
collective,
which
want
to
actually
mobilize
smaller
teams
to
have
micro
payments
to
actually
be
able
to
get
money
into
their
bank
account,
so
they
can
do
work
better
right.
So
that's
not
necessarily
the
same
level
of
things,
although
they
often
hit
the
same
amount
of
people
and
then
there's
funders
like
indeed
right
or
dwayne
you're,
all
familiar
with
him
who
are
like
osbos
corporate
osbos
are
interested
in
giving.
H
D
Or
at
least
shoring
up
risk,
and
then
there's
funders
like
people
who
have
just
exited
with
a
lot
of
bitcoin
but
are
still
independent
developers
who
basically
want
to
give
back
to
the
ecosystem
in
general,
there's
foundations.
So,
for
example,
I'm
thinking
about
the
ethereum
foundation
or
the
zcash
foundation,
which
are
both
set
up
by
large
crypto
entities
to
give
back
to
those
ecosystems
which
are
going
to
want
to
trace
dependencies
in
those
ecosystems,
but
not
at
scale
right,
not
not
for
everything.
D
Just
for
those
ecosystems
in
general,
then
there's
funders
like
git
coin,
which
are
actually
looking
for
projects
which
are
underfunded,
which
is
slightly
different
to
give
them
more
say
so
that
they
can
be
part
of
a
wider
community,
so
the
entire
ecosystem
could
be
built
up.
So
funders
covers
all
sorts
of
different
things
and
there's
definitely
more
than
that
right.
There's
people
like
like
there's
people
who
want
to
fund
ngos
who
want
to
fund
their
stacks.
D
One
of
the
interesting
questions
that
this
always
comes
up
for
me
is
how
do
you
track
dependencies
outside
of
package
manifest?
So
how
do
you
say
what
an
ngo
is
using
as
far
as
software
and
then
what
dependents
they
have
when
it's
not
entirely
just
a
javascript
file
right?
How
do
I?
How
do
I
fund
signal?
How
do
I
do
otf
type
stuff
right?
How
do
I
fund
large
democratic
institutions,
doing
work,
better,
etc,
etc?
D
And
again
these
are
very
broad,
strokes
and
sean
you're
doing
a
great
job.
Writing
them
down.
So
thank
you.
So
much
that's
just
funding
and
I
think
I
want
to
take
a
step
back
here
and
again,
I'm
sorry
for
talking
so
much,
but
the
stage
was
given
to
me.
So
thank
you.
I
guess
I
won't
say
that,
but
what's
interesting
is
that
sustain
is
not
a
cohesive
community
sustain
is
a
community
of
lots
of
different
people
coming
together.
D
Floss
bank,
which
is
interested
in
giving
back
equitably
algorithmically
to
every
single
dependency
and
highlighting
you
know,
nodes
which
are
more
interesting.
What
I
really
want
to
highlight
here
is
that
this
isn't
dependency
mapping
so
much
as
it's
actually
contributor
mapping.
They
want
to
know
not.
You
know
how
many
dependencies
are
in
the
tree,
but
how
many
of
those
dependencies
come
from
a
certain
person,
and
how
can
we
give
that
person
money?
D
So
a
good
example
is
when
you're
tracking
dependencies
do
you
track
all
javascript,
and
just
say
this
is
cool
or
do
you
track
all
the
packages
made
by
substack
are
made
by
sindray
and
then
try
to
give
sendra
money
right.
So
those
are
two
different
ways
of
looking
at
dependency
risk,
and
that's
really,
I
think
you
already
sort
of
cover
this
a
tiny
bit
when
you
think
about
governance
models.
D
You
know
how
how
good
is
a
is
a
dependency's
governance
and
how
stable
is
that
more
than
one
committer,
as
I
saw
somewhere
in
this
file,
which
is
great
another
example,
was
so
that
sorry,
that
was
a
floss
bank,
not
floss
space
yeah.
It's
all
right.
It's
an
actual
project.
Another
one
is
fair
oss,
which
is
looking
for
maintainers
of
projects
who
would
be
interested
in
having
equity
assigned
to
them
by
startups,
which
are
looking
to
give
back
to
their
dependency
trees,
which
is
a
whole
different
set
of
dependency.
Mapping
concerns
right.
D
D
So
those
are
two
of
the
main
people
doing
stuff
back.
Your
stack
is
another
one
where
we're
interested
in
collectives
of
people,
I'm
interested
in
other
questions
as
well.
Personally,
so
those
are,
I
think,
the
main
motivations
of
the
other
contributors
in
those
in
those
working
groups,
I'm
interested
in
senescence
in
general.
What
am
I
going
to
do
in
50
years,
when
most
of
the
people
who
are
making
the
dependencies
that
currently
underlie
the
web
are
dead
and
or
no
longer
code?
Senescence?
D
D
I
I
Yeah
or
aging
out,
basically
dependencies,
you
know,
aging
and
not
having
you
know.
Dependencies
are
still
there,
but
no
one.
It's
the
cobalt
problem.
Okay,
right.
D
Right,
yeah,
so
that
since
it's
the
same
root
as
senility
right.
I
I
Fair
enough
or
whatever.
I
D
D
G
So
sean
it
remind
me
in
the
notes,
because
I
was
digging
through
quickly
and
couldn't
find
it
quickly,
but
there
was
a
place
where
we
tried
to
have
a
broader
enumeration
of
dependency
categories.
I
kind
of
kind
of
liked.
As
richard
was
talking.
I
was
sort
of
thinking
about
general
categories
of
things,
we're
dependent
on
and
we've
started
with
as
software
and
code
dependencies.
So,
if
you're
dependent
on
a
specific
project,
but
then
especially
we're
saying
you
could
be
dependent
on
funding
on
people
on
infrastructure
and
on
other
kinds
of
components.
G
G
G
B
D
I'll
go
I'll,
go
goodbye.
Well
I
mean
don't.
I
I
don't
want
to
make
anyone
dive
back
into
conversations
which
were
overly
broad
at
an
earlier
point.
When
I
just
wasn't
around
you
know,
I'm
relatively
new,
my
birthday
was
yesterday:
it
wasn't
actually,
but
you
know,
but
I
I
I
just
wanna.
D
D
This
is
just
the
motivation
coming
from
from
our
group
and-
and
I
really
want
you
to
continue
in
your
own
way,
because
I
don't
have
a
lot
of
mind
space
to
really
help
out
right
now
with
coding
a
new
dependency
tree
analyzer,
but
these
are
questions
that,
like
we're
curious
about
in
sustain-
which
I
think
is
only
one
or
two
coders
who
are
really
actually
doing
it-
we're
kind
of
just
actually
providing
buzz
mind
around
them.
D
You
know
we're
just
sort
of
bouncing
ideas
off
them
if
you're
already
doing
work
to
figure
out
metrics
for
this
stuff.
That
is
so
cool
and
like.
Please
don't
spend
all
the
time
here
talking
about
the
newcomers
who
came
in
a
bit
late
and
said:
have
you
thought
about
x
and
like
yes,
we
have
so
it's
my
way
of
trying
to
be
self-deprecating.
I
guess
that's,
maybe
not
useful.
No.
A
It's
perfect,
it's,
I
think,
sophia's
idea
of
you
know
talking
through
every
the
perspective
that
you
bring.
I
think
we've
had
some
of
these
conversations.
I
think
we've
had
them.
We've
had
a
lot
of
conversations
in
depth.
I
think
you
bring.
There
are
perspectives
here
around
funders
and
types
of
funders
that
we
haven't
discussed
before.
A
I
think
the
sort
of
equity
questions
and
the
senescence
lord
knows
if
I
spelled
that
right
questions
have
not
really
come
up
directly
in
this
conversation
before
so,
but
many
of
the
things
that
you,
the
categories
of
things
you
bring
up
like
how
do
we
get
funding?
A
Where
did
where
does
support
come
from
what
happens
when
the
maintainer
goes
away?
Which
senescence
is
one
category
of
that
same
problem
we
have
talked
about,
but
but
having
having
sort
of
your
broad
perspective.
A
So
we
understand
it,
I
think,
is
useful
for
us
and
also
useful
for
for
hopefully
for
you
to
start
to
situate,
because
I
think
when
I
look
at
what
we're
calling
our
mbp
metrics
and
thank
you
for
whoever
indented
this
correctly,
you
know
just
just
listing
what
your
dependencies
are
is
super
valuable
and
there's
not
a
generally
accepted
way
of
doing
that,
and
so
so
that's
sort
of
one
of
our
mvps
sustainability
risk
as
an
mvp
is,
is
something
we
think
we
can
work
towards
because
it
builds
on
other
chaos.
A
A
H
Sure
so,
ideally,
all
your
libraries
you
depend
on
will
be
the
current
versions.
Sometimes
that's
not
true.
How
old
is
it
compared
to
the
current
version,
if
you
total
it
up
as
the
total
libyars,
if
you
divide
that
by
the
number
of
packages,
that's
the
average
number
of
libyars,
and
so
the.
C
A
Thank
you.
I
I
couldn't
have
done
that
in
more
than
five
less
than
five
minutes.
So
so
thank
you
in
just
enumerating
known
vulnerabilities.
We
discussed
this
a
bit
last
week.
There
is
a
public
database
of
known
vulnerabilities,
but
it's
incomplete,
and
so
there
are
existing
resources
for
trying
to
enhance
that.
But
there
is
a
obviously
there's
a
connection
between
vulnerabilities
and
dependencies
which
we're
calling
out
oss
scorecard.
A
H
I
am
so
basically,
this
is
from
the
open
source
security
foundation.
They
basically
yank
in
some
data
from
the
repository
and
score
it
using
a
couple
measures
and
it's
completely
automated.
So
it's
pulling
in
things
like
you
know,
number
of
committers
how
active
and
they
score
each
of
those
from
zero
to
ten
and
total
it
up,
and
the
idea
is
to
drive
a
quick
idea
of
the
riskiness
of
a
project.
A
I
think,
possibly,
if
I
look
at
these
mvps,
my
first
impression
is
that
they
serve
both
purposes
when
I
come
from
it
at
from
the
starting
from
the
risk
perspective.
I'm
do
you
see
value
for
these
kinds
of
metrics
and
the
work
that
you're
all
doing.
D
Very
much
so
these
are
great.
I
I
really
I
like
some
of
them.
I've
just
had
a
really
fun
time
in
my
head
just
now,
because
I
haven't
been
able
to
explain
this
problem
to
a
disparate
group.
I
know
george,
I
see
you
all
the
time,
but
I
don't.
I
don't
talk
to
a
lot
of
you
a
lot
and
so
reframing.
It
has
been
really
fun
for
me
just
now,
because
I've
been
framing
it
how's
it
looking
500
years
and
so
for
me
the
mvp
would
include.
Is
it
english
dependent?
D
D
That's
an
interesting
question,
because
a
lot
of
the
things
we
depend
on
are
basically
just
so
far
down
the
stack
that
no
one's
going
to
as
a
first
year
coder
everybody
will
be
able
to
get
there
and
become
a
maintainer,
and
anyone
who
does
get
there
is
going
to
be.
You
know
aged
out
because
they'll
be
like
well.
I
already
have
too
many
other
things
going
on.
D
I
can't
deal
with
gcc2
so
like
these
are
like
open
questions
that
I
have
around
sustainability
in
the
long
term,
but
I
think
your
mvp
is
a
much
better
mvp
than
including
these
concerns.
A
To
the
list,
because
yeah.
D
H
J
H
So
you
know
if,
if
you
use
machine
learning
all
that
stuff
absolutely
vitally
depends
on
fortrain
and
it
is
not
going
away
and
no
intends
it
do.
A
D
Usually
aware,
I'm
just
you
know,
I
got
into
machine
learning
with
pearl.
That
was
what
I
was
taught
in
my
university.
I
went
to
university
for
master's
in
machine
learning
in
germany
and
I
would
never
get
there
if
I
didn't
have
the
resources
to
do
that
and
that's
an
issue
for
the
ecosystem.
If
the
only
people
who
ever
touched
this
stuff
have
to
already
have
an
undergraduate
degree
to
get
there
easily,
if
everyone.
H
D
A
For
those
things
are
not
not
changing,
so
that
code
is
unlikely
to
change
for
people
who
are
doing
computational
biology
or
bioinformatics
or
medical
imaging
research
and
want
to
rely
on
those
same
libraries.
They
probably
are
going
to
need
new
libraries
and
somebody's,
possibly
going
to
have
to
write
them
in
fortran
or
new
functions
in
numpy.
So
I
think
it's
a
little
bit
domain
dependent.
But
your
point.
H
H
H
D
A
So
we
so
we
have
repository
dependency
enumeration
and
that
is
actu,
okay,
somewhere
language
level,
upstream
dependency
enumeration.
I
think
I
think
we
ultimately
changed
what
we
called
it,
and
but
I
reflected
that
in
the
spreadsheet
and
now
I'm
trying
to
get
to
my
chat
window
because
I'm
the
sharer.
A
This
is
a
direct
link
to
this
metric
that
we
were
working
on.
We
have
about
seven
minutes
left,
you
can
see.
We
started
on
this
metric
last
time
and
we
could
just
spend
the
last
seven
minutes
or
so
developing
it
and
give
a
brief
overview.
Like
I
said
it's,
these
are
projects.
My
project
depends
upon.
A
A
The
description
of
understanding
the
code-based
dependencies
embedded
in
a
piece
of
open
source
software
is
important.
There
was
some
debate
about
whether
or
not
we
should
or
should
not
exclude
infrastructure
focused
dependencies,
but
I
think
at
the
time,
although
all
this
is
flexible,
we
agreed
that
it
was
more
like
upstream
infrastructure
dependencies
than
it
was
a
software
dependency
or
it
exists
at
deployment
or
runtime,
not
necessarily
at
development.
A
And
I
think
there
was
there's
also
been
discussion
of
how
we
find
dependencies
they're
largely
pulled
out
through
package
managers,
but
they
also
exist
as
import
statements
and
then
direct
indirect
static,
dynamic
and
then
build
tests
and
run
time.
Environments
and
kate
might
be
able
to
kate
has,
I
think,
a
good
example
of
that
it's
been
a
build
test
and
runtime
environment
excuses.
A
I
Where
you've
got
basically
cons,
you've
got
constrained,
so
any
of
the
c
infrastructure
is
pretty
much
make
infrastructure
and
see
infrastructure.
I
A
I
Yeah
you
pretty
much
like,
say
you
can't.
If
you're
working
within
the
constrained
environments,
everything
has
to
be
on
your
hardware
device,
which
includes
all
your
you
know
dependencies,
whereas
in
a
lot
of
you
know,
modern
systems
there's
run
times
and
there's
potentially
services
you're
working
out
to
and
calling.
H
I
In
the
server
space,
and
so
that
there's
you
know,
I
wouldn't
say
build
like
say
the
parameters
aren't
necessarily
static
or
dynamic.
The
parameters
are
more,
you
know,
do
you
have,
you
know,
are
you
constrained
and
for
the
static,
dynamic
or.
I
Well,
I
think
about
so.
Let's
say
the
one
thing
that's
really
interesting.
These
days
is
expectation
of
services
which
is
more
than
dynamic
because
we're
used
to
dynamically,
linking
you
know,
lighting
loading,
libraries
and
things
like
that.
But
what
happens
if
you're
calling
it
to
another
machine,
that's
using
an
api
to
give
you
a
service.
H
To
list
that
out,
but
you
know,
services
as
opposed
to
code
right.
H
Possibly
I
mean
you
know
if
you
depend
on
google
play,
that's
a
you
know,
that's
a
big
deal
in
the
android
system.
So
you
know
there
are
phones
which
are
sell,
are
sold,
they're
android,
they
don't
have
google
play,
but
you
then
don't
have
certain
services
that
a
lot
of
applications
depend
on
and.
H
Yeah,
I
would
just
say
run
times
they
could
be
interpretive
or
whatever.
Okay,
you
know,
you
know
the
the
runtime
environment.
I
H
If
you
want
to
do
scientific
computing,
fortran's
still
king
yeah,
so.
A
H
I
A
H
H
I
think
it
is
challenging,
because
I
mean
you
could
say
you
could
probably
say
something
like
you
know,
language
level
package
manager
which
can
sometimes
bring
in
other
languages.
You
know,
numpy
being
an
example,
you
know
if
you're
a
python
developer
you
and
you
import
numpy,
you
generally
don't
know
it
actually
all
depends
on
fortran
and
there's
a
number
of
python
modules
that
depend
on
c.
H
A
F
A
A
H
Let's
be
specific,
it
sounded
like
we
were
talking
about
language
level,
package
managers.
A
H
And,
and
that
would
be
basically
the
you're
you're
looking
for
an
mvp
now
that.
H
Won't
help
if
you're
writing
in
in
c,
where
typically
you're
using
the
system
level
language
package
manager.
But
you
know
for
many
people
that
would
still
be
useful.
A
Yeah-
and
I
I
think
I
think
maybe
maybe
starting
with
this
metric,
because
we're
at
the
end
of
time,
starting
at
this
metric
in
the
next
discussion
and
starting
with
the
question
about
language
level,
package
managers
might
be
the
place
to
go.
My
my
question
about
that
is,
I
know
from
working
on
projects
like
auger
and
even
other
things
that
involve
machine
learning,
and
I
have
dependencies
that
are
not
managed
by
language
level.
Package
managers-
I
I
have
software
that
relies
on
importing
other
git
libraries
or
cloning
other
git
libraries
like.
A
I
don't
I
don't
like
I,
I
will
overthink
this
forever.
So
if
this
group
would
just
do
us
all
the
favor
of
making
a
decision
the
next
time,
we
gather
that
is
pretty
helpful.
So.
D
A
We're
building
a
metric
that
defines
what
a
tool
would
include
when
it's
looking
at
depth.
So,
for
example,
this
discussion
about
whether
or
not
the
metric
is
constrained
by
package
level,
language
level
package
managers
that
what
that
does
is
it
stops
other
people
from
having
three
months
of
debate
about
what
a
dependency
is,
and
it
just
says
that
we
may
be
right.
We
may
be
wrong,
but
we're
going
to
count
dependencies
this
way,
so
that
we're
consistent
and
we
can
get
our
work
done
like
so.
A
A
lot
of
a
lot
of
what
we're
doing
is
defining
a
common
language
that
can
be
that
can
be
reused
and
avoid
others
having
to
go
through
these
same
very
long
discussions
about
what
is
a
dependency
these.
What
is
these?
What
is
the
dependency
conversations
are
starting
to
remind
me
of
the
what
is
it
commit
conversations?
I
was
part
of
early
in
the
chaos
project,
because
there
were
a
surprising
number
of
different
opinions
about
what
a
commit
is.
So
wife
has
the
same
question:
yep:
okay,
I'm
not
going
to
go
there,
I'm
going
to
say!
A
Thank
you
everyone,
I
think.
Hopefully
this
was
I
enjoyed.
This
conversation
welcome
to
everyone,
who's
new,
welcome
to
all
the
folks
who
have
hung
in
there
and
helped
us
build
a
list
of
mvps
that
we
are
slowly
chipping
away
at
and
will
release
the
next
time.
Chaos
release
match
releases
metrics,
and
our
next
meeting
is
scheduled
for
march
18th,
which
is
the
day
after
st
patrick's
day.
So
if
you
don't
have
your
video
on,
because
you're
not
looking
or
feeling
great,
that
is
not
a
problem.