TAG GitHub repo spring cleaning
Opened this issue · 4 comments
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) |
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?
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.
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)
| 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.