1. Why TinyToCS?

    It’s been a few weeks since we launched TinyToCS to the community. Time to answer a question that I’ve been asked dozens of times since we launched: why are we doing this?! So here, I’m going relay a summary of the conversations I had with with Peter Bailis and Greg Valiant when we were planning TinyToCS.

    For those of you who missed the memo: TinyToCS is a “tiny” CS publication venue, in which the core idea of the paper must be conveyed in 140-characters or less (yes, that’s the length of a tweet). Authors are allowed references, and an abstract of up to 250 words — but the abstract is only allowed to provide background on the result/core idea. The abstract is not allowed to elaborate on the result. 

    We think TinyToCS has a valuable role to play in the CS community.

    We’re accustomed to sound-byte media. I find out about the latest news through Twitter/Facebook/My-RSS feed, and only then do I click through to read the whole article. The tech community at large disseminates a deluge of information through HackerNews, Slashdot, and the like.

    The CS community doesn’t work that way. Our method of content distribution is research papers. Research papers are an important part of the scientific process and have been for hundreds of years: you present your idea, describe what you did, why, how it works, thoroughly describe it down to every last bolt and nut, and then evaluate the heck out of every aspect of it that matters. Let’s be clear about our respect for research papers. When I’m reading through related work for a project, and want to know how project X implemented system Y or exactly how algorithm Z works, 140 characters just isn’t going to cut it.

    But research papers fail in some major ways: they’re slow to read (14 pages for a typical computer systems paper); they aren’t accessible to the community at large (I don’t understand the research papers that my Machine-Learning housemates publish); they’re slow to publish (months pass between a finding/result and when the work is actually presented at a conference); and they’re not aggregated in a timely way (my housemates found out about the latest and greatest in Software Defined Networking from New York Times article a few months back - SDN has been going on for years now at Berkeley).

    There are a number of great efforts to resolve parts of these problems, most notably, Communications of the ACM. CACM is great. I subscribe to it, as do many of my fellow PC members. But CACM doesn’t cover the time problem (articles in CACM come out even later than the conference edition), they’re a lot of work for the authors to put together, and because they’re curated “best-of” sets of work they don’t cover the play-by-play of what’s going on in the field. Contrast this to my RSS feed, which has more headlines than I can possibly read on more topics in industry than I quite understand, that I (as a 21st century young person) am adept at quick-filtering and deciding what to dig deeper on and what to skip.

    My generation is used to a fast-paced influx of information that we can quick-filter in to information we want to dig deeper on. There is no such medium for the CS community.

    TinyToCS, starting this July, will fill this gap. Submission cycles will be every three months. TinyToCS focuses on the sound bytes to draw readers in and convey key ideas, but provides background and references to those who want to dig deeper. TinyToCS considers accessibility to the CS community at large to be a key component of the selection criteria.

    We’re keeping the trappings of a program committee because we want to uphold a high standard of content. But we’re not filtering for what we think is the best work in a particular subfield - we’re filtering for what we think would be of interest to the community at large.

    So maybe, TL;DR?  Think of TinyToCS as your chance to submit an elevator pitch to the whole community, and have it get out there within weeks, not years.

    Hope to see you submit!

    2 years ago  /  0 notes  /  View comments