►
Description
The Cloud Foundry Dojo Experience — How to Become a Contributor - Cornelius Schumacher, SUSE Linux & Michael Trestman, Pivotal Cloud Foundry
The Dojo is Cloud Foundry's unique way of ramping up new contributors. Participants join existing core teams on site for six to ten weeks, and get introduced to technology, culture, and community by working as part of the team, pair programming all day.
The Dojo experience immerses participants in the extreme programming culture practiced at Pivotal, as well as a wide range of tools and technologies. The Dojo embodies the values of transparency and openness, prevents siloing of project expertise within Pivotal, and ensures that Cloud Foundry development is accessible to the greater community.
This presentation will give a first hand experience report about the Dojo from the perspectives of a new participant joining the BOSH core team and a full-time member of the project, and situate this in the broader context of Cloud Foundry software development.
About Cornelius Schumacher
Cornelius works as engineering manager in the cloud and systems management department at SUSE Linux, which is working on projects such as OpenStack, Docker, and a variety of systems management tools. Cornelius is driving SUSE's technical involvement with Cloud Foundry, in particular the work on the BOSH OpenStack Cloud Provider Interface. He is a long time contributor to many open source projects for more than a decade, such as KDE, openSUSE, the Open Build Service, or Machinery. Cornelius is a regular speaker at Linux and open source events, mostly in Europe, but also in the US or in Brazil.
About Michael Trestman
Michael Trestman is a software engineer on the BOSH core team at Pivotal Cloud Foundry.
A
Okay,
so
welcome.
We
would
talk
about
the
Cloud
Foundry
dojo,
so
this
is
a
unique
program
which
Cloud
Foundry
has
to
introduce
new
contributors,
and
we
will
give
you
a
first-hand
experience
how
how
it
is
to
to
do
the
dojo.
So
I
did
the
dojo
my
code,
this
part
of
the
Bosch
team,
and
so
my
name
is
I'm
here
on
the
left.
You
see
me
I'm,
Connie,
yes,
ramappa,
I'm,
working
for
Suzy,
Linux
and
yeah
I
did
the
dojo
in
the
Bosch
team
this
summer.
B
So
what
is
the
dojo?
It's
not
a
karate
class.
It
is
a
program
to
get
new
contributors
started
on
Cloud
Foundry
projects.
It
is
the
fast
track
to
committer
status
for
people
who
want
to
do
that.
So
the
goal
is
to
immerse
participants
in
the
practices
of
the
cloud
foundry
foundation
and
familiarize
them
with
the
related
technologies
and
practices,
and
it's
about
six
to
ten
weeks
working
in
a
team
on-site
and
one
of
the
pivotal
offices
and
in
most
ways
it's
very
similar
experience
to
being
a
new
hire
at
pivotal.
A
Yeah
and
for
me,
the
journey
got
started.
So
if
we
go
to
the
next
slides,
it's
it's
basically
when
we
decided
to
become
part
of
God
family.
So
we
started
a
project
that
souza
to
work
on
the
OpenStack
CPI
and
usually
at
those
that
we
do
a
lot
of
open
source
and
what
we
usually
would
have
done
is.
We
would
have
just
started
to
write
some
code
contribute,
create
some
pull
request
and
get
involved.
But
then
we
learnt
cloud
phone,
which
is
a
little
bit
different.
A
There's
this
dojo
program,
which
gets
you
started,
which
is
this
fast-track
to
commit
our
status,
so
we
had
to
call
with
a
crowdfunding
foundation.
They
told
us
about
the
program
and
so
on,
and
it
all
starts
with
this
remote
pairing
interview.
So
we
heard
about
that
in
the
keynote
or
in
the
fireside
chat
this
morning
from
Rob
miso.
So
this
is
the
same
process.
What
what
the
pivotal
employees
go
through
when
they
tired
so
you'd
get
this
test.
A
This
remote
pairing
thing
just
one
hour
remotely
by
a
Skype
where
an
interviewer
is
doing
some
remote
pairing
with
you
to
assess.
If
you
actually
have
the
skills,
the
social
and
technical
skills
to
successfully
come
complete
the
dojo
and
successfully
work
on
the
work
on
Cloud
Foundry.
So
that's
how
they
started.
So
we
got
through
that.
A
I
got
approval
there
to
start
with
that
and
then
started
to
organize
the
the
dojo
and,
as
we
wanted
to
contribute
to
the
Bosch
CPI,
the
OpenStack
CPI,
the
natural
place
to
do
the
dojo
was
the
Bosch
team,
the
Bosch
core
team,
so
they
they
were
open
to
accepting
me
as
a
dojo,
and
so
then
I
started
to
organize
that
and
that's
being
in
Germany
is
not
completely
trivial,
because
the
Bosch
team
is
sitting
in
San
Francisco
and
the
pivot
office
there.
So
we
had
to
get
this
disorganized
took
a
little
bit.
A
But
finally,
we
I
had
everything
in
place:
yeah
and
then
the
first
day
came
I
arrived
in
San
Francisco
and
the
instructions
I
had
where
come
to
the
office
at
8:45
join
us
for
breakfast
there
and
make
sure
you
are
there
at
9:04
for
the
global
stand
up
so
that
we're
mostly
all
the
instructions
I
got
so
I
went
there.
I
I
attended
the
breakfast
and
I
attended
the
globe.
It's
staying
there
stand-up
and
then
at
something
like
nine.
B
For
us
on
the
team,
it's
just
another
day,
a
new
teammate
is
always
exciting,
but
the
fact
that
he's
the
dojo
doesn't
really
matter.
You
know
just
welcome
to
the
team
and
let's
get
started,
doing
work
and
so
yeah,
one
of
the
kind
of
unique
things
about
pivotal
and
the
and
cliff
entry
and
and
being
in
the
dojo
for
most
people
will
be
pairing
we
pair
all
day
and
every
day,
and
this
is
what
it
looks
like
so
pair
programming
is
probably
our
most
important
core
practice.
B
Essentially,
what
it
means
is
that
every
bit
of
work
you
do
you
do
together
with
your
pair
two
heads
instead
of
one
and
so
usually
the
way
it
works
is
that
pairs
will
stick
together
for
one
or
two,
sometimes
a
little
bit
longer,
and
then
one
person
will
keep
the
context
with
a
new
pair,
while
the
other
one
rolls
off
to
another
pair
and
another
story.
So
what
is
pairing
all
about?
B
Ideally,
what
it
means
is
consensus
on
every
decision
that
you
make
in
the
entire
engineering
process
everything
you
do,
and
so
we
think
that
this
yields
two
main
benefits.
The
first
is
good
decision-making,
two
has
better
than
one,
and
so
hopefully
this
yields
very
high
code
quality
things
like
rigor
and
testing
smart
risk
management
when
you
make
decisions
about
deployment
and
things
like
that
and
the
other
key
benefit
is
propagation
of
knowledge
throughout
the
team
and
throughout
the
broader
organization,
as
people
move
around
as
well.
B
But
for
it
to
work
for
these
benefits
to
happen,
both
people
really
have
to
understand.
What's
going
on
as
you
do
things
so,
this
means
a
lot
of
communication
like
a
lot
of
talking
per
unit
of
typing
right
and
yeah,
so
it
really
puts
a
premium
on
communication
skills,
and
it
does
also
imply
kind
of
what
you
might
think
of
as
slowing
down
to
speed
up.
So
in
the
short
term
it
can
seem.
B
Like
you
know,
all
this
talking
is
taking
a
lot
of
time,
but
we
think
that
very
quickly
it
pays
off
and
is
worth
it,
and
so
this
is
a
picture
of
Cornelius
and
myself
in
the
San
Francisco
know
this
is
Plato
and
Socrates.
So
I
like
to
think
that
pairing
is
in
some
ways
a
lot
like
the
Socratic
method,
which
is
where
you
know
by
asking
questions
in
a
kind
of
open-ended
dialogue.
Two
people
can
come
to
understand
something
that
neither
one
did
at
the
start.
B
So
you
can
actually
produce
knowledge
or
understanding
through
dialogue
and
asking
questions
and
I
think
pair
programming.
Harness
is
something
very
similar
to
this
for
engineering,
where
you're
not
just
trying
to
produce
knowledge
but
actual
concrete
solutions
and
similar,
because
two
engineers
may
have
different
strengths,
different
gaps
in
their
understanding
and
may
come
across
a
problem
that
neither
one
of
them
really
knows
how
to
solve.
B
And
so
the
upshot
of
that
the
good
news
for
dojo
is,
is
that
well,
you
might
feel
overwhelmed
at
first
by
the
unfamiliar
technology
and
unfamiliar
tools,
but
you
can
contribute
just
by
asking
questions
just
by
kind
of
being
there,
and
by
pursuing
your
own
understanding,
you
can
actually,
in
many
cases,
contribute
to
a
concrete
solution
of
a
problem.
Yeah.
A
The
pairing
certainly
is
the
the
biggest
difference
for
most
of
people.
I
mean
there
are
not
many
places
where
pairing
is
done
to
such
an
extreme
degree
as
in
crowdfunding
and
especially
a
pivotal.
So
for
me,
I
never
had
worked
like
that,
so
it
was
really
something
I
had
to
get
involved
in,
but
the
great
thing
was
that
I
actually
was
productive
from
day
one.
A
And
for
me
it
was
a
great
learning
experience
in
this
way,
because
if
you
are
always
together
with
somebody
else
who
knows
different
things,
I
mean
that's
something
which
really
really
helps
and
also
gives,
if
security,
about
what
what
you
are
doing
so
that
that's
really
a
good
part
and
one
other
really
great
part
about
the
pairing,
is
that
you
talk
to
another
person
for
for
the
whole
day.
So
that's
usually
not
what
developers
are
doing
and
many
developers
are
talking
to
their
computer,
maybe
if
they
talked
at
all.
A
But
in
this
case
you
actually
have
to
talk
to
the
other
person.
So
you
you
get
to
know
every
member
of
the
team
in
first
week,
basically
because
you're
switching
pass
every
one
or
two
days,
so
you
really
see
a
lot
of
different
people.
You
see
a
lot
of
different
expertise,
a
lot
of
different
ways
how
to
do
things
and
really
get
to
get
into
that.
So
the
pairing
is
I
think
a
wonderful
way
to
get
into
a
new
project.
A
What
also
was
quite
visible
that
there
are
certain
values
and
pivotal
has
pretty
strong
values
and
that
might
not
be
as
visible
if
you're
coming
from
the
inside.
But
if
you're
coming
from
the
outside,
you
see
that
that
these
are
actually
there
and
I
say
specifically
imperative
values,
because
they
influence
Cloud
Foundry
a
lot
and
the
pairing
is
one
one
of
them.
I
mean
that's,
that's
how
most
people
in
California
work,
but
also
the
other
ones.
A
That's
actually
something
which
surprised
me,
because
I
was
thought:
okay,
they
they
have
this
schedule
and
they
work
like
that.
But
I
would
have
never
expected
that
actually,
five
plus
six
people
are
gone.
So
it's
really.
The
the
office
is
empty
within
five
minutes
and
I
was
really
surprised
by
that.
So
because
that
really
gives
a
way
how
to
sustain
that
every
day
and
again
and
again.
C
B
So
you
everybody
rotates
and
within
a
team,
everybody
works
on
everything,
that's
within
the
scope
of
the
team,
so
for
one
thing,
teams
have
to
be
carefully
scoped,
but
that
itself
is
a
kind
of
an
important,
pivotal
and
foundation
value.
Is
this
idea
of
collective
code
ownership?
So
if
you
are
on
a
team,
you
own
everything,
that's
in
the
scope
of
the
team,
and
so
it's
not
like
one
person
is
an
expert
on
one
part
of
something
within
a
team.
Everybody
rotates.
B
If
you,
if
that
happens,
then
something
has
broken
down
and
in
my
I
mean
sometimes
code
that
you
write
changes
because
it
doesn't
work
or
somebody
finds
a
better
solution
and
that
can
be
frustrating.
But
it's
not
your
code.
It's
the
team's
code,
you're
just
part
of
the
team,
so
I
think
that
attitude
is
kind
of
an
important
value
that
we
have
yep.
B
B
So
our
workday
starts
with
breakfast
and
stand-up
at
just
after
nine
o'clock.
We
are
encouraged
to
take
plenty
of
breaks
whenever
we
need
to
often
this
involves
ping-pong,
but
not
always
we
have
a
one-hour
lunch
and
no
working
is
allowed.
During
lunch
at
the
San
Francisco
office
we
often
have
technical
talks
which
are
optional
and
usually
include
something
to
eat.
So
that's
kind
of
nice
and
as
corny
I
said,
we
stopped
at
6:00,
sharp
and
as
well
there's
a
general
norm
that
you
don't
push
code
towards
the
end
of
the
day.
B
You
tend
to
not
make
the
best
decisions,
then,
so
it's
better
to
sort
of
wait
until
the
morning,
and
so
we
have
a
weekly
cycle
as
well,
which
basically
starts
with
a
planning
meeting
and
ends
with
a
retrospective,
which
is
where
we
kind
of
discuss
how
everything
is
going
and
the
team
what's
been
working.
What's
not?
What
are
the
pain
points?
B
A
This
rhythm
was
was
really
interesting
for
me
because
that's
not
the
way,
I
usually
work,
because
that
also
interrupts
people
working
at
different
times
and
so
on.
So
having
this
schedule
getting
up
in
the
morning
having
breakfast
having
daily
working
for
it,
I
was
going
back
home
and
doing
the
same
every
day.
A
Basically
there
that
gave
me
this
kind
of
zen-like
state
where
we're
just
repeated,
and
it
was
really
I,
had
the
feeling
that,
although
it
was
intense
and
I
learned
a
lot-
and
it
was
where
also
the
tile
tiring,
it
was
something
which
actually
is
sustainable.
So
that
was
an
interesting
experience.
Definitely.
A
A
time
it's
away
and
then
after
the
six-week,
where
did
the
dojo?
Okay,
that's
six
weeks
interesting
part
of
that
alters
the
environment,
so
I
think
we
have
a
photo
on
the
next
slide.
Yes,
so
that's
a
pivot
office,
and
this
was
designed
for
this
style
of
work.
It's
it's
an
open
plan,
so
it's
basically
a
big
open
space
where
everybody
is
sitting
together.
A
A
There
is
some
noise
level
there.
But
if
you
talk
to
another
person,
your
brain
is
trained
to
kind
of
remove
their
the
background
noise
and
focus
on
the
on
the
other
partner.
One
thing,
which
you
also
see
a
little
bit
small
they're
up
there
and
there's
a
monitor
which
shows
some
cio
results,
and
so
that's
that's
something
which
also
is
kind
of
dominating
the
visual
presence,
which
is
part
of
the
extreme
programming
culture
there
that
everything
is
test
driven,
everything
is
covered
by
CI
and
this
CI
is
omnipresent
in
the
office.
B
Talk
a
little
bit
about
our
CI,
so
this
is
an
illustration
of
some
of
our
pipelines,
our
Bosch
pipelines,
and
these
are
series
of
tasks
that
test
our
code
in
various
ways
and
then
promote
the
code
for
use
in
other
pipelines.
So
we
use
concourse,
that's
what
these
visualizations
are
here.
That's
our
wonderful,
open
source,
CI
system
that
was
made
in-house
in
the
San
Francisco
office,
so
CIS
yeah,
as
I,
said
a
very
important
part
of
our
culture.
We're
always
watching
the
board.
B
It
is
the
the
command
center
and
keeping
keeping
the
builds
green-green
is
when
they
pass
is
everybody's
responsibility
when,
if,
if
I'm
bill,
that's
read
if
that
means,
if
the
last
code
that's
been
pushed
to,
it
is
failing
some
tests,
then
you,
you
can't
push
to
it.
So
basically
you're
you're
held
up
until
you
fix
it,
so
the
team
must
coordinate
and
figure
out
what
has
to
happen
to
get
the
build
green
again.
B
Do
you
revert
forward,
tends
to
be
kind
of
a
team
decision,
or
one
pair
is
sort
of
in
charge
of
keeping
the
build.
Green
different
teams
work
a
little
bit
differently.
But
yes,
this
is
the
the
road
map
of
life
as
a
developer
and
the
so
the
the
structure
of
our
pipelines,
I
think
nicely
reflects
the
structure
of
the
system
of
components
that
compose
bosh.
B
B
That
runs
it
through
a
gauntlet
of
tests
that
are
in
isolation
or
sort
of
quasi
isolation
and
then
at
the
end
of
each
pipeline
the
build
that's
passed
through
is
promoted
and
then,
ultimately,
we
have
a
kind
of
master
pipeline
that
we
call
bats
the
Bosch
acceptance
tests
and
that
runs
all
of
these
promoted
builds
together
on
against
real
infrastructure.
Before
finally
publishing
the
the
the
final
release
on
Bosch
IO,
where
it's
available
to
the
community.
A
Yeah
for
dojo,
actually
the
having
the
CI
is
great
because
you
know
when
you
do
a
mistake,
there
is
some
kind
of
safety
net
which
tells
you
that
something
goes
wrong
before
it
goes
out
to
a
release
or
to
a
production
server
or
something
so
concourse
is
a
really
important
tool
and
it's
part
of
the
the
tooling
there's
more
tooling
involved.
Of
course
the
teams
have
settled
more
less
on
a
standard
set
of
tools.
So
it's
all
max.
It's
all
Ruby
mine,
it's
all
shared
as
vagrant
involved.
A
So
it's
a
it's
a
variety
of
tools
but
kind
of
a
standard
set
of
tools,
and
you,
even
if
you
are
not
used
to
this,
you
can
learn
them
very
quickly
while
pairing,
because
you
don't
need
to
read
a
manual
for
looking
up
keyboard
shortcuts,
but
your
partner
will
just
tell
you
you're
slower
type
this
and
you
would
be
faster
and
that's
great
one.
One
problem
is
the
tooling
actually
is
what
what
I
also
realized
is
that
most
tools
are
not
prepared
for
pair
programming.
A
There's,
usually
only
one
author
and
there's
no
way
how
to
get
two
authors
into
something
so
get.
For
example,
it
doesn't
allow
for
more
than
one
author,
so
there
are
a
couple
of
workarounds
in
place
to
be
able
to
do
that.
So
forget,
for
example,
we
use
get
to
add
which
alternates
author
and
committer
with
every
commit
source,
or
both
the
members
of
the
pair,
get
basically
the
same
share
of
commits.
A
B
That's
a
good
question,
so
in
principle,
there's
no
code
review
aside
from
from
pairing,
so
we
rely
obviously
very
heavily
on
a
good
test
coverage
and
good
decision
making
during
pair
programming.
That
varies
a
little
bit
on
Bosch.
For
example,
our
product
owner
Dmitri
is
a
very
deeply
technical,
very
knowledgeable
developer
in
his
own
right,
and
he
tends
to
get
his
hands
dirty
a
little
bit
with
our
code.
Ideally,
ideally,
there's
no
code
review
as
a
separate
as
a
separate
phase.
B
So
yeah
so
next
I'm
going
to
talk
a
little
bit
about
learning
kind
of,
as
as
a
core
value,
that's
built
into
the
way
we
work
it's
built
into
our
process
in
a
few
different
ways,
so
I
think
first
and
most
important
is
pairing
itself.
You
know
working
with
people
with
different
backgrounds
leads
to
a
very
potent
cross-pollination
of
ideas
and
techniques,
like
Cornelius
said
just
kind
of
even
something
like
keyboard
shortcuts,
but
you
know
goes
all
the
way
up
to
architectural
patterns
and
just
ways
of
making
decisions.
B
These
things
just
spread
in
a
kind
of
organic
way
when
you
pair
a
program
that
doesn't
require
a
lot
of
extra
overhead.
So
that's
really
great
about
it
about
a
pair
programming
but
at
pivotal
and
on
these
Cloud
Foundry
projects
we
also,
as
I
mentioned.
We
make
time
for
talks
both
kind
of
technical
talks
where
we
invite
outside
speakers.
But
it's
also
great
because
if
you
work
in
this
office,
you
have
an
opportunity
to
give
talks
very
frequently,
and
so
there's
this
kind
of
like
office
wide
tech
talks,
but
on
Bosch
anyways.
B
We
also
have
kind
of
a
weekly
slot
for
lightning
talks
within
the
team
where
somebody
will
discuss
you
know
an
issue.
They'll
do
a
little
bit
of
research,
something
that's
been.
You
know
bouncing
around
people
have
been
asking
questions
about.
Someone
will
go
the
extra
mile
and
do
some
research
and
then
present
that
to
the
team.
So
that's
always
nice
our
pace
as
well
as
designed
to
leave
time
and
energy
for
outside
learning.
B
A
So
for
me,
the
learning
was
great,
of
course,
through
the
pairing
I
learned,
a
lot
of
other
technology
and
so
on,
but
also
by
being
in
the
dojo
but
being
in
the
office.
I
also
learned
a
lot
about
the
context
in
which
this
happens.
A
lot
of
the
people
think
how
do
they
work?
What
what
happens
outside
of
the
extra
coat
contribution?
A
So
what
you
usually
don't
see
if
you
are
just
communicating
where
I
get
up,
so
that
was
a
great
thing
to
learn
and
what
also
was
quite
important
for
me
and
I
am
kind
of
a
relief
to
me
when
I
realized,
okay
I
for
me,
it
was
clear.
I
would
have
to
learn
a
lot
there,
but
when
I
was
there,
I
realized
that
actually
everybody
was
learning
a
lot
all
the
time,
so
he
always
had
to
learn
about
a
new
story
and
how
to
how
to
tackle
a
new
topic
and
and
everyone.
A
A
So
after
the
dojo
after
the
six
weeks,
I
went
home
and
I'm
now
working
in
the
OpenStack
CPI
team,
I'm
doing
pairing
all
day
and
that's
actually
something
which
surprised
me
a
little
bit
how
natural
this
this
became.
So
when
I
got
home,
actually
my
daughter
came
to
me
with
a
computer
problem
and
that
was
just
fixing.
It
I
realized.
A
Okay,
my
natural
reaction
was
oh:
let's,
let's
sit
down
together
and
fix
that
together,
that
was
kind
of
interesting
to
see
that
it's
really,
it
becomes
a
kind
of
a
second
nature
and
it's
really
a
great
way
how
to
work
together,
yeah
and
from
that
on
yeah
I'm
working
as
part
of
the
the
team
now
and
that's
kind
of
the
natural
progression.
Then
I'm
half
commit
right
now,
I'm
a
contributor
I'm
committee
in
Cloud
Foundry,
and
that
was
just
done
in
six
weeks.
So
that's
great
good,
some
challenges.
A
Doing
the
dojo
I
think
it's
a
great
thing.
It's
a
really
great
way
to
get
started,
but
it's
also
there.
There
are
some
things
which
are
challenging
with
that,
so
the
first
of
the
things
is
that
a
crowdfunding
really
is
a
unique
project.
We
talked
about
the
way
how
people
work
about
the
pairing
and
so
on.
A
That's
that's
pretty
unusual
and
it's
also
a
I
mean
it's
an
open
source
project,
so
everything
is
open,
but
you
can't
start
just
with
contributing
by
pull
request
and
just
you
won't
be
involved
in
the
same
way
as
in
some
other
projects
where
this
is
the
primary
way
of
contributing.
So
this
is
kind
of
a
barrier
and
a
challenge
which
I
think,
especially
when
cloud
form
is
growing.
We
have
probably
have
to
find
ways
out
how
to
make
this
less
of
a
barrier.
A
A
That's
a
good
question:
I
personally,
don't
have
numbers
about
that.
The
people
I
worked
with
and
I
have
met
by
that
I
mean
most
are
actually
prepared
for
that
they
want
to
do
that
and
they
were
really
very
happily
getting
involved
in
that.
That's
why
you're
working
but
I
don't
have
any
statistics
about
that.
So,
but
that's
that's
actually
a
good
and
interesting
question
and
that's
part
of
I
think
my
third
point
there.
Some
of
the
thing
is
not
very
transparent,
so
this
kind
of
data
is
not
publicly
available.
A
How
you
get
in
the
dojo
is
documented
and
so
on.
But
there
are
some
processes
where
it's
not
always
clear.
Is
there
pivotal?
Is
that
the
crowdfunding
foundation
is
that
the
community
and
a
lot
of
things
are
just
happening
by
talking
to
other
people
and
then
then
things
become
very
clear
and,
and
you
understand
them,
but
you
need
to
do
this.
A
You
have
to
really
seriously
want
to
contribute,
but
then
I
think
it's
absolutely
worth
it
and
to
conclude
that
some
tips,
how
to
do
the
dojo,
you
have
to
talk
to
people
who've
done
it
I
think
that
that's
very
important.
So
you
get
the
impression
what
it
is
you
learn
about
how
it
works,
what
you
have
to
do
and
so
on.
So
that's
that's
quite
important
and
you
have
to
be
really
very
open.
A
You
have
to
be
open
that
to
do
a
lot
of
things
which
are
from
what
we
are
used
to,
so
you
have
to
be
open.
You
have
to
get
engaged,
you
have
to
ask
you
have
to
speak
up.
You
have
to
tell
people.
What's
what
you
need?
You
have
to
ask
questions.
You
have
to
ask
all
these
seemingly
stupid
questions
which
actually
are
the
right
questions
to
get
some
thinking
going
and
so
on,
so
that
this
is
absolutely
essential.
I
think
you
have
to
be
humble.
A
That's
part
of
working
with
the
pair
every
day
that
doesn't
work
if
you
are
not
humble
and
you're
insisting
on
your
opinion,
but
you
also
have
to
be
fearless
because
you
in
many
cases
work
on
something
where
you
don't
have
any
idea
at
the
beginning,
how
to
deal
with
that,
but
that's
again
something
where
the
pairing
helps
a
lot,
because
you
have
the
means
to
find
out
what
what
it
takes.
So
it's
an
interesting
combination
with
what
you
need.
A
I
mean
you
really
need
to
be
active,
but
also
humble
in
the
same
way,
and
your
life
as
developer
will
be
different
after
the
dojo.
That's
that's
for
sure,
as
well,
and
I
can
only
recommend
to
brush
up
your
ping
pong,
that's
the
main
activity
to
have
a
small
break
between
coding
and
that's
a
great
thing,
and
you
would
have
fun
with
that.
So
for
me,
the
generator
by
advises
yeah
and
enjoy
the
time
enjoy
doing
the
dojo
and
I
think
it's
really
really
very
beneficial
to
the
project
and
a
great
way
to
introduce
people.
A
Yeah
talk
to
us.
If
you
want
to
know
more,
we
are
here
for
the
conference.
You
see
our
email
addresses
writers
write
us.
We
also
on
slack,
that's
the
usual
platform.
There's
a
channel
dojo,
a
loonie
where
we
try
to
collect
some
of
the
people
who
have
done
the
dojos,
so
we
can
actually
share
knowledge
and
I.
Think
that's
the
end.
B
A
B
A
From
my
experience
it
was
in
the
pivot
office.
They
are
pretty
open
anyway,
there
there
are
people
from
other
companies
as
well.
So,
and
sometimes
you
you
get
told
okay,
this
is
an
internal
meeting,
so
so
you
can't
participate.
All
the
stuff
we
are
working
on
is
open.
The
tracking
is
open.
The
planning's
open,
the
the
code
is
open
source,
so
there's
nothing
to
hide
there.
A
No
secrets
and
I
think
there
is
a
little
bit
of
a
separation
between
teams,
are
working
in
open
source
and
were
working
on
proprietary
parts,
but
in
general
this
is,
of
course
there
is
some
trust
part
of
that.
So
so
you
might
see
some
things
there,
which
are
not
meant
for
you,
but
I
think
that's
that's
part
of
trust
for
collaboration
in
most
situations
anyway.