Consider having a separate repo per explainer

[tomayac]

The current "mono repo" approach makes following explainers extremely tedious. Random email subject example from my Inbox:

[WebKit/explainers] Feedback (#32) 🤔

I know each Issue has a label, but they don't get carried over to email notifications. My flow is to mute email notification threads I am not interested in in Gmail, sometimes on GitHub. The current way WebKit Explainers works forces me to click through to each thread to figure out what explainer it is for, and if I want to follow it or not. I'm short before declaring email bankruptcy.

Thanks for your consideration! If it's just me, happy for others to share their (email-notification-based!) workflow. Maybe I just don't know the trick everyone else knows.

[tomayac]

Related: https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/381

[othermaciej]

I agree with this feedback. At that point we'll have to consider whether to create a new WebKitExplainers GitHub org, name all explainer repo with "explainer" in the name, or just live with it being less obvious from the name that some repos are explainers / standards proposals.

[othermaciej]

I do like that this repo acts as an index, though. Maybe we could keep that property in a future scheme.

[marcoscaceres]

yeah, I agree with this too... that would allow us to easily transfer the repo to the appropriate standards organization while also retaining any issues that were filed. Otherwise, it makes it easy for issues to get left behind and to lose (commit) history.