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

Wed Jul 29 06:01:09 UTC 2015

Chris: you are right and Seun is wrong. We are not setting up mini-quorums
or mini-vetoes by creating individual thresholds within participating SOs
or ACs.

best
Jordan

On 29 July 2015 at 17:48, Chris Disspain <ceo at auda.org.au> wrote:

> SO: My understanding was that the 75% is from each SO/AC(i.e ~4 out of 5
> votes of each SO/ALAC) and not from total votes casted
>
> A good point and if I have misunderstood then I apologise. Could someone
> clarify please?
>
>
>
> Cheers,
>
>
> Chris
>
> On 29 Jul 2015, at 15:45 , Seun Ojedeji <seun.ojedeji at gmail.com> wrote:
>
> On 29 Jul 2015 5:51 am, "Chris Disspain" <ceo at auda.org.au> wrote:.
> >
> > Let’s assume that the single member has a total of 20 votes (5 each for
> ASO, ccNSO, GNSO and ALAC) and that the threshold for the veto is 75%. That
> means that 15 votes are required.
> >
> SO: My understanding was that the 75% is from each SO/AC(i.e ~4 out of 5
> votes of each SO/ALAC) and not from total votes casted
>
> > Let’s assume that ALAC asks for an allocation of $2,000,000 to run an At
> Large Summit. At the moment, that is an extraordinary item (i.e. it is not
> automatically budgeted for each year or each X years) and the process of
> approval involves, in essence, the Board approving it. Under the veto
> provision, it would be possible for the ASO, ccNSO and GNSO to vote against
> the budget because of that line item.
> >
> > Equally, the ALAC, ccNSO and ASO could vote against a gTLD industry
> summit line item or a non-commercial users meeting cost. And, entirely the
> reverse could happen with SOs and ACs 'horse-trading' with each other so
> that they each get their (to quote you) needs, concerns, demands,
> objections met.
> >
> > Is this really what we want to set up?
> >
> SO: If my understanding of the 75% above is incorrect then I agree as
> well; it's definitely not a setup to uphold.
>
> Regards
>
> >
> > Cheers,
> >
> >
> > Chris
> >
> >
> >> On 29 Jul 2015, at 03:02 , Greg Shatan <gregshatanipc at gmail.com> wrote:
> >>
> >> I don't think the budget veto was ever intended to substitute for
> community participation in the budget process, rather it was intended to
> encourage it (in a sort of dark and foreboding way).  There are already a
> number of ways in which the community in general, and SOs and ACs (and
> their component parts) participate in the budget process, and these have
> been improving over time.  I'm not going to catalogue them here, but I
> should think it's readily available on the website or from Xavier Calvez's
> team.  These should continue to be improved.  One continuing shortcoming is
> that we are all still supplicants, beseeching ICANN finance for a little
> more pie.  While this is true in private (and public) entities as well, the
> level of influence of the community is probably lower than it should be.
> As it is now, the community can register all of its needs, concerns,
> demands, objections, etc., and in the end there is nothing to make those
> anything more than "kind requests."
> >>
> >> The budget veto is a final backstop in the event of a budget that
> fundamentally is at odds with where it should be.  The budget veto should
> not be viewed primarily as a power, as much as an admonishment, to add
> discipline the budget process.  It should constrain the Board from
> delivering a "veto-able" budget.  The best way to avoid that, of course, is
> communication with and due consideration of the need of the community
> throughout the process.
> >>
> >> One other note -- there seems to be a misunderstanding of what a
> "non-profit corporation" (and why it is called "non-profit").  A
> "for-profit" corporation pays out net profits to its owners (shareholders
> or other types of owners).  A non-profit does not have owners or
> shareholders, so it does not pay out profits to anybody.  While an entity
> can be " non-profit," this does not mean it is "non-surplus." "Non-profit"
> does not mean that it is not supposed to run an excess of revenues over
> expenses, or have no more assets than it has liabilities.  So, this idea of
> "balance" is misplaced.  A non-profit, like a for-profit, needs to balance
> its books in an accounting sense, but that does not in any way mean that
> there is a prohibition or even a presumption against having a surplus of
> cash over expenses.  There may be a point when sitting on a pile of cash is
> not consistent with the entity's goals, but that can also be true of a
> for-profit corporation.  It's entirely fair to talk about the numbers, but
> we should be careful not to bring in presumptions that don't exist.
>  [Caveat: I'm not referring to charitable organizations, which are often
> referred to as non-profits as well.]
> >>
> >> Greg
> >>
> >> On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <
> crg at isoc-cr.org> wrote:
> >>>
> >>> Dear George,
> >>>
> >>> I agree with you that a cumulated budget veto is a pretty useless
> accountability tool (independently of how difficult it would be for the
> sole member to exercise it…)
> >>>
> >>> Moreover, I think the community on the one hand should take care that
> the public interest objectives (policy development and compliance
> functions) are properly funded. It would be much more effective if those
> separate hose budgets (policy development and compliance functions) would
> be developed in a bottom up fashion, based on the needs of the community,
> and through the communities direct involvement. No need for a veto then
> since the SOs/ACs would be DIRECTLY responsible for their budgets.
> >>>
> >>> On the other hand, it is up to management to guarantee the financial
> BALANCE  of the day to day operations (yes, balance because ICANN purpose
> is non for profit), as well as guarantee the demands of the community for
> proper funding of the public interest functions (independently of the line
> overseer of the functions, which is another black box altogether).
> >>>
> >>> This would be in my view a much more effective system of so called
> “checks and balances”  than an absolute veto over the cumulated budget,
> where the community has little knowledge on the different objectives under
> it was produced, and remains in my eyes will very obscure, independently of
> the overall sum in relation to the size of the business.
> >>>
> >>> Best
> >>>
> >>>
> >>> Carlos Raúl Gutiérrez
> >>> _____________________
> >>>
> >>> email: crg at isoc-cr.org
> >>> Skype: carlos.raulg
> >>> +506 8837 7173 (cel)
> >>> +506 4000 2000 (home)
> >>> +506 2290 3678 (fax)
> >>> _____________________
> >>> Apartado 1571-1000
> >>> San Jose, COSTA RICA
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> On Jul 27, 2015, at 9:30 AM, 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
> >
> >
> >
> > _______________________________________________
> > 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/20150729/f4692146/attachment.html>