<div dir="ltr">hi Robin, Greg<div><br>Thanks for starting this thread.</div><div><br></div><div>It is really important in my mind to separate approval processes and rejection processes. </div><div><br></div><div>Approval is part of bringing a piece of work to its conclusion, forms a normal part of the process, and in respect of budgets and strategies is normally what a Board does - and sometimes is part of what members do (e.g. in my own InternetNZ incorporated society, the council (board) signs off the Budget and we operate to it, but it is subject to ratification at the AGM. Nobody has ever tested what would happen if the AGM didn't reject it...)</div><div><br></div><div>Rejection is something that happens after a piece of work is done, forms an extraordinary part of the process, and is generally what a board or governing body does *to* a piece of work from management in my experience.</div><div><br></div><div>The power we have scoped up here would be part of a suite, because of other WS2 discussions that we do need to improve the planning and budgeting process. But I do feel it is preferable in the context of how ICANN operates, based on what I know at this stage, to keep this as a rejection approach - as it has been from the start, and as the WP1 has largely seemed happy with.</div><div><br></div><div>Basically, I think that:</div><div><br></div><div>- we need to improve the budget and planning process so that there are obligations on ICANN to seek and incorporate community views -- but that doing so is a Workstream 2 issue (post-transition)</div><div><br></div><div>- to protect the Board's role as the governing body, and avoid interfering with the fiduciary responsibilities of the Board, we are best to maintain the community power we are talking about here as a veto/send back/reconsideration-and-pause <b>after </b>the relevant document is approved.</div><div><br></div><div>- this after-the-fact process is preferable to a co-approval on such a mundane matter, which would be over the top (we have only proposed co-approval for allowing changes to the fundamental bylaws, so far).</div><div><br></div><div>- this after-the-fact process it is far preferable to taking the right to approve these matters away from the Board and giving it to the community. Such a move would fundamentally call into question the Board's role.</div><div><br></div><div>- we do not want to force the community to decisions on matters that they shouldn't need to make decisions on - with input processes sorted out, the prospect of veto after the fact is the accountability constraint that helps make sure the Board does what the community wants in respect of these documents. If we're just part of the approvals stage, I can't see why we would not want to do this as well, as the absence of this but part of approving doens't really solve the problem of a final decision being made by the Board - it just takes us back to having to roll the Board if they don't "get" it.</div><div><br></div><div><br></div><div>That's my thinking at this stage. </div><div class="gmail_extra"><br></div><div class="gmail_extra">cheers</div><div class="gmail_extra">Jordan</div><div class="gmail_extra"><br><div class="gmail_quote">On 16 April 2015 at 14:19, Greg Shatan <span dir="ltr"><<a href="mailto:gregshatanipc@gmail.com" target="_blank">gregshatanipc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:verdana,sans-serif">This is an interesting thought. The Draft FY16 Operating Plan & Budget is out for public comment right now. <a href="https://www.icann.org/public-comments/op-budget-fy16-2015-03-18-en" target="_blank">https://www.icann.org/public-comments/op-budget-fy16-2015-03-18-en</a> So, it's not like there's no place for community input into the Budget; it just doesn't come with much leverage attached. Perhaps this could be amplified into an <u>approval</u> right by the SO/ACs on behalf of the community. Approval <i>after </i>the board decides (or a veto after the board decides) are inherently troublesome because it takes the "last word" away from the board. In a membership structure, it's natural for the members to have the last word. (In a designator structure, it's kind of unnatural.) Approval <i>before </i>the board decides doesn't cause the same kind of governance "heartburn."</div><span class="HOEnZb"><font color="#888888"><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif">Greg</div><h1 style="font-weight:300;font-size:1.6rem;margin:0.67em 0px 0px;font-family:Lato,Helvetica,Arial,sans-serif;color:black"><br></h1></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 15, 2015 at 8:31 PM, Robin Gross <span dir="ltr"><<a href="mailto:robin@ipjustice.org" target="_blank">robin@ipjustice.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Jordan, Greg,<div><br></div><div>I've been thinking about our discussions today on clarifying what type of community right we are looking for with respect to the ultimate adoption of budget and strat plan and I'm wondering if there is a much easier fix than we thought. We talked about creating this right as right approval for the community <b><u>after</u></b> the board makes its decision, but I wonder if we are thinking about the ideal process backwards. The budget and strat plan that should be presented to a board vote for ultimate approval should be one that the community has <b><u>already</u></b> approved of. Like how the GNSO policy is made: what gets put before the board for approval and adoption is something that the community already signed-off on before it gets to the board for final approval. It might be just terminology - misusing words like "veto" or "reconsideration" or "rejection" - when what we are ultimately seeking is an approval right on these issues. Might this clarification of language and what we are ultimately seeking be helpful to designing it into the bylaws?</div><div><br></div><div>Thanks,</div><div>Robin</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Jordan Carter<br><br>Chief Executive <br><b>InternetNZ</b><br><br>04 495 2118 (office) | +64 21 442 649 (mob)<br><a href="mailto:jordan@internetnz.net.nz" target="_blank">jordan@internetnz.net.nz</a> <br>Skype: jordancarter<br><br><i>A better world through a better Internet </i><br><br></div></div></div></div>
</div></div>