5 ms·

From the outside looking in, I am mostly impressed with the governance structure of the whole endeavor. It seems to me that it is a great model for other open s

From the outside looking in, I am mostly impressed with the governance structure of the whole endeavor. It seems to me that it is a great model for other open source projects. Edit: as someone involved with other, less mature (and less ambitious) open source projects, if you know of pain points in the governance of rust, i'd be interested in learning about them.

warnhardcode 12y ago
I have only the vague understanding that there are governance structures in place for open source projects. Can you go into a little detail about what aspects of this project's governance impress you?
- netcraft 12y ago
  aturon's response below (https://news.ycombinator.com/item?id=9046882 https://news.ycombinator.com/item?id=9046882) outlines most of what I would say - really its the RFC process that I'm most interested with and how that is managed in an open way. There are always pet ideas and desires that complicate processes like this - the volume of RFC's the project has dealt with is impressive with no major community rifts that I have heard of. This page talks about the process and their code of conduct: https://github.com/rust-lang/rust/wiki/Note-development-policy https://github.com/rust-lang/rust/wiki/Note-development-poli...
  - steveklabnik 12y ago
    Oh, since you quoted that page, you might want to know about this PR: https://github.com/rust-lang/rust/pull/22282 https://github.com/rust-lang/rust/pull/22282
codys 12y ago
There's a governance structure? That's news to me. I was under the impression that a few primary contributors (mostly/all mozilla employees?) are gatekeepers to merging anything. Having an "RFC" issue tracker isn't the same as having a governance structure. Edit: I suppose you could call the above a 'governance structure', but I'm having a hard time seeing anything impressive/different about it from other open source projects
- aturon 12y ago
  There's a core team (https://github.com/rust-lang/rust/wiki/Note-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 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 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.
- Gankro 12y ago
  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 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).
  - dbaupp 12y ago
    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).
    - Gankro 12y ago
      Huh. I thought it was basically a bijection, though?

warnhardcode 12y ago

I have only the vague understanding that there are governance structures in place for open source projects. Can you go into a little detail about what aspects of this project's governance impress you?

netcraft 12y ago
aturon's response below (https://news.ycombinator.com/item?id=9046882 https://news.ycombinator.com/item?id=9046882) outlines most of what I would say - really its the RFC process that I'm most interested with and how that is managed in an open way. There are always pet ideas and desires that complicate processes like this - the volume of RFC's the project has dealt with is impressive with no major community rifts that I have heard of. This page talks about the process and their code of conduct: https://github.com/rust-lang/rust/wiki/Note-development-policy https://github.com/rust-lang/rust/wiki/Note-development-poli...
- steveklabnik 12y ago
  Oh, since you quoted that page, you might want to know about this PR: https://github.com/rust-lang/rust/pull/22282 https://github.com/rust-lang/rust/pull/22282

codys 12y ago

There's a governance structure? That's news to me. I was under the impression that a few primary contributors (mostly/all mozilla employees?) are gatekeepers to merging anything. Having an "RFC" issue tracker isn't the same as having a governance structure. Edit: I suppose you could call the above a 'governance structure', but I'm having a hard time seeing anything impressive/different about it from other open source projects

aturon 12y ago
There's a core team (https://github.com/rust-lang/rust/wiki/Note-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 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 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.
Gankro 12y ago
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 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).
- dbaupp 12y ago
  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).
  - Gankro 12y ago
    Huh. I thought it was basically a bijection, though?