[At-review] Current state of Review and discussion documents fromManal & Fabio
Manal Ismail
manal at tra.gov.eg
Sat Apr 17 11:02:53 UTC 2010
Thanks Fabio for triggering the discussion on substance and for the rich document you have prepared ..
Thanks Cheryl for compiling and sending the latest updates ..
Following Cheryl's approach, I have added my comments to Fabio's document and am attaching below ..
Kind Regards
--Manal
-------------------------------------------------------
Review and discussion Doc#2
<text copy as at 1042 UTC 17th April 2010 showing comments>
Review team: initial reflections on various issues
(posted by Fabio Colasanti on 14 April 2010)
1. Objective/Terms of reference:
The AoC already provides the core of the team's "terms of reference" in paragraph 9.1 by describing the objective to which ICANN has committed ("to maintain and improve robust mechanisms for public input, accountability, and transparency so as to ensure that the outcomes of its decision-making will reflect the public interest and be accountable to all stakeholders") as well as the 5 sub-objectives. The AOC then states that "ICANN will organise a review of its execution of the above commitments". The contents of para. 9.1 therefore constitute the objective of the review team's activities and can be considered also the essential terms of reference. It is perhaps useful to consider whether any additional elaboration of the existing objectives is necessary or indeed appropriate.
<MI> I agree that the AoC should be our reference here.
One exception may be whether the team feels it is necessary to adopt a working definition of the terms "accountability", "transparency" and "public interest" since these terms are not defined in the AoC and different stakeholders are likely to have different views on what they should mean. To avoid frustration later in the process, it may better for the review team to adopt working definitions at the outset so to make the exercise transparent, rather than seek to initiate a lengthy (and ultimately inconclusive) search for "universally acceptable" definitions that could have consensus support from all parts of the community.
<CLO> I think it is essential for us to adopt working definitions of these terms at the outset. This matter (specifically the definition of "public interest') has indeed been raised in other ICANN fora.
<MI> I also fully support the suggestion to adopt working definitions of those terms. It's important that we all start from a common ground and share a common understanding of our scope of work which will be fine tuned by defining those terms.
2. Draft methodology:
The draft methodology produced by ICANN staff was a substantial piece of work, but the approach proposed is now likely to be too complex to implement in the short time available. The review team therefore needs to adopt a much simplified and "easily implementable" methodology that can be executed quickly and in the most transparent manner. This could include:
<MI> I agree. Drafting of how we are going to work should not delay the work itself. As mentioned, whatever we plan come up with should be short, simple and helps a quick start rather than a delay.
2.1 Consultation / evidence gathering
* ICANN staff should be asked to produce a report on how they have implemented earlier commitments to transparency and accountability which the review team can then subsequently assess. Staff could be asked to present their reflections to the first meeting of the review team in Marina Del Rey in early May. By identifying what assessments have already been carried out by ICANN to date, the review team can in particular then avoid duplicating review activities already carried out. A summary of the ICANN inputs at this stage should be made public and posted for public comment.
* This can be combined with a "general" public call for comments and proposed changes to ICANN's current practices and procedures with an initial deadline of, say, middle of June. The review team can then review this public input in their meeting in Brussels in late June.
* In parallel, each ICANN Supporting Organisation and Advisory committee should be invited to submit its own set of recommendations and/or observations through its representative(s) on the review team. This would have the advantage of making the whole ICANN community feel involved in the process and minimises the risk of the review team publishing findings/recommendations that are subsequently dismissed/rejected by the community. Such inputs could be discussed by the relevant bodies at the Brussels meeting and submitted to the review team shortly thereafter.
<CLO> I *strongly support* this approach... (reference here is to all three parts of the <FC> proposed methodology under 2.1)
<MI> I also fully support the suggested approach which takes into consideration input from ICANN, the community as well as SOs/ACs. I believe it's urgent, if agreed, that start communicating our request to ICANN staff in order to have a fruitful meeting in MdR. Moreover I also believe it is important that we come up with criteria or parameters we'll be looking at when evaluating the information gathered.
2.2 Deliverables / recommendations
* The drafting of recommendations by the team could then start in August/September with a view to posting draft proposals in October. Ideally, the proposals should be concise and concrete operationally. It is worth noting that the AoC only calls for the review team to produce recommendations, not a full report of its deliberations. Clearly, the team will need to demonstrate the rationale it has employed for any individual recommendation but focussing on recommendations (which should be no more than 2-3 pages in length) rather than on a lengthy report of proceedings should enable the team to save a lot of time and to concentrate its efforts on its core task.
<CLO> agreed and we may need to form ad-hoc Work Teams (WT's) to most effectively get initial drafting of our recommendations done. Our output must be clear, concise and be written to engage the wider community as part of a greater trust building exercise as well as being a specific measure of A&T in ICANN.
<MI> Agreed.
2.3 Organisation of the work of the Review Team
* The AoC states that "Resulting recommendations of the reviews will be provided to the Board and posted for public comment" without any indication of whether such recommendations should be endorsed unanimously by the team. While consensus should of course be sought, unanimity should not be required since this would effectively give the power of veto to each individual member. A better approach would be to seek consensus as a primary goal, but if members maintain different positions on any particular draft recommendation, to record the different positions[1]. This would also allow the team to avoid lengthy discussions on issues where there is no agreement - seek consensus but if it doesn't exist, record the different opinions and move on. (Thought needs to be given to whether the ex-officio member of the team - the Chairman of the Board - may need to recluse himself from having to endorse any proposals given that the recommendations will be submitted to the Board of which he is a member).
<CLO> agreed and this has become 'standard' practice in many ICANN WG's already and is enshrined in the draft guidelines for WG's currently being developed for GNSO WG use as part of their Improvement Implementation processes (I am part of one of those work teams (WT) perhaps we can distribute the current draft of this document for perusal by the AT-review members (let me know and I can arrange) even though it is still a work in progress... Certainly while we should aim for FULL consensus we should agree that divergence if view or minority reports are a good way to go forward when that can not be reached the points made regarding the Chairman of the Board are well taken and I'm sure there will be other times when depending on the topic on the table at the time various of our members may need to recluse ourselves and have that noted for the record.
<MI> Agreed.
* Prior to the first face-to-face meeting (but also through the process), team members should be encouraged to circulate their views on the various issues that need to be discussed. Once an issue has benefited from a first "tour" between members to gauge the level of interest and/or consensus, a volunteer can be sought to take responsibility for developing the exchange of views with a view to developing a recommendation. (It is important that developing recommendations remains the key operational objective since this is the main output expected of the review team in the AoC). Email exchanges are also useful for ensuring views are recorded fully and to ensure transparency between team members on their exchanges.
<CLO> agreed (along with use of whatever collaboration tools and archive methods we are comfortable with) email still tends to be a 1:1 dialog rather than a group discussion / interaction which can be offered by other methods even wiki's (which do not need to be public of course but can be used for redacted public version reporting of our activities if and when we deem that suitable.
<MI> Agreed.
* Physical meetings will be very important. Given the logistical difficulties in getting all members together (travel time, costs) such meetings, when they do take place, should be for at least 2-3 days. If the first meeting is in Marina del Rey to allow ICANN staff to make presentations to the team, only one day should be used for such purposes, with another 1- 1.5 days being available for team exchanges.
<CLO> I agree absolutely the concept of spending more time travelling to a meeting than at it does NOT impress me at all... We must make maximum use of the opportunities we have and of the resources committed to this work.. to that end I commented on the recent doodle for the Brussels F2F why were we not using any Sat time as options to ensure 2 or 2+day commitments... Re the MdR meeting if we can concentrate staff presentations in the beginning half+ of the first day (where we can act more like a panel {a good getting to know each other exercise any way} while Janis is absent then move onto the substantiative discussion and Agenda issues after that (including the admin issues) this might be the best use of the short time we actually have there... I also assume we could convene in after dinner sessions as well even if that is at the accommodation venue.
<MI> Agreed.
* Private meetings between team members will be very important if members are to be able to have frank and honest exchanges, and if members are to have the freedom to change their mind in the face of arguments made by others. Only having public meetings would risk limiting the possibilities for team members to engage in frank discussions. Members should also decide which sessions should be held under "Chatham House Rules"[2] - it will not be helpful to building confidence and trust between team members if all discussions are subsequently widely reported in the community. (The ICANN Board for example, and many ICANN SOs and ACs, also have some meetings in public and some in private to allow for open discussions).
<CLO> agreed and the ALAC has an everything is public other than in exceptional circumstances operating principal but with our interaction/ contribution opportunities (see AT-review Commons / Wiki information / reference later in this document) we are doing our best to engage our community publicly in a way they can feel their voice and contributions to the process is being heard and facilitated. My role is to ensure that we have a trust model that the community believes in both in these external to the AT-review team efforts and of course in our eventual methodologies. As Chair of the ALAC I am accountable to my At-Large and at-large communities, so hand on heart during and at the end of our work I must be able to say "we [the AT-review team] have had frank, full and fearless discussion of the issues of ICANN's A&T and about specific issues the community has desired to be raised in this predominantly closed fora.
<MI> Agreed.
* Participation: members could be assisted when necessary (e.g. for translation purposes) although the emphasis must remain on direct interaction between the named members. Assistants should not intervene themselves, nor should they be able to substitute for a member who is unable to participate. Remote participation possibilities should be provided in cases where a member is unable to travel.
<CLO> agreed
<MI> Agreed.
* To the greatest extent possible, the team members should seek to execute the above tasks between themselves, only taking advantage of staff support from ICANN on an ad hoc basis when necessary. This will minimise the burden on ICANN staff and ensure the perception of the independence of the review team.
<CLO> agreed
<MI> Agreed.
* External experts: none have been appointed to date. Given the short window available to team members, care needs to be given to avoiding spending too much time on additional procedures to access expert advice when it is required. In order for the team to maintain independence, it may also be necessary to avoid asking ICANN to identify an expert for any particular subject.
<CLO> for this initial AT-review, given the constraints we have I agree with this approach.
<MI> Agreed.
* Indicators: the ICANN staff paper on methodology highlighted how complex and onerous the collection of such indicators is likely to be. Moreover, the team members are not going to be in a position to collect any significant data themselves and instructing an external consultant on such a task is likely to be very resource intensive (drafting terms of reference etc). It is also arguable that the concepts of "accountability" and "transparency" do not lend themselves easily to quantitative analysis. Merely counting the number of documents ICANN has produced on any key subject for example is unlikely to be illuminating. A more logical approach would be to listen to concerns expressed by stakeholders and then for the team to determine to what extent such concerns are legitimate and how they might be addressed (i.e. by making a recommendation). Such an approach would not seem to require access to detailed "indicators" or other quantitative or qualitative methodologies for analytical purposes. Moreover, that data which is already available can be provided to the team by the ICANN staff in their presentation materials.
<CLO> I support our consideration of this all be it anecdotal material based but valid at this stage and considering the time constraints we have in my view, and would very much like to spend time at our F2F meeting discussing this issue in far greater detail (perhaps after the initial presentations by ICANN staff so we have a 'real' frame of reference) at the MdR meeting... However I do believe that some of the AC & SO's will have already accumulated some of this material OR (as is the case with the ALAC who has set up 'commons wiki space' for public at-large and ALS/RALO specific At-Large input into the AT-review process) we can access primary (and secondary) source information to complement and validate this proposed approach to 'data collection'... The pursuit of the more complex collection of empirical data methodologies should stay on our to look at agenda and may perhaps be a foundation of some further recommendations of useful metrics for intersession activity between the current and next AT-review process.
<MI> I agree that this is a practical approach that would help us jump start the evaluation process. I also feel the need to have our own set of criteria based on which we plan to evaluate the gathered information with respect to accountability, transparency and gathering of public input; otherwise we may be captured by the data received and address only concerns expressed by stakeholders who are already involved with ICANN without thinking of problems that may be facing stakeholders who might not be participating to ICANN yet.
2.4 Follow up ?
* The AOC states that ICANN shall "organise a review .....no less frequently than every three years". The review team may therefore wish to include among its recommendations an indication of when the next review should take place. Should, for example, the current team be reconvened one year later to review progress on the implementation of its recommendations?
<CLO> clearly we need to discuss this fully as there are resource considerations to take into account, but it is my view that the first follow up / repeat review after this initial work should be set and recommended to be at the earliest optimal yet practical time after completion of this first AT-review work is completed. 12 months out is likely to be a very suitable point in time for this first subsequent follow up.
<MI> Agreed. Also if time allows I believe it would be useful to provide some recommendations and lessons learned, constraints to our work, mistakes that could be avoided in future reviews as well as hopefully highlights of our positive experience too (again as so far agreed, no too much drafting, no long documents, all concise and to the point).
page 4 of 4
________________________________
[1] The GAC's operating principles offer a precedent in this respect: principle 47: "The GAC shall work to achieve consensus; however, where consensus is not possible, the Chair shall convey the full range of view expressed by Members to the ICANN Board".
[2] "When a meeting, or part thereof, is held under the Chatham House Rule, participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed". This rule was developed by the UK "Royal Institute of International Affairs" (whose home is at Chatham House in London) "with the aim of providing anonymity to speakers and to encourage openness and the sharing of information. It is now used throughout the world as an aid to free discussion. Meetings do not have to take place at Chatham House, or be organized by Chatham House, to be held under the Rule".
See http://www.chathamhouse.org.uk/about/chathamhouserule/ for more information.
<end text copy as at 1042 UTC 17th April 2010>
More information about the AT-Review
mailing list