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

From: Alissa Cooper <[email-masked]>
Date: Wed, 2 Jan 2019 15:49:13 -0500

Thanks to Martin for writing text and to everyone for your feedback. Looks like this had settled pretty well before the holidays, so I have stuck it in the datatracker: <https://datatracker.ietf.org/doc/charter-ietf-git/>. I’ll initiate the IESG review to kick off the chartering process next week unless I hear objections on this list.

Note: I named this mailing list as the WG mailing list. But if people would prefer to maintain a separate mailing list for the WG and use this one for more general discussion (?), please say so and I can change it.

Thanks, happy new year,
Alissa

---

From: Bret Jordan <[email-masked]>
Date: Wed, 2 Jan 2019 14:30:47 -0700

Martin,

I really appreciate your comments and the manner and way you responded to my concerns. I can go along with this, but I will try and keep beating the drum of "ease of use" and "easy to follow/understand what is going on".   

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."

> On Dec 30, 2018, at 10:39 PM, Martin Thomson <[email-masked]> wrote:
> 
> 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.
> 
> _______________________________________________
> Ietf-and-github mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-and-github

---

From: Martin Thomson <[email-masked]>
Date: Thu, 3 Jan 2019 10:41:20 +1100

> Note: I named this mailing list as the WG mailing list. But if people would prefer to maintain a separate mailing list for the WG and use this one for more general discussion (?), please say so and…

This list is good.

Thanks for getting this started.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 4 Jan 2019 00:06:33 -0600

I'm enjoying watching people work through important details on this topic,
but feel I should chime in on one point.

On Sun, Dec 30, 2018 at 11:39 PM Martin Thomson <[email-masked]> wrote:

> 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.
>
> 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.
>

Speaking as the responsible Spin Bit Area Director (along with some less
contentious work on transport protocols, hardly worth mentioning :)

Yeah, this can be a problem. Because I'm the responsible area director for
QUIC, I watch the working group mailing list pretty carefully looking for
"but we talked about this in github"/"but we agreed on this at the interim"
posts.

These situations do happen. In the recent cases I've observed, document
authors recognized that there was an educational task, and a responsibility
to listen to objections and filter for NEW concerns, without much need for
chairs to intervene.

I was pretty sure this kind of thing would happen from time to time, and
picked chairs who I trusted to intervene when necessary. I didn't pick the
editors, but the chairs picked editors who have been responsive. So we have
an existence proof that it's possible to pull this off.

It may be that we're talking about a workflow we can't engineer a flawless
technique to handle, and we just have to work through the bumps. But no one
has talked to me about concerns that decisions were happening in github AND
objections were being ignored on the mailing list, at any point, so I think
we can work through most bumps, based on that experience. So, +1 on
Martin's "social contract", on all sides, and +1 on gathering and sharing
experience so we don't have to relearn these lessons in every working group
that picks up github.

When Jeff Schiller was doing the new chair training sessions in the late
1990s, he drummed "new and valid technical concerns are never out of order"
into me pretty thoroughly. I don't think using github changes that, at all.

Spencer

> 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.
>

---

From: Bret Jordan <[email-masked]>
Date: Fri, 4 Jan 2019 10:45:35 -0700

Great comments Spencer. Being cordial and professional is always key.  Listening to others opinions and points of view is critical to building solid standards that get adopted en mass.   If we can all just keep that mindset and realize that other people’s use-cases are valid, even if we personally do not like them, I think we can really take a step forward.

Thanks,
Bret

> On Jan 3, 2019, at 11:06 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> I'm enjoying watching people work through important details on this topic, but feel I should chime in on one point. 
> 
> On Sun, Dec 30, 2018 at 11:39 PM Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> Speaking as the responsible Spin Bit Area Director (along with some less contentious work on transport protocols, hardly worth mentioning :) 
> 
> Yeah, this can be a problem. Because I'm the responsible area director for QUIC, I watch the working group mailing list pretty carefully looking for "but we talked about this in github"/"but we agreed on this at the interim" posts. 
> 
> These situations do happen. In the recent cases I've observed, document authors recognized that there was an educational task, and a responsibility to listen to objections and filter for NEW concerns, without much need for chairs to intervene.. 
> 
> I was pretty sure this kind of thing would happen from time to time, and picked chairs who I trusted to intervene when necessary. I didn't pick the editors, but the chairs picked editors who have been responsive. So we have an existence proof that it's possible to pull this off.
> 
> It may be that we're talking about a workflow we can't engineer a flawless technique to handle, and we just have to work through the bumps. But no one has talked to me about concerns that decisions were happening in github AND objections were being ignored on the mailing list, at any point, so I think we can work through most bumps, based on that experience. So, +1 on Martin's "social contract", on all sides, and +1 on gathering and sharing experience so we don't have to relearn these lessons in every working group that picks up github. 
> 
> When Jeff Schiller was doing the new chair training sessions in the late 1990s, he drummed "new and valid technical concerns are never out of order" into me pretty thoroughly. I don't think using github changes that, at all. 
> 
> Spencer
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ietf-and-github <https://www.ietf.org/mailman/listinfo/ietf-and-github>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ietf-and-github <https://www.ietf.org/mailman/listinfo/ietf-and-github>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 5 Jan 2019 08:06:41 +1300

+1 to Spencer, but I suggest that one mitigation that we could
encourage is that when a Git issue is resolved, the final comment
on the issue should summarise the rationale for the decision.
That would make it much easier for a re-discussion to be resolved,
for example if the issue comes up in WGLC or IETF LC.

"We settled that because X" is a much better response than "We already
settled that."

   Brian

---

From: Bret Jordan <[email-masked]>
Date: Fri, 4 Jan 2019 12:38:27 -0700

Yes but we need to be careful here.  If we settled it via the Github Issue discussion where 30 people participated and 10 were against and 20 were for the change (thus we had rough consensus) and then it goes to WGLC or IETF LC and we get 5+ people against it (and no new people for it), that would mean that we did NOT have rough consensus as the numbers would be more like 20 to 15+  

I know we like to “think” that we do not vote here in the IETF, but the reality is that we do at some level. We try to hide that by “humming” during a meeting.  But we always say that we will take things back to the list for final review. If people speak up on the list, they are effectively voting and not “humming”, meaning they are now being singled out.

So perhaps what would be good is to say as the last response to the thread (like you said) here is the decision we came to, here is why we came to that decision, here were the number of people that supported it and here are the number of people against it (along with their views). 

We just need to be careful that we do not claim consensus in the end, if at the end we do not have it. This will require editors, chairs, and ADs to carefully monitor things and error on the side of understanding.  So all in all, I am just asking that we be mindful, patient, and understanding. 

Thanks,
Bret

> On Jan 4, 2019, at 12:06 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 4 Jan 2019 17:01:08 -0600

On Fri, Jan 4, 2019 at 1:38 PM Bret Jordan <[email-masked]> wrote:

> Yes but we need to be careful here.  If we settled it via the Github Issue
> discussion where 30 people participated and 10 were against and 20 were for
> the change (thus we had rough consensus) and then it goes to WGLC or IETF
> LC and we get 5+ people against it (and no new people for it), that would
> mean that we did NOT have rough consensus as the numbers would be more like
> 20 to 15+
>
> I know we like to “think” that we do not vote here in the IETF, but the
> reality is that we do at some level. We try to hide that by “humming”
> during a meeting.  But we always say that we will take things back to the
> list for final review. If people speak up on the list, they are effectively
> voting and not “humming”, meaning they are now being singled out.
>
> So perhaps what would be good is to say as the last response to the thread
> (like you said) here is the decision we came to, here is why we came to
> that decision, here were the number of people that supported it and here
> are the number of people against it (along with their views).
>
> We just need to be careful that we do not claim consensus in the end, if
> at the end we do not have it. This will require editors, chairs, and ADs to
> carefully monitor things and error on the side of understanding.  So all in
> all, I am just asking that we be mindful, patient, and understanding.
>

Right. ISTM that this conversation maps very well onto the Conflict
Resolution and Appeals Process in
https://tools.ietf.org/html/rfc2026#section-6.5. The QUIC working group,
and the editors, have been responsive to mailing list concerns about
directions that seemed fine in github and at interims. The community knows
what to do next, if they get that wrong, and Section 6.5 is there for a
reason - it's not surprising when someone catches a problem that other
people haven't seen yet.

Please check literally any IESG telechat's minutes and narrative minutes
for worked examples of people noticing things that other people haven't
seen yet, at https://www.ietf.org/about/groups/iesg/minutes/. It takes a
village.

Spencer

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 4 Jan 2019 18:49:55 -0600

> directions that seemed fine in github and at interims. The community knows

Indeed, and I would hope that anything that had 10 people against and 20
for in a github issue would be taking to the list (and maybe in person)
before the chairs thought it was anywhere close to finalized!

-Ben

---

From: Bret Jordan <[email-masked]>
Date: Fri, 4 Jan 2019 19:08:30 -0700

Great. I am on board. 

Thanks,
Bret

> On Jan 4, 2019, at 5:49 PM, Benjamin Kaduk <[email-masked]> wrote:
>