Re: AD Time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hiya,

On 26/07/18 01:11, Ted Lemon wrote:
> Obviously the sponsorship can't have strings attached.   If you want there
> to be a QUIC AD, you had better make sure that there's enough funding for
> all the AD positions that exist.   You suggest that this would make things
> worse in terms of corporate control of the IESG, but if you take such a
> pessimistic view, that's already the status quo. 

No. I'm neither pessimistic (since I don't believe your idea
will fly), nor do I agree that your proposal is equivalent to
the status-quo. Yours is worse IMO.

>  There is the potential
> for a feedback loop if you can stack the IESG, but one thing that
> sponsorships allow is for orgs that can't afford to fund an FTE can still
> participate, 

Again, you assume that full-time ADs is a good thing. I do not
agree that that's a good goal.

> as with your term, which you say required multiple sponsors at
> the same time.

I didn't say that. It was different funders sequentially in my
case.

Honestly though - in the absence of any worked-out proposal isn't
it time to end this thread or take it offlist? I'm happy to chat
more but unhappy to be boring the full list, which I suspect is what
we're doing.

Cheers,
S.

> 
> On Wed, Jul 25, 2018 at 7:56 PM, Stephen Farrell <stephen.farrell@xxxxxxxxx>
> wrote:
> 
>>
>> Hiya,
>>
>> Getting to the specific ickiness...
>>
>> On 26/07/18 00:28, Ted Lemon wrote:
>>> The way I would
>>> expect this to would would simply be that the IETF would solicit
>>> sponsorships for AD positions, at a certain pay rate, and if someone was
>>> appointed, they'd get paid.
>>
>> Ick. So then we'd have 10 QUIC ADs? And maybe 10 from up-and-coming
>> companies from up-and-coming places working in up-and-coming spaces.
>> And of course, we'd be motivating companies to get rid of what they
>> might currently consider problematic AD roles - so no more of those
>> pesky security ADs say the rich (e.g. routing) companies de-jure? I
>> can imagine them earnestly explaining how they just don't have dosh
>> this year for that role, and are genuinely sorry. Ick.
>>
>> If you really wanted a sponsorship scheme, the money would need to
>> be thoroughly laundered, which then hands control to the laundry.
>> It's just a bad plan.
>>
>>> I don't think there would be a "reimburse the
>>> employer" process—the AD would just get paid, and it would be a
>> contract
>>> with a clear termination date, and exit clauses for termination with
>> cause
>>> by the IETF AD removal process.
>>
>> Do you know that according to Irish (and likely other EU) labour
>> law, that'd mean that a 4th AD term would entitle that person to
>> a full-time permanent employee position? That's good legislation
>> IMO, but I do not think the IETF ought be risking it applying for
>> the AD role.
>>
>> And of course, if a recall ever happened, then the money involved
>> would make a law suit quite likely.
>>
>> But a much more likely a bad consequence, is that whomever is the
>> sponsor may expect that "their" AD would act in their interests.
>> We have in the past seen such motivations impact on nomcom, and I
>> have very occasionally seen ADs worry about potential hidden agendas
>> of other ADs. What you're suggesting would make all that much worse,
>> and likely quite quickly.
>>
>> None of this is worth the time we've spent on these emails. It's
>> just a bad idea - wrong target (guaranteeing time), wrong method
>> (sponsorship) and IMO guaranteed wrong outcome (death to nomcom;-)
>>
>> Cheers,
>> S.
>>
>> PS: I do agree that the end of an AD's term is tricky, in very
>> many cases. That's another reason to try reduce the time needed
>> without affecting the rest of the AD's week. It is not a reason
>> to try fund 100% paid-for ADs. OTOH, what Christian and Warren
>> have said is entirely true (of me at least) - I learned a whole
>> lot doing the AD thing, and I feel the better for that, so it's
>> well worth doing.
>>
>>
>>
>>
>>
> 

Attachment: 0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux