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

["Gomes, Chuck" <cgomes@xxxxxxxxxxxx>]

Please see my responses below.

Chuck

> -----Original Message-----
> From: owner-gnso-arr-dt@xxxxxxxxx [mailto:owner-gnso-arr-dt@xxxxxxxxx]
> On Behalf Of Tim Ruiz
> Sent: Thursday, May 13, 2010 12:08 PM
> To: gnso-arr-dt@xxxxxxxxx
> Subject: RE: [gnso-arr-dt] RT Permanent Endorsement Process
> 
> 
> 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.
[Gomes, Chuck] We can't put the permanent process aside because it is needed so 
that applicants for the SSR and Whois RTs know how to apply and what the 
qualifications are.  You are correct though that we first need to agree on the 
number of GNSO reps.  I think Wolf's motion takes care of that, assuming we all 
agree with it.

> 
> 
> 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?[Gomes, Chuck]  Yes  Can 
> more than one SG
> endorse the same person, e.g. someone not from one's own SG?[Gomes, Chuck]  
> Yes  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.[Gomes, Chuck]  Agree with Tim.
> 
> 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...[Gomes, Chuck]  I can go either way on this.
> 
> 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.[Gomes, Chuck]  I have reservations about 
> allowing the NCAs to endorse a candidate because that gives 3 people not 
> associated with any GNSO SG much more influence than any SG has.  At the same 
> time I support NCA involvement in the process.  For example, they should be 
> able to provide their input to SGs and the Council regarding particular 
> candidates if they so wish. 
> 
> 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.
[Gomes, Chuck] We could encourage SGs to provide alternative endorsements to 
help meet diversity goals.  We don't have to rigidly require that though.
> 
> 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.[Gomes, Chuck]  Agree.
> 
> 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.[Gomes, Chuck]  I am fine with this.
> 
> 
> 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"?[Gomes, Chuck]  I think we need something to 
> emphasize a willingness to devote the necessary time and we need to 
> communicate clearly that it is a large commitment.
> 
> 
> 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?[Gomes, Chuck]  The SGs should consider these factors in their 
> selection process. I also think that we should consider adding RT specific 
> qualifications to the qualifications.
> 
> 
> 
> 
> 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). 
[Gomes, Chuck] I am okay with this.

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