Why Your JavaOne Submission Was Rejected

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.

JavaOne submission acceptance letters - and rejection letters - starting going out last night. This year, I was on the review committee for one of the tracks, so I got to see the proposals as well as the reasons for rejecting many of them. I thought I'd write these up, both to explain to the many submitters what might have gone wrong, as well as to give some tips for how to improve your chances next year. I'll probably link back to this post around the time submissions for JavaOne 2009 open up later this year.

• 
  Not Enough Details! There were a number of submissions that sounded interesting, but didn't include enough details for us to judge whether there is enough technical meat behind the promises. If you're promising insights or "lessons learned", tell us what those lessons are, such that we can judge whether your presentation will be worthwhile (and in particular, whether to choose your submission over the handful of other similar submissions in the same topic area).
  




• Wrong category! I was on the Tools and Languages track. You wouldn't believe how many submissions to our track
  were not related to tools and languages. Framework, Practices, Process or Methodology: If any of these words are in your title, make sure you're really explaining how this is going to be tool related or language related.
  
  
  
  
  So why can't we just reassign them to the right track? Well, each committee works independently, and if we were to suddenly have to accept "new" proposals that were miscategorized earlier that would increase the work a lot - we've already gone through and picked our top candidates for each subject area and so on.
  




• 
  Not of General Interest! If you're submitting for a technical session, rather than a BOF, the talk will be offered in a room seating hundreds and sometimes thousands of attendees. The subject needs to be interesting to more than 20-50 people. If you're proposing a talk on a subject that is extremely narrow or a tool or language that doesn't have a lot of traction yet, you'll have better odds submitting the talk as a BOF.
  




• Crowded Topic! Some topics are extremely popular. We received a large number of submissions for Groovy and Ruby for example. This means that if you submitted talks in one of these areas, even a perfect abstract wasn't enough and the choice for the committee was very difficult.
  




• Strong Competition! At the end of the day, we only had about 20 technical sessions to hand out. We had more than ten times that number of submissions. We had roughly 10 talks for tools, and 10 talks for languages. Let's take languages - there's Groovy, Scala, Ruby, Jython, Java, ... as you can see there's not room for more than one or at most two talks in any one topic area.
  
  The good news is that this hopefully means we'll have very high quality for the technical sessions!
  

Finally, work one one strong submission rather than submitting 5-10 half-baked ones; just adding lots of abstracts does not help your odds given my points above about the low number of available slots; each submission has to be fantastic.