# The issue tracker that governs the embedded Rust ecosystem

> rust-embedded/wg is a coordination repository rather than a library: an issue tracker, numbered RFCs, weekly meeting minutes and a Matrix call, where a two-person core team holds the casting vote on decisions nobody else can settle.

**rust-embedded/wg** — Coordination repository of the embedded devices Working Group

- Repository: https://github.com/rust-embedded/wg
- Stars: 2,153 · Forks: 116
- Language: Unknown
- License: not declared
- Published: 2026-10-14 · Updated: 2026-10-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/rust-embedded-wg

## An issue tracker standing in for a whole ecosystem

The opening line of the README calls this a coordination repository, and the next one explains what that means in practice: the issue tracker here is used by the embedded Working Group to coordinate efforts towards making Rust a good choice for embedded development. There is no library to depend on, no binary to install, no build step. The content is process: numbered RFCs, a record of weekly meetings, project tracking files, community surveys and a pair of document templates.

It is written for three overlapping audiences. Contributors who want a change to a core crate need the RFC route rather than a pull request. Teams already shipping firmware need the roster that tells them who owns which crate. Newcomers get the entry points the README hands over: the embedded Rust book at `docs.rust-embedded.org/book`, the wider bookshelf at `docs.rust-embedded.org`, a newsletter hosted at `rust-embedded.github.io/blog`, and the Matrix room `#rust-embedded:matrix.org`.

## Four stated outcomes and two parallel work tracks

The vision section names 4 broad goals. Improve the absolute quality of embedded software in the wild, which it unpacks as functionality, safety and performance. Improve the productivity of embedded development teams by cutting the tangible and intangible costs of reaching a given quality level. Improve the experience for the programmers doing the work. And make embedded systems programming accessible to people who are not already embedded developers.

Work then runs on two tracks. One is community work on the ecosystem: maintaining and developing core crates so the roadmap matches what users need, curating resources, and moderating the venues the community uses, which are this repository and the Matrix room. The other is representation, since the group acts as a bridge between the Rust teams and the embedded community and carries requests such as language features and `core` API stabilization upstream.

That second track sets a boundary worth naming plainly. Language and standard library changes are decided elsewhere, so anything in that category follows upstream scheduling rather than this group's own cadence.

## RFC threads decide, and the search runs across the whole organisation

The change path is spelled out in the help section. A proposal goes through an RFC, defined there as 'a discussion thread (which may or may not be backed by a proper RFC document) where we evaluate the pros and cons of a proposal and explore alternatives'. Consensus on accepting a proposal is what makes it effective, and the same paragraph says this route covers landing major breaking changes in core crates, not merely how the group is run. Breaking a published interface therefore takes a thread with consensus behind it, which is a slower path than opening a pull request.

The doorway to those threads is an organisation-wide search rather than an index of local files, even though an rfcs directory sits at the top level of this repository:

```
https://github.com/search?q=org%3Arust-embedded+is%3Aopen+label%3Arfc&type=Issues
```

Team functions are defined in RFC 0136, referenced locally as `./rfcs/0136-teams.md`, and the same document carries the section on adding new members that anyone seeking to join is directed to. That single file is the group's constitution, which is why the next section looks at how it is linked.

## Two names hold the casting vote when no majority forms

The core team carries 4 functions: represent the Working Group in meetings with other Rust teams, communicate the embedded community's needs to those teams, give the casting vote on intra-WG decisions where no voting majority can be achieved, and drive and moderate the weekly meetings. The member list under that team holds two names, `@adamgreig` and `@therealprof`.

A close reading of the next section turns up something the rosters never state. Both of those names also sit on the Arm team roster, so the two people who break ties inside the group come from the Arm side of the organisation rather than from a pool of their own. No line of the file explains that arrangement.

The tie-break rule is defined in the same RFC 0136, yet the link for voting majority resolves to `github.com/rust-lang-nursery/embedded-wg/blob/master/rfcs/0136-teams.md`, a repository under a different organisation path, while the document itself is referenced locally. Anyone relying on the casting vote has to settle which copy is current before treating it as a rule.

## The Arm roster names twelve crates and one rename

The Arm team covers crates for Arm microprocessors and microcontrollers, naming Cortex-A, Cortex-R and Cortex-M explicitly, and its project list runs to twelve entries: `aarch64-cpu`, `arm-dcc`, `aarch32-cpu`, `aarch32-rt`, `cortex-m-rt`, `cortex-m-semihosting`, `cortex-m`, `itm`, `panic-dcc`, `panic-itm`, `panic-semihosting` and `rust-raspberrypi-OS-tutorials`. The member list underneath matches it exactly, twelve handles for twelve projects.

Two entries reward attention. Only one records a rename, `aarch32-cpu` marked as having been `cortex-ar` before, which tells you a dependency name can change without the project moving anywhere. And three of the twelve are panic strategies rather than peripheral drivers, `panic-dcc`, `panic-itm` and `panic-semihosting`, so choosing a panic path is a decision separate from choosing a runtime crate.

One member line breaks the pattern of plain handles. `@davidtwco` is listed as representing `@rust-lang/arm-maintainers`, the clearest sign in the file that the Arm team answers to an upstream group as well as to itself.

## Two GPIO backends stay on the roster at the same time

The embedded Linux team has 5 members, `@eldruin`, `@nastevens`, `@ryankurte`, `@sirhcel` and `@jannic`, and its stated job is the core of the embedded Linux crate ecosystem. Its project list names 7 crates, `gpio-cdev`, `gpio-utils`, `i2cdev`, `linux-embedded-hal`, `meta-rust-bin`, `spidev` and `sysfs-gpio`, then stops on an eighth entry cut off mid-name.

What the listing does show is a transition held open rather than closed. `sysfs-gpio` and `gpio-cdev` cover the same job through two different kernel interfaces, and both remain on the roster, so neither path has been abandoned. `gpio-utils` sits alongside them as userland help, `linux-embedded-hal` carries the naming that ties the crate set together, and `meta-rust-bin` is the single entry whose name says nothing about a device interface at all.

Taken together, the names point at a kernel interface version split. The character device crate and the sysfs crate cannot cover the same board, and the team carries both rather than asking adopters to pick a side, which pushes the compatibility decision onto the code that calls them.

The cut-off line is the part that matters for anyone auditing ownership, because the README alone cannot produce a complete inventory of who maintains embedded Linux support.

## Eleven top-level entries, and no build files among them

The repository tree is the quickest way to see what kind of project this is, and all eleven top-level entries fit on one screen:

```
.github/
0000-project-template.md
0000-template.md
CODE_OF_CONDUCT.md
README.md
assets/
minutes/
ops/
projects/
rfcs/
surveys/
```

Two of them are templates named `0000-project-template.md` and `0000-template.md`, and that prefix matches the numbering used for RFCs such as 0136. Documents here are numbered rather than titled, which makes a governance rule citable by number in a thread. `minutes/` holds the weekly meeting record, `surveys/` the periodic community surveys, `projects/` the project tracking files, `ops/` the operational documents, and `assets/` the 256 by 256 PNG logo the README embeds at the top.

What the tree lacks is as informative as what it holds. There is no Cargo manifest, no build configuration outside `.github/`, and no documentation directory. The learning material the README promotes lives at a separate site, not in this repository.

Upgrading here means watching a thread rather than pulling a new tag. The last push landed on 2026-09-27 and the repository publishes no GitHub releases, so the record of what changed lives in the issue tracker and the meeting minutes. No licence identifier is declared for the coordination repository either, which is worth settling before you copy governance text from it into your own project documentation.

## Joining costs a conversation on Matrix, not a dependency

Four documented routes in, none of them involving an install. Report a gap in the language, compiler, tooling, documentation or crate ecosystem through the issue tracker, and the group says it will either raise it with the Rust teams or organise the community to build what is missing. Take part in an RFC thread. Pick up an issue labelled help wanted, which the README says covers bugs, features, tests, examples, tutorials, documentation and typo fixes, and which may need neither previous embedded experience nor access to hardware:

```
https://github.com/search?q=org%3Arust-embedded+is%3Aopen+label%3A%22help+wanted%22&type=Issues
```

Alternatively, attend the weekly meeting on Matrix. It runs on Tuesdays at 8pm CET/CEST, the agenda is posted in the channel in advance, and anyone can nominate an existing GitHub thread for synchronous discussion, which the README calls a faster alternative to the RFC threads. For sustained involvement the route runs through the teams, either by becoming a project collaborator after consulting the owning team, or by joining the team itself through the adding new members section of RFC 0136.

For a maintainer that is the whole value proposition. The rosters tell you who to ask, and the Matrix room tends to answer sooner than a thread does.

## Conclusion

This is a process repository, not a dependency, and it pays off only if you plan to shape the roadmap or track the crates your firmware already pulls in. Teams writing Rust for Cortex-M, other Arm cores or embedded Linux get the most from it, because the Arm and embedded Linux rosters name the maintainers behind those crates. Teams that only need a working driver today will find nothing installable here and should read the crates' own repositories. Before relying on any governance rule, check which copy of RFC 0136 is current, and read the embedded Linux project list from its own repositories rather than the truncated README.

## FAQ

### Is rust-embedded/wg a crate I can add to my project?

No. It is a coordination repository holding numbered RFCs, weekly meeting minutes, project tracking files, surveys and a code of conduct, with no library code and nothing to declare as a dependency.

### How do I propose a change to a crate the embedded Working Group maintains?

Open an RFC thread, which the README defines as a discussion thread that may or may not be backed by a formal RFC document. A proposal becomes effective only after the group reaches consensus on accepting it, and this route covers major breaking changes in core crates.

### How do I join the embedded Working Group or contribute to one of its crates?

Consult the team that owns the project to become a project collaborator, or join a team following the adding new members section of RFC 0136. Some issues labelled help wanted need neither previous embedded experience nor access to hardware.

### When do the working group meetings happen and how do I attend?

They run on Tuesdays at 8pm CET/CEST on Matrix in #rust-embedded:matrix.org. The agenda is posted in the channel in advance and anyone is free to join and share their thoughts.

### Where should I start learning embedded Rust?

The README points to the embedded Rust book at docs.rust-embedded.org/book, the wider bookshelf at docs.rust-embedded.org, a newsletter at rust-embedded.github.io/blog, and the Matrix room for live discussion.

## Sources

- [Issues](https://github.com/rust-embedded/wg/issues)
- [README](https://github.com/rust-embedded/wg/blob/master/README.md)
- [rust-embedded/wg on GitHub](https://github.com/rust-embedded/wg)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rust-embedded-wg