Call for proposals for next Rust Doc Days crates!


Since the first Rust Doc Days went well, we the Rust Documentation Team have decided to do it again. The second Rust Doc Days will happen after RustConf, likely during the end of September. But before we can schedule the event, we need your help.

For the second Rust Doc Days, we want you to propose crates that need better documentation. This time we’d prefer to focus on community crates. We’ve already nominated serde, but we need your thoughts. Let us know by leaving a comment below.

If you want to read more about the first Rust Doc Days, you can read the original Rust Doc Days announcement and the Rust Doc Days follow up post.

Here you go!

Reminder: planning the next Rust Doc Days
What's everyone working on this week (34/2016)?





log - in particular it would be great for it to lead you to some actual logger implementations. I happen to know that env_logger is the standard, but that’s not indicated in the docs, and I don’t know any other loggers and don’t know how to find them.


nom looks like a really cool library. I have attempted to learn it a couple of times but it’s not that easy to start with because it’s mostly using macros. I think nom is missing a lot of simple examples or a beginners guide to explain the basics.




criterion. Though I’m not sure its implementation is stable enough yet.


I’ve been wanting to help with examples and guides for diesel, but haven’t found the time. I think it’d be an excellent choice for making more approachable.


The rotor ecosystem (rotor, rotor_stream, rotor_http etc)


serde, especially serde without codegen.


I second this. My biggest problem with it is that I have no idea which operators accept byte slices, which accept strings, which accept both and which accept both, but treat both as byte streams (which might or might not matter). For many operators the documentation simply does not say and it’s hard to say from the source as the types are often inferred and so not mentioned in code either.

It would be particularly nice to modify the examplesdoc tests to contain non-ascii characters in all places that work on strings and chars to demonstrate they are handled properly (from brief look at the code I suspect it would find some bugs, too)—or clear information that it works on bytes, not utf-8 sequences.


I second this. We could really use some help on that front. We’re pushing towards 1.0 happening around that time, so I think it’d be a great impact on the project.


I think it’d also be a good idea to work on something a little more official that needs love; Rust by Example was how I learned Rust, and I think it could continue to be a great resource for people :slight_smile:


Seconded rust-by-example. Great bite-sized pieces of work, important, needs love.




Has this been scheduled?


Diesel could still use some more guides, and I added this issue to keep track of items that need API docs: