[Ietf-and-github] Meeting minutes from IETF 104

Christopher Wood <christopherwood07@gmail.com> Mon, 01 April 2019 12:49 UTC

MIME-Version: 1.0
From: Christopher Wood <christopherwood07@gmail.com>
Date: Mon, 01 Apr 2019 05:49:09 -0700
Message-ID: <CAO8oSXm7nP=L9Q8TJotwpJFXJ1N7zyzWZKvhWmkxFUDrL9xoEw@mail.gmail.com>
To: ietf-and-github@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-and-github/UiOvdiRp24RMqQMerjNDSoX4VAk>
Subject: [Ietf-and-github] Meeting minutes from IETF 104
Precedence: list

Minutes from last week's GIT meeting in Prague are now online [1].
They're also copied at the end of this message. Please have a look and
send any issues to the list.

Thanks to Matt Miller for taking notes!

Thanks,
Chris

[1] https://datatracker.ietf.org/doc/minutes-104-git/

----

2019-03-28 @ 11:50-12:20 CET
Congress Hall 3 (LL)

## Administrivia

### Do we want to use GitHub?

* "duh"
* Keep (as best as possible) substantive discussion on the mailing list

### WG Tools and Projects

* What other tools would help WGs?

  - Wiki for capturing ideas and info
  - We should document existing tools to improve understanding their use
  - We should document the entire process to improve understanding
their integration
  - Many in room willing to help improve and maintain documentation

## GitHub Configuration for IETF Working Groups

* Need resolve duplication between this document and
draft-thomson-git-using-github.

## Using GitHub in the IETF

* Worth documenting details with the time that it was valid
* Some discussion in the document for how to evolve would be useful

* How to deal with these drafts and changes in tooling / processes
  - This can document the guidelines that WGs maintain their details
  - Find a way to conceptually separate the static pieces from those
that are dynamic
  - This document can remain an I-D
  - There are efforts in IESG to define living documents

* Is there a good sense of normative vs. informative?
  - Having a higher level (normative?) document and keep more concrete
information here

* On advice on consensus (on how and when processes are put in place)
  - Note that having an issue does not mean it must be discussed in
the working group
  - Issues do not reflect the consensus of the working group
  - (QUIC started using project boards to help evolve processes)
  - If splitting "light vs heavy" description, then move this advice
to the "heavy"
  - Keeping this information can be useful to newcomers to a WG and is
helpful for newly forming or new-to-GitHub WGs

* **Adoption of this document?** -- consensus in room to adopt, and
chairs will confirm on the list
  - Note that the document can change radically
  - Change "heavy" to note it is an option
  - Chairs will take this to <wgchairs@ietf.org> for their contributions

* **Volunteers to co-author?**
  - Chairs will solicit for volunteers to co-author
  - Mike Bishop offered to help

* Suggested next step is to break out the concrete actions make sense
  - If valuable, progress both this document and an update to BCP 25
  - Charter states that "not changing existing processes [BCP 9]",
while the discussion is about adding to the processes
  - Actual changes to processes is not within scope for this working group

[Ietf-and-github] Meeting minutes from IETF 104 Christopher Wood