idnits 2.17.00 (12 Aug 2021) /tmp/idnits40083/draft-shmoo-async-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3934]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 02, 2020) is 558 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 shmoo M. Knodel 3 Internet-Draft CDT 4 Intended status: Informational K. Novotny 5 Expires: May 6, 2021 Association for Progressive Communications 6 November 02, 2020 8 Meeting asynchronously with mailing lists 9 draft-shmoo-async-00 11 Abstract 13 For when we can't meet in person, when there's interim work to be 14 done, or just because the task calls for it, an asynchronous text- 15 based meeting can sometimes be perfectly productive and useful. 16 Given how much the IETF uses email already [RFC3934] this document 17 aims to create additional guidance for co-chairs and meeting 18 facilitators who might want to host a meeting asynchronously with 19 mailing lists. Drawing from decades of facilitation experience in 20 global networks, the document also treats unique considerations for 21 facilitators that are introduced by this meeting methodology. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 6, 2021. 40 Copyright Notice 42 Copyright (c) 2020 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 (https://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 Simplified BSD License. 55 Table of Contents 57 1. Introduction: Why? . . . . . . . . . . . . . . . . . . . . . 2 58 2. How . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Before: Meeting preparation . . . . . . . . . . . . . . . 3 60 2.2. During: Facilitating and participating . . . . . . . . . 4 61 2.2.1. Welcome . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2.2. Mixed methods . . . . . . . . . . . . . . . . . . . . 5 63 2.2.3. Polling and reaching consensus . . . . . . . . . . . 5 64 2.2.4. Threading and subject lines . . . . . . . . . . . . . 5 65 2.2.5. Social/AOB . . . . . . . . . . . . . . . . . . . . . 6 66 2.3. After: The destination . . . . . . . . . . . . . . . . . 6 67 2.3.1. Closing threads . . . . . . . . . . . . . . . . . . . 6 68 2.3.2. Meeting reports . . . . . . . . . . . . . . . . . . . 6 69 2.3.3. Meeting feedback . . . . . . . . . . . . . . . . . . 7 70 3. Considerations . . . . . . . . . . . . . . . . . . . . . . . 7 71 3.1. Defining participation . . . . . . . . . . . . . . . . . 7 72 3.2. Translation and accessibility . . . . . . . . . . . . . . 7 73 3.3. Netiquette and participant instructions . . . . . . . . . 7 74 3.4. Compliance . . . . . . . . . . . . . . . . . . . . . . . 7 75 4. Annexes and examples . . . . . . . . . . . . . . . . . . . . 8 76 4.1. Guidance from "Closer Than Ever" . . . . . . . . . . . . 8 77 4.2. Sample welcome message and agenda . . . . . . . . . . . . 9 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 7. Informative References . . . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction: Why? 85 Meeting online introduces new and novel challenges to in-person 86 meetings. Getting people online in a synchronous meeting is 87 generally difficult and demanding on everyone. High costs include 88 logistics and The difficulty grows exponentially with the number and 89 diversity of desired participants. If the meeting participants cut 90 accross different timezones, participation to such a meeting requires 91 a real committment and sacrifice from many participants. Although 92 the synchronous voice/video meetings imitate face-to-face meetings, 93 they fall short in terms of productivity in serious ways. 94 Particularly when meetings are large, synchronous discussion at scale 95 is usually questionable, and the real outputs rarely justify the 96 investment needed from everyone in orser to participate. 98 By contrast, well-structured asynchronous meetings have pacing and 99 mixed-methods that gives participants an opportunity to participate 100 in the ways which work for them, and when they can. Especially 101 during a global crisis, but really whenever one is expected to 102 participate in remote work, asynchronous meetings are more compatible 103 with individuals' limitations because they can adapt their 104 participation to their realities - removing the liklihood of the 105 clashes, which are seemingly ever present in synchronous meetings. 107 Since email is ubiquitous, mailing list software can be the 108 centerpiece of an asynchronous meeting toolchain. This is 109 particularly smooth for IETF participants given the established and 110 discplined use of mailing lists for IETF work. Throughout the 2020 111 pandemic arrangements for virtual IETF meetings there has been a 112 noticable persistence in "taking it to the list" when co-chairs seek 113 to build consensus, even though in theory there are a reduced number 114 of barriers for an engaged IETF participant to join an online 115 meeting. This indicates that even during synchronous, online IETF 116 meetings that activity on mailing lists is still important. 118 2. How 120 This document outlines how to, over a time-bound period, cultivate 121 productive mailing list activity, in order to rely less on 122 synchronous moments, or not at all. 124 2.1. Before: Meeting preparation 126 Preparation for any meeting is key. However there are particular 127 opportunities with an asynchronous meeting in which chairs can take 128 extra care to ensure productivity for the group, but also efficiency 129 for their work as facilitators during the meeting itself. 131 First, set up an organising space. Perhaps the datatracker is enough 132 for IETF meetings, but perhaps with the addition of a wiki space, or 133 creative use of Meeting Materials. Participants will be switching 134 their attention radars on and off in different moments - that's the 135 point! But they won't be present when you ask them to, or when you 136 email key information. The ongoing flow of participants and 137 presenters asking for clarifying details need to be gently directed 138 to one place with all of the meeting instructions and resources to 139 all these details somewhere visible (header or footer of all messages 140 during the meeting, etc). 142 Next, determine distinct discussion topics. It will not be enough to 143 have each presenter or document author write to the mailing list to 144 start a discussion about their work. Chairs will need to create a 145 structured agenda, with threads for each topic (see next section) 146 opened with a clear message detailing the topic's purpose, objective 147 and process. This implies that "agenda review" needs to happen well 148 in advance of the beginning of the asynchronous meeting. 150 For each topic it is critical to agree ahead of time on this topic- 151 opening message, ideally with the presenter(s) and author(s). The 152 message should contain enough background and context such that all 153 participants start with clarity on prior discussion, recent 154 decisions, and most importantly the "POP" of the thread, or 155 asynchronous discussion, itself. What is the purpose of getting 156 everyone's focussed attention on this threaded discussion for the 157 next few days? What's the objective- perhaps a set of decisions- for 158 the chairs, and possibly the author(s)? Each thread needs its own 159 process, too, explained- eg watch the presentation, read the draft, 160 compare versions, look at the open issues, take a poll, etc. Make 161 sure materials are managed: drafts should be listed on the meeting 162 materials page, presentations uploaded, and if other videos or 163 resources are needed that they are clearly linked from the same 164 place. 166 Plan to give participants a social outlet during the meeting. 167 Advanced planning could help the chairs facilitate moments throughout 168 the meeting that happen spontaneously in an in-person meeting, and 169 even sometimes in online conferencing. The chitchat about current 170 events, our private lives, or something everyone cares about. 171 Creating space for this on an agreed agenda will set the expectation 172 for participants that the meeting will be interesting and include 173 moments of humanity and levity. 175 2.2. During: Facilitating and participating 177 2.2.1. Welcome 179 An opening welcome message is very important and should be the first 180 thread opened. It should list the purpose and objective of the 181 welcome message, which is to start the meeting and ensure everyone 182 knows the agenda and how to participate. It's the place where 183 compliance, bluesheets and other information is shared for the first 184 time. The details outlined in the welcome message should be 185 available in the meeting space as the agenda, or reference materials, 186 for easy reference. 188 It's recommended that basic instructions to participants include 189 being present some fixed number of hours for the duration of the 190 meeting, eg plan to set aisde 10-15 minutes per day for a week to 191 engage in this meeting. 193 2.2.2. Mixed methods 195 An agenda item might require a mixed method, for example a 196 presentation about a draft delivered by the draft's author. In each 197 topic thread, the process should be clear for all participants, eg 198 watch the presentation and reply to the topic thread with questions 199 (like a mic line). It may well be that a synchronous moment is 200 needed, over voice, video conference, jabber, etc. For these 201 moments, and for the benefit of meeting participants unable to 202 attend, both record the session and create notes immediately and use 203 them as the basis for the continuation of the thread. Mixed method 204 can be powerful, but hard to get right. You don't want to keep 205 participants unable to participate synchronously waiting 2-3 days for 206 a readout on what happened. 208 2.2.3. Polling and reaching consensus 210 The first step to reaching a destination is knowing where you're 211 going. Facilitators and chairs will have an easier time building 212 consensus from the list if from the beginning it's clear what is 213 being built. Perhaps employing silence procedure is wise given list 214 subscription sizes.[Silence] 216 There may be innovations beyond a simple polling tool to substitute 217 humming that others in the shmoo WG may be keen to adopt and that 218 would be appropriate in an asynchronous space. 220 2.2.4. Threading and subject lines 222 As mentioned in the above section on meeting preparation, allocating 223 each agenda item to a topic thread allows the facilitator to open 224 distinct discussions on the mailing list with clarity of purpose, 225 objective and process. A clear subject line should be used for each 226 threaded topic. Forking discussion topic threads by pre-pending can 227 be a useful way to identify sub-topic areas, but chairs might 228 consider whether they would like to be in control of those changes or 229 allow spontaneous forking by any participant during the time-bound 230 meeting. 232 It is generally assumed that the mailing list be used only for the 233 meeting during the meeting dates, eg no other threads should be 234 opened without checking with the chair. Likewise, when the meeting 235 has ended, that no one should reply to, eg continue discussion of, 236 meeting topic threads. 238 2.2.5. Social/AOB 240 Chairs can facilitate social exchange during the meeting, emmulating 241 the in-person experience to some small degree. That includes 242 allocating separately a welcome and agenda message, so that the 243 welcome message can give participants a chance to "check in" on 244 others, offer up personal annecdotes, or share links. There may be a 245 current event that has its own topic thread, but is only tangentially 246 related to the meeting that would compell meeting participants to 247 check in on the meeting. 249 Any other business is often part of an IETF WG/RG meeting agenda, and 250 creating a topic thread can allow for asynchronous proposals for 251 other topics to discuss from participants themselves, though as 252 mentioned in the meeting preparation section above, agenda review 253 should ideally be done well in advance of the first day of the 254 meeting. 256 2.3. After: The destination 258 After the closing message ends the meeting, it's a useful and helpful 259 thing to take a few extra steps to ensure all objectives of the 260 meeting were achieved, that leaders and authors are clear on their 261 next steps, and that participants know they shouldn't reply to 262 meeting threads anymore. 264 2.3.1. Closing threads 266 While notetaking isn't really necessary, since the list archive 267 itself is a verbatim account of the meeting, having a summary of each 268 thread will be useful. Especially since each thread should already 269 have outlined a clear purpose and objective, the summary should 270 easily address whether or not those were fulfilled. 272 Participants should be given a chance to correct the closing thread 273 summary for inaccuracies only. 275 2.3.2. Meeting reports 277 A meeting report might be a compendium of all closing threads, and 278 constitute the official notes for the meeting that appear in the data 279 tracker. It might also helpfully include statistics on 280 participation. 282 2.3.3. Meeting feedback 284 In all cases, but especially with new methodologies like MAML, it's 285 recommended to conduct a short post-meeting evaluation with all 286 participants that can help facilitators determine what worked, what 287 didn't and to collect any other meta views that participants might 288 want to share. Rather than an open thread, meeting evaluations are 289 best conducted with anonymous surveys. 291 3. Considerations 293 3.1. Defining participation 295 There are yet unexplored models for how to host a full IETF meeting 296 held only on mailing lists given subscription to lists isn't 297 monetised. It isn't recommended to hold an asynchronous meeting over 298 several days, and encompassing an IETF virtual synchronous moment for 299 which participants would need to pay, as this would put list-only 300 participants at a disadvantage. 302 Another consideration is how to handle bluesheets for an asynchronous 303 meeting held on a mailing list with hundreds of subscribers. For 304 those not reading the list carefully, they may be surprised to know 305 that their commentary on a mailing list thread consistutes official 306 participation in an IETF meeting. Likewise it would be difficult to 307 ask participants to sign in when attention will be rather fluid. 309 3.2. Translation and accessibility 311 Text-based communications present opportunities for increased 312 accessibility of discussions because they can be fed into machine 313 translators and screen readers; read, reread and referenced more 314 easily. Asynchronicity removes time-related constraints sometimes 315 present in accessibility tools. 317 3.3. Netiquette and participant instructions 319 While most IETFers are well versed in proper mailing list netiquette, 320 perhaps reminders of how the chairs would prefer the meeting flow in 321 its discussion could be 323 3.4. Compliance 325 Lastly delivery of the Note Well and other compliance considerations 326 when meeting only on a mailing list need to be explored further. 328 At all times, but especially when faced with potentially a huge 329 increase in list traffic, chairs should be ready to enforce the IETF 330 Code of Conduct [RFC7776]. 332 4. Annexes and examples 334 4.1. Guidance from "Closer Than Ever" 336 The Association for Progressive Communications was founded in 1990 337 and has used mailing lists in creative ways to connect its global 338 network. Their publication on working remotely was rebooted in 2020 339 and here's a relevant excerpt [APC]: 341 When the email lists are used for meetings, we always establish a 342 clear procedure so that everyone involved in the meeting knows how 343 long we will be discussing the topics addressed, what topics will be 344 discussed each day or each week, and how subject lines will be 345 handled. 347 A typical online meeting can take place over three weeks: * Week 1: 348 signing in and posting of discussion topics * Week 2: discussion of 349 topics * Week 3: voting. 351 These are the basic steps that we follow for our online council 352 meetings: 354 1. Two weeks prior to the meeting, the meeting facilitators will 355 post the proposed meeting agenda and motions to the Board of 356 Directors for approval. 358 2. One week prior to the meeting, the executive director will post 359 the meeting agenda, including the full slate of proposed motions, 360 to the council email list. 362 3. Then we start the discussion by sending out one message for each 363 point of the agenda, so that members may reply accordingly to 364 each subject line. The first messages are for checking in: each 365 member that will participate in the meeting sends a short message 366 stating their name and organisation, so that we all know who is 367 participating. Then we continue by replying to messages 368 according to the subject headings of the agenda. 370 4. Once the meeting is finished there is an official message closing 371 the meeting and thanking everyone for their participation. All 372 council members will then receive a summary of the points 373 discussed and the agreements reached. 375 5. During the meeting the facilitator has a key role in making sure 376 everyone is participating, clarifying any doubts in the 377 procedures, and asking relevant questions to those members who 378 have been silent (sometimes off list, encouraging them to 379 participate). 381 4.2. Sample welcome message and agenda 383 Subject: shmoo-IETF109 0: Agenda and process overview 385 This message is to open the _shmoo Meeting at IETF 109_. The meeting 386 will take place on this list between _DD-DD Month YYYY_. 388 The process for the meeting is the following: 390 The chairs will open specific topic threads by sending opening 391 messages to this list. 393 Reply to any thread at any time, just make sure to keep the subject 394 line intact so it is clear on what topic you are responding. 396 Below is the agenda. Please use this topic thread only if you have 397 something to say about the agenda or the process. 399 Remember that all relevant information and all documents shared in 400 this meeting are available on the datatracker: _URL_ 402 Please shout with any questions. 404 Welcome to the meeting! :) 406 AGENDA: Stay Home Meet Only Online IETF 109 Meeting, _DD-DD Month 407 YYYY_ 409 - shmoo-IETF109 0: Agenda and process overview (this thread) 411 - shmoo-IETF109 1: Check in and social space 413 - shmoo-IETF109 2: draft-shmoo-firstexample-00 415 - shmoo-IETF109 3: draft-shmoo-secondexample-07 417 - shmoo-IETF109 4: draft-thirdexample-03 419 - shmoo-IETF109 5: Any other matters 421 - shmoo-IETF109 6: Closing the meeting 423 5. Security Considerations 425 Security is dependent on a wide range of actors that are implementing 426 technical documentation. Therefore it is crucial that language is 427 clear, and understood by all that need to implement this 428 documentation. Correct and inclusive language is therefore conducive 429 for secure implementations of technical documentation. 431 6. IANA Considerations 433 This document has no actions for IANA. 435 7. Informative References 437 [APC] Association for Progressive Communications, . and , 438 "Closer than ever: A guide for social change organisations 439 who want to work online", 440 . 442 [RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the 443 Management of IETF Mailing Lists", BCP 25, RFC 3934, 444 DOI 10.17487/RFC3934, October 2004, 445 . 447 [RFC7776] Resnick, P. and A. Farrel, "IETF Anti-Harassment 448 Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March 449 2016, . 451 [Silence] Wikipedia, . and , "Silence procedure", 2020, 452 . 454 Authors' Addresses 456 Mallory Knodel 457 CDT 459 EMail: mknodel@cdt.org 461 Karel Novotny 462 Association for Progressive Communications 464 EMail: karel@apc.org