►
Description
Is your open source project “open” as in “available”, or “open” as in “welcoming”? I’m of the opinion that we should always strive to be welcoming in open source. It’s a great way to grow your project, and a great way for people to get opportunities to improve themselves as programmers. Everyone wins! In this talk we’ll explore some techniques for doing this effectively, and better understand how to approach mentorship in open source.
Manish Goregaokar
http://manishearth.github.io/
https://twitter.com/manishearth
https://github.com/Manishearth
https://users.rust-lang.org/users/manishearth/activity
http://2017.rustfest.eu
A
In
the
past,
a
lot
of
the
software
we
use
with
proprietary
folks
had
to
pay
licensing
fees
and
to
get
anything
done,
it
was
just
annoying
and
hard.
Our
industry
had
the
issue
of
a
lack
of
availability
of
software.
It
was
hard
to
get
the
software.
It
was
hard
to
get
the
source
code
and
out
of
this
grew
the
free
and
open
source
software
movement.
These
movements
were
focused
on
making
software
available,
making
it
so
that
you
could
obtain
the
software
or
even
the
source
code
with
little
or
no
restrictions.
A
Well,
there's
always
more
work
to
be
done.
The
lion's
share
of
this
goal
has
been
mostly
achieved.
It's
pretty
easy
to
find
open
source
versions
of
some
software
library.
It's
a
lot
of
the
software
we
use
on
a
day
to
day
basis
is
open,
source
or
heavily
dependent
on
open
source
components
as
open
as
these
projects
are
to
their
code
being
used,
they're,
not
necessarily
as
open
in
the
sense
of
being
welcoming
to
contributions,
sure
they're,
very
happy.
A
If
some
experienced
person
comes
along
and
starts
sending
them
patches,
but
for
an
inexperienced
contributor,
it's
very
non-trivial
to
get
involved.
I
feel
that
this
should
change
I
feel
like
people
wanting
to
participate
should
be
able
to
be
should
be
aided
in
doing
so.
So
I
want
to
show
you
how
your
open-source
project
can
be
more
welcoming
open,
as
in
welcoming
not
just
available
I'd
like
to
take
a
moment
to
say
that
the
rest
community,
all
of
you
and
thousands
of
others
who
are
not
here
right
now,
are
it's
one
of
the
most
welcoming
communities.
A
A
There,
so
why
should
we
bother
like
it's
a
good
question
to
ask
real,
really
I,
really
I,
just
feel
that
it's
the
right
thing
but
I'm
sure
that
not
everyone
agrees
with
me
on
this,
so
I'm
going
to
give
you
some
other
reasons,
one
of
the
most
common
arguments
against
making
projects
more
accessible
is
that
well
serious
contributors
are
they
can
deal
with
all
the
issues
with
getting
started
and
we
don't
care
about
the
rest.
It's
it's
an
argument
that
sort
of
makes
sense.
It
tries
to
be
practical,
but
it's
flawed.
A
Serious
contributors
really
start
out
serious.
They
start
out
curious
and
if
they
encounter
friction,
they
might
just
go
somewhere
else.
This
isn't
even
limited
to
inexperienced
programmers
if
you're
an
experienced
programmer
if
you're
frustrated
with
a
project
that
you're
interested
in
contributing
with
you
may
just
give
up
like
there
are
other
things
you
could
be
doing,
and
while
some
of
the
things
in
this
talk
are
focused
towards
inexperienced
contributors,
that
is
not
true
for
most
of
the
points
and
most
of
what
I'm
going
to
be
talking
about
helps
everyone
contribute.
A
It
usually
doesn't
take
that
much
effort
actually
takes
an
hour
or
so
to
set
up
things
like
basic
documentation
like
contributing
file,
mentoring,
an
issue
takes
between
zero
and
twice
the
amount
of
time.
You
would
need
to
fix
it
yourself,
so
it
usually
works
out
to
be
the
same,
and
ultimately
it
ends
up
being
worth
it.
In
my
experience,
whatever
time
you
put
into
this
it
more
than
recoups
itself,
when
it
ends
up
with
long
term,
contributors
are
becoming
a
part
of
your
project.
A
Servo
is
an
experimental
browser
engine
and
rust
and,
in
my
opinion,
it's
an
extremely
welcoming
open-source
project.
We
do
tons
of
mentoring,
we
have
a
and,
as
a
result,
we
have
a
very
vibrant
community
which
many
of
which
they
started
off
as
complete
novices,
who
may
not
even
have
known
rust,
but
now
we're
making
large
impactful
contributions.
It's
a
very
ambitious
project
and
we
would
not
have
reached
where
we've
reached
so
far
without
the
help
of
all
of
these
contributors.
A
A
We
tagged
the
bugs
is
EEZ
so
yeah
yeah,
and
this
is
also
helped.
The
project
I'm
currently
working
on
stylo,
which
is
for
taking
servo
bits
into
gecko,
there's
an
again
a
whole
lot
of
work
to
be
done
there
and
a
lot
of
it
just
gets
done
because
people
pick
up
bugs.
We
found
they're
like
yeah,
okay,
I'm,
going
to
fix
that
and
it's
it's
nice.
We
have
some
really
good
long-term
contributors
on
stylo
because
of
this
another
example
is
clip.
Clip
is
a
linting
tool
for
rust,
used
by
a
lot
of
folks.
A
For
some
reason,
people
who
use
rust
really
enjoy
being
scolded
by
the
compiler
so
much
that
they
actually
opt
into
more
of
that
I.
Don't
know
it
started
off
as
a
small,
not
very
serious
project.
It
kind
of
started
off
because
I,
like
the
name
I,
really
like
messing
with
the
internals
of
a
compiler,
and
this
was
a
way
for
me
to
like
do
things
without
actually
having
to
make
RFC's,
and
you
know
all
of
that
hard
work.
A
No
one
wants
to
do
that,
and
but
folks
started
using
it,
which
is
a
problem
because
now
folks
want
things
and
feature
requests
piled
up.
I
was
more
than
happy
to
like
start
working
on
those,
but
I
mean
I
had
limited
time,
a
very
enthusiastic
Andre
who's
sitting
right
there.
He
became
a
co
maintainer
when
he
wrote
his
own
collection
of
Lintz
and
we
merged
them
together,
but
still
with
two
people,
the
product.
The
project
was
going
quite
slowly,
like
issues
kept
piling
up.
A
Neither
of
us
had
the
time
to
like
sit
down
and
just
fix
everything,
and
even
if
we
wanted
to,
we
just
didn't
have
the
time
it
was
a
cool
project,
but
it
was.
It
was
small,
and
this
is
a
project
problem
that
so
many
open-source
maintainer
x'
have
they
have
cool
stuff.
They
want
to
work
on
if
projects
that
are
half
finished
and
they
have
limited
time
and
they've
got
well
priorities
as
well.
A
So
one
day
I
decided
to
try
and
make
it
easier
to
contribute
to
Clippy
I've
benefited
a
lot
from
random,
open
source
projects.
Helping
me
learn
so
I
wanted
to
give
back
and
I've
learned
a
bunch
of
techniques
from
awesome
people
on
servo
and
Firefox,
and
other
projects
and
I
want
I'd
applied.
What
I
knew
so
we
had
20
for
lint
at
the
time
a
small
number
I
sat
down.
I
did
a
couple
of
things:
I
wrote
a
contributing
file
and
it
had
some
tips
for
working
on
the
links
and
stuff
like
that.
A
I
urge
people
to
ask
questions
in
the
file.
People
are
usually
afraid
of
asking
questions.
I
also
went
and
tagged
every
issue
on
the
repo
as
easy,
medium
or
hard
and
I
shared
the
file
with
the
community.
This
didn't
take
much
effort.
It
took
like
maybe
in
an
hour
and
a
half
Andre
helped
so
I,
don't
know
how
long
it
took
him
no
yeah.
Nor
did
it
didn't
really
take
much
effort,
mentoring
that
people
arrived.
A
They
like
asked
a
few
questions,
we
answered
them
and
then
they
had
a
full
request,
which
was
mostly
good.
In
one
month
our
quiet
little
repo
had
59
blintz
in
1919
contributors
from
24
to
59
and
one
months.
That's
doubling
people
kept
dropping
by
they
wanted
to
learn.
They
want
to
contribute.
We
had
one
contributor
George
who
made
some
very
high-impact
contributions,
so
we
added
a
musical
maintainer.
We
can
already
see
this
maintainer
load
problems
will
be
fixing
itself
over
time.
We
had
a
steady
stream
of
contributors,
we
added
Martin
and
Oliver
as
maintainer
x'.
A
A
A
Given
a
random
issue
on
your
repo,
it's
unlikely
that
a
newcomer,
experienced
or
otherwise
will
understand.
What's
going
on,
most
issues
require
a
lot
of
unstated
context.
They
use
jargon.
They
refer
to
random
modules
that
nobody
understands,
and
it's
such
that
only
someone
who
already
understands
the
codebase
can
contribute.
A
Now
it's
going
to
be
hard
to
fix
up
all
of
these
with
all
the
context,
it's
usually
easier
to
fix
it
yourself,
but
it's
very
helpful
for
new
contributors
if
they
have
a
way
to
find
issues
that
don't
have
this
problem,
having
an
easy
bug
tag
or
some
page,
that's
easily
discoverable
that
has
list
it
helps
immensely.
These
bugs
will
often
be
bite-sized
tasks,
it's
better
to
tag
more
involved
bugs
as
like,
medium,
less
easy
or
something
like
that
easy
bugs
are
not
hard
to
create.
A
If
you
notice
something
you
want
to
refactor,
that's
often
a
great
easy
bug,
because
all
it
requires
is
basic
understanding
of
the
language.
If,
if
you're,
working
on
something
and
they're
like
little
bits
of
features
on
the
side
that
you
want
to
add
into
this
big
feature,
you're
working
on,
sometimes
you
can
break
those
off
as
alright
I'm
going
to
do
this
later
I'm
going
to
solve
this
as
an
easy
bug
and
just
land
the
main
core
of
your
feature
and
wait
for
other
people
to
come
up
and
fix
the
rest.
A
This
is
basically
extracting
things
as
self-contained
tasks.
It
would
be
easier
to
just
fix
it
now,
while
you're
doing
the
rest
of
it,
but
the
payoff
is
there's
a
chance
of
a
much
bigger
payoff.
If
you
help
someone
else
fix,
it
always
be
on
the
lookout
for
chunks
of
work
like
this,
it's
really
easy
to
find
these
chunks
of
work,
usually
there's
a
bunch
of
things
that
you
we
always
fix
a
big
thing
and
then
it's
like
oh
okay,
I
should
fix
at
6
at
I.
A
Should
that
don't
fix
some
of
those
and
just
file
bugs
don't
make
critical
bugs
into
easy
issues.
I've
made
this
mistake
many
times
I've
seen
this
mistake
being
made.
If
something
needs
to
be
solved
now
or
soon
having
it
locked
in
newcomer
is
like
a
recipe
for
sadness
everywhere.
You
may
end
up
pressurizing
the
contributor
to
get
the
patch
done,
which
is
not
grade,
or
you
might
end
up
doing
it
yourself,
while
they're
working
on
it
and
that's
a
really
really
bad
experience
for
the
contributor.
We
have
a
bad
taste
in
their
mouth.
A
If
there's
something
some
a
similar
bit
of
code
in
the
codebase,
you
can
point
to
that
as
well
and
say
like
just
what
we
did
here
is
similar
to
what
you
want
to
do
here,
give
some
starters
so
that
people
unfamiliar
with
the
codebase
can
basically
dive
right
in.
If
you
have
a
lot
of
similar
tasks,
consolidate
the
common
bits
into
the
into
guides,
so
that
then,
if
someone's
coming
to
your
repo,
then
you
don't
have
to
write
it
each
time
in
a
question
in
the
bug
and
instead
they
can
just
read
the
guide.
A
Always
so
Alyssa's
questions
always
say.
Please
ask
me
any
questions
you
have
while
working
on
this
many
people
make
people
know
that
it's
okay
to
ask
questions,
and
then
they
will
contributions,
don't
need
to
be
limited
to
code.
Pure
documentation.
Fixes
can
be
really
really
valuable
and
you
open
yourself
up
to
contributors,
who
prefer
doing
technical
writing
and
and
do
it
well
like
rusty,
has
a
whole
host
of
contributors,
mainly
focus
on
docs,
and
they
do
a
lot
of
stellar
work.
A
Even
infrastructure
work
like
fixing
CI,
build,
configs,
etc,
can
be
made
into
easy,
bugs
servo
does
this
and
we
get
frequent
contributions.
We
had
one
experienced
contributor
actually
like
revamp
this
whole
AR
of
all
of
our
infrastructure,
which
is
mostly
written
by
people
like
me,
who
do
not
understand
ops
at
all,
and
they
made
it
much
better
and
it
was
great.
A
So
this
can
have
a
large
payoff.
Rust
is
actually
doing
this
right
now,
where
the
rust
C
is
trying
to
make
its
infrastructure
much
more
distributed
in
the
sense
of
how
many
people
are
responsible
for
it
and
how
many
people
can
act
on
it
and
if
you're
interested
talk
to
maybe
talk
to
me
and
I'll
figure
out
who
you
can
talk
to
after
that
document.
A
Everything
these
are
questions
are
going
to
get
asked
anyway,
better
write
them
down
once
this
saves
your
time
and
it
aids
people
who
are
too
intimidated
to
ask
questions,
because
now
they
don't
have
to
ask
a
question:
they
can
just
read
the
docs
make
sure
your
readme
file
is
up
to
date
with
build
information.
The
nice
thing
about
rust
is
that
it's
usually
just
cargo
build,
but
sometimes
you're,
weird
steps
and
prerequisites,
or
whatever
just
document
them,
also
make
sure
you're
prominently
linked
to
your
contributions.
File.
On
that
note,
whoo
yeah.
A
Sorry
on
that
note,
create
a
contributions
file
where
you
can
put
the
bulk
of
the
information
for
new
contributors.
The
patch
workflow
is
probably
one
of
the
most
important
things
you
put
there.
This
helps
both
experienced
and
new
contributors.
It's
very
important
that
you
don't
miss
anything
here.
A
few
months
ago,
there's
this
rather
well
known,
open,
established,
open
source
tool
that
I
wanted
to
send
a
patch
to
I.
Had
my
patches,
I
was
a
simple
fix.
A
I
had
everything
done,
ready
to
go
and
I'm
like
okay,
now
I
need
to
submit
this,
they
weren't
on
github
or
whatever
so
to
figure
stuff
out.
They
had
a.
They
had
a
contributing
file.
They
had
some
Doc's
somewhere
on
a
web
page
with
everything
listed,
it
went,
excruciating
detail
and
like
various
things,
it
was
like
it
told
you
exactly
how
your
white
space
should
be,
and
it
also
told
you
like
the
exact
style
length
and
maybe
even
the
color
of
your
commit
messages.
I,
don't
know
it
had
a
lot
of
information
in
it.
A
They
had
no
links,
no
mention
of
anything
after
some
googling
I
found
their
mailing
list,
I
submitted
the
patch
and
then
various
issues,
but
made
that
made
it
hard
for
that
to
work
as
well
and
getting
all
of
this
to
work
was
like
so
frustrating
and
I
could
have
I
mean
they
could
have
documented
this
in,
like
one
paragraph,
here's
the
mailing
list,
here's
I
guess
a
bit
of
patch
here's
how
it
gets,
moderated.
Here's
whatever
and
no
like
this
was
such
a
bad
experience
for
me,
like
I,
had
other
patches
I
wanted
to
do.
A
It
was
an
interesting
project
and
as
like,
never
mind
and
then
I
didn't
even
I
was
even
thinking
of
fixing
the
documentation
to
add
that
information,
but
it
left
such
a
bad
taste
in
my
mouth
that
I
never
even
did
that
because
I'm
like
I'm,
not
going
to
go
through
this
process
again
so
make
sure
you
mentioned
the
flash
contribution
workflow.
That
is
basic
aside
from
the
patch
workflow
link
to
places
where
the
discussions
happen,
like
IRC
channel
mailing
lists.
Even
if
your
issue
tracker
is
the
only
place
you
have
that
it's
good.
A
To
mention
it
sometimes
in
again
encourage
questions.
People
are
afraid
of
asking
questions.
Just
encourage
them
include
information
on
how
your
tests
work.
If
you
have
we're
testing
setups
and
have
an
overview
of
the
code
base
so
that
it's
easier
for
people
to
find
things
and
so
link
to
the
API
Doc's
of
your
codebase
and
order
library
as
it
uses
so
that
they
can
it's
easier
to
hack
on
things
include
a
code
of
conduct.
A
If
you
don't
have
one
already,
you
can
base
it
off
of
rusts
one
make
it
clear
that
certain
kind
of
behavior
will
not
be
tolerated
in
the
project
and,
if
you're,
using
github
and
again
I'm,
not
saying
you
should,
but
it's
useful
for
making
things
welcoming.
Github
is
a
very
neat
feature
where
you
can
pre-fill
issue
and
pull
request
bodies
with
thumb.
Templates.
Servo
uses
this
to
automate
to
provide
checklists
for
contributors
like
please
check
here.
If
you
did
test,
if
you
ran
the
tests
or
what
tests
this
fix.
A
A
One
of
the
most
common
sources
of
friction
for
newcomers
is
overcomplicated
contribution
processes.
Usually
these
processes
exist
for
a
reason
like
complicated
process
of
projects
need
complicated,
review,
fools
and
complicated
issue
trackers
and
a
whole
bunch
of
other
things.
They're,
usually
a
reason
behind
it
usually
sensible,
but
for
most
new
contributors,
parts
of
these
processes
are
like
unnecessary.
They
don't
provide
anything
other
than
friction.
For
example,
in
servo
we
have
this
awesome
review
tool
called
reviewable.
It
handles
rebase
as
well,
and
it
lets
you
keep
track
of
review
progress
and
it's
pretty
good.
A
It's
also
very
complicated
tool.
It
takes
quite
a
while
to
get
used
to
I
still
get
confused
by
it.
Sometimes
I
feel
like
using
it
for
a
year.
So
what
we
do?
We
don't
require
people
to
use
this.
If
the
tool
is
little
is
optional,
it
gets
used
for
large
pull
requests.
Most
newcomers
don't
make
huge
pull
requests,
so
the
cool
review
tool
isn't
necessary
there
and
we
just
use
the
regular
review
stuff
and
it
works.
They
don't
have
to
deal
with
this.
A
Similarly,
the
open
SL
project
used
to
have
a
mailing
list
for
patches,
but
they
were
okay
with
you
submitting
submitting
the
patch
on
github
and
then
you
could
like
you
had
to
do
something,
but
it
was
not.
It
was
so
simple.
It
was
well
documented,
so
it
was
nice.
I
didn't
have
to
get
the
mailing
list
at
up
to
work.
A
Oh
by
the
way
we
fix
these
issues
next
time
try
to
fix
them
because
it's
great
to
be
able
to
make
a
perfect
pull
request,
but
that's
there's
no
reason
they
need
to
learn
that
on
their
first
try,
there
are
so
many
other
things
that
they
have
to
learn
that
time.
So
it's
good
to
spread
it
out
and
in
general,
it's
nice
to
make
like
bits
of
process
like
this
optional,
provide
alternatives
as
a
contributor
gets
more
involved,
they'll
be
able
to
learn
these
things
at
a
relaxed
pace,
so
they'll
get
there.
A
Flora
should
answer
their
questions,
but
what
else
is
involved
so
first
try
and
approach
it
as
if
you're,
their
companion,
discovering
the
code
base
along
with
them,
for
example,
if
you're
to
answer
a
question
about
the
code
base,
help
them
understand
the
process
by
which
they
themselves
could
have
answered
it
by
walking
through
the
code
base,
instead
of
just
giving
them
a
code,
snippet
show
them
how
some
code
elsewhere
is
doing
something
similar
and
how
that
relates
here
and
how
they
can
transform
that
into
the
code.
They
need,
of
course
it's.
A
You
should
eventually
give
them
the
answer,
but
give
them
the
answer
and
long
form
using.
We
instead
of
you,
is
really
really
helpful
here
found
this
attitude
is
best
dispels
a
lot
of
the
apprehension
people
have
because
now
it's
like
you're
more
of
this
friend
than
just
a
mentor
you're
like
going
along
with
them,
be
clear
and
setting
your
expectations.
A
If
you're
going
to
be
too
busy
to
help
out,
let
them
know
like
I've
said
like
four
times
are
now
I
guess
a
lot
of
people
are
afraid
of
asking
questions
so,
and
the
lack
of
a
response
will
make
them
feel
wait.
Was
my
question
too
stupid?
Are
they?
Are
they
too
annoyed
with
me
to
answer
it?
So
it's
good
to
give
a
response.
Even
if
you're,
a
response
is
just
I'm
busy
right
now,
but
I
will
get
to
this
in
X
days
or
sometime
in
the
future.
A
Sorry
about
this
mentoring
doesn't
have
to
be
one-on-one,
it's
nicer
when
all
maintainer
ZAR
helping
out
and
they're
popping
in
and
out
of
an
issue
giving
answers.
Whatever
your
spreads
out
the
work
and
the
new
contributor
learns
about
the
whole
community.
Much
quicker
just
be
careful
that
nobody
falls
through
the
cracks
where
it's
like
everyone
thinks
someone
else
is
helping
them
out
follow
up.
This
is
one
of
the
most
productive
things
you
can
do
in
mentoring.
If
a
new
contributor
just
landed
a
patch
point
them
to
some
similar
issue
that
they
could
also
solve
that.
A
That
is
a
bit
more
involved.
Many
most
of
the
time
they're
more
than
happy
that
you
thought
of
them
and
they're
like
oh
wow.
Yes,
this
is
what
I
want
to
work
on
next
or,
if
you
don't
have
such
an
issue,
remember
to
ping
them
the
next
time
you
see
one.
This
really
makes
them
that
you
care
and
keep
them
engaged.
It's
great.
A
It's
important
to
understand
where
your
contributors
are
coming
from.
One
of
the
most
common
mistakes
and
sources
of
frustration
is
that
it's
assuming
that
everyone
thinks,
like
you
and
shares
you're
experiencing
experiences,
which
is
never
the
case.
Open
source
mentorship,
isn't
an
opportunity
to
experience
different
ways
of
thinking
almost
firsthand.
It's
an
opportunity
to
become
a
better
teacher
and,
of
course,
improve
someone
else's
programming
in
the
process.
All
of
this
requires
empathy,
be
patient
with
your
mentees,
avoid
expecting
things
from
them.
A
For
example,
sometimes
they
may
not
be
familiar
with
the
tools
you
use
in
Clippy
we've
had
a
couple
of
great
contributors
from
we've
had
a
couple
of
great
contributions
from
people
who
just
made
the
patch
on
their
own
without
help,
and
then
they
didn't
know
how
to
use
github
and
like
in
the
rust
community.
We
sort
of
assume
people
know
how
to
use
github,
but
it's
not
true
for
everyone
and
some
and
like
ok,
we
explained
it
and
it
worked.
A
They
were
able
to
use
it,
but
I've
seen
this
happen
a
couple
of
times
other
times.
They
may
not
be
familiar
with
the
programming
language
and
Cervo.
We
get
a
lot
of
people
who
are
new
to
rust
and,
like
have
read,
maybe
the
first
few
chapters
of
the
book
and
they
feel
that
they
can
learn
Russ
better
by
contributing
to
an
open
source
project.
We
still
get
great
contributions
from
these
folks,
and
many
of
these
folks
have
gone
on
to
become
like
really
good,
rust.
A
Programmers
doing
a
lot
of
more
involved
things
on
both
our
code
bases
and
others.
Sometimes
I
mean
you
will
require
familiarity
with
the
language
for
an
involved
issue,
or
sometimes
you
just
won't,
have
the
time
to
mentor
someone
who,
like
needs,
help
with
the
language
itself,
but
it's
better
to
make
this
expectation
clear
and
the
bug
itself
as
much
as
possible
and
for
better
or
for
worse
a
project
will
usually
have
a
primary
language
of
communication.
Not
everyone
will
be
fluent
so
never
assume
that
so
I
guess
this
is
a
European,
your
room
room.
A
So
everybody
knows
that
and
finally
use
inclusive
language
of
what
phrases
like
just
do
this
like
just
while
the
task
may
seem
simple
to
you.
There
may
be
complexities.
You
have
just
ignored
because
you're
used
to
it
it's
very
hard
to
put
yourself
completely
in
someone
else's
shoes.
So
don't
ever
assume
that
you
have,
because
it's
very
discouraging
when
someone
tells
you
just
do
X
and
then
you
go
to
just
do
it
and
actually
pretty
hard
and
then
you're
like
wait,
but
that
person
thought
was
easy.
What
am
I
doing?
A
A
You
may
wish
to
do
the
same
I'm
going
to
leave
you
all
with
a
wonderful
quote
by
Toni
Morrison
that
helps
motivate.
Why
I
feel
that
way?
I
tell
my
students
when
you
get
these
jobs
that
you
have
been
so
brilliantly
trained
for.
Just
remember
that
your
real
job
is
that
if
you
are
free,
you
need
to
free
somebody
else.
If
you
have
some
power,
they
need
your
job
is
to
empower
somebody
else.
This
is
not
just
a
grab
bag
candy
game.
Thank
you.