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

> On 03 Sep 2015, at 07:33, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> 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. ^_^

A couple of comments about things you did not include in your mail.

- If you're receiving github issues by mail, you can reply to them from your mail client directly, and answer will go to github, in the correct thread. This is nice for those of us who occasionally need to work offline, as mail offers an asynchronous way to interact with github, both to read and to write

- Unfortunately, it doesn't seem to be possible to open new github issues by sending a mail. Someone will need to write a bot for that, or convince the nice folks over at github to do it for us

- Tagging an issues as being part of a particular spec seems to be something only members can do. This is a bit unfortunate, but would be solved by splitting the repo into one repo per spec. But that has downsides too (loss of cross spec history, changes needed to our web/test/build/... infrastructure to keep track of multiple repos rather than multiple specs per repos...), so we haven't done it so far. Solving this well is probably key for the potential CSSWG migration.


Florian

Received on Thursday, 3 September 2015 02:21:05 UTC