Thanks for the extremely thorough response! I think I don't actually have any questions left; you answered them all.
On Mon, Jun 16, 2014 at 4:56 PM, Felix S. Klock II <[email protected]> wrote: > 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 <[email protected]> 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 > > [email protected] > > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
