This year's JavaOne session review has just been completed and by now everyone who submitted papers should know whether they were successful or not. I had the pleasure again this year of leading the review of the 'JavaFX and Rich User Experiences' track. I thought it would be useful to write up a few comments to help people in future when submitting session proposals, not just for JavaOne, but for any of the many developer conferences that run around the world throughout the year. This also draws on conversations I recently had with various Java User Group leaders at the Oracle User Group summit in Riga. Many of these leaders run some of the biggest and most successful Java conferences in Europe.
Try to think of a title which will sound interesting. For example, "Experiences of performance tuning embedded Java for an ARM architecture based single board computer" probably isn't going to get as much attention as "Do you like coffee with your dessert? Java on the Raspberry Pi".
When thinking of the subject and title for your talk try to steer clear of sessions that might be too generic (and so get lost in a group of similar sessions).
Introductory talks are great when the audience is new to a subject, but beware of providing sessions that are too basic when the technology has been around for a while and there are lots of tutorials already available on the web.
JavaOne, like many other conferences has a number of fields that need to be filled in when submitting a paper. Many of these are selected from pull-down lists (like which track the session is applicable to). Check these lists carefully. A number of sessions we had needed to be shuffled between tracks when it was thought that the one selected was not appropriate. We didn't count this against any sessions, but it's always a good idea to try and get the right one from the start, just in case.
JavaOne, again like many other conferences, has two fields that describe the session being submitted: abstract and summary. These are the most critical to a successful submission. The two fields have different names and that is significant; a frequent mistake people make is to write an abstract for a session and then duplicate it for the summary. The abstract (at least in the case of JavaOne) is what gets printed in the show guide and is typically what will be used by attendees when deciding what sessions to attend. This is where you need to sell your session, not just to the reviewers, but also the people who you want in your audience. Submitting a one line abstract (unless it's a really good one line) is not usually enough to decide whether this is worth investing an hour of conference time. The abstract typically has a limit of a few hundred characters. Try to use as many of them as possible to get as much information about your session across. The summary should be different from the abstract (and don't leave it blank as some people do). This field is where you can give the reviewers more detail about things like the structure of the talk, possible demonstrations and so on. As a reviewer I look to this section to help me decide whether the hard-sell of the title and abstract will actually be reflected in the final content. Try to make this comprehensive, but don't make it excessively long. When you have to review possibly hundreds of sessions a certain level of conciseness can make life easier for reviewers and help the cause of your session.
If you've not made many submissions for talks in the past, or if this is your first, try to give reviewers places to find background on you as a presenter. Having an active blog and Twitter handle can also help reviewers if they're not sure what your level of expertise is. Many call-for-papers have places for you to include this type of information.
It's always good to have new and original presenters and presentations for conferences. Hopefully these tips will help you be successful when you answer the next call-for-papers.
