"The group publishes an index of the proposals worked on in GitHub." do you know where this is going to be or not?
it points to https://example.com/indexpage at the moment

ResizeObserver spec has moved to CSSWG so that new issues should not be filed in WICG.

https://github.com/WICG/ResizeObserver

However the project is still listed at https://wicg.io/.

If the project was archived, new issues can't be filed in it and https://wicg.io/ won't display it.

I think it is time to archive the project.

External projects consume biblio.json in order to create links to WICG specifications. This file should be updated when new repositories are created.

Hi there,

Please can I be added as a collaborator on GitHub?

Thanks,
Becca

Hi there,

Please can I get added to the picture-in-picture repo?

Thanks,
Becca

What we need:

• Write blog post.
• Create the actual CG?
• Coordinate with RICG.
• Decide on IRC/Slack? channel?
• Publish blog post
• Getting a site (http://wicg.io) up in place
• Get an IRC logger working

I'm about to propose a couple of these, so I'm starting out with a meta-issue for describing/discussing the overall pattern.

Basically, a GitHub repo is a great way of encapsulating an initiative within the WICG: it gets a README for an introduction / sort of meta-charter. Other files in the repo can be used for other documents whose content should be curated, with changes discussed in pull requests.

It also has its own wiki that can be edited by any user via GitHub, for gathering non-prescriptive informal thoughts together.

At the very top of the charter, it says this:

• Start Date: 2 July 2015
• Last Modified: 2 July 2015

But it's clear from charter.html's revision history that the charter has changed a number of times since then.

Minimally, the "Last Modified" line should be updated when the charter is changed. Ideally, the charter would include links to all previous versions.

Do we need our own logo or should we keep the WebPlatform "W"? Do we need to rebrand the discourse from its specifiction past?

It's time to do a review of work that should be migrated...

We currently meet this criteria on all repos, I think... but it would be good to be more explicit in our process.

Intent to Migrate: Badging API

Hi Folks working on this... with the Web Apps WG now up and running, we are ready to adopt this specification into the WG for formal standardization along the w3c rec track. 🎉

Before doing so, I could use a bit of help just filling out the template below... I've got things started already, but those with knowledge of the spec please jump in.

Working group decision to adopt

In W3C WebApps Charter

Proposal

https://github.com/WICG/badging/

Summary

An API allowing web applications to set an application-wide badge, shown in an operating-system-specific place associated with the application (such as the shelf or home screen), for the purpose of notifying the user when the state of the application has changed (e.g., when new messages have arrived), without showing a more heavyweight notification.

Motivation and Use Cases

Covered in explainer.

Compatibility Risk

Limited. Badging serves as progressive enhancement.

Ongoing technical constraints

What technical constraints will be added to user agents implementing this feature?

None.

Will this feature be supported in all environments (desktop, mobile, tablets, TV, eBooks, automotive, etc.)?

A detailed discussion of possible OS that could support this feature is discussed in the Explainer.

However, not all OS support badging.

Link to implementation experience and demos

If your proposal has implementation experience or demos, please provide links, including common patterns in deployed libraries. Otherwise, indicate if there are none.

https://crbug.com/719176

Data

What data do you have available that indicates that this enhancement will affect many users of the Web. Quantify the fraction of websites that are currently using something similar to this feature. Or, if a new feature, characterize the reason that you expect this to be far reaching.

This would be a new feature for Web Applications. However, is convention across popular mobile and desktop OSs - particularly on iOS, MacOS, and some Linux distributions. It is conceivable that OS-integrated web applications could make use of these OS-provided badging capabilities.

Security and Privacy

A web application could (ab)use the badging API to attempt to display badge numbers, in order to trick user to unnecessarily open the application. By launching the application, the user could unintentionally expose private information.

Bug: w3c/badging#25

Accessibility

Outline the implications of your proposal relative to access by everyone regardless of disability. Otherwise, indicate if there are none.

None, as this is often left to the OS (which is hopefully accessible). However, if the browser is in the control of presenting the badge, it should be possible to define some accessibility guidelines.

Bug: w3c/badging#24

Internationalization

Outline the implications of your proposal when used with different languages, scripts, and cultures. Otherwise, indicate if there are none.

The API allows setting unsigned long long types. Presumedly, these would then be formatted appropriately based on the user's locale settings.

w3c/badging#23

It's still not super clear how to set up a repo and get started. We should make that more clear.

Problem: Web search for WICG suggests w3.org/community/wicg. That page links to the charter, but not information on process that is documented on github.com/wicg/admin, nor the https://wicg.io page.

Similarly, https://wicg.io does not cross-link to the community group, or the github admin page.

Chore: Edit w3.org/community/wicg and https://wicg.io/ to link to each other and github.com/WICG/admin.

We've mentioned using Discourse. Right now the community's instance is sitting at Specifiction, which is probably not a great location. The initial plan was to move it to webplatform.org, but this has been mired in the lack of decision as to what to do with that site.

Should we push to keep webplatform.org or should we just go ahead and put everything under wicg.io? I like the former's name better, and it comes with a large and relevant Twitter following, but right now it's not moving...

Particularly interested in the canvas colorspace repo, where I am contributing comments and a review on a PR, but also there are CSS topics that come by WICG from time to time.

This is a follow-on from #64 inspired by WICG/netinfo#82.

Sometimes, WICG specs define features that (a) have only been implemented by one engine, and (b) are unlikely to be implemented in any other engines.

@marcoscaceres wrote, in WICG/netinfo#82:

I think this incubation might have run its course as it hasn't successfully gained the cross browser support we had hoped for in the last 7 years.

I think cases like this should be clearly marked, ideally with a big red modal like WHATWG Review Drafts, stating that the spec documents the implementation of a feature that is implemented by only one engine, that it's unlikely to be implemented elsewhere, and that developers should refrain from using the features defined in it.

A complaint I've received is that WICG specs look too much like "real" specs. I'm wondering if we should drop the W3C Logo from CG specs or use the "unofficial" stylesheet instead?

Hi,

We'd like to spin off the SMS message format currently defined in WICG/WebOTP and in https://github.com/WebKit/explainers/tree/master/sms-one-time-code-format into its own repository with its own explainer, spec, and issue tracker.

Could you create a WICG/sms-one-time-codes repo and give @hober and myself write access?

Thanks!

Sam, Tess

(I assume we don't have to jump through hoops on Discourse to do this, since it's just a reorganization of some of the work that already graduated from Discourse into WICG/WebOTP.)

Hey folks,
I'm new to participating in the WICG and I was wondering what the desired process is for scheduling calls among interested parties (e.g. for a topic like https://github.com/WICG/trust-token-api) and if there are canonical tools to do so.

I chatted with @yoavweiss offline who mentioned that scheduling via github issues might be a good idea, but to file an issue here to see what people think.

Elsewhere, @frivoal requested the following:

I would like to see statistics about the number of specifications started
in the WICG. How many of them died? How many of them lived on? How many of
those that lived on have graduated to a WG versus how many are still in the
CG? Of those that are still in the CG, how many are there because they are
still exploratory versus how many have turned into living standards? Of
those that have graduated to a WG, what was the typical level of stability?
Of those that have died, what were the main causes for giving up? How good
was the progress along TR for the specs that did make it to a WG? Are all
the statistics roughly the same depending on who originated the idea, or
are there significant differences when the originator is a browser vendor
vs a non-browser but experienced spec writer vs a new-comer? How do these
statistics compare to when early/exploratory work was still being allowed
in the WG?

A well constructed study along these lines could go a long way to put to
rest the concerns that have been raised against mandatory incubation, or on
the contrary it may show that they were justified. Or maybe statistics is
the wrong way to go about it, but nonetheless, we need to draw lessons for
the life-sized experiment we've been running, and do so in a way that seems
fair to proponents and opponents to the idea.

Please can we create a repo for this proposal?

https://discourse.wicg.io/t/proposal-media-feeds-api/4223

Forked from discussion in #79 (comment) and w3c/tr-design#186 (comment). See also #64.

I didn't realize that the ED status was meant for WG drafts, and that editor's drafts of CG specifications should use CG-DRAFT instead. It looks like lots of other editors have the same confusion. CGs generally should find a way to educate editors on this, but the WICG is as good a place as any to start looking for ways that work.

One thought is to edit https://github.com/tabatkins/bikeshed/tree/master/bikeshed/boilerplate/wicg to add a header-ED.include that loudly says to use the CG-DRAFT status instead. @tabatkins, does that make sense?

What other approaches should we try?

This is also a good place to disagree if the policy @marcoscaceres suggested is wrong for some reason. 😃

I have joined the WICG group and read https://github.com/WICG/admin/blob/gh-pages/README.md

However, I do not see a process to get permissions administer/close issues on a github repository. I am looking at https://github.com/WICG/webpackage in particular.

The WICG charter in the section on Community and Business Group Process and Patent Policy contains the text:

As with other Community Groups, W3C seeks organizational licensing commitments under the W3C Community Contributor License Agreement (CLA) (Proposals in this Community Group charter are applicable "Specification" in the CLA).

It's not particularly clear what this parenthetical means. What I hope it means is that any proposal (for example, an explainer) counts as a "Specification" in the terminology of the Community and Business Group Process, particularly where it says:

The label “Community Group Report” refers to any document produced by a Group. Some Community Group Reports are Specifications. The following rules apply to Specifications:

• drafts are governed by Community Contributor License Agreement (CLA). W3C will provide a template for including copyright information.
• they must include the name the group that published the deliverables and link to a public page about the group.
• they must include a publication date.
• the history of Contributions (as defined under the CLA) must be archived permanently on the W3C Web site.
• They must include boilerplate language required by W3C (e.g., notice that Contributions are made under the CLA and that certain conditions apply).
• When published on the W3C site, they must not violate the W3C Privacy Policy.
• The content and style of the Specification must not cause confusion about its status, in particular with respect to W3C Technical Reports.

... and later:

Other types of deliverables must be publicly available and must be archived permanently.

It would be helpful if this sentence were clearer; it's not clear what "are applicable" means in this context.

@dontcallmedom found a bunch of issues with our repositories around IPR etc:
https://w3c.github.io/validate-repos/report.html

We need to go through the list above and click the buttons in the repo manager to fix things.

The following repos are served both over http and https - they should be configured to use only https:

• https://github.com/WICG/admin/settings#pages-https-redirect-feature
• https://github.com/WICG/container-queries/settings#pages-https-redirect-feature
• https://github.com/WICG/ContentPerformancePolicy/settings#pages-https-redirect-feature
• https://github.com/WICG/CSS-Parser-API/settings#pages-https-redirect-feature
• https://github.com/WICG/directory-upload/settings#pages-https-redirect-feature
• https://github.com/WICG/EventListenerOptions/settings#pages-https-redirect-feature
• https://github.com/WICG/historical-a11yapi/settings#pages-https-redirect-feature
• https://github.com/WICG/historical-web-payments-browser-api/settings#pages-https-redirect-feature
• https://github.com/WICG/hsts-priming/settings#pages-https-redirect-feature
• https://github.com/WICG/img-conversion/settings#pages-https-redirect-feature
• https://github.com/WICG/indexed-db-observers/settings#pages-https-redirect-feature
• https://github.com/WICG/InputDeviceCapabilities/settings#pages-https-redirect-feature
• https://github.com/WICG/ResizeObserver/settings#pages-https-redirect-feature

(cf w3c/validate-repos#70)

Landing page for https://wicg.io has a bad link for "W3C membership". It currently links to

https://www.w3.org/2004/01/pp-impl/65406/instructions
"INSTRUCTIONS FOR WEB AND MOBILE INTEREST GROUP
The Web and Mobile Interest Group is now closed."

Along the same lines as overhauling the Discourse Terms of Service, I think it's important that the README/charter mention that users are subject to the GitHub Terms of Service (when on Github), since it's not a strict subset of the Code of Conduct (for the first instance I see from said terms of service, I don't think the W3C has any policy about keeping out participants under the age of 13).

If there are other rules governing Community Groups (such as something that does disallow participants under the age of 13), those should be mentioned in the README, too.

Steps:

1. Make sure they are WICG Members and have signed IPR agreement (join).
2. Invite the repo owner to the WICG - through the people interface. Add them to the "collaborator" group.
3. Once they accept the invite, ask them to transfer the repo over.
4. Add the user back as admin, through the repository interface.
5. Add the repo to the repo manager

Done.

Talking to folks participating in PING, we are wondering if it would be possible for us Chairs to notify PING when we kick off incubations?

Basically, we could add this to the initial transition steps:
https://github.com/WICG/admin/wiki/Process-to-transfer-a-repo

cc @snyderp

Supposing this is as good a place as any to track an agenda!

Hey Incubators! W3C TPAC is nearly upon us! For those of you who will be attending this year, our little community group has an opportunity to host topics related to the various current (and prospective!) incubations on Thursday and Friday. To help us get organized in advance, we can use this issue as a call for agenda topics, and to sort and organize the topics you folks would like to discuss.

As you suggest a topic, please include the following:

• the topic :-)
• who should lead the discussion
• hoped for outcome of the discussion
• a rough-idea of how long the discussion should be

We currently have 2 hours on 2 days to pack as much discussion-goodness as possible!

Remote participation - link
The session will be recorded.

Thursday (08:30 - 10:30) -

Meeting Location: Hishi, 3F (Maximum attendance: 20)

• Topic: WebTransport - 30 mins
• Topic: WebCodecs - 30 mins

Friday (10:30 - 12:30)

• Topic: TAG and incubation - 60 mins
• Topic: Best practices for complex incubation projects - 60 mins

The scroll-animations spec has moved to CSSWG so that new issues should not be filed in WICG.

https://wicg.github.io/scroll-animations/

However WICG's project is still listed at https://wicg.io/.

Once the project is archived, new issues can't be filed in it and https://wicg.io/ won't display it.

I think it is time to archive the project.

Also,

• The spec page should redirect users to the new spec page.

  https://wicg.github.io/scroll-animations/

  https://drafts.csswg.org/scroll-animations-1/

• The biblio.json may be need to updated.

  https://github.com/WICG/admin/blob/gh-pages/biblio.json

Note: I'm a fun of both ResizeObserver and scroll-animations and appreciate all of inculbation works.

Noted that our Chairs tracking spreadsheet (The Truth) seems out of sync with wicg.io, which is itself apparently powered by biblio.json. Do these need to synced-up? (Should we add that as a column in the spreadsheet?

The current plan of record is for Private Click Measurement to move to the Privacy CG (see privacycg/proposals#1 and privacycg/private-click-measurement#32).

Before I bungle everything by clicking the Transfer button, is there anything else I need to do? How does this usually work?

cc @WICG/chairs

Migration to working group should include a test suite.

This issue gathers ideas for being able to collaborate better with the TAG. We may spin off actions/issues from this issue.

@jonathanKingston wrote:

It would be nice if the first steps in making a proposal was more a document of words and code rather than formal spec themselves. The specs can come second to a well structured document being supportive to the use cases and also example syntax, how to test, what the problem areas of implementing might be, who needs to be involved.

In biblio.json there are 3 things using CamelCase:

• https://wicg.github.io/InputDeviceCapabilities/
• https://wicg.github.io/ResizeObserver/
• https://wicg.github.io/BackgroundSync/spec/

Also WICG-originating, I think:

• https://w3c.github.io/IntersectionObserver/
• https://w3c.github.io/ServiceWorker/

People don't seem to want to use the CamelCase names in web-platform-tests, see resize-observer, intersection-observer and service-workers: https://github.com/w3c/web-platform-tests

It would be less work for me matching up specs and tests in https://foolip.github.io/day-to-day/ if WICG repos tended to start out at dashed-names :)

Currently wicg.io is a placeholder.
We should:

• Create a simple page with links to discourse, charter, gitter, etc
• Make it pretty

I've been encouraged to create a fork of the Import Maps spec given the feedback on the PR in WICG/import-maps#210.

Per the charter this seems to be an encouraged process, yet there doesn't seem to be much info on the practical process. I would like to request some guidance on what is the proper way to manage this fork, with the goal to build interest and community around the new features and the intent to re-coordinate eventually.

Many thanks!

I'm interpreting the step of creating a repository in the WICG org as "adopting work".
The charter doesn't really say anything about what work the WICG can adopt.
The clearest statement I can find is in https://github.com/WICG/admin/blob/gh-pages/README.md#contributing-new-proposals:~:text=Evaluation

As a community, we will use Discourse to evaluate interest and ask for potential editors for the proposal. As soon as sufficient interest is shown in the discourse (notably from potential implementers), the WICG chairs will enable a team of editors to manage the proposal (based on the discourse), and those team members can move ownership of the GitHub repo (if any) to WICG.

What's "sufficient interest"? I think in practice it's been people from two separate organizations, not necessarily browser vendors or engine implementers, saying the problem is worth solving, but I'd like to be able to point potential contributors to something more official than my memory.

https://wicg.github.io/admin/charter.html#contrib describes some requirements on repositories added to the WICG, so it'd be nice to be able to copy a template repository that already has those files.

https://help.github.com/en/articles/creating-a-template-repository gives instructions.

I noticed that https://github.com/WICG/devtools-protocol are missing from the list on https://wicg.io/

What's the process for getting it added? We don't have a gh-pages branch yet with a formel spec or homepage.

(following the pattern suggested in #13)

Basically, this is a repo whose primary feature is its wiki, with pages like https://github.com/stuartpb/wicg-best-practices/wiki/WICG-Best-Practices that describe how to be effective in WICG.

This would be moved from https://github.com/stuartpb/wicg-best-practices to https://github.com/WICG/best-practices (or maybe WICG/wicg-best-practices to distinguish it from something like Technical Architecture Group best practices).

https://wicg.github.io/admin/charter.html#chairs is out of date, and https://github.com/WICG/admin talks about the chairs a lot without ever linking to a list. You have to know to go to https://www.w3.org/community/wicg/ and scroll down to find the current list.