TAG GitHub repo spring cleaning

[hober]

We have a lot of GitHub repositories, and sometimes it's not clear which one we should use for what, or which ones are going concerns and which ones are stale. I'd like to do some spring cleaning. Here's a list of every TAG repo that exists right now, and what I think we should do with them.

Meta (repos about the TAG)

Several of these seem rendundant with each other to me.

Repo	Status	Proposed change	Notes
meetings	Active		Part of our regular TAG work.
process	Active		Documenting our process.
w3ctag.github.io	Active		Our website.
tagdocs	Active	Archive after merging into w3ctag.github.io or process as appropriate.	Things about us for an outside audience should be on our website. Documentation of how we work should be in the process repo.
wiki	Inactive	Archive after merging into w3ctag.github.io.
placeholder	Inactive	Archive.	AFAICT, this is an entirely spurious, empty repo.
presentations	Inactive	Archive (check with @cynthia).	Doesn't look like we've ever actually used this to publish presentations.

Reviews (design and otherwise)

Repo	Status	Proposed change	Notes
design-reviews	Active		In addition to the issue tracker, this repo also contains longer review documents that the TAG has written in the past.
tracking-issues	Active
obsoletion	Inactive	Integrate into our weekly/monthly schedule.	We have a process obligation to handle obsoletion requests within 90 days. We are currently terrible at this.

Individual design reviews that got their own repos for some reason

None of these are active. We should probably archive all of these repos, after making sure to merge things that should be kept active into the design-reviews repo.

Repo	Notes
client-certificates	Ask @travisleithead.
eme
extending-html-responsibly
extensible-web-report-card
with-credentials	Ask @dbaron.

Findings

These repos contain the drafts of Findings the TAG has published.

I think we should go through all of these to make sure

• their ReSpec/Bikeshed statuses are all set to DRAFT-FINDING
• they have links to the published FINDING in their metadata
• appoint a current TAG participant as an editor if we think we want to revise it

When we officially publish Findings, the published copy (Status: FINDING) goes in the w3ctag.github.io repo (if I understand things correctly). Does this make sense? Shouldn't published Findings live in the same repos as the Draft Findings, in a subdirectory perhaps?

Repo	Editor (Currently on the TAG?)
capability-urls	@JeniT (N)
distributed-content	@triblondon (N)
encryption-finding	@mnot (N)
evergreen-web	@hadleybeeman (Y)
polyfills	@triblondon (N)
private-browsing-modes	@lknik (N)
unsanctioned-tracking	@mnot (N)
web-https	@mnot (N)

Self-check questionnaires

Repo	Type	Editor (Currently on the TAG?)	Proposed change	Notes
accessibility-questionnaire	N/A	@alice (Y)	Convert to Bikeshed & set status to ED.	Ask Alice.
security-questionnaire	ED	@hober (Y)

Principles

Our principles documents get published as Findings, and these are both already correctly marked as DRAFT-FINDING, so I don't think there's anything we need to do here.

Repo	Type	Status	Editor (Currently on the TAG?)	Proposed change
design-principles	@cynthia (Y)
ethical-web-principles	@hadleybeeman & @torgo (Y)

AWWW

Let's get real. Do we ever actually intend to update AWWW? If so, we should actually assign current TAG participants as editors and take the work on for real. If not, we should consider archiving this repo.

Repo	Type	Editors (Currently on the TAG?)
webarch	ED	@ianbjacobs (N) & @htInEdin (N)

Guides

As far as I can tell, the only one of these that's ever been fleshed out sufficiently & actually gotten traction with readers is the Promises guide. We should consider archiving the rest.

Should guides be EDs (and eventually NOTEs)? Or should they be DRAFT-FINDINGs (and eventually FINDINGs)?

Repo	Status	Editor (Currently on the TAG?)	Proposed change	Notes
promises-guide	Active	@atanassov (Y)		Make sure this is marked as an ED or a DRAFT-FINDING.
api-design-guide	Inactive	@triblondon (N)	Archive.
secure-the-web	Inactive	@travisleithead (N)	Archive.	Despite the repo name, this is not the source of our Secure the Web finding. That's in web-https.
subclassable-apis-guide	Inactive	N/A	Archive.
webcomponents-design-guidelines	Inactive	@kenchris (Y)	Archive.	Ask Kenneth.

Specifications

We are no longer working on any of these. We should archive them all.

Repo	Type	Editor (Currently on the TAG?)	Notes
jsidl	WD	@wycats (N)
packaging-on-the-web	ED	@JeniT (N)
private-mode	ED	@mnot (N)	Link to w3ctag/private-browsing-modes.
url	NOTE	@annevk & @rubys (N)	Obsolete fork of whatwg/url
urls-in-data	ED	@JeniT (N)

[cynthia]

Impressive!

Personally, I have not been a huge fan of the one repo per document approach. This just seems to lead to a bigger hole into the TAG abyss, as most of these repos remain unwatched. Would be a good time to discuss if we should consolidate findings and whatnots into per-category repo at least.

Presentations was intended to version control the TAG update slide deck @torgo uses every AC meeting, plus other talks we give during developer meetups so people can find them. That hasn't happened, so I think it's time we just delete the repo.

Specs... are we even allowed to publish specs? IIRC that wasn't the case in the current process. Should we ask WICG if they want to take over anything we have?

[dbaron]

I think repo-per-document works well for issue separation but badly for notifications and querying for issues that we need to deal with. But the way I (and maybe a few others) see the all-repo notification stream is the GitHub/Slack integration, which is my main way of seeing notifications for the TAG's repositories. So I (and I think a few others) who use that do see the notifications. I'm not sure what the state of the chairs' tools for agenda management is as far as running queries against all repos.

[cynthia]

Ah right, obsoletion - wonder if that could just be a different template for design-reviews, since it is pretty low traffic (and we aren't doing a good job at watching it)

[travisleithead]

secure-the-web	Inactive	@travisleithead (N)	Archive.	Despite the repo name, this is not the source of our Secure the Web finding. That's in web-https.

Archive sounds great--I don't even remember this.

client-certificates	Ask @travisleithead.

This one is overtaken by events (e.g., removal of <keygen> was 6+ years ago). I think most of this also predates the work in the Web Authentication WG, which espouses the principles identified in the document AFAICT. Archive sounds good to me.