►
From YouTube: CHAOSS.Common.April.18.2019
Description
CHAOSS.Common.April.18.2019
A
To
add
anything
to
the
agenda,
we'll
go
through
the
previous
action
items,
we'll
talk
about
whether
or
not
we
should
create
a
separate
repo
for
the
common
working
group
and
talk
about
focus
areas
for
for
the
upcoming
release,
so
those
are
kind
of
the
areas
is
there.
Anybody
have
anything
to
add
to
the
agenda.
A
C
C
A
A
A
For
sure,
okay
yeah
we'll
talk
about
that:
okay,
okay,
so
start
down
the
previous
action
items.
Toby
was
gonna
review.
The
expanded
document
I
think
he's
it's
his
European
he's
on
holiday
this
week,
so
I
don't
think.
There's
any
any
update
there.
Sean
was
going
to
create
a
template
in
the
repository
I
I.
Don't
think
I!
A
D
D
He
and
I
basically
had
a
couple
of
meetings
last
week
regarding
this
and
really
what
we're
trying
to
do
and
I
can
post
a
link
for
everybody
to
look
at
hang
on
wait.
What
no
sorry
hold
on
it's
being
weird,
we
can.
What
we're
trying
to
do
is
right
now
we're
trying
to
ascertain
like
the
scope
of
all
the
different
metrics
that
are
in
here
what
can
be
applied
and
what
can't
like.
D
It
looks
like
yes,
so
then,
basically
we're
trying
to
define
the
model
of
what
we're
doing
here
in
all
the
different
ways
that
we
can
kind
of
put
these
metrics
together
and
come
up
with
good
questions
and
what
those
questions
might
be
so
I
think
I,
don't
right,
so
I
think
what
we
are
trying
to
do
now
and
what
I
can't
speak
for
Toby,
but
what
I
need
help
with
is
now.
How
do
we
take
this
and
punch
this
into
a
an
appropriate
template
for
metrics,
because
I'll
be
I'll,
be
honest?
D
A
Yeah
I
mean
I
think
what
we
probably
need
to
do
is
start
with
you
know,
so
we
have
organizational
affiliation
as
a
as
a
focus
area
and
then
what
we
need
to
do
is
put
each
of
the
individual
decide
what
granularity
we
want
to
have
for
the
individual
metrics
and
then
apply
those
to
the
template
that
we're
going
to
get
from
Sean,
okay
and
I.
Think
once
we
have
the
template
and
once
we
figure
out,
you
know
exactly
which,
which
metrics
and
what
granularity
we
want.
A
D
A
I
mean
right
with
the
diversity
inclusion
we
have
like,
like
one
of
the
metrics
is
like
with
an
event.
Diversity
is
speaker
diversity,
so,
but
within
that
speaker,
diversity
metric,
we
have
kind
of
a
dozen
different
ways
to
measure
that
so
are
the
speaker's
diverse
across
across
tracks.
Do
you
have
you
know
dude?
Does
the
audience
feel
like
the
speakers
are
diverse,
and
so
there
are
all
of
these
things.
You
can
measure
around
that.
A
C
A
C
A
C
D
D
And
I
think
Georg
actually
kind
of
helped.
Me
click
with
the
language
just
a
second
ago
when
he
said
quantitative
versus
qualitative.
You
know
so
the
argument
I
think
would
be
made
that
these
lower
level
ones
are
quantitative,
because
they're
very
measurable,
the
higher
levels
might
be
more
qualitative
because
they're
kind
of
making
a
value
call
based
on
other
numbers.
Mm-Hmm.
B
C
C
Encouraging
yeah
so
the
so
you
have
questions
there
so,
for
example,
how
to
handle
change
over
time.
Mm-Hmm
are
those
with
that
question
have
metrics
associated
with
it,
so,
for
example,
with
that
like
wood
footprint
of
an
organization
answer
that
question
I.
Maybe
that's
not
the
right
metric
in
that
question,
but
well.
D
Yeah
so
like
that
one
I
know
captures
and
actually
most
cities
they
they
capture
what
we
were
talking
about
in
our
back
and
forth.
In
our
conversation,
because
one
of
the
things
like
footprint
of
an
organization
I
made
the
point
that
like
if
we
apply
like
the
growth
and
maturity,
the
I'm,
sorry
the
evolution
model.
If
we
apply
the
evolution
model
to
this,
then
sure
when
a
project
starts,
you
know
and
I'll
use
us
as
an
example.
D
Red
Hat
might
have
all
of
it
right
because
we've
just
launched
it
a
year
or
two
down
the
road.
If
we're
still
at
that
spot.
Well,
then,
the
footprint
of
the
organization
metrics
the
the
judging
around
that
changes
over
time
because
now
you're
like
wait.
Why
is
Red
Hat?
Still
the
only
player
in
this
game,
mm-hmm.
C
D
A
Pieces
affiliations,
data
model
is
underlying
all
of
the
low-level
metrics
that
they've
defined
and
the
higher
level
metrics.
That
they've
defined
is
the
ability
to
be
able
to
categorize
people
by
an
organization
at
a
specific
date,
and
so
because
this
is
something
I
spent
a
lot
of
time
on
on
my
PhD
frankly,
and
all
of
these
were
things
that
I
ran
up
against,
where
you
have.
A
You
know:
I
work
for
work
for
the
scale
Factory
in
September
and
now
I
work
for
pivotal
and
being
able
to
classify
my
issues
and
commits,
and
whatever
to
the
scale
Factory
and
then
cut
over
on
the
day
that
I
switched
jobs
has
to
be
tracked
right.
So
it's
this.
How?
How
do
you
track
when
someone
changes
affiliation
and
what?
How
do
you
handle
mergers
and
affiliation?
So,
for
example,
IBM
acquires
red
hats?
A
When
do
you
call
those
people
IBM
or
do
you
or
he
continue
to
call
them
red
hat,
because
they're
managed
as
a
separate
entity,
and
is
that
true
for
for
hep-c
on
VMware,
because
when
VMware
acquired
heftier,
they
rolled
everyone
in
so
you'd
count
them
as
VMware,
but
with
a
Red
Hat
IBM
merger
people
still
call
themselves
Red
Hat
employees,
but
they're
owned
by
IBM.
So
how
do
you?
How
do
you
make
those
decisions
and
then,
like
the
the
pair
programming,
is
an
issue
the
the
contractors?
A
A
D
A
B
C
B
C
D
Talking
about
little
question
metric
approach,
I've
been
sitting
over
the
last
five
minutes,
waiting
to
bring
this
up
the
one
way
we
can
move.
This
word
is
to
actually
leave
this
document
for
a
moment
and
think
about
the
goals
and
questions
that
we
have
around
organizational
affiliation
and
then
once
we
have
the
goals
and
questions
come
back
to
this
document
that
Toby
and
Ryan
put
together
to
see
which
metrics
can
help
us
answer
those
questions,
because
that
process
then
gives
us
the
structure
to
represent
it.
In
the
repository
and.
D
B
D
D
A
B
A
A
D
A
Maybe,
let's
maybe
come
back,
come
back
to
it.
If
we
have
time,
because
I
would
definitely
like
to
do
that
so
I
have
not
identified
the
other
issues
that
should
be
tagged
with
common
metrics
Daniels,
not
here
to
talk
about
responsiveness,
metrics
and
Matt.
You
were
gonna
check
with
the
metrics
list
for
naming
differences
or
add
new
metrics
yeah.
A
C
A
A
Is
the
next
agenda
item
conveniently
enough?
So
so
the
question
has
become
whether
or
not
we,
as
the
common
metrics
working
group,
should
be
working
within
the
metrics
repository
or
whether
we
should
have
our
own
repository.
The
way
that
all
of
the
other
working
groups
do
initially
when
I
was
kind
of
thinking
about
this.
The
common
metrics
working
group
I
was
thinking
about
it
more
from
the
standpoint
of
individual
metrics,
because
when
you
look
at
that
metrics
page,
it's
just
a
big
ole
list
of
stuff
that
nobody
was
doing.
A
The
same
way,
a
lot
of
the
other
working
groups
are
handling
things
and
if
we
create
focus
areas
just
for
the
common
metrics
working
group
within
the
metrics
repository
I
think
that's
going
to
create
confusion
in
the
future,
because
only
some
of
the
focus
areas
are
in
the
metrics
group
and
it's
not
clear
that
those
are
the
ones
from
the
common
metrics
repo.
So
the
more
and
more
I
think
about
this.
A
C
A
C
Agree
and
I
agree
so
I
think
having
a
working
group
having
a
repository,
makes
a
lot
of
sense
and
might
have,
and
and
also
just
from
people
trying
to
get
their
head
around
how
chaos
works.
It's
just
it's
so
simple,
we'll
just
to
say
we
have
kind
of
the
metrics
list
that
captures
everything
it's
just
kind
of
a
laundry
list,
but
then
each
of
the
working
groups
really
does
their
work
or
represents
their
work
inside
of
each
of
their
own
repositories.
C
A
Yeah
and
I
think,
especially
because
we
are
looking
at
it
more
from
a
focus
area
standpoint,
because
we've
really
identified
at
least
three
three
that
I
know
of
and
I've
missed
a
couple
of
the
recent
meetings
but
organizational
affiliations.
Obviously,
one
responsiveness,
metrics
is
another
focus
area
and
then
we've
also
got
kind
of
the
geographic
stuff
as
a
focus
area.
A
Okay,
my
so
my
my
stream-of-consciousness
thought
model
here:
I
want
to
jump
back
to
one
thing
in
the
organizational
affiliation
metrics
that
I
just
realized,
I
forgot
to
mention
Brian,
have
you
talked
to
people
like
Daniel
or
people
at
but
giorgia,
on
about
elephant
factor?
No
okay,
because
they're
actually
doing
a
bunch
of
work
to
measure
that
and
and
I
don't
know
if
they
have
it
implemented
in
their
tools
or
it's
a
separate
tool.
A
Yeah
cuz
I'm
just
thinking
if
I've
already
got
it
because
I
think
they
have
implemented
in
a
tool.
I
just
can't
remember
where
or
what
so,
definitely
getting
back
to
the
conversation
that
Matt
was
talking
about
earlier
about
adding
to
the
agenda
the
the
tools
mm-hmm,
that's
a
definite,
a
definite
tie
in
there.
D
A
A
D
A
A
D
A
D
C
A
A
C
C
C
A
We
have
focus
areas
for
the
upcoming
release.
I
think
we
haven't.
We
haven't
really
done
a
good
job
of
defining
focus
areas,
they've
sort
of
emerged
organically
into
the
the
three
that
we
talked
about
organizational
affiliation,
responsiveness
and
geography,
so
I
think
given
where
we
are
right
now
in
the
working
group.
I
think
that
those
those
three
are
all
pretty
big
and
so
I
would
I
would
tend
to
be
inclined
to
just
focus
on
those
three
areas
for
the
release
and.
C
A
C
A
B
C
A
C
B
A
Start
defining
those
so
rather
than
basing,
because
in
Indy
and
I
we
based
it
on
which
ones
we've
already
done,
and
the
maturity
level
of
those
and
I
think
for
for
this
working
group,
we
can
do
the
same
exercise
with
a
focus
on
which
one
should
we
okay
focus
on.
Okay
might
make
I
mean
to
other
people,
agree
with
that.
That
seemed
reasonable.
It.
C
A
C
A
A
C
A
C
A
A
Ramar
side
and
I
think
you're
right
I
think
we
do
definitely
need
to
keep
that.
Keep
that
in
mind
and
make
sure
that
we're
constantly
talking
to
the
people
who
are
building
the
tools
and
getting
getting
it
kind
of
you
know
like
top-down
bottom-up,
so
like
what
do
we?
What
do
we
think
the
metrics
should
be?
What
are
we
already
doing
and
use
those
to
kind
of
feed
together,
I
think
you're,
absolutely
right,
I
think.
A
C
A
D
So
the
way
that
I
imagined
we
could
do
this
and
I'm
making
this
up
as
we
go.
So
please
do
try
and
if
you
have
other
ideas,
we
can
take
the
document
that
we
have
for
organizational
affiliation
and
at
the
top
define
have
a
list
of
questions.
So
we
just
create
a
new
section
called
question
and
those
become
the
questions
that
we
then
later
tie
the
metrics
to
to
see
how
we
can
answer
those
medical
questions
with
the
metrics
that
defined
currently
in
this
document.
A
D
C
D
D
C
B
B
D
Or
bad
or
I
mean
I
could
easily
see
this
being
gained
to
you
know
we
want
it
all,
not
that
redhead
does
that
so,
but
but
seriously,
yeah,
okay
and
and
the
things
you
can
make
arguments
either
way
about
it.
But
yeah
go
ahead.
Yeah.
A
C
A
How
do
you
define
this,
and
then
the
interpretation
is
up
to
some
up
to
up
to
the
project,
so
dominance
of
a
single
organization
in
a
project
might
be
a
good
thing
in
some
projects.
It
might
be
a
bad
thing
in
other
projects
and
we
try
not
to
make
that
judgment,
call
of
whether
it's
a
good
thing
or
a
bad
thing,
but
we
try
to
help
people
find
ways
to
define
the
thing.
D
D
Organizational
affiliation,
Merson
and
we'll
have
to
rephrase
this
organizational
affiliation
versus
valen
non
organizational
affiliation,
because
that's
something
that's
important
too,
because
this
these
metrics
can
help
identify
drive
by
contributors,
especially
drive
by
volunteer
contributors.
Who
may
or
may
not.
D
Because
if
I've
got,
you
know,
I
guess
somebody
in
Red
Hat
that
came
in
and
you
know,
did
something
really
useful,
but
then
they're
just
and
we
have
this
even
in
our
company.
You
know
people
just
come
in
look
at
something
and
say:
oh
yeah
I
know
how
to
fix
that
and
they
do
it
and
then
they
leave
okay,
you
know
and
and
those
are
actually
harder-
they're
tracting
outside
drive-bys,
because
they're
just
one
more
Red,
Hat
affiliation
and
the
mix.
So
you
know
this
gets
into
yeah
who's.
D
C
B
C
A
Think
about
that
from
a
pivotal,
VMware
standpoint,
so
you
look
at
our
work
in
kubernetes
and
we
have
joint
projects.
So
we
have.
We
have
joint
kubernetes
projects
of
VMware,
we're
both
working
on
them
and
both
contributing
back
into
the
open
source
upstream
project,
and
so
even
though
it's
two
separate
companies
making
commits
some
of
the
some
of
its
related
mmhmm
yeah.
C
C
B
D
Like
a
much
I,
don't
know
if
it
would
be
useful,
but,
like
you
know
over
time,
if
a
given
organization
is
dominant
in
a
large
project,
they're
going
to
tend
to
attract
new
developers
and
I'm
wondering
if
that
would
be
useful
at
all
II
that
migration
move
like
if
everybody
decided
that
Google
was
the
only
place
to
really
work
on
kubernetes.
That's
where
all
the
action
was
and
that's
where
all
the
innovation
was.
A
D
Maybe
the
issue
with
it
that
I
see
is
that
it
spans
multiple
communities
make
out
magnets
as
they
move
between
communities.
Well,
I.
Think
it's
more
useful
in
the
opposite
sense
like
who's
losing
like
who
are
the
anti
magnets,
because
clearly,
then
that
would
be
an
identifier
for
a
community
manager
to
say
wow.
We
are
really
losing
a
lot
of
people
who
used
to
work
for
us
and
now
they're
working
for
so-and-so
or
anybody.
Why
is
that?
What
are
we
doing
wrong?
D
A
A
It's
what
what
Brian
was
just
talking
about,
which
is
so
when
I,
when
I
think
about
which
organizations
are
magnets
and
which
organizations
are
anti
magnets.
What
this
is
really
showing
is
people
leaving
one
organization
and
joining
another,
so
they
can
work
on
the
cool
products,
a
cool
company
within
the
project
as
I
see
working
on
the
right,
I
also
think
of
us,
so
there
there
are
other
other
pieces
of
of
this
that
that
impact
this
the
things
like
I'm,
just
gonna,
write
down
layoffs.
A
Well
well,
I
talked
about
this,
so,
for
example,
Nokia
laid
off
a
whole
bunch
of
their
open-source
developers
when
they
went
all-in
on
Microsoft
and
they
they
laid
off
a
bunch
of
kernel
developers
and
we
actually
sent
a
team
to
fly
to
Finland
on
zero
notice
and
they
flew
in
open
to
Helsinki
office
and
hired
as
many
of
those
people
as
we
possibly
can.
And
so
you
can
see
this
in
the
data.
A
When
you
look
at
Linux
kernel,
job
change
data,
you
can
see
the
the
Nokia
migration
to
Intel
and-
and
there
are
a
few
others
like
that-
there
was
a
big
layoff
at
Texas.
Instruments
I
think
and
a
lot
of
those
people
I
forget
what
company
they
went,
but
you
see
these
like,
like
these
job
change,
migrations
that
happen
as.
A
D
A
D
Yeah
and
I
was
thinking,
I
actually
figured
out
a
way
to
articulate
this
I
would
think
that
an
enterprise
if
there
was
a
pattern
of
intra
project,
organizational
switches,
you
had
a
bunch
of
people
leaving
company
a
and
going
to
Company
B,
but
they
were
still
working
on
the
same
project
and
if
you
then
kind
of
track
that
with
I
did
their
level
of
contributions
go
up.
You
know
when
they
went
to
cut
Company
B,
not
might
tell
us
that
I
mean
it
could
always
be.
D
The
Company
B
is
paying
more
right
and
it's
a
it's
a
purely
fiscal
decision.
But
if
they're,
if
they're,
if
their
contributions
go
up,
then
you
gotta
wonder:
is
there
a
problem
in
the
environment
of
company
a
who
is
also
working
with
your
project
that
isn't
aligning
as
well
with
your
projects,
overall
goals
or
environment
or
whatever
mm-hmm
you
know,
and
then
that
might
give
you
a
little
ammunition.
They
kind
of
gently
go
back
to
company
a
and
say
hey.
D
A
C
A
D
C
B
A
A
D
A
A
All
right,
I,
I,
think
that
this
is
definitely,
though,
so,
I
love
this
exercise.
Thank
you.
Thank
you.
Garrick
I
think
it
still
needs
some
work.
I
suspect
that
if
we
look
down
through
this,
this
big
list
of
stuff
we'll
find
some
some
duplicates
some
gaps,
maybe
some
things
that
we
can
bucket
under
other
things
like
the
job
changes,
so
I
think,
maybe
maybe
in
the
minutes.
Let's
give
ourselves
an
action
item
to
to
maybe
revisit
this
discussion
and
have
another
I.
D
A
A
Okay,
so
I
created
an
AI
for
everybody
to
look
at
the
organizational
affiliation
questions
again
in
another
meeting.
I
need
to
quickly
look
at
my
calendar,
Isis
I
think
actually
that
I.