RE: [gnso-arr-dt] RT Permanent Endorsement Process

["Tim Ruiz" <tim@xxxxxxxxxxx>]

Comments in line below.  
 
-------- Original Message --------
Subject: [gnso-arr-dt] RT Permanent Endorsement Process
From: William Drake <william.drake@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, May 13, 2010 8:50 am
To: gnso-arr-dt@xxxxxxxxx

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.

TIM: Good question. I don't think we can require a SG to endorse, or SGs
not to endorse the same person. It may be that we are given "up to" x
seats on the RT. I think the point is making sure the GNSO feels
appropriately represented.

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...

TIM: A SG does not have to endorse someone affiliated with their SG.
They could endorse someone from another SG, or someone unaffiliated. So
unaffiliated applicants are not shut. I just have a problem with
"forcing" the issue by requiring the Council to endorse an unaffiliated
candidate whether the SGs do or not. Perhaps a resolution to this is to
allow the NCAs to endorse an applicant. In fact, that seems like a good
resolution. But even they should be allowed to endorse who they want, a
SG affiliated candidate, or someone endorsed by a SG, and be required to
endorse a non-affiliated candidate.

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.  

TIM: We can state the desired outcome in terms of diversity to encourage
consideration. I don't think we should require it, or go back to SGs
asking them to reconsider. Make the diversity aspirations clearly known,
but accept the endorsements as presented.

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.

TIM: We can state the desired outcome in terms of diversity to encourage
consideration. I don't think we should require it, or go back to SGs
asking them to reconsider. Make the diversity aspirations clearly known,
but accept the endorsements as presented.

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)

TIM: Yes, only from the pool of actual applicants. Diversity should not
be a requirement, and the Council should not second guess the SGs by
adding in their own cadidates. Diversity for the sake of diversity makes
no sense.

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.

TIM: Yes, I believe we could abandon the Evaluation Team. But if we
don't, let's come up with a name for it that has a better acronym ;-)


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