wicg / admin Goto Github PK

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.

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.)

Please can we create a repo for this proposal?

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

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.

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.

Hi there,

Please can I be added as a collaborator on GitHub?

Thanks,
Becca

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.

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.

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.

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.

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?

Migration to working group should include a test suite.

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

@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.

(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).

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

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

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.

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'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 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.

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.

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.

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.

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.

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

"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

Many of the new APIs, such as Web Serial, say:

It is not a W3C Standard nor is it on the W3C Standards Track.

I am wondering how someone can get involved to express support or join in the effort to get standards like this on the standards track?

I have joined the WICG but I am not sure what else to do from there. I would appreciate input on this.

Thanks

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.

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

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. 😃

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

Currently wicg.io is a placeholder.
We should:

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

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 :)

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

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

@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.

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.

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)

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?

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.

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.

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."

Hi there,

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

Thanks,
Becca

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