idnits 2.17.1 draft-eckel-shmoo-ietf-hackathon-03.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1098 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (10 March 2021) is 1136 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 shmoo C. Eckel 3 Internet-Draft Cisco Systems 4 Intended status: Informational 10 March 2021 5 Expires: 11 September 2021 7 Running an IETF Hackathon 8 draft-eckel-shmoo-ietf-hackathon-03 10 Abstract 12 IETF Hackathons encourage the IETF community to collaborate on 13 running code related to existing and evolving Internet standards. 14 This document provides a set of practices for running IETF 15 Hackathons. 17 Discussion Venues 19 This note is to be removed before publishing as an RFC. 21 Discussion of this document takes place on the Stay Home Meet Only 22 Online Working Group mailing list (manycouches@ietf.org), which is 23 archived at https://mailarchive.ietf.org/arch/browse/manycouches/. 25 Source for this draft and an issue tracker can be found at 26 https://github.com/eckelcu/internet-drafts. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 11 September 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction 62 2. Conventions and Definitions 63 3. Timing 64 3.1. Agenda 65 3.2. Hackdemo Happy Hour 66 3.3. Code Lounge 67 3.4. Code Sprint 68 3.5. Online Only 69 4. Funding 70 4.1. Sponsorship 71 4.2. Expenses 72 4.2.1. In-person Event Expenses 73 4.2.2. Remote Participation Expenses 74 5. Project Presentations 75 5.1. Project Pitches 76 5.2. Results Summaries 77 5.2.1. Templates 78 5.3. Upload to GitHub 79 5.4. Presenting in Person 80 5.5. Presenting Remotely 81 6. Tooling 82 6.1. Datatracker 83 6.2. IETF Website 84 6.2.1. Hackathon Webpage 85 6.2.2. Meeting Webpage 86 6.3. Registration 87 6.3.1. Attendee List 88 6.3.2. Caps on Registrations 89 6.4. Meeting Wiki 90 6.4.1. Hackathon 91 6.4.2. Lost and Found 92 6.4.3. Results Presentation Schedule 93 6.4.4. In Person Only 94 6.4.5. Online Only 95 6.5. Mailing List 96 6.5.1. Hackathon Chairs Email Alias 97 6.6. GitHub 98 6.7. Meetecho 99 6.8. Network 100 6.8.1. Remote Networking 101 6.9. Webex 102 6.10. Gather 103 7. Statistics and Metrics 104 7.1. IETF Survey Results 105 7.2. Hackathon Survey results 106 8. Roles and Responsibilities 107 8.1. Hackathon Chair(s) 108 8.2. Secretariat 109 8.3. Sponsor 110 8.4. Champions of Projects 111 8.5. IETF LLC, Director of Communications and Operations (was 112 ISOC) 113 8.6. Judges 114 9. Security Considerations 115 9.1. Privacy Considerations 116 10. IANA Considerations 117 11. Normative References 118 Acknowledgments 119 Author's Address 121 1. Introduction 123 IETF Hackathons encourage the IETF community to collaborate on 124 running code related to existing and evolving Internet standards. 125 IETF Hackathons aim to: 127 * Advance the pace and relevance of IETF standards activities by 128 bringing the speed and collaborative spirit of open source 129 development into the IETF 131 * Bring developers and young people into IETF and get them exposed 132 to and interested in the IETF 134 IETF Hackathons are free to attend and open to everyone. Software 135 developers are the primary audience, but participation by subject 136 matter experts who are not necessary developers is encouraged and 137 very important as well. Similarly, while the Hackathon is meant to 138 attract newcomers and those who do not typically view themselves as 139 standards people, long time IETF contributors, including Internet- 140 Draft authors, working group chairs, and subject matter experts, are 141 key participants as well. Group dynamics and blending of skillsets 142 and perspectives are extremely valuable aspects of IETF Hackathons. 144 In addition to the running code created and improved as a result of 145 each Hackathon, the exchange or ideas, extensions of human networks, 146 and establishment of trust, respect, and friendships are some of the 147 most valuable outputs of each Hackathon. Code written in a 148 programming language can be more illustrative and less 149 confrontational than opinions expressed during a meeting or in an 150 email. Working together to find common understanding of proposals, 151 concerns, and solutions that result in improvements to evolving 152 Internet standards is as important as the development of running code 153 that implements or validates the correctness of these same proposals. 155 Consequently, IETF Hackathons are collaborative events, not 156 competitions. Any competitiveness among participants is friendly and 157 in the spirit of advancing the pace and relevance of new and evolving 158 Internet standards. 160 This document provides a set of practices for running IETF 161 Hackathons. 163 2. Conventions and Definitions 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in BCP 168 14 [RFC2119] [RFC8174] when, and only when, they appear in all 169 capitals, as shown here. 171 3. Timing 173 The first IETF Hackathon was held the weekend before the start of the 174 IETF 92 meeting. The rationale was to avoid conflicts yet make it 175 relatively convenient for those attending the IETF meeting to 176 participate in the Hackathon as well. Holding the Hackathon on the 177 weekend was also viewed as making it more accessible to non IETF 178 meeting attendees, including students and working professionals who 179 would have other commitments during the week. The weekend before was 180 viewed as better than the weekend after so that things learned during 181 the Hackathon could be shared and discussed with the rest of the IETF 182 community during working group sessions and the like. This worked 183 well at IETF 92, was repeated at IETF 93, and quickly became an 184 established norm with the IETF meeting being officially extended to 185 include the Hackathon at the start. An additional benefit of this 186 timing noted and appreciated by participants is that it serves as a 187 more informal and social way to physically and mentally acclimate to 188 changes in time zones, surroundings, and subject matter. 190 3.1. Agenda 192 The IETF Hackathon is a strenuous event. Though not a competition, 193 participants want to make the most of their time together, much as 194 with the IETF meeting in general. Competitive Hackathons typically 195 run non-stop for on the order of 40 hours. There is a strict 196 deadline and teams are judged and winners declared at the end. 197 Afterward everyone is wiped out and heads off to briefly celebrate or 198 commiserate, but mainly to recuperate. As the IETF Hackathon serves 199 as the start of the overall IETF meeting, we aim to strike a 200 compromise that provides enjoy time to get valuable work accomplished 201 without exhausting themselves before the main IETF meeting even 202 starts. While some people participate in the Hackathon only, the 203 majority of people remain and plan to be actively engaged in the rest 204 of the IETF meeting. 206 The typical agenda is as follows: 208 Saturday before IETF meeting week 209 08:30: Room open for setup by project champions 210 09:00: Room open for all - Pastries and coffee provided 211 09:30: Hackathon kickoff 212 09:45: Form Teams 213 12:30: Lunch provided 214 15:30: Afternoon break - Snacks provided 215 19:00: Dinner provided 216 22:00: Room closes 218 Sunday before IETF meeting week 219 08:30: Room opens - Pastries and coffee provided 220 12:30: Lunch provided 221 13:30: Hacking stops, prepare brief presentation of project 222 14:00: Project presentations to other participants 223 15:45: Closing remarks and opportunities for next time 224 16:00: Hackathon ends 225 17:00: Tear down complete 227 The time on Saturday morning provides team champions time to setup 228 and participants time to socialize and learn more about projects and 229 team they might want to join. The kickoff presentation and 230 formalities are kept to minimum to leave as much time as possible for 231 team to work together with their team on their projects. The 232 proximity of teams to each other fosters communication and 233 collaboration across teams as well. 235 Lunch and dinner are provided as a convenience and an incentive to 236 remain at the Hackathon. Participants are free to come and go as 237 they like. It is well understood and accepted that there are other 238 things vying for time and that meeting with friends or colleagues 239 outside of the Hackathon is an entirely reasonable thing to do. 241 The room closes Saturday evening to give hotel staff unfettered 242 access to the room and to encourage people to pace and take care of 243 themselves. There are no rules against continuing work on Hackathon 244 projects outside of the Hackathon room. Similarly, working on 245 projects long before and after the Hackathon is allowed and 246 encouraged. 248 The end of the Hackathon on Sunday is driven by other IETF meeting 249 events. There typically are Newcomer events that start at 16:00. 250 The IETF Hackathon typically includes many newcomers in its list of 251 participants. It is important to provide them time to participate in 252 the Newcomer events. The opening reception typically start at 17:00, 253 and we want to make it easy for all Hackathon participants to join 254 that as well. 256 Hackdemo Happy Hour (ref) and the Code Lounge (ref) exist to 257 facilitate ongoing discussion and work on projects beyond the 258 official end of the Hackathon weekend. 260 3.2. Hackdemo Happy Hour 262 Hackdemo Happy Hour provides an opportunity for more in depth sharing 263 and discussion than is possible within the time constraints of the 264 result presentation that occur at the end of the Hackathon. This 265 opportunity is made available to all teams. As with the results 266 presentation, participation is optional. 268 Initially, we did something similar as part of Bits and Bites. This 269 worked well for the Hackathon but the Bits and Bites event was 270 eventually abandoned for other reasons. Hackdemo Happy Hour was 271 created as a low cost, informal event to provide a venue for the IETF 272 community to engage with the Hackathon teams in more in depth 273 discussions related to their projects. 275 Hackdemo Happy Hour is typically Monday evening, roughly from 18:00 - 276 19:30, often overlapping a bit with the last working group session of 277 the day but continuing long enough to allow everyone an opportunity 278 to join. The goal is to make it convenient to attend by not 279 conflicting with other meetings but also no running too late into the 280 night. 282 Light snacks and non alcoholic beverages are provided, and a cash bar 283 is available to align with the spirit of a happy hour. 285 3.3. Code Lounge 287 The Code Lounge provides space for groups to gather and continue to 288 collaborate on running code after the Hackathon. It is typically in 289 the IETF Lounge and open the same hours as the IETF Lounge. 290 Champions are encouraged to look at the final agenda and determine 291 time slots best suited to ensure successful attendance of Code Lounge 292 sessions as well as any traditional working group sessions. It is 293 okay for multiple teams to sign up for the same time slots. This is 294 in fact encouraged for work that spans multiple working groups or 295 projects. 297 3.4. Code Sprint 299 Some efforts were made to have the Hackathon and the Code Sprint work 300 together or potentially be combined into a single event focusing on 301 the development of IETF protocols and IETF internal tools. There is 302 some concern that the events currently compete for resources. There 303 is also a great deal of synergistic potential. Several Hackathon 304 projects, such as those related to YANG model validation, involve the 305 creation or modification of IETF tools. 307 The Code Sprint existed long before the Hackathon and has its own 308 identity and way of doing things. The Code Sprint organizers are 309 against combining the events and potentially losing this identity the 310 benefits of a customized event. The practice that exists today is to 311 locate the events physically close to each other to facilitate 312 switching back and forth between the two events. 314 3.5. Online Only 316 The IETF 107 Hackathon was originally scheduled to be the weekend at 317 the start of the IETF meeting in Vancouver. When COVID-19 hit and it 318 became clear the IETF meeting could not occur in person, the 319 Hackathon already had 23 projects and 176 registrations. With only 320 10 days until the anticipated start of the Hackathon, a survey went 321 out to the Hackathon community, including all project champions and 322 registered participants, to see if they wanted to participate in the 323 Hackathon exactly as planned except with everyone participating 324 remotely rather than in person. A relatively small number of people 325 expressed interest in participating, with even fewer wanting to 326 continue to champion their projects. The fact that the Hackathon was 327 planned for the weekend before the IETF meeting and in the local time 328 zone, both of which were historically very convenient and attractive 329 to Hackathon participants, suddenly became huge obstacles. 330 Consequently, the IETF 107 Hackathon was cancelled. 332 We knew more in advance that IETF 108 would be an online only 333 meeting. We moved and expanded the schedule to run the entire work 334 week before the rest of the IETF meeting. The Hackathon kickoff was 335 set for Monday, the closing for Friday, with all the time in between 336 left for individual project teams to arrange to meet how and when was 337 most convenient for them. The kickoff and closing sessions were 338 schedule to align with the time frame established for the IETF 108 339 meeting. All of this was, of course, not ideal, and it worked much 340 better for some people than for others, but at least everyone knew 341 the plan and corresponding time commitment well in advance and had 342 the ability to plan accordingly. 344 The response was great. We ultimately had 19 projects and almost 300 345 registrations. It is hard to say how many people actually 346 participated and for how long, but many projects were able to get 347 substantial work done. For the closing, 10 teams produced and shared 348 presentations summarizing their findings and achievements. All 349 presentations as well as the agenda and a recording of the closing 350 session are available via the IETF 108 Hackathon wiki 351 (https://trac.ietf.org/trac/ietf/meeting/wiki/108hackathon). 353 Hackdemo Happy Hour and the Code Lounge are not applicable for online 354 only Hackathons. 356 4. Funding 358 The Hackathon requires funding, and that funding increases with the 359 number of participants. Participating has always been free; 360 therefore, funding from other sources than participant fees is 361 required. 363 4.1. Sponsorship 365 The initial funding model was to have Hackathon sponsors sign up to 366 sponsor and fund the Hackathon for one year. As part of starting the 367 Hackathon, Cisco volunteered to sponsor and fund the Hackathon for 368 its first year (i.e., three Hackathons, one at each IETF meeting 369 during a calendar year). This sponsorship was to rotate. Huawei 370 volunteered to sponsor the second year of the Hackathon. After the 371 second year, a sponsor for the 3rd year was not found. However, the 372 Hackathon had become a proven success. Consequently, the IETF 373 decided to fund the Hackathon as part of the IETF meeting, with 374 Hackathon sponsorship being on a best effort basis. 376 Online only Hackathons in response to the COVID-19 pandemic, and 377 increased remote participating in general, result in increased cloud 378 infrastructure requirements that make Hackathon sponsorship more 379 attractive to cloud infrastructure providers. 381 Hackathon sponsorship opportunities are publicized via a dedicated 382 page on the IETF website (https://www.ietf.org/about/support/ 383 hackathon-sponsorship/). 385 4.2. Expenses 387 The primary expenses associated with the Hackathon are those for 388 hosting an in-person event, e.g., meeting space, food and beverage, 389 etc. It is often challenging to quantify the portion of this 390 associated with the Hackathon from that incurred for the IETF meeting 391 overall. 393 4.2.1. In-person Event Expenses 395 The following expenses are associated with in-person participation in 396 a Hackathon. When the IETF meeting is online only, these expenses 397 are eliminated. 399 4.2.1.1. Meeting Space 401 The meeting space for the Hackathon is sometimes included as part of 402 the overall contract for the IETF meeting. Other times, additional 403 expense is incurred to secure a large enough space earlier than would 404 otherwise have been required. Typically, the space is needed for 405 setup from Friday afternoon before the start of the IETF meeting 406 until Sunday afternoon. After the Hackathon, the space is typically 407 repurposed for the IETF Lounge. If the size of the Hackathon 408 continues to increase, it might be necessary to use the same space as 409 is later used for the IETF plenary. 411 4.2.1.2. Food and Beverage 413 Some portion of the food and beverage expense is often included as 414 part of a minimum spend the IETF is obligated to make. When a 415 Hackathon sponsor is identified, funds resulting from this 416 sponsorship are typically used to offset food and beverage expenses, 417 or to increase the food and beverage budget. 419 The minimum food and beverage for the Hackathon has been, 421 * coffee, tea, and water Saturday and Sunday morning 423 * lunch Saturday and Sunday 425 Additional items, in order of importance, include, 427 * beer Saturday evening 429 * dinner Saturday evening 431 * continental breakfast Saturday and Sunday 433 * afternoon snacks Saturday and Sunday 435 4.2.1.3. T-shirts 437 Hackathon t-shirts are an important part of the Hackathon. They have 438 been provided for all in-person Hackathons and greatly appreciated by 439 many participants. The also serve as great advertising for the IETF, 440 the Hackathon, and sponsors. Cisco or other event sponsors have 441 often covered expenses associated with t-shirts. The current model 442 is that the secretariat covers the expenses using whatever funding is 443 available. 445 The number of size distribution of t-shirts for IETF 107 is provided 446 here as an example. 448 * 380 t-shirts at a cost of roughly $10 USD / t-shirt with shipping 449 to the Secretariat included 451 - 50 Small 453 - 120 Medium 455 - 110 Large 457 - 75 XL 459 - 25 XXL 461 The t-shirts are all standard cut. We previously tried providing 462 fitted cut t-shirts as an option for Hackathon participants, but 463 these were not well received. 465 4.2.1.4. Stickers 467 Laptop stickers are popular with developers. Stickers have been made 468 available at the Hackathon for those that want them. Expenses have 469 been covered by the IETF LLC, Director of Communications and 470 Operations. 472 4.2.2. Remote Participation Expenses 474 The following expenses are associated things done primarily to 475 facilitate remote participation in a Hackathon. This includes 476 participation when the Hackathon is online only as well as remote 477 participation when the Hackathon is in-person. 479 * Meetecho: cost associated with Hackathon kickoff and closing 481 * Gather: costs associated with premium service, required to enable 482 more than 25 concurrent users. This has not been necessary, but 483 will almost certainly be if Gather becomes a valuable way for 484 Hackathon participants to meet within and across teams. 486 * Webex: IETF Webex accounts are made available to champions for the 487 duration of the Hackathon and some period beyond that encompasses 488 at least the rest of the IETF meeting. These accounts are 489 available at no additional cost to the IETF at present 491 * Network: setup and support of the IETF network, and remote access 492 to it 494 The change in timing and extended duration of the Hackathon at an 495 online only IETF meeting increases the duration and use of remote 496 participation facilities from 7 days to 12 days. This may result in 497 increases to the cost of providing these facilities. 499 5. Project Presentations 501 Project presentations are an important mechanism for capturing what 502 each team intends to accomplish, what they actually accomplished, and 503 sharing the results and findings with the IETF community. 505 For the first few Hackathons, we had two very distinct types of 506 presentations, 508 1. Presentation that served as project pitches at the start of the 509 Hackathon 511 2. Presentations that summarize results at the end of the Hackathon. 513 5.1. Project Pitches 515 The project pitches were 5-10 minute presentations by a champion of a 516 project describing what they wanted to do and how they proposed to 517 accomplish it. This gave everyone in the room a better understanding 518 of all the projects and helped participants match themselves with 519 appropriate projects. This worked well when we had a small number of 520 projects, but it became unwieldy as the number of projects increased. 521 As knowledge of the Hackathon grew and advanced planning became more 522 common, many participants knew exactly which team they planned to 523 join and wanted to get to work as quickly as possible rather than 524 spend a couple hours listening to presentations. Project pitches 525 were dropped from the Hackathon. Champions are encouraged to share 526 this type of information in advance via the Meeting Wiki 527 (Section 6.4) instead. 529 5.2. Results Summaries 531 The results summaries are brief presentation by each team of what 532 problem they tried to solve, what they achieved, and highlights that 533 include lessons learned, feedback to associated working groups, and 534 collaboration with open source communities and other standards 535 organizations. They also highlight individuals who are participating 536 in their first IETF Hackathon or first IETF event to facilitate their 537 introduction into the IETF community. The production and 538 presentation of results summaries is optional. Fortunately, despite 539 the lack of awards and prizes, most teams participate. 541 As with the project pitches, results summaries can become unwieldy as 542 the number of projects increases. With this in mind, the total time 543 for all results summaries is limited to 2 hours. The maximum 544 duration of each presentation is calculated based on the number teams 545 that have indicated the desire to present. This maximum is strictly 546 enforced to ensure all teams have the opportunity to present their 547 results. Maximum durations of 3-5 minutes are typical. 549 5.2.1. Templates 551 Project results presentation templates provides guidance on what to 552 cover. The use of these templates is optional. They are made 553 available in various in various formats in a GitHub repo created 554 specifically for the presentations for each IETF Hackathon (e.g., 555 https://github.com/ietf-hackathon/ietf108-project-presentations 556 (https://github.com/ietf-hackathon/ietf108-project-presentations)). 558 5.2.1.1. PPTX 560 For portability, presentations that use this template should be made 561 exported into PDF format as well. 563 5.2.1.2. HTML format 565 This template should render within any browser. It can be rendered 566 as a slideshow using remark (https://github.com/gnab/remark). 568 5.3. Upload to GitHub 570 All presentation are uploaded to the GitHub repo created the 571 Hackathon (e.g., https://github.com/ietf-hackathon/ietf108-project- 572 presentations (https://github.com/ietf-hackathon/ietf108-project- 573 presentations)). The contents of this repo are used as the source 574 for all project presentations at the end of the Hackathon and remain 575 as a reference after the Hackathon. 577 One must be a member of the IETF-Hackathon GitHub org to upload a new 578 presentation or update/replace an existing presentation. 580 To be added as a member, presenters are asked to 582 * include the name by which they are known in their GitHub profile 584 * enable two factor authentication (2FA) 586 * send your GitHub user name to the Chair(s) 588 Presenters are asked to do this at their earliest convenience as the 589 Chair(s) typically get very busy as the start of presentations 590 approaches. 592 5.4. Presenting in Person 594 Presentations are run from a shared ChromeBook at the front of the 595 Hackathon room. This Chromebook is provided by the Secretariat. 597 5.5. Presenting Remotely 599 Remote presenters are welcome to run their own presentations using 600 the screen sharing functionality in Meetecho. Alternatively, the 601 Hackathon Chairs can share the presentation and advance slides for 602 the presenter. 604 6. Tooling 606 The IETF Hackathon uses the same tooling used by the IETF community 607 for its work and meetings. 609 6.1. Datatracker 611 The datatracker (https://datatracker.ietf.org/) supports the notion 612 of Teams that are not a part of the standards development process. 613 The Hackathon exists as one such Team. From the datatracker menu, 614 navigate to "Other" -> "Active Teams" -> "Hackathon". Here exists a 615 datatracker space for the Hackathon similar to what is available for 616 working groups, including meeting materials, agendas, etc. 617 Initially, there was some attempt to copy materials hosted in GitHub 618 (https://github.com/ietf-hackathon) to the datatracker. Now this is 619 done only when required for integration with other IETF tooling, 620 including: 622 * requesting sessions (https://datatracker.ietf.org/secr/sreq/) for 623 the Hackathon kickoff and closing, and for Hackdemo Happy Hour 625 * posting agendas (https://datatracker.ietf.org/meeting/agenda/) 627 6.2. IETF Website 629 6.2.1. Hackathon Webpage 631 The IETF website includes a dedicated page for the Hackathon webpage 632 (https://www.ietf.org/how/runningcode/hackathons/). This page 633 contains information about the Hackathon in general as well as links 634 to past, present, and future Hackathons. The relevant links are 635 updated after each IETF meeting. Other content on the page is 636 updated on a more ad hoc basis. 638 6.2.2. Meeting Webpage 640 Each IETF meeting webpage (https://www.ietf.org/how/meetings/) 641 contains information about the corresponding Hackathon, including the 642 dates of the Hackathon in the header, a link to the Hackathon webpage 643 in the "Additional Events" section. 645 6.3. Registration 647 Registration for the Hackathon is through the IETF meeting 648 registration (https://registration.ietf.org) system. Participant 649 registration for the Hackathon is 651 * independent of participation registration for the meeting 653 * free 655 * required 657 As with meeting registration, registrants for the Hackathon 658 acknowledge the Note Well (https://ietf.org/about/note-well/) during 659 the registration process. 661 6.3.1. Attendee List 663 An active list of all registered attendees (e.g., 664 https://registration.ietf.org/109/participants/hackathon/ 665 (https://registration.ietf.org/109/participants/hackathon/)) is 666 maintained by the Secretariat. Important information displayed for 667 each registrants include the set of projects and technologies in 668 which each participant is interested and an email address. This 669 information is optional at the time of registration and may be 670 updated or removed by editing ones registration. 672 6.3.2. Caps on Registrations 674 Registrations were capped for the first several Hackathons. This was 675 done both for space and costs considerations. The cap was hit 676 multiple times, each time resulting in temporary confusion and 677 frustration among would be registrants, followed by the cap being 678 increased. Currently, there are no caps enforced by the registration 679 system. 681 6.4. Meeting Wiki 683 The meeting wiki serves as the primary source of information for each 684 Hackathon. 686 6.4.1. Hackathon 688 A page within the meeting wiki (e.g., 689 https://trac.ietf.org/trac/ietf/meeting/wiki/109hackathon 690 (https://trac.ietf.org/trac/ietf/meeting/wiki/109hackathon)) is 691 created by the Secretariat for each Hackathon and initialized with 692 information that is based largely on the information from the 693 previous Hackathon. Once created, the Hackathon Chairs update and 694 moderate this page. Champions are requested and responsible for 695 adding information about projects for which they are a champion. 697 Anyone can edit the wiki by logging in using their datatracker login 698 credentials. Credentials can be obtained by requesting 699 (https://datatracker.ietf.org/accounts/create/) a new datatracker 700 account. 702 6.4.2. Lost and Found 704 A Lost and Found wiki page (e.g., 705 https://trac.ietf.org/trac/ietf/meeting/wiki/109hackathon/lost&found 706 (https://trac.ietf.org/trac/ietf/meeting/wiki/109hackathon/ 707 lost&found)) is created by the Chairs for each Hackathon. 708 Participants looking for a team are encouraged to add themselves to 709 the "Skills to Offer" table, providing some information about their 710 skills and interests. This will help others with matching needs and/ 711 or interests find them. Champions wanting help on their projects are 712 encouraged to add their teams to the "Skills Needed" table, providing 713 some information about the skills they seek. 715 6.4.3. Results Presentation Schedule 717 A Results Presentation Schedule wiki page (e.g., 718 https://trac.ietf.org/trac/ietf/meeting/wiki/109hackathon/ 719 resultspresentationschedule 720 (https://trac.ietf.org/trac/ietf/meeting/wiki/109hackathon/ 721 resultspresentationschedule)) is created by the Chairs for each 722 Hackathon. Hackathon teams are welcome and encouraged to present 723 their results during the Hackathon Closing. Hackathon teams add the 724 name of their project and the name of the presenter to the table at 725 the bottom of this page. 727 6.4.4. In Person Only 729 The following wiki pages are applicable for in-person Hackathons 730 only. 732 6.4.4.1. Hackdemo Happy Hour 734 A Hackdemo Happy Hour wiki page (e.g., 735 https://trac.ietf.org/trac/ietf/meeting/wiki/106hackdemo 736 (https://trac.ietf.org/trac/ietf/meeting/wiki/106hackdemo)) is 737 created by the Chairs for each Hackathon. Champions are welcome and 738 encouraged to add their project by entering the project name/acronym 739 and a contact name and email address in the table displayed on the 740 page. 742 6.4.4.2. Code Lounge 744 A Code Lounge wiki page (e.g., 745 https://trac.ietf.org/trac/ietf/meeting/wiki/106codelounge 746 (https://trac.ietf.org/trac/ietf/meeting/wiki/106codelounge)) is 747 created by the Chairs for each Hackathon. Champions are welcome and 748 encouraged to add their project by entering the project name/acronym 749 and a contact name and email address in the table displayed on the 750 page. 752 6.4.5. Online Only 754 The following wiki pages are applicable for online Hackathons only. 756 6.4.5.1. Team Schedule 758 A Team Schedule wiki page (e.g., 759 https://trac.ietf.org/trac/ietf/meeting/wiki/109hackathon/ 760 teamschedule 761 (https://trac.ietf.org/trac/ietf/meeting/wiki/109hackathon/ 762 teamschedule)) is created by the Chairs for each online only 763 Hackathon. Online only Hackathons take place globally for an entire 764 week. It is up to individual project teams to determine the 765 preferred dates, times, and ways to meet to work on their project 766 within the context of that week (e.g., Zoom, Webex, Slack). This 767 page is meant to help facilitate coordination of schedules within and 768 across teams. 770 6.5. Mailing List 772 The Hackathon mail list, hacakthon@ietf.org 773 (https://www.ietf.org/mailman/listinfo/Hackathon), is used for all 774 email communication and announcement related to the Hackathon. All 775 registrants and given the option to subscribe to the list. Anyone 776 interested in staying up to date on the Hackathon is able to 777 subscribe at any time. 779 6.5.1. Hackathon Chairs Email Alias 781 The email alias hackathon-chairs@ietf.org (mailto:hackathon- 782 chairs@ietf.org) was created and is maintained by the Secretariat. 783 It is used on hackathons webpages and wiki pages to provide a single 784 point of contact for the Hackathon. 786 6.6. GitHub 788 The IETF-Hackathon (https://github.com/ietf-hackathon) is used to 789 share code, presentations, and other artifacts at IETF Hackathons. 790 The Hackathon Chairs are responsible for administering the GitHub 791 org. 793 Code for Hackathon projects often exist elsewhere, which is perfectly 794 fine. Anyone needing a place to host code for the Hackathon can 795 request the creating of a repository for their project. 797 A repository is created and maintained by the Chairs for each 798 Hackathon (e.g., https://github.com/ietf-hackathon/ietf109-project- 799 presentations (https://github.com/ietf-hackathon/ietf109-project- 800 presentations)). This repo is for participants to upload project 801 presentations. The contents of this repo are used as the source for 802 all project presentations at the end of the Hackathon and remain as a 803 reference after the Hackathon. 805 6.7. Meetecho 807 Meetecho (https://www.meetecho.com/) is used for the kickoff and 808 closing sessions of the Hackathon. This provides many capabilities, 809 including the following: 811 * allows participants to join Hackathon sessions in person or 812 remotely 814 * validate registration of participants at time of joining Hackathon 815 sessions 817 * enable remote presentations of project results 819 * capture recording of Hackathon sessions 821 6.8. Network 823 Access to the IETF network is an important aspect of the Hackathon. 824 The IETF network provides unfettered Internet access that is not 825 typical within many residential, corporate, and university 826 environments. For many of IETF participants and projects, access to 827 the Internet and each other via wireless access to the IETF network 828 is sufficient. However, due to the nature of the work done in the 829 IETF, wired access and special networking capabilities are often 830 required. 832 The NOC has graciously met the needs of the Hackathon since its 833 inception and continues to add more capabilities over time. 834 Champions are able to request in advance wired access and special 835 networking functionality, including static IPv4 and IPv6 addresses, 836 IPv6 only networking, a closed user group, NAT64, and IPv6PD. All of 837 this, and the IETF network in general, is made available by the start 838 of the Hackathon and in advance for setup to the extent possible. 840 6.8.1. Remote Networking 842 Online only meetings present both a personal networking challenge and 843 a computer networking challenge. The NOC came to the rescue for the 844 latter with remote networking options to join the IETF network while 845 attending the meeting remotely. With a Raspberry Pi 2B, 3B, or 4B, 846 the NOC has a recipe that allow teams to be virtually connected to 847 the IETF network with all the previously mentioned options. This 848 remote networking capability is available for in-person and online 849 only Hackathons. 851 Virtual connectively to the IETF network remains generally available 852 between meetings. Individuals or project champions can request 853 access through the IETF Ticketing System 854 (https://tickets.meeting.ietf.org/newticket). 856 6.9. Webex 858 Champions can request a Webex account 859 (https://ietf.webex.com/webappng/sites/ietf/dashboard?siteurl=ietf) 860 they can use to schedule meetings for their team. These are similar 861 to the Webex accounts allocated to working group chairs to be used 862 for virtual interim meetings. An account can be requested by a team 863 champion at any time. Accounts remain active and available 864 throughout the duration of the Hackathon and the associated IETF 865 meeting. A project name may be used in place of "Working Group Name" 866 in the request form. 868 6.10. Gather 870 Gather (https://gather.town/) facilitates virtual hallway interaction 871 during IETF meetings. A dedicated area within the overall space is 872 created by the Secretariat for the Hackathon. The area includes 873 tables, identified by letters of the alphabet, that teams are free to 874 self assign and use as and when they like. Eight to ten seats around 875 each table facilitate group discussions within the team. A 876 whiteboard or shared notes tablet (via CodiMD) at tables facilitates 877 sharing of information within the team. The tables also facilitate 878 collaboration across teams. One cautionary note, Gather has relative 879 high network bandwidth and CPU requirements, and as such may not be 880 well suited for some Hackathon participants. 882 The Gather space remains available between IETF meetings, with 883 incremental improvements and additions made during this time. The 884 space is cleaned about a month prior to the start of the next 885 meeting, removing anything left over from the previous meeting. 886 Hackathon teams are encouraged to make a copy of anything they want 887 to retain within a week of the end of the IETF meeting. 889 7. Statistics and Metrics 891 Metrics have been captured for each Hackathon. Adding these metrics 892 is on the todo list. 894 7.1. IETF Survey Results 896 https://www.ietf.org/media/documents/survey-planning-possible-online- 897 meetings-responses.pdf 899 (From L-R: Very important, Important, Neutral, Not important, Not at 900 all important, Score (lower score is more important)) - Hackathon 901 6.73% 20.20% 40.65% 19.70% 12.72% 3.11 903 7.2. Hackathon Survey results 905 todo 907 8. Roles and Responsibilities 909 This section provides a summary of the roles and responsibilities of 910 individuals and groups involved in a successful IETF Hackathon. The 911 summary provided here is not meant to be exhaustive. Some 912 responsibilities are described entirely or in more detail throughout 913 the rest of the document. 915 8.1. Hackathon Chair(s) 917 The role of a Hackathon chair is similar to that of a working group 918 chair. As with working groups, it is typically best to have co- 919 chairs share responsibilities and workload. The Chairs work very 920 closely with the Secretariat on all responsibilities. Key 921 responsibilities include: 923 * Organize and deliver a Hackathon at each IETF meeting, soliciting 924 help from all other roles to do much of the heavy lifting 926 * Encourage and provide guidance to champions who volunteer to lead 927 projects 929 * Maintain the Hackathon wiki (e.g., 930 https://trac.ietf.org/trac/ietf/meeting/wiki/109hackathon 931 (https://trac.ietf.org/trac/ietf/meeting/wiki/109hackathon)) and 932 all of its child pages. 934 * Moderate Hackathon@ietf.org email list 936 * Request sessions for Hackathon opening and closing at IETF meeting 937 (i.e., https://datatracker.ietf.org/secr/sreq/ 938 (ttps://datatracker.ietf.org/secr/sreq/)) 940 * Emcee the Hackathon, including the opening and closing sessions 941 and announcements in between 943 * Create and manage the GitHub repo used for each Hackathon (e.g., 944 https://github.com/ietf-hackathon/ietf108-project-presentations 945 (https://github.com/ietf-hackathon/ietf108-project-presentations)) 947 * Main point of contact for all Hackathon questions and concerns 949 8.2. Secretariat 951 Key responsibilities include: 953 * Configure and manage Hackathon registration system 955 * Maintain Hackathon web page (https://www.ietf.org/how/runningcode/ 956 hackathons/) 958 * Create and maintain web page for each Hackathon (e.g., 959 https://www.ietf.org/how/runningcode/hackathons/109-hackathon/ 960 (https://www.ietf.org/how/runningcode/hackathons/109-hackathon/)) 962 * Create wiki page for each Hackathon (e.g., 963 https://trac.ietf.org/trac/ietf/meeting/wiki/109hackathon 964 (https://trac.ietf.org/trac/ietf/meeting/wiki/109hackathon)). 965 This is initialized and updated at times by the Secretariat, but 966 the Chair(s) are ultimately responsible for maintaining it. 968 * Handle venue logistics for Hackathon, Hackdemo Happy Hour, and 969 Code Lounge (e.g., reserve room, food and beverages, AV, etc.) 971 * Internal IETF promotion (e.g., email messages to community) 973 * Assist with external outreach, as needed, including finding 974 sponsors 976 8.3. Sponsor 978 Key responsibilities include: 980 * Provide some funding to help offset costs of Hackathon (either per 981 meeting or per year, depending on model) 983 * Optionally provide t-shirts or other giveaways 985 * Optionally provide support staff to assist with Hackathon 987 Key benefits include: 989 * Sponsor logo on Hackathon t-shirts 991 * Sponsor logo on Hackathon signage 993 * Sponsor logo on Hackathon webpage and wiki 995 * Sponsor logo and call out in Hackathon kickoff and closing 996 presentation 998 * Sponsor logo and call out in IETF Plenary presentation 1000 * Sponsor logo and call out in Hackathon recap on IETF blog 1001 (https://www.ietf.org/blog/) 1003 * Recognition in IETF community for helping the IETF Hackathon 1004 remain free and open to everyone 1006 8.4. Champions of Projects 1008 Champions of projects are the key to a successful Hackathon. Key 1009 responsibilities for champions include: 1011 * Volunteer to lead a project at the Hackathon 1013 * Serve as primary contact for the project 1015 * Add and manage information on the Hackathon wiki for the project 1017 * Promote the project to appropriate groups inside IETF and outside 1018 as well 1020 * Welcome and organize members of the team 1022 * Provide focus, guidance, and leadership for the project 1024 8.5. IETF LLC, Director of Communications and Operations (was ISOC) 1026 Key responsibilities include: 1028 * External (outside world) promotion 1030 * Outreach to local universities 1032 * Provide photographer 1034 * Laptop stickers 1036 8.6. Judges 1038 The first several Hackathon involved judges who listened to summary 1039 presentations by teams at the closing of each Hackathon and 1040 identified winning teams for an arbitrary number of project 1041 categories. Prizes were made available to members of winning teams. 1042 This was done as an incentive to participate in the Hackathon and 1043 present results, and to provide a fun yet informative end to the 1044 Hackathon that could be appreciated by the entire IETF community. 1045 Judging and awarding of prizes led to confusion regarding the nature 1046 of the Hackathon, making it appear to some overly competitive. 1047 Procurement of appropriate prizes was financially and logistically 1048 challenging. Arrangement of judges, determination of winners, and 1049 awarding of prizes all became more time consuming, especially as the 1050 number of projects and participants grew. Ultimately, it was deemed 1051 best to eliminate judging, awards, and prizes entirely. Apparently 1052 the IETF community has an innate incentive to participate and present 1053 results in the Hackathon. 1055 9. Security Considerations 1057 None. 1059 9.1. Privacy Considerations 1061 Participant names and email addresses are displayed publicly in the 1062 Attendee List (Section 6.3.1). Participants may opt-in or opt-out of 1063 the display of their email address as part of their registration. 1065 The email addresses of individual champions are often shared publicly 1066 by the champions on the wiki. This is done voluntarily by individual 1067 champions to make it easier for others to contact them. 1069 10. IANA Considerations 1071 This document has no IANA actions. 1073 11. Normative References 1075 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1076 Requirement Levels", BCP 14, RFC 2119, 1077 DOI 10.17487/RFC2119, March 1997, 1078 . 1080 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1081 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1082 May 2017, . 1084 Acknowledgments 1086 Michael Richardson and Benson Muite provided valuable contributions 1087 to this document. 1089 Author's Address 1091 Charles Eckel 1092 Cisco Systems 1094 Email: eckelcu@cisco.com