Update repo and spec to show this is no longer being actively incubated

[astearns]

In #82 there are arguments made against archiving this repo, but many statements that agree something should be done to indicate that this is no longer being incubated. Currently the readme says this is “currently incubating” which is a bit misleading since nothing has happened in the repo for over a year, and there have been objections raised that have not been addressed.

In #82 (comment) one chair suggests there should be a documentation mode for specs here that indicate incubation has stopped, but that has not happened.

In #82 (comment) another chair suggests some signals be added to better show a WICG spec status, but that has not happened.

If archiving this repo isn’t going to happen, something else does need to happen to make it obvious that this spec does not have a path towards cross-browser standardization.

@yoavweiss @cwilso

[yoavweiss]

In #82 there are arguments made against archiving this repo, but many statements that agree something should be done to indicate that this is no longer being incubated

I disagree. I think we need to revise the API based on feedback from Mozilla, which may open a path for their adoption. The main blocker for this is (ironically) bandwidth.

/cc @tomayac @nhelfman

[astearns]

That may be, and I hope something can be worked out so that more people agree this is worth implementing.

But @yoavweiss, you and your co-chairs need to figure out what needs to be done in situations like these. As chair you argued against archiving in favor of labeling. Over a year later, you are now arguing against labeling in favor of waiting for revisions to be proposed. I think WICG would benefit from having some clear procedure for indicating the current state of the proposal does not have a path forward.

Whatever this process is (labelling, edits to the readme/spec, parking in some other repo), it could have been applied in April 2020 to satisfy those asking for the proposal to be archived. It could be applied now to indicate revisions need to be made. And it could be lifted as soon as the revisions are made and multi-vendor interest is rekindled.

[astearns]

In WebStandardsFuture/browser-engine-diversity#1 (comment) @cwilso suggested a ‘graduated from incubation, currently in stasis’ state for specs (like this one) where the spec has ‘pretty much gone as far as it can with a single vendor.’

@igrigorik @tomayac, Since spec revisions will be needed before other vendors would re-consider implementing this spec, would you be OK with putting this spec in that state until you all have time to work through these revisions?

[tomayac]

I have rebooted the Network Information API based on long-going discussions with @yoavweiss (who is currently still OoO) and would appreciate you all's feedback:

• Motivational doc: https://docs.google.com/document/d/1RDA23zSNdDuIcxZTX9Xo3zlD2fxf8dZg9-e0YaJQv0g/edit?usp=sharing
• Explainer: https://github.com/tomayac/netinfo/blob/relaunch/README.md
• Spec draft: https://tomayac.github.io/netinfo/

[astearns]

@tomayac unless you intended to limit the first round of feedback to the people in (or following) this issue, you may want to broadcast this more widely (in issues #84 and #85, at least)

Personally, I have no expert opinion to bring to this API. I am mainly being a process dork who would like WICG to be more clear about proposal states.

[tomayac]

@tomayac unless you intended to limit the first round of feedback to the people in (or following) this issue, you may want to broadcast this more widely (in issues #84 and #85, at least)

Done.