[Internal-cg] How to define consensus in ICG?
Mohamed El Bashir
mbashir at mbash.net
Sat Jul 26 09:30:14 UTC 2014
+ Patric, for summarizing the issue and putting a way forward.
Agree to (a) and (b)
On Fri, Jul 25, 2014 at 7:54 PM, Milton L Mueller <mueller at syr.edu> wrote:
> Agree strongly with Adiel and Patrik on this point. We should not have to
> go back to our constituencies for every single little "type A" issue as
> Patrik described them. We cannot work efficiently in that way. On
> substantive issues, there should be consultations, especially on
> controversial and high-stakes issues, but most of us have been selected for
> this committee by our groups because they have confidence in our judgment.
> -----Original Message-----
> > 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. 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 cate
> gory. 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
> > 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.
> - a.
> Internal-cg mailing list
> Internal-cg at icann.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Internal-cg