Align Mozilla signal options with actual Mozilla signals

[jyasskin]

Chrome Status's options for Firefox signals include all of:

• Shipped/Shipping
• In development
• Positive
• No signal
• Negative
• Neutral
• N/A
• Under consideration
• Important
• Worth prototyping
• Non-harmful
• Defer
• Harmful

Mozilla's standards positions repository only lists:

• positive
• neutral
• negative
• defer
• under consideration

In mozilla/standards-positions#680, @martinthomson mapped "important" and "worth prototyping" to "positive", "non-harmful" to "neutral", and "harmful" to "negative".

We should align with those changes, and stop offering developers so many options to pick from that they can miss the right option.

I propose that we put the remaining options in the following order:

• No signal
• N/A
• Under consideration
• Defer
• Positive
• Negative
• Neutral
• In development
• Shipped/Shipping

I'm not certain we should include "In development"; it probably depends on whether the API owners consider that a replacement for asking explicitly.

The code for this is at

chromium-dashboard/client-src/elements/form-field-enums.js

Lines 269 to 287 in 4dda7c5

	export const VENDOR_VIEWS_COMMON = {
	SHIPPED: [1, 'Shipped/Shipping'],
	IN_DEV: [2, 'In development'],
	PUBLIC_SUPPORT: [3, 'Positive'],
	NO_PUBLIC_SIGNALS: [5, 'No signal'],
	OPPOSED: [7, 'Negative'],
	NEUTRAL: [8, 'Neutral'],
	SIGNALS_NA: [9, 'N/A'],
	};
	export const VENDOR_VIEWS_GECKO = {
	...VENDOR_VIEWS_COMMON,
	GECKO_UNDER_CONSIDERATION: [10, 'Under consideration'],
	GECKO_IMPORTANT: [11, 'Important'],
	GECKO_WORTH_PROTOTYPING: [12, 'Worth prototyping'],
	GECKO_NONHARMFUL: [13, 'Non-harmful'],
	GECKO_DEFER: [14, 'Defer'],
	GECKO_HARMFUL: [15, 'Harmful'],
	};

[martinthomson]

Thanks @jyasskin, this looks good. With respect to "in development" or "shipped", we do generally say that just because we ship it, that doesn't mean we think that it is good. That is, what we think of something is somewhat orthogonal to whether we like it.

That said, I think that something that ships tends to supersede negative positions to some extent. That's not true for something that might be in development. How an "in development" position is determined is less robust than our standards position process, especially given how our project operates. I would prefer if you just dropped that one from the table, at least for us.