Bugzilla

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer) -- you will notice that the bug similarly lacks information but the intent to ship has all of it.

I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. That way, if something is missing in the mailing lists, you can fall back onto the bug. 

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer) -- you will notice that the bug similarly lacks information but the intent to ship has all of it.

I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. That way, if something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. That way, if something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. That way, if something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases. For example, in the case of this bug which may be uplifted to 91.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. That way, if something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. Because stage 3 proposals in tc39 are intended to be prototyped and tested, we are usually implementing them and sending an intent to prototype. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. However given that other standards have their own process, it doesn't line up 100% across the board except for the intent to ship. 

I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. That way, if something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. Because stage 3 proposals in tc39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), we are usually implementing them and sending an intent to prototype. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. However given that other standards have their own process, it doesn't line up 100% across the board except for the intent to ship. 

I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. That way, if something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. Because stage 3 proposals in tc39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), we are usually implementing them and sending an intent to prototype, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. However given that other standards have their own process, it doesn't line up 100% across the board except for the intent to ship. 

I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. That way, if something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. Which one to send is at the discression of the person writing it. From my perspective, because stage 3 proposals in tc39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. However given that other standards have their own process, it doesn't line up 100% across the board except for the intent to ship. 

I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. That way, if something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. Which one to send is at the discression of the person writing it. From my perspective, because stage 3 proposals in tc39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. However given that other standards have their own process, it doesn't line up 100% across the board except for the intent to ship. 

Since you are relying on the bugs for this information, rather than adding more process and more fields, I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. That way, if something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. Which one to send and when is at the discression of the person writing it. From my perspective, because stage 3 proposals in tc39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. However given that other standards have their own process, it doesn't line up 100% across the board except for the intent to ship. 

Since you are relying on the bugs for this information, rather than adding more process and more fields, I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. That way, if something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in tc39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. However given that other standards have their own process, it doesn't line up 100% across the board except for the intent to ship. 

Since you are relying on the bugs for this information, rather than adding more process and more fields, I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. That way, if something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in tc39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information, rather than adding more process and more fields, I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. That way, if something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in tc39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: rather than adding more process and more fields, I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. That way, if something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in tc39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: rather than adding more process and more fields, I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. If something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in tc39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: rather than adding more process and more fields, I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. If something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in tc39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: rather than adding more process and more fields, I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. If something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do. Another thing we can do is have feature implementers update the compatibility table when something ships. 

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in tc39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: rather than adding more process and more fields, I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. If something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do. Another thing we can do is have feature implementers update the compatibility table when something ships, which I have done in the past. 

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in tc39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: rather than adding more process and more fields, I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. If something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do. Another thing we can do is have feature implementers update the compatibility table when something ships. 

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in tc39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: rather than adding more process and more fields, I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those, especially if you are working across browsers. If something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in tc39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. If something is missing in the mailing lists, you can fall back onto the bug. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in tc39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in tc39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. If something is missing in the mailing lists, you can fall back onto the bug or ask. If a bug is landed and no extra information is present, it is likely because someone forgot. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in tc39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

For getting the current status shipping information. What I can do is stop using dev-doc-needed until the shipping bug is created. I usually create these bugs as clones of past bugs, and in the past -- someone from the doc team has come and added that label for me if I didn't have it. If you have documentation on how you use this label, it would be easier for me to know when to add it.

Otherwise: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

For getting the current status shipping information. What I can do is stop using dev-doc-needed until the shipping bug is created. I usually create these bugs as clones of past bugs, because in the past -- someone from the doc team has come and added that label for me if I didn't have it. If you have documentation on how you use this label, it would be easier for me to know when to add it. Or I can leave it to you. Either is fine by me, but it seems now like you would prefer to add it.

Otherwise: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

For getting the current status shipping information. What I can do is stop using dev-doc-needed until the shipping bug is created. I usually create these bugs as clones of past bugs, because in the past -- someone from the doc team has come and added that label for me if I didn't have it. If you have documentation on how you use this label, it would be easier for me to know when to add it. Or I can leave it to you. Either is fine by me, but it seems now like you would prefer to add it. I thought that your team wanted a heads up for new features, but I no longer know what that label signifies or what changes you have made recently in how you use it.  For example, the dev-doc here was added 2 years prior to the feature being implemented: https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I don't know what has changed since that point. 

Otherwise: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

For getting the current status shipping information. What I can do is stop using dev-doc-needed until the shipping bug is created. I usually create these bugs as clones of past bugs, because in the past -- someone from the doc team has come and added that label for me if I didn't have it, usually before implementation had started. If you have documentation on how you use this label, it would be easier for me to know when to add it. Or I can leave it to you. Either is fine by me, but it seems now like you would prefer to add it. For example, the dev-doc here was added 2 years prior to the feature being implemented: https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I don't know what has changed since that point or how you want to do things. 

Otherwise: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

For getting the current status shipping information. What I can do is stop using dev-doc-needed until the shipping bug is created. I usually create these bugs as clones of past bugs, because in the past -- someone from the doc team has come and added that label for me if I didn't have it, usually before implementation had started. If you have documentation on how you use this label, it would be easier for me to know when to add it. Or I can leave it to you. Either is fine by me, but it seems now like you would prefer to add it. For example, the dev-doc here was added 2 years prior to the feature being implemented: https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I don't know what has changed since that point or how you want to do things. 

Otherwise: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I usually create these bugs as clones of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I don't know what has changed since 5 months ago or how you want to do things. It also isn't my decision, I will leave it to you and your team to decide how you want to go forward. If you have documentation on how you use this label, it would be easier to understand what kind of work you are doing with it, and when it is appropriate to add that label.

Otherwise, for identifying when something shipped: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I usually create these bugs as clones of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature. The firefox status was updated as part of a separate bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not. If you have documentation on how you use this label, it would be easier to understand what kind of work you are doing with it, and when it is appropriate to add that label or which.

Otherwise, for identifying when something shipped: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I usually create these bugs as clones of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature. The firefox status was updated as part of a separate bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not. If you have documentation on how you use this label, it would be easier to understand what kind of work you are doing with it, and when it is appropriate to add that label or if a new one is made, when to add that one.

Otherwise, for identifying when something shipped: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I usually create these bugs as clones of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature. The firefox status was updated as part of a separate bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not. If you have documentation on how you use this label, it would be easier to understand what kind of work you are doing with it, and when it is appropriate to add that label or if a new one is made, when to add that one. This isn't up to me, but to you and your team. 

Otherwise, for identifying when something shipped: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I usually create these bugs as clones of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature. The firefox status was updated as part of a separate bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not. If you have documentation on how you use this label, it would be easier to understand what kind of work you are doing with it, and when it is appropriate to add that label or if a new one is made, when to add that one. This isn't up to me, but to you and your team. 

Otherwise, for identifying when something shipped: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I usually create these bugs as clones of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature. The firefox status was updated as part of a separate bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not. If you have documentation on how you use this label, it would be easier to understand what kind of work you are doing with it, and when it is appropriate to add that label or if a new one is made, when to add that one.  

Otherwise, for identifying when something shipped: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I usually create these bugs as clones of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not. 

Otherwise, for identifying when something shipped: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I usually create these bugs as clones of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not. 

Otherwise, for identifying when something shipped: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I usually create these bugs as clones of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not. 

Otherwise, for identifying when something shipped: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I usually create these bugs as clones of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases. 

Otherwise, for identifying when something shipped: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I usually create these bugs as clones of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, though I sympathize with this being a bit confusing to use the same label. 

Otherwise, for identifying when something shipped: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I usually create these bugs as clones of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. 

Otherwise, for identifying when something shipped: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information: I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I usually create these bugs as clones of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. 

Otherwise, for identifying when something shipped: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I usually create these bugs as clones of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs.

Otherwise, for identifying when something shipped: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs.

Otherwise, for identifying when something shipped: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs.

Otherwise, for identifying when something shipped: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. However, things still change in stage 3, so doing so may result in things going out of sync, as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. Things still change in stage 3, so doing so may result in things going out of sync as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of the information. All stage 3 proposals are expected to have a detailed explainer of what the feature is and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. Things still change in stage 3, so doing so may result in things going out of sync as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. This proposal is not an outlier -- it is the norm and enforced by the committee. If we were to write it up ourselves, it would be copy-pasting their description. Things still change in stage 3, so doing so may result in things going out of sync as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. Things still change in stage 3, so doing so may result in things going out of sync as well as being redundant. 

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. Things still change in stage 3, so doing so may result in things going out of sync as well as being redundant. In addition, we do not design these features, our iteration here is implementation specific -- not design oriented. These are not firefox specific features. You should not be searching our bugs for details about how a TC39 feature is designed -- always go to the proposal. It is the most up to date version along with discussion and examples. The Champions are also the authorities on the spec text -- if there are questions do not hesitate to ask them by opening an issue.

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. Things still change in stage 3, so doing so may result in things going out of sync as well as being redundant. In addition, you should not be searching our bugs for details about how a TC39 feature is designed, we won't be discussing that. Always go to the proposal, that is why it is linked. It is the most up to date version along with discussion and examples. The Champions are also the authorities on the spec text -- if there are questions do not hesitate to ask them by opening an issue.

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. Things still change in stage 3, so doing so may result in things going out of sync as well as being redundant. In addition, you should not be searching our bugs for details about how a TC39 feature is designed, we won't be discussing that because it isn't for us to decide -- it is decided by TC39 of which we are a part of. 

Always go to the proposal, that is why it is linked. It is the most up to date version along with discussion and examples. The Champions are also the authorities on the spec text -- if there are questions do not hesitate to ask them by opening an issue.

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. Things still change in stage 3, so doing so may result in things going out of sync as well as being redundant. In addition, you should not be searching our bugs for details about how a TC39 feature is designed, we won't be discussing that because it isn't for us to decide in isolation -- it is decided by TC39 of which we are a part of. 

Always go to the proposal, that is why it is linked. It is the most up to date version along with discussion and examples. The Champions are also the authorities on the spec text -- if there are questions do not hesitate to ask them by opening an issue.

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. Things still change in stage 3, so doing so may result in things going out of sync as well as being redundant. In addition, you should not be searching our bugs for details about how a TC39 feature is designed, we won't be discussing that because it isn't for us to decide in isolation -- it is decided by TC39 of which we are a part of. 

Always go to the proposal, that is why it is linked. It is the most up to date version along with discussion and examples. The Champions are also the authorities on the spec text -- if there are questions do not hesitate to ask them by opening an issue. This is not a design bug, it is an implementation bug.

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. Things still change in stage 3, so doing so may result in things going out of sync as well as being redundant. In addition, you should not be searching our bugs for details about how a TC39 feature is designed, we won't be discussing that because it isn't for us to decide in isolation -- it is decided by TC39 of which we are a part of. 

When documenting a new feature for TC39, always go to the proposal, that is why it is linked. It is the most up to date version along with discussion and examples. The Champions are also the authorities on the spec text -- if there are questions do not hesitate to ask them by opening an issue. While we can likely answer any questions you have, our bug tracker is not used for design, TC39 uses github for that. 

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. Things still change in stage 3, so doing so may result in things going out of sync as well as being redundant. In addition, you should not be searching our bugs for details about how a TC39 feature is designed, we won't be discussing that because it isn't for us to decide in isolation -- it is decided by TC39 of which we are a part of. 

When documenting a new feature for TC39, always go to the proposal, that is why it is linked. It is the most up to date version along with discussion and examples. The Champions are also the authorities on the spec text -- if there are questions do not hesitate to ask them by opening an issue, or ask questions about the examples in their explainer. While we can likely answer any questions you have, our bug tracker is not used for design, TC39 uses github for that. The deliverable of the implementation bugs is always an implementation of the spec text.

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. This proposal is not an outlier -- it is the norm. If we were to write it up ourselves, it would be copy-pasting their description. Things still change in stage 3, so doing so may result in things going out of sync as well as being redundant. In addition, you should not be searching our bugs for details about how a TC39 feature is designed, we won't be discussing that because it isn't for us to decide in isolation -- it is decided by TC39 of which we are a part of. 

When documenting a new feature for TC39, always go to the proposal, that is why it is linked. It is the most up to date version along with discussion and examples. The Champions are also the authorities on the spec text -- if there are questions do not hesitate to ask them by opening an issue, or ask questions about the examples in their explainer. While we can likely answer any questions you have, our bug tracker is not used for design, TC39 uses github for that. The deliverable of the implementation bugs is always an implementation of the spec text or a subset of the spec text.

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is (or should be) the norm. In the past I have requested the explainer to be improved for new features or have improved it myself, because that is where the information should be. 

Things still change in stage 3, so doing so may result in things going out of sync as well as being redundant. In addition, you should not be searching our bugs for details about how a TC39 feature is designed, we won't be discussing that because it isn't for us to decide in isolation -- it is decided by TC39 of which we are a part of. When we have made design changes based on implementation experience, it has been discussed in the proposal, not in the implementation bug.

This is really critical: When documenting a new feature for TC39, always go to the proposal, that is why it is linked.

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is (or should be) the norm. In the past I have requested the explainer to be improved for new features or have improved it myself, because that is where the information should be. 

Things still change in stage 3, so doing so may result in things going out of sync as well as being redundant. In addition, you should not be searching our bugs for details about how a TC39 feature is designed, we won't be discussing that because it isn't for us to decide in isolation -- it is decided by TC39 of which we are a part of. When we have made design changes based on implementation experience, it has been discussed in the proposal, not in the implementation bug. If a proposal is a subset, as has been the case for private fields, it has been documented and is usually part of an epic, but this only impacts our implementation and not the feature as a whole.

This is really critical: When documenting a new feature for TC39, always go to the proposal, that is why it is linked.

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is (or should be) the norm. In the past I have requested the explainer to be improved for new features or have improved it myself, because that is where the information should be. 

Things still change in stage 3, so rehashing the proposals description may result in things going out of sync as well as being redundant. You should not be searching our bugs for details about how a TC39 feature is designed, we won't be discussing that because it isn't for us to decide in isolation -- it is decided by TC39 of which we are a part of. When we have made design changes based on implementation experience, it has been discussed in the proposal, not in the implementation bug. If a proposal is a subset, as has been the case for private fields, it has been documented and is usually part of an epic, but this only impacts our implementation and not the feature as a whole.

This is really critical: When documenting a new feature for TC39, always go to the proposal, that is why it is linked.

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is (or should be) the norm. In the past I have requested the explainer to be improved before advancing for new features or have improved it myself, because that is where the information should be. 

Things still change in stage 3, so rehashing the proposals description may result in things going out of sync as well as being redundant. You should not be searching our bugs for details about how a TC39 feature is designed, we won't be discussing that because it isn't for us to decide in isolation -- it is decided by TC39 of which we are a part of. When we have made design changes based on implementation experience, it has been discussed in the proposal, not in the implementation bug. If a proposal is a subset, as has been the case for private fields, it has been documented and is usually part of an epic, but this only impacts our implementation and not the feature as a whole.

This is really critical: When documenting a new feature for TC39, always go to the proposal, that is why it is linked.

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is (or should be) the norm. In the past I have requested the explainer to be improved before advancing for new features or have improved it myself, because that is where the information should be. 

Things still change in stage 3, so rehashing the proposals description may result in things going out of sync as well as being redundant. You should not be searching our bugs for details about how a TC39 feature is designed, we won't be discussing that because it isn't for us to decide in isolation -- it is decided by TC39 of which we are a part of. When we have made design changes based on implementation experience, it has been discussed in the proposal, not in the implementation bug. If a proposal is a subset, as has been the case for private fields, it has been documented and is usually part of an epic, but this only impacts our implementation and not the feature as a whole.

This is really critical: When documenting a new feature for TC39, always go to the proposal, that is why it is linked. Absolutely do not rely on the implementation bug.

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is (or should be) the norm. In the past I have requested the explainer to be improved before advancing for new features or have improved it myself, because that is where the information should be. 

Things still change in stage 3, so rehashing the proposals description may result in things going out of sync as well as being redundant. You should not be searching our bugs for details about how a TC39 feature is designed, we won't be discussing that because it isn't for us to decide in isolation -- it is decided by TC39 of which we are a part of. When we have made design changes based on implementation experience, it has been discussed in the proposal, not in the implementation bug. If a proposal is a subset, as has been the case for private fields, it has been documented and is usually part of an epic, but this only impacts our implementation and not the feature as a whole.

This is really critical: When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked. Absolutely do not rely on the implementation bug.

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is (or should be) the norm. In the past I have requested the explainer to be improved before advancing for new features or have improved it myself, because that is where the information should be. 

Things still change in stage 3, so rehashing the proposals description may result in things going out of sync as well as being redundant. You should not be searching our bugs for details about how a TC39 feature is designed, we won't be discussing that because it isn't for us to decide in isolation -- it is decided by TC39 of which we are a part of. When we have made design changes based on implementation experience, it has been discussed in the proposal, not in the implementation bug. If a proposal is a subset, as has been the case for private fields, it has been documented and is usually part of an epic, but this only impacts our implementation and not the feature as a whole.

This is really critical: When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked. Do not rely on the implementation bug.

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is (or should be) the norm. In the past I have requested the explainer to be improved before advancing for new features or have improved it myself, because that is where the information should be. 

Things still change in stage 3, so rehashing the proposals description may result in things going out of sync as well as being redundant. You should not be searching our bugs for details about how a TC39 feature is designed, we won't be discussing that because it isn't for us to decide in isolation -- it is decided by TC39 of which we are a part of. When we have made design changes based on implementation experience, it has been discussed in the proposal, not in the implementation bug. If a proposal is a subset, as has been the case for private fields, it has been documented and is usually part of an epic, but this only impacts our implementation and not the feature as a whole.

This is really critical: When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked. Do not rely on the implementation bug. The details discussed around implementation are not relevant for this.

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is (or should be) the norm. In the past I have requested the explainer to be improved before advancing for new features or have improved it myself, because that is where the information should be. 

Things still change in stage 3, so rehashing the proposals description may result in things going out of sync as well as being redundant. You should not be searching our bugs for details about how a TC39 feature is designed, we won't be discussing that because it isn't for us to decide in isolation -- it is decided by TC39 of which we are a part of. When we have made design changes based on implementation experience, it has been discussed in the proposal, not in the implementation bug. If a proposal is a subset, as has been the case for private fields, it has been documented and is usually part of an epic, but this only impacts our implementation and not the feature as a whole.

This is really critical: When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked. Do not rely on the implementation bug. The details discussed around implementation are not relevant for this.

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion. Once you have a process you are happy with, you can let me know how I can help.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear (though I expect you mean the explainer), but it is important to emphasize that this proposal is not an outlier -- it is (or should be) the norm. In the past I have requested the explainer to be improved before advancing for new features or have improved it myself, because that is where the information should be. 

Things still change in stage 3, so rehashing the proposals description may result in things going out of sync as well as being redundant. You should not be searching our bugs for details about how a TC39 feature is designed, we won't be discussing that because it isn't for us to decide in isolation -- it is decided by TC39 of which we are a part of. When we have made design changes based on implementation experience, it has been discussed in the proposal, not in the implementation bug. If a proposal is a subset, as has been the case for private fields, it has been documented and is usually part of an epic, but this only impacts our implementation and not the feature as a whole.

This is really critical: When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked. Do not rely on the implementation bug. The details discussed around implementation are not relevant for this.

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion. Once you have a process you are happy with, you can let me know how I can help.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is (or should be) the norm. In the past I have requested the explainer to be improved before advancing for new features or have improved it myself, because that is where the information should be. 

Things still change in stage 3, so rehashing the proposals description may result in things going out of sync as well as being redundant. You should not be searching our bugs for details about how a TC39 feature is designed, we won't be discussing that because it isn't for us to decide in isolation -- it is decided by TC39 of which we are a part of. When we have made design changes based on implementation experience, it has been discussed in the proposal, not in the implementation bug. If a proposal is a subset, as has been the case for private fields, it has been documented and is usually part of an epic, but this only impacts our implementation and not the feature as a whole.

This is really critical: When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked. Do not rely on the implementation bug. The details discussed around implementation are not relevant for this.

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion. Once you have a process you are happy with, you can let me know how I can help.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

For the body text about what the change is, usually the expectation is that the feature explainer has all of this information. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is the norm. In the past I have requested the explainer to be improved before advancing for new features or have improved it myself, because that is where the information should be. 

Things still change in stage 3, so rehashing the proposals description may result in things going out of sync as well as being redundant. You should not be searching our bugs for details about how a TC39 feature is designed, we won't be discussing that because it isn't for us to decide in isolation -- it is decided by TC39 of which we are a part of. When we have made design changes based on implementation experience, it has been discussed in the proposal, not in the implementation bug. If a proposal is a subset, as has been the case for private fields, it has been documented and is usually part of an epic, but this only impacts our implementation and not the feature as a whole.

This is really critical: When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked. Do not rely on the implementation bug. The details discussed around implementation are not relevant for this.

It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion. Once you have a process you are happy with, you can let me know how I can help.

Otherwise, for identifying when something shipped when it is not directly clear: Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. It is part of the exposure guidelines -- I am guessing you are working for open docs, so you are likely looking at multiple implementations. Here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

Your comment however suggests that there might be more misunderstandings. Allow me to clarify and hopefully simplify the work that you do: The information you are looking for when you ask "what feature does this implement and how does it work?" is in the linked document. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is the norm. In the past I have requested the explainer to be improved before advancing for new features or have improved it myself, because that is where the information should be. 

This is really critical: When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked. Do not rely on the implementation bug. The details discussed around implementation are not relevant for this.

Along the lines of this specification/implementation split: It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion. Once you have a process you are happy with, you can let me know how I can help and I am happy to follow those guidelines.

Otherwise, for identifying when something shipped when it is not directly clear: This is where "intents" come into play. I already shared the intent to prototype for this bug. Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. If you are working on documentation for multiple browsers, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

Your comment however suggests that there might be more misunderstandings. Allow me to clarify and hopefully simplify the work that you do: The information you are looking for when you ask "what feature does this implement and how does it work?" is in the linked proposal repository. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is the norm. In the past I have requested the explainer to be improved before advancing for new features or have improved it myself, because that is where the information should be. 

This is really critical: When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked. Do not rely on the implementation bug. The details discussed around implementation are not relevant for this.

Along the lines of this specification/implementation split: It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion. Once you have a process you are happy with, you can let me know how I can help and I am happy to follow those guidelines.

Otherwise, for identifying when something shipped when it is not directly clear: This is where "intents" come into play. I already shared the intent to prototype for this bug. Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. If you are working on documentation for multiple browsers, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

Your comment however suggests that there might be more misunderstandings. Allow me to clarify and hopefully simplify the work that you do: The information you are looking for when you ask "what feature does this implement and how does it work?" is in the linked proposal repository. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is the norm. In the past I have requested the explainer to be improved before advancing for new features or have improved it myself, because that is where the information should be. 

This is really critical: When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked. Do not rely on the implementation bug. The details discussed around implementation are not relevant for this and are likely to be confusing.

Along the lines of this specification/implementation split: It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion. Once you have a process you are happy with, you can let me know how I can help and I am happy to follow those guidelines.

Otherwise, for identifying when something shipped when it is not directly clear: This is where "intents" come into play. I already shared the intent to prototype for this bug. Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. If you are working on documentation for multiple browsers, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

Your comment however suggests that there might be more misunderstandings. Allow me to clarify and hopefully simplify the work that you do: The information you are looking for when you ask "what feature does this implement and how does it work?" is in the linked proposal repository. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is the norm. In the past I have requested the explainer to be improved before advancing for new features or have improved it myself, because that is where the information should be. 

This is really critical: When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked. Do not rely on the implementation bug. The details discussed around implementation are not relevant for this and are likely to be confusing.

Along the lines of this specification/implementation split: It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion. Once you have a process you are happy with, you can let me know how I can help and I am happy to follow those guidelines in relation to the use of the labels.

Otherwise, for identifying when something shipped when it is not directly clear: This is where "intents" come into play. I already shared the intent to prototype for this bug. Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. If you are working on documentation for multiple browsers, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

Your comment however suggests that there might be more misunderstandings. Allow me to clarify and hopefully simplify the work that you do: The information you are looking for when you ask "what feature does this implement and how does it work?" is in the linked proposal repository. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is the norm. In the past I have requested the explainer to be improved before advancing for new features or have improved it myself, because that is where the information should be. 

This is really critical: When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked. Do not rely on the implementation bug. The details discussed around implementation are not relevant for this and are likely to be confusing.

Along the lines of this specification/implementation split: It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. We are not required to implement everything right away, so from a user perspective, a split between "the feature has been specified" and "firefox has implemented" is a useful one, as sometimes we implement a year or more later. I understood your process to be to eagerly document regardless of our implementation status. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion. Once you have a process you are happy with, you can let me know how I can help and I am happy to follow those guidelines in relation to the use of the labels.

Otherwise, for identifying when something shipped when it is not directly clear: This is where "intents" come into play. I already shared the intent to prototype for this bug. Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. If you are working on documentation for multiple browsers, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

Your comment however suggests that there might be more misunderstandings. Allow me to clarify and hopefully simplify the work that you do: The information you are looking for when you ask "what feature does this implement and how does it work?" is in the linked proposal repository, not in the bug. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is the norm. In the past I have requested the explainer to be improved before advancing for new features or have improved it myself, because that is where the information should be. 

This is really critical: When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked. Do not rely on the implementation bug. The details discussed around implementation are not relevant for this and are likely to be confusing.

Along the lines of this specification/implementation split: It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. We are not required to implement everything right away, so from a user perspective, a split between "the feature has been specified" and "firefox has implemented" is a useful one, as sometimes we implement a year or more later. I understood your process to be to eagerly document regardless of our implementation status. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion. Once you have a process you are happy with, you can let me know how I can help and I am happy to follow those guidelines in relation to the use of the labels.

Otherwise, for identifying when something shipped when it is not directly clear: This is where "intents" come into play. I already shared the intent to prototype for this bug. Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. If you are working on documentation for multiple browsers, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

Your comment however suggests that there might be more misunderstandings. Allow me to clarify and hopefully simplify the work that you do (which honestly, is hard and information is scattered): The information you are looking for when you ask "what feature does this implement and how does it work?" is in the linked proposal repository, not in the bug. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is the norm. In the past I have requested the explainer to be improved before advancing for new features or have improved it myself, because that is where the information should be. 

This is really critical: When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked. Do not rely on the implementation bug. The details discussed around implementation are not relevant for this and are likely to be confusing.

Along the lines of this specification/implementation split: It seems that your process has changed since I was working with the docs team in the past. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. We are not required to implement everything right away, so from a user perspective, a split between "the feature has been specified" and "firefox has implemented" is a useful one, as sometimes we implement a year or more later. I understood your process to be to eagerly document regardless of our implementation status. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion. Once you have a process you are happy with, you can let me know how I can help and I am happy to follow those guidelines in relation to the use of the labels.

Otherwise, for identifying when something shipped when it is not directly clear: This is where "intents" come into play. I already shared the intent to prototype for this bug. Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. If you are working on documentation for multiple browsers, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

Your comment however suggests that there might be more misunderstandings. Allow me to clarify and hopefully simplify the work that you do (which honestly, is hard and information is scattered): The information you are looking for when you ask "what feature does this implement and how does it work?" is in the linked proposal repository, not in the bug. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is the norm. In the past I have requested the explainer to be improved before advancing for new features or have improved it myself, because that is where the information should be. 

This is really critical: When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked. Do not rely on the implementation bug. The details discussed around implementation are not relevant for this and are likely to be confusing.

Along the lines of this specification/implementation split: It seems that your process has changed since I was working with the docs team in the past and I am happy to adapt. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. We are not required to implement everything right away, so from a user perspective, a split between "the feature has been specified" and "firefox has implemented" is a useful one, as sometimes we implement a year or more later. I understood your process to be to eagerly document regardless of our implementation status. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion. Once you have a process you are happy with, you can let me know how I can help and I am happy to follow those guidelines in relation to the use of the labels.

Otherwise, for identifying when something shipped when it is not directly clear: This is where "intents" come into play. I already shared the intent to prototype for this bug. Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. If you are working on documentation for multiple browsers, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

Your comment however suggests that there might be more misunderstandings. Allow me to clarify and hopefully simplify the work that you do (which honestly, is hard and information is scattered): The information you are looking for when you ask "what feature does this implement and how does it work?" is in the linked proposal repository, not in the bug. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. You mentioned that the "spec was excellent" this is good to hear, but it is important to emphasize that this proposal is not an outlier -- it is the norm. In the past I have requested the explainer to be improved before advancing for new features or have improved it myself, because that is where the information should be. 

This is really critical: When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked. Do not rely on the implementation bug. The details discussed around implementation are not relevant for this and are likely to be confusing.

Along the lines of this specification/implementation split: It seems that your process has changed since I was working with the docs team in the past and I am happy to adapt. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. We are not required to implement everything right away, so from a user perspective, a split between "the feature has been specified" and "firefox has implemented" is a useful one, as sometimes we implement a year or more later. I understood your process to be to eagerly document regardless of our implementation status. That said, the exposure guidelines are browser wide. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion. Once you have a process you are happy with, you can let me know how I can help and I am happy to follow those guidelines in relation to the use of the labels.

Otherwise, for identifying when something shipped when it is not directly clear: This is where "intents" come into play. I already shared the intent to prototype for this bug. Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. If you are working on documentation for multiple browsers, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails which I mentioned earlier. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

Your comment however suggests that there might be more misunderstandings and this is more pressing. You indicated that you expect the implementation bug to include the feature documentation itself. This is not the case, we do not design the features: The information you are looking for when you ask "what feature does this implement and how does it work?" is the linked proposal repository, not in the bug. The proposal is always linked. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. 

This is really critical: When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked. Do not rely on the implementation bug. The details discussed around implementation are not relevant for this and are likely to be confusing.

Along the lines of this specification/implementation split: It seems that your process has changed since I was working with the docs team in the past and I am happy to adapt. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. We are not required to implement everything right away, so from a user perspective, a split between "the feature has been specified" and "firefox has implemented" is a useful one, as sometimes we implement a year or more later. I understood your process to be to eagerly document regardless of our implementation status. That said, the exposure guidelines are browser wide. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion. Once you have a process you are happy with, you can let me know how I can help and I am happy to follow those guidelines in relation to the use of the labels.

Otherwise, for identifying when something shipped when it is not directly clear: This is where "intents" come into play. I already shared the intent to prototype for this bug. Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. If you are working on documentation for multiple browsers, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails which I mentioned earlier. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

Your comment however suggests that there might be more misunderstandings and this is more pressing. You indicated that you expect the implementation bug to include the feature documentation itself. This is not the case, we do not design the features: The information you are looking for when you ask "what feature does this implement and how does it work?" is the linked proposal repository, not in the bug. The proposal is always linked. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. 

This is really critical: When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked. Do not rely on the implementation bug. The details discussed around implementation are not relevant for this and are likely to be confusing.

Along the lines of this specification/implementation split: It seems that your process has changed since I was working with the docs team in the past and I am happy to adapt. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. 

I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. We are not required to implement everything right away, so from a user perspective, a split between "the feature has been specified" and "firefox has implemented" is a useful one, as sometimes we implement a year or more later. I understood your process to be to eagerly document regardless of our implementation status. That said, the exposure guidelines are browser wide and is established process. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion. Once you have a process you are happy with, you can let me know how I can help and I am happy to follow those guidelines in relation to the use of the labels.

Otherwise, for identifying when something shipped when it is not directly clear: This is where "intents" come into play. I already shared the intent to prototype for this bug. Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. If you are working on documentation for multiple browsers, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails which I mentioned earlier. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

Your comment however suggests that there might be more misunderstandings and this is more pressing. You indicated that you expect the implementation bug to include the feature documentation itself. This is not the case, we do not design the features: The information you are looking for when you ask "what feature does this implement and how does it work?" is the linked proposal repository, not in the bug. The proposal is always linked. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. 

This is really critical: **When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked** Do not rely on the implementation bug. The details discussed around implementation are not relevant for this and are likely to be confusing.

Along the lines of this specification/implementation split: It seems that your process has changed since I was working with the docs team in the past and I am happy to adapt. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . I believe this was initial documentation of the new feature which was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17. 

I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. We are not required to implement everything right away, so from a user perspective, a split between "the feature has been specified" and "firefox has implemented" is a useful one, as sometimes we implement a year or more later. I understood your process to be to eagerly document regardless of our implementation status. That said, the exposure guidelines are browser wide and is established process. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion. Once you have a process you are happy with, you can let me know how I can help and I am happy to follow those guidelines in relation to the use of the labels.

Otherwise, for identifying when something shipped when it is not directly clear: This is where "intents" come into play. I already shared the intent to prototype for this bug. Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. If you are working on documentation for multiple browsers, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails which I mentioned earlier. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

Your comment however suggests that there might be more misunderstandings and this is more pressing. You indicated that you expect the implementation bug to include the feature documentation itself. This is not the case, we do not design the features: The information you are looking for when you ask "what feature does this implement and how does it work?" is the linked proposal repository, not in the bug. The proposal is always linked. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. 

This is really critical: **When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked** Do not rely on the implementation bug. The details discussed around implementation are not relevant for this and are likely to be confusing.

Along the lines of this specification/implementation split: It seems that your process has changed since I was working with the docs team in the past and I am happy to adapt. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . This documentation was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17 as is part of our implement then ship split on many bugs. 

I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. We are not required to implement everything right away, so from a user perspective, a split between "the feature has been specified" and "firefox has implemented" is a useful one, as sometimes we implement a year or more later. I understood your process to be to eagerly document regardless of our implementation status. That said, the exposure guidelines are browser wide and is established process. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion. Once you have a process you are happy with, you can let me know how I can help and I am happy to follow those guidelines in relation to the use of the labels.

Otherwise, for identifying when something shipped when it is not directly clear: This is where "intents" come into play. I already shared the intent to prototype for this bug. Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. If you are working on documentation for multiple browsers, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails which I mentioned earlier. For example for this [bug](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/UjVKYf8Fnao/m/tFfKb4VbAgAJ). I will detail the "intent" process later. 

Your comment however suggests that there might be more misunderstandings and this is more pressing. You indicated that you expect the implementation bug to include the feature documentation itself. This is not the case, we do not design the features: The information you are looking for when you ask "what feature does this implement and how does it work?" is the linked proposal repository, not in the bug. The proposal is always linked. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does. 

This is really critical: *When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked* Do not rely on the implementation bug. The details discussed around implementation are not relevant for this and are likely to be confusing.

Along the lines of this specification/implementation split: It seems that your process has changed since I was working with the docs team in the past and I am happy to adapt. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . This documentation was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17 as is part of our implement then ship split on many bugs. 

I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. We are not required to implement everything right away, so from a user perspective, a split between "the feature has been specified" and "firefox has implemented" is a useful one, as sometimes we implement a year or more later. I understood your process to be to eagerly document regardless of our implementation status. That said, the exposure guidelines are browser wide and is established process. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion. Once you have a process you are happy with, you can let me know how I can help and I am happy to follow those guidelines in relation to the use of the labels.

Otherwise, for identifying when something shipped when it is not directly clear: This is where "intents" come into play. I already shared the intent to prototype for this bug. Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. If you are working on documentation for multiple browsers, here is an example from chrome [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1213927) and here is their [intent to ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/di9BL9d1CKI/m/G2OM5JG4AQAJ?utm_medium=email&utm_source=footer). 

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the [process](https://tc39.es/process-document/)), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is [here](https://wiki.mozilla.org/ExposureGuidelines) -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in. 

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.