ietf
[Top] [All Lists]

Re: Charging remote participants

2013-08-25 07:40:27
Hi Hadriel,

I agree that charging IETF participants with any money is not a good idea,
but charging participants with some effort/work/contribution to do is
needed. For example, participants SHOULD do some work in IETF, either
review, authoring, attending-meetings, commenting on lists, etc. Otherwise
the IETF will not develop. If someone just subscribe to the list with no
contribution, that I will not call a participant. The reward/motivation
from IETF to participants is to acknowledge in writting their efforts,
which I think still the IETF management still does not motivate/encourage.

IETF Remote Participants (IETFRP) SHOULD charge the IETF not the other way,
because still the IETF ignores some IETFRP efforts (or even hides
information that should be provided to the diverse community).

AB

On Fri, Aug 16, 2013 at 11:10 PM, Hadriel Kaplan
<hadriel(_dot_)kaplan(_at_)oracle(_dot_)com>wrote:


Since the topic keeps getting raised... I think that charging remote
participants any fee is a really terrible idea.  One of the really great
things about the IETF is its open and free (as in beer) participation
policy.  The real work is supposed to be done on mailing lists, and there's
no charge or restriction on who can send emails.  That policy is actually
quite rare for standards bodies, and makes our output better not worse.

Obviously we discuss things and do real work at physical meetings too, and
they're not simply social occasions.  At the end of the day we actually
want people to come to the physical meetings, but the realities of life
make that impossible for many.  But charging remote participants for better
tools/experience isn't the answer.  At least for me, whenever I'm
discussing a draft mechanism I actually *want* input from remote
participants.  I don't want it to be only from folks who can afford to
provide input.  I want it from people who can't get approval for even a
$100 expense, from people who are between jobs, people from academia, and
even from just plain ordinary users rather than just vendors or big corps.
 At one time we worried that free remote participation would lead to too
many random participants to get work done, but that hasn't become a problem
afaict.  Please don't whittle it down further to only those who can afford
it.

I would do anything whatsoever to avoid charging remote participants, even
if it means raising the fee for f2f attendees to subsidize
remote-participant tooling costs.

In that vein, I think a lot of the f2f attendees get our reg-fee paid by
our employer and another $50 or even $100 isn't going to make a bit of
difference for us - for those whom it would make a difference, I'd create
another category of f2f registration fee like 'Self-paying Attendee' or
some such.  Selecting the new category would drop your fee by the $50 or
$100, but wouldn't change what gets displayed on your badge or anything.
 It would be purely optional, with no guilt attached for not paying it and
no visible difference to anyone else.  Just put some words on the
registration form page saying something like "If you cannot expense your
registration fee, please select the 'Self-paying Attendee' category" or
something like that.  Or make it some checkbox thingy.  I believe the
majority of folks who can expense it will not have difficulty expensing a
'Regular Attendee' charge so long as it doesn't say we opted to pay more.

-hadriel

p.s. Even from a purely practical standpoint, charging remote participants
raises a lot of issues - we debate incessantly just about the f2f day-pass,
and that's nothing compared to this.  For example: if things break during
the meeting session, do we re-imburse them?  Do we pro-rate the
re-imbursement based on how many of their meetings had technical issues
with audio or video?  Do we charge a flat fee for the whole week of
meetings, or just charge per meeting session, or depending on how long the
session is?  Do we charge students a different rate, like we do f2f
reg-fees?  Do we need to provide tech support with a specific SLA?  This
while thing is a can of worms.  It's not worth it.


<Prev in Thread] Current Thread [Next in Thread>