Let’s suspend the 10am meeting until
I have a chance to communicate further with Bjorn about our processes.
From: eclipse.org-eclipsecon-program-committee-bounces@xxxxxxxxxxx
[mailto:eclipse.org-eclipsecon-program-committee-bounces@xxxxxxxxxxx] On Behalf Of Bjorn Freeman-Benson
Sent: Thursday, November 10, 2005
6:50 PM
To: Eclipsecon Program Committee
list
Cc: ward@xxxxxxxxxxx
Subject:
[eclipse.org-eclipsecon-program-committee] Tutorial voting and theOpen process
(IMPORTANT)
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
