meta: unclear stability state of tracking issues for RFCs

[pnkfelix]

While reviewing the situation of #15701, I realized that I don't actually know when one is supposed to close a tracking issue.

Is it supposed to happen when:

• the feature has an initial feature-gated potentially-broken implementation, or
• a "complete" non-broken but still feature-gated implementation, or
• the feature is stabilized?

(or something else?)

From reviewing a semi-randomly selected set of RFC's, I don't think we have a consistent policy here.

The most reliable thing that I noted is that if the label:B-unstable is present (on open or closed issues), then that implies that the feature is unstable; but that is not a bi-directional implication.

This ticket is meant to suggest we take three steps:

1. Establish what the actual policy is here,
2. Update the existing tickets to reflect that policy, and
3. Document that policy somewhere (perhaps in the RFC process document).

Since this is largely about meta-administrative issues of the rust-lang/rust repo, I have filed the issue there. But its possible the core team will determine that this actually belongs as a first class RFC (or RFC amendment) of its own...

[alexcrichton]

For the libs team our policy is basically:

1. After an RFC is accepted, open a B-RFC-accepted issue
2. After it's implemented, change the same issue to B-unstable
3. When stabilized or deprecated to be removed, close the issue

That... may not be written down though, and it may not also apply to historical or lang issues perhaps.

[brson]

I've just gone through and tagged a bunch of stuff B-unstable, though I was not thinking about whether they had actually been implemented yet. Oops. Anyway, @alexcrichton's response seems to be how it works.