►
From YouTube: CHAOSS.Evolution.Sept.23.2020
Description
CHAOSS.Evolution.Sept.23.2020
A
All
right
welcome
everybody
back
to
the
evolution
meeting
evolution
working
group
meeting
for
september
23rd.
You
know
what
I'm
not
showing
my
screen.
Do
you
guys
want
to
go
ahead
and
share
my
screen,
or
should
we
wait
to
do
that?
That
might
be
helpful.
B
I
cannot,
I
can
share
mine
if
you
want
to
not
have
actually,
that
would
be
helpful,
yeah
yeah.
Can
you
make
me
co-host?
Yes,.
A
A
A
So
here
so
looking
at
what
we
talked
about
last
time,
because
there
wasn't
anything
specific
on
the
agenda
for
today,
we
spent
a
lot
of
our
time
revisiting
the
same
question
that
was
talked
about
at
the
last
meeting,
specifically
or
the
meme
before
that,
specifically
talking
about
dependencies
in
the
context
of
evolution,
and
I
mean
kind
of
approaching
that
question
from
a
variety
of
angles,
including
what
is
our
goal
with
understanding
dependencies?
A
A
Really
you
can
it's
a
very
broad
term,
and
so
we
kind
of
just
spent
some
time
thinking
about
important
questions
that
could
related
to
dependencies
that
people
might
be
interested
in
and
some
of
them
were
things
that
maybe
belong
in
other
working
groups.
But
should
we
kind
of
continue
in
the
same
vein
today
and
maybe
think
about
some
other
questions
we
could
ask
we
want
to
try
to
take
one
and
turn
it
into
a
bit
more
of
a
full-fledged
metric.
B
C
A
Requests
yeah,
I
don't
think,
probably
first
nothing,
the
first
three
don't
look
like.
B
The
other
ones,
I
think
anything
from
before
may,
I
think
we
can
deal
with
offline,
but
okay
update
like
updating
grammar
live
links.
We
should
probably
do
that.
E
A
File,
because
I
think
contributors
are
spelled
wrong,
yeah
excuse
me
yeah.
We
can.
We
don't
have
to
worry
about
doing
this.
Resolving
that
merge,
complete
live.
I
think
that's
fine
and
that
that
also
looks
like
look
at
it
again.
B
A
A
B
B
A
Okay,
there
is
a
metric
file
that
snuck
in
here.
A
G
B
B
A
I
mean,
I
think
it's
fine
to
merge.
I
don't
see
any
reason
why
we
wouldn't
merge
it,
because
we
it's
not
we've
been
keeping
these
up
to
date.
I'd
I'd
like
to
get
that
metric
out
of
there
before
we
merge
it.
So
it's
not
a
huge
deal.
If
we
don't,
I
guess
so
that
we
can
or.
A
B
Yeah,
but
that
it's
like
clearly
one
that
has
existed
for
a
long
time,
but
probably
let's
see
yeah,
it
was
created
march
31st
and
never
developed
yeah,
so
that
was
kevin
was
that
before
the
spreadsheet
became
widely
used,
I
feel
like
we've
been
using
it
for
longer
than
that,
but
maybe
I'm
my
sense
of
time
is
all
distorted
since
the
pandemic.
I
E
I
One
was
not
was
not
nearly
as
built
out
as
the
one
we're
using
currently.
H
B
You
know
getting
rid
of
this
metric.
It
was
an
idea
that
had
only
a
name
and
no
other
intellectual
contribution
and
it
did
not
ever
get
to
the
spreadsheet
or
get
developed
or
get
discussed
in
the
subsequent
meetings.
So.
B
A
A
Okay,
should
we
look
at
some
of
the
issues?
Maybe
oh.
B
B
That's
a
this
is
an
interesting
idea
that
I
have
not.
I
mean
it's
occurred
to
me.
That
branches
do
indicate
something
I
haven't
ever
considered
the
metric,
but
I
think
it's
like
if
I
think
about
the
work
we
do
on
auger.
B
The
branches
that
come
and
go
certainly
do
indicate
that
we
are
busy
and
more
active
and
carter,
you've,
driven
that,
just
as
an
example
driven
us
towards
more
feature
branches.
B
So
I
think
all
we
would
do
is.
A
Third,
merge
located
yeah.
This
is
a
this.
Definitely
is
an
interesting
idea,
I'm
just
what's
the
intent
behind
measuring
it
like
what?
What
what
are
we
like?
I'm
trying
to
think
what
you
would
what
information
you
would
gain
by
like
what
kind
of
things
you
would
say
about
the
bridge
like.
J
It's
like
a
development
branch
or
a
stable
branch
or
like
different
version
brands,
so
it
gives
a
sense
of
overall
sense
of
a
repo
in
the
different
seats
or
like
okay.
The
development
work
is
being
happened
in
this.
This
is
the
staple
branch
which
is
like
used
by
anyone
who
would
just
want
the
code
or
anything
there's
like
a
version
branch.
Okay,
these
are
the
different
versions
you
keep.
A
Right
that
make
that
makes
sense,
I
guess
I'm
just
not
clear
on
what
that
information
gives
you
in
terms
of,
like
other
other
than
that
it
exists
that
there
are
multiple
branches
which
I
would
assume
most
to
get
projects
used
in
multiple
branches
and
anyways.
I
feel
like
I'm
probably
about.
I
don't
want
to.
B
So
is
it
possibly
a
filter
on
information
about
pull
requests
like
a
branch
fork,
switch.
A
I
don't
think
it's
a
filter,
because
I
mean
you
can
use
branches
without
pull
requests
just
by
merging
at
the
command
line,
which
is
like,
if
you're
using
git,
for
example,
yeah.
A
Which,
if
that
information
wouldn't
be
captured
on
pull
request,
so
I
think
that
information-
may
maybe
information
abrupt
about
the
branches
of
a
pull
request,
the
source
in
the
target
branch
that
actually,
that
still
might
be
an
interesting
like
filter
on
that
metric.
That
that's
something
I
would,
I
think
we
could
consider
adding,
but
I
don't
think
that
this
specific
metric
is
probably
a
filter
on
it.
That's
my
interpretation
at
least
so
do
we
want
to
should
we
should?
A
J
A
A
Maybe
that
means
they
release
it's
like
yeah.
You
can
get
that
information
from
releases
and
not
branches.
It's
gonna
say
I
mean
you
might
be
able
to
use
that
as
a
you
know,
an
indicator
of
project
maturity.
It's
been
around
for
a
while.
It's
got
a
lot
of
you
know,
branches
for
versions,
but
that
probably
fits
more
under
like
releases
or
tags
and
not
branches.
F
B
B
A
That
it
might
be
interesting
to
okay,
like
I
mean
that's,
giving
the
idea.
Maybe
it
would
be
interesting
to
look
at
the
way
that
the
projects,
the
project
uses
branches
like
do
a
lot
of
people,
commit
to
the
same
branch.
Usually
do
it?
Does
everybody
commit
to
their
own
branch?
Is
there
one
branch
where
everybody
works
together
and
then
everybody
else
has
their
own
separate
branch
like
referencing
like
cross
referencing,
the
contributors
and
the
commits
they're
making
with
where
they're
making
them
could
be
interesting?
G
H
B
I
don't
know
if
there's
other
issues
we
want
to
address.
These
are
just
release,
notes.
B
F
B
Armstrong
is
this
right.
I
I
think
the
request
here
is
to
integrate
visualizations
related
to
two
categories
of
metrics
issues
and
pr's.
B
What
are
we
calling
the
a
non-atomic
metric,
or
do
we
create?
Are
these
visualization
standards
that
can
be
implemented
by
tools?
B
B
B
B
Etc,
I'm
I'm
still
like,
and
a
non-atomic
metric
would
be
something
that's
like,
basically
putting
together
a
bunch
of
metrics
like
like
there
was
this
social.
The
value
group
had
this
incredibly
complex
metric
that
I
reviewed
and
suggested
I
think
12
different
atomic
metrics
required
to
construct
that.
C
J
J
A
J
J
B
J
I
think,
like
every
open
source
program
which
is
developed
through
these
git
platforms,
whatever
the
git
platform
goes
through
this
cycle.
B
Yeah,
and
and
like
have
you
seen
the
auger
community
reports,
because
this
kind
of
thing
is
pretty
honestly.
This
is
what
this
is,
what
the
what
you
call
it.
The
pull
request,
auger
community
report
is.
B
B
Here's
a
competitive
analysis
of
first
response
time,
looking
at
five
repositories
in
addition
to
zephyr
that
are
in
their
competitive
space,
mean
comments.
B
And
so
I
wonder
if,
if
so
I
tagged,
armstrong
and
matt
in
in
the
the
issue
here
in
my
comment.
B
Although
when
I
look
at
I've,
just
got
a
new
file
upload.
A
B
The
part
the
powerpoint
was
developed
by
our
colleagues
in
the
asia
pacific
region,
so
yeah.
It's
not
that
good.
F
E
B
A
Why
not?
Is
there
something
funky
with
the
formatting
of
your
link
like
what
happens
if
you
remove
the
link
and
then
try
to
post
the
comment
and
then
add
the
link
after
I
don't
know.
B
A
Okay,
which
issue
is
that.
A
360.,
do
we
wanna,
I
mean
it
is
9
30..
Do
we
want
to
talk
about
any
more
issues
or
maybe
try
to
focus
on
something
else
for
the
last
15
minutes?
I
think
everything
else
that
all
the
issues
that
are
open
have
been
open
for
a
while.
So
there's,
probably
not
much
else,
we
can
do
all
right.
C
J
J
Like
four
or
five
dependencies
metrics
like
co-dependency
package
dependency,
api
dependency
infrastructure
dependencies,
maybe
we
can
pick
one
and
refine
it
or
we
just.
A
Okay,
so
yeah
we
can,
I
mean
we
can
do
that.
Should
we
so
there's
like
I
mean,
there's
a
couple,
different
types
that
we
talked
about
like
types
of
dependencies
from
last
time,
it's
a
little
bit
farther
down
sean,
it's
right
there
that
it's
highlighted
right
there.
A
So
these
are
like
different
kinds
of
just
some
of
the
kinds
of
dependencies
that
we
like.
What
could
the
dependency
refer
to
that
we
thought
about
yeah
at
a
very
high
level,
at
a
pretty
quickly.
I
By
defining
these,
we
can,
we
can
talk
about
dependencies
in
the
future.
A
little
more
intelligently.
G
And
infrastructure
is
more
like,
depending
on
ios
or.
J
Like
this
google
app
platform,
something
like
those
like,
or
linux
or
windows,
maybe.
I
B
J
Yes,
like
once
after
use,
multiple
programs,
also
like
in
different
port
chunks,
so
where
they
are
dependent
on
sometimes
in
java
or
in
python,
or
in
like
some
other
language.
Okay,.
B
C
F
Called
dependencies
is
probably
in
order,
but
I
think
evolution
is
the
best
place
to
really
handle
these
kind
of
things,
because
yes,
because,
as
some
let's
take,
for
example,
api
dependency,
when
things
are
evolving,
they
become
duplicated.
They
start
creating
this
dependency
and
things
like
that
because.
F
I
I
B
J
I
think
risk
and
evolution
are
very
kind
of
overlapping.
Also,
sometimes
it's
like.
D
I
E
I
Just
a
matter
of
perspective,
it's
the
yes
the
way
you
look
at,
and
I
think
I
think
evolution
looks
at
dependencies
from
a
very
in
a
very
useful
way
for
all
of
the
working
groups
and
then
and
then
risk
and
common
and
value
are
probably
looking
at
it
in
more
specific
use
cases
if
they
want
to
yeah.
B
I
agree,
and
I
think
I
think
so
risk
is
looking
at
it
from
a
sustainability
as
well
as
a
runtime
trustworthiness
perspective.
B
So
I
don't
have
religion
about
where
it
lives.
I
think
it
definitely
is
a
concern
for
evolution,
kevin
and
now
we
have
this.
We
do
have
a
way
of
indicating
there's
a
state
where
we
can
say
it
refers
to
it.
There's
a
different
working
group:
that's
working
on
these
metrics.
J
I
Yeah,
I
think
that's
I
think
that
that's
already
gonna
be,
I
think,
that's
addressed
through
the
the
dependency
metrics
that
we've
already
mentioned.
The
nod.
D
I
I
But
I
think
I
think
evolution
is
a
great
place
to
set
the
standard
yeah.
I
agree.
A
B
Maybe
we
could
create
the
docs
okay,
where
we
have
like
yeah.
We
have
eight
minutes.
Maybe
let's
just
pick
a
pick,
one
of
the
dependency
ones
and
get
it
sketched
out
in
the
google
doc
for
five
minutes.
A
B
Very
nervous
it
is,
it
is
absolutely
random
people's
google
accounts
and
in
an
ideal
world,
what
we
should
probably
do
is
have
a
chaos.
Google
account
that
is
owned
and
controlled
by
some
collection
of
people
where
nobody
can
delete
it
yeah,
but
right
now,
it's
just
a
bunch
of
people's
google
accounts.
E
I
Once
it
becomes
once
we
transfer
it
to
markdown,
we
never
return
to
these
documents
right,
so
so
the
I
guess,
the
the
main
reason
to
to
keep
them
would
be
to
keep
that
history
of
work.
I
J
J
Maybe
a
discussion
for
a
journal
working
group
that
should
we
have
a
transparency
of
the
google
docs
also
for
the
record.
A
Okay,
I
just
created
one
for
code
dependencies
and
I
put
the
the
the
link
in
there
in
the
in
this
spreadsheet
and
I
can
go
ahead
and
copy
the
template.
A
A
A
A
We
can
start
if
we
want
and
put
the
template
in.
B
So
co-dependent
when
we
say
codependencies
it's,
it
sounds
like
codependency
when
we
say
code
dependencies
do
we
mean
like
the
import
statements
that
are
in
within
a
program.
B
Also
so
it's
interest
so
there's
so
there
were
like,
like
libraries.io,
did
a
good
job
of
scanning
the
package
managers
for
dependencies
between
packages
distributed
to
that
individual
platform.
B
By
just
just,
although
it
wouldn't,
it
wouldn't
indicate
the
thing
that
package
manager-
and
this
is
hard
to
do
without
visualization
package
manager
dependencies
get
you
the
packages
that
also
have
to
be
installed
when
you
install
like
mat
lot
like.
Let's
take
matplotlib,
for
example,
there's
like
a
half
a
dozen
other
packages
that
automatically
get
installed
when
you
install
matplotlib.
B
E
B
J
B
F
This
is,
I
don't,
really
know
the
mindset
of
developing
co-dependence
in
this
perspective,
like
in
agreement
with
what
you
guys
have
already
said
up
front,
I
would
think
they
were
trying
to
look
at
the
class,
the
function
and
the
meta
dependencies,
because
already
we
we
know
about
the
api
and
the
package
manage
the
pack
management
dependency
and
the
part
dependency,
but
code
dependencies
a
lot,
it's
a
little
bit
ambiguously
defined.
A
B
C
A
A
Coming
everybody
see
you
in
two
weeks.