Minutes IETF103: wugh
minutes-103-wugh-00

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