Expectations for standards-positions with only an explainer (pre-spec)

[zcorpan]

Context: #806 (comment)

Requesting standards-position before a spec exists i OK and encouraged, so that we can engage sooner. However we may need to update documentation about this to clarify what is expected for both the reporter and for Mozilla for such issues.

[dveditz]

There's nothing wrong with private feedback on a new proposal, but our standards position process doesn't seem like the place for it. Technically feedback here is given in public so it's not private feedback, but the audience is narrow so it's not functionally a "public" proposal either. I'd be more comfortable using our "standards" positions to give feedback on proposals that have at least been presented for discussion in one of the standards groups we participate in. Benefits:

• chance for feedback from people who don't think like browser-engine developers (web app and server devs)
• more clarity on IP rules for the proposal

[martinthomson]

I agree with Dan. It is perfectly fine to ask for input on just about anything here. But we might decline to engage or defer engagement for work that is clearly incomplete. Coming here might be a good way to make us aware of something when it is very early, but it is better in every respect to discuss work in standards groups. If not immediately, then as soon as possible.

[johannhof]

It's not entirely clear to me what's being discussed here: Feedback before a spec exists or feedback on private proposals?

From a (personal) Chrome perspective, I do think it's helpful for us to be able to get very early and non-committal "this seems non-harmful" signals from Mozilla to figure out the fundamental questions before we've done a lot of work on a spec (which in the Blink launch process usually means there's also already a prototype implemented in Chrome). The common alternative is back-channeling feedback from Mozillians we have existing relationships with, which has a lot of disadvantages.

But I think that largely exists through Mozilla giving feedback on CG proposals (without a spec), and (not considering IP complications) it seems non-harmful to me to extend the same treatment to privately hosted proposals on a per-case basis where it makes sense, as Martin suggests.

I think a different question is whether Mozilla should give out "actionable signals" (specifically regarding the Blink Intent to Ship) to proposals without a spec. We had a very recent case where an old "defer" decision from Mozilla was used in an I2S and subsequently got delayed on significant feedback from Martin. We could try to solve this on Blink side and avoid or double-scrutinize I2S with "defer" signals, but this isn't perfect because "defer" could mean either "we're not ready yet, don't ask us" or "the proposal isn't ready yet, please ask us later". Maybe it makes sense to split the two positions so that we can disallow the latter in the Blink launch process.

cc @RByers as proxy for API Owners