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
relatively-straightforward or it may be a major undertaking. You can always ask
for help or mentorship from more experienced compiler devs.  Also, you don't
have to be the one to implement your feature; but keep in mind that if you
don't, it might be a while before someone else does.

For the `?` macro feature, I needed to go understand the relevant parts of
macro expansion in the compiler. Personally, I find that [improving the
comments][comments] in the code is a helpful way of making sure I understand
it, but you don't have to do that if you don't want to.


I then [implemented][impl1] the original feature, as described in the RFC. When
a new feature is implemented, it goes behind a _feature gate_, which means that
you have to use `#![feature(my_feature_name)]` to use the feature. The feature
gate is removed when the feature is stabilized.

**Most bug fixes and improvements** don't require a feature gate. You can just
make your changes/improvements.

When you open a PR on the [rust-lang/rust], a bot will assign your PR to a
reviewer. If there is a particular Rust team member you are working with, you can
request that reviewer by leaving a comment on the thread with `r?
@reviewer-github-id` (e.g. `r? @eddyb`). If you don't know who to request,
don't request anyone; the bot will assign someone automatically based on which files you changed.

The reviewer may request changes before they approve your PR, they may mark the PR with label 
"S-waiting-on-author" after leaving comments, this means that the PR is blocked on you to make 
some requested changes. When you finished iterating on the changes, you can mark the PR as 
`S-waiting-on-review` again by leaving a comment with `@rustbot ready`, this will remove the 
`S-waiting-on-author` label and add the `S-waiting-on-review` label.

Feel free to ask questions or discuss things you don't understand or disagree with. However,
recognize that the PR won't be merged unless someone on the Rust team approves
it. If a reviewer leave a comment like `r=me after fixing ...`, that means they approve the PR and 
you can merge it with comment with `@bors r=reviewer-github-id`(e.g. `@bors r=eddyb`) to merge it 
after fixing trivial issues. Note that `r=someone` requires permission and bors could say 
something like "🔑 Insufficient privileges..." when commenting `r=someone`. In that case,