There's a core team (https://github.com/rust-lang/rust/wiki/Note-core-team) responsible for final decisions on the direction of the language and libraries. Proposed changes go through a public RFC process (https://github.com/rust-lang/rfcs#what-the-process-is), including those proposed by members of the core team -- which are frequently revised or even rejected as part of this process. See for example the path API RFC (https://github.com/rust-lang/rfcs/pull/474).

PRs can be reviewed by anyone from a large pool of reviewers. PRs that introduce new features etc. have to come after an RFC is approved, however.

The core team includes Huon Wilson, Yehuda Katz, and Steve Klabnik, none of whom work for Mozilla (though the latter two have done some contracting work). We hope to continue expanding to include other stakeholders.

EDIT: Steve tells me he's currently working as a "seasonal employee" at Mozilla for doing Rust docs, but it's a short term thing.

In addition to what aturon said, for actual patches these are the people who decide on merging: https://github.com/orgs/rust-lang/teams/rust-push

Maybe a third to a half are Mozilla employees (although it's infamously hard to tell who actually works at Mozilla and is just weirdly into maintaining Rust).

FWIW, the Rust-push team doesn't match the set of reviewers (people to which the integration bot bors will react and merge a PR). Being on that list offers powers like issue tagging and the ability to push to the 'try' branch, but manually merging a PR or pushing straight to master is essentially banned (and would be reverted immediately).

Huh. I thought it was basically a bijection, though?

There is an injection from the set of reviews to the rust-push team (Or, at least, there should be), but e.g. people have got privs because they've been doing a lot of triage or need try push, without having review powers.