[CCWG-ACCT] Budgetary veto/control solves the wrong problem and avoids solving the right one

Jordan Carter jordan at internetnz.net.nz
Mon Jul 27 18:46:25 UTC 2015


I'd go further in thanking you, George, for a nice write up of what WS2
needs to solve in these respects.

But given the community's feedback on the WS1 proposal, dropping this power
now isn't going to work.

It is also worth me gently pointing out that we have to finalise our draft
proposal in the next 36 hours or so. Going back to basics isn't viable.

best
Jordan

On 28 July 2015 at 05:15, Jonathan Zuck <JZuck at actonline.org> wrote:

>   And fundamentally, this is an empowerment issue, not meant to be a
> practical tool for budget or strategic plan development. A big part of WS2
> is improving the process by which the budget and strategic plan are
> developed in the first place. WS1 is about empowering the community.
>
>   From: <accountability-cross-community-bounces at icann.org> on behalf of
> Kieren McCarthy
> Date: Monday, July 27, 2015 at 1:00 PM
> To: Dr Eberhard W Lisse, CCWG Accountability
> Cc: "directors at omadhina.net"
> Subject: Re: [CCWG-ACCT] Budgetary veto/control solves the wrong problem
> and avoids solving the right one
>
>  What I think you're missing with your analysis, George, is the fact that
> the community knows it has a window to put things in place so more granular
> changes can be made later.
>
> The veto is the backstop to make those future changes happen. Without it,
> no one believes ICANN will actually make the required changes. After all,
> people have been asking for a decade now and only very slight improvements
> have emerged as a result.
>
> The veto is there to make sure ICANN can't weasel out of change once it
> has IANA.
>
> It is also a test of good faith on the Board's part. Is the Board actually
> willing to be held accountable or will it try to argue its way out of
> giving the community any real additional powers?
>
>
> Kieren
>  On Mon, Jul 27, 2015 at 8:41 AM Dr Eberhard W Lisse <el at lisse.na> wrote:
>
>> George,
>>
>> though I agree about right vs quick, if it only were so that we
>> fundamentally redesigned ICANN.
>>
>> Which it needs.
>>
>> el
>>
>> --
>> Sent from Dr Lisse's iPad mini
>>
>> > On Jul 27, 2015, at 16:30, George Sadowsky <george.sadowsky at gmail.com>
>> wrote:
>> >
>> > All,
>> >
>> > These are my personal opinions.
>> >
>> > I suspect that the reaction to this post will be, "we are way past
>> this, we've discussed this, and now just help us work on the implementation
>> details."  If so, I think that's a mistake, because what I'd like to do is
>> question one of the fundamental assumptions behind what this group is doing.
>> >
>> > When this process started, there was general agreement that it was more
>> important to do this right than to do it quickly  Unfortunately, this
>> feeling appears to have reversed, with the current sense that it is more
>> important to get it done quickly in the name of the transition than to
>> spend the time needed to do it right.  This process is going beyond
>> accountability to a fundamental redesign of ICANN, with IMO inadequate
>> concern for assuring inclusivity of support as well as lack of concern for
>> unanticipated consequences.
>> >
>> > So here's what I'd like to contribute ...
>> >
>> > I've been uncomfortable with the notion of budgetary control/veto since
>> the idea was first presented.  I think that I now know why: in my opinion
>> it solves the wrong problem, and it is the wrong solution to the right
>> problem.  Let me explain.
>> >
>> > In general, budgetary control is exercised by groups who want to
>> control an aggregate budget, whether for reasons of limiting growth or
>> ensuring that aggregate expenses for a budget do not exceed some measure of
>> income.  I don't think that's the case here, although I suppose that under
>> exceptional circumstances it might be.
>> >
>> > The alternative is that the control the group appears to want must be
>> by program or even by line item, even though you're planning to use a very
>> blunt instrument  --  control over approval of the aggregate budget  --  as
>> your tool to accomplish this.  If that's the case, then what you really
>> want is programatic control, not budgetary control.  If the program is
>> accepted, then subject to resource constraints, it's up to the staff to
>> deliver, and any specific line item or similar objection, however
>> expressed, interferes with the execution of the activity.
>> >
>> > If the disagreement is with the program, with the objectives to be
>> accomplished, and how the objectives are to be accomplished, then that is
>> where the control should be exercised.  Any budgetary control after that is
>> micromanagement.  The response to that is if you don't trust the
>> organization to implement a rather well defined activity, then change the
>> management/staff, don't restrict their resources and let them continue
>> anyway.
>> >
>> > I suggest pursuing this line of argument further.  In my opinion, our
>> fundamental problem has two components: (1) a persistent inadequate level
>> of trust between groups within the ICANN community, and (2) our
>> inability/unwillingness to create and use structures to deal directly with
>> this situation and improve it.   I see the mechanism as starting with a
>> lack of trust   --  in Board, management, staff, as well as the ACs and the
>> SOs and their constituent parts  -- that generates not only suspicion
>> regarding motives, non-transparent actions, and actions that are not
>> equally favorable to all groups involved, but also the sense that the
>> process is not serving "me" (whoever I am) well and is therefore out of
>> control.
>> >
>> > In other words, IMO we have a fundamental problem of trust, and we
>> don't have an effective way to talk about it or to otherwise address it,
>> much less solve it.
>> >
>> > The budget rejection process that is being defined by the group is IMO
>> based more upon defining ultimate ("nuclear" if you like) confrontation
>> mechanisms than upon finding cooperative mechanisms to identify and resolve
>> potential conflicts at an earlier stage.  It does not address the trust
>> issue, and to the extent that my hypothesis is correct, if not addressed
>> the trust issue will continue to bedevil ICANN activities, in other
>> probably equally destructive ways.   Should not this group be equally or
>> more concerned about mechanisms to identify issues and encourage
>> cooperative-based and trust building processes to solve problems as they
>> arise?   It does not appear so to me.
>> >
>> > In summary, the current approach, gaining more control over budget
>> approval, is based upon a model of checks and balances, and that may be
>> legitimate to some extent.  However, I sense that is not the way in which
>> it is planned to be employed.  If so, it solves the wrong problem, nad it
>> does not address the real problem.   We need a different approach, one of
>> getting to the root of disagreements, real and perceived, that is early and
>> based upon increased cooperation and trust, and we need a way to
>> communicate that encourages this to happen.  This is not an easy problem to
>> solve, but IMO it's the real problem that we have to solve, rather than
>> some well meaning but inaccurate proxy representation of it.
>> >
>> > Please consider these thoughts in your discussions.
>> >
>> > George
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Accountability-Cross-Community mailing list
>> > Accountability-Cross-Community at icann.org
>> > https://mm.icann.org/mailman/listinfo/accountability-cross-community
>> _______________________________________________
>> Accountability-Cross-Community mailing list
>> Accountability-Cross-Community at icann.org
>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
>


-- 
Jordan Carter

Chief Executive
*InternetNZ*

+64-495-2118 (office) | +64-21-442-649 (mob)
Email: jordan at internetnz.net.nz
Skype: jordancarter

*A better world through a better Internet *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20150728/931f57a5/attachment.html>


More information about the Accountability-Cross-Community mailing list