Subject: rough notes from working group chairs training on git (4 November 2015)

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 4 Nov 2015 06:39:39 +0000

Below are some rough notes from today’s working group chairs training.
Comments/discussion welcome.

GitHub WG Chairs Training @ IETF 94
Wednesday 4 November 2015, 1145 - 1245 JST

Presenters: Richard Barnes and Martin Thomson
Slides: https://www.ietf.org/proceedings/94/slides/slides-94-edu-wglunch-7.pdf

Questions:

Paul Hoffman: Interacting with the working group through these tools is going to require a github account.

Mike Richardson: Small correction, you can interact with github without a github account, but you need to know what you are doing, and it has some impact on the editors who then have to do something additional.

Alia: It is probably a good idea to have the organization also owned by the AD. That has been the case for some working groups and not others. This is something that could be addressed by guidelines for github usage for a working group.

Natasha: Does there need to be a naming convention for individual repositories? Seems like that would be helpful.

Richard: I don’t feel there needs to be a naming convention. The underlying issue is discoverability. Currently it is the discretion working group chairs.

Assuming a WG has a repository. Can I move from my personal repository to the working group repository. There isn’t currently a good way to do this. Also, issues don’t transfer over.

Forks are a bad idea. If you delete the original, in some cases you can lose the fork.
Maintaining issues across the move is the issue.

Another source of confusion (beyond those listed on the slide) is trac. Question about choosing tools for the working group and maintaining transparency.
Justin: Github is a better way to manage issues than trac.
Richard: There is some benefit to using github for issues because it ties pull requests to the issues.
If you use trac you are guaranteed to archive the history of issues.
IETF could create rules about how to manage that history.
Rich Salz: You can pull down the issues automatically using a Github API.
ACTION: Need to follow up on how to capture artifacts especially at key milestones.

IPR Notices: There is and ongoing discussion (somewhere?) about what the right thing to put on the page wrt IPR. There is a draft working its way through and there will be some guidance forthcoming. Some existing working groups have done a good job of organizing this information. httpbis is running an experiment on how to use github and may not be the best example to follow (because it is experimental).

Michael Richardson: I think there needs to be more process around this.
Trac sends issue to mailing list. What is the github equivalent?
You can interact with github issues with email. It does bad things with quoting, and I wouldn’t recommend it.
http2 used a simple system of labels

Paul Hoffman: github does bring in new contributors, but often these contributions don’t contribute back to the mailing list, puts a lot more work/responsibility on the wg chairs to maintain this connectivity and transparency.

What is the workflow of the documents that are being maintained in github?

The http working group experiment has set up a separate mailing list for the working group that receives notifications from the github repository. The problem is it gets pretty spammy, and we need to be careful about that.

Dave Thayler: There is an issue similar to the trac confusion. Which copy of the document should be discussed on the list or reviewed (in particular by external reviewers)? If it is the git hub version, we have a consistency issue, how do we educate a working group about the best practices? It is even hard to find the location of the document if you aren’t active in the working group. How do we address discoverability for cross working group or area review of the current draft?

It helps reviewers if we can separate complex issues from simple ones to help manage transparency and coherence.

Are there any important questions to be addressed around the business model associated with GitHub. Should the IETF have its own similar site. Do we expect people to have free or paid accounts.

Is it possible to tide code projects into the document repositories. Is this even something we want to do?