[NCSG-PC] Fwd: [council] RrSG Feedback to GNSO PDP 3.0 discussion paper

Ayden Férdeline icann at ferdeline.com
Thu Aug 16 01:08:09 EEST 2018


The future of bottom-up, multistakeholder participation in ICANN activities is being questioned again.

> "The RrSG encourages the Council to consider team make up specific to each PDP, just as it does with drafting the scope, to ensure that the team make up is fit for purpose.  The RrSG believes the Council’s approach to the recent EPDP is a good example of considering the uniqueness of the issue and creating a suitable team model."

—Ayden

> Begin forwarded message:
>
> From: "Darcy Southwell" <darcy.southwell at endurance.com>
> Subject: [council] RrSG Feedback to GNSO PDP 3.0 discussion paper
>
> Date: 16 August 2018 at 00:03:34 CEST
> To: "GNSO Council List" <council at gnso.icann.org>
> Reply-To: "Darcy Southwell" <darcy.southwell at endurance.com>
>
> Council,
>
> Please see the comments below from the RrRSG regarding the GNSO PDP 3.0 discussion paper.
>
> Thank you,
> Darcy
>
> The Registrar Stakeholder Group appreciates the opportunity to comment on the GNSO PDP 3.0 document and offers the following:
>
> 4.1 Working Group Dynamics – Incremental Improvements
>
> #1. Terms of participation for WG members
>
> The RrSG supports outlining commitment expectations for WG members, so long as it doesn’t adversely impact the ability to coordinate volunteers and solicit appropriate representation for a PDP based on its charter and specified structure.  To ensure volunteers understand what will be asked of them, the RrSG suggests any call for volunteers include some basic commitments/expectations, such as:
>
> - anticipated duration of the PDP, meeting commitment (e.g., weekly meetings of 90 minutes) and expected  availability to attend [the majority of] meetings and devote sufficient time to prepare for meetings (e.g., require reading);
> - recommended expertise, if necessary, for the subject matter of the PDP;
> - knowledge of and respect for the GNSO policy development process; and
> - good faith commitment to working to build consensus.
>
> PDP participants should be appropriately trained on how to use ICANN’s remote meeting tools, including AdobeConnect, to ensure that PDP work is not disrupted due to user challenges with the technology.
>
> #2. Consider alternatives to open WG model
>
> The RrSG supports balanced representation when it comes to policy development.  However, a one-size-fits-all approach to PDP team structures is not appropriate.  The RrSG encourages the Council to consider team make up specific to each PDP, just as it does with drafting the scope, to ensure that the team make up is fit for purpose.  The RrSG believes the Council’s approach to the recent EPDP is a good example of considering the uniqueness of the issue and creating a suitable team model.
>
> #3. Limitations to joining of new members after a certain time
>
> The RrSG cautions the Council to remember that, at times, a PDP participant withdraws due to unforeseen circumstances (e.g., job change, medical issue, etc.).  Rather than prohibiting new members in such cases, an expectation should be made of replacement members to come up to speed on what has transpired, understand where consensus has been reached, etc., to avoid any delay in the PDP’s work or the rehashing of previously decided issues as a result of the new member’s concern.
>
> 4.2 WG Leadership – Incremental Improvements
>
> #4. Capture vs. Consensus Playbook
>
> The RrSG supports the idea of a “playbook” or expanded guidelines to assist WG leaders, but we are also concerned that there may be a more systemic issue.  Groups seem ever more willing to “lay down on the tracks” for almost any issue. The community as a whole needs to determine a way to replenish its “lake of goodwill” which appears in a severe drought.
>
> #5. Active role for and clear description of Council liaison to PDP WGs
>
> The RrSG supports the idea of the Council liaison having a more active role in PDP WGs, including the ability to actively be involved in leadership/preparatory meetings.
>
> #6. Document expectations for WG leaders that outlines role & responsibilities as well as minimum skills/expertise required
>
> No strong position here.
>
> 4.3 Complexity of Subject Matter – Incremental Improvements
>
> #7. Creation of Cooperative Teams
>
> Effective policy development requires participation from the PDP team members, especially active members responsible for responding to calls for consensus.  ICANN staff ensures that meetings are recorded with audio recordings and written transcripts available to participants. The RrSG strongly disagrees that any subset of members should be preparing summaries for “observers / less active” members to utilize in place of the recordings and transcripts.  That information is already available without interpretation by others that could alter the message.
>
> #8. PDP Plenary or Model PDP
>
> Since there are no limitations on observers in most PDPs, the RrSG has no objections to allowing individuals to observe to learn more about the subject matter.  However, given the demand already placed on PDP leadership and participants, it is an unnecessary burden to ask PDP leadership to hold plenary sessions specifically to educate newcomers on PDP subjects.
>
> Further, ICANN already offers a number of methods of education on the GNSO policy development process.  These tools are already available, and the RrSG questions the need for further resources to be developed in that arena.
>
> 4.4 Consensus Building – Incremental Improvements
>
> #9. Provide further guidance for sections 3.6 (Standard Methodology for decision making)
>
> The RrSG supports this improvement.  We would suggest that Council and staff meet with PDP leadership at the outset to discuss the consensus categories outlined in each PDP charter and acceptable methods for identifying consensus status.  We also suggest providing a basic training to PDP team members on the same.
>
> #10. Document positions at the outset
>
> The RrSG generally supports using surveys or other methods to try to find middle ground on issues in order to make the policy development process more efficient.  However, the RrSG is concerned that limitations on restating positions be carefully considered and outlined. It would undermine the policy development process to refuse to allow a participant to restate a position during a formal call for consensus when that participant’s knowledge and understanding of the full scope of the issue has changed, based on PDP discussions, since the initial survey on middle ground.
>
> 4.5 Role of Council as Manager of the PDP – Incremental Improvements
>
> #11. Enforce deadlines and ensure bite size pieces
>
> Adequate, narrow PDP scoping is critical to creating an attainable, realistic work plan.  The RrSG recommends that each PDP leadership team engage with Council in a PDP evaluation process following PDP completion.  Similar to #16 below, we recommend a standardized summary template be created to provide Council with data to indicate the effectiveness and efficiency the PDP had in achieving its work plan, meeting the scope of the PDP, etc.
>
> #12. Notification to Council of changes in work plan
>
> Not only is it important that PDP leadership communicate changes to the work plan and the rationale for such changes, but both the PDP leadership and the Council should be sure to consider the effect the change may have on the totality of the PDP and how do accommodate for the changes.  Continually extending a PDP because of work plan changes isn’t acceptable. Further, if work plan changes are necessitated by challenges with the PDP scope, the Council should consider whether the original scope was appropriate and, if not, review the scope for necessary changes in order to ensure the PDP accomplishes the necessary goal(s).
>
> #13. Review of Chair(s)
>
> The RrSG is concerned that an anonymous survey could easily be gamed or abused.  Instead of an anonymous survey, the RrSG suggests using the monthly reporting (comparing performance to the work plan) in #16 as a better means to ascertain if potential issues exist.  Council would then be able to speak with the PDP leadership to determine what has gone off track and why.
>
> #14. Make better use of existing flexibility in PDP to allow for data gathering, chartering and termination when it is clear that no consensus can be achieved.
>
> Data and metrics are vitally important and should be a stand-alone item, instead of being lumped with chartering and termination. The DMPM WG made the following observations in its Final Report, which seem still relevant today (see pages 12 & 13, https://gnso.icann.org/sites/default/files/filefield_48169/dmpm-final-09oct15-en.pdf):
>
> - Lacking baseline data hampers the understanding of problems which should be a primary rationale for making changes to policy. Therefore, ensuring relevant baseline data as one element guiding the policy process is critical and should be mandated by WGs.
> - ... ideally, data gathering and analysis should occur prior to and/or while scoping the issue with the policy development process to follow. Note however, at the working group phase, a group should not be limited in seeking further data and metrics should additional analysis be required, especially when new forms of data may become available.
> - When a WG makes recommendations, it should include a policy impact assessment, and recommend suitable metrics to measure the impact. Specifically, implementation of Consensus Policies should ensure post- implementation data is collected to analyze whether or not policy goals are achieved using defined metrics.
>
> The RrSG, however, also believes that it is important to ensure that WGs do not engage in data gathering exercises for the sake of gathering data.  Data gathering should not be used as a fishing expedition. We are concerned, for example, that some in the RPM PDP have used the “date gathering” requirement as an exercise to try to either 1) delay the progress or the group or 2) test hypotheses that have yet to have any supporting detail.  In other words, a data gathering exercise should not be used to test academic or philosophical theories, but rather should be used only where there is at least some evidence or reliable anecdotal data that support the notion of a more comprehensive data collection exercise.
>
> #15. Independent conflict resolution
>
> Possible implementation: ICANN org put out a call for expressions of interests seeking volunteer mediators to form a standing panel that could be called upon by PDP WGs if and when needed.
>
> #16. Criteria for PDP WG Updates
>
> The RrSG encourages the Council to set the parameters (e.g., timing, content) for PDP WG updates to ensure reporting provides the Council with the information needed to effectively management the policy development process.  For example, request monthly data that indicates:  (a) which issues contained in the scope are complete and which are not; (b) whether or not the PDP is on track to the work plan; (c) identify roadblocks causing the PDP to miss work plan deadlines; (d) identify resource concerns. Providing such regular reporting will allow the Council to more effectively manage policy development, evaluate timelines and issues, and  ensure overall policy work is efficient and effective.
>
> #17. Resource reporting for PDP WGs
>
> The RrSG understands that ICANN has not done any sort of resourcing data collection or analysis in the past, but that is expected from the EPDP.  The RrSG encourages such reporting and analysis. In order for the Council to effectively prioritize policy development work, one component it needs to understand is the resourcing efforts involved.
>
> Further general comments/suggestions:
>
> - The RrSG asks that Council consider the limitations of the PDP process, and its utility in making decisions, versus finding compromise.  The PDP excels at identifying issues, convening diverse stakeholders and perspectives, and conducting an analysis of potential solutions.  The PDP fails, however, when it is tasked with an either-or proposition, where the implications and views are known and well-established, and where the solutions are not suited for private contracts (unenforceable).  In these situations, the Council should prevent SGs and Cs from proposing or initiating PDPs, and instead look for other avenues to advance the work.
>
> - The RrSG encourages the Council to consider how to determine the right timing for policy development.  For example, at times policy development has begun while technical analysis may have been the more appropriate first step (e.g., IRTP-C (Change of Registrant), Across Field Validation (AFAV)).  We encourage the Council to consider what issues or information are necessary prior to policy development, and engage those avenues first to ensure policy development is as effective as possible.  In addition, there have been times when multiple PDPs are underway and competing for resources. Sometimes PDPs are working on similar issues but working separately and are, therefore, somewhat out of alignment. We encourage the Council to consider competing resources, timing, etc., to ensure that policy development is getting the attention it deserves, is adequately resourced, and is aligned with other ICANN community work to avoid duplication of efforts or competing results.
>
> __________
>
> Darcy Southwell | Compliance Officer
>
> M: +1 503-453-7305 │ Skype: darcy.enyeart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncsg.is/pipermail/ncsg-pc/attachments/20180815/fbfa062e/attachment.htm>


More information about the NCSG-PC mailing list