Re: [Ietf-and-github] Warren Kumari's Discuss on draft-ietf-git-using-github-05: (with DISCUSS and COMMENT)

[Martin Thomson <[e-mail]>]

I will try to address Warren's questions here.  Apologies for the length; I promise this is not an amplification attack, I just have limited time to process this.

On the ideological questions, I have no answer.  I value pragmatism too highly.  (Separately, someone also pointed out that GitHub doesn't do DNSSEC, but neither does tools.ietf.org, so maybe that's not a principle we can stand our ground on :)

On Wed, Mar 11, 2020, at 04:45, Warren Kumari via Datatracker wrote:
> This smacks of scope-creep / chairs having control and
> process where it a: isn't needed and b: isn't helpful.

I get that this goes a long way into examining the details of the process, likely far more so than our previous documents.  But I hope that the document is clear how that should be consensual: a WG for which the detailed process is not suitable can operate as before.  Indeed, in working groups that follow the more involved processes described here there are a few participants who pay none of the GitHub stuff any mind and that doesn't disadvantage them at all.  It's document editors and chairs who sometimes need to manage any impedance mismatch in that case.

Frankly there are places where I personally have felt the creep as a negative thing.  Part of that is a consequence of finer-grained visibility into what is going on and part of that is in feeling out the process.  I don't always agree with the QUIC chairs about the direction they take on minor issues.  But I don't see that sort of tension as a product of *this* process, but just a natural tension between participants and chairs.

> 1a: [On the implication that GitHub is better]

I see what you mean here, but I don't see how to address that.  If your concern is about the publication of this document being used to bludgeon people into accepting these work practices against their will, I don't know how to further hedge against that (if you have specific suggestions, I'm happy to take those to the working group).  If your concern is that this doesn't fully acknowledge some costs that might be incurred by adopting this path, sure.

> 1b: [On dicing with updates to BCP 9]

I understand the reaction, but I don't agree with the implication regarding BCP 9.

You cited a case that I believe to be benign, in the sense that I believe it to be a restatement.  Would it help to avoid 2119 language in that case?  Do you believe that there are other such cases?

> 2: The focus on GitHub makes my deeply uncomfortable

The reasons for this have been litigated at length and a short synopsis of the conclusions are captured in the draft.  Discomfort is an expected side effect of the consensus process; see your doctor if symptoms persist.

> 3: 
> -- having WG "owned" repos *will* lead to instances where decisions get made in
> the issue tracker, and not communicated tp the mailing list

Given how much of the document is dedicated to addressing this risk, I don't know that anything more can be said here.

It is also true that hallway conversations, private chats and email threads, and conference calls are used to reach conclusions.  That is how we make progress on the most difficult issues often.  It might be oft-lamented, but it is effective.

Today, we rely on people catching the worst of that behaviour by reviewing documents, especially at WGLC or IETF LC.  None of that changes.  I'd argue that this approach improves the situation by giving a public venue to those side discussions, both by allowing others to jump in and by recording a transcript of events.

Finally, some of this has to be cultural.  We teach others to respect those not present by asking to take discussions to the mailing list in those cases that might benefit from wider discussion and by proactively doing so ourselves when we recognize the need.

> 4: git (and GitHub) has a really steep learning curve - if a WG decides to
> fully jump in and start using GitHub, this (either explicitly or implicitly)
> disenfranchises people who don't use or want to use git.

I should let those people who don't use GitHub speak here about the disenfranchisement point.

I agree with the learning curve thing.  git is truly abominable, but it's easier than learning a new language and it has fairly broad applicability in the industry.

> 5: Moving state (primarily issues) from a personal repo to a WG one when a
> document is adopted is non-trivial

That's interesting.  Yes, moving is not free, but I have never had serious problems.  I did have a chair decide that a fork was a good plan and that took some unraveling, though the deletion of the repo was probably the biggest problem.  On the other hand, moving has always worked for me, I usually only have to fix a couple of broken links to the old repo (for which I usually am able to use the same script I use to setup the repo in the first place).

> I think a much much better approach would be have people simple keep the
> documents in their personal repos and not have the disruption that moving the
> repo entails.

For models that have a lighter touch, that might be OK. There are some issues around ensuring that chairs control who edits documents and so forth though.

> Don't get me wrong - I like git, and a: host my own gitea instance, b: maintain
> a few gitlabs and gogs instances, and c: put all of my drafts in GitHub - but I
> really don't think that the IETF should be implying that this is the "one true
> way" (BCP) (nor do I like the WG hosted model).

This last view (in parentheses) was expressed during early working group sessions and the view of the group was that a single org would be too unwieldy.  Even organizations who adopted that model early on, like the W3C, have moved more to independent GitHub orgs.

Thanks for your input.