Bugzilla

This is not quite right -- significant in the field experience is not the same thing as unflagging the implementation. An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4.  The only browser to use unflagging as a policy is chrome. Two browsers shipping unflagged means that they believe that the proposal will not change any further.

This is not quite right -- significant in the field experience is not the same thing as unflagging the implementation. An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4.  The only browser to use unflagging as a policy is chrome. Two browsers shipping unflagged means that they believe that the proposal will not change any further. I took a more cautious approach because we recently had problems with the `.at` proposal, which also added a builtin method.

This is not quite right -- the process document does not require unflagged implementations, and significant in the field experience is not the same thing as unflagging the implementation. An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4.  The only browser to use unflagging as a policy is chrome. Two browsers shipping unflagged means that they believe that the proposal will not change any further. I took a more cautious approach because we recently had problems with the `.at` proposal, which also added a builtin method.

This is not quite right with regards to the process document -- the process document does not require unflagged implementations, and significant in the field experience is not the same thing as unflagging the implementation. An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4.  The only browser to use unflagging as a policy is chrome. Two browsers shipping unflagged means that they believe that the proposal will not change any further. I took a more cautious approach because we recently had problems with the `.at` proposal, which also added a builtin method.

This is not quite right with regards to the process document -- the process document does not require unflagged implementations, and significant in the field experience is not the same thing as unflagging the implementation. The process document requires two implementations however, which is yet another thing (that is what we have here). An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4.  For some proposals, the champion may wish to have more confidence before moving forward, and may wait.

The only browser to use unflagging as a policy is chrome. Two browsers shipping unflagged means that they believe that the proposal will not change any further. I took a more cautious approach because we recently had problems with the `.at` proposal, which also added a builtin method.

This is not quite right with regards to the process document -- the process document does not require unflagged implementations, and significant in the field experience is not the same thing as unflagging the implementation. The process document requires two implementations however, which is yet another thing (that is what we have here). An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4. Significant in the field experience was achieved via Node and others. For some proposals, the champion may wish to have more confidence before moving forward, and may wait.

The only browser to use unflagging as a policy is chrome. Two browsers shipping unflagged means that they believe that the proposal will not change any further. I took a more cautious approach because we recently had problems with the `.at` proposal, which also added a builtin method.

This is not quite right with regards to the process document -- the process document does not require unflagged implementations, and significant in the field experience is not the same thing as unflagging the implementation. The process document requires two implementations however, which is yet another thing (that is what we have here). An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4. Significant in the field experience was achieved via Node and others. Spec adjustments were made after people encountered unexpected behaviour in a spec-adherent implementation. For some proposals, the champion may wish to have more confidence before moving forward, and may wait.

The only browser to use unflagging as a policy is chrome. Two browsers shipping unflagged means that they believe that the proposal will not change any further. I took a more cautious approach because we recently had problems with the `.at` proposal, which also added a builtin method.

This is not quite right with regards to the process document -- the process document does not require unflagged implementations, and significant in the field experience is not the same thing as unflagging the implementation. The process document requires two implementations however, which is yet another thing (that is what we have here), which has the purpose of ensuring multi-implementer buy in. An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4. Significant in the field experience was achieved via Node and others. Spec adjustments were made after people encountered unexpected behaviour in a spec-adherent implementation. For some proposals, the champion may wish to have more confidence before moving forward, and may wait for a high confidence signal from more browsers.

The only browser to use unflagging as a policy is chrome. Two browsers shipping unflagged means that they believe that the proposal will not change any further. I took a more cautious approach because we recently had problems with the `.at` proposal, which also added a builtin method.

This is not quite right with regards to the process document -- the process document does not require unflagged implementations, and significant in the field experience is not the same thing as unflagging the implementation. The process document requires two implementations however, which is yet another thing (that is what we have here), which has the purpose of ensuring multi-implementer buy in. An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4. Significant in the field experience was achieved via Node and others. Spec adjustments were made after people encountered unexpected behaviour in a spec-adherent implementation. For some proposals, the champion may wish to have more confidence before moving forward, and may wait for a high confidence signal from more browsers.

The only browser to use unflagging as a policy is chrome -- they do not consider it to be significant in the field experience without unflagging. Not all browsers follow this however. Two browsers shipping unflagged means that they both believe that the proposal will not change any further, as unflagging may ultimately change the landscape for the feature. I took a more cautious approach because we recently had problems with the `.at` proposal, which also added a builtin method.

With regards to the process document -- the process document does not require unflagged implementations (it is recommended), and significant in the field experience is not the same thing as unflagging the implementation. The process document requires two implementations however, which is yet another thing (that is what we have here), which has the purpose of ensuring multi-implementer buy in. An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4. Significant in the field experience was achieved via Node and transpilers. Spec adjustments were made after chrome shipped and had to be landed quickly as a result which is less than ideal. For some proposals, the champion may wish to have more confidence before moving forward, and may wait for a high confidence signal from more browsers.

The only browser to use unflagging as a policy is chrome -- they do not consider it to be significant in the field experience without unflagging. Not all browsers follow this however. Two browsers shipping unflagged means that they both believe that the proposal will not change any further, as unflagging may ultimately change the landscape for the feature. I took a more cautious approach because we recently had problems with the `.at` proposal, which also added a builtin method.

With regards to the process document -- the process document does not require two unflagged implementations (though you may say it is recommended), and significant in the field experience is not the same thing as unflagging the implementation. The process document requires two implementations however, which is yet another thing (that is what we have here), which has the purpose of ensuring multi-implementer buy in. An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4. Significant in the field experience was achieved via Node and transpilers. Spec adjustments were made after chrome shipped and had to be landed quickly as a result which is less than ideal. For some proposals, the champion may wish to have more confidence before moving forward, and may wait for a high confidence signal from more browsers.

The only browser to use unflagging as a policy is chrome -- they do not consider it to be significant in the field experience without unflagging. Not all browsers follow this however. Two browsers shipping unflagged means that they both believe that the proposal will not change any further, as unflagging may ultimately change the landscape for the feature. I took a more cautious approach because we recently had problems with the `.at` proposal, which also added a builtin method.

With regards to the process document -- the process document does not require two unflagged implementations (though you may say it is recommended), and significant in the field experience is not the same thing as unflagging the implementation. The process document requires two implementations however, which is yet another thing (that is what we have here), which has the purpose of ensuring multi-implementer buy in. An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4. Significant in the field experience was achieved via Node and transpilers. Spec adjustments were made after chrome shipped and had to be landed quickly as a result which is less than ideal. For some proposals, the champion may wish to have more confidence before moving forward, and may wait for a high confidence signal from more browsers. 

If you choose this (which I also recommend) then yes, do wait until there are two browsers shipping unflagged.

The only browser to use unflagging as a policy is chrome -- they do not consider it to be significant in the field experience without unflagging. Not all browsers follow this however. Two browsers shipping unflagged means that they both believe that the proposal will not change any further, as unflagging may ultimately change the landscape for the feature. I took a more cautious approach because we recently had problems with the `.at` proposal, which also added a builtin method.

With regards to the process document -- the process document does not require two unflagged implementations (though you may say it is recommended), and significant in the field experience is not the same thing as unflagging the implementation. The process document requires two implementations however, which is yet another thing (that is what we have here), which has the purpose of ensuring multi-implementer buy in. An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4. Significant in the field experience was achieved via Node and transpilers. Spec adjustments were made after chrome shipped and had to be landed quickly as a result which is less than ideal. 

For some proposals, the champion may wish to have more confidence before moving forward, and may wait for a high confidence signal from more browsers. If you choose this more cautious approach, then yes, do wait until there are two browsers shipping unflagged.

The only browser to use unflagging as a policy is chrome -- they do not consider it to be significant in the field experience without unflagging. Not all browsers follow this however. Two browsers shipping unflagged means that they both believe that the proposal will not change any further, as unflagging may ultimately change the landscape for the feature. I took a more cautious approach because we recently had problems with the `.at` proposal, which also added a builtin method.

With regards to the process document -- the process document does not require two unflagged implementations (though you may say it is recommended), and significant in the field experience is not the same thing as unflagging the implementation. The process document requires two implementations however, which is yet another thing (that is what we have here), which has the purpose of ensuring multi-implementer buy in. An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4 (not before). Significant in the field experience was achieved via Node and transpilers. Spec adjustments were made after chrome shipped and had to be landed quickly as a result which is less than ideal. 

For some proposals, the champion may wish to have more confidence before moving forward, and may wait for a high confidence signal from more browsers. If you choose this more cautious approach, then yes, do wait until there are two browsers shipping unflagged. 

The only browser to use unflagging as a policy is chrome -- they do not consider it to be significant in the field experience without unflagging. Not all browsers follow this however. Two browsers shipping unflagged means that they both believe that the proposal will not change any further, as unflagging may ultimately change the landscape for the feature. I took a more cautious approach because we recently had problems with the `.at` proposal, which also added a builtin method.

With regards to the process document -- the process document does not require two unflagged implementations (though you may say it is recommended), and significant in the field experience is not the same thing as unflagging the implementation. The process document requires two implementations however, which is yet another thing (that is what we have here), which has the purpose of ensuring multi-implementer buy in. An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4 (not before). Significant in the field experience was achieved via Node and transpilers. Spec adjustments were made after chrome shipped and had to be landed quickly as a result which is less than ideal. 

For some proposals, the champion may wish to have more confidence before moving forward, and may wait for a high confidence signal from more browsers. If you choose this more cautious approach, then yes, do wait until there are two browsers shipping unflagged. 

The only browser to use unflagging as a policy is chrome -- they do not consider it to be significant in the field experience without unflagging. Not all browsers follow this however. Two browsers shipping unflagged means that they both believe that the proposal will not change any further, as unflagging may ultimately change the landscape for the feature. I took a more cautious approach because we recently had problems with the `.at` proposal, which also added a builtin method and ultimately required one rename, and negotiation with a site to change their code after that rename.

With regards to the process document -- the process document does not require two unflagged implementations (though you may say it is recommended), and significant in the field experience is not the same thing as unflagging the implementation. The process document requires two implementations however, which is yet another thing (that is what we have here), which has the purpose of ensuring multi-implementer buy in. An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4 (not before). Significant in the field experience was achieved via Node and transpilers. Spec adjustments were made after chrome shipped and had to be landed quickly as a result which is less than ideal. 

For some proposals, the champion may wish to have more confidence before moving forward, and may wait for a high confidence signal from more browsers. If you choose this more cautious approach, then yes, do wait until there are two browsers shipping unflagged. 

The only browser to use unflagging as a policy is chrome -- they do not consider it to be significant in the field experience without unflagging. Not all browsers follow this however. Two browsers shipping unflagged means that they both believe that the proposal will not change any further, as unflagging may ultimately change the landscape for the feature. I took a more cautious approach because we recently had problems with the `.at` proposal, which also added a builtin method and ultimately required one rename, and negotiation with a site to change their code after that rename. This web compat issue was identified in nightly.

With regards to the process document -- the process document does not require two unflagged implementations (though you may say it is recommended), and significant in the field experience is not the same thing as unflagging the implementation. The process document requires two implementations however, which is yet another thing (that is what we have here), which has the purpose of ensuring multi-implementer buy in. An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4 (not before). Significant in the field experience was achieved via Node and transpilers. Spec adjustments were made after chrome shipped and had to be landed quickly as a result which is less than ideal. 

For some proposals, the champion may wish to have more confidence before moving forward, and may wait for a high confidence signal from more browsers. If you choose this more cautious approach, then yes, do wait until there are two browsers shipping unflagged. 

The only browser to use unflagging as a policy is chrome -- they do not consider it to be significant in the field experience without unflagging. Not all browsers follow this however. Two browsers shipping unflagged means that they both believe that the proposal will not change any further, as unflagging may ultimately change the landscape for the feature. I took a more cautious approach in particular because we recently had problems with the `.at` proposal, which also added a builtin method and first shipped in nightly. It ultimately required one rename, and negotiation with a site to change their code after that rename. This web compat issue was identified in nightly.

With regards to the process document -- the process document does not require two unflagged implementations as significant in the field experience (though you may say it is recommended as the example provided for significant in the field experience is unflagged implementations). Significant in the field experience is not the same thing as unflagging the implementation however. Two implementations ensure multi-implementer buy in and is an important part of the process. An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4 (not before). Significant in the field experience was achieved via Node and transpilers. Spec adjustments were made after chrome shipped and had to be landed quickly as a result which is less than ideal. But, in the end the proposal met the criteria for advancement.

For some proposals, the champion may wish to have more confidence before moving forward, and may wait for a high confidence signal from more browsers. I think this is a better signal, and would recommend to wait until there are two browsers shipping unflagged or have plans to do so. 

The only browser to use unflagging as a policy is chrome -- they do not consider it to be significant in the field experience without unflagging. Not all browsers follow this however. Two browsers shipping unflagged means that they both believe that the proposal will not change any further, as unflagging may ultimately change the landscape for the feature. I took a more cautious approach in particular because we recently had problems with the `.at` proposal, which also added a builtin method and first shipped in nightly. It ultimately required one rename, and negotiation with a site to change their code after that rename. This web compat issue was identified in nightly.

With regards to the process document -- the process document does not require two unflagged implementations as significant in the field experience (though you may say it is recommended as the example provided for significant in the field experience is unflagged implementations). Significant in the field experience is not the same thing as unflagging the implementation however. Two implementations ensure multi-implementer buy in and is an important part of the process. An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4 (not before). Significant in the field experience was achieved via Node and transpilers. One risk is that this might end up not being so smooth: spec adjustments were made after chrome shipped and had to be landed quickly as a result which is less than ideal.

For some proposals, the champion may wish to have more confidence before moving forward, and may wait for a high confidence signal from more browsers. I think this is a better signal, and would recommend to wait until there are two browsers shipping unflagged or have plans to do so. 

The only browser to use unflagging as a policy is chrome -- they do not consider it to be significant in the field experience without unflagging. Not all browsers follow this however. Two browsers shipping unflagged means that they both believe that the proposal will not change any further, as unflagging may ultimately change the landscape for the feature. I took a more cautious approach in particular because we recently had problems with the `.at` proposal, which also added a builtin method and first shipped in nightly. It ultimately required one rename, and negotiation with a site to change their code after that rename. This web compat issue was identified in nightly.

With regards to the process document -- the process document does not require two unflagged implementations as significant in the field experience (though you may say it is recommended as the example provided for significant in the field experience is unflagged implementations). Significant in the field experience is not the same thing as unflagging the implementation however. Two implementations ensure multi-implementer buy in and is an important part of the process. An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4 (not before). Significant in the field experience was achieved via Node and transpilers. One risk is that this might end up not being so smooth: spec adjustments were made after chrome shipped and had to be approved and landed quickly as a resultl.

For some proposals, the champion may wish to have more confidence before moving forward, and may wait for a high confidence signal from more browsers. I think this is a better signal, and would recommend to wait until there are two browsers shipping unflagged or have plans to do so. 

The only browser to use unflagging as a policy is chrome -- they do not consider it to be significant in the field experience without unflagging. Not all browsers follow this however. Two browsers shipping unflagged means that they both believe that the proposal will not change any further, as unflagging may ultimately change the landscape for the feature. I took a more cautious approach in particular because we recently had problems with the `.at` proposal, which also added a builtin method and first shipped in nightly. It ultimately required one rename, and negotiation with a site to change their code after that rename. This web compat issue was identified in nightly.