IDNs EPDP Charter Drafting Team
Who can see your viewing activity?
Nathalie Peregrine - ICANN Org
Please review ICANN Expected Standards of Behavior here: https://www.icann.org/resources/pages/expected-standards-2016-06-28-en.
WG should create it
not we are
how do we deal with the synchronization with operation stream?
hmm but we wont put out a partial report?
I am not sure the partial report is possible
Working Groups generally do 1 Initial Report and 1 Final Report on all of the topics. But, there is nothing preventing Working Groups from being more Agile and taking this in pieces (if possible)
For example, could the WG do an initial report on only the narrow issue of evaluators determining whether an application for a TLD is confusingly similar to an existing TLD or to another application due to the fact that they are variants?
Section 2 has been revised along the way of the meeting
Staff have noted in the agenda email to note what questions have been revised
I do not think we can add "please add here something" as part of the plan :)
the deliveries are all or nothing, we can not issue deliveries in bits
The whole notion of Agile Project Management is taking things in bite size pieces
even if prioritisation is necessary, shouldn't we leave that to the working group to decide?
as a part of my job I have to mend things cause by the agile approach
bite size pieces is about the task and not about endless deliveries
there is no more than one final report in the design
I do not support the idea of multiple final reports
@Dennis, we could be
Its what we did for transfers way back when. We broke it down into phases. But in this case, it would be the Working Group itself that decides the phases
the final report can consist out of different bits , but delivered at the same time
PDP 3.0 is about improving the PDP process and trying to gain more efficiencies.
I think we should say - they should create plan e. t. c.
That's the biggest lesson for me with SubPro
pdp 3.0 is not for WG members trying pilot projects
@Maxim, that’s right
FYI, the Transfer Policy is intended to operate in two phases. I believe the IDNs EPDP could determine that its work is better conducted in phases and build that into its work plan. The work plan goes to Council for review and acknowledgment, so they would have an opportunity to object.
Thanks Steve. This is useful
And the GNSO Council liaison could communicate that the EPDP might be thinking of going that direction in advance, to keep the Council more informed.
We can try this option
I would change the "shall" to a "may"
This is not a legally binding document
or you can say "are expected to"
it was more like a set of ideas
I have made that language revision
Nathalie Peregrine - ICANN Org
Reminder to state your name before speaking for recording and transcription purposes, thank you!
we should not confuse some flexibility with unlimited pilot
We don't have a change history, do we?
Change history is not needed at the point
Change history is needed when the Council decides to update the already approved charter
I tend to agree…. some repetition (i.e stressing importance) might be good, and a quick way to find the resources
Maybe we should also add the Scoping Team final report, as it includes additional links of reference documents in its annex
Does the DT want to specify how many Staff Liaisons should be involved?
In other words, trying to close out some issues
Also the number of liaisons
GNSO council appointments the liaison, not WG
@Maxim - my point is not who selects, but the fact that this charter contains a provision to have one.
I am just not clear as to why this section is a TBD?
at least one might sound better
I am fine with Maxim's language
reasonable number :) like not 6
you need the word "appoint" back in there
We will resolve the comments and redlines for the sections that have already been reviewed by the DT
So the charter doc will look much cleaner when it is circulated next
By resolving redlines, you mean accept deletions, etc.?
Yeah, accept the revisions already approved by the DT
We will get rid of them
We remove this language along the way for sections already reviewed by the DT
But I still see things like "GAP" and references to the mapping document
thanks all, have to drop the call