[rust-dev] Clarification about RFCs

Gábor Lehel glaebhoerl at gmail.com
Tue Jun 17 11:40:39 PDT 2014

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 <pnkfelix at mozilla.com>

> 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 <glaebhoerl at 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 at mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140617/eb254842/attachment.html>

More information about the Rust-dev mailing list