search

w3c / geolocation

W3C Geolocation API
https://www.w3.org/TR/geolocation/
81 stars 56 forks source link

Publish as FPWD #42

Closed marcoscaceres closed 3 years ago

marcoscaceres commented 4 years ago

The spec now contains some pretty significant updates since 2016:

@plehegar, @anssiko, I think it's worth republishing new Recommendation. WDYT?

anssiko commented 4 years ago

@plehegar, @anssiko, I think it's worth republishing new Recommendation. WDYT?

I agree. We have now addressed all the known open issues and the spec has been hardened for security and privacy in line with the group's maintenance commitment after taking the spec over from the now-defunct Geolocation WG. To my understanding, all the major implementations agree with the spec, but implementers please chime in if that's not the case.

@plehegar what is the path of least resistance (read: least make work) to publish a new Recommendation? Should we wait for the Process 2020 to be operational?

Cc @reillyeon for the co-chair perspective.

Cc @cdumez for WebKit.

reillyeon commented 4 years ago

I agree that a new Recommendation is warranted.

plehegar commented 4 years ago

TL;DR: use Process 2019 even if it's not ideal.

Long version:

Current choices are listed in the next steps.

Do you consider the part "Controlled by feature policy" to be a new feature? My guess is that it isn't, since it does not add new functionality.

If I'm correct, the path with Process 2019 would be to Publish a Candidate Recommendation with substantive changes (but no new features).

This would put you to publish the amended REC in September 2020.

If you pick the Proceess 2020 route, the current prediction is September 1 for it to become effective. You would first have to move your charter to P2020. That's around 30 days. This mean you could republish the original REC, with the changes appearing as proposed corrections (see Revising a Recommendation: Substantive Changes) in October 2020. You can then republish the REC, with the proposed changes folded in, around January 2021 (time is eaten by the Call for Exclusion started in October).

Now, the pros and cons:

So, in summary, if you can bear the thought of going through a CR first, I recommend the path P2019 since it gets you to the updated REC sooner.

marcoscaceres commented 4 years ago

I don't mind going through CR again.

xfq commented 4 years ago

I agree with @plehegar that we should publish a Candidate Recommendation with substantive changes (but no new features), if the feature policy support is not considered a new feature.

We also need wide review of the changes before the CR transition.

marcoscaceres commented 4 years ago

Ok, let me know if there is anything I can do to help!

plehegar commented 4 years ago

@anssiko , if you concur, it would be nice to have some kind of group decision to point to for this, and then @xfq can do the paper work.

anssiko commented 4 years ago

@plehegar CfC to publish Geolocation API Amended Recommendation - review by 18 June 2020

anssiko commented 4 years ago

@xfq CfC passed, please feel free to proceed with the paper work.

xfq commented 4 years ago

Some information for myself:

New normative references since the last REC:

Test suite: https://github.com/web-platform-tests/wpt/tree/master/geolocation-API

Preliminary implementation report: https://wpt.fyi/results/geolocation-API?label=experimental&label=master&aligned

CR exit criteria: two interoperable deployed implementations of each feature

Wide review: https://github.com/w3c/geolocation-api/issues/43

marcoscaceres commented 3 years ago

@xfq, #68 adds [Permissions API] as a dep.

marcoscaceres commented 3 years ago

Given that we are operating under the new charter + 2020 Process, I wonder if we should revisit the publication options? We are no longer blocked on using the 2020 Process, so...

anssiko commented 3 years ago

For discussion at https://www.w3.org/events/meetings/a8a1448f-049b-468e-8b45-8eae6b8e75be#agenda

marcoscaceres commented 3 years ago

Awesome! thanks @anssiko. I'll chat to @plehegar in the meantime to get a better understanding of our options to bring to the meeting.

marcoscaceres commented 3 years ago

Hey Folks, @plehegar met this week to chat about the path forward. We looked at the requirements from the Process 2020 and, because we've added new features to the spec, we need to publish a FPWD... which turns out to be a great thing because it means we can significantly modernize the spec, then (relatively) quickly move it to be a "living standard".

So, basically, this will be the plan:

We can publish a FPWD whenever we like. Ideally we will do that straight after our meeting in a few weeks - which will give me time to make the above changes. After FPWD, @plehegar suggested we wait one month before going to CR. We can sit on CR until we get browser alignment on the page visibility issue (there are some web compat issues, so we need to decide which model is best and then figure out which engine needs updating). Alternatively, we move quickly to REC, then republish an updated REC to fix the visibility issue ~6 months down the line.

If it's ok with everyone, I'd like to "officially" become Editor of this spec. I'd also be keen to have someone be a co-editor, to also edit or help review PRs (maybe someone new who hasn't edited before - preferably from an underrepresented community in our working group). Any taker to be my co-pilot?

marcoscaceres commented 3 years ago

In prep for FPWD:

must record the group’s decision to request advancement.

https://www.w3.org/2021/04/07-dap-minutes.html#r04

must obtain Director approval.

@xfq, I can't recall the name of the repo where to file the request :( Could you assist me with this?

must publicly document all new features (class 4 changes) to the technical report since the previous publication.

https://w3c.github.io/geolocation-api/#changes-since-last-publication

must publicly document if other substantive changes (class 3 changes) have been made, and should document the details of such changes.

https://w3c.github.io/geolocation-api/#changes-since-last-publication

should publicly document if editorial changes have been made, and may document the details of such changes.

https://github.com/w3c/geolocation-api/commits/gh-pages

must formally address all issues raised about the document since the previous maturity level.

All issues have been responded to in: https://github.com/w3c/geolocation-api/issues

must provide public documentation of any Formal Objections.

None.

should report which, if any, of the Working Group's requirements for this document have changed since the previous step.

None.

should report any changes in dependencies with other groups.

None.

should provide information about implementations known to the Working Group.

Implementation in Blink, WebKit, and Gecko.

xfq commented 3 years ago

@xfq, I can't recall the name of the repo where to file the request :( Could you assist me with this?

It's https://github.com/w3c/transitions/issues and I am happy to help file the issue (actually I have created a test FPWD snapshot), but before filing the transition request, I found the following paragraph in our charter:

To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions (for example, via email and/or web-based survey), with a response period from 5 to 10 working days, depending on the chair's evaluation of the group consensus on the issue. If no objections are raised on the mailing list by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.

It looks like we only have a CfC for publishing this spec as an Amended Recommendation, but not for FPWD, so we probably need to issue a new CfC first...

marcoscaceres commented 3 years ago

It looks like we only have a CfC for publishing this spec as an Amended Recommendation, but not for FPWD, so we probably need to issue a new CfC first...

Agree. @anssiko, do you want to "replay": https://lists.w3.org/Archives/Public/public-device-apis/2020Jun/0006.html

In the meantime, it would be great if someone from the group could step up and review the spec from start to finish. I basically rewrote the whole thing, so there are bound to be typos or potentially other issues.

anssiko commented 3 years ago

FYI: CfC to publish Geolocation API First Public Working Draft - review by 26 April 2021

anssiko commented 3 years ago

The CfC passed. @xfq please proceed with the publication.

xfq commented 3 years ago

Since the shortname of the current REC is geolocation-API and an FPWD is considered a new document, we cannot reuse the same shortname, so the document has to be published under a different shortname.

We have two options:

marcoscaceres commented 3 years ago

"geolocation" is my preference... versions/levels don't make any sense.

reillyeon commented 3 years ago

Having "geolocation-API" point to the REC and "geolocation" point to the WD sounds confusing. Are there no prior examples we can work from here? I have a slight preference for "geolocation-API-WD". I assume that when we publish another REC version of this specification it will overwrite the current document at "geolocation-API".

marcoscaceres commented 3 years ago

geolocation-API-WD

Having that status in the short name is not a thing.

How it will work is "geolocation-API" will become Superseded Recommendation, and "geolocation" will become the new canonical Recommendation.

deniak commented 3 years ago

I wouldn't recommend using geolocation-API-WD since it's the shortname that will be used to identify the specification even after it reaches CR. Now, if the new document is published under the shortname geolocation, we could redirect https://www.w3.org/TR/geolocation-API/ to https://www.w3.org/TR/geolocation/.

reillyeon commented 3 years ago

How it will work is "geolocation-API" will become Superseded Recommendation, and "geolocation" will become the new canonical Recommendation.

Does this mean that every time there is a new Recommendation the shortname needs to change or does this only apply because we're switching to a new Process?

deniak commented 3 years ago

Does this mean that every time there is a new Recommendation the shortname needs to change or does this only apply because we're switching to a new Process?

It's actually a mix of things. With the previous process document, you can only revise a REC with non substantive changes. In this case, I understand you are adding new features. That's why @plehegar said you need to publish a FPWD.

The good news is the new process document facilitates that kind of updates to existing RECs so going forward, WGs won't need to publish a FPWD to add new features.

anssiko commented 3 years ago

Redirect from https://www.w3.org/TR/geolocation-API/ to https://www.w3.org/TR/geolocation/ solves the REC vs WD confusion so I believe we can settle on ”geolocation” as the shortname.

xfq commented 3 years ago

Published: https://www.w3.org/TR/2021/WD-geolocation-20210527/