►
From YouTube: CHAOSS Common Working Group - 11-12-20
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
Charge
just
like
charles
in
charge,
but
better
so
welcome
to
the
november
12th
chaos
common
meeting.
If
you
could
add
yourself
to
the
agenda,
that
would
be
great
so
going
through
the
agenda
looks
like
we
have,
as
we
start
approaching
the
holiday
season,
we're
gonna
call
into
question.
Maybe
just
a
few
of
the
meetings
obviously
looks
like
our
next
one
for
common
would
be
on
thanksgiving,
so
that
is
naturally
not
going
to
happen
and
then
the
10th
would
be
the
next
one
looks.
E
A
A
A
That
sounds
good
all
right,
so
the
next
thing
is
taking
a
look
at
action
items
from
previous
meetings,
so
I
will
scroll
down.
A
A
So
let
me
take
a
look
at
that:
google
lock.
If
you
could
take
a
look
at
that
google
doc
real
fast,
the
burstiness
one.
I
don't
think
yoga
has
added
the
visualization.
A
F
D
A
F
C
Have
I
have
the
auger
technology
api
worked
out
for
showing
language
distribution.
A
C
I
haven't
finished
the
metric,
but
I
know
how
to
build
an
auger
which
is
the
like
for
me
just
how
I
do
things
and
then
I
back
it
into
the
metric.
B
B
E
And
I
had
the
technical
folk,
I
created
a
pull
request.
I
think
kevin
made
some
changes
in
that
and
don't
accept
it.
I
forgot
to
add
it
on
the
github
readme
page,
so
I
think
that
pull
request
is
still
pending.
B
Looking
at
that
pull
request
and
and
your
your
dco
check
always
fails,
do
we
know
why
that
is
so.
E
I
tried
to
figure
it
out:
I'm
using
a
tool
called
git
crane,
it's
a
software
which
provides
the
integration
with
the
github.
I
think
it
is
because
of
that
I
provide
all
the
signature,
even
the
like
email,
everything
but
and
the
gpc
set,
which
like
verifies
secure,
setup
with
the
github,
but
I
I'm
not
sure
why
it's
doing
it.
I
have
created
a
issue
on
the
platform
like
github
for
them
to
get
it
fixed.
B
F
A
F
I
didn't
think
it
was.
I
wasn't
at
the
last.
I
wasn't
at
the
last
comment
meeting,
so
I
wasn't
sure
if
this
was
if
we
were
moving
it
towards
release
or
if
we
were
completely
releasing
it.
So
there's
there's
pull
requests
on
the
website
side,
so
I
got
a
little
worried
that
it
was
going
alive.
The
way
it
was
so
I
so
I
went
in
and
made
several
copy
edits
and
cleaned
up
some
of
the
text
that
I
thought
was
a
little
troublesome.
F
So,
however,
that
pull
request
has
not
been
put
through,
so
I
think
I
I
think
I
requested
reviews
on
it.
So.
F
B
So
I
already
merged.
Let
me
just
I'll
back
up
a
little
bit,
I
already
merged
the
technical
forks
full
request.
Oh.
B
Then
the
number
5
number
95
is
actually
just
a
change
to
the
readme
file
to
point
to
the
technical
forks
metric.
A
B
Under
the
focus
areas
for
what
so
it's
it's
just
the
it's
just
a
readme
file,
change
that
didn't
get
made
in
the
first,
the
first
one.
So
we
can
probably
just
merge,
merge
that
one
and
then
we
can
take
a
look
at
kevin's
changes
because
I'll
admit
that
I
I
saw
I
was
tagged
for
review
and
then
I
forgot
to
do
it.
B
A
F
F
There
were
a
couple
sentences
in
there
that
I
found
a
little
troublesome
based
on
previous
conversations
about
the
the
technical
fork
metric
and
one
of
those
is
that
the
when
we
were
when
we
were
building
the
technical
that
fork
metric.
F
F
So
it's
a
little
shorter
and
then
and
then
there
there
are
some
copy
edits
in
it
as
well.
C
A
F
Are
two
two
commits
that
are
part
of
this,
so
the
it's
a
little
harder
to
tell
what's
been
changed.
F
So
I
removed
the
so
the
technical
fork
metric
indicates
how
many
people
created
a
distributed
copy
of
the
repository
to
a
different
account
or
organization.
On
the
platform
I
removed
that
whole
last
sentence,
because
I
don't
believe
we're
counting
people
in
this
metric.
I
think
we're
just
counting
the
forks,
that's
right,
so
so
that
last
sentence
doesn't
really
add
anything
so
that
was
removed
that,
following
sentence,
the
technical
forks
may
provide
insight.
I
actually
pulled
that
out
and
kind
of
rewrote
it
and
moved
it
down
into
the
objectives.
F
And
then
in
the
objectives
I
removed
the
remove
the
parts
that
were
kind
of
taking
us
away
from
what
technical
forks
were
and
kind
of
soften
the
language
on
technical
forks
can
can
provide
insight
into
these
forking
intentions.
And
then
we
can
talk
about
the
contributing
and
non-contributing
forks.
So.
A
Kevin
I'm
moving
down
into
implementation.
Do
you
want
to
walk
us
through
a
little
bit
about
what.
F
You
were
doing
through
there
down
here.
It's
mostly
just
copy
editing,
so
reminder
in
markdown.
Two
spaces
creates
a
a
new
line.
F
So
generally,
I
think
it's
best
practice
to
do
two
spaces
after
you,
after
you
do
a
line
just
to
ensure
that
the
the
next
line
is
a
new
line.
Okay
and
then
for
the
there
was.
I
think
there
was
a
typo
in
the
filter.
F
F
Yeah,
so
the
ratio
of
non-contributing
fork
to
total
fork,
two
total
forks.
I
forget.
F
E
F
A
A
A
A
A
All
right
that
is
merged.
A
Great
all
right,
the
next
thing
is
to
take
a
look,
we've
kind
of
been
doing
this,
taking
a
look
at
the
prs
and
issues
we
currently
have
zero
pull
requests.
A
A
So
if
I
bring
up
on
the
issues
here,.
E
E
A
And,
as
I
was
made
fully
aware,
that
will
stay
until
we
do
the
next
full
release
in
january,
so
it'll
be
marked
this.
This
issue
will
remain
open
with
this
label
until
january.
Whatever
is
the
next
release
right?
C
That
came
up
in
the
evolution
meeting
last
week
and
I
think
it
failed
to
make
the
agenda
for
the
general
meeting,
but
the
the
idea
is
that
we
created
these
deadlines
around
events
that
no
longer
occur
at
the
same
time
and
will
not
occur
in
the
next
year
and
force
us
to
develop
metrics
during
like
really
terrible
times
of
the
year
like
the
holidays
and
august
they're
they're
just
july,
I
mean
they're
bad
times
for
people,
and
you
know
just
let's
just
rearrange
it.
F
C
F
So,
rather
than
rather
than
doing
the
release
right
now,
the
target
is
february
1st.
We
would
target
march
1st
instead.
A
Okay,
all
right
seems
totally
fine
to
me
anyway.
Other
issues
that
we
have
in
here
looks
like
most
of
them
are
new
metric
ideas
all
from
daniel,
oh
burstiness.
What
is,
can
we
close
this
32.
C
A
Yeah,
I
I
think
I
was
I
had
burstiness
and
technical
fork,
somehow
crisscrossed
in
my
head.
So
as
soon
as
it
came
out
and
then
I
realized
I,
it
was
not
correct.
Okay
cool
all
right,
so
maybe
this
can
lead
into.
We
have
time
between
review
cycles,
time
waiting
for
reviewer
action,
submitter
action
and
time
to
merge.
A
Maybe
could
somebody
make
a
note
in
these
metrics
that
these
are
moving
forward
as
part
of
our
call,
but
it's
not
just
an
idea
at
this
point
that
these
are
actually
being
discussed.
It's
a
little
traction
on
the
unless
people
think
that's
a
bad
idea,
just
a
little
traction
on
the
issues.
F
Create
a
new
new
label.
A
G
F
It's
kind
of
a
it's
kind
of
a
light,
light
blue
gray,
so
remove
remove
metric
idea.
I
think
so.
A
And
then
kevin,
can
you,
as
I
work
through
the
agenda?
Can
you
just
add
something
to
that
issue
to
orbinod?
What's
that?
Oh,
it's
just
a
it's
just
to
update
the
issue
a
little
bit
just
a
comment
that
says
we're
currently
working
on
this
at
the
above
document.
We
talk
about
it
bi-weekly.
You
know
something
along
those.
A
A
A
At
the
moment
we
have
technical
forks,
which
I
move
to
under
review.
We
have
sean,
you
have
language
distribution.
C
Yeah-
and
I
can
just
I
haven't-
finished
working
out
the
metric,
but
I
can
show
you
kind
of
what
it
looks
like
here.
That'd
be
cool
screen,
share.
Well,
I'll,
show
you
what
all
right
do
I
have
to
give
you
permission,
sir.
Let
me
give
you
nope
now
I've
got
it
just
have
to
find
my
all
right,
so
you
don't
care
about
the
query,
but
basically
on
any
repo.
C
A
A
Okay,
we
have
that
one
pretty
much
done
at
this
point
and
then
burstiness.
It
looks
like
we're
waiting
for
the
visualization
from
george.
A
A
Distribution
and
burstiness
that
both
appear
to
be
nearing
the
finish
line
right
and
then
maybe
maybe
we
could,
like
you,
know
just
kind
of
help,
daniel
as
a
as
a
working
group
here
to
think
through
some
interaction,
reviewer
action
and
time
between
iterations
to
me,
it
doesn't
seem
like
we
need
to
necessarily
take
on
more
metrics
but
help
help
these
through
the
process.
What
do
you
all
think.
C
Yeah,
I
think,
let's
get
them
through
the
process.
We
could,
if,
like
what
we
did
in
evolution,
is
we
said
these
are
the
ones
we're
definitely
putting
through
the
process,
and
then
we
identified
a
couple,
others
that
you
know
time
permitting.
We
might
pursue.
A
Okay,
all.
B
A
E
Which
one
time
between
review
cycles
where's
that
one.
D
A
D
F
A
A
F
C
Between
reviews
yeah,
it's
it's
when
a
pull
request
is
made,
but
it's
not
accepted
and
changes
are
requested
and
then
it
goes
back
under
review
and
there's
there's
changes.
So
on
me.
You
said
you
get
a
when
you
do
a
review
of
a
pull
request.
You
can
approve
it
or
you
can
ask
for
changes
and
it's
how
long
it
takes
that
ask
for
changes
to
occur
and
then
how
long
it
takes
the
original
pr
maker
to
make.
The
changes,
I
think,
is
what
we're
talking
about.
E
E
What
I
recall
we
changed
the
review
to
the
change
request
right
in
all
the
metrics
wait.
Is
it
the
time
between
a
change
request.
E
A
A
That
the
this
is
the
length
of
time.
F
F
F
E
I
think
we
have
a
review,
we
change
all
to
the
change.
First.
E
F
Okay,
then
I
would
then
I
would
change
what
I
said
there
and
maybe
before
we
talk
about
the
time
that
it
takes
between
reviews,
we
should
maybe
define
reviews
as
a
metric.
A
C
Really,
I
think
you
can
think
of
it
as
a
this
is
part
of
the
change
request,
approval
process
so,
like
change,
requests,
we've
defined
one
way,
and
this
is
really
the
cycle
of.
I
guess
it
is.
It
is
the
review
cycle
within
the
pull
request,
the
change
request
process.
C
Right
and
I'm
just
saying
that
the
reviews
could
be,
we
can
reference
change,
requests
and
talk
about
the
review
cycle
inside
of
change
requests
like
that's
the
way,
because
they're
connected
in
in
that
way,.
F
Comments
are
a
different
activity
within
a
change
request.
That's
yeah,
they
are,
I
mean
it
can
be
part
of
a
review
but
yeah.
So
if,
if
change
request
comments
is
a
metric,
then
change
request.
Reviews
should
be
a
metric
as
well,
and
I
and
I
realized
that
it's
a
kind
of
a
a
lower
abstraction
of
a
change
request,
but
it
is
it's
an
activity
within
a
pull
request
that
could
be
handled
as
its
own
metric.
Otherwise
we
could
just
say:
everything's
change,
requests
right.
G
F
F
F
Think
there's
too
much
stuff
going
on
there
to
just
include
it
within
the
change
request
metric.
But
to
the
earlier
point,
I
think
if,
if
we're
going
to
talk
about
the
time
between
review
within
a
change
request,
we
probably
need
to
define
this
thing.
That
is
the
review
activity
before
we
do
that.
F
I
agree
and
that's
the
I
think,
the
in
in
github,
there's
reviews
invited
reviews
accepted
and
reviews
completed
number
of
reviewers
the
edits
made
during
that
process.
There's
a
bunch
of
stuff.
E
A
Even
better
so
cha
listening
to
talk
kevin
like
a
metric
called
change,
request,
reviews
or
change
request,
review.
F
A
A
Okay,
let's
I'll
just
I
mean
what
do
we
even
say
here?
Does
this
work.
A
A
When
we
come
back
in
the
10th
in
a
month.
I'm
sure
you
will
totally
remember
this
discussion
guaranteed
all
right.
Well
with
that
does
any
does
anybody
else
have
any
comments
on
on
this?