ICANN/GNSO GNSO Email List Archives

[council]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [council] Managing the run-up to ICANN meetings


Stéphane,
thanks for sharing your thoughts and also for the article that contains various 
points that help stimulate a discussion.
 
I guess this is not off topic, but most relevant - at least I am suffering from 
the bulk of information. 

There is a risk of the quality of our work being affected by this and factors 
such as this do not make it particularly attractive for members of the 
community to participate. 
Also, the reputation of the organisation as such may suffer when the outside 
world considers it unlikely that decision-makers are fully aware of all 
information that is the basis for a discussion. 

If there is time for us to discuss this f2f in Prague, we should do that. You 
say that ICANN does not properly manage the release of documents. But, who is 
ICANN - aren't we part of the problem if we do not come up with constructive 
proposals as a community how things can be improved?

Best,
Thomas



Am 06.06.2012 um 12:24 schrieb Stéphane Van Gelder:

> 
> Hi all,
> 
> In the interest of full transparency, I wanted to inform you of a Circle ID 
> article that I wrote: 
> http://www.circleid.com/posts/20120605_icann_gets_crazy_again/
> 
> You've heard me speak of the potential for volunteer burn-out many times in 
> the past. You've also heard me moan about the lack of pre-planning on 
> document roll out by ICANN. This post is also voicing my opinion that the 
> current trend is making it difficult for volunteer bodies like ours to 
> adequately look at all issues when making policy.
> 
> In actual fact, my main worry is with the Board. I am told that they get 
> about 3 times the volume of documents to read in the run-up to ICANN meetings 
> that we as community members get. So does that mean we're asking Board 
> members to get to grips with so much reports and briefings and documents, and 
> then expecting them to make quality decisions? If that's the case, I think we 
> are asking too much of them.
> 
> I note with interest a couple of the comments posted in response to this 
> article. Avri's comments, for example, rightly point out that some of these 
> reports do not require us to read every single page. However, I do think that 
> is an insider's POV, and one that is deeply involved with ICANN like Avri is 
> and has her depth of knowledge of the issues. I would wager that with so much 
> going on, most of us need to read a full report just to remind ourselves of 
> the subject matter's past history.
> 
> I was also interested to read Kieren's comments, because I think he hits the 
> nail on the head when he says that because there is a 15-day deadline for 
> document publication, everything tends to come out on that deadline. I agree 
> with him that if we are able to plan ahead more and better pre-plan, we would 
> not end up with more than 700 pages of reading to do before we all congregate 
> for what remains the most important item on the ICANN yearly calendar: the 
> ICANN meeting. After all, it is in these face-to-face meetings that a lot of 
> the crucial ICANN decisions get shaped, if not taken, so it is important that 
> they are based on people having had sufficient time to take in and digest the 
> documents that provide the context for them.
> 
> I hope you do not feel this email is off topic. I think this is at the heart 
> of what we do at ICANN, which is to constantly strive to do the best we can 
> when weighing the issues that we deal with at ICANN.
> 
> I would love to hear your views on this, not just as a Council, but also as 
> individual ICANN volunteers who all have to face the same problems that are 
> being described here: that of what bandwidth you have available to deal with 
> ICANN-related stuff in a way which you feel does credit to the organization 
> and what it is tasked with doing.
> 
> Thanks,
> 
> Stéphane Van Gelder
> Directeur Général / General manager
> INDOM Group NBT France
> ----------------
> Head of Domain Operations
> Group NBT
> 
> 





<<< Chronological Index >>>    <<< Thread Index >>>