[Internal-cg] How to define consensus in ICG?

[Adiel Akplogan]

On Jul 25, 2014, at 10:29 AM, Patrik Fältström <paf at frobbit.se> wrote:

> I am concerned we have issues here and I would like to propose the following as a boot strap mechanism to be able to move forward.
> 
> First, this proposal is based on upon the fact we do have one and only one chair. We could <snip>…

> Second, it is also based upon the fact that although we are representing and to some degree liaisons between ICG and whatever community that appointed us, we are all as individuals collectively responsible for ensuring ICG do deliver whatever we are to deliver. As such we as individual must be able to use the trust we have had to make some decisions without going back to our respective consensus processes for every single decision. If nothing else it is important to *now* go back to understand where the red lines are, and what we are allowed to make decisions on and not without explicitly going back.

This above is critical in my sense for the smooth operation of the ICG. It is important that we work as a group that has a collective responsibility instead of being primarily liaison to our respective groups on each and every decision! The group and it chair(s) must be able to take consensual decision within the ICG. Time when consultation with community is needed must be clearly defined and agreed on. I will suggest that it happens when we open our decision for public comments so all community have an equal ability to comment. We will have an issue when we allow one community to have a consultation and direct input on a particular discussion/issue where the other did not have the formal opportunity to do so. 

> With these basis, I suggest the following.
> 
> We have two different kinds of issues to decide upon:
> 
> A. The non-substantial issues that might has to do with how we work, what tools and processes we use to reach certain goals and what not.
> 
> B. The substantial issues that none of us can say anything about without ensuring some consensus process has come to some conclusion.

Ok with me to go with these two categories.

> Of course there is a large gray area between A and B. But my point is that we do have a large set of issues that are of type A. And personally, I think some of the issues we have today not been able to reach consensus on are of type A. I.e. we SHOULD as individuals given we are appointed be able to reach consensus.

+1

> 1. How to reach consensus on issues of type A
> 
> Issues of type A are by the chair announced to this mailing list. The proposals and choices are clearly defined. The chair give a deadline at which point choices should have been filed. The chair can decide wether choices should be sent to the list, to the chair personally or whether some online poll should be used. In all cases the result of the poll, including who have what input, should be presented to this list. The minimum time between the call from the chair and close of the poll is "one business day". Normal time should be "three business days". Business day is Mon-Fri minus travel days, holidays etc...but ultimately we trust our chair to make the right decision here. Possible responses can part from selection of choice, whether one agree or not, be to call this not to be of category A, but instead category B and that way ask for extended evaluation. Non-responses is to be treated as "not against the proposal", but should in the summary be reported as a separate category. At the end of the poll, the chair draw conclusions, and present the consensus based conclusion to this list. 
> 
> Summary: Chair clearly let on this list know what issue there is, and ask for feedback no later than a certain point in time. Non-responses are to be treated as "not against". Shortest time for the feedback one day. Chair draw and present conclusions.

Workable for me.

> 2. How to reach consensus on issues of type B
> 
> Issues of type B are by the chair announced to this mailing list. Substantive matters must be backed by arguments based on the result from the consensus based processes in the respective communities. I.e. it is for these matters not ourselves as individuals that makes the call, but we are coordinating and summarizing what the communities do think about a specific issues. ICG as a whole is also to write explicit reasons for various conclusions, specifically when the consensus is not a unanimous conclusion, or when feedback is completely missing from a certain category of communities.
> 
> Exactly how to reach consensus on these matters, and how to do the coordination, outreach, repeated outreach when we have lack of information, are things we probably have to invent more or less on the fly when we move forward, but I do hope that all of these calls are decisions on type A.

Agree.

- a.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 313 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140725/8a8ec4e3/signature.asc>