Skip to main content

Sensys 2009 PC meeting

The Sensys'09 PC meeting was held here at Harvard a couple of Saturdays ago. I meant to post about this earlier, but a little something got in the way.

This year we had 119 full paper submissions (down a bit from last year) and accepted 21 papers, for an acceptance ratio of 17.6%. This is similar to the acceptance ratio for previous years, and I think it represents a healthy level of competition for the conference. Personally, I would have preferred that we accepted closer to 25 papers, but at some point there's only so much pressure one can put on the program committee to make that happen. The full list of accepted papers is here. It is a very strong program and Jie and I are both extremely appreciative of the program committee for all of their hard work.

Overall, I was very happy with the reviewing process this year. The model we used for Sensys was similar to other top-flight systems conferences: PC members do the reviewing themselves (rather than farming out to external people or students); they write detailed reviews; and everyone has to attend the PC meeting in person. The program committee did a fantastic job and worked very hard to make this happen. On average each PC member reviewed 22 papers. We reviewed papers in two rounds. All papers were assigned three reviews in the first round. Roughly 50% of the papers were considered in the second round and got at least two additional reviews, sometimes more.

During the PC meeting, we grouped papers roughly by topical area, rather than simply ordering them globally by score. This made it possible to directly compare multiple papers on, say, time synchronization during the discussion. I think this worked very well as it provided more context for the discussion on a given paper and often some of the same PC members were involved in reviewing papers in a given area. At the end of the first pass we had roughly 15 papers in the "accept" list and about the same number in the "maybe" category. We then went through a second pass on the "maybe" papers to come up with the final list. The PC was generally very positive during the discussion; and in a few cases a reviewer with an initially negative reaction to a paper was able to reconsider as the rest of the program materialized.

One thing I am mindful of is that it is sometimes harder to accept a paper when it has "too many" reviews. At SIGCOMM, NSDI, and other conferences, I've seen papers get 7 or more reviews in the final round. My concern is that beyond a certain point enthusiasm for a good paper tends to wither with more reviewers weighing in on it. We recognize that no paper is perfect and the question was which papers were both technically sound and interesting enough to constitute a good program. The two-round process seemed to strike the right balance. I did not feel that we were accepting or rejecting papers based on not enough information.

We also had a fairly diverse program committee this year, including some folks representing areas not traditionally associated with Sensys. Part of our goal here was to ensure that the PC was not too insular and that we got a broad range of opinions. We also wanted to broaden the scope of the conference to encompass non-conventional sensor networks. We have a few good papers involving application case studies as well.

It should be an exciting conference - hope to see you in Berkeley in November!

Comments

  1. Matt, I notice you are an author on a paper. What is your thinking on a PC chair having a paper in their own conference? How did you handle conflict of interest?

    ReplyDelete
  2. That's right, I do have a paper in the conference. So does Jie Liu, my co-chair.

    We had a long discussion with others, including the SenSys Steering Committee and organizers of other conferences, before deciding to allow Program Chairs to submit to the conference. SenSys, along with many other conferences, has traditionally allowed Program Chairs to submit papers. We felt that it would be unfair to our students and collaborators to suddenly change this practice for this year. If you look back on past SenSys conferences, the program chairs are often fairly active members of the community and it is not unusual for them to publish papers in the conference when they are chairing it.

    It is always a tricky issue as it is important to avoid any kind of conflict of interest. In this case, the Program Chair papers were handled completely outside of the regular reviewing system and as a result Jie and I never had any knowledge of or influence over the identity of the reviewers. The reviewers were no doubt aware that these were PC authored papers and we hope they held these papers to a very high standard. Jie and I both left the room during the discussion of these papers and delegated the "chair" role to another PC member.

    I'm happy to answer any questions about the process as we think it's important to be as transparent as possible!

    ReplyDelete

Post a Comment

Popular posts from this blog

Why I'm leaving Harvard

The word is out that I have decided to resign my tenured faculty job at Harvard to remain at Google. Obviously this will be a big change in my career, and one that I have spent a tremendous amount of time mulling over the last few months.

Rather than let rumors spread about the reasons for my move, I think I should be pretty direct in explaining my thinking here.

I should say first of all that I'm not leaving because of any problems with Harvard. On the contrary, I love Harvard, and will miss it a lot. The computer science faculty are absolutely top-notch, and the students are the best a professor could ever hope to work with. It is a fantastic environment, very supportive, and full of great people. They were crazy enough to give me tenure, and I feel no small pang of guilt for leaving now. I joined Harvard because it offered the opportunity to make a big impact on a great department at an important school, and I have no regrets about my decision to go there eight years ago. But m…

Rewriting a large production system in Go

My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in Go. I say "almost" because one component of the system -- a library for transcoding between image formats -- works perfectly well in C++, so we decided to leave it as-is. But the rest of the system is 100% Go, not just wrappers to existing modules in C++ or another language. It's been a fun experience and I thought I'd share some lessons learned.

Why rewrite?

The first question we must answer is why we considered a rewrite in the first place. When we started this project, we adopted an existing C++ based system, which had been developed over the course of a couple of years by two of our sister teams at Google. It's a good system and does its job remarkably well. However, it has been used in several different projects with vastly different goals, leading to a nontrivial accretion of cruft. Over time, it became apparent that for us to continue to innovate rapidly wo…

Running a software team at Google

I'm often asked what my job is like at Google since I left academia. I guess going from tenured professor to software engineer sounds like a big step down. Job titles aside, I'm much happier and more productive in my new role than I was in the 8 years at Harvard, though there are actually a lot of similarities between being a professor and running a software team.

I lead a team at Google's Seattle office which is responsible for a range of projects in the mobile web performance area (for more background on my team's work see my earlier blog post on the topic). One of our projects is the recently-announced data compression proxy support in Chrome Mobile. We also work on the PageSpeed suite of technologies, specifically focusing on mobile web optimization, as well as a bunch of other cool stuff that I can't talk about just yet.

My official job title is just "software engineer," which is the most common (and coveted) role at Google. (I say "coveted&quo…