Subject: [Ietf-and-github] WG documents and pull requests, issues, and WG mail

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 25 Oct 2016 16:55:14 -0700

Greetings. This list has been dead^Wquiet for a while, but it seems like 
some WGs are slowly adopting GitHub for document editing.

I'm interested in how WGs that have WG documents on GitHub deal with 
requested updates. Instead of suggesting how it might be done, I'd love 
to hear some WG chairs or document authors discuss what they are doing 
today, maybe expanding into what they would change. Specific examples 
would be great.

--Paul Hoffman

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 26 Oct 2016 11:41:05 +1100

Hi Paul,

Can you be more specific?

> On 26 Oct. 2016, at 10:55 am, Paul Hoffman <[email-masked]> wrote:
> 
> requested updates

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

---

From: Dean Willis <[email-masked]>
Date: Tue, 25 Oct 2016 20:18:37 -0500

> On Oct 25, 2016, at 18:55, Paul Hoffman <[email-masked]> wrote:
> 
> Greetings. This list has been dead^Wquiet for a while, but it seems like some WGs are slowly adopting GitHub for document editing.
> 
> I'm interested in how WGs that have WG documents on GitHub deal with requested updates. Instead of suggesting how it might be done, I'd love to hear some WG chairs or document authors discuss what they are doing today, maybe expanding into what they would change. Specific examples would be great.
> 

Well, Marc and I did a heavy edit on p2psip, with the main authors Eric and Cullen coordinating.

We kept the xml2rfc source in github, made a pull request for each major edit, and they either accepted or didn’t. We used the github issue tracker extensively. It worked pretty well. But this was several years ago and things have certainly evolved since …

—
Dean

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 25 Oct 2016 18:28:59 -0700

> Can you be more specific?

Always! :-) A person in a WG is looking at a WG draft and sees what they 
consider a defect. They might or might not have specific wording to 
remedy the defect. How do they report the defect in a way that it can be 
considered for the next version of the draft?

--Paul Hoffman

---

From: Dean Willis <[email-masked]>
Date: Tue, 25 Oct 2016 20:50:31 -0500

> On Oct 25, 2016, at 20:28, Paul Hoffman <[email-masked]> wrote:
> 
> Always! :-) A person in a WG is looking at a WG draft and sees what they consider a defect. They might or might not have specific wording to remedy the defect. How do they report the defect in a way that it can be considered for the next version of the draft?
> 

github issue tracker?

—
Dean

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 25 Oct 2016 18:54:34 -0700

On 25 Oct 2016, at 18:50, Dean Willis wrote:

>> Always! :-) A person in a WG is looking at a WG draft and sees what 
>> they consider a defect. They might or might not have specific wording 
>> to remedy the defect. How do they report the defect in a way that it 
>> can be considered for the next version of the draft?
>>
>
> github issue tracker?

Sorry if I wasn't clear. I'm not asking for suggestions, I'm asking for 
how WGs that are already doing this. I have been told different ways, 
but it might be useful to have people currently using them list them and 
talk about perceived advantages and disadvantages.

--Paul Hoffman

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 26 Oct 2016 15:37:57 +1100

> On 26 Oct. 2016, at 12:28 pm, Paul Hoffman <[email-masked]> wrote:
> 

Officially, for us:
  https://github.com/httpwg/http-extensions/blob/master/CONTRIBUTING.md

In a nutshell -- new issue preferred (with a pull request is fine, but don't use a pull request to open an issue, it'll get lost). Raising the issue on the ML is fine too. 

People can suggest changes / bring up nits by commenting on the individual commits, but they may get overlooked.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 26 Oct 2016 11:57:27 +0000

> Sorry if I wasn't clear. I'm not asking for suggestions, I'm asking for how WGs
> that are already doing this. I have been told different ways, but it might be
> useful to have people currently using them list them and talk about
> perceived advantages and disadvantages.

We follow what seems to have been HTTP-bis's lead.

The document is edited on github (ietf-wg-xxxx is a project, specific docs within that are their own repo).  We use PR's extensively.  We have folks open issues, and we try to keep the discussion of them on the mailing list.  We use Martin Thomson's template/tooling.

My biggest issue is non-mailing list discussion, but folks in the WG seem to get "trained" to do the right thing.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Oct 2016 10:30:04 -0400

This is all concerning to me because it seems to lead to a situation 
where it is hard to find and follow the discussion and reasoning that 
surrounds the development of the document. It is distributed between the 
mailing list and github.

IMO it would be better to limit github to use as a tool for sharing and 
discussion among the authors/editors of the document. This would lead to 
"drops" of new -nn versions of the document to ietf that can be 
discussed on the mailing list, between the authors and the other members 
of the wg.

	Thanks,
	Paul

On 10/26/16 7:57 AM, Salz, Rich wrote:
> _______________________________________________
> Ietf-and-github mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-and-github
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 26 Oct 2016 08:00:54 -0700

On 26 Oct 2016, at 4:57, Salz, Rich wrote:

> The document is edited on github (ietf-wg-xxxx is a project, specific 
> docs within that are their own repo).  We use PR's extensively.  We 
> have folks open issues, and we try to keep the discussion of them on 
> the mailing list.  We use Martin Thomson's template/tooling.
>
> My biggest issue is non-mailing list discussion, but folks in the WG 
> seem to get "trained" to do the right thing.

For this WG (which I'm assuming is TLS...), what do you consider "the 
right thing"?

--Paul Hoffman

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 26 Oct 2016 08:08:22 -0700

On 26 Oct 2016, at 7:30, Paul Kyzivat wrote:

> This is all concerning to me...

You are one of many people you have expressed that concern, but there 
are also a bunch of WGs who insist that their use of GitHub has made the 
discussion-and-update process much more manageable and predictable. 
That's why I started a tread about "what are actual WGs doing": so the 
concerned folks can look at working examples.

--Paul Hoffman

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 26 Oct 2016 15:44:46 +0000

> For this WG (which I'm assuming is TLS...), what do you consider "the right
> thing"?

No, it's ACME (which I co-chair, not TLS which I gladly don't:).  Right thing is open an issue so we can track it, post a note to the mailing list for discussion.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Oct 2016 11:56:04 -0400

> concerned folks can look at working examples.

OK. I appreciate that. It will be good to hear.

Note I have seen similar questions come up regarding using the IETF 
issue lists in WGs. Mostly I have seen that descend into chaos. I expect 
it can be very effective if carefully managed, but consistent norms for 
that don't seem to have emerged.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Oct 2016 11:58:26 -0400

> No, it's ACME (which I co-chair, not TLS which I gladly don't:).  Right thing is open an issue so we can track it, post a note to the mailing list for discussion.

Are all the participants on the mailing list assumed to be following 
what is going on in github? Or can wg members be fully engaged just 
following the mailing list?

	Thanks,
	Paul

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 26 Oct 2016 16:00:53 +0000

> Are all the participants on the mailing list assumed to be following what is
> going on in github? Or can wg members be fully engaged just following the
> mailing list?

The intent is that all WG business happens on the mailing list.

Sometimes a discussion will start there with "I posted a new issue, please see ..." and there will be a clickable link.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 26 Oct 2016 18:11:47 +0200

On Wed, Oct 26, 2016 at 1:55 AM, Paul Hoffman <[email-masked]> wrote:
> requested updates. Instead of suggesting how it might be done, I'd love to
> hear some WG chairs or document authors discuss what they are doing today,
> maybe expanding into what they would change. Specific examples would be
> great.

So, this isn't really an instance of a WG doing this, but an example
from an author -- I'm an author on a document in DNSOP. I stuck the
document in Github because it makes it easier *for me and my
co-authors* to collaborate, but the document also says:

[ This document is being
 collaborated on in Github at: https://github.com/wkumari/draft-ietf-
 dnsop-nsec-aggressiveuse.  The most recent version of the document,
 open issues, etc should all be available here.  The authors
 (gratefully) accept pull requests.]

The document got a good amount of feedback during WGLC -- some of the
suggestions were minor, and some of them were much larger. The
discussion happened on the mailing list, but having a place where I
could integrate / address people suggestions, and then publish a new
"mini-version" to make sure that their comment had been addressed was
(IMO) helpful. The repo has ~40 commits, being able to say "I
addressed your comment $here, is this good now?" instead of publishing
40 version of the draft was helpful.

A number of people also sent pull requests -- this was much simpler
for both me, and (I think!) the contributor -- a PR with a bunch of
nits is easier to write than:

O:  query the example.com serves and will get back an NSEC (or NSEC3)
query the example.com servers and will get back an NSEC (or NSEC3)
record starting that there are no records (alphabetically) between
P: query the example.com servers and will get back an NSEC (or NSEC3)
query the example.com servers and will get back an NSEC (or NSEC3)
record stating that there are no records (alphabetically) between
C: You have 'serves' instead of 'servers' at the beginning of the
text, and also you get back a record **staring**, not **starting**.

I realize that this only partially answers your question, or answers a
subtly different question -- welcome to the IETF :-P

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Oct 2016 12:52:26 -0400

This approach sounds exactly right to me!

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Oct 2016 08:26:43 +1300

> This approach sounds exactly right to me!

Yes. We've been doing something even simpler at https://github.com/becarpenter/animaproto.
We use that just as a repo, all discussion of issues on the WG list, and fine
details on the design team list. The open and resolved issues are logged in
(temporary) appendices in the document itself.

Similarly https://github.com/mbehring/ANIMA-Reference-Model, except there is no
formalised issues list.

One interesting choice is whether you decide to put a "generic" or versioned
xml file in the repo. For the first of these two examples, I chose the versioned
approach: draft-ietf-anima-grasp-00.xml, draft-ietf-anima-grasp-01.xml, etc.
For the second one, Michael chose the generic approach: every version is
draft-ietf-anima-reference-model.xml

Personally I have never been very happy with mechanised issue trackers;
they seem at least as much bother as they are worth.

    Brian

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 27 Oct 2016 13:37:23 +0200

RTCWEB has been using github extensively. https://github.com/rtcweb-wg/
My experience as document author has been varying across repos:

- https://github.com/rtcweb-wg/rtcweb-transport has been my own notepad.
I have used the issue tracker to copy/paste text from the mailing list
discussion (when I didn't, it turned out I often forgot about the
issue), used PRs to structure "here's the solution to this problem,
here's the solution to that problem", editing on master for small /
speedy changes, and generally doing what I wanted to do.

- https://github.com/rtcweb-wg/jsep has been a collaborative effort
between the 3 document editors (not me). I've filed a few issues there,
and made comments on others. It's been useful to keep track of whether
my issues are resolved (I keep links of them in other repos), but I've
otherwise kept at arm's length from it.

There are a couple of other repos that exist, but don't matter - they
have had little activity. A repo is not a guarantee of life.

- https://github.com/w3c/webrtc-stats (not an IETF repo) is me and a
collaborator working together. We use the built-in issue tracker to keep
track of who's promised to do what, and the PR mechanism to look at each
others' suggested text before committing it.

In other contexts (W3C), I've found that some people work entirely on
github, and ignore mailing lists. Especially they ignore the mailing
lists of other groups than their own. This is a problem for people who
expect to watch the mailing lists to figure out if anything is
happening; unless they also watch the repo, things "change underneath them".
I haven't yet found a good way to keep a "zeitgeist sync" between the
mailing list and the github repos.

I could go into much more details about my W3C experience with github,
but since the request was for IETF experience, I think I'll stop now.

On 10/26/2016 01:55 AM, Paul Hoffman wrote:
> Greetings. This list has been dead^Wquiet for a while, but it seems
> like some WGs are slowly adopting GitHub for document editing.
>
> requested updates. Instead of suggesting how it might be done, I'd
> love to hear some WG chairs or document authors discuss what they are
> doing today, maybe expanding into what they would change. Specific
> examples would be great.
>
> --Paul Hoffman
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 27 Oct 2016 07:16:11 -0700

> but since the request was for IETF experience, I think I'll stop now.

The W3C is our closest cousin, and therefor experience there could be 
relevant here. Please continue.

--Paul Hoffman

---

From: Dean Willis <[email-masked]>
Date: Thu, 27 Oct 2016 10:19:04 -0500

> On Oct 27, 2016, at 06:37, Harald Alvestrand <[email-masked]> wrote:
> 
> 

Could one copy issue tracker and PR notifications to the mailing list? Or would that drive the list crazy?

—
Dean

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 27 Oct 2016 17:33:35 +0200

> Could one copy issue tracker and PR notifications to the mailing list? Or would that drive the list crazy?
It drives the list crazy. We have been doing that on
[email-masked] for a few months now, and it has essentially
rendered the list silent except for the notifications - real mail gets
lost in the barrage of notifications.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 27 Oct 2016 10:37:27 -0700

For those not on the list Harald mentioned, he started a related 
conversation there that is worth watching.

<https://lists.w3.org/Archives/Public/public-webrtc/2016Oct/0103.html> 
is a good entry point (and is currently the end of the thread but 
hopefully there will be more commentary).

RjS

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 28 Oct 2016 09:41:41 +0900

> lost in the barrage of notifications.

In the Internationalization WG of the W3C, we also had this problem, and 
changed it so that only the creation of an issue and the closing of an 
issue is reported to the mailing list (there's a separate archival 
mailing list to avoid the problems discussed at 
https://lists.w3.org/Archives/Public/public-webrtc/2016Oct/0103.html).

(Most if not all of the actual investigation and setup work has been and 
is done by Richard Ishida, the I18N Activity Lead.)

The justification for this is that when the issue is created, you can 
subscribe to the github issue if you think you're interested, and you'll 
get a last chance to check how things went when the issue is closed.

Also, there's some logic being put in place whenever we review the work 
of some other WG (which happens quite frequently given the nature of the 
group); some of their issues get an "I18N" tag, and some of the 
contributions to these issues are then sent to our mailing list.

My personal impression is that this is certainly better than being 
swamped with all the contributions to each issue. However, it's still 
far from optimal. One example is that on github, the closure of an issue 
is a separate action from any commenting, so the mailing list just gets 
"this issue has been closed", without any indication as to how or why.

One problem I see with github is that except for the subject line, 
there's absolutely no context in the messages. We have looked at e.g. 
including the previous comment in a "issue has been closed" message, but 
checking a few examples led to the conclusion that it wouldn't help too 
much.

The main issue tracker system that I'm otherwise familiar with is 
redmine, as used at bugs.ruby-lang.org. That's in the context of 
software development, not spec development, but I'll mention a few 
points that I think are relevant anyway.

Redmine always appends the full first contribution (i.e. the issue 
details). That can look quite redundant, and useless if the discussion 
goes on a tangent. But it's more of a context than just the subject line.

Also, redmine allows to 'quote' earlier contributions on an issue. It's 
not impossible on github, but has to be done by hand. And because those 
who comment see the earlier comment in front of their eyes on the issue 
page, quoting is usually not found necessary.

In summary, github essentially always expects you to go to the issue 
page. That may be part of their strategy (quite successful up to now) to 
get everything and everybody on github :-(.

Regards,   Martin.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Oct 2016 15:26:08 +1300

On 28/10/2016 13:41, Martin J. Dürst wrote:
> issue is reported to the mailing list

And that, it seems to me, might be a direct violation of IETF rules.
BCP 25 (RFC 2418) makes it clear that discussions and decisions
take place on the WG mailing list. Even if we regard github as a sort
of design team activity, it must still be "subject to approval, rejection
or modification by the WG as a whole." So you can't say "we closed the
foobar issue on github." You can say "github participants propose
the following resolution of the foobar issue, does the WG agree?"
But then you might have to repeat the whole discussion on the WG list.
That's the price of democracy, IETF-style.

   Brian

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 28 Oct 2016 09:39:55 +0000

> lost in the barrage of notifications.

Could a second companion list be set up for the notifications? SO that the people who don't want to be on github can subscribe to it and interact that way?

Lars

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 28 Oct 2016 20:55:10 +1100

> On 27 Oct. 2016, at 2:58 am, Paul Kyzivat <[email-masked]> wrote:
> 
> Are all the participants on the mailing list assumed to be following what is going on in github? Or can wg members be fully engaged just following the mailing list?

Our intent is that someone can do any of:

1) Just follow the WG mailing list, and become aware of things that happened in Github through the drafts and on-list change summaries / notifications
2) #1 + following the WG issues mailing list (generated from Github comments)
3) Just engage on Github (e.g., by filing issues, commenting and making pull requests)

Cheers,

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Oct 2016 21:06:15 +1100

I think it's worth emphasizing that in the WGs I am involved in that use
Github,
people do regularly produce published drafts prior to IETF [0], so you can
follow
the work in the way you always have, namely by reading the drafts and
commenting
on-list. Historically we've given draft editors quite a bit of discretion
in how they
edit the draft, with WG review of each published version as a primary
method of
determining consensus.

The primary impact of Github workflows, in my experience, has been to
provide
finer-grained validation of WG consensus (i.e., at the level of each pull
request),
and as Mark has indicated, the discussion of the general principle behind
substantive
changes usually happens on the list, with the details worked out in PRs.
The
result  is that when the drafts are published they already mostly have
broad consensus
for the general principle and consensus of the Github-following population
for the
specific text. This seems strictly more transparent than the process we had
before
where editors mostly made the changes they thought were appropriate and then
we validated them in meetings.

-Ekr

[0] And in some cases more regularly because the workflow tends to keep the
documents in "always shippable" shape, so producing drafts is cheaper.

On Fri, Oct 28, 2016 at 8:55 PM, Mark Nottingham <[email-masked]> wrote:

> 1) Just follow the WG mailing list, and become aware of things that
> happened in Github through the drafts and on-list change summaries /
> notifications

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 28 Oct 2016 12:15:54 +0200

> Could a second companion list be set up for the notifications? SO that the people who don't want to be on github can subscribe to it and interact that way?

We did that for WEBRTC, before switching to "the list gets notified of
new and closed issues". Only two persons ever subscribed.

I can't explain that....

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 28 Oct 2016 12:18:49 +0200

On 10/28/2016 02:41 AM, Martin J. Dürst wrote:
>>> Could one copy issue tracker and PR notifications to the mailing
>>> list? Or would that drive the list crazy?
> In the Internationalization WG of the W3C, we also had this problem,
> and changed it so that only the creation of an issue and the closing
> of an issue is reported to the mailing list (there's a separate
> archival mailing list to avoid the problems discussed at
> (Most if not all of the actual investigation and setup work has been
> and is done by Richard Ishida, the I18N Activity Lead.)
>
> subscribe to the github issue if you think you're interested, and
> you'll get a last chance to check how things went when the issue is
> closed.

We have done that in the WEBRTC WG and the Media Capture TF too, but
it's still too many mails when the editors are active - check out the
display here:

https://lists.w3.org/Archives/Public/public-media-capture/2016Oct/

All the messages that start with [mediacapture- are from github.

Another problem we have is that we have branching issues - issues raised
in other bugtrackers for other specs - in the mailing-list-only times,
these would be CCed to both groups' mailing lists, but in the github
times, there's no natural way to notify the WG that you're filing an
issue on their behalf in someone else's github.

The tagging stuff that i18n is doing may help there.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 28 Oct 2016 11:08:26 +0000

> 1) Just follow the WG mailing list, and become aware of things that happened
> in Github through the drafts and on-list change summaries / notifications

Not clear to me where you intend/want discussions to happen.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Oct 2016 10:44:12 -0400

Ekr,

Comment at end.

On 10/28/16 6:06 AM, Eric Rescorla wrote:
> people do regularly produce published drafts prior to IETF [0], so you
> can follow
> on-list. Historically we've given draft editors quite a bit of
> discretion in how they
> finer-grained validation of WG consensus (i.e., at the level of each
> pull request),
> and as Mark has indicated, the discussion of the general principle
> behind substantive
> for the general principle and consensus of the Github-following
> population for the
> specific text. This seems strictly more transparent than the process we
> had before

What you describe seems reasonable to me, but one aspect of it seems 
likely to be controversial. In particular, there seems to be a 
difference of opinion on how editors are to decide the details of 
changes and then deliver them to the wg:

1)

1a) an issue is raised on the wg mailing list;

1b) it is discussed there until it is clear what change is needed;

1c) the editor describes the change in some detail on this list;

1d) the group agrees and the editor publishes a new version with that 
change.

1e) there are typically no surprises about whether the change is what 
the wg expected, except possibly minor editorial stuff.

2)

2a) an issue is raised on the wg mailing list;

2b) it is discussed until the editor says: "I can take it from here";

2c) the editor then publishes a revised draft with his proposed text 
addressing the issue;

2d) then the wg discusses the new version;

2e) if necessary further issues are raised to "fix" it, or a decision is 
made to roll back the change.

Personally I think both approaches have merit - it depends on the state 
of the document and the sorts of issues being considered. (For instance, 
changes that require major restructuring of the document really can't be 
done via (1).) But some people seem to have a near-religious attachment 
to (1).

The way you describe using github seems to align with (2), but not so 
much with (1).

Of course the situation is very different for *individual* documents. 
Before they come under wg control the authors can work together however 
they want.

	Thanks,
	Paul

> On Fri, Oct 28, 2016 at 8:55 PM, Mark Nottingham <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     > On 27 Oct. 2016, at 2:58 am, Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ietf-and-github>
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Oct 2016 08:39:35 +1300

> Not clear to me where you intend/want discussions to happen.

And that's the point. Under IETF rules, if the discussion didn't happen
on the WG mailing list, it didn't happen. So any discussion that only
takes place on github (or any other tracker) doesn't count; it's just
private chatter.

Note, I'm not saying that private chatter isn't allowed during document
development. I do it all the time. I'm just saying that it doesn't determine
WG consensus and it can be ignored or overridden by the WG. There's nothing
new here; github is just another tool.

    Brian

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 28 Oct 2016 13:43:35 -0700

On 28 Oct 2016, at 12:39, Brian E Carpenter wrote:

>>> happened
>>> 3) Just engage on Github (e.g., by filing issues, commenting and 
>>> making pull
>>> requests)
>>

Nothing in the list above says "WG consensus". It is about what appears 
in a draft. There are plenty of examples of things appearing in drafts 
because someone asked for something, the author agreed, it went in, and 
the the WG says "no, take that out".

I'm being specific here because you are equating a tool that allows 
people to see how a document develops better than they ever have as 
"private chatter". It's not private, and that's the point. Document 
development is not the same was WG consensus development, although they 
are clearly related.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 29 Oct 2016 08:51:48 +1100

On Sat, Oct 29, 2016 at 1:44 AM, Paul Kyzivat <[email-masked]> wrote:

> likely to be controversial. In particular, there seems to be a difference
> of opinion on how editors are to decide the details of changes and then
> deliver them to the wg:
>
> 1)
>
> 1e) there are typically no surprises about whether the change is what the
> wg expected, except possibly minor editorial stuff.
>
> 2)
>
> Personally I think both approaches have merit - it depends on the state of
> the document and the sorts of issues being considered. (For instance,
> done via (1).) But some people seem to have a near-religious attachment to
> (1).
>

They may have such an attachment, but I'm unaware of any IETF rules that
require it. It's up to the WG.

> The way you describe using github seems to align with (2), but not so much
> with (1).
>

To the contrary. Github makes the first flow practical whereas before it
was not (after having
tried to do it many times).

-Ekr

>>     > Are all the participants on the mailing list assumed to be
>> following what is going on in github? Or can wg members be fully engaged
>> just following the mailing list?
>>
>>     making pull requests)

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 29 Oct 2016 09:00:01 +1100

FWIW - in httpbis, we use both approaches, depending on the situation.

> On 29 Oct. 2016, at 1:44 am, Paul Kyzivat <[email-masked]> wrote:
> 
> Ekr,
> 
> Comment at end.
> 
> What you describe seems reasonable to me, but one aspect of it seems likely to be controversial. In particular, there seems to be a difference of opinion on how editors are to decide the details of changes and then deliver them to the wg:
> 
> 1)
> 
> 1d) the group agrees and the editor publishes a new version with that change.
> 
> 1e) there are typically no surprises about whether the change is what the wg expected, except possibly minor editorial stuff.
> 
> 2)
> 
> 2c) the editor then publishes a revised draft with his proposed text addressing the issue;
> 
> 2e) if necessary further issues are raised to "fix" it, or a decision is made to roll back the change.
> 
> Personally I think both approaches have merit - it depends on the state of the document and the sorts of issues being considered. (For instance, changes that require major restructuring of the document really can't be done via (1).) But some people seem to have a near-religious attachment to (1).
> 
> The way you describe using github seems to align with (2), but not so much with (1).
> 
> Of course the situation is very different for *individual* documents. Before they come under wg control the authors can work together however they want.
> 
> 	Thanks,
> 	Paul
> 
>> -Ekr
>>

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 29 Oct 2016 09:01:10 +1100

> On 28 Oct. 2016, at 10:08 pm, Salz, Rich <[email-masked]> wrote:
> 
> 

See:

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Oct 2016 11:28:21 +1300

> development is not the same was WG consensus development, although they 

Paul, in the IETF, if it isn't on the WG list (or in a minuted meeting),
it *is* private, as far as the IETF process is concerned. That is very
clear in RFC2418; the fact that some people find github to be a useful
tool doesn't affect that. As far as I can see there is a complete analogy
with a design team mailing list with a public archive: it's available
to the WG, but design team decisions made on that list do not bind the WG.

So, if the github users choose to cc the WG list on all issue traffic,
the IETF rules apply, and everybody gets annoyed by the emails. If the
github users don't cc the WG list, any decision made via github needs
to be reported back to the WG - quite possibly by posting a new version
of the draft, with a change log. That's all I'm trying to say: github
changes nothing in IETF rules (unless we decide to update RFC2418).

   Brian