Consider renaming worth prototyping (or adding a label)

[annevk]

As noted in #184 by @padenot and elsewhere by others, "worth prototyping" is not a great fit for things we're supportive of and already ship. "important" is the only alternative, but generally reserved for more important things.

Shall we rename "worth prototyping" to "supportive" or some such?

[bholley]

I like "supportive".

I've also seen a related problem wherein we decide we're supportive of some parts, but think certain specific parts are harmful, and then sort of split the difference with non-harmful (i.e. #194 (comment)).

It would be nice to also brainstorm better solutions to this while re-thinking the taxonomy.

[dbaron]

Do we want "supportive" and "supportive with caveats"?

[bholley]

Do we want "supportive" and "supportive with caveats"?

That seems reasonable, assuming we think "with caveats" is strong enough to convey "we think this is harmful now but believe the harmful bits can be excised with sufficient work". I think it's probably sufficient for practical purposes, but would be interested to hear other opinions.

[martinthomson]

I suspect that it will always be the case that we have caveats on support for any feature. So the more terse label is probably OK provided we document the fact that any spec, in any stage of deployment (including shipped in Firefox; including stuff Mozilla developed) likely has aspects we would rather be different.

There are cases that are truly "mixed" in the sense that there are good things and bad things. The question is whether we can find ways to split them.

[bholley]

I wonder if we should allow a mixed position? I worry that just marking something with known deal-breakers as worth prototyping carries the risk that the nuance will be lost and our position will be misconstrued.

[marcoscaceres]

Can I throw some support behind "supportive". I think it would make sense for #28, for instance.

[martinthomson]

Apple's approach is simple: opposed, neutral, supportive. Obviously there is plenty of space for nuance here, but that might be worth aligning on. It's certainly less confusing.

That would mean losing the double-plus "important" and the more negative connotations of "harmful", but I'm starting to think that is OK.

When our position is complicated (some negative, some positive) we can use neutral and some exposition; note that our position is rarely 100% positive or negative. We always hold out some hope that an idea can find a way to make a positive contribution to the web; likewise, we have to always be aware of the risk of making any change, whether that be unexpected harms, complications in deployment and implementation, or just failure in the market.

[bholley]

I generally like the idea of simplifying the taxonomy and aligning with Apple and mapping important and worth-prototyping to "supportive", non-harmful to "neutral", and harmful to "opposed".

My one concern is that I think "neutral" connotes a degree of disinterest which is appropriate for a lot of our "non-harmful" positions but not for the ones where we're enthusiastic about some parts but consider something a deal-breaker. If we want to split the difference (as we have occasionally done in the past) I think we should add "mixed" alongside "neutral". The alternative approach is just to mark anything with deal-breakers as "opposed", though that may work better in some situations than others.

[bgrins]

They also have "concerns" tags defined, which combined with the 3 positions (and comments in the issue) might be able to communicate that important nuance without introducing "mixed". At the moment their most used concern label is "integration" and it happens that its only applied to opposed or non-positioned issues (https://github.com/WebKit/standards-positions/labels/concerns%3A%20integration) but I could certainly imagine that being applied to neutral or even supportive issues.

[bgrins]

For reference, from https://github.com/WebKit/standards-positions/labels:

concerns: compatibility
concerns: complexity
concerns: duplication
concerns: integration
concerns: internationalization
concerns: interoperability
concerns: performance
concerns: privacy
concerns: security
concerns: usability

and

position: neutral
position: not considering
position: oppose
position: support
position: under consideration

[bholley]

I suspect that even if we attached concerns labels to neutral or supportive positions, those caveats would frequently get lost when other actors cite our position on a proposal.

[hober]

I suspect that even if we attached concerns labels to neutral or supportive positions, those caveats would frequently get lost when other actors cite our position on a proposal.

FWIW, as the person who heavily based WebKit's standards-positions repo on yours, I don't think there's much we can do to fix that citation problem. There are so many "Safari: no public signals" where we've repeatedly, publicly made our stance clear. I've mostly given up.

[hober]

That said, we intentionally chose not to use IETF-y terms of art like "considered harmful," primarily because our audience may not be familiar with them and may misinterpret them as a result.

[bgrins]

Re-reading:

My one concern is that I think "neutral" connotes a degree of disinterest which is appropriate for a lot of our "non-harmful" positions but not for the ones where we're enthusiastic about some parts but consider something a deal-breaker

I think the what to do when we consider one aspect a deal-breaker is actually a challenge that's somewhat decoupled from the ultimate position (and also isn't easy to deal with using our current position tags).

As an example, let's say there's a new API which has a major accessibility problem as written. We may be supportive of what the API does otherwise, neutral on it, or opposed to it.

• If we're otherwise supportive, then worth-prototyping / supportive isn't a great position (since shipping with the accessibility problem would potentially make it harmful). Even taking it down a notch to non-harmful / neutral isn't correct under the same reasoning. In the proposed terminology, "mixed" is appropriate here.
• If we're otherwise neutral, then non-harmful / neutral isn't a great position (since shipping with the accessibility problem would potentially make it harmful). In the proposed terminology, "mixed" would not be appropriate here as we aren't mixing any positivity with the concern.
• If we're otherwise opposed the solution is easy -> tag it as harmful (as resolving the accessibility concern doesn't change the position).

How we've handled this in recent cases (like #664 (comment)) is withhold a position (either just not label or mark under consideration), but raise the concern both in s-p and in the upstream spec. Then if we get to a good resolution then go back to the typical process and set a position.

For this to work, I think a few things need to be true generally speaking: (a) we need to be responsive to the initial request (when we're most likely to get engagement and changes upstream) (b) spec authors need to be responsive to the concerns and work to resolve them (or convince us the concerns are wrong) and (c) there needs to be an achievable resolution that fits within the design constraints and goals of the spec.

If for whatever reason we don't get to a resolution on the specific concern, then it's not super clear to me what to do with it. Maybe tagging with a concern and then leaving it in a defer state?

[bgrins]

FWIW I also like the proposal to align with Apple's taxonomy for positions w/ "support", "neutral", "oppose".

Then for the other two states there's already "under consideration" with the same definition, and "defer" is almost the same as "not considering" (with Mozilla's including "at all"). I don't care much either way how we name that one.

• "defer - Mozilla does not intend to look at this specification at all in the near future."
• "not considering - WebKit does not intend to look at this specification in the near future."

[bholley]

Yeah, we can certainly withhold a position, or temporarily mark it as "opposed", and try to get the issues resolved — particularly if we do a better job of keeping up with inbound (as I think we have been recently).

I am fine to see if we can handle all of these cases that way. I mainly object to using "neutral" to split the difference as we've done in the past. If we find the need to do that in the future, we can revisit adding "mixed".

[martinthomson]

OK, it sounds like a rationalization of the positions is getting some support.

I want to punt on "mixed" as well. As for hedging, let's not do that as much. I think that in Brian's examples we should generally err on the side of negativity until major issues are resolved. That might mean an otherwise great spec is marked "opposed" until we are satisfied that the huge accessibility problem has been addressed.

I realize that in some cases the problems might be smaller, larger in number, and nuanced, which might lead us toward hedging because on balance the effect would be "neutral". That's always the case: part of the problem here is that we need to plot out where we think things are headed and factor in the ways in which proposals might evolve. Apple's "concern: X" tags are a way of flagging that, and we might want to consider them. For now, we can stick to what we are doing and use words.

(I also like "opposed" over "harmful" because it is less of an absolute. "Harmful" always struck me as a statement for everyone as opposed to just being a statement about what Mozilla thinks.)

[bholley]

SGTM

[tomayac]

FWIW, Chrome uses the following terminology:

• For Signals from developers in an intent-to-ship:

Signal	Required evidence
No Signal	Link to outreach attempts that remained unanswered. This is different from N/A.
Positive	There is evidence of publicly linkable positive statements of support from developers or framework authors not associated with or not speaking on behalf of a browser vendor: Online social networking sites like Twitter. Version control sites like GitHub. Discussion boards like WICG Discourse. Personal sites like blogs. Support sites like StackOverflow. Bug trackers like crbug (including the "star" signal[1]). Working Group call minutes that included industry participants like this. Authorized quotes from an important partner that they will try it and why like on blink-dev@. Client-side implementations of libraries that (in part, if not fully doable on the client-side) do what the feature proposes, like, for example, NoSleep.js for the Screen Wake Lock API.Feature reached TC39 stage 3.
Mixed	There are signals that point in both positive and negative directions. Link to representative examples of each. This situation can happen if there is some amount of developer disagreement or controversy regarding a feature.In such cases, also add explanatory text about the reasoning for how the negative feedback is outweighed by the positive, and how the feature design mitigates the legitimate concerns represented by the negative feedback.
Neutral / Negative	There is evidence of publicly linkable neutral / negative statements of support from developers or framework authors not associated with or not speaking on behalf of a browser vendor: Version control sites like GitHub. Discussion boards like WICG Discourse.Personal sites like blogs.Support sites like StackOverflow. Bug trackers like crbug (including the "star" signal). Working Group call minutes that included industry participants like the W3C’s archives. Authorized quotes from an important partner that they will not try it and why like on blink-dev@. In such cases, also add explanatory text about the reasoning for how the feature design mitigates the legitimate concerns represented by the negative feedback.
N/A	Indication of why a Web / Framework Developers Signal is not needed in this case and no outreach attempt was made. This is different from No Signal.

• For Signals from other implementations in an intent-to-ship:

Signal	Required evidence
No Signal	Link to Official Standards Signal Process issue or thread that is not yet complete
Shipped/Shipping	Link to public documentation or bug/issue that demonstrates the issue has shipped (i.e., an issue that links to patches that have been merged, or a comment that a previously disabled feature is now enabled by default).
In Development	Link to public documentation or bug/issue clearly indicating feature is in development (not just filed as a bug or under consideration). When in doubt, follow the Official Standards Signal Process
Positive	Statement made through an Official Standards Signal Process for that implementation
Neutral	Statement made through an Official Standards Signal Process for that implementation
Negative	Statement made through an Official Standards Signal Process for that implementation
	Statement made through an Official Standards Signal Process for that implementation (see Gecko in particular; try not to use it for WebKit)
N/A	Indication of why an Official Standards Signal is not needed in this case

[tantek]

I like the direction of simplifying our positions labels, and some degree of harmonizing for better communication.

Rephrased from what I shared in some private discussions earlier this week:

I think "support" may inadvertently convey a stronger meaning than what we intend a lot of the time. Similarly "oppose".

One thing that other browsers explicitly look for are "positive signals" or absence of "negative signals", so I think it may be better to directly use such terms, e.g.

"positive", "neutral", "negative"

More:

In my opinion this also reads better for evaluations of proposals which in their current state have more disadvantages than advantages, we can mark them "negative" without completely discouraging someone with "oppose" which sounds more like something we’d actively fight.

Similarly, a lot of the time we don’t want to say "Mozilla supports X" if we think something has promise but has lots of holes to fill in or other problems. Such an expression may have the unintended consequence of discouraging (or deprioritizing) active work on the issues we file for such holes/problems. Also "support" is an overloaded term, that I’d expect broader audiences to possibly misinterpret as indicative of product plans.

I believe "positive, neutral, negative" will more accurately convey what we mean than current labels, with less chance of misinterpretation (whether intentional or not) than the alternatives.

(Originally published at: https://tantek.com/2022/238/t1/)