| RE: [eclipse.org-eclipsecon-program-committee] Long talkbreakdownby projects and the two thematic virtual tracks(embedded and RCP) |
|
+1 on 60à45min for long talks so
that we can accept more. It’s a tough question – there’s
a huge amount of value in keeping a single, yearly conference, but it
necessarily means that we’re bringing together some fairly disparate
interests, and all of them require some minimal level of representation. FWIW,
I think a tightly packed program is still better than the alternatives so long
as it’s possible to attend what you’re interested in. (My big
complaint about JavaOne isn’t that it’s a large program, but that they
make it hard to read the program (and thus find what you’re interested in
seeing) and then you often can’t get into the popular talks anyway
without lining up an hour or more in advance. I hope we can avoid those
problems in EclipseCon…) In terms of future breakdowns, I’m a
fan of domains for several reasons: presenters usually know what area they’re
in, attendees often come with a list of topics they want to learn more about,
and PC members can rely on top-level projects or other domain-based groups to
help provide expert advice within such buckets. Some special categories operate
similarly – for instance, we had the RCP and embedded “themes”
this year, business is a special case, and “newbie” might be as
well. It’s also an easier way to make progress as a program committee –
reading every submission is increasingly daunting, so breaking down into
separate groups (assuming the allocation can be worked out) feels more scalable
as a process. From: eclipse.org-eclipsecon-program-committee-bounces@xxxxxxxxxxx
[mailto:eclipse.org-eclipsecon-program-committee-bounces@xxxxxxxxxxx] On Behalf Of Gaff, Doug 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. |