This is tricky because sometimes there are multiple crates that solve a given problem, and we need to“choose a winner”
What is our cadence for updating this set, and the examples?
Principles
First and foremost, the goal is to be useful to programmers trying to get work done
That means being“comprehensive” is a non-goal; if we overwhelm people with options, we haven’t given them the help they need
A secondary, and very important, goal is to provide a sense of an“extended standard library”
std is very minimal, compared to other languages
The cookbook is how we envision presenting a“batteries included” story for Rust
The cookbook needs to be“trusted”
Crates need to be high quality, maintained, stable
If we want people to treat this like an extended std, that sets a very high bar
Proposal
Criteria
Problem being solved must be common/representative within a domain
Crate should be relatively stable(ideally post-1.0) and must be well-maintained
Crate should be ranked“high” in recent downloads within its category
Crate should be of high quality; ideally it would pass a libs team evaluation easily
In general, we should avoid referencing multiple crates with very similar functionality(see principles above). This is where the“picking a winner” part comes into play.
Oversight
Dedicated group of cookbook maintainers(who should be libs team“peers”)
These maintainers handle day-to-day concerns of reviewing particular recipes and making decisions about crates that are relatively clear-cut
In tricky cases, libs team can help weigh in. Should also have check-ins with the full libs team on some cadence.
Selection/update process
During initial development, the cookbook has been very crate-focused(due to being fed by the Blitz)
We need to make sure we are also problem-focused(go back to the first principle above!)
Questions
Principles
Proposal
Criteria
Oversight
Selection/update process