►
From YouTube: Documentation in the Rust Ecosystem — Andrew Brinker
Description
Materials for this talk are available at https://github.com/AndrewBrinker/talks/tree/master/rust-belt-rust-2016
Documentation is important. It lowers the barrier for newcomers to use and understand libraries. It helps train and prepare new contributors. It opens up avenues of contribution that go beyond writing code. It makes open source more open, and makes libraries better by its existence.
Rust has all the makings of a great ecosystem of well-documented libraries: a high-quality and ever-improving documentation generator ships with the compiler, and the language team leads by example with a strong focus on documentation. Yet the quality and availability of documentation for Rust crates remains spotty, with many crates providing incomplete documentation, or relying on the types they expose to describe their use and function. This talk takes an in-depth look at the state of documentation in the Rust ecosystem today—including how many crates provide easily-located documentation, and how complete that documentation is—and then describes ideas for improvement, including improvements to Rust's documentation-related tools and ideas for crate maintainers to both write better docs themselves and to encourage contributions from others via documentation-focused mentorship.
http://www.rust-belt-rust.com/
A
Hello,
so,
as
she
said,
I
am
Andrew,
Brinker
and
I'm
here
today
to
talk
about
documentation
in
the
rust
ecosystem.
Basically,
why
do
docks
matter?
What
kinds
of
docks
we
need
to
consider
like,
which
is
what
are
the
different
sort
of
types
that
are,
that
should
be
available
for
a
library
how
our
docks
in
the
rust
ecosystem
looking
right
now,
and
how?
A
So
first
things
first
I
think
it's
important
to
understand
what
we
mean
by
docks.
Are
there
different
types
of
docks?
What
are
the
goals
and
characteristics
of
the
different
types
of
documentation?
Basically,
what
does
the
word
docks
include
and
I'd
like
to
sort
of
think
of
them
in
in
three
categories
we
meet-cute
the
black
triangle,
the
walkthrough
and
the
reference
and
I
think
it's
also
important
to
note
that
each
of
these
types
of
docks
can
can
be
present
in
in
different
actual
documents.
You
may
have
one
document
that
has
several
of
these.
A
This
isn't
talking
about
like
a
particular
document.
You
could
have,
for
example,
a
walkthrough
and
a
reference
that
are
both
using
rust
dock.
So
this
is
more
about
the
concept
of
the
documentation
itself,
rather
than
the
documents
that
are
being
used
to
communicate
it.
So
the
meet-cute
is
answering
the
most
basic
questions
about
your
library.
It's.
What
is
this
thing?
Why
should
I
care
like?
Is
this
useful
to
me?
Usually
you'll
see
this
at
like
the
top
of
a
readme.
It's
your
shortest
pitch
of.
Why
does
this
thing
exist
right?
A
Because
if
you,
if
you
don't
have
that,
if
you
don't,
you
can't
convince
a
person
when
they
come.
Look
at
your
library
that
this
thing
is
something
that
they
need
or
if
they
don't
even
know
what
you're
doing
and
have
no
idea
what
your
library
is.
No
one's
going
to
use
it,
and
so
this
is
sort
of
the
most
basic
piece
of
documentation.
A
Next,
you
have
the
black
triangle,
which
is
the
the
simplest
code
to
do
something
good,
so
the
the
name,
the
black
triangle,
actually
comes
from
a
story
by
a
developer
at
rampant
games.
They
were
developing
a
new
game
and
had
built
up
this
whole
new
asset
pipeline
and
graphics,
rendering
system
and
there's
a
whole
bunch
of
stuff
and
have
been
working
for
several
months
and
hadn't
really
had
anything
to
show
that
thought
it
was
all
sort
of
down
in
the
weeds
work
and
they
hadn't
gotten
anything
to
go
through
the
whole
system
and
actually
display.
A
And
finally
they
did.
It
was
a
black
triangle
and
everyone
in
the
in
the
project
who
was
working
on
that
was
very,
very
excited
to
see
this
this
little
black
triangle
on
the
screen,
because
they
knew
that
it
had
gone
through
all
this
other
stuff,
they'd
written
in
it.
It
showed
that
what
they'd
already
done
and
showed
what
they
could
do
now
now
they
had
all
this
stuff
in
place.
They
could
actually
go
about
building
the
game
and
so
I
think
yeah.
You
want
sort
of
the
same
response
from
your
simplest
example.
A
Your
simplest
thing
that
shows
hey
here's,
how
this
thing
works
at
a
most
basic
level:
here's
what
it
enables
you
to
do,
and
so
that's
really
what
the
black
triangle
is.
It
is
the
simplest
code
to
do
something
to
do
something.
Cool
sort
of
entice
people
to
explore
more,
the
walk
through
I
would
say,
is
probably
the
hardest
part.
A
Looking
at
the
the
same
sort
of
idea
for
your
individual
library,
this
is
this
is
difficult
to
write
and
I
will
get
into
that.
And,
finally,
you
have
the
reference.
This
is
your
API
reference.
This
is
the
complete
thing.
It
says
every
little
component
you've
got
how
it
works,
how
the
things
interrelate
and
it's
I,
think
the
most
important
thing
to
remember
here
is
that
people
can
come
at
this
documentation
from
all
sorts
of
different
directions.
A
Doc's
are
often
the
first
thing
people
see
before
they
actually
look
at
your
code
before
they
do
anything
with
your
library.
People
are
likely
to
to
look
at
the
readme.
Look
at
some
examples.
Having
that
that
first
documentation
be
good
is
is
really
important
because,
frankly,
first
impressions
are
important.
Documentation
is
how
your
library
says
hello
and
making
sure
that
that
that
hello,
making
sure
that
that
first
impression
is
good
is
is
very,
very
important
and
most
of
all,
good
Doc's
are
really
needed
for
productivity.
A
With
the
library
people
aren't
going
to
be
able
to
build
things.
Do
things
with
your
code?
No
one
wants
to
actually
go
through
all
the
code
itself
to
figure
out
what
are
you
providing
to
them?
How
do
the
parts
work
together?
How
do
you
use
it?
People
want
to
have
Doc's,
so
it's
just
it's
important
to
actually
make
sure
you
do
that
and
to
give
a
sort
of
case
study
about
this
I'm
gonna
talk
a
little
bit
about
the
creation
of
the
rust,
frequently
asked
questions
page
now.
A
For
those
of
you
who
don't
know,
if
you
go
to
the
rust
website,
go
to
the
documentation
page,
just
the
link
at
the
top
there's
a
on
that
page
linked
to
the
frequently
asked
questions
page
right
now.
It's
got
just
under
120
questions
and
answers'
know
how
they
recommend
people
check
that
out
and
if
you
have
any
problems
with
it,
please
let
me
know
I'm
happy
to
to
work
on
it
with
you.
A
So
the
the
process
for
the
frequently
asked
questions
page
was
basically
done
in
three
phases
and
I
think
that
the
this
these
three
phases
provide
a
good
template
for
working
on
documentation
in
other
contexts.
So
the
first
was
community
outreach
about
a
year
ago,
some
of
you
all
made
it
may
have
seen
posts
on
like
the
rust
subreddit
or
the
user
forum
or
lobster's
record
news
wherever
I
may
be,
on
Twitter
asking
for
feedback
about
common
questions.
People
have
with
with
rust.
A
If
you
remember
that
that
those
questions
were
going
to
eventually
went
into
the
frequently
asked
questions
page
in
this
particular
case,
this
process
was
a
really
nice
fit
because
it's
a
frequently
asked
questions
page,
and
so
it's
nice
to
just
ask
what
are
your
questions
and
then
there
you
go,
you
have
them.
You
just
need
to
organize
them
and
answer
them.
A
So
that's,
but
but
the
idea
of
community
outreach
the
idea
of
reaching
out
to
your
users
or
to
potential
users
who
maybe
looked
at
the
thing
you've
made
and
said:
no,
it's
not
for
me
reaching
out
to
them
and
finding
out
why
they
didn't
use
it
or
what
they
don't
like
about
it.
What
their
questions
are?
It's
a
really
really
valuable
thing
to
get
a
sense
of
what
you're
missing,
and
the
first
thing
to
know
is
to
it's
useful
to
reach
as
far
as
humanly
possible.
A
So
for
this
that's
just
meant
posting
sort
of
the
solicitation
for
questions
on
as
many
places
as
we
could
think
of
I
know
the
rust
Twitter
account
tweeted
about
it
and
got
some
people
through
that.
Just
making
sure
that
you're
really
not
if
you
don't
want
to
miss
people,
the
more
input
you
get
it's
just
it's
always
valuable,
you're,
never
going
to
be
like.
Oh
no
I'm
done
I,
don't
I,
don't
want
any
more
feedback
on
this.
A
It's
you
just
you
want
as
right
as
why
to
reach
as
many
eyes
as
many
people
contributing
as
possible
and
next
is
to
take
all
input
seriously.
One
of
the
things
I
found
is
like
when
you've
worked
on
a
thing.
You've
built
a
thing.
You
are
often
one
of
the
worst
judges
of
what's
easy
to
understand
or
hard
to
understand
about
it
or
like
what
people
are
gonna
have
issues
with
it's
easy
to
forget
what
it's
like
to
be
someone
who's
completely
new
to
something
has
no
idea.
A
What's
going
on
and
it's
easy
to
when
people
do
give
that
feedback
to
kind
of
ignore
it
or
discounted
or
say
oh
well,
I
think
they're
overstating
how
hard
this
is
or
like
you
want
to
take
your
users
and
people
are
giving
feedback.
You
want
to
take
them
seriously
when
I
really
listen
to
what
they're
telling
you
and
you
want
to
check
for
existing
sources.
A
One
of
the
nice
things
about
being
a
programmer
is
that
we
like
to
ask
our
questions
in
the
public
we
put
stuff
on
Stack
Overflow,
and
that
provides
actually
a
really
nice
place
where
you
can
go
and
say
hey.
What
are
people
asking?
What
are
people
having
trouble
with,
and
in
this
particular
case,
the
stuff
we
found
on
Stack
Overflow
was
pretty
much
the
in
line
with
what
we
were
getting
from
the
direct
feedback,
but
it
provided
more
confidence
in
ok.
A
We
need
we're
addressing
the
right
stuff
and
it
did
fill
out
a
couple
of
things
that
hadn't
been
caught
in
the
sort
of
survey.
So
you
know
if
you
have
pre-existing
materials
that
tell
you
what
things
people
are
having
issues
with
what
questions
people
are
having
go.
Look
at
them,
make
sure
that
you're
actually
answering
the
questions
that
people
have
already
shared.
So
the
next
part-
and
this
is
really
the
the
hardest
part-
is
the
first
draft.
A
It's
just
going
from
a
blank
screen
or
a
blank
piece
of
paper
to
something
this
part
for
me
took
me
about
a
month
that
was
like
just
working.
My
free
time
took
me
about
a
month
on
about
initially
a
hundred
questions,
and
it's
just
tough,
because
there's
that
you
have
this
sort
of
pressure
to
get
it
right,
the
first
time.
This
sort
of
you
need
to
have
all
that.
A
The
perfect
framing
the
perfect
contextualization,
the
best
examples
and
explanations,
and
you
get
sort
of
paralyzed,
because
you
don't
you
don't
know
how
to
how
to
just
get
that
right
away,
and
so
the
first
thing
to
really
remember
you
don't
need
to
know
everything.
I
didn't
I
wrote
answers
that
were
wrong.
I
wrote
answers
that
were
incomplete,
weird
answers
that
were
just
bad,
but
I
wrote
answers
and
then
people
could
come
in
and
give
feedback
and
say
hey.
This
is
this
is
bad.
This
is
wrong.
A
This
is
whatever,
and
so
I
ended
up
learning
a
lot.
I
became
I
think
a
better
Russ
programmer
from
writing.
The
frequently
asked
questions
page
because
people
came
in
and
told
me
when
I've
gotten
something
wrong
or
right.
You
know
didn't
know
something
and
just
being
able
to
say:
hey,
I,
don't
know
something,
but
I'm
gonna
write
anyway,
is
is
really
important.
Just
cuz
once
you
have
a
starting
point,
it
gets
a
lot
easier
and
it's
okay
to
write
poorly
we're
human.
Sometimes
we
just
don't
words
good
it
just
doesn't
people.
A
You
know
you
can't
be
expected
to
get
all
of
the
wording.
Right
have
the
perfect
sentences
that
are
crystal
clear.
Everything
needs
revision.
It
is
the
very
rare
person
who
doesn't
need
to
edit
something
that
they've
written
so
I
think
letting
go
of
this
idea
that
you
have
to
get
it
right.
The
first
time
make
sure
all
your
grammar
is
right
and
sort
of
free
out
of
it
before
you
show
it
to
anyone.
A
It's
when
there's
something
to
to
take
a
stance
against
or
to
take
a
stance
in
favor
of
like
it
becomes
a
lot
easier
than
just
sort
of
inventing
something
from
whole
cloth,
and
then
you
get
to
move
on
to
the
next
stage,
which
is
the
longest
stage,
refinement
or
editing,
taking
that
terrible,
probably
thing
that
you've
written
and
making
it
not
terrible.
So
for
me,
the
initial
stage
took
about
two
months.
The
the
refinement
stage
took
about
three
months
working.
It
was
a
good
part
time,
so
it
wasn't
a
job.
A
First
thing,
don't
fear
the
Delete
key.
It
can
be
easy
once
you've
spent
a
lot
of
time
on
something
to
feel
really
attached
to
it
and
not
like
what
not
want
to
give
it
up.
This
is.
This
is
gonna
make
the
end
product
worse.
If
people
are
telling
you
that
something
isn't
clear,
something
doesn't
work,
listen
to
them.
You
need
to
you
know
it.
You
can't
be
completely
attached
to
the
things
you've
written
or
like
have
some
sort
of
sense
of
of
self-worth
tied
up
in
these
things
and
I'll,
say
it's
easier
said
than
done.
A
It's
easy
when
you've
spent
a
lot
of
time
in
something
to
get
defensive
when
people
come
and
critique
it
and
letting
go
with.
That
is
a
really
valuable
thing
and
next
get
outside
opinions.
Working
on
the
frequently
asked
questions
page,
we
had
a
ton
of
people
who
came
in
and
and
gave
really
really
thorough
feedback.
A
People
are
giving
you
to
really
consider
it
deeply
and
respect
that
people
are
coming
from
different
perspectives
and
different
circumstances
than
you.
So
like
I,
remember
one
of
the
answers.
I'd
use
some
wording
or
a
particular
word
that
was
apparently
difficult
for
people
who,
for
whom
English
wasn't
their
first
language,
and
this
was
obvious
for
something
I've
never
considered
English
as
my
first
language
I,
don't
speak,
anything
else
and
writing
it
was
just
like.
Yes,
this
seems
like
the
right
word
to
use,
but
then
people
come
up
in
a
like.
What
does
this
mean?
A
What
are
you
saying
here
and
really
listening
to
them
and
saying
okay?
Well,
how
can
we
phrase
this
in
a
way
that
will
be
clearer
to
a
broader
range
of
people
is
important,
so
in
the
end
it
took
about
four
months.
Four
hundred
and
sixteen
comments,
forty-two
commits
and
twenty-nine
participants-
and
that
was
all
by
the
way,
just
for
the
the
first
first
version.
It
never
been
changes
and
improvements.
Since
then,
we've
added
more
questions
and
more
answers,
updated
answers.
A
There
are
some
answers
right
now
that
need
need
fixing
I
know,
there's
an
answer
on
higher
kind
of
types
that
is
not
great
and
needs
improvement
that
and
I
there
others
just
you
know
the
things
I
can
always
be
improved.
You
get
more
feedback
from
people.
This
is
really
a
ride.
Getting
good
documentation
is
a
continuous
process
like
it
doesn't
stop.
When
you
publish
to
the
thing
and
you're
like
okay
I'm,
you
want
to
keep
getting
that
feedback.
You
want
to
keep
collaborating
the
people
when
they
come
up
with
some
new
way
of
phrasing.
A
Some
some
new
idea
to
really
incorporate
that
and
make
sure
that
your
documentation
is
the
best
that
it
can
possibly
be
good.
Doc's
require
empathy,
they
require
collaboration,
they
require
time
and
they
don't
happen
on
accident
and
I.
Think
that
this
is
just
important
to
remember
that
your
your
documentation
isn't
just
gonna
suddenly
get
what
get
good
without
some
real
effort
and
attention
and
time
given
to
it.
It's
it.
You
really
have
to
to
want
good
Doc's
for
them
to
happen.
A
So,
given
all
this,
I
want
to
talk
a
little
bit
about
where
documentation
is
right
now
in
the
the
rust
ecosystem.
So
first,
the
the
rust
ecosystem
is
is
quite
big.
Now,
as
of
Monday,
when
I
made
this
slide,
there
are
six
thousand
six
hundred
and
thirty
nine
crates
and
79
million
seven
hundred
and
seventy
1988
downloads.
So
this
is
awesome.
A
It's
super
cool
to
see
this
many
crates
to
see
that
a
little
over
a
year,
past
1.0
the
the
ecosystem
keeps
growing,
and
for
this
basically
looked
at
the
the
number
of
like
how
the
docks
are
for
the
top
100
crates,
we've
done
more,
but
because
this
was
a
sort
of
a
manual
process.
There
was
only
so
many
crates.
I
was
willing
to
go
and
check
the
docks
for
so
looking
at
the
top
100
crates.
Basically,
no
docks
provided
means
that
there's
either
no
links
to
documentation
or
that
the
link
that's
given
is
broken.
A
I
think
there
was
only
one
broken
link,
the
other
ones
just
just
weren't
there.
Poor
quality
means
that
there
there
may
be
like
a
couple
of
dot
comments,
but
it's
for
the
most
part,
there's
really
not
much.
Almost
everything
is
undocumented.
Fair
quality
is
maybe
you've
got
like
half
of
your
stuff,
that's
covered
by
dot
comments,
but
there
are
large
portions
of
the
API
that
aren't
documented
and
then
good
quality
is
that
everything's
got
documentation
and
all
of
us
by
the
way
is
looking
just
at
the
documentation.
A
That's
linked
from
crates
do
once
again,
just
like
a
time
of
thing:
I
couldn't
go
in
and
do
like
a
deep
dive
with
all
100
of
the
top
crates,
and
you
know
what
this
is.
This
is
pretty
good.
We've
got
roughly
half
of
the
the
top
100
crates
that
really
have
quality
documentation.
This
is
looking
at
crates
like
regex,
has
really
good
documentation,
lazy,
static,
byte
order
things
that
just
are
clear.
Documentation
says
exactly
what
how
to
use
this
thing.
A
What
all
the
different
parts
are,
how
they
work
and
that's
it's
really
exciting,
but
there
is
room
for
improvement,
not
not
just
in
the
the
API
Docs,
not
just
in
the
docs,
linked
from
from
crates
of
I/o,
but
in
the
rest
of
the
sort
of
docs
portfolio.
That
was
talking
about
earlier,
making
sure
that
the
the
readme
is
clear,
making
sure
that
there's
some
sort
of
walkthrough
first
lots
of
the
docs
are
incomplete.
A
Like
I
said,
there
are
some
of
these
poor
quality
and
quality
docs
that
don't
have
complete
documentation
coverage
of
their
API
things
that
just
could
use
some
more
love,
and
then
you
have
Docs
that
that
don't
explain
enough,
maybe
they
they
have
comments
but
they're
sort
of
not
not
helpful.
The
funny
is
one
I've
seen
and
I.
A
Everyone,
the
foundation,
is
already
laid.
One
thing
that
I
really
appreciate
in
rust
is
one
of
the
things
that
I
I
personally
love
about
the
Russ
community
is
that
people
actually
care
about
documentation.
I
have
seen
other
programming
communities
where
it's
it
seems
to
be
less
of
a
of
a
focus,
at
least
in
like
the
sort
of
core
language
level,
and
that
can
be
really
frustrating
as
a
user,
but
the
the
rust
team
clearly
I
think
cares
about
documentation.
There's
been
all
the
work
on
the
rust
book
and
the
new
edition
of
the
rust
book.
A
It
is
nice
to
know
that
as
a
community
we
seem
to
care
about
documentation
and
Russ
doc
is,
is
super
cool
and
getting
better?
It
is
just
wonderfully
nice
to
have
something
that
is
sort
of
standard.
Everyone
uses
comes
with
the
language
integrates
with
everything
nicely,
and
it's
just
it's.
It's
a
good
tool.
A
I,
don't
know
about
you
guys,
but
I've
been
very
happy
in
my
experiences
using
Russ
doc
and
then
I'm
happy
to
know
that
they're
things
now
like
doc
start
RS
exist
where
it's
very
easy
to
get
the
the
current
documentation
for
four
different
crates,
and
it
would
be
it's
just
it'll
be
nice
to
see
this
system
continue
to
improve
as
improvements
come
to
Russ
doc.
So
at
this
point
it's
really
a
question
of
focus
and
planning
making
sure
that
we're
actually
giving
our
attention
to
documentation
that
libraries
are
deciding
hey.
A
So
question
now
is:
where
do
we
go
from
here
like
what
are
the
actual
substantive
next
steps
to
improve
a
documentation
from
where
it
is
right
now
and
I
think
the
answer
is
different,
depending
on
your
sort
of
role
in
the
ecosystem.
So
if
you're
a
great
developer,
I
think
the
first
thing
is
to
review
your
current
Doc's
portfolio.
What
do
you
have?
What
do
you
not
have?
A
A
Your
library,
more
and
I
think
that
offering
mentored
issues
on
documentation
where
you
can
sort
of
pair
with
with
someone
who
knows
the
internals
but
maybe
doesn't
want
to
devote
all
of
the
time
and
resources
to
actually
writing
it,
and
so
you
get
this
nice
sort
of
supportive
relationship.
We
have
someone
that
wants
to
to
get
into
writing
documentation
with
this
thing
it
wants
to
get
into
the
library
and
can
can
get
knowledge
from
the
more
skilled
person
who
then
doesn't
have
to
devote
quite
as
much
time
and
attention
into
writing.
A
A
You
know
with
with
respect
and
group
of
professionalism,
and
then
next
can
consider
doing
doc
days
or
doc.
Sprints
sort
of
a
you
know
short
little
period
where
you
really
focus
contribution
to
say:
hey
everyone,
we're
gonna,
we're
gonna
work
on
documentation
and
then
get
people
together
to
to
make
it
happen.
It's
it's
nice
to
think
just
because
it.
What
do
you
have
everyone
focused
on
it?
You
can
get
a
lot
more
done
than
when
everyone's
sort
of
haphazardly
coming
at
it.
A
There
can
be
I
think
a
really
valuable
way
to
do
direct
and
focus
the
work.
Now,
if
you
are
a
great
user
that
there
also
a
variety
of
things,
you
can
do
first
report
Doc's
issues
when
you
have
them.
It's
really
easy
like
when
you've
come
to
a
library
and
the
documentation
is
missing
or
something
is
not
clear
to
just
say:
okay,
well,
I'm
I'm
not
going
to
I'm
just
gonna
leave
I'm
not
gonna,
participate
this
anymore,
and
that
is
certainly
fine
for
the
the
crate
user.
A
But
then
it
creates
this
problem
where
the
the
crate
maintainer
may
not.
You
know
they
don't
know
that
you
look
at
this
thing
and
then
left
because
of
a
particular
reason
they
don't
hear
about.
You
know.
Why
did
you
leave,
and
so
it's
easy,
then
for
the
maintainer
to
miss
out
on
important
stuff
that
they're
doing
wrong.
A
That's
causing
people
to
leave
or
to
not
start
and
so
I
think,
just
if
there's
a
problem,
if
you
find
something,
that's
unclear,
that's
missing
just
say
so:
just
open
up
an
issue
and
say:
hey
I,
don't
know
that
I'm
gonna
use
this
thing,
but
I
found
this
particular
issue,
and
this
is
kind
of
a
blocker
for
me.
I,
don't
really
understand,
what's
happening
here
and
then
that
that
really
helps
the
the
crate
maintainer
to
understand
whether
deficiencies
are
and
focus
their
work
better
next
to
participate
in
Doc's
discussions.
A
So
you
don't
even
have
to
do
much,
it's
just
sort
of
showing
up
and
giving
feedback
whether
it's
feedback
on
on
the
language
that's
been
used,
so
making
sure
that
the
wording
is
clear.
Like
the
people
who
told
me
that
my
I
used
some
wording
that
wasn't
clear
for
people
who
didn't
have
English
as
a
first
language,
that
was
really
valuable
and
that
was
stuff
that
I
never
would
have
gotten
on
my
own
and
so
participating
in
these
discussions.
A
Providing
the
unique
sort
of
perspective
from
people
with
the
wide
variety
of
technical
backgrounds
and
personal
backgrounds
is
really
valuable
and
then,
finally,
in
this
probably
the
most
obvious
one
contribute
to
the
docs.
If
something
is
unclear-
and
you
understand
it
write
an
explanation-
and
this
is-
is
a
really
valuable
way
and
maybe
look
for
some
mentored
issues.
Yes,
do
that
so
I
think
there's
a
lot
of
things
that
can
be
done
to
improve
the
Blair
documentation
is
right
now
and
then
for
for
everyone.
A
A
Yeah,
that's
definitely
a
good
idea
and
I
know
that
I've
seen
Doc's
that
do
stuff
like
that,
where
you'll
have
a
sort
of
a
quick,
easy
way
to
go
straight
from
the
documentation
to
opening
an
issue.
I
think
that's
a
good
idea.
I
think
lowering
the
sort
of
barrier
to
giving
that
feedback
makes
more
people
make,
makes
people
more
likely
to
give
that
feedback.
A
A
A
A
A
A
Yeah,
oh
I
should
I
should
explain
the
term
meet-cute,
for
anyone
is
unfamiliar.
The
meet-cute
is
a
term
that
comes
from
film.
It's
the
name
for
sort
of
the
scene
where,
like
like
two
characters,
happened
like
who's
gonna,
have
some
sort
of
romantic
interest
first
meet
you
calmly,
see
it
and
like
romantic,
comedies
and
stuff.
So
it's
that
first
scene,
where
two
characters
meet.
A
A
It
sure
I
use
asking
is
the
the
rust
ecosystem,
largely
English,
centered
and
I
would
say:
I
haven't
looked
at
the
whole
thing,
but
yes,
I
would
I
believe
so,
and
that's
another
thing
I
think
to
to
think
about
is
the
possibility
of
providing
documentation
in
in
other
languages,
although
obviously
often
there
you're
gonna
be
relying
on
other
people,
I
need
to
find
people
essentially
who
are
willing
to
contribute
translations.
I
know.
A
A
Yes,
yes,
for
anyone,
who's
not
familiar,
you
can
use
a
attribute
on
your
crate
to
cause
a
build
to
fail
if
you
are
missing
documentation
on
your
public
API
now.
Obviously,
this
can't
check
that
the
documentation
is
good.
It
could
just
check
that
it's
there,
but
but
that's
it.
That's
at
least
a
really
solid
starting
point,
and
it's
something
I
think
that
everyone
should
do
yes,.