►
From YouTube: Lessons Learned Under the Big Tent - Thierry Carrez (OpenStack) OpenShift Commons Gathering
Description
Lessons Learned Under the Big Tent
Thierry Carrez (OpenStack)
OpenShift Commons Gathering on Community Development
June 15 2020
https://commons.openshift.org/gatherings/Community_Development_2020.html
A
You
have
been
instrumental
in
lots
of
different
arenas
in
OpenStack
and
in
you
know
and
I'm,
follow
that
a
lot
of
the
OpenStack
stuff
from
the
early
days
and
I'm
really
thrilled
that
you're
here
today
to
share
your
lessons
learned
under
what
I
call
the
big
tent
I
think
you
guys
coined
the
word
or
it
was
coined
about
OpenStack,
so
I'm
gonna.
Let
you
take
it
away
and
talk
for
as
long
as
you
like
and
then
we'll
bring
on
a
panel
as
well.
So
I
really
take
it
away,
we're
on
time
for
a
change.
B
Perfect
well,
thank
you
for
having
me
thanks
thanks
you,
too,
Diana
and
Daniel
for
the
invitation.
It's
always
great,
to
be
able
to
share
our
experience
and
mistakes
and
and
good
things
about
the
OpenStack
experience.
So
my
name
is
East
Jericho,
as
I'm
working
for
the
OpenStack
foundation,
I've
been
working
on
OpenStack
since
the
very
beginning
of
the
project,
and
in
a
month
we'll
be
celebrating
the
10
years
of
the
OpenStack
project.
B
I
think
it's
really
a
great
time
to
reflect
back
on
what
happened
and
July
lessons
from
from
this
adventure
on
our
experience
really
openly
developing
at
a
massive
scale.
So
what
do
I
mean
by
openly
developing
at
a
massive
scale?
Well,
by
openly
developed
I
mean
an
open
source
project
where
anyone
can
participate
on
a
little
playing
field
where
there
is
no
main
sponsor
with
special
rights
or
special
access,
where
everything
is
transparent
and
obviously
today
there
are
few.
B
There
are
a
few
new
projects
that
have
followed
the
same
path,
but
most
notably
kubernetes,
obviously
also
an
openly
develop
project
back
in
2010.
When
a
bird
stack
started,
it
wasn't
that
common
for
new
projects
to
be
set
up
that
way-
and
it's
also
massive
in
in
terms
of
in
ten
years
OpenStack,
has
grown
a
lot
and
have
a
few
numbers
to
try
to
illustrate
that.
B
We
currently
have
760
to
git
repositories
and
those
are
all
official
OpenStack
repositories
under
the
stewardship
of
the
OpenStack
Technical
Committee.
It's
basically
all
all
those
repositories
under
a
single
governance
body.
We
also
have
more
than
eight
thousand
individual
contributors.
You
OpenStack
so
far,
and
here
I
count
only
code
contributors,
the
authors
of
patches
that
have
been
accepted
in
an
open
stack,
not
just
people
that
participated
in
the
community
one
way
or
another
by
by
asking
questions
or
anything
and
in
terms
of
activity.
B
We
had
around
48,000
changes
merged
over
the
past
year
and
those
are
Gerrit
changes
which
are
compatible
to
get
up,
pull
requests
for
those
who
are
more
familiar
with
with
github,
as
in
there
reviewed
by
a
human
and
tested
before
they
are
merged.
So
this
these
are
like
comparable
metrics
and
this
place
is
OpenStack
still
as
one
of
the
most
active
open-source
projects
in
activity
today.
B
Finally,
in
terms
of
deployments,
our
OpenStack
user
survey
reports
about
10
million
CPU
cores
of
computing
power
running
on
OpenStack.
Those
are
pouring
virtual
machines,
containers,
bare
metal
machines
to
edge
and
and
networking
resources,
and
that's
only
what's
been
reported
to
us,
because
we
also
know
a
lot
of
deployments
that
do
not
report
exactly
numbers
to
us.
The
picture
on
the
slide
is:
is
the
Large
Hadron
Collider
at
CERN,
the
European
Center
for
Nuclear
Research,
which
uses
an
openstack
cloud
with
more
than
300,000
CPU
cores
to
power
its
data
processing
capabilities
da
wall?
B
I
would
say
that
those
10
years
has
been
a
wild
ride.
We
mostly
focused
on
handling
that
crazy
growth
and
there
was
really
a
lot
of
yak
shaving
involved,
especially
in
on
the
project
infrastructure
side,
where
we
we
quickly,
we
quickly
hit
the
limits
of
what
we
started
with
in
2010,
so
we
started
with
the
launch
pad
system
from
from
canonical,
but
clearly
at
one
point
we
of
our
group
Bazaar,
which
was
the
coriander,
could
revision
control
system,
and
so
we
switch
to
get
and
then
from
launch
pad.
B
We
switch
to
Jenkins
for
running
off
tests
to
Zul
CI
for
for
handling
in
the
load
that
we
ended
up
wanting.
So
there
was
we
need
a
lot
of
yak
shading
involved
and,
at
the
same
time
now
it's
really
calmer
and
we
don't
grow
as
fast
anymore.
Openstack
components
are
more
stable.
It's
really
a
good
time
to
reflect
back
and
extract
some
hard
learn
lessons
from
from
that
experience
and
share
them
the
first.
B
The
first
lesson
is
that
you
should
ignore
the
headers
and
it's
sad
that
it
happens
with
open
source
projects,
but
with
any
reasonably
successful
project.
There
will
always
be
a
group
of
people
that
will
publicly
express
dislike
for
what
you're
doing,
for
what
you're
trying
to
achieve
what
you're
doing
and
and
trying
to
bring
you
down,
and
usually
it's
coming
from
people
that
are
not
really
part
of
the
project
at
the
beginning
and
they
feel
left
out
so
rather
than
trying
to
join
and
participate.
They
prefer
to
do
you
dislike
the
project.
B
Publicly
and
OpenStack
has
been
predicted
dead
for
the
past
nine
years.
It's
been
an
interesting
exercise,
but
we're
still
very
much
around
adoption
is
still
going
like
crazy,
so
my
advice
would
be
to
ignore
the
people
that
say
you're
dead
and
and
pursue
your
goals,
because
time
will
ultimately
prove
you're,
right
and
and
open-source
is
very
resilient.
So
that's
really
follow
your
follow
your
your
own
light
and
don't
listen
too
much
to
people
that
don't
like
you.
The
second
lesson
is
that
hype
goes
up
and
down
hype.
B
Is
this
excitement
around
your
technology
as
people
try
to
wrap
their
heads
around
the
around
the
technology
and
try
to
understand
it?
Do
it
that
really
generates
a
lot
of
participation?
A
lot
of
press
articles,
massive
conference
attendance
and
it's
generally
fueled
by
curiosity,
but
at
one
point
people
start
to
understand
the
technology
and
what
it
can
and
cannot
be
used
for,
and
at
that
point,
hype.
B
Goes
Down-
and
it's
generally
a
painful
moment
because
to
support
all
the
participation
that
this
hype
face
brings
you
tend
to
build
a
lot
of
structure
in
terms
of
even
size,
processes,
project,
infrastructure
and
scaling
that
infrastructure
down
to
more
reasonable
and
sustainable
levels
can
be
difficult,
especially
if
you
are
engaged
in
multiple
years
ahead.
And
another
aspect
to
that
is
that
the
open
source
project
in
itself
is
not
a
business
model
and
company
is
getting
involved
with
the
project,
actually
need
a
real
business
model.
B
So
a
lot
of
companies,
mostly
vendors,
tend
to
join
the
project
early
on,
in
hope
that
it
will
magically
make
them
relevant
in
the
21st
century
without
having
a
clear
business
model
in
mind
and
when
they
fail
to
magically
extract
money
on
the
project
they
readjust
their
investments,
that
jump
to
the
next
thing
or
they
completely
drop
from
the
game.
And
at
that
point,
when
hype
goes
down
and
companies
pull
out
resources,
a
lot
of
people
will
leave
your
community
and
you
have
to
be
strong
and
resilient.
B
What
you
are,
what
you
soon
realize
is
that,
at
the
end
of
the
day,
you
are
actually
ok
as
long
as
you
have
users,
users
is
really
what
you'll
see
making
matters,
because
they
will
be
self-sustaining
at
some
point
and
so
past
that
depression.
If
you
stick
to
the
project,
you
realize
that
boring
is
good
turns
out
once
you
remove
all
the
hype
infrastructure,
software
is
kind
of
boring
and
hype
can
be
very
toxic.
B
Read
our
every
word
on
mailing
list
posts
and
try
to
extract
drama
that
wasn't
really
there
and
that
that
was
a
lot
that
was
very
stressful
and
now
we're
in
a
much
center
environment
with
a
lot
less
external
pressure,
and
we
also
got
rid
of
poisonous
people
that
that
got
attracted
by
hype
and
glow.
At
some
point,
so
I
would
say
we're
in
a
better
position
now
in
terms
of
community
health
than
we
were,
maybe
four
or
five
years
ago.
B
I've
seen
it
happen
with
OpenStack
I'm
now,
seeing
it
happen
with
kubernetes
in
a
way
turns
out
you're,
not
the
last
thing.
There
will
always
be
another
technology
that
will
come
next
and
still
the
height,
and
you
have
to
prepare
for
that
and
when
that
something
else
comes
in
simpleton
to
realize
that
they
don't
replace
you.
Technology
is
really
additive.
B
People
like
to
think
that
one
technology
can
be
used
for
everything
that
it
can
replace
everything
blown
it
and
you
will
never
need
to
learn
anything
else,
sell
it
and
you
will.
They
will
just
solve
all
of
your
customers.
Problems
forever,
but
reality
is
more
complex.
Containers
did
not
replace
virtual
machines,
which
did
not
replace
pyramidal
machines.
Functions
will
not
replace
containers,
unique
kernels
will
not
replace
function.
B
Technology
is
additive
and,
as
we
add,
those
technologies,
integration
becomes
real
Challenge
and
that's
why
it's
so
important
to
engage
beyond
your
community.
That's
what
I'm
trying
to
do
here
by
sharing
our
experience
at
peak
hype.
There
is
a
tendency
to
think
that
everything
should
be
absorbed
and
done
inside
a
single
community
and
ignore
all
the
other
community.
B
Engaging
beyond
gives
you
perspective.
It
avoids
you
getting
stuck
into
an
echo
chamber.
It
allows
you
to
learn
from
history.
You
learn
from
the
mistakes
of
others
or
they're
good
experiences.
It
reduces
the
risk
to
repeat
the
same
mistakes
and
that's
why
I'm
here
today
try
to
share
lessons
from
the
OpenStack
experience.
B
B
You
will
rely
on
the
work
of
a
lot
smaller
number
of
configures.
That's
because
some
roles
are
just
how
to
feel
you.
There
are
multiple
reasons
for
that.
First
organizations
tend
to
do
tactical
contributions.
They
tend
to
invest
in
things
that
benefits
them.
In
particular,
like
adding
a
feature
they
need
or
fixing
a
bug
that
would
only
affect
them,
and
you
need
people
to
do
strategic
contributions,
things
that
will
benefit
everyone
like
handling
release
management
or
fixing
a
complex
bug
that
affects
everyone.
B
The
second
reason
is
that,
at
the
peak
of
the
height
doctrine,
functions
are
really
hard
to
feel
developers
tend
to
be
kings
and
they
have
the
luxury
to
choose,
though
they
generally
pick
things
that
are
less
boring
and
more
creative,
which
really
leaves
a
number
of
holes
to
be
filled.
And
finally,
some
functions
are
just
requiring
significant
expertise.
That
is
different
from
that
of
the
crowd,
like
technical
writing
or
UI
design,
and
sometimes
hard
to
find
the
resources
to
fill
those
or
to
attract
them
in
your
community.
B
The
next
lesson
is
that
over
time,
people
will
join.
One
error
we
made
early
on
was
to
assume
that
our
principles
and
our
culture
would
naturally
transmit
to
newcomers
oral
tradition,
and
that
worked
to
an
extent,
but
at
one
point
it
stopped
working,
and
we
realized
that
we
should
have
documented
our
culture
rather
than
just
assume
that
it
will
naturally
transfer
to
people
that
join.
The
mirror.
Lesson
from
play.
B
B
Another
issue
we
encountered
is
how
we
scale
development
itself
in
OpenStack.
We
split
development
across
project
teams
that
are
dedicated
to
specific
components
and
in
those
that
would
be
call
reviewers,
which
would
be
basically
people
that
approve
the
changes
ultimately.
But
those
people
can't
give
you
everything,
but
they
basically
have
to
trust
each
other
to
review
changes
like
they
would
have
reviewed
them
and
turns
out
that
works
until
the
group,
which
is
a
certain
size
which
is
around
16
people.
You
can't
really
scale
up
trust.
B
You
have
to
scale
it
out
by
further
splitting
code
areas
and
that
can
really
be
difficult
when
people
both
want
to
let
go
of
their
ownership
over
a
specific
area
and
that's
just
one
way:
Conway's
law
will
bat
bite.
You
Conway's
law
states
that
organisations
which
design
systems
are
constrained
to
produce
designs
which
are
copies
of
the
communication
structures
of
those
organizations.
B
Basically
do
your
you,
you
put.
What
you
produce
is
completely
predetermined
by
how
you
organize
things.
Internally
and
in
OpenStack
we
organised
development
around
project
teams
specialized
in
specific
components
which
made
it
hard
to
do
cross
project
horizontal
work
and
it's
harder
to
track
that
kind
of
work.
B
It's
harder
to
do,
and
it's
not
well
recognized,
as
projects
got
more
stable,
it
started
biting
us
because
we
wanted
the
various
components
to
work
better
together,
and
so
we
needed
we
needed
a
lot
of
that
consistency,
work
to
be
done
and
that
that
work
is
much
more
difficult
than
it
should
be.
It's
important
to
be
aware
that
another
way
Conway's
law
will
bite.
B
You
is
that,
due
to
the
way,
the
open-source
project
is
organized
everything
our
community
developed
was
put
in
the
same
bucket
and
called
OpenStack,
and
now
we
realize
that
it's
sending
a
pretty
confusing
message.
People
are
still
asking
us
what
is
up
and
stack
today
and-
and
it
also
made
it
difficult
to
discover
components
that
can
be
used
standalone
without
any
other
OpenStack
components.
So
we've
started
recognizing
that
and
make
it
easier
to
discover
and
reuse
individual
components
within
the
OpenStack
framework.
B
B
B
Open
design
is
a
step
beyond
that.
Design
should
not
be
done
behind
closed
doors
by
a
separate
group
of
privileged
developers.
It
should
be
done
in
the
oven
and
be
inclusive
of
users.
That's
really
critical
and
finally,
the
last
open
is
open
community
any
individual
should
be
able
to
join
the
community
and
become
a
leader
contribution
should
be
your
only
currency.
Nobody
should
have
special
rights
based
on
who
they
happen
to
work.
For
those
four
options
are
the
key
to
a
successful
and
healthy,
open
collaboration.
B
B
Another
hidden
secret
of
open
collaboration
is
that
open
collaboration
will
inevitably
lead
to
scope
creep.
The
reason
is,
it's
really
difficult
to
say
no
in
an
open
collaboration.
Someone
comes
up
with
a
feature
to
support
a
corner
case
and
brings
it
to
the
Commons.
It's
really
difficult
to
reject
it.
So
you
end
up
usually
with
lots
of
options:
lots
of
plugins
lots
of
things
that
are
beyond
your
scope.
B
B
As
engineers
we
like
to
gather
data
and
measure
performance
to
try
to
improve
and
as
humans
who
we
like
to
see
how
we
compare
to
each
other.
So
that's
usually
why
we
derive
stats
and
metrics
to
follow
our
development
efforts
and
we
put
up
websites
which
present
those
metrics
the
the
problem.
Is
it
usually
incentivizes
gaming,
the
stats
and
results
in
the
wrong
behaviors,
the
good
out,
slow
states
that,
when
a
measure
becomes
a
target,
it
ceases
to
be
a
good
measure.
B
So,
basically,
if
you,
if
you
start
publishing
the
metrics
and
people
start
to
compare
each
other
using
those
metrics,
then
the
metrics
go
bad
and
it's
a
difficult
one
to
fix
in
OpenStack.
We
try
to
avoid
it
completely
by
not
providing
such
competitive
metrics
at
all,
but
then
someone
else
built
the
website
that
allowed
people
to
compare
to
each
other
that
that's
really
a
problem
in
resulted
in
in
like
people
submitting
patches
for
for
typos
everywhere
to
try
to
boost
their
standing
and
I.
B
Don't
have
like
a
great
solution
for
that.
The
last
axiom
is
that
face
to
face
time
is
necessary
and
I
know.
We
are
running
a
virtual
event
here
and
as
much
as
I
would
personally
like
us
to
be
truly
globally
distributed.
Some
things
require
spending
some
time
together
in
person
like
building
trust,
building,
shared
understandings
holding
how
problems
agreeing
on
priorities.
B
B
B
Open
source
projects
are
ultimately
social
beasts.
People
are
joining
a
community,
not
necessarily
a
technology,
though
setting
a
number
of
principles
in
stone
from
day.
Zero
will
really
help
set
expectations
and
build
a
common
culture.
You
in
terms
of
project
governance,
I,
have
two
rules
to
follow
that
I.
B
Advise
people
to
follow
is
to
add
governance
structures
only
at
levels
where
final
decisions
on
there
shouldn't
be
any
vanity
government
bodies,
because
that
that's
not
very
helpful
and
it
creates
a
lot
of
churn
in
the
community,
but
you
should
add
enough
structures
to
strongly
aligned
with
your
constituency.
If
you
have
completely
separate
groups,
there
should
be
completely
represented
by
different
governance
bodies.
A
lot
of
projects
just
stopped
with
the
btfl
model.
But
to
me
that's
that's
an
anti
feature.
B
B
You
should
make
sure
that
your
processes
and
tuning
are
not
actively
excluding
in
minority
groups,
because
if,
if
those
those
tuning
is
put
in
place
by
the
majority
group,
obviously
they
can
be
very
excluding
I
said
earlier
that,
as
long
as
you
have
users
you're
good,
but
users
don't
appear
from
nowhere.
You
have
to
cultivate
them.
If
you
want
them
to
be
part
of
your
community,
getting
users
engaged
and
actively
participating
in
the
feedback.
Loop
is
essential,
but
it's
important
also
to
not
build
a
developer
versus
user
mentality.
B
One
mistake
we
made
early
on
in
up
and
stack
is
to
have
separate
governance,
representation
for
developers
and
users.
I
feel
like
it
prevented
users
from
being
more
naturally
involved
with
with
the
developers
in
in
and
participating
in
that
feedback
loop.
It
can
be
pretty
difficult
to
unwind,
as
time
goes
on.
B
B
So
I
think
it's
important
to
assume
that
if
you
don't
test
things
there,
they
can
very
well
be
broken
and
adopting
good,
getting
like
we
did
in
in
OpenStack
as
a
lot
of
side
benefits
like
the
development
branch
is
always
usable
and
it
promotes
a
test
centric
culture
that
it's
really
good
I
would
also
strongly
encourage
adopting
time-based
releases
of
your
feature.
Base
releases
I
feel
like
it's.
It's
becoming
pretty
obvious.
B
Now
that
helps
because
in
a
truly
openly
developed
project,
you
will
have
really
have
to
have
time
predicting
what
and
when
features
will
laugh
rather
than
doing
a
bad
job
at
feature
base
releasing
you
should
embrace
the
benefits
of
time
base.
What
is
it,
which
is
to
have
a
predictable
cycle?
Clear
plan?
Don't
downtime
for
your
community
happy
downstream
users,
knowing
where
their
work,
when
their
work
starts
and
evens
that
can
be
well
synchronized,
with
your
development
cycle
embrace
time-based
releases.
B
What
an
end
or
a
bad
job
at
future
base
wages
and
finally,
my
last
advice
would
be
to
automate
everything
you
can
automate.
Missus
plenty
of
benefits
in
automation
will
obviously
save
you
a
lot
of
time
about
a
lot
of
human
hair
and
ensure
repeatable
processes.
But
beyond
that,
automatable
tasks
are
usually
boring
and
so
for
your
community
people
will
prefer
to
work
on
automating
those
tasks
rather
than
do
them
over
and
over
again,
so
an
openstack.
We
ended
up
automating
everything,
even
things
that
don't
really
make
sense.
B
Automating,
like
our
IRC
meeting,
calendar
or
or
though
well.
What
is
process
is
completely
automated,
but
it
pretty
pays
off
in
the
end
in
terms
of
making
sure
that
all
those
those
boring
tasks
are
are
covered
and
that's
it.
That
concludes
stoke.
So
thanks
for
watching
this
and
I
think
we
can
open
the
panel
for
questions
absolutely.
A
Sorry,
thank
you
very
much
for
this
amazing
talk.
I
think
everybody's
been
chatting
amongst
themselves
here
in
the
in
there
and
going
there
are
so
many
things
that
we
all
learned
and
are
still
learning
from
the
OpenStack
foundation
and
the
work
that
you
guys
have
done
and
I
really
can't.
Thank
you
enough
for
making
this
actually
happens
here.
I'm
just
gonna
unmute,
a
bunch
of
people
who
I
think
you
all
recognize
and
know
should
have
everybody
unmuted
rain
and
Amy
Marik
and
Lisa
Marie
and
Daniela.
A
A
A
We
also
have
a
lot
of
us
came
from
the
OpenStack
community
into
the
kubernetes
and
there's
still
a
lot
of
collaboration
and
work
that
goes
on
between,
but
we
we
really
are
grateful
for,
for
you
sharing
this
experience,
you
know
your
experience
and
continuing
to
work
and
collaborate
with
everybody.
So
thank
you
that
said,
I
have
Daniel
Raine
and
Lisa
Marie
and
Amy
here,
I'm
sure
they
all
have
comments
on
this,
but
I'm
going
to
just
right
off
the
bat
Mike.
A
C
D
A
B
B
It
was
the
idea
that
we
should
be
a
very
inclusive
community
and
you
know
who
are
we
to
decide
with
who
is
part
of
our
comedian,
who
is
not
part
of
our
community
to
end
anything
that
the
OpenStack
community
produced,
ended
up
being
called
up
and
stack,
and
obviously
that's
not
a
pretty
poor
product
management,
because
in
the
end
you
end
up
with
something
that
is
called
up
and
stack.
That
has
so
many
facets
and
and
at
one
point
I
mean
I
understand
why
we
ended
up
this
way.
B
And
so
what
happens
in
OpenStack
summits,
for
example,
was
more
gathering
of
operators
of
open
infrastructure
solutions
and,
as
they
were,
discussing
new
projects.
New
pieces
of
software
admit
more.
It
made
really
apparent
that
the
real
gain
for
us
was
to
provide
this
environment,
where
people
can
discuss
up
an
infrastructure
in
general
and
rather
than
just
OpenStack
and
work
on
the
complex
problems
which
are
integration
rather
than
and
operations
rather
than
just
discuss
like
development
of
OpenStack.
That's
where
the
the
flip
switched
in
my
head,
like
we
are
not
about
producing
up
and
stack.
B
We
are
about
helping
people
operate,
open
infrastructure,
and
so
we
can
do
that
by
helping
obviously
producing
OpenStack,
but
also
producing
other
pieces
of
software,
discussing
integration
with
other
communities
and
not
just
the
pieces
of
software
that
we
produce
and
that's
where
the
the
extension
came,
we're
a
community
of
humans
solving
a
problem
space.
Not
just
could
you
sing
a
certain
piece
of
software
or
a
certain
brand.
D
And
if
I
can
jump
in
here
for
a
second
from
a
community
standpoint,
we
I
remember
when
this
discussion
was
starting
to
happen
and
I
feel
like
as
community
managers.
We
really
pushed
the
envelope
on
that
one,
because
the
conversation
sometimes
starts
in
the
community
before
it
actually
gets
to
the
foundations
right,
and
it
should
be
that
way
and
but
I
really
have
to
applaud.
You
upset
foundation
for
listening,
because
we
had
we
changed
name
of
our
community.
D
We
used
to
be
just
openstack,
we
changed
it
to
open
infrastructure,
and
then
it
became
negative,
open
infrastructure
and
it's
you
know,
and
we
started
doing
that
I
think
years
before
the
actual
summit
changed
its
name,
because
that's
the
conversation
that
the
community
wanted
to
have
and
we
you
know
we
still
did
open
Sextus.
We
were
on
the
first
ever
dual
Meetup
and
we
were
on
the
first-ever
cotta
containers
Meetup,
and
we
still
really
tried
to
push
the
technology
when
it
was
required.
But
it
became
more
talking
about
solutions.
D
The
community
was
was
users
was
contributors
was
ops
was
architects.
It
was
a
whole
bunch
of
different
people
who
were
coming
and
they
wanted
to
talk
about
complete
solutions
and
and
really
solving
a
lot
of
business
problems.
So
we
had
already
done
that
and
by
we
I
mean
the
San
Francisco
Bay
Area
chapter
and
I
really
have
to
applaud
the
the
foundation
for
taking
the
feedback
and
and
for
listening
and
for
then
changing
the
name
of
the
summit.
To
really
help
us.
You
know
kind
of
mirror
the
community.
B
Yeah
I
totally
agree
that
it's
based
on
the
feedback
of
the
community
that
we
ended
up,
seeing
that
as
at
least
from
the
development
side
of
the
community.
Clearly,
that's
the
around
the
time
where
we
were
in
that
echo
chamber
that
I
described
in
the
talk
where
you
don't
you
only
hear
about
up
and
stack
everything
your
world
is
all
up
and
stack,
and
you
you
you're
blind
to
what
happens
elsewhere
and,
and
so
it
was
really
useful.
B
The
community
really
helped
bringing
that
external
perspective,
especially
operators
in
general
like
having
to
operate
those
stacks
of
software.
They
didn't
care
about
like
who
produces
it.
You
know
what
they
want
is
the
resulting
stack
to
work,
and
so,
rather
than
discuss
only
one
piece
of
technology
in
in
a
vacuum.
It's
much
more
useful
to
discuss
integration
of
the
value
species
and
solving
real
problems,
rather
than
be
a
bit
territorial
about
what
you.
What
you
end
up,
accepting
to
discuss
and
horner.
E
We
put
on
twice
yearly
events
and
they're
mainly
focused
around
OpenStack
and
opera,
but
they're,
exciting,
set
and
they're
opening
it
up
to
other
things
in
order
to
meet
the
needs
of
the
operators
and
again
that
complete
solution.
So,
okay,
we
need
a
bigger,
more
robust
orange
that
fills
the
need
and
a
lot
of
people
are
using
it.
So
why
not
included
in
no
I.
C
C
B
That
that's
definitely
something
that's
being
discussed.
I
would
say
that,
in
order
to
justify
that,
we
would
need
to
I
would
say
we
we
don't
have
enough
technology
on
new
technology
or
new
members
to
actually
justify
that
at
the
moment,
OpenStack
is
still
like
the
the
main,
the
main
product,
but
if
we
ask
people
like,
like
you,
said,
I
understand
what
you're
trying
to
achieve
when
we.
B
When
we
talk
about
up
and
infrastructure,
there
will
be
more
potential
for
other
organizations
to
join
with
other
pieces
of
technology
that
are
not
connected
to
up
and
stuck
in
particular,
but
are
still
used
to
provide
infrastructure
using
open
source
solutions
and
at
that
point
I
think
it
would.
It
would
make
more
sense,
but
I
want
to
rename
just
for
the
sake
of
renaming
I,
think
it's
good
that
we
renamed
the
summit's
I
think
it's
good
that
we
rename
the
events,
but
I
would
say
for
winning
the
foundation.
We
would
I
think
it's
important
to.
B
D
B
E
You
look
at
the
ptg,
it
was
going
to
be
the
open,
dev
plus
PT
g.
Now
that's
been
separated
into
two
different
events,
but
the
open
death
part
is
kale
and
edge,
and
so
many
different
topics
than
what
would
be
covered
during
the
PT
G,
which
was
very
focused
at
specific,
so
inviting
other
groups
to
come
and
talk
he's
definitely
been
where
the
OSF
is
going.
B
That
we've
been
trying
to
invite
as
many
like
adjacent
communities
to
to
our
events,
especially
the
the
project
team
gathering,
because
it
allows
developers
to
like
they
have
their
own
meeting,
but
they
can
mingle
with
with
developers
from
the
other
communities
and
that
kind
of
post
samosas
between
the
between
the
groups
is
pretty
interesting.
It's
it's
difficult
to
do
without,
like
being
accused
of
you,
know,
stealing
other
communities.
B
But
if
you
like
that,
rappers
don't
care,
I
mean
Ryan
has
been
to
a
number
of
PT
G's
and
we've
seen
that
we've
seen
self
we've
seen
other
like
Eric
containers,
but
also
things
tend
fabric
and
other
groups
joining,
because
there
was
significant
overlap
in
there
in
the
urge
interest
and
and
just
having
them
there.
Having
them
around
was
really
useful
to
to
bridge
bridge
the
gap
between
the
between
the
between
the
communities
and
discuss
potential
integration
points
and
in
the
end,
the
software
works
better.
D
Mentioned
earlier
in
their
in
your
presentation,
where
you
were
talking
to
that,
that
kind
of
you
shouldn
is
your
and
that
everybody,
you
know
as
part
of
the
community,
if
you
know
you're
contributing
so
I,
want
to
point
out
that
Amy
I
spent
a
lot
of
time.
Talking
about
this,
when
you
say
contributing
you're,
not
just
talking
about
writing
code,
there
are
lots
of
ways
to
contribute
to
a
community
and
people
sometimes
forget
that
and
there's
so
many
there's.
D
So
many
important
roles
to
play
and
a
lot
of
people
get
really
intimidated
about
joining
and
staying
in
communities.
If
they're,
not
actually,
programmers
working
on
a
project
I
mean
doc
was
pointed
it
out
earlier.
You
know
the
community
will
let
you
know
where
the
gaps
in
your
project
are
doc
is
often
a
gap,
but
there's
so
many
other.
D
What
was
the
name
of
the
group
Amy,
the
Aug,
the
or
the
ATTC,
but
I
can't
remember
the
acronym,
but
but
in
OpenStack
we
went
and
did
create
a
user
community,
a
group
of
active
contributors
that
aren't
actually
boudic
and
Lathon
code
contributor.
There's
bias
in
that
statement
right
there
and
we
had
to
call
it
something
else,
and
so
the
active
user
community
goes
well
beyond
people
who
are
just
developers.
So
I
want
to
make
that
point
so
that
everybody
understands
they
have
a
world
playing
community
an
important
one.
A
A
B
It's
actually
a
dark
side
of
get-ups.
Is
that
once
you
turn
everything
into
git
repository,
then
everything
is
measured
against
changes
that
you
produce
and
if
you
don't,
if
your
work
does
not
translate
into
a
change,
then
then
you
don't
exist
and
and
that's
that's,
really
the
dark
side
of
automating.
Everything
like
we
did
in
OpenStack
or
driving
everything
forget
and
any
others
is
that
if
you
don't
get
out
of
your
way
to
also
count
all
those
other
distribution
x'
that
are
really
key
to
having
a
food
perspective
on
what's
happening.
B
It's
difficult,
and
you
mentioned
the
AU
secret
area,
which
is
basically
having
a
number
of
rules
to
recognize
automatically
recognize
contributors
that
have
participated
in
in
those
non
measurable
ways
like.
So.
If
you
motivate
a
session
at
the
knops
meetup,
you
should
you
shouldn't
even
have
to
ask.
Ask
for
to
be
added
to
the
group
should
be
given
to
you,
because
we
all
know
that
the
humans
have
to
ask
all
things.
They
just
don't
necessarily
do
it
so
having
a
way
to
list
all
those
forms
of
contributions
that
that
should
automatically
be
recognized.
B
Even
if
you
don't
have
a
script
that
will
automatically
compute
the
list,
for
you
is
I,
think
a
good
step
that
we
we
put
in
place
in
that
in
OpenStack.
It's
really
easy
for
a
developer,
centric
community
to
just
like
ignore
that
and
I'm
talking
from
the
I'm
I'm
an
offender
of
that
in
the
early
years
of
just
in
the
light.
A
So
they
have
the
get
centric
stuff,
but
none
of
the
data
scientists
or
the
data
people
who
are
looking
at
they're
all
clinicians
and
data
scientists
and
we're
trying
to
force
fits
feed
them,
get
lab
and
get
processes.
And
it's
you
know
and
we're
going
to
do
it.
You
know
we're
not
stopping.
We
are
going
to
use
it,
so
this
is
just
the
nature
of
the
beast
that
we
live
in.
A
E
It's
like
an
open
stack
and
we
offered
it
to
other
parts
of
the
community.
Thunder
OS
his
first
contact
thing.
You
know,
group
of
people
who
are
gonna
help
you
get
start
in
the
community
OpenStack
upstream
Institute.
You
know,
live
hand-holding
and
help
for
two
days
right
before
summit
or
as
some
of
the
OpenStack
days
or
now
infrastructure
days,
so
the
community
providing
people
who
are
going
to
help.
E
You
is
so
important
because
for
someone
who
doesn't
know
your
processes
like
we
use
Garrett
I
love
Garrett
over
PRS,
but
most
people
don't
know
Garrett
or
how
to
install
it
or
anything
else.
So
having
people
there
who
are
willing
to
take
their
time
to
help
you
contribute
your
first
patch
is
awesome
and
more
and
more
groups
are
doing.
D
Amy
I
have
to
give
a
shout
out
any:
is
that
a
phenomenal
job
building
a
mentoring
program?
This
is
another
valuable
part
of
a
community,
the
the
mentoring
program
in
in
OpenStack
and
and
beyond
that
she's
worked
on
for
years,
and
you
know
these
are
thankful,
assad's
and
the
steel.
He
was
saying
you
don't
always
get
the
credit,
though,
as
community
organizers
out
there,
it's
important
to
really
think
about
these
things
and
then
to
figure
out
how
you
can
recognize
those
members
of
the
community.
A
Another
thing,
I
would
say
quite
often
the
community
developers
managers
and
the
people
organizing
all
these
things
aren't
recognized
unless
they're
doing
some
sort
of
you
know
documentation
or
something
like
that.
So
it's
like
you
might
go
and
work
on
a
project
like
OpenStack
or
one
of
the
many
other
ones
and
never
make
an
engineering
contribution.
So
you
never
do
that.
So
it's
also
interview
I
I,
have
some
qualms
about
the
the
gamifying,
the
badge
the
badging.
A
C
I've
done
for
Fedora
is
around
advocacy,
work
and
diversity,
work
that
doesn't
have
a
chorus,
pin
corresponding
badge
or
gamification
or
award,
and
it's
not
that
I
wouldn't
have
done
that
stuff.
It's
just
that.
It's
it's
very
difficult
to
recognize.
Advocacy
specifically
I
think
that's
something
we
should
change.
Let's.
Let's
do
something
around
that
right.
There
even.
E
In
the
o
UI
sessions,
people
have
gotten
their
companies
to
send
them
places
early
and
they
just
sit
in
the
room.
What
we
started
saying,
whoever
answers
this
question:
it's
a
Tim,
Tam
people
started
answering
questions,
here's
a
sticker,
you
know
some
gamification
can
get
participation
and
in
those
instances
it's
really
good.
But
when
it's
for
a
company
or
someone
to
just
say,
we've
got
the
most
commits.
We've
got
the
most
that
then
it's
got
a
realistic
application
of
a
game,
because
your
gaming
numbers
to
your
benefit,
not
gaming,
to
help
the
community.
A
I,
don't
think
I'm,
not
so
much
worried
about
I
mean
we've
all
seen:
people,
gaming
systems,
unstack,
analytics
and
other.
You
know
everything
and
I'm
the
first
to
say
that
I
love,
metrics,
I,
love,
dashboards,
I
love
the
insights
they
give
me
into
what's
going
on
in
the
community
and
who's
doing
what,
but
that
they're,
not
the
full
picture
and
I
think
my
point
is
more
about
that.
A
So
when
we
you
know
go
to
whatever
we
don't
have
that
you
know
the
badge
of
honor
or
something
like
that,
so
I'm
I'm
not
so
much
worried
about
people
gaming.
The
system,
people
know
that
happens.
All
right
people
are
have
been
in
enough.
These
things
so
I
think.
That's!
That's
one
of
the
things
that
I
am
I'm
always
cognizant
of.
Is
that
all
of
the
other
participants
in
the
community?
How
did
they
get?
How
do
we
recognize
them?
A
And
you
know
we
able
to
you
know
let
people
flag
themselves
as
end
users
using
a
production,
giving
them
the
podium
sharing
that,
but
it's
really
I
think
one
of
the
more
difficult
tasks
in
community
building
is
making
everybody
feel
like
that.
Their
contribution
counts
and
get
that
you
know,
especially
because
of
everybody,
not
everybody,
but
a
lot
of
people
work
for
companies
that
value
the
contribution
label,
though
I
think
that's
something.
That's
we
still.
We
still
haven't
quite
figured
out
yet.
E
Who
recognize
people
and
like
I'm
Faisal
actually
didn't
have
a
script
that
would
go
through
on
the
AEC's
to
some
degree,
but
then
it
was
also
reaching
out
and
every
time
it
was
reached
out
to
me
from
either
the
women
hoping
sac
and
will
later
the
diversity
agent
working
group
I
was
provided
names
of
people
who
being
showed
up
and
did
something
not
just
that
full
of
women
meeting.
You
know
you
came
and
helped
out
at
something
you
deserve
a
you
see.
You
know
you
helped
run
the
mentoring
program.
You
got
a
you
see,
though.
E
It's
got
to
be
a
two-way
street,
where
the
community
is
asking
the
people
who
know
and
the
working
groups
and
the
SIG's
who
may
not
be
showing
up
even
the
technical
contributors.
There's
an
extra
ATC
status,
Terry
you'll
know
the
correct
name
for
it,
but,
like
before
dogs
was
considered
a
technical
contribution.
This
was
a
way
of
the
doc
contributors
getting
recognized,
so
there
are
ways
of
doing
it,
but
the
communities
also
have
to
be
open
to
it
and
be
able
to
supply
the
information
and.
D
It's
not
about
being
recognized
because
one
of
the
things
that
the
the
OpenStack
foundation
did-
and
we
know
we
brought
this
all
the
way
up
to
the
board,
but
they
listened
it
was
they
they
started,
giving
this
passes
to
the
conferences
and
scholarships.
If,
because
the
problem
is
a
lot
of
times,
if
you're
managing
a
community-
or
you
know,
you're
doing
that
on
your
nights
and
weekends,
somebody
has
tomato
how
to
fly
it
about
that.
A
lot
of
us
are
not
doing
like
when
I
was
working
at
HP,
I
was
never
paid
to
run.
D
D
We
did
a
Sunday,
she
listened
and
they
started
giving
this
passes
to
the
conference
and
and
in
some
cases,
because
I
was
never
getting
paid
to
be
sent
there.
They
were,
you
know,
doing
some
airfare
and
things
like
that
and
I
really
thank
them
for
that,
and
we
did
get
our
little
a
you
see
on
the
badge
our
little
sticker
and
it
really
meant
a
lot
to
be
walking
around
the
conference.
D
B
Think
the
keys
to
is
to
judge
engagement,
whether
than
you
know
the
end
results
like.
If
someone
engages
and
and
participates
in
the
community,
they
should
be
considered
a
contributor
and
also
apply
very
liberally.
The
like
the
rule,
not
not
try
to
restrict
it
to
you
to
an
elite
group,
because
otherwise
that
that's
that
way
lies
madness
and
so
like
we
use
the
use,
the
expertise
each
you
to
for
all
the
translators
for
support.
B
B
A
I
know
the
Daniel
and
I
who
have
been
doing
some
work
on
he'd
mentioned
it
earlier
today.
It's
it's
one
thing
to
collect
the
metrics,
but
if
you
don't
have
a
domain
expert
or
someone
who
knows
the
community,
you
apply
the
metadata
or
to
the
understanding
of
what
they're
doing
in
the
community.
It's
it's
a
two-part
measuring
and
collection
of
data
and
information.
So
that's
always
pretty
significant.
Well,
we
are
a
little
over
our
time
and
our
next
guest
speaker
has
has
come
and
so
I
really
sorry
again.
A
I'm
gonna
keep
saying
this
all
of
you
who
are
on
this
call
Amy
I'm,
so
glad
you're
you're
with
us
at
Red
Hat,
because
I
am
so
going
to
take
you
on
as
Commons
person
to
help
us
build
out
a
lot
of
our
end
user
and
other
parts
of
our
community.
So
it's
wonderful
to
have
you
here:
rain
I,
you
just
departed
Red
Hat!
So
good
luck
at
packet!
Thank
you!
So
much
and
Lisa
Marie
I
can't
tell
you
how
much
I
respect
the
work
that
you've
done
in
the
OpenStack
community.
A
So,
thank
you
again
for
all
of
that
and
I'm
definitely
going
to
have
all
of
you
back
on
for
other
variations
on
this
theme.
Soon,
though,
thanks
thanks
again
for
your
work
and
your
efforts
and
and
Terry
I'm
gonna
figure
out
your
lighting
situation,
because
you
look
the
healthiest
of
all
of
that
color
lighting.
D
Thank
you
for
everything
you
do.
It's
not
easy.
What
you've
done.
You
have
created
an
incredible
community
with
OpenShift
gathering
and
the
conferences
that
you
put
on
and
it's
I've
been
honored
to
participate
and
I
think
five
or
six
of
them.
They
are
really
amazing.
So
thank
you
for
all
the
work
you
do
we'll.