►
From YouTube: CHAOSS Common Working Group Meeting 01-07-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).
B
I
think
I
missed
the
last
meeting
yeah,
so
I
kind
of
threw
together
a
very
generic
agenda,
but
if
there's
other
stuff
people
want
to
talk
about
or
if
somebody
else
wants
to
wants
to
drive
this
based
on
what
we
did
last
week,
that's
that's
totally
cool.
I'm
a
little
bit
out
of
the
loop.
B
Yeah
I
took
three
weeks
of
holiday
and
it
was
amazing,
but
I
feel
like
I've,
I'm
coming
back
and
I've
just
forgotten
everything.
I
have
no
idea.
What's
going
on.
C
And
time
waiting
for
submitter
action,
so
this
is
the
time
between
review
cycles
was
one
that
daniel
had
brought
up.
If
I
recall-
and
I
think
we're
getting
some
pretty
good
resolution
on
it,
I
think
it
was
a
little
confusing
as
to
what
that
meant,
but
I
think
the
narrative
is
starting
to
play
out
pretty
well.
C
C
And
then
the
only
other
thing
that
I
was
thinking
about
this
morning
with
respect
to
common
in
the
agenda
is
maybe
this
year.
Thinking
about
how
the
common
metrics
are
being
kind
of
played
out
in
the
other
working
groups
and
try
to
you
know
like
make
those
connections
a
little
bit
more
explicit,
because
I
they're
certainly
there
there's
no
doubt
about
it,
but
working
to
just
really
highlight
that
work
as
it's
being
consumed
or
used
in
the
other
working
groups.
B
C
B
B
B
B
Okay,
so
do
we
want
to
start
with
the
open
issues
and
prs?
It
looks
like
we
don't
have
any
pr's.
B
C
Yep,
so
I
can
share
my
screen
real
quickly,
perfect,
so
here's
the
current
set
of
issues
in
common
you
can
see
that
two
of
the
seven
issues
are
related
to
the
release,
so
technical,
forks
and
just
the
release
notes
I'm
guessing
that
this
number
89
right
here,
the
time
between
review
cycles.
We've
gotten
all
this,
like
the
naming
of
the
that's
the
other
thing
we
did.
C
So
obviously,
this
one
is
something
that
I
think
we
can
take
care
of
today,
cool,
particularly
with
getting
this
metric
done
and
honestly.
The
rest
are
just
really
new
metric
proposals
for
common.
So
I
I'm
guessing
these
issues
can
kind
of
be
taken
care
of
as
we
develop
the
metrics
associated
metrics
or
decide
not
to
with
each
one
of
these
issues.
So
I
don't
know
that
there's
much
to
do
with
this
list
today,
at
least
at
the
moment.
C
B
C
C
So
elizabeth
and
john
bernard,
whoever
was
on
that
call
last
time
I
think
really
what
what
this
comes
down
to
is
kind
of
like
a
an
academic
paper.
C
So
as
you
would
submit
what's
the
time
between
that
submission,
and
you
know
any
changes
that
are
requested
where
it
kind
of
comes
back
to
the
to
the
author
right.
So
how
long
is
that
time-
and
there
may
be
things
in
between
there,
but
we're
just
trying
that's
what
a
review
cycle
is
here,
so
I
would
issue
a
pr
don.
You
would
talk
about
it.
Other
people
would
chime
in
on
the
pr
and
then
the
time
between
me
then
submitting
a
revision
to
that.
A
A
A
To
the
next
cycle,
or
is
it
that
you
know
so
it's
a
little
bit
confusing,
so
I
think
that's
where
we
landed
last
time.
F
A
And
down
in
implementation,
I
think
we
sorted
it
out
a
little
further
how
to
calculate
that.
F
So
is
this:
how
quickly
a
pull
request
is
responded
to?
Is
that
what
we're
talking
about.
C
No,
but
that's
part
of
it,
so
it
would
be
sean
again.
Elizabeth
told
me
if
I'm
wrong,
but
it
would
be
somebody
submitting
a
pr,
okay
and
there's,
there's,
certainly
a
response
to
that
pr
and
there's
conversation
about
that
particular
pr.
Even
after
the
first
response.
B
Okay,
I
think
the
reason
it's
the
reason
it's
framed.
This
way
is
because
you
can
have
within
a
single
pr
multiple
review
cycles.
So
I
get
I
get
feedback,
I
make
some
changes
and
then
I
you
know
add
some
more
commits
or
whatever
to
address
some
of
those
changes,
and
then
people
provide
more
feedback,
and
maybe
that
wasn't
quite
right
and
then
I
need
to
submit
some
more
commits.
So
it's
this
multiple,
you
know
and
really
complex
code.
You
do
get
this.
You
get
this
multiple
review
cycles
within
a
single
pr.
F
Super
helpful,
thank
you
because,
when
I
first
just
coming
from
at
this
point
an
outsider's
standpoint,
I'm
when
I
saw
review
cycles
it
made
me
think
of
you
know
how
I'll
just
take
openstack,
for
example,
how
if
the
project
releases
twice
a
year
or
you
know
the
spring
in
the
fall
or
what
have
you
it
made
me
think
of
like
the
time
between
the
like,
you
know,
mataka,
and
what
would
that
have
been,
but
right
between
those
reviews.
F
B
B
C
C
Again
thinking
academic
paper
wise,
those
are
two
things
that
do
get
reported
differently
right.
So
it's
actually
not
the
review
cycle.
Duration.
It's
how
long
it's
been
in
review.
There's
one
thing
that
gets
reported
in
academic
papers
and
then
I
know
these
aren't
academic
papers
and
then
the
other
is
how
many
times
it
went.
C
C
Right,
so
do
you
want
to
don?
Do
you
want
to
take
maybe
five
minutes
for
all
of
us
to
read
it?
I
think
it's
pretty
close
at
this
point,
or
do
you
just
want
to
kind
of
take
it
as
is
and
use
the
community
review
period
as
a
time
that
we
could
make
changes,
because
we
could
move
it
out
of
this
stage
and
into.
B
B
F
C
A
A
D
D
D
Former
and
it's
it's
really
the
last
last
line
where
it
says
the
duration
of
a
review
cycle
or
the
time
between
each
new
version
of
the
source
code
is
the
basis
of
this
metric.
So
everything
about
this
description
so
yeah.
D
B
D
I'm
saying
I'm
saying
that,
like
I
wasn't
I'm
trying
to
figure
out
what
this
metric
is
supposed
to
measure
and
those
that
sentence
is
inconsistent
with
the
rest
of
it,
and
I
think
matt
said
that
it
is
indeed
the
time
between
reviews
of
an
individual
pull
request,
merge,
request
and.
C
B
B
Because
the
way
I
think
of
it
is
I
I
submit
a
pull
request,
it's
got
some,
it's
got
some
code
in
it
right
and
you
look
at
it
and
you're
like
oh
well,
you
know,
if
you
did
this
better,
it
would
be
a
lot
more
efficient
and
matt
comes
back
and
he
says
oh
and
this
in
this
other
bit.
If
you
do
this,
it
would
be.
B
B
B
B
D
D
B
But
my
point
my
point:
is
it's
not
a
single
change
request?
It's
multiple
potential
change
requests,
so
you
requested
a
change.
Matt
requested
a
change
and
the
review
cycle
is
the
period
of
time.
It
takes
me
from
the
individual,
like
the
first
thing
that
I
submitted
and
the
thing
that
I
submitted.
That
has
some
fixes
in
it
that
came
out
as
a
part
of
feedback
as
a
part
of
changes,
but
that
that
review
cycle
could
have
10
change
requests
in
it.
B
B
B
E
B
Simple
projects,
this
doesn't
happen
as
often
right
in
simple
projects.
There
might
be
one
review
cycle
or
maybe
it
just
gets
merged
and
there's
no
real,
like
formal
review
cycle,
because
there
are
no
changes
required.
But
if
you
look
at
like
kubernetes,
if
I
refactor
a
big
chunk
of
code,
that's
gonna
be
a
bunch
of
different
review
cycles
because
I'm
gonna,
I'm
gonna,
get
feedback
from
some
people.
I'm
gonna
resubmit
something.
B
D
C
G
Submitted
or
changed
or
anything
so
this
is
change.
Request
cycle
duration
be
consistent
with
the
language
you're
using.
D
B
No
because
it's
not
it's
not
necessarily
like
we're
getting
caught
up
in
the
difference
between
github
and
git
lab
here,
but
it
doesn't
even
necessarily
have
to
be.
This
could
be
a
review
on
a
mailing
list.
Right,
I
mean
like
this
could
be
like
you
look
at
the
linux
kernel.
This
is
like
patches
getting
submitted
to
the
mailing
list,
so
I
feel.
D
H
Can
I
time
in
here
because
what
I
felt
is
attending
all
the
different
groups.
I
realized
that
okay
for
review
in
all
other
groups,
we
are
using
the
terminology,
change
request,
which
represents
github
gitlab
everywhere,
so
that
any
change
or
even
a
pull
request
is
represented
by
change
request.
B
B
Which-
and
I
guess
in
gitlab
terminology
would
happen
within
a
change
request
and
then
you'd
have
these
multiple
multiple
cycles.
So
I,
let's
use
github
terminology
for
just
a
minute,
because
I
think
that's
easier
for
people
to
understand,
because
I
I
rarely
use
gitlab
so
I
submit
I
submit
a
pull
request.
It's
got
some
code
in
it.
B
Shawn
takes
a
look
at
it
and
is
like
nope
that
bit's
wrong
matt's
like
nope
that
bit's
wrong
and
then
I
fix
it
and
I
submit.
I
add
more
commits
to
this
pull
request
and
what
we're
talking
about
here.
The
review
cycle
duration,
is
the
time
between
that
original,
pull
request.
Where
I
had
original
commits
and
the
time
that
it
takes
me
to
submit
a
second
batch
of
commits
that
fix
the
things
that
people
ask
me
to
fix.
H
D
Yeah,
no,
I
mean
I
could
get
it.
I
just
don't
know
why
we're
calling
it
a
review
cycle
on
how
to
change
your
quest
cycle.
G
B
Because
the
change
request
cycle
would
be
the
duration
that
let's
call
it
a
pull
request,
the
duration,
that
a
pull
request
is
open
right.
So
that's
the
duration
of
the
change
request.
So
if
you
look
at
the
change
request,
that's
the
duration
of
time
that
the
pull
request
is
open.
But
within
that
pull
request
there
may
be
multiple
review
cycles.
G
D
Yeah
I
mean
review,
I
just
I
want.
I
mean
my
only
I
think
I
was
confused
about
what
this
metric
was,
because
it
seemed
disconnected
from
change,
requests
or
pull
requests,
but
it's
also
entirely
about
change,
requests
or
pull
requests
so
simply
calling
it
review
cycle
duration
made
it
unclear
to
me
what
we
were
talking
about.
D
D
That
makes
it
more
clear
to
me
that,
okay,
this
is
something
about
change,
requests
and
the
cycles
that
happen
within
change
requests
and
that
I
understand
like
there
are
multiple
review
cycles.
Yes,
like
the
first
time
I
submitted
full
request
in
august,
it's
unlikely
that
it
will
be
accepted.
I
get
reviews
and
then
I
make
changes
that
usually
goes
on
three
or
four
times.
H
C
D
D
A
I
have
a
quick
question,
so
will
we
measure
the
average
of
this
duration
across
all
pull
requests
for
for
our
repo
for
a
project?
Whatever
will
we
take
the
average
or
how
like
I'm
not
sure
how
we're
going
to
pull
that
information
yeah.
H
So
this
will
be
for
one
particular
review
cycle
and
if
we
look
across
all
the
review
cycles,
we
can
take
the
average
very
easily
like
if
we
have
all
the
review
cycles
duration,
we
can
easily
take
out
the
average
of
that
right
now.
The
focus
is
on
the
duration,
calculating
the
duration
of
one
particular
review
cycle.
B
B
Maybe
peripheral
due
to
the
metric
itself,
and
this
sentence,
I
think,
is
just
unclear.
H
D
E
C
C
B
C
C
E
D
B
I
C
B
B
C
D
D
D
Yeah
the
data
in
the
graphic
or
is
that
are
those
actual
review
cycle
mile
markers,
not
what
they
look
like.
C
D
D
D
That
focusing
on
that
patch
set
like
somewhere
in
the
world
somebody
said
I'm
uploading
a
patch
set
that
those
are
markers
that
indicate
the
iteration
is
completed
as
a
new
one.
B
B
A
D
E
B
B
A
H
D
Yeah
hard
to
have
it's
an
interesting
link.
I
just
have
no.
C
In
the
notes,
we
can
put
an
action
item
that
I'll
get
this
in
as
a
metric
for
a
review.
Yeah
perfect
before
the
next
meeting.
B
B
C
B
So
I'll
just
add
that
I'll
add
that
to
the
agenda.
Okay
for
the
21st:
let's
make
sure
I
don't
have
any
conflicts.
Let
me
see
we
need
anybody
else
to
run
the
meeting
super
not
organized
for
this
today.
No,
I
think
we
should
be
good.
Okay,
yeah
and
I'll.
Add
that
process
for
how
we
identify
the
common
metrics,
because
we
didn't
get
to
that.
We
sort
of
stayed
on
the
on
this
metric,
totally
cool.