Add a standards positions URL field to the schema

[ddbeck]

I think the best way to capture that would be a standards_positions field that can link to issues in https://github.com/mozilla/standards-positions or https://github.com/WebKit/standards-positions.

Originally posted by @foolip in #183 (comment)

[captainbrosset]

I think there are discussions to do this in BCD too. Also worth noting that Chrome and Edge don't have a standards positions repo.

[foolip]

Alternatively we ask the maintainers of those repos to use some tagging mechanism so they can maintain the mapping. For chromestatus that's what I'd like to do at least.

[captainbrosset]

I do think we need something here. For both BCD and web-features. It's different to say "this feature is not yet implemented in browser X", than to say "this feature is not implemented in browser X, see browser X's position about it at ...".

Currently, neither BCD and web-features tell this story, and I think it would be useful for web developers to know. They might be contemplating using an API, without knowing that it will simply never be implemented in some browser (that is, unless the feature's design changes substantially).

---

Example: Idle Detection

Baseline badge and BCD table

They both simply say that the feature is not supported:

Standards positions

They tell a different story

• Mozilla: https://mozilla.github.io/standards-positions/#idle-detection-api

  We are concerned about the user-surveillance, user-manipulation, and abuse of user resources potential of this API ...

• WebKit: https://lists.webkit.org/pipermail/webkit-dev/2020-October/031565.html

  Unless a significant new development is being made in either one of the issues we've raised, our position will remain to object to the addition of this API unless otherwise stated regardless of whether we continue to say so in public or not.

---

Deciding if the data should be maintained in those positions repos (by using tags that match our web-features' IDs), or in the present repo or in BCD (by using boolean statuses and links) seems like an implementation choice we can always change later.

@Elchi3 I seem to remember BCD wanting to collect this information. Did this happen?

I'd also value @jgraham's and @annevk's points of view on this issue. Would you be open to adding a field in your positions JSON data that maps back to the web-features maintained here?
For Idle Detection, for Mozilla for example, this could like this:

  {
    "ciuName": null,
    "description": "This document defines a web platform API for observing system-wide user presence signals.",
    "id": "idle-detection-api",
    "mozBugUrl": "",
    "mozPosition": "negative",
    "mozPositionDetail": "We are concerned about the user-surveillance, user-manipulation, and abuse of user resources potential of this API, despite the required 60 second mitigation. Additionally it seems to be an unnecessarily powerful approach for the motivating use-cases, which themselves are not even clear they are worth solving, as pointed out in <a href=\"https://lists.webkit.org/pipermail/webkit-dev/2020-October/031562.html\">https://lists.webkit.org/pipermail/webkit-dev/2020-October/031562.html</a>",
    "mozPositionIssue": 453,
    "org": "Proposal",
    "title": "Idle Detection API",
    "url": "https://wicg.github.io/idle-detection/",
    "web-features-tag": "idle-detection"
  },

[hober]

@captainbrosset wrote:

For both BCD and web-features. It's different to say "this feature is not yet implemented in browser X", than to say "this feature is not implemented in browser X because they oppose this feature of the web platform, learn more at ...".

"because they oppose this feature of the web platform" is poor framing that presumes a disputed outcome—if a feature is only implemented in one engine, it's by definition not part of the web platform.

[ddbeck]

I think this continues to be a nice-to-have (it'd be helpful for confirming the results of computed statuses, for instance), but I don't think we should put any effort into a schema until there's a consumer that's actually going to attempt to tell a story to web developers with such data.

Last I heard, there was not enthusiasm on MDN or caniuse's part to make this information prominent. Until we hear from someone saying that they're going to do something with this data, I'd prefer to see what Philip suggested in #186 (comment).

[captainbrosset]

@hober wrote:

"because they oppose this feature of the web platform" is poor framing that presumes a disputed outcome—if a feature is only implemented in one engine, it's by definition not part of the web platform.

Thanks for the feedback, I agree about removing the "web platform" part of it and I've updated my comment to say "this feature is not implemented in browser X, see browser X's position about it at ..." instead.

[captainbrosset]

@ddbeck I agree with not doing anything until consumers of the data share a need for this with us. And I also prefer Philip's suggestion, which is why I'd like to hear what folks who maintain browser position repos think about adding web-features IDs to their data.

[annevk]

FWIW, I think we'd probably accept patches, but I'm not sure about actively investing in the accuracy of that data.

[jgraham]

I think there are use cases for this which don't depend on user-facing consumers.

For example for Interop if a proposal corresponds to a web-feature (which hopefully is the most common case, particularly if we support features being defined before implementations ship) we could automatically pull in the s-p data from different vendors so it wouldn't require additional manual effort to find vendor's existing positions on the feature.

[atopal]

@annevk you mean you'd accept patches for the https://github.com/WebKit/standards-positions repo? If we follow Philip's proposal, once we tag those positions with the Web Feature identifiers, you'd only need to keep the repo itself up to date.

[captainbrosset]

I just proposed this PR for Mozilla: mozilla/standards-positions#1034
I plan on opening a similar one for WebKit.

[captainbrosset]

And here is the PR for WebKit: WebKit/standards-positions#357.

@foolip what about chromestatus.com? Is there ongoing work to also map features there?

[foolip]

@foolip what about chromestatus.com? Is there ongoing work to also map features there?

It's not being worked on right now, but there is a plan! Each chromestatus entry would get a web-features ID, replacing the categories we currently have.

cc @past

[captainbrosset]

For information, and to revive this thread, the WebKit and Mozilla PRs didn't go very far. Both repos want to use labels on issues to track the info about a position. Only repo maintainers would be able to add new labels (e.g. web-features:grid) on position issues.
I didn't get the impression that either wanted to commit to doing this, and the discussions died down.

Should we add a standard-position field to our features? @ddbeck ? @atopal ?
I know we're trying to only add the fields that are strictly necessary to generate the data for a feature, and leave it to other data sources to points to us via our unique IDs. But there are also cases, like these ones, where it's either not practical to do so, or perceived as too much work.

Another example of it seeming like too much work is web-platform-tests/interop#693.

[atopal]

Thanks for reviving Patrick! For standards positions, I'd try again to see if there is a way, but ultimately it might still be a good idea to handle that in Web Features, since we may take that into account for future availability statuses, they are very limited in number and will very rarely change, so the maintenance burden should be low.

For developer signals from Interop items, I'm not so sure about that, there are so many possible sources of signals for developer needs, it seems like this would set a bad precedent; also because those won't impact the availability status. I think your suggestion of tagging or in some other way marking them with web-feature-ids in the Interop repo makes much more sense.

[dontcallmedom]

There is undoubtedly value in mapping standard positions to Web Features, and I think this group is well positioned to do so as we review features and their implementations. I'm not sure it needs to be part of the main Web Features dataset or package - iow, it could be maintained by us out of band, either as a separate file (there aren't so many to track in the first place), or a in a separate repo altogether.

[ddbeck]

I'm neutral on adding standards positions URLs to web-features. An out-of-band experiment would be a good step, to figure out what proportion of (non-Baseline) features would even have a standards position associated with it—if mapping proves especially challenging, it'd be nice to know that before we merge new data and code into web-features.

That said, if they were added to web-features, then I'd like their introduction to include:

• Linting for validity. I didn't really like the usage stats URLs because the only checking we did was against a regex. It was still rather easy to introduce incorrect URLs. Ideally, we'd get an inventory (or inventories) of vendors' standards positions URLs (or make one ourselves, like I've done for MDN content).

• Dropping URLs as soon as they become historic. Again, ideally, I'd like something like this to happen: if a vendor ships a feature, we drop that vendor's standards position URL as soon as that information propagates to us from BCD.

• A use case. Even if it's initially only the web-features explorer, I'd like there to be some consumer for the data. I think my earlier comment didn't actually bear fruit. I can recall one time I was curious enough to go looking for a standards position while authoring or reviewing a feature. Standards positions are not obviously useful for authoring, so I'd like there to be some realistic expectation that the data's going to be used somewhere.

[captainbrosset]

A use case. Even if it's initially only the web-features explorer, I'd like there to be some consumer for the data. I think my earlier comment didn't actually bear fruit. I can recall one time I was curious enough to go looking for a standards position while authoring or reviewing a feature. Standards positions are not obviously useful for authoring, so I'd like there to be some realistic expectation that the data's going to be used somewhere.

I can commit to adding this to the explorer. In fact, there's already a link to search for standard positions on feature pages. For example: https://web-platform-dx.github.io/web-features-explorer/features/file-system-access/ shows that Firefox and Safari do not support the API. Clicking on the Search for standards position links takes you to Mozilla and WebKit's standards position repositories, and you then have to go and find the position issue yourself.
Ideally, if they exist, those links would take you to https://mozilla.github.io/standards-positions/#native-file-system and https://webkit.org/standards-positions/#position-28 instead.

[captainbrosset]

Maintaining this out of band would, I think, be the right thing to do here. In fact, I can see how a JSON mapping of web-features ID to standards-position URLs could be useful to others too. I know BCD has wanted something like this too.

Are folks here ok if I create a new repo under our GitHub organization to get this started? Does this seem like the right first step?

[tidoust]

Are folks here ok if I create a new repo under our GitHub organization to get this started?

That seems a good idea. It's also a good way to eat our own dog food ;)

Dropping URLs as soon as they become historic.

If we do it out of band, I would actually prefer that we preserve the information: these URLs should be relatively stable, and the information can help with historical analyses (be it only to measure average durations between events in the lifecycle of a feature).

[jgraham]

FWIW I think the missing piece on getting vendors interested here is more likely about not seeing how the workflow will work, or understanding the value proposition vs technical concerns about where the data is stored. Or at the least I think the technical concerns can be resolved if the use cases are strong enough.

Trying to store these mappings outside of standards positions is a workaround that doesn't seem sustainable in the longer term, and only seems worthwhile for prototyping the system to understand the challenges.

So, what do I think the long term should look like? Well:

• When someone starts working on a spec and it's reached the level of stability that they want to get formal input from others, or start prototyping an implementation, they define a web feature.
• Initially this feature should be considered mutable. That's pretty different from the kinds of features we've defined so far which are mostly well-established and might be expected to grow, but not change.
• The feature name is used in all the following situations:
  • Submitting a standards position request
  • Publishing an Intent (e.g. to implement or to ship)
  • Other communications relating to the feature.
• It is the responsibility of the person requesting the s-p or writing the Intent to ensure that the feature is defined, and matches their plans.
• In the case where the plans don't match the feature that is clearly documented and we have some clear escalation process. For example if browser A proposes a large feature X and browser B decides that they are only interested in some subset X', we need to resolve that e.g. by splitting the feature into separate X' + X'', which can get different statuses.
• Other vendor published data (e.g. use counters, release notes) uses the feature name wherever it makes sense.

The goal here is that it's easy to understand the status of in-progress or partially implemented platform features without needing to manually read a lot of different data sources, and piece together which of them are relating to the same functionality. That's definitely a pain point, and whilst sometimes one can use spec names to solve it, often that doesn't work.

I think in terms of process, getting a commitment that people will do the work to define a feature and provide the feature name when communicating about the feature is more important than getting people to agree up-front to a standardised way of storing that information if it happens to be provided. Even if people provide the feature name as plain text (e.g. in an intent email or s-p request) it should be possible to parse that out much of the time, assuming there's a template that they're using. Once that's working and people see the value there's a lot more motivation to solve the "how do I store this in a more structured way" question (which for GH labels could be something like an action that can parse out the feature from the issue, check it's a real feature, and then automatically create a label if it is).

[captainbrosset]

When someone starts working on a spec and it's reached the level of stability that they want to get formal input from others, or start prototyping an implementation, they define a web feature.

I like the idea of reserving feature IDs early in time. I remember this group talking about this a few times already, and I recall general agreement.

I'm less excited about the they define a web feature part. Much as I'd love for people to do it, I don't really see it happening because I fear it'll be perceived as one more manual step in an already long and complex process.
How can we make this easy/transparent/fast enough for it to happen every time? I don't know ... Happy to hear proposals.
After that, I agree that it's easy enough to change the template used in intent emails, or in new s-p issues.

[captainbrosset]

As for a short term fix, while waiting for web-features to become a fully integrated part of the platform evolution process, how's this:

1. Create a new repo in this GH org
2. Add a big JSON file to it which maps web-features IDs to WebKit and Mozilla standards positions issues
3. Optionally add a CI script that periodically gets the actual position (positive/support, neutral, negative/oppose, defer, ...) for each known standards position and updates the JSON with it.
4. Update the explorer to use and present this data somewhere in the UI.

More context on the way WebKit and (soon) Mozilla manage their standards positions:

• They both have a GitHub repo where issues constitute the source of truth for positions.
• Mozilla is in a bit of a mixed situation right now, with some positions as issues, others on a website, others in a JSON file. But they're moving to using issues only, like WebKit.
• New issues are filed to request them to state a position about a feature.
• Issue may have a position: ... label or not. Issues that do have this label have received a position. Others haven't (yet).
• Positions may be positive, neutral, negative, or sometimes defer.

Here is how I envision our JSON mapping file to be:

[
  // Positive position
  {
    webFeatureID: "nesting",
    positions: {
      mozilla: {
        link: "https://github.com/mozilla/standards-positions/issues/695",
        position: "positive"
      }
      webkit: {
        link: "https://github.com/WebKit/standards-positions/issues/69",
        position: "support"
      }
    }
  },
  // No position
  {
    webFeatureID: "eyedropper",
    positions: {
      mozilla: {
        link: "https://github.com/mozilla/standards-positions/issues/557"
      }
      webkit: {
        link: "https://github.com/WebKit/standards-positions/issues/29"
      }
    }
  },
  // Negative position
  {
    webFeatureID: "file-system-access",
    positions: {
      mozilla: {
        link: "https://github.com/mozilla/standards-positions/issues/154"
      }
      webkit: {
        link: "https://github.com/WebKit/standards-positions/issues/28",
        position: "oppose"
      }
    }
  }
]