shiflett asked how important it is to be a "name" when submitting proposals for OSCON. I thought it was important enough a question that I shouldn't bury my answer in a comment. (And I have to try to catch up to TorgoX's number of posts somehow!)
To some extent, yes, the person matters. But rarely is it that simple. The three concerns are: topics, proposals, and people. There are topics that I know I have to cover. But on a single topic I might have several different proposals. I want the best one. But I also want to get a good distribution of people--I could almost have a Perl conference full of diverse topics with nobody but Damian and Dominus, but attendees would lose (I think) more from only having two points of view than they'd gain from having two great speakers and a lot of different topics.
Big names from p5p, mailing lists, CPAN, whatever, tend to have a "here's what you should be doing" point of view because they often created the technology they're talking about. But the not-famous in-the-trenches people often share real world-knowledge, telling attendees "here's what you have to do to make it work" without any of the head-in-the-clouds thinking or theoretical concerns that sometimes the famous people are prone to. (hoping I'm not making myself enemies!) It's important to get both sides--testing and QA used to be an academic exercise, but as my email bungle shows, it's pretty bloody important in the real world! The nature of technology is that what's far-out today is commonplace tomorrow, so it's important to have that mixture of "what you need to know to do your job today" and "what you'll need to know to do your job tomorrow".
Anyway, back to juggling topics, proposals, and people. For example, this year I had two proposal for Perl optimization tutorials: one from Mark Jason Dominus and one from Robert Spier. Both had submitted other talks, so it wasn't the case that I absolutely had to pick their tutorial to get them into the program. Dominus had a lot of other talk and tutorial proposals, and Robert had two or three others.
Both proposals were strong. I know that both presenters know a lot about the area--Robert's been doing a lot of a Real World sysadmin stuff lately (for perl.org, in fact) and Mark's got great insights into the internals of Perl. So in the end I selected Mark's tutorial, and as Robert was already speaking as part of RT and Single Sign-On talks, I knew the attendees would still have a chance to hear from him over the course of the conference.
This was a rare example because most proposals aren't equally good. If you don't include an outline that'll show me what you plan to talk about, or you do have the outline but it's missing a key component to the field, or you don't tell me what the benefit to attendees is, you're making it much harder for your proposal to be the best.
So yes, you are at a disadvantage in this game if I don't recognize your name and think "we must make room for him/her". But even then it's not a given. Inevitably, each year there is at least one famous Perl person who didn't get selected and is pissed off about it. But space is limited and sometimes I simply can't cram in everyone who deserves to be there. And there are dozens of non-famous Perl people who wonder how the heck they could have done better.
To some extent you're also at the mercy of how I feel about a topic. For example, I tend to lump database proposals together in my mind. If I get three proposals, one on DBD::something, one on DBIx::something else, and one on how you used Perl to reduce your DBA workload to something you can do from the beach via SMS on your cellphone, they're probably going to be duking it out for however many "databasey" slots I think I can give. And that number is affected by the content in the other tracks--this year there's an awesome MySQL and embedded Perl talk in the MySQL track, so I didn't feel the need to have a MySQL and Perl talk in the Perl track.
It's a complex juggling system, part intuition and part method, and I'm sure it's cruelly unfair. If you've written to me asking "why didn't I get accepted?" I'll be replying over the coming week, explaining how far your proposal got and how you could improve the outline, description, or title.
While I have your attention, though, the single best thing you can do is give your talk or tutorial a meaningful title: "Effective Perl Debugging Strategies" is so much easier to see the importance of than "Kickz0r Your Fl34z: Debugging a New Millennium". (I made up that title) There were some talks and tutorials that I suggested new names for, because they were good but it would be hard for someone skimming the list to recognize how good they were. But I'm sure that some worthy talks and tutorials were inadvertently penalized because "Doing Better Perl" just didn't jump out at me from the lists when I was juggling the last twenty candidate talks and only had five slots to put them in.
--Nat
But the not-famous in-the-trenches people often share real world-knowledge, telling attendees "here's what you have to do to make it work" without any of the head-in-the-clouds thinking or theoretical concerns that sometimes the famous people are prone to. (hoping I'm not making myself enemies!)
Not at all, Nat.
We theoretical, head-in-the-clouds thinkers already hate you!
Seriously though, Nat does have a legitimate mandate to provide some "brand name recognition" -- in order to attract attendees to the conference. However, despite that constraint, he almost always seems to favour selecting presentations on their own merits and on the perceived value to the OSCON audience.
Consequently Nat rejected approximately half of the proposals I submitted this year. Last year, he rejected a little over two-thirds of presentations I pitched.
So being a "name" is no guarantee of automatic acceptance.
It's also important to bear in mind that there is a vast oversupply of proposals to fill the relatively small number of available slots. I don't know what the actual numbers were this year, but I'd be surprised if there weren't at least five hours of proposals for every available one hour of conference time.
Re:Fame is no guarantee...
gnat on 2003-03-19T03:29:40
It's also important to bear in mind that there is a vast oversupply of proposals to fill the relatively small number of available slots. I don't know what the actual numbers were this year, but I'd be surprised if there weren't at least five hours of proposals for every available one hour of conference time.It's more two to one numerically, but that doesn't take into account the durations: we had a lot more tutorial proposals than we could take.
--Natmysql> select count(*) from e_sess where e_conf='[23]' and status='[confirmed]' o
r status='[accepted]';
+----------+
| count(*) |
+----------+
| 179 |
+----------+
mysql> select count(*) from e_sess where e_conf='[23]';
+----------+
| count(*) |
+----------+
| 544 |
+----------+Re:Fame is no guarantee...
Damian on 2003-03-19T04:11:29
Err. 544:179 is fractionally over 3:1.
But I'm still surprised contention wasn't higher.
(Of course, if a quarter of those submissions were for tutorials, then that's 136 proposals for maybe 24 tutorial slots, which is better than 5:1.)Re:Fame is no guarantee...
gnat on 2003-03-19T21:54:56
Err. 544:179 is fractionally over 3:1.Yeah, I was thinking "I could have schedule two more for every one I coudl take", hence 2:1.
Proposal numbers would have been higher if we'd had been more on the ball with PHP and PostgreSQL CFPs. Both those tracks were unnaturally muted, because we dropped the ball getting the word out. (Bruce from PostgreSQL was mysteriously not on the committee mailing list, etc.) It was like an OSCON gypsy curse
:( We only managed to get a good lineup for those tracks by dint of much last-minute scrabbling. --Nat
Re:Fame is no guarantee...
Damian on 2003-03-20T02:35:07
Ah, so you're saying that theoretically, from a capunebulous perspective, the ratio was in fact 5:1.
;-) Re:Fame is no guarantee...
gnat on 2003-03-20T05:21:58
Mumble mumble capurectal coitocranial mumble mumble.:) --Nat
