W3C home > Mailing lists > Public > public-houdini@w3.org > September 2015

[announcement] Houdini moving to GitHub issues for all technical discussion

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 2 Sep 2015 15:33:22 -0700
Message-ID: <CAAWBYDA72TRh_Tb8owgo-QHXnu1CUPirBPHhz8nQRE6yKbFPhw@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:53:24 UTC