Need to add a bunch of specs. How?

[foolip]

w3c.github.io:

• https://w3c.github.io/keyboard-lock/
• https://w3c.github.io/longtasks/
• https://w3c.github.io/deviceorientation/spec-source-orientation.html
• https://w3c.github.io/staticrange/
• https://w3c.github.io/touch-events/
• https://w3c.github.io/uievents/
• https://w3c.github.io/web-nfc/
• https://w3c.github.io/webvr/spec/latest/

wicg.github.io:

• https://wicg.github.io/media-capabilities/
• https://wicg.github.io/netinfo/
• https://wicg.github.io/web-share/

drafts.csswg.org:

• https://drafts.csswg.org/css-scroll-anchoring/

[foolip]

I am beginning to suspect that there's no process for getting new specs into specref when they're spawned at the W3C. @sideshowbarker, is there something we could do about that? For example, check all public GitHub repos in the w3c org, and do a thing.

[strugee]

I believe if those are published under w3.org they should be pulled in automatically?

[tobie]

I am beginning to suspect that there's no process for getting new specs into specref when they're spawned at the W3C.

Specref gets its W3C data from tr.rdf and its WICG data from https://github.com/WICG/admin/blob/gh-pages/biblio.json (it seems like the WICG folks don't keep it up to date—@marcoscaceres, is there something that could be done to improve this?).

There's no clear data source for in progress CG work as far as I know, so maybe your idea to scrape github is the best approximation we can get for this?

The CSS drafts spec repo should be a lot easier to handle, we can probably even do it directly with the API provided by @plinss, see: https://drafts.csswg.org/api/.

[marcoscaceres]

For WICG it's complicated because not all repos end up having a spec (this is by design).

For when specs do emerge, they should really only end up in Specref iff:

1. they complete incubation and get moved to a W3C WG, in which case they enter specref automagically via tr.rdf.
2. Another spec cites that work (thus requiring the cited spec to be added to biblio.json manually (again, this is kinda by design... otherwise spec ref ends up having random/half-baked docs in it, which we should avoid).

We should be encouraging fast incubation and transition of WICG things to real W3C specs - and SpecRef serves as a small gate keeper there :)

[sideshowbarker]

I am beginning to suspect that there's no process for getting new specs into specref when they're spawned at the W3C. @sideshowbarker, is there something we could do about that?

Sure. But as far as I can see @tobie is already on top of this, and his comment at #397 (comment) seems to indicate as much.

Looking through the w3c.github.io specs in the list in the description for this issue, I believe the issue with all of them is that each is either:

• a spec that has never yet actually been published by the W3C, as a FPWD at least; or
• a spec that was published as a WD but subsequently demoted to a Note — which is the case with https://www.w3.org/TR/orientation-event/

The one exception to that I find in the list is https://w3c.github.io/uievents/. That was published at https://www.w3.org/TR/uievents/, so I would expect it’d show up in Specref. If it really doesn’t than I guess we need to figure out why, and fix something.

To be clear, something published only as an Editor’s Draft with a W3C logo on it but never yet as a FPWD has no actual recorded existence as far as the W3C publication-tracking systems go.

[marcoscaceres]

To be clear, something published only as an Editor’s Draft with a W3C logo on it but never yet as a FPWD has no actual recorded existence as far as the W3C publication-tracking systems go.

As it should be. The bar for publishing something "officially" is pretty low across most of the orgs we cover. We should at least demand that before we add things to specref.

[sideshowbarker]

The bar for publishing something "officially" is pretty low across most of the orgs we cover.

Yeah, though the effort to which W3C working groups go to ensure something gets published as FPWD as soon it can/should, that varies a lot among working groups.

We should at least demand that before we add things to specref.

Agreed in principle but also take a look through the list of w3c.github.io specs in the description for the issue, and see if there are any there which you believe are mature enough and/or have enough implementation in the platform already that we should be including them.

I guess one important question to ask is whether we have any other specs that are normatively referencing any of them. If we do have another spec normatively referencing something, then it seems like we ideally should have a means for facilitating references to it.

[foolip]

The background for this is that I'm trying to get "all" specs into https://foolip.github.io/day-to-day/, at the very least spec-like things that have test-like things in web-platform-tests.

The things I listed I believe are far along enough that they belong in specref, the question of auto-populating specref with anything that shows up in WICG is another one.

I'll see about fixing https://w3c.github.io/uievents/ by just added an edDraft entry now.

[foolip]

I fixed that in #402.

[marcoscaceres]

The things I listed I believe are far along enough that they belong in specref, the question of auto-populating specref with anything that shows up in WICG is another one.

Ok, the WICG ones are easy to add manually. Unfortunately, that's probably the best we can do for now.

[foolip]

I'm doing a PR for biblio.json now, if it keeps coming up on a regular basis let's revisit.

[tobie]

I guess one important question to ask is whether we have any other specs that are normatively referencing any of them. If we do have another spec normatively referencing something, then it seems like we ideally should have a means for facilitating references to it.

In the past, these have been manually added to Specref, or directly added on a per spec basis through the custom biblio system both ReSpec and Bikeshed support.

[sideshowbarker]

I'm trying to get "all" specs into https://foolip.github.io/day-to-day/, at the very least spec-like things that have test-like things in web-platform-tests

OK, yeah, I guess existence of web-platform-test tests for a spec is another data point that argues for it to be included in spec biblio systems

[marcoscaceres]

OK, yeah, I guess existence of web-platform-test tests for a spec is another data point that argues for it to be included in spec biblio systems

That's another debate we need to have at some point... sometimes things we (implementers) haven't agreed should be part of the platform end up in WPT (😱). Expect something about this soon from Mozilla people... but obviously outside the scope of discussion here.

[foolip]

😱

Yes, that's a discussion I'd very much like to have. It's not just new browser features, there's also https://github.com/w3c/web-platform-tests/tree/master/annotation-model and similar.

We just don't import some things like that. And wpt is a collection of test suites and not really one test suite, so no aggregate numbers make sense, and I'd argue should never be part of https://wpt.fyi/.

Can you post to public-test-infra?

[foolip]

Possibly related is the idea in web-platform-tests/results-collection#83 (comment) that each directory could have a per-implementation bit that means "this is our primary test suite for this feature", "this has good code coverage of our implementation" or just "we like this feature". With something like that, all the information should be there to present the facts as they are on wpt.fyi.

[marcoscaceres]

Can you post to public-test-infra?

I'm hoping someone from Mozilla will post something soon. We are ironing out our position on all this stuff internally right now.

[foolip]

@marcoscaceres, it's not quite done yet, but https://github.com/foolip/testing-in-standards/blob/master/lifecycle.md is my thinking on where we need to go with this. Hope that sheds some light.

[marcoscaceres]

@foolip that's great... specially if we can closely track and encourage the .tentative tests.

[foolip]

Yep, if that's the main concern, then I can see about working out a system where tentative tests are triaged any time they've remained untouched for 90 days or so. It would be best if this were a per-feature triage owned by people in feature/OWNERS, but ecosystem infra could be the fallback and the place we notice if triage isn't happening.

[foolip]

I've added a TODO to Ecosystem Infra rotation to not forget.

[foolip]

I've added a lot of WICG specs recently. I still don't know how to deal with w3c.github.io before they've been published under TR though. @tobie, is there a good way to get them into specref? If not I'll keep adding them manually to day-to-day.

[tobie]

@foolip not super sure I understand what you mean.

[tobie]

Did you add them to https://github.com/WICG/admin/blob/gh-pages/biblio.json? If so, they should just show up in Specref < 60 minutes later.

[marcoscaceres]

@foolip - also not sure what you are asking for. In particular:

I still don't know how to deal with w3c.github.io before they've been published under TR though

Are you asking about migration from WICG spec to W3C Working Group spec and updating the ref then?

[foolip]

Did you add them to https://github.com/WICG/admin/blob/gh-pages/biblio.json? If so, they should just show up in Specref < 60 minutes later.

Yes, and all of that's been working fine after #404.

[foolip]

Are you asking about migration from WICG spec to W3C Working Group spec and updating the ref then?

No, just how to get specs under w3c.github.io that aren't yet under TR into specref. Those specs aren't listed in https://www.w3.org/2002/01/tr-automation/tr.rdf.

Probably fun things will happen when things move from wicg.github.io to w3c.github.io, but as long as they were already in the WICG biblio.json at least the old URLs will stay around and be redirected.

[tobie]

Oh. Well, we could add a JSON file just like WICG has and update it some way or other.

[tobie]

Probably fun things will happen when things move from wicg.github.io to w3c.github.io, but as long as they were already in the WICG biblio.json at least the old URLs will stay around and be redirected.

We just have to figure out how to do it. Shouldn't be a huge deal.

[foolip]

In specref you mean? That'd work for me. https://github.com/foolip/day-to-day/blob/master/specs-manual.json has some of the specs I'd add.

[tobie]

So it seems you're missing some references and the easiest way is to add them manually, right? Those are going to be W3C refs in the future, correct? If so, just manually add them to refs/w3c.json and be done with it.

[foolip]

Presumably they will be, yes. I'll send some PRs for moving them over, then.

[tobie]

Do remember to add and remove corresponding entries in the same PR to avoid getting the test suite all mad at you.

As a side note, I'm starting to think we should reconsider splitting the db into multiple JSON files. Seems to create more problems than it solves.