Gabor (cc’ing rust-dev)- I have filed an issue to track incorporating the answers to these questions into the RFC process documentation.
https://github.com/rust-lang/rfcs/issues/121 Here is some of my opinionated answers to the questions: 1. When an RFC PR is merged as accepted into the repository, then that implies that we should implement it (or accept a community provided implementation) whenever we feel it best. This could be a matter of scratching an itch, or it could be to satisfy a 1.0 requirement; so there is no hard and fast rule about when the implementation for an RFC will actually land. 2. An RFC closed with “postponed” is being marked as such because we do not want to think about the proposal further until post-1.0, and we believe that we can afford to wait until then to do so. “Evaluate” is a funny word; usually something marked as “postponed” has already passed an informal first round of evaluation, namely the round of “do we think we would ever possibly consider making this change, as outlined here or some semi-obvious variation of it.” (When the answer to that question is “no”, then the appropriate response is to close the RFC, not postpone it.) 3. We strive to write each RFC in a manner that it will reflect the final design of the feature; but the nature of the process means that we cannot expect every merged RFC to actually reflect what the end result will be when 1.0 is released. The intention, I believe, is to try to keep each RFC document somewhat in sync with the language feature as planned. But just because an RFC has been accepted does not mean that the design of the feature is set in stone; one can file pull-requests to change an RFC if there is some change to the feature that we want to make, or need to make, (or have already made, and are going to keep in place). 4. If an RFC is accepted, the RFC author is of course free to submit an implementation, but it is not a requirement that an RFC author drive the implementation of the change. Each time an RFC PR is accepted and merged into the repository, a corresponding tracking issue is supposed to be opened up on the rust repository. A large point of the RFC process is to help guide community members in selecting subtasks to work on that where each member can be reasonably confident that their efforts will not be totally misguided. So, it would probably be best if anyone who plans to work on implementing a feature actually write a comment *saying* that they are planning such implementation on the tracking issue on the rust github repository. Having said that, I do not think we have been strictly following the latter process; I think currently you would need to also review the meeting notes to determine if someone might have already claimed responsibility for implementation. 5. The choice of which RFC’s get reviewed is somewhat ad-hoc at the moment. We do try to post each agenda topic ahead of time in a bulleted list at the top of the shared etherpad ( https://etherpad.mozilla.org/Rust-meeting-weekly ) , and RFC’s are no different in this respect. But in terms of how they are selected, I think it is largely driven by an informal estimate of whether the comment thread has reached a steady state (i.e. either died out or not showing any sign of providing further insight or improvement feedback to the RFC itself). Other than that, we basically try to make sure that any RFC that we accept is accepted at the Tuesday meeting, so that there is a formal record of discussion regarding acceptance. So we do not accept RFC’s at the Thursday meeting. We may reject RFC’s at either meeting; in other words, the only RFC activity on Thursdays is closing the ones that have reached a steady state and that the team agrees we will not be adopting. I want to call special attention to the question of "What if the author of the reviewed RFC isn't a participant in the meetings?” This is an important issue, since one might worry that the viewpoint of the author will not be represented at the meeting itself. In general, we try to only review RFC’s that at least a few people have taken the time to read the corresponding discussion thread and are prepared to represent the viewpoints presented there. Ideally at least one meeting participant would act as a champion for the feature (and hopefully also have read the discussion thread). Such a person need not *personally* desire the feature; they just need to act to represent its virtues and the community’s desire for it. (I think of it like a criminal defense attorney; they may not approve of their client’s actions, but they want to ensure their client gets proper legal representation.) But I did have the qualifier “Ideally” there, since our current process does not guarantee that such a champion exists. If no champion exists, it is either because not enough people have read the RFC (and thus we usually try to postpone making a decision for a later meeting), or because no one present is willing to champion it (in which case it seems like the best option is to close the RFC, though I am open to hearing alternative actions for this scenario). ---- Did the above help answer your questions? Let me know if I missed the point of one or more of your questions. Cheers, -Felix On 16 Jun 2014, at 14:44, Gábor Lehel <glaebho...@gmail.com> wrote: > Hi! > > There's a few things about the RFC process and the "meaning" of RFCs which > aren't totally clear to me, and which I'd like to request some clarification > about. > > > 1) Which of the following does submitting an RFC imply? > > 1a) We should implement this right away. > > 1b) We should implement this before 1.0. > > 1c) We should implement this whenever we feel like it. > > > 2) Some RFC PRs get closed and tagged with the "postponed" label. Does this > mean: > > 2a) It's too early to implement this proposal, or > > 2b) it's too early to *evaluate* this proposal? > > > 3) Are the designs outlined by RFCs supposed to be "incremental" or "final"? > I.e., > > 3a) First of all we should make this change, without implying anything about > what happens after that; or > > 3b) This is how it should look in the final version of the language? > > > 4) If someone submits an RFC, does she imply that "I am planning to implement > this", or, if an RFC is accepted, does that mean "anyone who wants to can > feel free to implement this"? > > > 5) The reviewing process is somewhat opaque to me. > > 5a) What determines which RFCs get reviewed in a given weekly meeting? > > 5b) As an observer, how can I tell which RFCs are considered to be in a > ready-for-review or will-be-reviewed-next state? > > 5c) What if the author of the reviewed RFC isn't a participant in the > meetings? > > 5d) (I might also ask "what determines which RFC PRs get attention from the > team?", but obviously the answer is "whatever they find interesting".) > > > I think that's all... Thanks! > > Gábor > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
