FINAL VERSION SUBMITTED (IF RATIFIED)
The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote.
FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC
The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.
DRAFT SUBMITTED FOR DISCUSSION
The first draft submitted will be placed here before the call for comments begins. The Draft should be preceded by the name of the person submitting the draft and the date/time. If, during the discussion, the draft is revised, the older version(S) should be left in place and the new version along with a header line identifying the drafter and date/time should be placed above the older version(s), separated by a Horizontal Rule (available + Insert More Content control).
Submitted by Alan Greenberg on 02 October 2018 at 02:00 UTC
The ALAC appreciated the opportunity to comment on the next steps on Reviews
ATRT3 - Proposed Path Forward: Commence ATRT3 to start its substantive work in January 2019. To achieve this target, the Board would ask for the community to reconfirm their review team nominees and for the SO/AC chairs to appoint the review team by 30 November 2018.
The ALAC supports the proposal.
Specific Reviews - Proposed Path Forward: ATRT3 to consider undertaking a discussion on how to streamline Specific Reviews to make them more effective and impactful. ATRT3 could explore relevant input from: ICANN community (public comments on Long-term options and additional consultations), ICANN organization via observed best practices and opportunities for efficiencies from specific reviews conducted in the past year, and ICANN Board, via observations from OEC.
ATRT3 discussions, guidance and potentially recommendations would inform next steps.
The ALAC considers this a low priority item for ATRT3. Based on recent experience, the reviews have largely worked well. What has not worked as well is the ICANN Org implementation which seems to focus far more on ticking off boxes than on addressing the intent of the recommendations.
Organizational Reviews - Proposed Path Forward: Begin an effort to formulate a shared understanding of the purpose of Organizational Reviews and their expected outcomes - within the ICANN community, Board and ICANN organization. Identify potential options to accomplish the agreed upon purpose and expectations, with an eye toward improved efficiency and effectiveness. The goal would be to achieve a balanced outcome, resulting in an effective process with support from the community, while preserving transparent and consistent means of assessing SO/AC accountability to their stakeholders and a means of implementing meaningful improvements. The Board, through the OEC, would provide guidance and direction on the possible solutions, and community consultation would also take place.
The ALAC supports the proposal but with caution. We need not just change, but effective change. The Organizational Review process has been a HUGELY expensive (both financial and volunteer effort; both the review process proper and their implementations). It is not at all obvious that any benefits have come near to being commensurate with the efforts.
This cannot be a Board and/or ICANN Org effort “with consultation”. There needs to be active community participation in formulating any recommendations.
Specific Reviews Operating Standards - Proposed Path Forward: Rooted in practical experience over the past year with two post-transition-initiated reviews, ICANN organization will incorporate proposals based on significant lessons learned and include operational process improvements implemented within the past year. The next draft Operating Standards will be responsive to community concerns about selection of RT members, scope setting and monitoring progress of review teams with clear definition of escalation procedures, among others.
The ALAC supports this, but it must be done with GREAT CARE.
Institutionalizing things which have only had limited application can lead to unintended results. As an example, the first version of the Operating Standards went into excruciating detail where it was not warranted. It specified that all RTs must have Co-Chairs, because Co-Chairs were in vogue and were successful for the CWG-Stewardship Transition and the CCWG-Accountability. The RDS-WHOIS2-RT and now the reformed SSR2-RT decided that a Chair and Vice-Chairs made more sense.
As a second example, the first version of the Operating Standards specified a very cumbersome (in time and community effort) to define the scope of a review because of the PERCEIVED problem in one recent review. And it is far from clear whether that perception was even accurate.
As a third example (provided by the Chair of the RDS-WHOIS2-RT) the forced DETAILED planning has helped the RDS-WHOIS-Review develop and (roughly) keep to its schedule. But it only worked because the review team leadership was willing to consciously make specific changes even though it had committed to other timelines in its Terms of Reference. Agility, here, as in modern programming, is essential. On the other hand, adoption of report standards and careful adherence to then, has led to a bloated and largely inflated Draft Report.
Operating Standards should take a minimalist approach.
