[gnso-arr-dt] RT Permanent Endorsement Process
- To: gnso-arr-dt@xxxxxxxxx
- Subject: [gnso-arr-dt] RT Permanent Endorsement Process
- From: William Drake <william.drake@xxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 13 May 2010 15:50:44 +0200
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.
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
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?
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.