2019-05-13 PDP3.0

Notes/ Action Items

ACTION ITEMS

For Small Team:

• Small Team to continue providing comment/input to Improvement #2 and #11 via SLACK channels.
• In particular for #2, Small Team to develop language for the different attributes (e.g., membership, leadership, etc.) to help guide the decision-making process for choosing different options for working groups

For Staff:

• For Improvement #11, Staff to create a next version of the overall project list by removing the “activity” section and including a “risk mitigation” section, a change log, an ownership proposal for designating the “status/condition”, and other additional revisions. Staff should also consider developing an instruction/FAQ document to accompany the prototype/template.

• For Improvement #2, Staff to synthesize the list of working group models, pare down to 2-3 variations (e.g., open WG model, representative model), and create a menu of options for mix and match (e.g., options for selecting the working group chair).

NOTES

2. Improvement #11

• Main components of the Fact Sheet have been inherited from the IANA Stewardship Transition CWG. The EPDP Phase 1 also used the Fact Sheet because it had resource/fund allocated; the Fact Sheet will be used again in EPDP Phase 2. The Fact Sheet focuses on the financial component of the project. Some enhancements have been made to the prototype in order to address Improvement #11.
• Five questions for the group to consider (bolded questions were focused on during the call):
1. Not all projects on the projects list will look as complete as the prototype. For example projects not yet started but in the pipeline will have very little content and almost an empty shell.  Do we create a “thin version” vs. the “thick” version of the prototype?
2. What do we want to do about priority, if anything?  I’ve not yet included a priority field in the prototype, but there has been lots of discussion in the community about priority of projects.  We know we’re running well above 100% capacity. Do priority assignments help to park new or lesser priority projects until bandwidth is freed? 
3. How do we handle projects that become owned by GDD during Implementation (stage 7)?  While the GNSO needs to be informed about the implementation of projects, Policy does not own the delivery.  Is it worth keeping this same design, or would it be better to link to a set of status reports maintained by GDD outside of the projects list?
4. Who should own project status designation and/or input into a designation change (Staff, WG Leadership, Liaison, or all)?  How does this compliment a PCR (Project Change Request) of a WG when they can’t deliver to the agreed date?
5. Do we somehow integrate Council Action Items better into the project list?https://community.icann.org/display/gnsocouncilmeetings/Action+Items
• A “thin” version of the milestone/workplan can be developed as the steps/phases in GNSO projects are generally consistent on a high level.
• There are six possible indicators for status, and they are differentiated by colors. Who are the primary owners for the status components?
• It would be most helpful if the project end date does not change much.
• The assigned support staff to the WG should work with the WG leadership to update the Fact Sheet.
• The “Project Change Request (PCR)” should be formalized. It can affect deliverables, additional issues, and timeline. Leadership should be invited to join the Council call and explain why they submit a PCR.
• The designation of status/condition should be done collaboratively between the Council liaison, WG leadership, and assigned staff member(s) to the WG, but the overhead should be kept low.
• If there is no agreement between the liaison the WG leadership regarding the status/condition, the liaison should speak with the Council about the disagreement.
• There is a need to create a change log for the status/condition, perhaps in a separate document.
• The high-level milestone/task table does not provide enough details to reflect the work between the milestones. It is up to the WG leadership to manage those “sub milestones” and continued deliberations.

ACTION ITEM: Staff to create a next version of the overall project list by removing the “activity” section, including a “risk mitigation” section, a change log, an ownership proposal for designating the “status/condition”, and other additional revisions. Staff should also consider developing an instruction/FAQ document to accompany the prototype/template.

ACTION ITEM: Small Team to continue providing comments/input via the SLACK channel.

3. Improvement #2

• During SPS, staff have compiled a complete list of WG models being used over years, and the list has been updated incorporating feedback from the Small Team.
• Small Team will need to develop criteria and relevant questions for the Council to help clarify what type/model of the WG would be best suited for the policy development purpose. There may be need to develop a check-list/decision tree to facilitate the decision making process.
• The reference to the working group should be consistent – e.g., PDP Team, PDP WG, or PDP WG/Team.
• Some group that carry out ad-hoc work (e.g., drafting team, small team, etc.) may not have charters but they are not concerned by Improvement #2. It may be helpful to include a “special features” section to include information on those “non-standard” working groups.
• If the Small Team believes some models in the list are not suitable for policy work, they should be discussed, clarified, and/or removed from the list.
• According to the GNSO Operating Procedures, the GNSO Council may form a working group, task force, committee of the whole or drafting team (the “PDP Team”), to perform the PDP activities. The preferred model for the PDP Team is the Working Group model due to the availability of specific Working Group rules and procedures that are included in the GNSO Operating Rules and Procedures. The GNSO Council should not select another model for conducting PDPs unless the GNSO Council first identifies the specific rules and procedures to guide the PDP Team’s deliberations which should at a minimum include those set forth in the ICANN Bylaws and PDP Manual.

ACTION ITEM: Staff to synthesize the list of working group models, pare down to 2-3 variations (e.g., open WG model, representative model), and create a menu of options for mix and match (e.g., options for selecting the working group chair).

ACTION ITEM: Small Team to develop language for the different attributes (e.g., membership, leadership, etc.) to help guide the decision-making process for choosing different options for working groups. Small Team to continue the discussion in the SLACK channel.