- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 2 Sep 2015 15:33:22 -0700
- To: "public-houdini@w3.org" <public-houdini@w3.org>
Hello all! tl;dr: Houdini is switching its process to primarily conduct conversations in GitHub Issues in the repository at <https://github.com/w3c/css-houdini-drafts/>. Please open all new issues there, rather than sending emails. This mailling list will be reserved for announcements and the odd general-interest mail, such as requests to review or notifications of publication. ts;wrm: At the recent Houdini f2f meeting, the relatively lower usability of mailing lists was brought up, particularly in contrast to GitHub issues. Some specific complaints about mailing lists given were: 1. Too noisy. Your only choice is to not subscribe, or get the full firehose of every message in every conversation. 2. No state tracking. You can't tell whether an issue in an email thread is open or closed without reading it, and there's no easy search. 3. Archives suck. The W3C's mailing list archives suck. There's really no nicer way to put it. The UI is terrible, and threads break if they cross archive periods (lolwtf). You can always get an mbox file and import that into your own mail reader, but hahahahaha I couldn't even keep a straight face, never mind. 4. Threading sucks. Different mail readers support threading to a greater or lesser extent, and not everyone is compatible with each other. It's pretty easy and common for people to accidentally break threading, making tracking a conversation much more difficult (and basically impossible if you're archive-diving after the fact). 5. Formatting sucks. If you send plain-text emails, you're limited to effectively Markdown source code. If you send HTML emails, your defaults are usually terrible and make your mail harder to read (because most email composers are terrible). GitHub Issues fix all of these problems. (1) You can subscribe to individual threads as you wish, and if you're subscribed to the entire repo, you can unsubscribe from individual threads whenever you want. (2) State-tracking with labels is trivial, and open/closed is built right into the UI. (3) Issues archives are easy to search and read. (4) Threading works perfectly automatically. (5) Formatting is rich but consistent, with the standard Markdown experience. As such, we are now moving our process to primarily work within the GitHub Issues system. All new issues should be raised by opening an Issue in GH, *not* be sending an email to this list. The list will be reserved for general-purpose emails, like requests for review and publication announcements. Any attempt to start a technical discussion on the list will result in a request to instead open a GH issue, rather than useful technical conversation. If you would like to still receive the firehose of content, just subscribe to all notifications in the repository; your experience will be effectively identical to what it is today with the mailing list. Otherwise, subscribe to individual threads as they show up and interest you. We will be providing a bot-operated secondary mailing list that receives New-Issue notifications only, if you want to be informed of new issues without necessarily seeing all updates on those issues; this should function as nice mid-level alternative between silence and firehose. (This'll happen once someone has the time to write the bot.) This process will also serve as a pilot for the CSSWG to do the same thing. If it goes well, expect to see a proposal for CSSWG to move to GH Issues sometime in 2016. If you have any comments or concerns, please open a GitHub issue about them. ^_^ ~TJ
Received on Wednesday, 2 September 2015 22:34:09 UTC