Re: [Ietf-and-github] WGLC: draft-ietf-git-using-github-02

[Mike Bishop <[e-mail]>]

True, lack of experience with CODEOWNERS might keep us from recommending it.  Noting its presence and potential usefulness, however, seems reasonable.  It might be worth turning it on in QUIC so that we can get some experience with it and have a more informed opinion.

-----Original Message-----
From: Ietf-and-github <[e-mail]> On Behalf Of Martin Thomson
Sent: Wednesday, December 4, 2019 12:34 AM
To: [e-mail]
Subject: Re: [Ietf-and-github] WGLC: draft-ietf-git-using-github-02

Thanks for reviewing Mike,

Your PR is: https://github.com/ietf-gitwg/using-github/pull/36

On Wed, Dec 4, 2019, at 09:05, Mike Bishop wrote:
> In section 3.2/3.3, it might be worth mentioning that GitHub  has a 
> feature 
> <https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners> for the owners/administrators to give certain user(s) control of individual files, despite the global write access that contributors have. This means it's possible to configure the SHOULD NOT on GitHub, rather than relying on everyone's good behavior. I think this configuration should be RECOMMENDED for multi-document repos.

That's a relatively new feature.  One that I note we aren't using in the two multi-document repositories I'm involved in.  I don't know enough about the limitations of that to say whether a recommendation there is a good idea or not.  At some level, I'm concerned that it will encourage more WGs to create single repositories, which I think are terrible.  That's probably not a great reason not to include it, but lack of experience with it should be.

> In section 4.0, we should probably include a reminder that, regardless 
> of the from of contribution, all contributions are covered by the Note 
> Well. (I know that’s implied by the term, but it’s worth being
> explicit.)

In https://github.com/ietf-gitwg/using-github/pull/33 in response to Rich's review I moved that around a little.  The emphasis being on the notices and not the contributions.  Is that the wrong angle?  Both of you picked Section 4.
 
> In section 4.3, is it truly the WG that provides these facilities at 
> the chair’s request? This seems like something that either a) chairs 
> MAY configure independently at the WG’s request, or b) something that 
> the IETF would provide at the chair’s request. The latter seems the 
> most sensible, but does represent a requirement for new functionality.

I struck the paragraph.  I don't think that we can say (yet) who needs to run that infrastructure.  That's a question we can resolve outside of a published document.

> In Section 7, I’m not certain about the “greater time commitment” 
> reasoning. There is an identical level of traffic coming into your 
> inbox regardless of whether the incoming deluge is e-mail or GitHub 
> notifications. And in fact, exactly the same discussions that take 
> place on GitHub *could* take place on the mailing list. The fact that 
> GitHub facilitates a greater pace of interaction and therefore 
> generates a greater volume of traffic is really what we’re alluding to 
> here. GitHub helps working groups work more quickly, and quicker work 
> risks leaving some people behind.

I'll reword.

> Appendix A.2 states that the quicwg has only two repos, but it in fact 
> has three. Another example of the ops drafts being ignored.

\o/  There are also other repositories now.

See my other email.  I don't know how much editorial control I can exercise over this text.  I think that I'd rather remove these sections now that they have done their jobs.

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