Maybe conference reviewers shouldn't also be speakers
Here's one to think about: if you're reviewing sessions for a conference, should you be allowed to submit sessions of your own to that same conference? On the one hand, this seems like an arbitrary restriction, and one that would harm the conference: you're apt to lose either good sessions or good reviewers if the people who know what they're talking about can't participate in one role or the other.
But on the other hand, being part of the review committee gives would-be speakers an advantage over others. Even if they don't vote on their own proposals, someone wearing two hats may know the other reviewers and have a chance to lobby them. When I was on this year's OSCON committee, I gave a low rating and pretty harsh review to a talk whose submitter was later added to the committee, and who was therefore able to see my comments. I didn't change my vote or comments -- I wouldn't want to say things behind colleagues' backs that I wouldn't say to their face -- but still, would I have graded it differently if I knew the submitter was or would later be a committee member?
Cay Horstmann faced a nearly identical issue recently, in reviewing JavaOne proposals:
I am a reviewer for Java One. I have about 350 project proposals to plow through and not enough time to give each of them justice.
One submitter proposed a talk on "Doing your own language". The outline talked about parsing, abstract syntax trees, and generating code. I flippantly commented "A DSL is not a DYOL. You use a DSL precisely because you DON'T want to write another parser."
Of course, what I had in mind was the recent trend of embedding DSLs in programming languages such as Groovy and Scala. (See this blog for Groovy.)
The submitter happened to be a reviewer in another Java One track, so he was able to see my comment, and he was not happy. He emailed me: "I feel strongly that this is mistaken. Most DSL's originate with domain experts, who become weary of using general-purpose languages to work within their domain concepts and patterns. Many of us are the beneficiaries of such efforts, but DSL's don't spring forth from nothingness."
In his blog, DSLs--Standalone or Embedded?, Cay then gets into the substance of the debate: "Now here is my thinking. Technically speaking, the submitter is right. A DSL is simply a domain-specific language, and the term does not imply an implementation strategy. [...] I just think that the embedded approach should be the approach of choice when it is at all feasible."
Also in today's Weblogs, Sergey