idnits 2.17.1 draft-halpern-nomcom-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 22, 2009) is 5238 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3777 (Obsoleted by RFC 7437) ** Obsolete normative reference: RFC 5680 (Obsoleted by RFC 7437) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF J. Halpern 3 Internet-Draft Ericsson 4 Expires: June 25, 2010 December 22, 2009 6 Nominating Committee Tools Requirements 7 draft-halpern-nomcom-requirements-00.txt 9 Abstract 11 With the change in the rules for disclosure of nominees, the tools 12 that support the Nominating Committee need to change. Also, given 13 that some of these tools are critical to the Nominating Committee's 14 work, and have critical constraints, it is important to have a clear 15 description of the requirements. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on June 25, 2010. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Event Sequence . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Necessary Tools . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Highly Desired Tools . . . . . . . . . . . . . . . . . . . . . 6 61 5. Useful Tools . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 64 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 With the change in the rules for disclosure of nominees, the tools 70 that support the Nominating Committee (nomcom) need to change. Also, 71 given that some of these tools are critical to the nomcom's work, and 72 have critical constraints, it is important to have a clear 73 description of the requirements. 75 The document begins with a brief description of the general flow of 76 the processing by the nominating committee. This is included to give 77 context to the following discussions. It is by no means a complete 78 description of all the sequences of events which can occur. 79 Following that, there are three sections describing tool support. 80 The first of these describes the tool components that appear to be 81 necessary for the nominating committee to complete its job in the 82 current environment. The second describes tools which while not 83 strictly necessary, are highly desirable. The third section captures 84 some of the items that nominating committees would like to have 85 available. 87 It should be noted that there are existing tools, provided by highly 88 effective and valued volunteer labor, which provide many of these 89 needed functions. While the tools need not provide exactly the 90 current user interface, and may well operate differently under the 91 covers, the existing tools are a useful model for understanding how 92 some of these needs can be met. 94 2. Event Sequence 96 The sequence of events and actions, and the rules of operation of the 97 IETF Nominating committee (nomcom) are defined in [RFC3777] and 98 [RFC5680]. The following is a general description, to provide 99 context for the tools descriptions below. 101 The process starts with the naming of the Nominating Committee chair 102 by the ISoc President. The chair then lays out a time line, and 103 issues a call for volunteers for the nominating committee. 105 The chair collects volunteers, frequently issuing multiple 106 solicitations, as the larger the pool of qualified and willing 107 volunteers, the better. Upon completion, the list of volunteers is 108 published. The community is given a chance to challenge entries on 109 the list, and then a random selection of 10 volunteers is performed. 110 The community is given a chance to object, and then the nomcom is 111 constituted. 113 The committee begins by working out procedures, getting the list of 114 openings, the job descriptions, the list of liaisons and adviser, and 115 performing initial organizational work. 117 Once the openings to be filled are known, the committee, via the 118 chair, issues a call for nominations. Anyone may nominate 119 individuals for positions. Nominations are for specific positions 120 (although the entire IAB is considered one "position", for which 121 multiple people will be selected. There is a list of IESG slots to 122 be filled, a number of IAB slots to be filled, and usually one IAOC 123 slot to be filled. The announcement usually includes the list of 124 incumbents. When nominations are received, the Nomcom chair is 125 responsible for contacting the nominee and determining if they are 126 willing to be considered for the position for which they have been 127 nominated. The list of nominees who have accepted nomination, and 128 the post or posts for which they have accepted nomination, are public 129 information. 131 In current practice, in parallel with the call for nominations the 132 nominating committee develops a questionnaire for the nominees. 133 Currently, there are three questionnaires, one for IAB nominations, 134 one for IAOC nominations, and one for an IESG nominations. Future 135 committees could create different questionnaires for each IESG slot, 136 or could use one questionnaire for all slots. Nominees are asked to 137 fill out their questionnaire by a given date. While committees will 138 generally be forgiving if asked for a little extra time, failure to 139 respond is usually considered grounds to disregard a nominee. The 140 questionnaire responses are confidential to the nominating committee. 141 Portions of them may be shared with the confirming body, depending 142 upon the procedures worked out between the Nomcom Chair and the 143 confirming bodies. 145 All email exchanged among or received by the committee needs to be 146 archived for review under certain circumstances. This archive, like 147 the questionnaire response, feedback, and other information received 148 by the committee must be handled with extreme care to ensure its 149 confidentiality. This is a personnel process. 151 At some point, the Nominating committee calls for feedback on 152 nominees. The exact time when this is done, and where these messages 153 are be sent, will need to be determined by the Nominating committee. 154 Traditionally, this has not happened until after the nominations were 155 closed, and was sent to a managed list of people in an effort to meet 156 the confidentiality requirements that used to exist relative to the 157 list of nominees. With the procedure change, described in [RFC5680], 158 it is probably practical to start collecting feedback as soon as the 159 first set of nominee names are made public. 161 The nominating committee will then undertake various processes 162 (interviews, email questions of more people, arm-twisting to get 163 nominees, extensive discussion of substance and form among the 164 volunteers and chair, ... to come to a selection of candidates. It 165 is very common, along the way, for the committee to craft short-lists 166 for various positions. 168 At various points in this process, the Nomcom Chair will need to 169 confirm the willingness and availability to serve of nominees. 170 Depending upon the stage of the process this may vary from "are you 171 still interested and willing?" to "please confirm that you have 172 management support for the time commitment you have stated for this 173 job." This is mentioned here in case someone sees a way for tools to 174 be helpful to this part. 176 Once the candidates are selected, the Nomcom Chair writes up the 177 information about the selections, and sends the information to the 178 confirming body. There may be exchanges of email or other 179 discussions. There may be modifications of the list of candidates. 180 Eventually, a set of candidates is confirmed by the confirming body. 182 3. Necessary Tools 184 There must be an email list for the nominating committee work. 185 Anyone in the community must be able to send to this list. There 186 must be a confidential archive for this list. In addition to the 187 archive, the Chair, advisers, liaisons, and volunteer members of the 188 committee must receive email from this list. 190 Any feedback received by the nominating committee must be stored by 191 the tool with the same confidentiality as the email list itself. 193 There must be a tool for making the list of nominees who have 194 accepted nomination, and the position(s) for which they are willing 195 to be considered, visible to the IETF community. 197 There must be provision for repairing errors. Mistakes get made. 198 Certain repairs may require administrative privileges, but there has 199 to be some way to fix things. 201 Any and all changes to the data should be logged. Even repairs 202 should be logged, so that in the event of dispute there are ways to 203 determine exactly what happened. This log itself needs to be 204 confidential. 206 4. Highly Desired Tools 208 It is extremely useful for the tools to provide explicit support 209 allowing any community member to provide feedback on any listed 210 nominee. This information should be recorded by the system and tied 211 to the person it is about, so as to make it easy for the nominating 212 committee to review all of the feedback about a given person. 214 If Feedback collection is provided by the tool, it needs to include 215 provision for attributed feedback that identifies the feedback author 216 (the normal case) and anonymous feedback. It is unclear at this time 217 whether the tool should itself anonymize the feedback, whether it 218 should send the feedback to the Chair for handling, or whether it 219 should be marked as anonymous, with provision for the chair to 220 determine who provided the information. In addition, the Chair and 221 the Adviser must be able to enter feedback either with or without 222 attribution to members of the community. 224 If there is tool support for collecting feedback, committee members 225 need to also be able to use that to create feedback (as well as, of 226 course, being able to review the feedback that is received.) In case 227 other members are asked to enter anonymous feedback, it would be 228 helpful if they could indicate that when entering feedback. 230 It can be helpful if the tools can assist the Nomcom Chair with the 231 processing of collecting nominees for positions. This includes 232 keeping track of who has been nominated, for what positions. For 233 each nominee/position pair, it should help send a confirmation, and 234 should track whether a confirmation or turn down has been received. 235 For those nominees who accept, if the committee chooses to use 236 questionnaires it would be helpful if the tool can track whether a 237 questionnaire response has been received. 239 As a general rule, it would be extremely helpful if information only 240 needed to be entered once. For example, If feedback is received as 241 email, and the system has recorded it as miscellany, it should be 242 possible to tell the system who this feedback is about, and have it 243 properly marked so that it is found when looking for feedback about 244 that person. Similarly, the list of nominees should be handled such 245 that there is no need to reenter people when they accept nomination, 246 and the committees view of nominees should be just a view into that 247 list. Similarly, if the tool assist with pruning lists during the 248 selection processes, these prunings should be marked (in ways that 249 affect what is seen by the nomcom but have no effect on what is seen 250 by the general community) so as to indicate those choices. 252 Having a suitably confidential Wiki has proven to be extremely 253 helpful to the nominating committee. 255 5. Useful Tools 257 A method to easily collect the volunteers for the nominating 258 committee could be helpful to the Nomcom chair. This could be the 259 base for a simpler mechanism by which names are submitted to the 260 Secretariat for verification, and the verification (or lack there of) 261 is returned. This needs to allow for several corner cases if it is 262 done. The Chair and Secretariat may determine that an initially 263 invalid volunteer was actually valid. Or the reverse. Also, a 264 volunteer may withdraw for other reasons. If the system is to help 265 with this phase, it needs to allow for flexible updating of the data. 267 If the chair chooses to use [RFC3797], the tool could provide the 268 programmatic support for that. (Usage of such support should not be 269 mandatory, as some chairs will want to have stricter verification of 270 the random process. If tools support is provided for the volunteer 271 selection process, it must allow for the chair determining (either by 272 himself, or because of a protest) that certain individuals are 273 disqualified, for example if there are too many volunteers with the 274 same affiliation. 276 It would be helpful if the feedback collection tool allowed for and 277 encouraged feedback on areas and bodies (the IAB, the IETF as a 278 whole, ...) as well as on specific individuals. 280 Given that nomcom members can no longer be expected to recognize 281 every person in the community who gets nominated, it would be helpful 282 if the tool had provisions for additional information about the 283 person, such as a photograph, a web page link, or other such fields. 284 This could also be used to provide easy links to the original 285 nomination, the acceptance, and the questionnaire response provided 286 by the nominee. 288 If the tool is storing and presenting feedback to nomcom members, it 289 is helpful if the tool can present the information in multiple ways. 290 The current tool easily presents the feedback about each person, in 291 time sorted order. It could also be helpful to be able to look at 292 the most recent set of feedback received, across all the nominees. 293 (Currently, one has to open each and every nominee to find any new 294 feedback.) 296 During its deliberations, the nominating committee will frequently 297 craft lists of people of interest (short-lists) for particular slots. 298 It would be helpful if the tool could easily show the committee those 299 lists. Any such support would need to be confidential. 301 6. References 302 6.1. Normative References 304 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 305 Recall Process: Operation of the Nominating and Recall 306 Committees", BCP 10, RFC 3777, June 2004. 308 [RFC5680] Dawkins, S., "The Nominating Committee Process: Open 309 Disclosure of Willing Nominees", BCP 10, RFC 5680, 310 October 2009. 312 6.2. Informative References 314 [RFC3797] Eastlake, D., "Publicly Verifiable Nominations Committee 315 (NomCom) Random Selection", RFC 3797, June 2004. 317 Author's Address 319 Joel M. Halpern 320 Ericsson 321 P. O. Box 6049 322 Leesburg, VA 20178 323 US 325 Email: joel.halpern@ericsson.com