WUGH BoF
IETF 103, Bangkok
Wednesday November 7, 2018
BoF chair: Paul Hoffman
Notetaker: David Lawrence
(Not taking notes on slide presentations, just on the mic line)


Alissa Cooper presented "GitHub Configuration for IETF Working Groups" slides.
	https://datatracker.ietf.org/meeting/103/materials/slides-103-wugh-github-configuration-for-ietf-working-groups-00

Aaron Falk: Can you clarify what the difference is between owners and administrators?

Alissa: My understanding is owners can add other collaborators, including appointing administrators, but administrators can't.

Cullen Jennings: It might be easier to have just one organization for all the ietf rather than per working group.  It should be as easy to get a repo as it is to publish a draft.

ekr: I think one org per wg works better for reporting.
    
Brett Jordan: One per WG does work.  My concern is that there's a barrier to entry to using GitHub.  Working groups are already a bit hostile to newcomers, without this additional hurdle.  GitHub is great if you know how to use it, but the simple tooling isn't there for newcomers.

Alissa: The intent isn't to make people use this, but have a consistent approach for those who want to.

Martin Thompson: I agree to ekr.  Cullen's suggestion was interesting, but this per-wg conclusion is what I arrived at too.  Useful to keep wg autonomy.  Yes, some of these things would be easier to do if it were all bundled together, but probably what we should do is concentrate on improving tooling.

Mark Nottingham: Please please please don't put it all in one org.  Also, we could collect better metadata for use by datatracker.

Cullen: I'm fine with it being multiple orgs.  I do think that some people speaking to per-wg have reflected some lack of knowledge of how GitHub works.  I think we're all aiming to the same goal to have it be low-friction to get going with a repo.

Martin: Want to avoid having a lot of bespoke tooling on top of this; this is probably the right level proposed here.  We probably want to keep datatracker linkage really loose.  The repo should inform the datatracker rather than the other way around.

Alissa: Yes, I was thinking that the datatracker integration to get things initiated was useful, and then the repo could inform the tracker.

ekr: I support the idea of being able to push a button to set things up, as long as people still have the option to do it manually if they prefer

Joel Halpern: I have concern that the current IETF policy that wg business is conducted on the mailing list.  Weekly github digest notifications, or individually tracking GitHub directly, as being the main way of staying on top of discussion would be a real problem.

Brett: I have a lot of experience doing this in other orgs and am willing to help.  We just need to make it really clear for people coming in how things are done.

Chris Lemmons: The wg I work with uses GitHub and the mailing list, but really inconsistently.  People end up feeling like their feedback is not being paid attention to because they are looking in the wrong place.  The WG needs to spell out the expecations for interaction.

Mark: In http and quic we spent a considerable amount of time figuring this out, so I am happy to lay out our experience.  Regarding the mailing list issue, that I've had very similar feedback from the other side, that developers can't invest time in the mailing list and working the GitHub flow is much better for them.

Dan York: It is quite confusing to be able to track the thread of a discussion through GitHub isssues and pull requests. 

Jon Klensin:  Admittedly I'm an old fuddy-duddy, but even with all the problems of IETF wg lists, I've never found W3Cs use of GitHub to be better.  We need to make it easier for people to be able to casually follow discussion, and GitHub doesn't help.  Share Joel's concerns.

Harald Alvestrand: Automatic GitHub notification to the list is helpful, alerts you to when something happened you need to pay attention to.  Not necessarily great, but better than not having it.

Yuri ?: As a wg chair I would be more than happy to make use of this, but as an author of an IPv6-only draft I would be ashamed to put it into an IPv4-only system.

Rich Salz: I don't think GitHub is necessarily better or worse, but it is different.  As we look at the dropping IETF participation dropping, we should consider whether this is an opportunity to develop more interest in the IETF.

?: It would also be useful if this tooling could be used to create a draft repository in your own (non-ietf) org before wg adoption

Martin:  That's pretty straightforward.

Cullen: Right, as long as you can keep track of the issues and other previous history, but there are about five different views on how to make it work

Dan York: I would like a better understanding how to move my own stuff into wg stuff.  [Martin shows him.]  Oh look at that, okay.  We need to make this clear for everyone though.

Martin: [discussion of some of his tooling for backups / history]

Aaron: Have an agenda bash ... but I'll wait

Mark: Would you archive the repos?  In the GitHub sense, where it becomes just historical with no more input?

Aaron: In my wg there are some people using private repos to work on wg docs.  I've been watching it, but I am a novice github user.  I'm sensitive to the issue of people to be able see what issues are being discussed but not on the list, particularly for people who aren't deep into the working group

ekr: It is true that it can be hard to follow discussion on either github or on the list.  A bit part of the problem is just volume, and it's true that github can exacerbate this.  That does benefit transparency but at the cost of traffic.  

Alissa: This has been really helpful, Paul and I will take it back to revise the draft and look specifically at how to help with tooling and newcomers.


Martin presenting "WGs Using GitHub"
	https://datatracker.ietf.org/meeting/103/materials/slides-103-wugh-using-github-at-the-ietf-00

Dan York: When you're talking about labels, you mean for the issues?

Martin:  Yes, we're up to almost 2000 issues now in quic, and have relied heavily on labels for managing them.

Paul:  I could see both lightweight and heavyweight policies regarding labels, depending on the group.  Some groups just don't need them, others die without them.

Brett: Agree with Paul, seems like a group-dependent thing.  For some groups though the consistency in use would be a big win particularly for people coming in.

Rich Salz:  I just copied what Martin did, that goes along from wg to wg.  Don't get hung up on the labels, very easy to modify.

Mark: Agree on that.  We've refined over time and that's fine.  (Gave some counts on label use for http and quic, and pointed out one for quick is "unicorns!!")

Brett: No matter which system you use at some point the discussion just gets to be too much to track for anyone not directly participating, and the outcome should just be summarized back to the list by the chairs.

Martin: To that point, if the chairs have to do that job it means the editors are failing.  It shouldn't fall on the chairs.

Brett: There is a potential conflict of interest though in that the editors likely have a bias and the chair should be a more impartial third party.

Ben Kaduk: You can use "show outdated comments" for review.

Martin: and you can turn comments into an issue.

Mark: We have a rule for "no discussion on pull requests", which you can't technically prevent but make it a cultural behaviour.  I wish we had tooling that would take the github history to summarize all the changes that happened for a new draft.

Martin: Working on tooling for that.  Almost there.

Mark: In terms of concensus we've had an interesting evolution here.  We used to have a concensus flag on all issues but it was cumbersome.  Now we only use it for the most highy contentious issues to flag that we finally reached consensus.

Martin:  Right, we don't consider a closed issue to necessarily reflect consensus.  If it needs to be reopened, reopen it

Dan: Definitely want to be able to leverage the ability to convert pull request comments into issues.  As for formats, on mine I keep the converted output in my repo so people can easily keep it, need examples for others of how to do that.

John Klensin: Archiving of all official interactions is important

Fred Baker: Will be working on setting up an IETF-specific github, one we run?

Martin: No, that would lose a significant benefit of the people participating in the main github.

Alissa: Just to clarify you want a wg to develop policies?

Martin: Yes, to develop consensus on them in the way the IETF typically does

ekr: Yes, we need to do some work and publish some documents on it, so use the mechanisms we have as clunky as they are

Adam Roach: If we're developing a tool list, I heard a desire for better training on GitHub in general and your tools around it.  Please do a EDU on it.

?: Has anyone thought to ask the Tools Team what they think of this all?

Robert Sparks (on the Tools Team): Yes, we're paying attention.

Brett: Support a wg on this, and hope we produce really crisp, clear documention on it

Dan: +1 to that.  I'd hope we'd get into providing guidance on the finer details like tagging and such.  Our tools need to be accessible to people who are less savvy.  How to we give people the tools they're used to in datatracker, like diffs.

Mark: To the education question, Martin's tools are amazing in their capability but fall down in documentation, and I'm willing to help out there.

Paul: Yes, since you're a wg chair that's been using them, please do and draft whatever experienced wg participants you can to help.

Mark: I'm wary of adding requirements to these documents.  Should be focused on general advice.  Chosing document names or tags is probabky too much.

Jonathan: Need more advice around the end of document lifetimes, particularly to indicate it really is done and is not accepting more changes.

Neil ?: Alissa's draft says something about SHOULD backup issues via API but probably should say MUST.

Paul: Yes I just didn't try the API.

Dan: Maybe we need to say "just use Martin's tools"?

Martin: Jonathan's right, we need something to mark the end of lifecycle, but also it can be useful to get feedback on documents that are done.  I just got one on an old doc that was really useful.  

Tale: Pointers to errata submission might help too.

Mark: +1 to Martin.  In http we welcome feedback on published docs.  People currently abusing errata system for that.

Alissa: Fully agree with Mark on the after-publication bit.  Don't agree with him on not providing guidance on things like doc names and tags and such.  The conventions would be really useful to explore.  We didn't think maybe this wouldn't be wg forming because of lack of discussion online in advance, but really happy to see so much discussion here, and a wg seems appropriate