Being from one of those small companies I appreciate the sensitivity
here. Having come from a large company I know the challenges in
getting the wheels to grind as/when desired. I quite liked Bjorn's
suggestion of "remove the speakers until they get their act together".
There is a risk however that disoriented speakers such as myself will
forget which talks they were on once they are removed. (BTW I have
already signed my speaker agreement so am safe this year). So I
propose that we institutionalize this approach and simply *mark* all
speakers on the talks as hidden until such time as they have submitted
their agreement. So for all intents and purposes the speaker has been
removed. They are not publicly associated with the talk and would not
appear in the program etc. This seems simple and effective.
Jeff
Kevin McGuire wrote:
Hi Bjorn,
Thanks for the answer.
I can't speak to whether there haven't been negative consequences, or
you
just haven't seen them (it could've created friction that never
surfaced
publically).
I agree it's important/required that
people sign the agreements before registering. I'm not arguing that.
The basic assumption that I find
questionable
is that the peer pressure will positively drive the speaker's behaviour
to get the agreement signed. That's true if it's up the speaker,
but in many organizations no document can be signed without prior legal
approval. Maybe those people are away, maybe they're busy with other
things... all sorts of things can happen which have nothing to do
with
the speaker.
The penalty to an organization in
not
getting themselves sorted is that they miss the early registration and
must pay more. That's perfectly fine. But by requiring signing
to be true for all speakers, the penalty of one company's tardiness
will
cost some other, leaving the poor speaker's in the middle. I'm
particularly
sympathetic to the smaller companies (e.g. individual consultants), for
whom the financial impact could be quite real.
There's still time to early
registration
so maybe as you said it just all works out fine, there's no specific
problem
I'm speaking to, but I just think this is unhealthy dynamics. The
fact it can be circumvented by removing/adding speaker's may avoid the
financial impact to a company but doesn't fix the dynamics issue.
As a program committee member I
regard
it as part of my job to ensure the conference is the best it can be
(thus
the CC to the others). If this is more an Eclipse.org policy and
up to the emo then I'll (try to <g>) stop arguing.
Best Regards,
Kevin
Kevin,
We understand your perspective and I'll answer this in two ways:
First, we've been doing the agreements this way for a while and haven't
seen any negative consequences. Thus I would say that the evidence does
not support your opinion.
Second, it is important from a legal perspective that we get people's
e-signatures
before they speak. In the past, we've had difficulty with people not
signing
their agreements. Peer pressure is one of the main mechanisms that open
source projects use to enforce their rules and thus my choice of peer
pressure
in this case is consistent with other uses of peer pressure in
Eclipse-land.
Third, there's an easy solution for authors whose co-authors are more
corporately
delayed: remove those other co-authors until their legal departments
can
return a verdict and then re-add the co-authors at that time. In the
meantime,
the less delayed co-authors will have signed and can use their discount
coupon to register.
- Bjorn
Kevin McGuire wrote:
I strongly feel we should remove
this
restriction of all speakers signing before one can register. One
signature, one registration.
P.S. Nothing is preventing co-authors from registering
- the only constraint is registering at a discount/free. For long
talks,
the need-all-signatures constraint only delays the free registration:
those
who are paying can register as soon as they want.
--
[end of message]
_______________________________________________
eclipse.org-eclipsecon-program-committee mailing list
eclipse.org-eclipsecon-program-committee@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-eclipsecon-program-committee
|
