►
From YouTube: CHAOSS Evolution Working Group 11-18-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).
B
Okay,
all
right
welcome
everybody
to
the
chaos
evolution
working
group
meeting
on
november
18th,
wednesday
november
18th
2020.
everybody's
doing
all
right.
Today.
We've
got
a
couple
things
that
we
can
talk
about
today,
some
stuff
from
last
week,
primarily
working
on
getting
some
new
metrics
released,
specifically
working
on
some
stuff.
I
think.
Last
week
we
worked.
We
worked
on
some
stuff
related
to
branch
lifecycle,
as
well
as
talking
about
some
stuff
about
change,
requests
and
talking
about
some
of
the
language
around
those
I
figured.
B
We
could
just
kind
of
continue,
maybe
working
through
some
of
those
metrics
and
see
where
that
takes
us.
That
sounds
good
with
you
guys.
B
Cool,
let
me
pull
up
the.
B
B
C
D
B
D
D
A
B
So,
okay,
so
it's
not!
It
wasn't
on
the
agenda
that
we
talked
about.
I
know
that
we
discussed
this
specific
change
request,
issue
mapping.
I
actually
think
isn't
this:
this
might
be
the
issue
that
we
talked
about.
Oh
yes,
this
is
so
this
issue
which
I
believe
yeah
king
opened
talks
about
mappings
of
issues
in
prs
to
each
other
and
just
what
that
might
entail,
and
we
talked
a
little
bit
about
it.
We
added
it
as
a
code
development,
efficiency
metric.
B
That's
one
thing
that
we
could
work
on.
That's
one
metric,
there's
also
a
bunch
of
these
that
are
in
considering
some
of
these
are
more
recent
than
others.
I
think
some
of
these
actually
did
get
moved.
But
specifically,
I
believe
branch
life
cycle
is
some
of
the
new
ones
and
then
I
think
some
of
the
change
requests
we'd
also
talked
about.
We
could
just
work
on
one
of
these
metrics
and
see
if
there's
any
that.
B
Did
anybody
have
any
particular
thoughts
on
which
one
we
should
work
on?
You
think
that
workflow
should
just
come.
B
Maybe
it's
because
I'm
sharing
too
oh
google's,
not
liking!
That
sorry
give
me
just
a
second.
F
A
D
D
Were
you
in
that
conversation?
Yes,
I
think
that
daniel
proposed
that,
in
between
cycle
release
like
okay,
one
pull,
request
and
reviews
within
that,
so
that
cycle
of
that
iteration.
I
think
it's
similar
to
that.
A
Yeah,
it's
being
developed,
okay,.
D
B
D
I
think
from
instead
of
iteration,
we
landed
to
the
review
cycles
right.
That's
what
I'm
recalling.
C
D
A
And
yes,
and
the
time
between,
like
how
long
does
it
take
in
between
you
know
each
response,
I
think
so
that
sounds
very
similar
to
what
we're
trying
to
do
with.
I
would.
B
Agree
with
that,
for
some
reason
I
think
the
metric,
the
document
that
it
leads
to
change,
request
generation.
D
A
B
B
B
I
feel
like
this
is
a
case
where
you
could
pretty
easily
argue
that
it
would
belong
in
either
common
or
evolution,
but
I
feel
like
it
might
make
more
sense
in
evolution,
because
it's
specifically
because
it's
talking
about
review
cycles
and
the
time
between
them,
like,
I
guess,
I'm
wondering
how
this
is
like.
Why
did
you
guys
feel
this
belonged
in
common?
A
I
think
so
yeah
I
don't.
I
don't
know
that
there
have
been
a
lot
of
discussions
around
the
shared
use
of
it
across
working
groups
like
I'm,
not
really
sure
how
this
fits
in
with
like
diversity,
inclusion
for
instance,
or
even
risk.
So
maybe
it
does
make
more
sense
in
evolution.
D
A
Do
we
want
to
like
put
a
note,
a
comment
at
the
very
top
and
the
next
comment
either
vanaderai
or.
B
C
A
Yeah
I'll
put
a
note
in
the
next
agenda
for.
B
B
I
mean
I'm
sure
other
people
could
find
this
useful,
but
it
feels
really
kind
of
specific
to
evolution
and
I'm
maybe
there's
just
something
obvious,
a
question
that
question
you
can
answer
for
other
working
groups
with
this.
That
sounds
good.
Thank
you
guys
and
I
this
will
probably,
but
I
mean
this
will
basically
be.
B
B
I
mean
that
would
be
nice
if,
if
you
get,
if
common
decides
to,
let
us
have
it
we've
given
them
our
finished
metrics
before
it
may
be
nice
to
have
some
there's
metrics.
D
D
D
It's
saying
last
meeting
agent
yeah
this
one
yep,
exactly
the
one
you
have
selected
yeah.
I
totally
missed
that.
C
As
well,
let
me
see,
if
did
let
me
pull
up
the
branches.
B
Yeah
it's
on
line
25
of
the
evolution.
B
D
B
Yeah,
let's,
okay,
so
it
must
be
the
spreadsheet
yeah.
It's
the
yeah.
It's
on
line,
25
of
the
evolution
tab,
the
branch
lifecycle
metric.
When
I
click
on
it
it
says
you
do
not
have
access
to
this
file.
Well,
that's
pretty
dumb!
On
my
part,
I
feel
like
we
were
working
on
it
together
during
the
last
meeting.
E
Sean
in
the
chat
yep,
I
found
it.
Let's
see.
G
Share:
okay
change
to
anyone
with
link.
Okay
can
be
editor
copy
link
done
all
right.
Now,
I'm
going
to
go
on
the
spreadsheet
and
imagine
I'm
just
going
to
paste
a
new
link.
Oops.
D
E
D
G
B
We
had
in
the
notes,
is
working
on
for
this
upcoming
release.
Yeah.
G
But
I
use
suggesting
so
you
can
see
what
I.
B
G
G
F
G
D
B
I
think
I
le
I
like
the
second
part
of
the
question,
but
I'm
wondering
if.
B
Because
it's
called
branch
life
cycle-
and
I
think
how
a
repository
use
branches
is
an
interesting
question
that
we
can
answer.
But
for
this
specific
question,
if
we
want
to
talk
about
life
cycle,
maybe
it
would
just
make
it
more
like
or
you
know,
maybe
explicitly
say
how
does?
How
does
the
project
manage
the
life
cycles
of
their
branches
or
something
like
that?
B
D
G
I
almost
need
an
example
metric
to
like
remember
what
a
metric
reads
like
just
kind
of
thinking.
The
same
thing.
G
D
G
G
B
B
G
Change
requests
are
our
change.
Requests
are
our
word
for
pull
requests
or
merge,
requests
on
gitlab,
yeah,
right,
yeah,
so,
okay
and
and
really,
I
think,
what
the
issue's
getting
at
is
the
free.
So
some
repositories
use
a
strategy
of
creating
like
a
patch
branch
and
then
deleting
that
branch
after
a
while
in
augur
we
clean
up
patch
branches
after
some
time.
G
Other
repositories
have
feature
branches
that
are
sustained
over
time
and
there
are
pull
requests
in
both
directions
from
like
a
central,
dev
or
main
repository.
G
So
I
think
it's
that
sort
of
understanding
and
describe
that
data
needed
to
understand
and
describe
that
flow
of
code
from
which
branches
into
which
other
branches
and
which
branches
are
created
and
which
branches
disappear
in
a
time
period,
because
some
some
projects
don't
actually
do
a
lot
of
branch
creation
and
destruction
and
others
do.
B
Yeah
that
that
makes
sense
I
get.
I
guess
I
just
change.
Requests
are
specific
to
a
hosted.
Git
platform
like
github
or
bitbucket
git
doesn't
have
concept
of
change
requests,
it's
only
merges,
so
I
guess
I
I
think
the
all
the
things
you
describe
like
looking
at
those
in
context
of
pull
requests,
branch,
lifecycles
cycles
and
support
requests
is
very
important
and
very
interesting.
I
think
we
should
also
explicitly
call
out
just
like.
B
B
G
Yeah,
I'm
okay
with
that,
I
wonder
if
that's
really,
I
wonder
if
really
the
local
merge
requests
are
actually
under
the
umbrella
of
what
we're
calling
change
requests
more
generally,
I
don't.
B
B
B
I
just
want
to
do
this.
I
need
to
do
this.
It's
kind
of
how
I
view
it
okay,
but
you
know
that
might
be
I'm
sure
there
are
other
ways.
G
I
mean
if
I'm
doing,
inner
source
and
I
don't
want
to
pay
for
enterprise
git,
lab
or
enterprise
github.
I
might
just
be
sharing
a
git
repository
on
a
server
and
having
developers
check
things
in
and
out
on
the
command
line.
I
don't,
I
think
most
people
are
buying
enterprise,
github
and
enterprise
gitlab
for
that
nowadays,
but
I
don't
have
elizabeth
if
you
have
any
more
insights
about
that.
A
I
was
just
going
to
say,
I
think,
I'm
kind
of
conflicted
because
I
totally
get
what
you're
saying
carter
about
is
just
being
one
person,
but
in
the
same
vein
like
I
still
go
through
the
same
process
like
I
still
make
my
changes
to
a
branch
and
then
merge
that
into
master
or
into
maine,
not
like
just
directly.
You
know
what
I
mean
like.
I
still
go
through
the
same
process
as
if
there
was
another
person,
but
that's
just
me.
So
I
don't
know
if
that
counts
or
not,
but.
B
I
don't
know
I
guess
I'm
I'm
talking
more
about
like
when
you
do
emerge
on
git.
You
don't
go
through
like
just
using
git,
there's
no
whole
rigmarole
of
opening
the
pull
request
and
adding
labels
to
it
and
opening
it
for
discussion.
Like
you
just
do
the
merge,
because
I
mean
I
do
the
same
thing:
I'll
merge
between
branches.
So
I'm
just
saying
it's
a
different
context.
B
When
you
don't
it's
not
it's
not
a
public
operation
when
you're
doing
it
out
in
github
or
bitbucket,
or
where
have
you
as
opposed
to
when
you
do
it
out
for
where
anybody
would
be
able
to
see.
I
mean
they'll
be
able
to
see
that
you
did
it
regardless
because
it's
all
version
control,
but
I
think
that
the
gating
aspect
of
the
pr
is
what's
most
interesting
to
me
about
that
distinction.
It's
like
doing
locally
yeah.
You
can
do
whatever.
G
But
so
I
guess
from
the
question
the
point
of
view
of
king's
question,
I
think
elizabeth
is
like
I
would.
I
guess
I
would
still
be
interested
in
that
information
like,
even
if,
even
if
it's
like
I,
I
do
track
that
myself
and
it
is
a
signal
of
the
kind
of
process
that
I'm
following.
Even
if
I'm
one
developer
like,
I
don't
think
it's
a
big
deal
to
include
it
as
opposed
to
exclude
it.
D
D
G
B
D
E
D
D
A
G
Yes,
yeah.
Definitely,
I
think
so
I
think
there's
like
a
those
are
going
to
be.
Like
I
don't
know,
there's
like
new,
I
don't
know
is
the
word
mnemonic
or
syntactic.
They're
sort
of
like
I've
observed
like
some
common
syntaxes,
are
like
dash
dash
patch
right,
but
other
projects
have
their
own
more
idiosyncratic
syntaxes.
C
A
A
A
B
That's
a
good,
that's
a
good
question.
I
had
I'd,
actually
never
thought
about
it
like
that
before.
I
guess,
because
I
just
making
I
I
do
the
same
thing
I
you
know
usually
like
to
make
it
a
little
bit
of
a
more
descriptive
name
than
just
the
the
pr
or
issue
number
rather,
but
I
usually
delete
them
pretty
fast
so
that
nobody
else
will
see
it
and
get
attached
to
it.
That's
actually
a
very
interesting
thought
that
naming
it
kind
of
not
it's.
It's
not
like
naming
a
child
but
kind
of.
A
H
A
G
G
Joke
about
delete,
delete
from
table
or
something
name.
Oh
yeah,.
A
I
just
realized
that
second
reference
that
I
posted
was
actually
written
by
a
friend
of
mine.
I
didn't
even
know
it
so
yay.
B
What
the
is
there
a
way
to
preview
all
of
these.
G
A
Go
up
to
go
where
it
says:
editing,
there's
a
little
triangle
right
next
to
it.
I
think
if
there's
a
viewing
option
yeah
there
you
go.
E
A
G
H
B
B
I
read
it,
I
just
sucked
up
and
it
took
me
like
three
tries,
but
I
got
through
it.
I
mean
I
I
like
your
changes.
I
probably
will
have
some
to
add
myself
as
well,
but
I
think
your
changes
are
good.
G
B
G
I
think
I
just
went
super
nerdy
with
implementation,
so
I
think,
might
be
worried.
I'm
sorry,
it
might
be
and
that'll
get
me
for
that.
Just
fine.
B
G
Oh
okay,
yeah,
you
kind
of
type
in
the
same
thing,
actually
all
right
I'll,
just
paste
what
I
typed
and
you
can
take
it
or
leave
it.
I'm
gonna.
G
A
G
B
Yeah,
I
was
gonna
say
the
first
place
that
I
would
check
to
look
would
be
the
if
they
have
a
contributing.md
file
in
the
root
of
the
repository.
I
would
check
that
and
see
if
they
say
anything
about
how
they
do
branches.
I
mean
that
would
be
pretty
difficult
to
parse,
though,
because
you
would
have
to
like
actually
parse
the
meaning
of
the
mark
down
that
was
written
in
it,
because
I
doubt
that
they
would
be
so.
Nice
is
to
say,
here's
our
branching
style,
branching
style
colon
here
it
is
like.
B
I
know,
auger
for
sure,
doesn't
do
that.
We
have
a
description
of
how
we
like
to
do
branches
and
how
we
do
things,
but
it
certainly
doesn't
use
any
it
takes
several
pages.
It
takes
several
sentences
to
do
so.
I
definitely
think
it
could
be
done,
but
it
would
be
hard
to
implement.
We
don't
have
to
worry
about
that
right
now.
So
I
say.
A
G
Like
just
looking
for
keywords
is
pretty
straightforward,
and
actually
I
was
thinking
like
the
way
I
might
do
it
is.
I
would
I
would
guess
there
are
fairly
standard
versions
of
the
contributing
doc.
There's
language,
that's
common.
I
don't
think
people
like
reinvent
that
every
single
time
they
participate
in
a
new
project,
so
just
a
similarity
score
with
other
repositories,
might
give
you
a
pretty
good
clue
of
what
the
management
style
is.
G
I
put
a
note
about
that
under
implementation,
it
might
belong
where
you're
typing
carter,
I'm
trying
to
think
of
like
like
some
of
the
aggregators.
I
think
that
I've
seen
before
earlier,
metrics
aren't
necessarily
like
where
my
head
is
like
count
is
not
an
aggregator
and
the
example.
I'm
looking
at.
G
I
guess
aggregators
and
parameters
so
aggregators.
B
Is
like
digging
like.
B
Can
you
guys
hear
me
okay,
my
connection
is
better
yeah.
A
G
G
A
G
A
H
H
G
G
H
G
G
And
I
think
I
mean
I
think,
we've
got
a
really
good
start
on
this
metric
and
yeah
we're
near
time.
So
I'm
good
with
calling
it
and
coming
back
to
this
at
the
next
meeting.
G
Because
I've
had
enough
means
to
go
over
this
week
that
I'm
cool
with
one
like
ending
on
time
carter,
we're.