including Rust team members.

To open an RFC, open a PR on the
[rust-lang/rfcs](https://github.com/rust-lang/rfcs) repo on GitHub. You can
find detailed instructions in the
[README](https://github.com/rust-lang/rfcs#what-the-process-is).

Before opening an RFC, you should do the research to "flesh out" your idea.
Hastily-proposed RFCs tend not to be accepted. You should generally have a good
description of the motivation, impact, disadvantages, and potential
interactions with other features.

If that sounds like a lot of work, it's because it is. But no fear! Even if
you're not a compiler hacker, you can get great feedback by doing a _pre-RFC_.
This is an _informal_ discussion of the idea. The best place to do this is
internals.rust-lang.org. Your post doesn't have to follow any particular
structure.  It doesn't even need to be a cohesive idea. Generally, you will get
tons of feedback that you can integrate back to produce a good RFC.

(Another pro-tip: try searching the RFCs repo and internals for prior related
ideas. A lot of times an idea has already been considered and was either
rejected or postponed to be tried again later. This can save you and everybody
else some time)

In the case of our example, a participant in the pre-RFC thread pointed out a
syntax ambiguity and a potential resolution. Also, the overall feedback seemed
positive. In this case, the discussion converged pretty quickly, but for some
ideas, a lot more discussion can happen (e.g. see [this RFC][nonascii] which
received a whopping 684 comments!). If that happens, don't be discouraged; it
means the community is interested in your idea, but it perhaps needs some
adjustments.


The RFC for our `?` macro feature did receive some discussion on the RFC thread
too.  As with most RFCs, there were a few questions that we couldn't answer by
discussion: we needed experience using the feature to decide. Such questions
are listed in the "Unresolved Questions" section of the RFC. Also, over the
course of the RFC discussion, you will probably want to update the RFC document
itself to reflect the course of the discussion (e.g. new alternatives or prior
work may be added or you may decide to change parts of the proposal itself).

In the end, when the discussion seems to reach a consensus and die down a bit,
a Rust team member may propose to move to "final comment period" (FCP) with one
of three possible dispositions. This means that they want the other members of
the appropriate teams to review and comment on the RFC. More discussion may
ensue, which may result in more changes or unresolved questions being added. At
some point, when everyone is satisfied, the RFC enters the FCP, which is the
last chance for people to bring up objections. When the FCP is over, the
disposition is adopted. Here are the three possible dispositions:

- _Merge_: accept the feature. Here is the proposal to merge for our [`?` macro
  feature][rfcmerge].
- _Close_: this feature in its current form is not a good fit for rust. Don't
  be discouraged if this happens to your RFC, and don't take it personally.
  This is not a reflection on you, but rather a community decision that rust
  will go a different direction.
- _Postpone_: there is interest in going this direction but not at the moment.
  This happens most often because the appropriate Rust team doesn't have the
  bandwidth to shepherd the feature through the process to stabilization. Often
  this is the case when the feature doesn't fit into the team's roadmap.
  Postponed ideas may be revisited later.


When an RFC is merged, the PR is merged into the RFCs repo. A new _tracking
issue_ is created in the [rust-lang/rust] repo to track progress on the feature
and discuss unresolved questions, implementation progress and blockers, etc.
Here is the tracking issue on for our [`?` macro feature][tracking].


<a id="impl"></a>

## Implementation

To make a change to the compiler, open a PR against the [rust-lang/rust] repo.


Depending on the feature/change/bug fix/improvement, implementation may be