[gnso-arr-dt] RT Permanent Endorsement Process

[William Drake <william.drake@xxxxxxxxxxxxxxxxxxxx>]

Hello,

I am back on the grid after an unavoidable absence, or at least am crawling in 
that direction.  I've read very little mail in May and am way behind, please 
correct any misunderstandings.

It appears we put the permanent process aside for the moment to focus on the 
SSR and WHOIS per Janis.  So presumably we are shooting for the 10 June Council 
meeting, and need a motion by the 3rd, three weeks from today.  

Endorsement Process

On 30 April Tim proposed a simplified procedure in which each SG endorses one 
candidate and any diversity concerns are then addressed at the Council level, 
with the addition of x people being possible via a majority vote of both 
houses.  Two people replied favorably, nobody opposed.  Some questions about 
going down this path:

1.  Can a SG decide not to endorse any candidate?  Can more than one SG endorse 
the same person, e.g. someone not from one's own SG?  Both seem reasonable, 
although I suppose we'd have to tweak the request that the Selectors allocate x 
slots to GNSO per RT.

2.  Are people now inclined to abandon the concept of having an Council-wide 
elected slot for people who consider themselves to be in the GNSO community but 
not affiliated with/seeking the endorsement of any particular SG?  It obviously 
would simplify things, but previously there were concerns about this being 
exclusionary and having a slightly cartel-like optic.  We did after all have 
people apply as unaffiliated in the first round...

3.  Re: diversity, in this model we'd only consider adding people to move 
toward the objectives , rather than e.g. going back to SGs and asking them to 
reconsider their first choice.  

a.  Would we still state the diversity objectives?  Our existing language says 
that unless the applicant pool does not allow, no more than two nominees should 
come from the same geographical region, nominees must not all be of the same 
gender, and the distribution between genders should be no greater than 
two-thirds to one-third.  Personally, I still think it is desirable to publicly 
state an aspiration and try to hold ourselves to it IF the pool submitted to 
ICANN allows.  Especially if we drop down to just up to four SG endorsed 
nominees in the first instance, I would hope we could aspire at least to one 
woman and two non-US.

b.  I presume Council would only be able to pick from the pool of people who 
applied to ICANN?  How many?  Worst case scenario, SGs nominate 4 white guys 
from the US, could we propose up to two for balance?  (which hopefully the 
Selectors would give equal consideration)

c.  In this model, would we abandon the Evaluation Team?  If we don't have 
elected slots 5 and 6 and diversity is being at the Council level via possible 
additions rather than any negotiation etc, it's not obvious we'd need this 
mechanism.


Additional GNSO Requirements.

If I recall correctly nobody thought these needed any amendment.  However, 

1.  In the first round we included in the in-house Action Plan (below) the 
statement that "volunteers are encouraged to self- identify with any GSNO SG / 
Constituency with which they feel most closely affiliated."  I suggest we move 
this encourgement to the Requirements, where it should have been.

2.  In light of the ICANN CFP wording should we delete the "attestation that 
the applicant is able and willing to commit at least ten hours per week during 
the review period"? 

3.  It has been suggested that for the SSR RT some indicator of security/tech 
expertise would be useful.  One could argue that specialized expertise would be 
useful for the competition and WHOIS RTs as well.  Do we feel the need to add a 
sentence that caters to these situations or should we just assume people will 
be reasonable and self-select?


Action Plan

Our initial effort included a set of in-house procedures.  Depending on what we 
decide about the process, will we still need to have such a document?  For 
example, the existing one dealt with how to handle unaffiliated or unclearly 
affiliated people.  In Tim's model, this isn't needed as there's no elected 
unaffiliated slot and the SGs just endorse whomever they like from the pool 
(irrespective of whether or how they've self-identified).  We could lose the 
elaborate language on time lines etc that resulted from ICANN's shifting 
parameters on the maiden voyage, and the still relevant bits could probably be 
collapsed down to a simple sentence or so in the publicly available Endorsement 
Process, e.g. stating that by x days after ICANN's deadline for submissions the 
Council will forward its nominations to the Selectors.


It would be really helpful to hear from all members of the DT on these and any 
related points.  I see that the 20 May Council agenda has 25 minutes allocated 
to this topic and that I'm supposed to convey the DT's recs, so any movement 
toward closure by then would be great.

Thanks,

Bill