►
Description
Everything you want to know about the current and future state of the Rust project, team and community.
A
So
I'm
josh
triplett,
I'm
on
twitter
as
josh
underscore
triplet.
Please
don't
all
run
off
to
twitter
simultaneously
and
disappear
from
the
in
person
event.
The
I'm
a
member
of
the
language,
library
and
cargo
teams,
which
I
really
love
working
with
and
rust.
I
care
about
a
great
deal
as
a
technology,
I
think,
is
absolutely
incredible.
Does
a
lot
of
things?
Many
other
things
don't.
A
However,
I
care
about
rust,
even
more
in
terms
of
the
processes
used
to
develop
it
and
in
terms
of
the
people
that
make
up
the
project,
and
so
that's
definitely
an
ascending
order
of
importance.
So
I
want
to
give
a
little
bit
of
history.
For
myself,
I
was
at
the
first
rust
conf
in
2016
and
gave
a
talk
rfc
in
order
to
form
a
more
perfect
union,
about
adding
c-style
unions,
to
rust,
to
support,
building
virtual
machines
based
on
linux
and
dev
kvm,
but
as
well
as
being
a
technology
talk.
A
A
So
by
way
of
how
rust
has
evolved
over
time,
I
want
to
mention
my
own
first
rust
project
called
get
series.
Get
series
was
trying
to
track
the
history
of
history,
versioning,
a
patch
series,
and
I
wanted
to
build
this
on
libgit2,
because
I
didn't
want
to
reinvent
git
myself,
so
I
started
looking
at
the
documentation
of
this
and
saw
things
like
this
returns.
A
tree
entry,
that's
owned
by
the
tree.
This
returns
a
tree
entry
owned
by
the
user.
It
must
be
freed
explicitly.
I
saw
lots
of
things
like
this
and
my
thought
is.
A
Where
have
I
heard
that
before
so
I'd
been
hearing
about
this
new
rust
thing
and
following
all
of
the
blogs
on
planet,
mozilla
and
other
places-
and
I
saw
that
it
just
hit
rust
1.0,
which
was
really
exciting?
It
was
stable.
No
more
breaking
changes,
no
more
runtime,
which
is
incredibly
exciting,
really
differentiating
no
more
pointer
sigils.
A
It
doesn't
look
like
pearl
anymore
and,
most
importantly,
for
my
purposes
there
was
this
great
library
git2rs
that
alex
crichton
wrote
that
bound
to
all
of
the
libgit2
calls
and
took
care
of
all
of
those
lifetime
issues
for
me.
So
I
did.
I
learned
rust
in
the
course
of
writing.
Git
series,
and
one
of
the
biggest
things
I
ran
into
was
error.
Handling
issues
that
was
my
rust
is
hard
to
learn.
A
Moment
was
dealing
with
error
handling,
so
rust
was
a
really
different
language
back
then,
question
mark
didn't
actually
exist
yet
as
an
operator
kind
of
hard
to
imagine
now,
but
that
was
not
introduced
till
rust,
118
in
november
2016..
That
was
really
quite
a
contentious
change
and
I
was
doing
this
work
in
early
2016..
A
So
at
the
time
there
was
still
the
try
macro
which
tended
to
pile
up
on
the
left
rather
than
being
post-fixed
but
hey.
If,
at
first
you
don't
succeed,
so
error
handling
was
complicated
for
a
number
of
reasons,
but
most
of
all,
you
had
to
build
an
error,
handling
type,
something
to
be
the
e
and
the
result
of
type
and
error
that
could
hold
any
error.
You
might
produce
whether
that
was
an
error
from
git
to
an
io
error.
A
Reading
and
writing
a
file,
a
utf-8
error,
dealing
with
character
sets
and
it
had
a
whole
stack
of
requirements
that
I
won't
go
into,
but
in
general
I
have
to
write
this
by
hand.
I
have
to
write
out
a
manual
error,
enum
and
I
have
to
add
to
it
whenever
I
try
a
new
error
type
that
I
haven't
used
before.
A
Well,
fortunately,
there
were
already
libraries
to
deal
with
this.
There
was
a
library
called
quick
error
that
provided
a
macro
looking
a
lot
like
an
enum,
it
implemented
all
the
traits.
You
need
to
make
an
error
and
you
just
add
a
new
variant
for
each
error
and
it
was
fairly
easy
to
do
a
couple
lines
of
code.
It's
actually
almost
as
old
as
rust,
.0
1.0.
It
was
released
right
around
the
same
time.
A
A
There
are
far
more
libraries
than
I
have
time
to
cover,
I'm
omitting
a
lot
of
unimportant
details
and
really
many
many
people
deserve
credit
for
all
the
changes
along
the
way,
and
I
can't
possibly
cover
them
all,
but
the
next
library
that
I
had
experience
with
that
lots
of
people
used
was
called
error
chain.
Its
big
innovation
was
hey.
Let's
preserve
the
error
that
caused
an
error.
You
failed
to
open
this
file.
Let's
capture,
I
failed
to
open
this
data
file
and
the
reason
for
that
was
a
permission.
A
Error
or
the
file
doesn't
exist
or
cosmic
ray,
and
this
was
a
really
popular
library,
made
it
much
easier
to
debug,
where
an
error
came
from.
There
was
a
blog
post
about
it,
how
to
start
a
new
rust
project
right
with
error
chain,
and
this
library
was
much
better
than
what
came
before.
Clearly,
everybody
should
use
this.
Why
wasn't
something
like
this?
In
the
standard
library,
the
next
major
development
after
that
was
a
library
called
failure
which
was
much
simpler
to
use
it
had
a
new,
simpler
version
of
the
error,
trait
called
fail.
A
It
had
a
a
proc
macro
derived
to
create
your
enum,
which
means
you
could
use
rust,
actual
syntax
to
write
your
enum
also
provided
a
catch-all
type
for
when
you
don't
really
care
what
kind
of
error
it
was.
You
just
need
to
do
like
simple
command
line,
error
handling,
and
it
made
it
really
easy
to
write
your
error
messages
for
each
variant
because
it
had
kind
of
a
display
derive
as
well.
A
So
this
was
much
better
than
what
came
before.
Clearly,
everybody
should
use
this.
Why
wasn't
failure
in
the
standard
library?
Well,
at
this
point,
we
did
start
to
make
some
changes
to
the
standard
library
we
simplified.
The
error,
trait
you
no
longer
had
to
implement
a
few
methods
in
order
to
write
error.
A
So
anyhow
was
the
new
catch-all
error
type
and
it
was
built
on
those
same
standard
library
changes,
and
then
this
error
was
for
when
you
wanted
a
derived
to
have
individual
enum
types
rather
than
a
catch-all,
and
it
was
just
as
lightweight
as
implementing
it
all
yourself
and
we
made
a
few
more
language
changes.
At
this
point.
We
added
support
for
returning
a
result
from
your
main
function
and
you
didn't
have
to
write
any
error,
catching
error
catching
boilerplate
anymore,
but
now
we're
doing
actual
output
to
display
the
error
and
report
the
error.
A
So
what
should
the
reported
error?
Look
like
there's
lots
of
opinions
on
user
experience.
Should
this
be
for
quick
and
dirty
programs,
or
is
this
something
everyone
should
use
so
at
that
point,
error
written
by
jane
currently
on
the
library
team,
jane's,
error,
library,
jane
eyre,
but
it
gives
full
control
over
error
reporting
over
what
information
you
collect
if
you
want
to
get
a
back
trace
or
a
span
trace
all
sorts
of
other
useful
things
and
we're
making
more
changes
to
the
standard
library
further
to
work.
A
Well
with
things
like
this,
we're
adding
a
provider
api
that
lets,
you
attach
arbitrary
information
to
an
error
like
a
span
trace
or
a
back
trace
or
similar
and
we're
finally
moving
the
error
trait
to
core
I'm
expecting
that
to
go
in
literally
any
day
now
and
we're
going
to
make
more
changes
in
the
future,
we'll
likely
add
a
standard
catch-all
type
similar
to
anyhow
or
error,
we'll
likely
add
a
standard
derive
error
or
derived
display,
but
the
whole
time
we
were
evolving
these
libraries
and
adding
a
few
more
things.
People
continued
to
ask.
A
A
So
obviously,
the
lesson
for
this
is
that
we
should
wait
a
long
time
and
make
sure
everything
is
completely
settled
before
we
had
anything
to
rust
right
well,
along
the
way,
though,
we
made
a
lot
of
incremental
steps.
We
added
changes
to
the
library
changes
to
the
language,
to
make
rust
work
better
with
those
various
error
handling
libraries,
we
didn't
just
wait
for
all
the
dust
to
settle,
so
the
key
thing
is
that
rust
and
the
ecosystem
evolve
together.
A
This
is
constantly
true
and
it's
a
constant
cycle.
This
has
been
true
for
many
other
things.
This
was
true
for
async
await
where
it
was
a
major
use
case
for
rust
users.
People
wanted
to
experiment
throughout
the
ecosystem,
and
this
was
so
much
easier
to
use
when
you
had
native
syntax
for
it
rather
than
writing
it
all
with
macros
or
similar.
A
A
So
we
see
things
that
are
widely
used
and
really
have
one
correct
way
to
do
them.
There's
no
reason
to
have
20
implementations,
so
we
add
them
to
the
standard
library
and
another
I'm
incredibly
excited
about
is
the
I
o
safety
work,
which
is
stabilizing
this
week,
I
believe
so
or
shipping
in
the
version
coming
out
later
this
week.
A
But
this
is
a
continuous
cycle
where
we
have
a
full
foundation
of
the
rust
language,
libraries
and
tooling.
We
have
established
crates
that
build
on
those.
We
have
more
experimental
crates
that
build
on
the
established
crates
and
try
interesting
new
things,
and
we
have
applications
which
consume
any
of
those
and
try
to
provide
useful
functionality
to
the
user
and
all
of
these
feed
into
each
other.
In
a
very
continuous
cycle.
A
We
have
experimentation
in
la
in
applications
in
more
experimental
crates
to
come
up
with
exciting
new
ways
to
do
things
and
the
best
of
those
find
their
way
into
standardization
in
the
rust
language
in
the
rust
standard
library
in
more
established
crates-
and
this
is
a
continuous
cycle,
so
lots
of
things
can
happen
if
you
stabilize
too
quickly,
you
could
end
up
with
a
skyscraper
with
exposed
girders
in
the
foundation.
You
end
up
with
unfixable
problems,
you're
trapped
by
your
stability
guarantees,
and
this
can
really
stifle
ongoing
innovation
on
an
api
itself.
A
Oh
we've
now
standardized
a
thing,
so
there's
no
point
in
continuing
to
experiment
and
make
it
better
because
here's
the
standard
thing,
so
we
don't
want
to
do
it
too
quickly,
but
if
we
stabilize
too
slowly,
then
we
don't
have
any
foundation
at
all.
There's
too
much
uncertainty
out
there,
and
this
stifles
innovation
above
the
api.
Oh,
I
want
to
build
on
async,
but
there's
too
many
different
libraries.
I
want
to
build
on
this
technology,
but
there's
too
many
variations
I'll
wait
for
the
dust
to
settle.
A
Well,
one
big
question
we
continuously
ask
ourselves
is:
when
do
we
start
standardizing
things
we
have
to
balance
between
experimentation
on
an
api
when
we're
still
improving
and
cycling
on
that
with
experimentation,
atop,
an
api
which
really
wants
to
have
a
stable
foundation
to
build
on
and
there's
no
one
right
answer
for
this.
This
is
a
continuous
process
and
continuous
refinement.
A
We've
also
learned
to
be
careful
of
the
second
system
effect
where
oh
we're
going
to
make
this
perfect
the
second
time
around,
let's
redesign
this
and
put
it
in
the
standard
library.
At
the
same
time,
that's
never
a
good
idea,
so
redesigns
are
something
we
always
want
to
prototype
outside
the
standard
library
and
then
fold
in,
even
if
we
fold
them
in
fairly
quickly,
because
we
know
we're
looking
to.
We
want
to
do
the
experiment,
try
it
out
and
then
pull
it
in.
A
We
also
hope,
honestly
to
make
standard
a
little
bit
less
special
as
a
central
place
in
the
ecosystem.
It's
still
the
standard
library,
but
we
could
use
fewer
nightly
features.
We
could
standardize
a
lot
of
the
things
that
only
the
standard
library
uses
and
stabilize
them
so
that
other
libraries
can
do
some
of
the
same
tricks
we
do
and
we're
also
hoping
to
avoid
breakage
when
we
standardize
things.
A
We've
taken
things
like
itter
tools,
intersperse
stabilized
it
as
iterator
intersperse,
and
we
ran
into
a
lot
of
conflicts
where
somebody
using
iter
tools
would
now
get
compilation
errors.
This
was
especially
bad
when
the
name
was
still
unstable,
so
it
was
you've
got
a
name
conflict.
You
should
be
using
this
thing.
A
Oh,
this
thing's
nightly
only
this
was
kind
of
an
unavoidable
error
and
we're
improving
name
resolution
in
some
ways
to
try
to
avoid
this
to
try
to
steer
towards
if
you're,
using
iter
tools,
you
must
have
wanted
to
use
inner
tools
and,
in
the
other
direction,
we're
thinking
of
adding
things
like
config
accessible
to.
Let
things
like
iter
tools
say
well,
I'm
providing
intersperse,
but
only
if
the
standard
library
doesn't
and
in
general
we
have
incredible
stability
guarantees.
A
It's
really
important
that
we
promise
that
new
code
compile
but
brand
new
rust
compilers
will
compile
all
of
your
old
code
and
never
break
anything.
But
we
are
also
looking
to
support
editions
for
the
standard
library.
Editions
have
been
a
great
way
to
evolve
the
language
without
making
breaking
changes
for
existing
code,
and
the
library
has
historically
not
been
able
to
make
use
of
that
and
we're
hoping
to
change
that
in
the
future.
A
A
A
So
as
a
result
of
all
this
evolution,
a
lot
of
people
start
asking
questions
like
well:
when
will
russ
stop
changing
when
will
rust
be
done
and
from
inside
the
ecosystem,
if
you're
already
using
rust?
This
can
sound
a
lot
like
well,
when
will
rust
stop
evolving
with
its
ecosystem?
When
will
russ
stop
listening
to
its
users?
When
will
russ
start
dying?
Well,
we're
not
planning
on
dying
anytime
soon,
but
people
who
are
asking
this
are
really
asking
for
a
stable
foundation
to
build
a
top
they're
in
that
layer
of
well.
A
The
layer
underneath
me
isn't
a
firm
enough
foundation.
When
will
that
layer
stop
changing,
and
so
one
of
the
things
we
want
to
improve
on,
but
that
we
already
somewhat
do
we
can
evolve
and
still
provide
a
stable
foundation
underneath
we
already
don't
break
stable
rust
code
and
supporting
new
use
cases
does
not
mean
we're
breaking
the
existing
ones,
but
it
does
mean
that
there's
some
more
to
learn.
A
So
I
talked
about
how
rust
and
the
ecosystem
evolved
together,
but
I
also
said
that
I
care
about
technology
and
process
and
people
in
ascending
order
of
importance,
so
I
also
want
to
talk
about
how
rust
and
the
community
evolve
together.
Well,
our
processes
are
in
many
ways
an
api
of
the
rust
project.
They
don't
have
quite
the
same.
Stability
guarantees
it's
inconvenient
when
they
change,
but
they're
not
immutable.
A
So
I
want
to
talk
about
a
few
of
those
processes
in
the
current
state
of
them.
First
of
all,
the
initiative
process,
a
number
of
teams
have
been
experimenting
with
a
new
process
for
proposing
changes.
It
was
supposed
to
be
lightweight,
unlock
experimentation,
make
it
easier
to
contribute,
and
the
quick
update
is
unlocking
experimentation
check
that
worked
really
well.
A
Simplifying
contribution
not
so
much,
we
ended
up
making
it
a
little
more
complicated
to
contribute,
because
there
are
more
entry
points
and
people
weren't
quite
sure,
which
way
they
should
be
contributing,
so
expect
some
further
iteration
and
simplification
on
this
process
to
make
it
more
obvious.
Here's
your
one-stop
shop,
for
I
want
to
contribute
to
rust.
What
kind
of
issue
do
I
need
to
file?
Where
do
I
file
it,
etc?
A
I
want
to
talk
briefly
about
the
target
tier
policy.
This
is
the
policy
we
put
out
some
time
ago
for
how
we
support
different
targets.
This
is
tier
one.
We
all
support
it
together.
This
is
tier
three,
it's
supported
by
its
users
and
it
talks
all
about
how
we
support
those
targets
who
supports
them
and,
most
importantly,
who
does
which
part
of
the
work-
and
this
is
going
to
be
a
recurring
theme
in
a
lot
of
our
processes-
of
what
many
use
cases
should
be
well
supported.
A
A
We've
talked
about
having
process
for
community
projects
easier
ways
of
like
we
need
a
successor
for
the
working
group,
project,
group,
etc,
model
and
that's
still
somewhat
under
evolution,
and
a
very
brief
update
on
rust
governance.
So
many
of
you
may
have
heard
that
we've
had
some
issues
and
improvements
to
make
with
thrust
governance.
Lately,
I'm
not
going
to
go
into
great
detail
on
those
but
effectively
we
discovered
undefined
behavior
in
some
of
our
processes
oops,
and
we
put
together
a
bit
of
interim
governance
to
try
to
work
our
way
through
those.
A
A
We
also
want
to
avoid
the
second
system
effect.
Remembering
that
same
lesson,
so
we
don't,
we
don't
think
we're
going
to
get
it
perfect.
The
first
time,
which
means
one
of
our
most
important
goals,
is
to
have
processes
to
evolve
smoothly
over
time
and
never
have
rust,
governance
process
2.0
and
a
new
rest
governance
crisis.
In
that
way.
A
A
Watch
for
people
who
are
seeking
support
in
areas
you
care
about
watch
for
people
who
are
seeking
support
in
areas
rust
desperately
needs
and,
if
you're,
in
a
position
to
do
so,
then
see
if
there's
some
way
that
you
can
help,
and
that
doesn't
just
mean
helping
with
code,
so
that
can
come
in
a
lot
of
different
forms.
Some
people
are
looking
for
employment.
Some
of
the
people
today
may
be
looking
for
a
job.
Some
of
them
may
be
looking
for
a
contract.
A
Some
of
them
may
be
providing
services
or
looking
for
some
kind
of
services.
Some
of
them
may
be
looking
for
sponsorship,
and
so
I
want
to
encourage
you
to
support
the
people
who
are
working
on
rust
to
make
rust
possible,
and
it
is,
if
you
see
people
asking
for
support,
saying
hey.
I
work
for
you
know
this,
I'm
looking
for
a
new
role,
I'm
looking
for
sponsorship.
A
A
Thank
you.
I
really
appreciate
that
yeah.
When
did
it
become
less
kosher
to
explicitly
talk
about
how
we
support
the
work
that
gets
done,
but
being
an
example
of
that
myself,
I
am
working
on
build
systems
with
a
startup
called
build
it.
I
do
contracting
with
futureway,
which
I'm
really
happy
working
with,
and
I
do
github
sponsors
which
I'm
really
grateful
to
all
of
these
people,
sponsoring
my
work
on
rust,
including
solana
and
embark
studios,
and
I
really
appreciate
that-
and
I
want
to
thank
you-
please
enjoy
the
conference.
A
B
B
B
B
There's
an
old
saying
you
may
have
heard
that
says
if
you
want
to
go
fast,
go
alone,
but
if
you
want
to
go
far,
go
together
and
this
quote
predates
computers,
but
it
really
embodies
the
dream
of
open
source
and,
in
particular,
rust's
commitment
to
those
ideals
you
see.
Rust
has
gone
far
and
in
fact
we've
been
talking
about
ideas
like
this.
For
years
on,
our
blogs,
through
the
community
and
in
places
like
ruskoff
keynotes,.
B
Now,
of
course,
rust
is
an
open
source
project.
That's
not
what
I'm
talking
about.
Openness
is
about
being
open
to
ideas
and
perspectives
other
than
your
own
rust
was
built
with
the
help
of
grizzled
c
systems.
Programmers
and
with
the
help
of
ruby
and
python
developers
who
wanted
to
speed
up
their
web
apps
and
those
groups
didn't
really
overlap
that
much
before.
B
B
Now,
let's
be
real,
no
one
is
unlimited
in
their
capacity
to
do
this.
You
can't
build
a
language
for
everyone,
and
eventually
projects
have
to
make
decisions,
but
because
we
practice
this
openness,
those
decisions
tend
to
be
made
with
a
much
better
understanding
of
the
trade-offs
involved
and
the
principles
behind
each
option.
B
B
B
B
B
B
Now,
there's
good
news,
it's
easy
to
find
examples
of
these
values,
echoing
throughout
the
project.
Today,
if
you
ask
around
you'll,
hear
project
numbers
say
things
like
we
document
we
mentor,
we
tag
issues
for
new
contributors,
the
contributors
will
say
things
like
the
reviewers
are
kind,
and
you
can
feel
the
good
intentions
from
a
mile
away.
B
B
B
They'll
tell
you
to
focus
on
what's
happening
in
these
requests,
because
that's
where
you're
going
to
learn
the
most.
Those
responses
are
where
the
big
really
big
problems
live,
and
sometimes
you
study
one
and
you
find
there's
nothing.
You
can
do
some
things
are
completely
out
of
your
control,
but
other
times
you
find
a
problem
in
your
system
that,
under
higher
loads,
might
bring
down
your
whole
service.
If
you
don't
fix
it.
B
B
In
this
metaphor,
the
higher
the
percentile,
the
fewer
people
it
captures,
but
generally
the
worse
experiences
people
are
having
and
as
we
saw,
we
had
30
of
people
trying
and
failing
to
contribute
to
rest,
that's
around
the
70th
percentile
and
eight
percent.
Oh
that's
around
the
90th
percentile,
the
person
who
doesn't
feel
welcome
in
the
first
place,
and
these
are
just
the
people
we're
reaching
with
the
rest
survey.
Today,
it's
not
at
all
representative
of
what
we'd
like
the
project
to
look
like
five
years
from
now.
B
These
groups
that
don't
have
good
representation
in
the
project.
Today
they
have
the
biggest
headwinds
to
getting
involved
in
the
first
place,
and
that's
why
we
focus
on
the
top
on
the
one
percent
of
people
who
have
the
most
difficult
time.
We
want
to
see
that
one
percent
become
two
percent
and
then
five
percent,
maybe
even
10
percent.
B
Now
I
want
to
emphasize
that
this
is
for
everyone.
Listening
to
this
talk,
if
you're
part
of
the
rest
community,
it
applies
to
you.
There's
no
other
way
to
scale
this
as
the
number
of
rest
users
and
their
perspective
goes
up.
It's
almost
the
number
of
open
and
curious
people
who
interact
with
them
and
build
a
shared
understanding
of
common
problems.
The
core
language
team
is
like
five
people.
They
can't
do
it
all
by
themselves.
B
B
B
B
B
Now,
if
you've
committed
to
mentoring,
someone
or
reviewing
their
something,
they
write.
Obviously
you
should
follow
through.
But
beyond
that,
don't
always
prioritize
your
friends
or
the
people.
You
know
it'll
only
reinforce
the
existing
in-group,
accurate
dynamics
and
ultimately
hinder
rest
growth.
B
B
B
B
Now,
if
you've
been
around
open
source
for
a
while,
you've,
definitely
seen
this
break
down
this
open
source,
ideal
breakdown
in
other
projects,
you
see
features
land
without
any
documentation.
You
see
complexity
and
tech.
Debt
accumulate
over
time
without
clear
owners,
you
see
sometimes
see
reviewers
who
become
kind
of
zealous
gatekeepers
and
eventually
it
becomes
so
hard
to
contribute
that
people
kind
of
invent
their
own
work
arounds.
Instead
of
actually
fixing
problems
upstream
in
extreme
cases,
they
will
fork
the
project
and
maintain
a
fork.
B
First,
when
you're
contributing
to
open
source,
it's
common
to
think
of
your
contribution
of
as
simple
as
design
implement,
hopefully
with
documentation
and
then
land,
but
for
the
project
to
stay
healthy.
Someone
needs
to
drive
that
feature
to
stabilization
and
continue
maintaining
it
over
time.
Answering
questions
and
paying
down
tech
debt
so
make
sure
you're
committed
for
the
full
life
cycle
of
a
feature
and
include
each
stage
in
your
planning,
but
it
doesn't
stop
there,
there's
a
cost
for
the
project,
meaning
the
rest
project
to
accept
this
contribution
as
well.
B
B
B
B
And
also
remember
that
your
counterparts
in
a
discussion
might
not
be
on
the
clock.
They
could
be
volunteers
with
less
time
to
commit
to
a
discussion
than
you
have
and
that's
not
a
license
to
ignore
them.
If,
if
anything,
it
means
you
have
a
greater
responsibility
to
practice.
Openness
and
curiosity
try
to
pull
out
the
valuable
parts
of
their
perspective.
B
Finally,
if
you're
a
manager
recognize
that
this
is
a
skill
that
not
everyone
is
willing
or
able
to
do
well,
in
fact,
it
can
be
quite
difficult,
but
working
in
a
project
like
rest
requires
practicing
these
qualities
of
openness,
curiosity
tact
because
influence
doesn't
have
anything
to
do
with
their
seniority
in
your
company.
It
has
everything
to
do
with
their
ideas
and
their
reputation
and
the
reputation
of
someone
who's
working
for
you
becomes
your
reputation.
So
it's
crucial
that
you
recognize
this
as
a
skill
in
your
employees
or
contractors
and
reward
it.
B
B
Now
before
I
close,
I
want
to
say
that,
as
josh
mentioned,
a
number
of
our
speakers
today
are
looking
for
sponsorship.
Now
I've
been
speaking
for
myself,
but
I
do
work
for
google
on
the
fuchsia
team
and
I'm
lucky
enough
to
do
this
work
as
part
of
my
job.
So
I
don't
need
sponsorship
of
any
kind,
but
do
please
keep
your
eye
out
for
people
who
are
seeking
that
sponsorship
or
other
support
and
consider
us
just
supporting
one
of
them.