Subject: [Ietf-and-github] Proposed GIT working group charter

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Dec 2018 10:57:44 -0500

Hi,

After the hugely productive discussion we had in Bangkok, we decided
that we would entertain the notion of a new working group.  Here's my
proposed charter.  I think that it is self-explanatory if you attended
the meeting, but I'm happy to discuss details.

Cheers,
Martin

~~~
Many IETF working groups use external code repository services, primarily
[GitHub](https://github.com/), in managing their work.  Individual working
groups, while continuing to operate within IETF guidelines for working group
activity, have developed their own policies and practices for how they use these
services.  These policies and practices cover aspects such as: managing
discussion between working group mailing lists and GitHub issues and pull
requests; how text contributions are expected to be made; labeling and naming
conventions; maintaining readable draft snapshots; using tooling and automation;
and others.

The GitHub Integration and Tooling (GIT) working group will select a set of such
practices and document policies that support those practices.  The policies will
each detail how work is conducted by working groups that opt to follow the work
practice.  Whether working groups choose to use GitHub to support their work
will remain entirely at their discretion.  The goal is to provide both process
and tooling support for working groups that choose to adopt the documented
practices.

The working group may also discuss tooling requirements in support of GitHub
use. Decisions about implementing specific tooling needs will be undertaken in
consultation with the IETF Tools Team and other interested contributors.

Milestones:

Work practice description and policy document(s) sent to IESG - Aug 2019

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Dec 2018 18:23:07 +0000

Hi,

I  did not participate in the Bangkok discussions, so I apologize if my questions were already raised and discussed.

Q1: Could we only use Git (instead of GitHub) in the WG name? That would better allow the WG to cover other repositories in the future, should there be a need for that.

Q2: Related to Q1, while the focus (at least initially) is on GitHub, should there also be generic text saying that the scope of the WG is Git repositories. That would allow to cover other Git services in the future, while making clear that non-Git services are outside the scope of the WG.

Q3: The text says that WGs are free to choose whether they use GitHub in their work, but there is no text about whether WGs that use GitHub have to follow the procedures defined by the GIT WG. No, I see no reason why a WG should not follow the guidelines, but this is IETF after all... :)

Regards,

Christer

On 07/12/2018, 17.58, "Ietf-and-github on behalf of Martin Thomson" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    Cheers,
    Martin
    
    ~~~

    
    Milestones:

    _______________________________________________
    Ietf-and-github mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/ietf-and-github

---

From: "Aaron Falk" <[email-masked]>
Date: Fri, 07 Dec 2018 13:25:53 -0500

Hi Martin-

Thanks for drafting some text.  I have a couple of thoughts / questions.

* It’s unclear from the text whether the results of the group will be 
rules or recommendations.  My preference would be recommendations but I 
think the charter should be clear regardless.
* I think the charter & working group should be clear the 
recommendations will be consistent with RFC2026/BCP9, which has 
addresses things like wg record keeping.
* I’m not sure if it belongs in the charter but I don’t understand 
what happens after the IESG receives the “work practice description 
and policy document(s)”.  Must they be approved the IESG?  What is the 
role of the wg if the IESG disagrees or wants changes?  Will there be 
some public artifact of the output?

--aaron

---

From: Mike Bishop <[email-masked]>
Date: Fri, 7 Dec 2018 20:07:34 +0000

I would envision the outcome as BCP RFCs describing one or more sets of policies that WGs should consider adopting, but are not obligated to follow.

From: Ietf-and-github <[email-masked]> On Behalf Of Aaron Falk
Sent: Friday, December 7, 2018 10:26 AM
To: Martin Thomson <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ietf-and-github] Proposed GIT working group charter

Hi Martin-

  *   It’s unclear from the text whether the results of the group will be rules or recommendations. My preference would be recommendations but I think the charter should be clear regardless.
  *   I think the charter & working group should be clear the recommendations will be consistent with RFC2026/BCP9, which has addresses things like wg record keeping.
  *   I’m not sure if it belongs in the charter but I don’t understand what happens after the IESG receives the “work practice description and policy document(s)”. Must they be approved the IESG? What is the role of the wg if the IESG disagrees or wants changes? Will there be some public artifact of the output?

--aaron

Hi,

Cheers,
Martin

~~~

Milestones:

_______________________________________________
Ietf-and-github mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ietf-and-github

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Dec 2018 16:47:58 -0500

Hi Christer,

> Q1: Could we only use Git (instead of GitHub) in the WG name? That would better allow the WG to cover other repositories in the future, should there be a need for that.

I said this in the meeting, but I'll repeat it for your benefit and
the benefit of others: I don't believe that we get the same benefit
from using just git.  The primary advantage we gain from using GitHub
is access to the community of people who are already there.

This doesn't mean that individuals and WGs can't choose to use other
tools, but we have realized that GitHub is an option that is very
widely used and we want to optimize for the common case first.

The same goes for groups that choose to roll their own processes.
That will remain a choice, but we will not necessarily provide
additional support for those processes.

(I happen to think that there is value in homogenous process and
practice as long as it preserves the diversity of input we rely on.  A
homogenous process can be hugely powerful.  But I am fully aware that
this sometimes leads to easier suppression of views.  In a way, our
reliance on email and mailing lists has that effect.  It's just
something we're acclimatized to.)

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Dec 2018 17:00:50 -0500

So, before I respond, I realize that I failed here.

This is now up on GitHub: https://github.com/martinthomson/ietf-git-charter

Inline responses...

On Fri, Dec 7, 2018 at 1:25 PM Aaron Falk <[email-masked]> wrote:
> It’s unclear from the text whether the results of the group will be rules or recommendations. My preference would be recommendations but I think the charter should be clear regardless.

I don't know how this is unclear.  The charter says "working group
will select a set of such practices and document policies that support
those practices.  The policies will each detail how work is conducted
by working groups that opt to follow the work practice."  I read that
as saying that will be rules, but only if a working group agrees to
use those rules.

> I think the charter & working group should be clear the recommendations will be consistent with RFC2026/BCP9, which has addresses things like wg record keeping.

The intent with the "while continuing to operate within IETF
guidelines for working group activity" was to cover that.  Would a
reference to 2026 there be sufficient?

> I’m not sure if it belongs in the charter but I don’t understand what happens after the IESG receives the “work practice description and policy document(s)”. Must they be approved the IESG? What is the role of the wg if the IESG disagrees or wants changes? Will there be some public artifact of the output?

This would be a working group as normal, where the output of the group
is subject to the normal processes.  So we have both IESG and
community approval.  As Mike says, BCPs seem the likely result. I
don't want to prejudice this with text in the charter though.

---

From: "Aaron Falk" <[email-masked]>
Date: Fri, 07 Dec 2018 17:17:04 -0500

Thanks for the quick reply, Martin.

On 7 Dec 2018, at 17:00, Martin Thomson wrote:

> This is now up on GitHub: 
> https://github.com/martinthomson/ietf-git-charter
>
> Inline responses...
>
>> It’s unclear from the text whether the results of the group will be 
>> rules or recommendations. My preference would be recommendations but 
>> I think the charter should be clear regardless.
>

Sorry, let me make my question more explicit: is it the intention that 
working groups will be able to use GitHub and deviate from the policies? 
  We have a lot of process BCPs that don’t permit that.

>
>> I think the charter & working group should be clear the 

I think so.  Maybe BCP9 as it would avoid hairsplitting about updates to 
that doc.  Also, I received a couple of private emails making me think 
it might be a good idea to call out that the group should address IPR 
and Note Well concerns.

>
>> I’m not sure if it belongs in the charter but I don’t understand 
>> and policy document(s)”. Must they be approved the IESG? What is 
>> the role of the wg if the IESG disagrees or wants changes? Will there 
>> be some public artifact of the output?
>

Ah, here I disagree.  I think the discussion about the charter of the 
working group should take a stand on and be explicit about what the 
actual output should be.  I agree that consensus documents like BCP RFCs 
would be appropriate.

--aaron

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Dec 2018 11:20:21 +1300

On 2018-12-08 11:00, Martin Thomson wrote:
...
> reference to 2026 there be sufficient?

I'd make it BCP 9 to pull in all the updates without extra verbiage in
the charter. And IMHO you also need BCP 79 to pull in the IPR rules,
and BCP 25 (= RFC2418 + RFC3934 + RFC7776) as the main reference for
WG operations. For example, that pulls in the anti-harassment rules.

  Brian

---

From: Fred Baker <[email-masked]>
Date: Fri, 7 Dec 2018 18:11:57 -0800

+1 to Christer's comments. I would add one; it seems like there was interest in the discussion about adding an IETF-operated git repository that was IPv6-capable. The argument against that in the meeting was that GitHub is commonly used, which seems to me a weak argument at best. If that were added in the charter, we would be in a position to discuss it and perhaps add it to the IETF tools.

> On Dec 7, 2018, at 7:57 AM, Martin Thomson <[email-masked]> wrote:
> 
> Hi,
> 

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 8 Dec 2018 21:03:59 +0000

> The primary advantage we gain from using GitHub

Strongly agree.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 8 Dec 2018 21:59:32 +0000

> Q1: Could we only use Git (instead of GitHub) in the WG name? That would better allow the WG to cover other repositories in the future, should there be a need for that.

Even if the WG name says "GitHub", the WG could later discuss GitLab and friends, or even "git without pull requests or issue trackers". So far, the vast majority of the interest has be in GitHub, but that doesn't mean it will always be this way.

> Q2: Related to Q1, while the focus (at least initially) is on GitHub, should there also be generic text saying that the scope of the WG is Git repositories. That would allow to cover other Git serv…

This is better to me than making the WG seem to be generically about Git in the name.

> Q3: The text says that WGs are free to choose whether they use GitHub in their work, but there is no text about whether WGs that use GitHub have to follow the procedures defined by the GIT WG. No,…

Exactly.

--Paul Hoffman

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 9 Dec 2018 12:30:00 +0000

>> The primary advantage we gain from using GitHub is access to the community of people who are already there.
>    
> Strongly agree.
  
If we talk about IETF contributors, that's a valid point - it's easier for people to adopt a tool they are familiar with. 

But, if we talk about people in general, I doubt the usage of GitHub alone is going to bring new people to IETF: people will join IETF if they are interested in what we produce - not the tools we are using. Otherwise one could claim we should start writing of drafts and RFCs using MS Word, because of the big community out there... __

Note that I personally have no problem with using GitHub.

Regards,

Christer

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 10 Dec 2018 08:36:25 +1100

> On 9 Dec 2018, at 11:30 pm, Christer Holmberg <[email-masked]> wrote:
> 
> 

That argument ignores the people who are interested in our work, but don't know how to engage or don't want to, because of the tools and processes we use are unfamiliar and clunky to them. 

--
Mark Nottingham   https://www.mnot.net/

---

From: Melinda Shore <[email-masked]>
Date: Sun, 9 Dec 2018 21:19:06 -0900

On 12/9/18 12:36 PM, Mark Nottingham wrote:
> That argument ignores the people who are interested in our work, but
> don't know how to engage or don't want to, because of the tools and
> processes we use are unfamiliar and clunky to them.

I'm ambivalent about several aspects of this work.  I think
there's a lot of value in creating documents describing best
practices around tools that are in common use around the IETF and
which may conflict to varying degrees with how we describe our
processes (moving from a mailing list-focused process to one in
which the work is driven by activity in repos, primarily).

To get to Mark's point, it's not at all clear to me that people
who find our current processes and tooling opaque and who'd be
comfortable with Github wouldn't be equally at home with other
repositories, particularly others based on Git.  I think a lot of
us work primarily at the command line rather than through the
web interface.  Also, I'm just not in love with creating IETF
tools and processes that are resident on other people's gear.
Leaving open the possibility that at some point in the future
this could all be moved to an IETF-owned Git service would go
some distance towards improving my comfort level with that.
But even then, if you've been writing software for any period
of time you've probably run through <bignum> different revision
control systems and I expect that Git/Github will fall out of
favor within some number of years, as well, and there's value
in staying flexible.

I'm also concerned that this work may lead to working groups
feeling pressured to do their work on Github even though they'd
rather not.

In summary, 1) love the idea of producing BCPs addressing the
question of how to use Git/Github effectively in IETF working
groups, 2) don't love the idea of any of this becoming
normative, 3) really don't like the idea of it becoming narrowly
focused on one service that doesn't belong to the IETF (or ISOC
or various associated I- bodies).

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Dec 2018 08:03:13 +0000

Hi,

    >> But, if we talk about people in general, I doubt the usage of GitHub alone is going to bring new people to IETF: people will join IETF 
    >> if they are interested in what we produce - not the tools we are using. Otherwise one could claim we should start writing of drafts and 
    >> RFCs using MS Word, because of the big community out there... __
    >
    > That argument ignores the people who are interested in our work, but don't know how to engage or don't want to, because of the tools 
    > and processes we use are unfamiliar and clunky to them. 

   As far as I understand, those people will anyway have to use many/most of our tools, because formal decisions etc will still have to be done in the WG, on the mailing lists etc. 

   I DO like the way you use GitHub in HTTPbis, and I personally use it for my drafts (the XML code, and to track issues), so I think it can be very useful. I still doubt it will bring new people to IETF - but hopefully I'm wrong :)

   Regards,

   Christer

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 10 Dec 2018 09:06:44 +0000

I have no objection to looking at new tooling that may make our work 
proceed better.  But deciding that we should use a particular tooling 
because a particular group of external people are comfortable with it 
and may join our work if we use it seems wrong.  There are many 
different external groups we would like to engage more.  They use many 
different tools.

So looking at how we can use git / github is reasonable.  Saying "we 
have to use github, not just git, because one group of people is more 
comfortable with that" seems wrong.

Yours,
Joel

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 10 Dec 2018 11:44:27 +0000

On 10/12/2018 09:06, Joel M. Halpern wrote:
> But deciding that we should use a particular tooling because a 
> particular group of external people are comfortable with it and may 
> join our work if we use it seems wrong. 

I agree.

BTW the natural conclusion of that slippery slope is that we go over to 
using MS Word like pretty much every other SDO.

- Stewart

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 10 Dec 2018 12:48:55 +0000

I don't recall anyone saying "we have to use github."  Do you?

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 10 Dec 2018 09:10:33 -0500

I also agree with Stewart and Joel (and Fred's comments earlier in the
thread). Developing IETF-focused best practice procedures for using Git as
a draft development tool is very reasonable, we should of course take
advantage of externally-developed tooling when it makes sense.

However, saying that we have to use GitHub because "that's where the
developers are" makes very little sense to me. If you're comfortable with
using GitHub, you'll be comfortable using the same toolset hosted elsewhere
as well. And I much prefer the IETF using hosting resources that are under
its own control rather than having to depend on the kindness (and support)
of others. GitHub is a major attraction to the DDOS community (see
https://www.wired.com/story/github-ddos-memcached/ for example), and any
outages on their part, whether caused by DDOS, HW failures, ISP failures,
etc., would be totally out of our control.

Cheers,
Andy

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Dec 2018 06:34:01 -0800

Indeed. I'm not quite sure I understand the thrust of the argument that
people are making.

1. A significant fraction of the community has decided (for whatever
reason) to use Github. They could have decided to use self-hosted Git
or some other Git service, but they didn't.

2. The processes and tooling on our side for using Github are not great.

3. The purpose of this WG is to define requirements and norms to
remedy (2). In other words, we're trying to pave the cowpaths [0].

Nobody is stopping you from (a) using another Git service (b) hosting
your own Git service (c) using some entirely different tool, And if
enough people do one of those things that it's worth trying to build
some common understanding of how to do that, then that's something we
should consider at that time. However, that's not what people are
doing now, and the idioms for those cases (especially self-hosted Git)
are sufficiently different that trying to cover all those cases would
be significantly more work, and would work less well.

So, I think this WG should focus on the Github use case. And if
someone later wants to do a Gitlab one or adapt it to self-hosting,
then that would be fine. But we should resist the urge to
over-generalize at this point.

-Ekr

[0] http://www.designingsocialinterfaces.com/patterns/Pave_the_Cowpaths

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Dec 2018 08:49:40 -0800

On Mon, Dec 10, 2018 at 6:10 AM Andrew G. Malis <[email-masked]> wrote:

> as well.

This is actually a somewhat complicated topic, as "the same toolset" could
mean several things, in increasing order of dissimilarity from the
currently common model.

1. Github Enterprise (https://enterprise.github.com/home).
2. Some other self-hosted version of a Github-like workflow (gogs, etc.)
3. Self-hosting of regular Git (+review tools, CI, etc.)

People who are comfortable using Github might be comfortable with Github
enterprise (though creating a new account *is* a significant barrier in
practice). And of course, this isn't actually a standalone thing because
you'd need stuff like continuous integration, which Github doesn't actually
have but rather people outsource to other tools like CircleCI which are
integrated with Github, The other options actually feel pretty different.
As an example, BoringSSL is hosted on Git but uses a totally different
workflow based on Gerritt and its own CI and it would be quite unfamiliar
to someone who knew Github.

> And I much prefer the IETF using hosting resources that are under its own
> control rather than having to depend on the kindness (and support) of
> others. GitHub is a major attraction to the DDOS community (see

This is really off topic for the question of whether we ought to form this
WG, but like it or not, the industry is largely moving away from
self-hosting. As a concrete example, Mozilla has a substantial ops
department and used to have physical datacenters, and has moved the vast
majority of that stuff into cloud. Even beyond that, a large number of our
mission-critical services (e-mail, calendar, chat, etc.) are cloud hosted,
and this is basically the way that the industry is going, even for
organizations with a much larger ops budget than IETF.

-Ekr

---

From: Mike Bishop <[email-masked]>
Date: Mon, 10 Dec 2018 18:22:53 +0000

Yes and no.  For people that want to get deep into the process -- submit drafts, participate in discussions, etc. they'll certainly need to get into our toolset.  But one thing GitHub enables is a lower barrier to entry to provide specific feedback on a document.  During both HTTP/2 and QUIC, we've gotten drive-by editorial fixes from people who don't actively participate on the list, but followed a link to the doc, saw an issue, and submitted a fix. We've also gotten issues filed on things that weren't clear from the document.  The IETF is constantly in search of document reviewers, and GitHub has helped us get reviews from people who weren't already steeped in the tribal knowledge of the working group.

It's not all rosy -- some of those review comments weren't directly useful feedback, because the reviewer was unaware of other context.  But even those sorts of comments highlight where something that we think is clear and obvious wasn't to a lay reader.

I think the appeal here is two-fold:  The tools in GitHub et al. help those of us "in" the IETF do things more easily, and it provides another on-ramp for people to interact with the work we're doing before deciding it's worth getting heavily invested and participating.

-----Original Message-----
From: Ietf-and-github <[email-masked]> On Behalf Of Christer Holmberg
Sent: Monday, December 10, 2018 12:03 AM
To: Mark Nottingham <[email-masked]>
Cc: Salz, Rich <[email-masked]>; Martin Thomson <[email-masked]>; [email-masked]
Subject: Re: [Ietf-and-github] Proposed GIT working group charter

Hi,

   Regards,

   Christer

---

From: Melinda Shore <[email-masked]>
Date: Mon, 10 Dec 2018 12:23:01 -0900

On 12/10/18 9:22 AM, Mike Bishop wrote:
> But one thing GitHub enables is a
> lower barrier to entry to provide specific feedback on a document.
> During both HTTP/2 and QUIC, we've gotten drive-by editorial fixes
> from people who don't actively participate on the list, but followed
> a link to the doc, saw an issue, and submitted a fix. We've also
> gotten issues filed on things that weren't clear from the document.
> The IETF is constantly in search of document reviewers, and GitHub
> has helped us get reviews from people who weren't already steeped in
> the tribal knowledge of the working group.

That's really interesting, as it's something I haven't seen
happen in other working groups (and yes, the plural of
"anecdote" is not "data"), and it would be excellent if we
could tease out why this happened and whether or not it's
something we could do in other working groups using Github.
To be perfectly honest I suspect that it has something to
do with QUIC getting a lot of attention right now rather
than specifically because of the tooling, but I could be
wrong about that, and if so, it would be extremely useful
to figure out what led to more input from the broader
(non-IETF) community.

Thanks,

Melinda

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Dec 2018 13:26:48 -0800

> to figure out what led to more input from the broader

I don't think it's because of QUIC being popular (at least not solely). We
see the same thing in TLS.

-Ekr

---

From: Mike Bishop <[email-masked]>
Date: Mon, 10 Dec 2018 21:27:36 +0000

Yes, I suspect the reading-the-doc happened because of the current popularity of QUIC development and the then-popularity of HTTP/2 development.  My focus is on the ease with which readers could self-convert to contributors, not necessarily the problem of getting pre-RFC readers in the first place.

-----Original Message-----
From: Ietf-and-github <[email-masked]> On Behalf Of Melinda Shore
Sent: Monday, December 10, 2018 1:23 PM
To: [email-masked]
Subject: Re: [Ietf-and-github] Proposed GIT working group charter

On 12/10/18 9:22 AM, Mike Bishop wrote:
> from people who don't actively participate on the list, but followed a 
> link to the doc, saw an issue, and submitted a fix. We've also gotten 
> issues filed on things that weren't clear from the document.
> The IETF is constantly in search of document reviewers, and GitHub has 
> helped us get reviews from people who weren't already steeped in the 
> tribal knowledge of the working group.

That's really interesting, as it's something I haven't seen happen in other working groups (and yes, the plural of "anecdote" is not "data"), and it would be excellent if we could tease out why this happened and whether or not it's something we could do in other working groups using Github.
To be perfectly honest I suspect that it has something to do with QUIC getting a lot of attention right now rather than specifically because of the tooling, but I could be wrong about that, and if so, it would be extremely useful to figure out what led to more input from the broader
(non-IETF) community.

Thanks,

Melinda

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Dec 2018 16:17:44 +1100

On Sat, Dec 8, 2018 at 9:17 AM Aaron Falk <[email-masked]> wrote:
> Sorry, let me make my question more explicit: is it the intention that working groups will be able to use GitHub and deviate from the policies? We have a lot of process BCPs that don’t permit that.

This would deviate from that.  I don't see any reason to forbid the
use of GitHub outside of these practices.  The point here is to pave
the cowpaths, not sow the rest of the area with spikes.

> I think so. Maybe BCP9 as it would avoid hairsplitting about updates to that doc. Also, I received a couple of private emails making me think it might be a good idea to call out that the group should address IPR and Note Well concerns.

BCP 9 it is.

I agree about note well/IPR.  I just don't think that it is necessary
to encharter that, if only because the charter is already too long and
opaque.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Dec 2018 16:28:51 +1100

> different external groups we would like to engage more.  They use many

This implies that we're speculating about external people.  That's not the case.

We've real evidence of bringing new contributors into the process via
this channel.  I don't want to name names, but on the documents I've
worked on there have been several individuals who have made
significant contributions, participating only via GitHub.  Some of
those people have moved from exclusive GitHub use to include
(sporadic) use of email, but not all.

> comfortable with that" seems wrong.

That's not what is being said at all.  What is being said is that
GitHub is the path we want to provide this additional support for.

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 11 Dec 2018 06:00:11 +0000

> +1 to Christer's comments. I would add one; it seems like there was interest in the discussion about adding an IETF-operated git repository that was IPv6-capable. The argument against that in the m…

Is the (main) point to have an IPv6-capable git repository? In that 
case, would it be sufficient if GitHub offered IPv6 support?

Or is the (main) point to have an IETF-controlled repository?

Regards,   Martin.

---

From: Lars Eggert <[email-masked]>
Date: Tue, 11 Dec 2018 15:52:25 +0200

> over-generalize at this point.

+1

Lars

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 11 Dec 2018 16:02:26 -0500

> On Dec 7, 2018, at 5:17 PM, Aaron Falk <[email-masked]> wrote:
> Ah, here I disagree. I think the discussion about the charter of the working group should take a stand on and be explicit about what the actual output should be. I agree that consensus documents like BCP RFCs would be appropriate.
> 
> 

I think the way we typically handle this is in the milestone descriptions (not formally part of the charter since they can be updated independently from it, but good to have there at charter time). So in this case the milestone could be altered to say "Work practice description and policy document(s) submitted to IESG for publication as BCP(s).” If it turns out the WG or the IETF wants to change the documents’ standards level later, that is doable, doesn’t require a charter change, and happens fairly often.

Alissa

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 11 Dec 2018 15:25:43 -0600

As one of the ADs who will likely ballot on this charter and not on the
resulting documents :-)

On Tue, Dec 11, 2018 at 3:03 PM Alissa Cooper <[email-masked]> wrote:

> I’m not sure if it belongs in the charter but I don’t understand what
> happens after the IESG receives the “work practice description and policy
> document(s)”. Must they be approved the IESG? What is the role of the wg if
> the IESG disagrees or wants changes? Will there be some public artifact of
> the output?
>
> working group should take a stand on and be explicit about what the actual
> output should be. I agree that consensus documents like BCP RFCs would be
> appropriate.
>
>
> I think the way we typically handle this is in the milestone descriptions
> (not formally part of the charter since they can be updated independently
> from it, but good to have there at charter time). So in this case the
> milestone could be altered to say "Work practice description and policy
> document(s) submitted to IESG for publication as BCP(s).” If it turns out
> the WG or the IETF wants to change the documents’ standards level later,
> that is doable, doesn’t require a charter change, and happens fairly often.
>

What Alissa said, seems like the most helpful formulation to me.

If the working group is (for example) targeting BCP, that may result in a
particular document structure and style (for example, using BCP14
keywords), and having a target may make things easier for the working
group.

If what the working group delivers would be more appropriate as something
besides a BCP, that change is doable, as Alissa says, and can happen as
late as IESG Evaluation (as per
https://tools.ietf.org/html/rfc2026#section-6.1.2).

So we can always do the right thing.

Spencer

---

From: "Aaron Falk" <[email-masked]>
Date: Tue, 11 Dec 2018 16:32:04 -0500

On 11 Dec 2018, at 16:25, Spencer Dawkins at IETF wrote:

>> what
>> actual

This sounds fine to me and what I was expecting.

--aaron

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Dec 2018 12:13:25 +1100

In an attempt to close the loop on this, I have two edits:

https://github.com/martinthomson/ietf-git-charter/commit/ad5bde52112c10d2ac78ebc32366bb19ac280a2f

Proposed text:
+The documents will not alter the Internet Standards Process (BCP 9), they will
+describe how to work within it.  Whether working groups choose to use GitHub to
+support their work will remain entirely at their discretion.

And Alissa's suggestion:
https://github.com/martinthomson/ietf-git-charter/commit/d53f32ad0130c18ba11b830d5ebc001eb5902a61

As always text/PRs welcome.  I'm certain that this could be improved further.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Dec 2018 07:22:45 +0000

Hi,

A minor comment: I suggest to say "The processes will not alter..." instead of "The documents will not alter...".

Because, maybe the WG does not produce any documents to begin with - perhaps everything ends up begin documented in GitHub :)

Regards,

Christer

On 12/12/2018, 3.14, "Martin Thomson" <[email-masked]> wrote:

    
    Proposed text:

    And Alissa's suggestion:

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Dec 2018 16:20:44 -0500

> A minor comment: I suggest to say "The processes will not alter..." instead of "The documents will not alter...".

Thanks Christer,

The intent is to document the practices, which is stated in the
preceding text.  So I think that "documents" is fine.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Dec 2018 10:51:40 +0000

Hi,

>  The intent is to document the practices, which is stated in the preceding text.  So I think that "documents" is fine.

As you say, the text does say that practices will be documented. But, there is no mention of documents earlier, so one could wonder what "the documents" refer to.

But, I know what the text means, and if others think it's clear, I won't argue against it.

Regards,

Christer

---

From: Bret Jordan <[email-masked]>
Date: Sun, 30 Dec 2018 11:52:54 -0700

I know we have been discussing and talking about a charter for this group.  However, I think it is critical to mention that Github represent a significant barrier to entry for a lot of people.  Also, once a document gets sufficiently large and has a significant number of contributors, issues and pull requests, the work can nearly grind to a halt do to the weight of the process needed to manage all of the changes. It can also make it really hard for people to follow along on what is being changed and what are all of the proposed changes for a given piece of text. Meaning, it is hard to see all of the proposed changes to a piece of text at the same time and allow people to comment and suggest changes to other people’s changes. 

What we need, we do not yet have. We need something like Google Docs that automatically tracks all changes, comments on changes, and suggestions in something like Github. Where the communication between Google Docs and Github is bidirectional. 

In the end, we need to ensure that anything we do with the charter will not hinder people bringing work to the IETF.  When I see the attendance numbers and then compare that with the growth of other SDOs, we need to enable more people to contribute and work on technology in the IETF, not less.

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 30 Dec 2018 11:30:56 -0800

On Sun, Dec 30, 2018 at 10:53 AM Bret Jordan <[email-masked]> wrote:

> I know we have been discussing and talking about a charter for this
> group.  However, I think it is critical to mention that Github represent a
> significant barrier to entry for a lot of people.
>

Well, those people can continue to read the drafts as they are published
and send comments in email as people have historically done. We do have
people doing that and I don't see anyone proposing to change that.

 Also, once a document gets sufficiently large and has a significant number
> of contributors, issues and pull requests, the work can nearly grind to a
> halt do to the weight of the process needed to manage all of the changes.
>

This has not been my experience with any of the documents where we have
used Github (specifically TLS and QUIC). Rather, in these cases we actually
move far faster than on documents where we have followed a more traditional
strategy.

It can also make it really hard for people to follow along on what is being
> changed and what are all of the proposed changes for a given piece of text.
> Meaning, it is hard to see all of the proposed changes to a piece of text
> at the same time and allow people to comment and suggest changes to other
> people’s changes.
>

I agree that this is an issue.

What we need, we do not yet have. We need something like Google Docs that
> automatically tracks all changes, comments on changes, and suggestions in
> something like Github. Where the communication between Google Docs and
> Github is bidirectional.
>

I'm not quite sure what you have in mind here, so it's hard to comment on.
However, I have done a lot of co-work on documents in Google docs and my
experience is it's not generally preferable to Github,

In the end, we need to ensure that anything we do with the charter will not
> hinder people bringing work to the IETF.  When I see the attendance numbers
> and then compare that with the growth of other SDOs, we need to enable more
> people to contribute and work on technology in the IETF, not less.
>

This seems sort of tangential to the thrust of this proposed WG. We already
have a lot of WGs who have chosen to use Github and my expectation is that
trend will continue. This WG is about specifying some lightweight common
practices to make it easier for people who want to use Github to do so, not
about making people move to Github. With that said, my experience and I
think the experience of all the major GH-using WGs is that it has brought
in a lot of new contributors.

-Ekr

---

From: Bret Jordan <[email-masked]>
Date: Sun, 30 Dec 2018 13:34:31 -0700

Thanks for the comments and perspective.    Some comments in-line.

Thanks,
Bret

> On Dec 30, 2018, at 12:30 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> On Sun, Dec 30, 2018 at 10:53 AM Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:
> I know we have been discussing and talking about a charter for this group.  However, I think it is critical to mention that Github represent a significant barrier to entry for a lot of people.
> 
> Well, those people can continue to read the drafts as they are published and send comments in email as people have historically done. We do have people doing that and I don't see anyone proposing to change that.

Yes, but it is a bit of a turn-off for people when they have to wait until a published draft is released to comment and then they are told, “we already talked about this and discussed it using the Github pull/issue methods”. All I am suggesting is that we give some care and thought to how this will be perceived by people that do not use Git on a daily basis.  Further, we need to understand what this will mean for their ability to comment and provide suggestions. 

An example.  A hotly discussed topic gets rough consensus through the GitHub issue / pull process to do X.  Then when it gets released as an early draft we have some number of people say that it should have been Y.  But the decision has been made and rough consensus was achieved to do X.  However, if their comments would have come in earlier, then they may have tilted the balance and rough consensus could have been for Y. We just need to be careful. 

In all things like this, I think careful management by the chairs and area directors can really help here and help ensure that all voices and use cases are heard and given equal treatment.

> I'm not quite sure what you have in mind here, so it's hard to comment on. However, I have done a lot of co-work on documents in Google docs and my experience is it's not generally preferable to Github,
> 

I am suggesting that it would be nice if we had some sort of easier UI for people to comment and make suggestions, and see other peoples suggestions and comment and then suggest on top of those other suggestions.  Github is generally bad at this and true collaboration of prose text kind of requires this.  But I do not have a solution. We just need to be mindful of this, and be careful.

> This seems sort of tangential to the thrust of this proposed WG. We already have a lot of WGs who have chosen to use Github and my expectation is that trend will continue. This WG is about specifying some lightweight common practices to make it easier for people who want to use Github to do so, not about making people move to Github. With that said, my experience and I think the experience of all the major GH-using WGs is that it has brought in a lot of new contributors.

As long as it stays in that realm of thought then I can generally agree. Meaning, a light-weight process that helps WGs if they choose to go this route.  But I would add that it also needs to be a light-weight process to help contributors that want to work on a standard that may not be well versed in Git.  This work needs to address both sides of the coin.  I may even go so far as saying we should also call out some of the pitfalls and problems that can arise and give some guidance to Chairs and Area Directors on how best to manage it and support the working group and our vast divergent user base.

Bret

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 31 Dec 2018 03:12:08 +0000

Can you explain why you see adding a new avenue for contributions is a bad thing?

---

From: Martin Thomson <[email-masked]>
Date: Mon, 31 Dec 2018 16:39:18 +1100

On Mon, Dec 31, 2018, at 07:34, Bret Jordan wrote:
> Yes, but it is a bit of a turn-off for people when they have to wait 

Nit: they don't *have* to wait, we're just talking about what happens when they do.

> until a published draft is released to comment and then they are told, 
> “we already talked about this and discussed it using the Github pull/
> issue methods”. 

That is a valid first response - as a way to bring in the extra context of those discussions, more than a counter-argument.  However, I would say that once that context has been assimilated, the working group needs to be responsive to the arguments presented.  That is, if there is a new argument, which can be the case, that needs to be considered.

Anything truly contentious shouldn't be decided without consulting the list, or - worst case - spending face-to-face time, so it's rare that this will happen with something where the positions are firmly held.

> An example.  A hotly discussed topic gets rough consensus through the 
> GitHub issue / pull process to do X.  Then when it gets released as an 
> early draft we have some number of people say that it should have been 
> Y.  But the decision has been made and rough consensus was achieved to 
> do X.  However, if their comments would have come in earlier, then they 
> may have tilted the balance and rough consensus could have been for Y. 
> We just need to be careful. 

One thing we've settled on in this is a mode where consensus on documents as a whole is left to WGLC.  There might be individual issues that we've consensus on (to varying degrees), but the entire work product is always open for changes.  If the working group worked through a contentious topic (QUIC spin bit, I'm looking at you), that should be both well-documented and not made available for discussion, but most of the rest is considered open.

That said, there's a social contract that says that you don't reopen a discussion frivolously, even if you were not originally involved.  I think that it's OK for the rest of the group to push back a little in these cases, though doing so from the perspective of trying to see if there is new information about the problem, rather than as a "go away" might be the most polite approach.

This area is probably something that needs some documentation, as an aid to chairs.

> I am suggesting that it would be nice if we had some sort of easier UI 
> for people to comment and make suggestions, and see other peoples 
> suggestions and comment and then suggest on top of those other 
> suggestions.  Github is generally bad at this and true collaboration of 
> prose text kind of requires this.  But I do not have a solution. We just 
> need to be mindful of this, and be careful.

The GitHub tools could stand to be improved here, but you can do a good amount of the commenting and suggesting you describe without installing git.  The UI is perhaps not as slick as Word, but that just suggests a business opportunity: there's nothing inherently preventing that from happening.