Subject: [Manycouches] FW: New Version Notification for draft-eckel-shmoo-ietf-hackathon-00.txt

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 4 Nov 2020 17:46:41 +0000

Hi all,

I posted draft-eckel-shmoo-ietf-hackathon (announcement below). This draft is an attempt to capture the set of practices for running IETF Hackathons. There are subsections that address practices that are altered or specific to online only IETF Hackathons.  The upcoming IETF 109 Hackathon is only our second experience with running a hackathon online.  While the online aspects are expected to be of most interest to this group, feedback on the entire draft is welcome and greatly appreciated.

Cheers,
Charles

On 11/4/20, 7:15 AM, "[email-masked]" <[email-masked]> wrote:

    A new version of I-D, draft-eckel-shmoo-ietf-hackathon-00.txt
    has been successfully submitted by Charles Eckel and posted to the
    IETF repository.

    Name:		draft-eckel-shmoo-ietf-hackathon
    Revision:	00
    Title:		Running an IETF Hackathon
    Document date:	2020-11-02
    Group:		Individual Submission
    Pages:		21
    URL:            https://www.ietf.org/archive/id/draft-eckel-shmoo-ietf-hackathon-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-eckel-shmoo-ietf-hackathon/
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-eckel-shmoo-ietf-hackathon
    Htmlized:       https://tools.ietf.org/html/draft-eckel-shmoo-ietf-hackathon-00

    Abstract:
       IETF Hackathons encourage developers to collaborate and develop
       utilities, ideas, sample code and solutions that show practical
       implementations of IETF standards.  This document provides a set of
       practices for running IETF Hackathons.

    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.

    The IETF Secretariat

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Nov 2020 15:10:08 -0500

Charles Eckel \(eckelcu\) <eckelcu=[email-masked]> wrote:
    > I posted draft-eckel-shmoo-ietf-hackathon (announcement below). This
    > draft is an attempt to capture the set of practices for running IETF
    > Hackathons. There are subsections that address practices that are

Thank you for this document!

I don't know if you cribbed from some other non-virtual Hackathon description
in preparing this.  The non-virtual Hackathon description is really priceless.

I did not participate in the IETF108 week-long Hackathon for a variety of
reasons, but I intend to try to participate in 109.
So I really can't comment on the virtual aspects which are explained.

I think that there are some missing aspects in your write up.
(Or perhaps things that you don't want to trumpet to sponsors)

Some portion of attendees to the hackathon are what I'll call "soft"
participants:  WG-chairs, document-authors, and other people don't
have machine-executable code they are working on.

I say "machine-executable" code, because in many cases they are working on
IETF documents (human-executable code...), on test cases, on tooling for the
test cases, or are just sitting at table trying to bring on consensus.
A document author who sits with a person writing code gets a lot of feedback
on their document.
I don't think that the above benefit is really captured in your document
as a key return.
Unfortunately, the above pieces are what is mostly lost in virtual events.

Due to the Hackathon, many people arrange to arrive Friday (or sometimes very
early Saturday morning as flights permit).  They then force themselves to
stay up Saturday during the hackathon as part of an effort to adjust their
time zone to the local time zone.
The group dynamic plus availability of low-cost caffeine and sugar is key.
Many people spend 1/2 of Saturday simply catching up on colleagues, preparing
and/or reviewer slides they are preparing at the "last minute", etc.

I think that this is also a key *socialization* benefit of the Hackathon.
Again, I don't know if this can be explained, or should be explained in
detail to sponsors.

I spend twenty minutes yesterday deciding, based upon Hackathon MUD-table
doodle how I was going to adjust my clock for IETF109... am I getting up
really early for IETF109, or staying up really late?  Is IETF109 at the
beginning of my day, or the end of my day?  I decided it was going to be at
the end of my day, so I'll be sleeping while the kid is at school.

What does this mean for the Hackathon?
Well, it affects what hours I'll be online next week during the Hackathon.
I'll be staying up later and later each day, using the Hackathon to help me
deal with the "jetlag"

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 5 Nov 2020 16:01:21 +0000

On 11/4/20, 12:10 PM, "Michael Richardson" <[email-masked]> wrote:

You bet. Thanks for taking a look.

Thanks. I pulled information primarily from notes created while preparing for previous IETF Hackathons and blog post summaries that followed each one.

Those sections are a bit challenging. As an IETF community, we have IETF 107 as an aborted attempt at an online Hackathon and IETF 108 as what I would categorize as a relatively successful first online Hackathon. The IETF 109 Hackathon should help a great deal, and hopefully in terms of what worked well more so than what did not. The draft needs to do a better job of highlighting things from online Hackathons that can and should be used to improve the experience of remote participants at in-person Hackathons.

Great point. This needs to be added.

Another great point. My impression is Hackathon sponsors are interested in the overall success of the IETF, so I expect they would value these benefits you highlight as well.

This is a tough one and much worse for online Hackathons. The thought process and constraints are likely very different for Hackathon participants and even within individual Hackathon teams. The use of a doodle poll seems a good idea to help teams arrive at optimal, or at least good decisions for the team. 

Thanks again!
Charles