►
From YouTube: CHAOSS.Community.Evolution
Description
CHAOSS.Community.Evolution
A
All
right
welcome
to
the
november
4th
2020
evolution
working
group.
Lots
of
things
are
evolving
today,
but
one
of
them
is
our
understanding
of
software
evolution
in
the
open
source
community.
We
have
a
number
of
items
here
that
we
want
to
share
and
I
will
share
my
screen
for
those
items
to
facilitate
the
video
so
with
us.
Today
are
carter
myself,
kevin
and
venad,
and
our
agenda
is
to
review
the
status
of
name
chain
or
name
name
change
or
into
pull
requests.
A
As
you
may
recall,
the
reviews
name
that
was
used
for
pull,
requests
on
github
and
merge
requests
on
gitlab
caused
a
great
deal
of
confusion
from
for
anyone
who
is
a
newcomer
to
to
chaos,
so
it
became
an
obstacle
to
newcomer
newcomer
integration
and
stickiness
in
the
project,
and
so
it
needed
to
be
fixed
and
we
landed
on
change
requests
instead
of
reviews,
and
so
I
just
want
to
run
over
to
the.
B
A
A
B
Actually,
if
you
pull
up
the,
if
you
pull
up
the
release,
notes
issue,
which
I
will
drop
into
the
chat,
real
quick,
the
code
requests
change.
What
is
that
code
request
change.
B
Yeah
and
some
of
them
there
are
some
notes
in
here
that
so
code
change,
code,
change,
request,
iteration
is
one
of
them
and
then
the
other
one
is
code,
change,
request,
efficiency.
A
B
B
A
B
I
should
say
one
one
question
I
had
on
this
was
since
we
are
since
we're
in
the
process.
I
think
code
review
iteration
is
the
one
you're
talking
about
yes
and
it
changes
to
code
change,
request,
iteration.
A
Let's
see
how
developed
this
one
is
not
really
at
any
level
of
development.
So
if
we
get
to
the
point
of
working
on
metrics,
it
seems
like
these
are
metrics
that
we
want
to
focus
on
if,
unless
anyone
disagrees.
B
So
for
code,
review
efficiency,
there's
a
note
there
that
says
it's
the
same
as
go
back
to
that
pre
the
same
as
review.
A
B
A
And
code
review,
iteration
yeah,
I'm
just
sorry,
I'm
going
to
leave
these
pending
because
I
already
lost
track
of
which
ones
they
are
so
I
think
code
review
efficient.
I
don't
know
carter
vinod
kevin.
What
do
you
think?
I
think,
when
I
think
of
what
code
review
efficiency
is-
and
I
think
of
what
review
duration
is
review.
Duration
is
a
discrete
statistic
that
just
counts
the
days
when
I
think
of
efficiency.
A
Yeah,
so
if
I
jump
back
to
the
stock
name
of
the
metric
okay,
I
don't
it's
like.
I
still
don't
know
how
google
determines
what
my
default
user
is.
B
B
B
A
A
A
A
B
C
D
D
B
So
change
request,
iteration
and
change
your
quest.
A
Because
the
markdown,
the
google
doc
has
nothing,
has
nothing
yeah.
So
that's
the
part,
that's
baffling
to
me:
oops,
I'm
gonna
change,
request,
efficiency.
A
C
A
So
to
avoid
fair,
so
question:
is
there
description,
objective
implementation,
filter
description,
visualizations
tools,
data
collection,
references
all
right,
so
we're
it's
all
there?
It's
not
it's,
not
the
wrong
template.
I
just
wanted
to
make
sure
before
I
blew
it
away.
So
we
have
change,
review
change,
request,
efficiency,
actually
in
better
shape
than
we
realize.
A
Did
you
say
that
change
request?
Iteration
was
also
in
the.
A
A
A
So
at
least
we
have
at
least
we
have
that's
a
bit
more
developed
than
we
thought
it
was
so
now
we're
back
to.
We
have
three:
we
actually
have
three
metrics
that
are
change,
request,
oriented
that
have
been
initiated
and
developed
to
varying
degrees
change,
request
comments
that
still
change
request
comments.
I
don't
need
two
of
those
review.
Comments,
no
longer
exists,
change,
request,
iterations,
not
very
well
developed
change,
request,
efficiency
that
is
still
change
your
breast
efficiencies.
A
So
it's
duplicate
review
comments
no
longer
exists,
so
we
have
change
request,
efficiency,
change,
request,
iterations
and
change,
request
comments,
change,
request
comments
is
clearly
the
farthest
along
yeah.
It's
certainly
the
easiest
one
to
to
wrap
up
yeah.
So
do
you
want
to
maybe
spend?
Should
we
spend
like
10
minutes
working
on
this
one
like
or
do
you
want
to
discuss?
We
can
stay
on
the
line
and
discuss
it.
A
A
B
I
know
well,
some
of
the
some
of
the
working
groups
do
do
that.
I
think
that's,
I
think,
that's
up
to
to
you
and.
A
A
If,
if
that
works
for
for
everyone.
C
A
B
C
B
Quick
question
yeah,
so
on
the
did
you
add
these?
Did
you
add
the
change
request,
comments
to
the
sheet.
A
C
A
B
A
B
B
A
I've
changed
them
depending
is
so
I
can
find
them
in
the
spreadsheet.
I
don't
I
don't.
Actually
what
is
I'm
sure
it
tells
me
pending
means
want
it
want
to
add
it
for
release.
So
I
think
that
we
can
say
I
mean
I
think,
that's
legit,
to
leave
these
at
penn
yep
yep.
I
think
you're
right
and
like
so
I
think,
let's
get
through
these
three
and
because
the
next
is
there
a
date
for
the
next
like
for,
if
we
like,
set
a
calendar
for
the
next
early
cycle
january.
B
Deadlines,
oh
it'll,
be
the
it'll
be
the
end
of
december,
because
the
the
month
of
january
is
the
review
period
and
then
it
gets
released
right
before
fosdem
so
february.
1St
ish.
A
A
B
A
I
think
I
think
we
just
make
it
the
end
of
like
the
release
goes
into
under
review
in
february
and
start
that
the
review
period
can
begin
at
fosdem,
because
fosdem's
going
to
be
virtual
and
so
I've
seen
it.
I
see
no
reason
to-
and
it's
really
frankly
for
the
working
groups
that
I
work
in.
It's
really
hard
to
get
people
engaged
after
thanksgiving.
So
I
want
january
and
there's
no
reason
that
there's
no
reason
that
we
should
limit
the
metrics
we
release
simply
to
have
them
released
at
a
conference.
A
Yeah
so
I'll
make
I'll
make
I'll
make
that
point,
maybe
on
the
mailing
list.
First.
B
So,
generally,
generally
speaking,
we
we
shoot
for
two
regular
releases
and
they
don't
have
to
be
spaced
completely
six
months
apart,
but.
A
So
february,
like
released
at
the
end.
B
B
A
A
Yeah
yeah,
so
I
think
I
think
our
release
dates
can
a
lot.
You
know.
We've
kind
of
forced
release,
dates
that
I
think
times
that
are
really
bad
times
of
year,
like
august
is
terrible
for
europe.
We
should
just
adjust
it
because
a
none
of
these
conferences
are
happening.
This
year
and
b
oss
summit
north
america
moved
to
june
so
said
you
know.
D
A
C
So
on
this
line,
26
27
28,
we
have
review
accepted
review
decline
to
view
duration.
Are
these
going
to
be
change,
request,
accepted
change,
request,
decline
or
change,
request,
duration?
Or
is
it
going
to
be.
A
C
A
A
Okay
and
I
think
yeah,
like
line
35,
that's
I
assume
that's
been
updated
right.
I
haven't
like.
D
B
A
A
Yeah
change
request
commits
and
change
request
files.
B
A
B
B
Okay,
we
got
all
right
and
then
one
more
thing
before
we
jump
to,
I
think
we're
going
to
look
at
change.
Request
comments,
yeah,
one
more
thing
before
we
change
to
that:
can
we
can
we
look
at
what
the
pending
and
the
in
progress
are
real,
quick
and
decide
which
can
kind
of
rank
them
in
order
of
either
determine
which
ones
we
do
want
to
work.
B
Them,
okay,
so
so
the
order
for
pending
and
in
progress
is
in
progress
is
advancing
it
for
the
release
pending
is
want
to
add
it
for
the
release.
Yeah
oops
did
something
weird
there.
B
B
A
F
G
A
B
A
B
Which
is
it's
weird,
but
but
that's
that's
the
way
we
would
defined
it
so.
A
So
advancing,
why
am
I
not
seeing
advancing
for
release
on
this
drop
down
should
be
in
progress?
A
A
All
right
in
code
change
files,
we
haven't
done
any
work
on
code
dependencies,
I
would
say
pending
like
we
haven't.
I
think
there's
there's
just
a
lot
of
questions
about
those
those
right
now
that
we
want
them
like.
I
guess
all
of
these
are
pending
they're
not
being
considered.
We
want
to
do
them,
but
they're,
not
we're
not
we're
not
advancing
them.
A
A
A
A
B
A
A
And
I'm
changing
it
to
change,
request
acceptance
ratio.
So
if
I
was
to
say,
I
think
change
acceptance,
change,
acceptor,
question,
good
god
change,
request,
acceptance,
ratio
and
change
request
comments
are
the
two
that
are
farthest
along
okay.
If
that
does
that
look
that
looks
when
I
look
at
the
sheets.
A
A
A
A
Should
we
are
we
do
we
want
to
go
there
or
do
we
wanna?
I
mean
we
got
basically
five
minutes.
If
we
want
to
try
see
how
far
we
can
get.
D
We
could
do
that.
There
also
was
another
issue
that
that
I
mean
if
we
wanted
to
talk
about
it
that
got
opened.
I
think,
like
all
right.
D
D
B
B
E
Mapping
stability
of
change
requests
to
issue
mapping
because
we're
looking
for
a
change
request,
link
to
issue.
A
A
C
Change
request
to
issue
ratio.
Basically,
we
are
calculating
the
ratio
yeah
right.
B
A
D
A
C
Yeah
change
request,
issue
mapping,
title
change
request
something
similar.
A
Mapping
or
something
like
that,
and
I
think
that
might
go
under
efficiency
or
it
could
go
under
issue
wrestle
resolution.
B
I
would
do
I
would
actually
do
efficiency,
because,
because
there
is
a
there
is
a
connection
between
merge
success
and
whether
or
not
it's
linked
to
an
issue.
C
B
Can
go
anywhere
either
of
these,
so
it's
kind
of
an
issue
of
explicit
coordination
versus
implicit
coordination.
So
what
you?
What
you
also
see
is
that,
in
in
in
large
projects,
you
see
that
change
requests
are
more
often
explicitly
linked
to
pull
requests
than
in
smaller
projects,
and
then
also
what
you'll
also
see
is
that
the
more
the
more
complex
a
change
request
is
the
the
more
likely
it
is
linked
to
a
issue.
D
So
one
of
the
in
the
in
the
original
issue,
king
linked
to
an
old
issue,
that's
actually
still
open
on
evolution,
talking
about
basically
the
same
thing
from
the
issue
side.
D
One
of
the
interesting
points
it
brings
up
is
talking
about
like
issues
that
wouldn't
necessarily
map
to
a
pull
request,
because
they're
more
like
discussion
based
or
just
they're
trying
to
it's
like
a
bug
report
or
something
like
that-
I'm
not
well.
I
guess
that
probably
would
fit,
but
maybe
that
changes
how
we
think
about
it.
B
C
I
have
a
question
on
mapping
versus
ratio
in
mapping.
We
are
matching
one
to
one,
but
in
ratio.
We
are
looking
in
totality
of
all
the
issues
and
all
the
pr
requests,
and
what
is
the
ratio
of
these?
B
C
My
question
was
more
on
the
defining
on
this.
Maybe
we
can
think
on
it
when
we
brain
is
from
like
right
upon
this,
I
was
focusing
on
the
method
like
okay:
are
we
focusing
on
matching
it
them
together
or
with
other
issues,
or
we
are
just
aggregating
them
and
seeing
a
ratio
of
matching
to
assess
the
health
or
like
evaluate
overall
health
of
the
project
or
a.
A
A
I
just
type
some
stuff,
I'm
sure
I
think
you
can
see
it
on
my
shared
screen.
Just
is
there
at
least
one
issue
mapped
to
a
change
request.
That's
the
first
thing,
because
often
there's
not
if
more
than
one
issue
is
mapped
to
a
change
request,
what
is
the
total
and
then
so?
That's
from
the
change
request
perspective
and
then
to
vanad's
point.
If
issues
are
mapped
to
more
than
one
change
request,
what
is
the
ratio
of
issues
to
change
requests.
B
A
D
At
time,
but
I'm
a
little
bit
confused
about
sean
if
you
can
go
back
to
that.
Yes,
the
third
point:
the
ratio
of
issues
to
change
requests.
So,
like
I,
I
guess
I'm
confused
because
in
my
mind
it's
like
you're
either
looking
at
one
issue
right
like
is
it
so.
Let
me
see.
A
A
Actually
yeah,
there
needs
to
be
a
second
line
there.
If
change
requests
are
mapped
to
what
is
the
okay?
If
actually
the
line,
it's
not
what
the
total
is.
But
what
is
the
ratio
right
if,
if
one
issue
is
mapped
to
a
change
request,
if
more
than
one
issue
is
mapped
to
a
change
request?
What
is
the
ratio
of
change
requests
to
issues?
A
A
A
It
was
like
a
reasonable
good
use
of
our
last
three
minutes,
because
I
think
we've
also
do
we
add,
and
this
is
this
is
going
to
go
under.
B
C
Oh
I'm
saying
that
this
particular
patrick
itself
is
an
efficiency
metric.
Isn't
it.
B
B
Again,
so
that
would
be
how
the
the
relationship
between
change
request
issue
mapping
is
to
merge
success
right.
A
Is
that
it
feels
like
there's
some
optional
parameters,
I'll
put
it
under
here
for
now.
B
A
A
Okay,
all
right
now
we
are
six
minutes
and
25
seconds
past
time,
I'm
going
to
say
very
productive
meeting.
If
anyone
wants
to
begin
working
on
these
issues
in
the
next
few
weeks,
that
would
be
awesome.
A
So
let's
go
forth
and
see
what
new
hijinks
have
occurred
in
the
united
states
of
america.
While
we
were
on
this
call
and
we'll
talk
with
you
all
soon,.