|
| 1 | +# Evaluation guidelines |
| 2 | + |
| 3 | +These are the guidelines used by the Resources team to evaluate project |
| 4 | +submissions. |
| 5 | + |
| 6 | +## Hard requirements |
| 7 | + |
| 8 | +The project must fulfill these requirements or it will be rejected. |
| 9 | + |
| 10 | +- The main logic of the application must be written in Rust. |
| 11 | + |
| 12 | +- The source code must be public. Licensing terms are unimportant. |
| 13 | + |
| 14 | +## Bonus points |
| 15 | + |
| 16 | +> N.B. A project repository may contain more than one crate. In those cases, one |
| 17 | +> (binary) crate will be the application, and the other crates will be libraries |
| 18 | +> and / or tools. In the review consider only the crates that are compiled for |
| 19 | +> the target device. One of these crates will be the application ("application |
| 20 | +> code") and the rest will be libraries ("support code"). |
| 21 | +
|
| 22 | +Award points if |
| 23 | + |
| 24 | +- The project is unlike the projects currently on display. |
| 25 | + |
| 26 | +- The documentation includes instructions on how to build the program, or the |
| 27 | + firmware can be built with just `cargo build`. |
| 28 | + |
| 29 | +- The repository has a CI setup. |
| 30 | + |
| 31 | +- The application compiles on stable. |
| 32 | + |
| 33 | +- The application code is free from `unsafe` code and all `unsafe` code has been |
| 34 | + pushed to libraries that only expose a safe API. |
| 35 | + |
| 36 | +- Code that's not target specific, if any, has unit tests. |
| 37 | + |
| 38 | +- Support code, if any, is documented. |
| 39 | + |
| 40 | +## Penalties |
| 41 | + |
| 42 | +Subtract points if |
| 43 | + |
| 44 | +- The application contains potential soundness issues. For example, using |
| 45 | + `mem::transmute`, unchecked creation of singletons and unchecked use of |
| 46 | + `static mut` variables are huge red flags. |
| 47 | + |
| 48 | +- Explicit panicking (e.g. `unwrap`) is used instead of proper error handling. |
| 49 | + However, note that `unreachable!` is OK if properly used. |
0 commit comments