Running an IETF Hackathon
draft-ietf-shmoo-hackathon-08

[Ballot comment]
I feel like I have to squint a bit to see how this fits into the SHMOO charter, as it reads more like a general guide to running Hackathons than it does to something specific to online-only events.  Only Section 2.5 really talks about the "Meet Online Only" part of SHMOO.

[Ballot comment]
# Éric Vyncke, INT AD, comments for draft-ietf-shmoo-hackathon-07
CC @evyncke

Thank you for the work put into this document. A very nice and useful pre-meeting event.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Mallory Knodel for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Section 1

Can the text be a little softened:
```
  Code written in a
  programming language can be more illustrative and less
  confrontational than opinions expressed during a meeting or in an
  email.
```

### Section 3.1

```
  Consequently, the IETF
  decided to fund the Hackathon as part of the IETF meeting, with
  Hackathon sponsorship being on a best effort basis.
```
"IETF" or "IETF LLC" ?

### Section 3.2

Should the cost of small prizes/awards (symbolic of course but there were there at the beginning) and the cost of NOC people having to arrive earlier (my guess) be included in the cost ?

### Section 5.1

The navigation is rather Groups -> Other -> Active Teams

### Section 5.3.2

I hope that there is still a cap, even if only to comply with fire department regulations ;-)

### Section 7.1

Learned a new word "Emcee", assuming it is acting as Maître de Cérémonie ;-)

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
** Section 1.  Per the opening paragraph, isn’t a goal of the Hackathon also verification and validation of in-flight IETF work?  Reference implementations to foster adoption of IETF work?

** Section 1.

      Bring developers and young people into IETF and get them exposed
      to and interested in the IETF

Consider “students”, “early career professionals” or “newcomers” instead of or in addition to “young people.”

** Section 1.
  Similarly, while the Hackathon is meant to
  attract newcomers and those who do not typically view themselves as
  standards people,

Who are “standards people”?

** Section 1.
  Group dynamics and blending of skill sets
  and perspectives are extremely valuable aspects of IETF Hackathons.

Per “Group dynamics … are extremely valuable …”, can the phrase “group dynamics” be more specific.  Which dynamics is the hackathon trying to foster?

** Section 1.
  Examples include, but are
  not limited to, interoperability of implementations, proof of
  concepts, and tools.

What is a “tool” if not a proof of concept?  Is this tooling to support the standards development process?

** Section 2.2.  Editorial.
  Initially, we did something similar as part of Bits and Bites

-- The voice in the sentence changed to first-person plural (we).

-- Is there more context to provide on Bits and Bites for those that might not be familiar.

** Section 2.3
  Champions are encouraged to look at the final agenda and determine
  time slots best suited to ensure attendance of Code Lounge sessions
  as well as any related working group sessions. 

The idea of “Code Lounge session” and the “Code Lounge” being open continuously would benefit from an explanation. Is there an expectation that the champion is scheduling things during IETF week?  I don’t see this scheduling in the roles and responsibilities section.

** Section 2.4.  Editorial.
  The IETF [CODE-SPRINT] develops tools that support the work of the
  IETF. The Code Sprint existed ...

Using [CODE-SPRINT] after “IETF” is an odd place to put the reference.  Recommend putting it after “Code Sprint” in the second sentence.

** Section 9.1. An additional privacy consideration is the photography described in Section 7.5.  Perhaps mention the lanyard system to opt-out.

[Ballot comment]
Thanks for this interesting document.

Minor:

1. In §5.1,

  Team.  From the Datatracker menu, navigate to "Other" -> "Active
  Teams" -> "Hackathon".  Here exists a Datatracker space for the

But when I look at the Datatracker "Other" menu, there's nothing about teams. I did eventually find it under "Groups" -> "Other" -> "Active Teams" -> "hackathon" (in lower case :-) So in short, "Groups" was missing at the beginning of the path.

Nits:

2. In §2.1,

                                          As the IETF Hackathon serves
  as the start of the overall IETF meeting, we aim to strike a
  compromise that provides enjoy time to get valuable work accomplished
  without exhausting themselves before the main IETF meeting even
  starts.
 
There's something broken in this sentence but I can't quite make out what it is. Maybe "enjoy" is supposed to be "everybody"?

3. Again in §2.1,

  and participants time to socialize and learn more about projects and
  team they might want to join.  The kickoff presentation and
  formalities are kept to minimum to leave as much time as possible for
  team to work together with their team on their projects.  The

s/team/teams/g (I guess, although that's a lot of "teams" in a row -- maybe the middle "team" is actually "them"?)

4. In §2.5,

  most convenient for them.  The kickoff and closing sessions were
  schedule to align with the time frame established for the IETF 108

s/schedule/scheduled/

[Ballot comment]
Thanks for this interesting document.

Minor:

1. In §5.1,

  Team.  From the Datatracker menu, navigate to "Other" -> "Active
  Teams" -> "Hackathon".  Here exists a Datatracker space for the

But when I look at the Datatracker "Other" menu, there's nothing about teams. I did eventually find it under "Groups" -> "Other" -> "Active Teams" -> "hackathon" (in lower case :-)

Nits:

2. In §2.1,

                                          As the IETF Hackathon serves
  as the start of the overall IETF meeting, we aim to strike a
  compromise that provides enjoy time to get valuable work accomplished
  without exhausting themselves before the main IETF meeting even
  starts.
 
There's something broken in this sentence but I can't quite make out what it is. Maybe "enjoy" is supposed to be "everybody"?

3. Again in §2.1,

  and participants time to socialize and learn more about projects and
  team they might want to join.  The kickoff presentation and
  formalities are kept to minimum to leave as much time as possible for
  team to work together with their team on their projects.  The

s/team/teams/g (I guess, although that's a lot of "teams" in a row -- maybe the middle "team" is actually "them"?)

4. In §2.5,

  most convenient for them.  The kickoff and closing sessions were
  schedule to align with the time frame established for the IETF 108

s/schedule/scheduled/

[Ballot comment]
# Internet AD comments for {draft-ietf-shmoo-hackathon-07}
CC @ekline

## Comments

### S5.8

* Consider expanding "IPv6 PD" to "IPv6 Prefix Delegation".

## Nits

### S1

* "who are not necessary developers" -> "who are not necessarily developers"

### S2.1

* "learn more about projects and team"
  -> "learn more about projects and the team", or
    "learn more about projects and teams", perhaps

[Ballot comment]

The link to the "Running Code Sponsors" is out of date -- this is the right one: https://www.ietf.org/support-us/sponsorship/#running-code

I didn't check other links, but it would be a good idea to do so.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-shmoo-hackathon-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-06-23):

From: The IESG
To: IETF-Announce
CC: draft-ietf-shmoo-hackathon@ietf.org, lars@eggert.org, manycouches@ietf.org, mknodel@cdt.org, shmoo-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Running an IETF Hackathon) to Informational RFC

The IESG has received a request from the Stay Home Meet Occasionally Online
WG (shmoo) to consider the following document: - 'Running an IETF Hackathon'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-06-23. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

  IETF Hackathons encourage the IETF community to collaborate on
  running code related to existing and evolving Internet standards.
  This document provides a set of practices that have been used for
  running IETF Hackathons.  These practices apply to Hackathons in
  which both in-person and remote participation are possible with
  adaptations for Hackathons that are online only.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-shmoo-hackathon/

No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is intended to become an Informational RFC. It documents the experiences and the practices followed of running the IETF hackathon at IETF 108 onwards after recovering from a cancelled hackathon at IETF 107 due to the late move to a virtual meeting. Hence Informational seems to be the right classification for this.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

IETF Hackathons encourage the IETF community to collaborate on running code related to existing and evolving Internet standards. This document provides a set of practices that have been used for running IETF Hackathons. These practices apply to Hackathons in which both in-person and remote participation are possible with adaptations for Hackathons that are online only.

Working Group Summary:

The document was presented to shmoo early in the WG lifecycle where there was discussion on whether an RFC was the right mechanism to capture these experiences and practices and there was widespread agreement in the WG that it was. There was a lot of feedback on the draft both prior to its adoption as WG item as well as after. All issues brought up on the draft were tracked using an issue tracker on github and the shepherd has confirmed that these have been addressed in the latest version of the draft.

Document Quality:

The document has been presented several times to the working group and all the feedback received has been addressed in the latest revision. The document has received significant review from the WG before and after adoption and also during working group last call.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Mallory Knodel is the Document Shepherd. Lars Eggert is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Charles has clearly documented the tried and true formula for the IETF Hackathon and it's a privilege to have this excellent work documented in the shmoo working group. It is within scope of the shmoo charter for the critical elements of remote participation in all meetings, including appropriate considerations for those that are online only. My review was for consistency of documentation only and to ensure there were no questions, gaps or confusing information. Charles has addressed all issues both on the list and in Github, and incorporated all PRs. With these minor changes, the document is certainly ready to progress towards publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. Both of the WG chairs have reviewed multiple versions of the draft and are comfortable with the level of review this draft has received till date.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is solid WG consensus behind this document. A large number of WG participants have expressed support for this draft and there has been no opposition to it progressing.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are no nits, warnings or errors identified by idnits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes. The document only has Informative references.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

There are no IANA actions required.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are no IANA actions required.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is intended to become an Informational RFC. It documents the experiences and the practices followed of running the IETF hackathon at IETF 108 onwards after recovering from a cancelled hackathon at IETF 107 due to the late move to a virtual meeting. Hence Informational seems to be the right classification for this.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

IETF Hackathons encourage the IETF community to collaborate on running code related to existing and evolving Internet standards. This document provides a set of practices that have been used for running IETF Hackathons. These practices apply to Hackathons in which both in-person and remote participation are possible with adaptations for Hackathons that are online only.

Working Group Summary:

The document was presented to shmoo early in the WG lifecycle where there was discussion on whether an RFC was the right mechanism to capture these experiences and practices and there was widespread agreement in the WG that it was. There was a lot of feedback on the draft both prior to its adoption as WG item as well as after. All issues brought up on the draft were tracked using an issue tracker on github and the shepherd has confirmed that these have been addressed in the latest version of the draft.

Document Quality:

The document has been presented several times to the working group and all the feedback received has been addressed in the latest revision. The document has received significant review from the WG before and after adoption and also during working group last call.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Mallory Knodel is the Document Shepherd. Lars Eggert is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Charles has clearly documented the tried and true formula for the IETF Hackathon and it's a privilege to have this excellent work documented in the shmoo working group. It is within scope of the shmoo charter for the critical elements of remote participation in all meetings, including appropriate considerations for those that are online only. My review was for consistency of documentation only and to ensure there were no questions, gaps or confusing information. Charles has addressed all issues both on the list and in Github, and incorporated all PRs. With these minor changes, the document is certainly ready to progress towards publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. Both of the WG chairs have reviewed multiple versions of the draft and are comfortable with the level of review this draft has received till date.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is solid WG consensus behind this document. A large number of WG participants have expressed support for this draft and there has been no opposition to it progressing.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are no nits, warnings or errors identified by idnits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes. The document only has Informative references.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

There are no IANA actions required.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are no IANA actions required.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is intended to become an Informational RFC. It documents the experiences and the practices followed of running the IETF hackathon at IETF 108 onwards after recovering from a cancelled hackathon at IETF 107 due to the late move to a virtual meeting. Hence Informational seems to be the right classification for this.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

IETF Hackathons encourage the IETF community to collaborate on running code related to existing and evolving Internet standards. This document provides a set of practices that have been used for running IETF Hackathons. These practices apply to Hackathons in which both in-person and remote participation are possible with adaptations for Hackathons that are online only.

Working Group Summary:

The document was presented to shmoo early in the WG lifecycle where there was discussion on whether an RFC was the right mechanism to capture these experiences and practices and there was widespread agreement in the WG that it was. There was a lot of feedback on the draft both prior to its adoption as WG item as well as after. All issues brought up on the draft were tracked using an issue tracker on github and the shepherd has confirmed that these have been addressed in the latest version of the draft.

Document Quality:

The document has been presented several times to the working group and all the feedback received has been addressed in the latest revision. The document has received significant review from the WG before and after adoption and also during working group last call.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Mallory Knodel is the Document Shepherd. Lars Eggert is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Charles has clearly documented the tried and true formula for the IETF Hackathon and it's a privilege to have this excellent work documented in the shmoo working group. It is within scope of the shmoo charter for the critical elements of remote participation in all meetings, including appropriate considerations for those that are online only. My review was for consistency of documentation only and to ensure there were no questions, gaps or confusing information. Charles has addressed all issues both on the list and in Github, and incorporated all PRs. With these minor changes, the document is certainly ready to progress towards publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. Both of the WG chairs have reviewed multiple versions of the draft and are comfortable with the level of review this draft has received till date.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?



(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is solid WG consensus behind this document. A large number of WG participants have expressed support for this draft and there has been no opposition to it progressing.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are no nits, warnings or errors identified by idnits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes. The document only has Informative references.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

There are no IANA actions required.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are no IANA actions required.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is intended to become an Informational RFC. It documents the experiences and the practices followed of running the IETF hackathon at IETF 108 onwards after recovering from a cancelled hackathon at IETF 107 due to the late move to a virtual meeting. Hence Informational seems to be the right classification for this.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

IETF Hackathons encourage the IETF community to collaborate on running code related to existing and evolving Internet standards. This document provides a set of practices that have been used for running IETF Hackathons. These practices apply to Hackathons in which both in-person and remote participation are possible with adaptations for Hackathons that are online only.

Working Group Summary:

The document was presented to shmoo early in the WG lifecycle where there was discussion on whether an RFC was the right mechanism to capture these experiences and practices and there was widespread agreement in the WG that it was. There was a lot of feedback on the draft both prior to its adoption as WG item as well as after. All issues brought up on the draft were tracked using an issue tracker on github and the shepherd has confirmed that these have been addressed in the latest version of the draft.

Document Quality:

The document has been presented several times to the working group and all the feedback received has been addressed in the latest revision. The document has received significant review from the WG before and after adoption and also during working group last call.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Mallory Knodel is the Document Shepherd. Lars Eggert is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.



(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. Both of the WG chairs have reviewed multiple versions of the draft and are comfortable with the level of review this draft has received till date.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?



(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is solid WG consensus behind this document. A large number of WG participants have expressed support for this draft and there has been no opposition to it progressing.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are no nits, warnings or errors identified by idnits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes. The document only has Informative references.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

There are no IANA actions required.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are no IANA actions required.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A