Tim and all,
First, a small issues - I prefer to use the language ACCEPT and
DECLINE. I don't rejecting things - instead we are "declining their
offer to present". Thanks.
Second, the big and important issue.
The EclipseCon submission and review process is supposed to be open and
transparent. We stated as much on the call for
submissions page and again on the submission system.
To quote from these pages: "The selection this year is being done in an
open and transparent way using the Eclipse open source project rules."
and "Transparent: the process and the decisions will be visible to the
community; no decisions will be made behind closed doors".
This is very important.
We cannot be an open community if we are making decisions behind closed
doors.
When I look at this spreadsheet, I see lots of effort that you all have
put in, voting positively and negatively on these tutorials. But when
I look at the public face - the open and transparent face - of the
eclipsezilla entries themselves, I see something different, except for
Gunnar: I don't see any votes by the Program Committee.
So, for example, if we were to decline #159
as is, the community would read the Eclipsezilla and ask "hmm, where
are the negative votes?" If we were to accept #125,
the community would ask "where are the positive votes?"
Worse, if we were to decline something that has positive votes on the
submission and no negative votes on the submission (such as #124),
the community would wonder about how open and transparent the
process really is.
Thus you all MUST, and I repeat MUST, put all of your votes on the
eclipsezilla entries themselves. You must be committers who make
decisions in public. #176
should have seven +1s and then be accepted. #138
should have two +1s and three -1s and then be declined. And so on and
so on.
If you are not willing to make your votes public, then you should
resign from the program committee and your votes will be removed from
the pool... Period... I realize this is different from previous program
committees you have been on, but it is part and parcel of our being an
open organization - we have to make our deliberations and our decisions
public.
Third, on the 52
versus 70
(the two GEF proposals). Is the reason you are taking 52 is because
Randy is the project lead for GEF? Looking at the community feedback on
the two, there is one comment on each: the comment on Randy's is "the
EclipseWorld version was packed thus we need a GEF tutorial"; the
comment on Koen's is "I have seen Koen present on this topic before. He
has a great format for making this information easily consumable."
That second comment is a lot more positive about the presenter than the
first comment. Thus, if the reason the decision is being reached is
the name "Randy", I would like to suggest that you reconsider - our
goal is the best presenter, not just "the big names".
Perhaps you could open the question to the community - ask them (via a
newsgroup or an email to the membership at large or a blog entry or ??)
which of the two GEF proposals is the right one - ask them to comment
on the Eclipsezilla entries and then gather comments for a week or so
and then make a decision. Ask the two proposers to provide more details
to help the public decide. Use the community.
Fourth, I would like to add a "silver" Foundation vote for 151
(Designing APIs) (not golden as in "guaranteed accept", but silver as
in "please strongly consider for the sake of the Foundation"). It has
three positives from the community (including my own), and no
negatives. If a "silver" vote is sufficient to tip it from the PC's
four positives and no negatives into the yes-accept pool, that would be
good. If necessary, I will state this on the eclipsezilla entry
reinforcing my previous comment that this is important.
Tim Wagner wrote:
Program committee members,
Please find the tutorial
votes attached. I’ve also
included a recommendation column based on the following policy:
- Accept all talks with 6 or more
positive votes and no negative votes (20)
- Reject all talks for which the
sum of the positive and negative votes is <= 2. (13)
- Leave all other talks in an
undecided category pending a 2nd voting round. (17)
As a reminder we have 30
slots to fill, or 10 remaining if
we accept the 20 talks with 6 or more votes in this round.
-t
|
