Close this repository in the future

[hayatoito]

Given that the actual spec update has been happening recently in WHATWG DOM Standard repository and WHATWG HTML Standard repository, I am feeling that there is a kind of duplication (or redundancy) if we continue to keep this w3c/webcomponents repository's all functionalities. This repository has acted its role, but we might want to re-consider this repository's role now.

Regarding spec discussion:

• Shadow DOM: Use DOM Standard repository's issues, basically
• Custom Elements: Use HTML Standard repository's issues, basically
• HTML Imports: This is Chrome-specific feature. It might be better to file a bug for Blink.
• HTML Modules: It might be okay to use this repository, but that doesn't have to be here, I think.

I don't have any concrete idea how to migrate issues to WHATWG Standard repository, but I don't think we have a lot of of important files bugs which need to be migrated.

Regarding W3C version specs:

• Until the situation becomes clear (and/or all things are upstream-ed), we should keep and maintain them somehow: Shadow DOM, Custom Elements

[domenic]

My personal take has been treating this repository's issue tracker as a host for incubation, per the WHATWG working mode. It's done pretty well in that regard, so I would be OK continuing in that fashion.

Discussion of bugs in the existing spec makes more sense in the other repository's issues, I agree, and maybe migrating those would be good.

[rniwa]

Given a lot of active discussions are happening here already, it's valuable to keep using this repository's issue trackers to discuss new ideas. The last migration from W3C Bugzilla to Github caused all sorts of confusions. There is no need to repeat the same painful process.

[hayatoito]

Thank you for feedback. Okay, let's keep this repository's issue tracker as a host for incubation and/or more casual discussion for us. Let me close this issue.

[annevk]

Let's reconsider this, since folks continue to raise issues here that are better suited for whatwg/dom, whatwg/html, w3c/uievents, w3c/csswg-drafts, etc. Coupled with that, at least one implementer was confused about which documents to look at, which is rather problematic.

I'll see about that at least each v1 issue is also tracked upstream somehow.

[rniwa]

I don't think we should abandon this repository since most of web components related issues are still tracked here. It's much harder to track web components related issues across dom/html issue trackers.

[annevk]

One problem is that if we make a decision here, e.g., to not ever support >>>, the CSS WG could just make a different decision since they have the "authority". It would be nice if everything was discussed here, but it seems at least for the CSS parts there's also a substantial amount of discussion elsewhere. (And note they might not do so maliciously, they might simply not know about all the design decisions around shadow trees. And in such cases it's fairly common for domain experts not to be asked. E.g., the Performance WG has exposed numerous networking bits without consultation with those working on Fetch/XHR...)

[TakayoshiKochi]

How about keeping this repository as a historical archive, close filing new issues here?
For unresolved active issues, upstream to where appropriate, or get it concluded here.

Yes, it is hard to web components-specific bugs in whatwg/dom and whatwg/html among other various issues, but could be better tracked there using "shadowdom" or "customelements" labels?

[rniwa]

I don't think we should be upstreaming issues. When W3C moved all the issues from Bugzilla to Github, it made a huge mess, and it was such a PITA to keep track of what happened to each issue. Even today, I still find some issues that never got migrated properly, or got lost during the migration without a proper triaging.

[annevk]

@rniwa I can agree with that. How does this sound:

1. We require new issues to be filed upstream. Anyone filing new issues here will be helped to find a place to file it instead.
2. We keep working on addressing the remaining issues here. This will likely happen by upstream PRs closing issues here though sometimes an issue here may be duplicated against an upstream issue.
3. We keep this repository as a way to organize meetings.
4. We keep this repository for new issues that do not have a clear upstream.
5. We keep this repository for new proposals until such a time they are ready to be turned into a proper draft.

[rniwa]

Sure, that sounds good. I agree that once a concrete proposal to make HTML/DOM spec changes, it's better to have the discussion in respective repositories instead.