Suggestions and Examples of What Not to Submit
1. Attendees are paying to take classes—they don’t want to hear a sales pitch, no matter how thickly veiled. Please do not submit classes that feature your product or describe problems that happen to be solved by your products.
Attendees and the conference organizers are equally skeptical of technical talks proposed by marketing people, Business Development Managers or CEOs—unless that person has the appropriate technical background and experience. Even the appearance of a sales pitch, such as when a talk is given by a marketer, will cause people to not attend that class.
2. Attendees don’t need to be taught why something is important (why security testing is important, why testing early in the SDLC is important, etc….). If they sign up for the class, they already know that. In your abstract, explain how the attendees will learn HOW to do something by taking your class.
3. Read the Course Catalog from the previous conference to learn how the classes are described. Try to match that, and have a colleague review your submission to make sure that your abstract makes sense. Experience has shown that an incoherent abstract is not a good sign for a coherent presentation.- From the Software Test&Performance
Call for SpeakersIf you run a conference, especially a regional or non-profit one, you might want to slap something like this right onto your call for speakers. After running a regional software conference and participating in a few more, I've seen pretty much all of these problems. Heck, I've seen them in Lightning Talks.
Sometimes it can be very hard for a program chair to know who to select and who not to. The best thing we can do to help is to give them solid presentations, a strong outline, and no fluff.