how_to_get_your_session_accepted_at_an_agile_conference
no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
Last revision | |||
— | how_to_get_your_session_accepted_at_an_agile_conference [2018/11/13 06:54] – created hpsamios | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== How To Get Your Session Accepted at the Agile Conference? ====== | ||
+ | |||
+ | ====== Premise ====== | ||
+ | |||
+ | The bottom line is that for the Agile Alliance Conference there are at least three times more submissions than the number of sessions that could run in the conference week. In addition you will be competing for slots with people that are already " | ||
+ | |||
+ | ====== Advice ====== | ||
+ | |||
+ | Some collected advice and learning after doing Agile Conference submissions for a while. The main aim here is to get a session accepted because we believe we have something important to add to the agile discussion. But we also need to sell the importance of our session. Some of this learning is based on "what seemed to work" but since the submission system is a bit like black box these observations might have been the result of " | ||
+ | |||
+ | * Have a catchy name for the session, something that pokes fun or is a little controversial. This helps not only in capturing the interest of the reviewers, but makes it more memorable when it comes time for the reviewers to determine who will be presenting. And it will help when the conference attendees are thinking about which session to attend. | ||
+ | * From past experience we have learned that proposing a single session significantly reduces your chance of being accepted. So we proposed 3 this time. This is just playing the odds and is based on talking to people that did get accepted - most had submitted more than one. | ||
+ | * From past experience level of discussion associated with an entry is no indicator of likely acceptance. First time I was accepted there was no input. Second one had a lot of people commenting, and saying things like "good subject" | ||
+ | * Work offline, work collaboratively. Take a copy of the headings on the submission page and put them of something like a wiki page so you can work with others on the submission. Track changes made, especially the big ones as a result of comments so there is an understanding of the history but, more importantly, | ||
+ | * Read the Agile web site instructions. I've been submitting for a few years, but what I found is that the use of the proposal system has changed a little over that time. For example, the abstract is now more aimed at what the conference goer will see and respond to as opposed to being an abstract for the submission process. As such I was making it too long. I could have figured this out by reading the instructions a little closer instead of assuming I knew what was going on. | ||
+ | * Read the section on what the stage is about, specifically the questions they see the stage is addressing and then craft you submission so you address a few of those items explicitly. Having been on the " | ||
+ | * The section called " | ||
+ | * Don't overload the section on " | ||
+ | * The first paragraph of the abstract needs to capture people' | ||
+ | |||
+ | End result - 1 presentation accepted out of 3 submitted, as we expected for the year I wrote this. | ||
+ | |||
+ | ====== Want to Know More? ====== | ||
+ | |||
+ | * [[ideas_for_future_conference_sessions|Ideas for Future Conference Sessions]] also shows previously accepted sessions | ||
+ | |||
+ | {{tag> | ||
/home/hpsamios/hanssamios.com/dokuwiki/data/pages/how_to_get_your_session_accepted_at_an_agile_conference.txt · Last modified: 2020/06/02 14:22 by 127.0.0.1