| RE: [eclipse.org-eclipsecon-program-committee] Long talk breakdownby projects and the two thematic virtual tracks (embedded and RCP) |
|
I like the idea of going back to 45 minute
slots. Yeah, the conference will feel tight again, but it seems worse to
compress so much good content into short talks. Even with the additional
slots, we will still find ourselves rejecting very good talks for lack of time. It does beg the question though: in
future conferences, how should we address this? If we assume that the Eclipse
community continues to grow rapidly, does this problem just get harder and
harder each year? Do we need more parallel sessions and additional tracks
in future years? For example, the following breakdown: - Application-specific (embedded, rcp, etc)
– both developer and user perhaps - “newbie” developer/user –
put all of the intro stuff here and schedule accordingly - Advanced developer – showcase the
project changes - Business - Cool stuff – all of the extras –
“Eclipse in the wild” It’s premature to talk about this I
supposed. It’s just been on my mind so I thought I’d send it
out. From: eclipse.org-eclipsecon-program-committee-bounces@xxxxxxxxxxx
[mailto:eclipse.org-eclipsecon-program-committee-bounces@xxxxxxxxxxx] On Behalf Of Bjorn Freeman-Benson PC Members, From
the discussion on the “Developer Track Subcommittee” telecon Monday
evening. Partitioning the talks should help us hone in on finalizing the long
talk portion of the program. Note that not all of these selections are
finalized yet (because in some cases we need project feedback, additional
discussion, etc.)
I'd really prefer to see a program that does not
require trading in (any? very many?) short talks. The advantage of short talks
is that they give more people the chance to talk about their technology and
their ideas. At a 6-to-1 ratio, the short talks are a good use of time... I'm sure you know this already, but just a reminder
that you don't have to just accept the "most public voted"
submissions - you are a committer-based meritocracy and you at the top of that
merit tree. Thus you (collectively and using the open source rules) have the
final say. The public voting is for your guidance; they are like bug reports
(in fact, they are bug reports!) with patch files. You can choose to
accept them or not, based on their merits. If you think a talk with a lot
of votes is not worthy of being in the program - say so. If you think a talk
with few votes is important - say so. In the end, just like when you write
code, your names are associated with the program content - you will be listed
on the website and the printed program. Technology (no specific allocation, but this seems like too
few)
Most of the Technology projects are candidates for
short talks rather than long talks. In my wildest dreams, I can only imagine
long talks from:
If I only get one more, I'd choose PTP - it's a better
Technology talk than ORM. |