|
| 1 | +# Summary |
| 2 | +[summary]: #summary |
| 3 | + |
| 4 | +This RFC proposes establishing a new repository for a web page advertising |
| 5 | +noteworthy embedded Rust projects. This new resource would go beyond the |
| 6 | +existing [awesome-embedded-rust] list by allowing long form |
| 7 | +descriptions, photographs, and videos to best demonstrate the projects. |
| 8 | + |
| 9 | +[awesome-embedded-rust]: https://github.com/rust-embedded/awesome-embedded-rust |
| 10 | + |
| 11 | +# Motivation |
| 12 | +[motivation]: #motivation |
| 13 | + |
| 14 | +We would like a well-presented list of interesting embedded projects using Rust |
| 15 | +to advertise Rust's abilities in this domain. Existing lists are mainly |
| 16 | +targeted at embedded Rust developers looking for libraries; this list would |
| 17 | +instead be advertising the final projects people have accomplished with Rust, |
| 18 | +and so should appeal to potential users who are not already embedded Rust |
| 19 | +developers. |
| 20 | + |
| 21 | +The main embedded Rust website will contain a shortlist of especially notable |
| 22 | +projects, but is aimed at presenting a very high-level overview to all users |
| 23 | +including non-technical users. This proposed list would be able to present more |
| 24 | +projects in more detail, and will require that their source code is publicly |
| 25 | +available so embedded developers interested in Rust can inspect it. |
| 26 | + |
| 27 | +# Detailed design |
| 28 | +[design]: #detailed-design |
| 29 | + |
| 30 | +## New Repository |
| 31 | + |
| 32 | +We create a new repository, `showcase` (TBC), in the |
| 33 | +rust-embedded organisation and under the existing Resources team. It will use |
| 34 | +the same underlying technology as the upcoming embedded Rust website to render |
| 35 | +Markdown to a web page. |
| 36 | + |
| 37 | +## New Web Page |
| 38 | + |
| 39 | +The new web page would live at https://showcase.rust-embedded.org (TBC). |
| 40 | + |
| 41 | +Each project is listed with a photograph/GIF/video, description, and other |
| 42 | +details (see Submission section). |
| 43 | + |
| 44 | +Additionally, each project has a badge indicating whether it builds on stable |
| 45 | +Rust or requires a nightly compiler. |
| 46 | + |
| 47 | +## Project Requirements |
| 48 | + |
| 49 | +To be considered for inclusion, projects must: |
| 50 | + |
| 51 | +* Involve embedded Rust, in other words, use Rust and run on embedded hardware |
| 52 | + |
| 53 | +* Have publicly available source code |
| 54 | + |
| 55 | +The objective of this list is to showcase Rust code in action; we can't do this |
| 56 | +if people can't read the code! There might be space on the main Embedded Rust |
| 57 | +website to showcase projects known to use Rust but without public code. We |
| 58 | +don't require any specific license; just that it's available for interested |
| 59 | +users to read. |
| 60 | + |
| 61 | +* Have working CI builds |
| 62 | + |
| 63 | +Since we want people to be able to learn from the code, we require it at least |
| 64 | +builds successfully. Working CI also shows what versions of Rust it builds on, |
| 65 | +which is useful to establish if a project works on stable Rust. |
| 66 | + |
| 67 | +* Have build instructions |
| 68 | + |
| 69 | +These might be as simple as `cargo build` or might document any specific |
| 70 | +Rust versions, build oddities, or other steps required to produce the |
| 71 | +final firmware. Projects could also document their physical build, for example |
| 72 | +whether a particular development board was used, or what custom hardware is |
| 73 | +present, but this is not required. |
| 74 | + |
| 75 | +* Have at least one photograph/video/GIF of the project in action |
| 76 | + |
| 77 | +## Project Submission |
| 78 | + |
| 79 | +Projects are submitted by their authors via pull requests. Submissions must |
| 80 | +contain the following information: |
| 81 | + |
| 82 | +* Project name |
| 83 | +* Author name |
| 84 | +* Project website/repository |
| 85 | +* Project description |
| 86 | +* Images, GIFs, or video of the project |
| 87 | +* Whether or not the project builds on stable Rust |
| 88 | + |
| 89 | +After a project is submitted, the resources team will review the PR, possibly |
| 90 | +consulting the other teams when relevant. Approval can then be granted by any |
| 91 | +of the resources team members. |
| 92 | + |
| 93 | +# Alternatives |
| 94 | + |
| 95 | +* Instead of badges for builds-on-stable projects, the nightly-only projects |
| 96 | + could be binned together at the bottom of the page. |
| 97 | +* The web page could instead be maintained as part of the main embedded-rust |
| 98 | + website, existing as a page in that website. |
| 99 | +* We could extend awesome-embedded-rust to permit longer descriptions of |
| 100 | + projects. |
| 101 | +* We could integrate this concept into the existing awesome-embedded-rust |
| 102 | + repository, but still render the projects to a web page. |
| 103 | + |
| 104 | +# Unresolved Questions |
| 105 | +[unresolved]: #unresolved |
| 106 | + |
| 107 | +* Final name for repository/web page |
0 commit comments