Re: [Ietf-and-github] Tracking drafts

["Martin Thomson" <[e-mail]>]

On Thu, Feb 13, 2020, at 03:57, STARK, BARBARA H wrote:
>  
> >  * This patch is well-meaning, but it does not meet the IESG guidelines for design teams. For example, it enables completely closed groups that throw their output over the fence into Github. The edit does say "open participation", but that's not really defined. In particular, the IESG design team recommendations require named members, and periodic reports.
> 
> > Perhaps adding “(such as making the repo public)” fixes that.
> 
> 
> Since it costs money to make a GitHub repo private [...]

GitHub recently made private repositories available to all users, albeit with restrictions that might make them awkward to use for design teams.  And a good number of people I work with pay GitHub for a "pro" account, so finding a sponsor likely wouldn't be that difficult.  So finding a private repositories might not be that hard.

So I'm inclined to take Rich's suggestion here, if only because it clarifies intent better.  I've updated the PR.

> If people want to set up a private and paid-for repo to stage changes 
> before putting them in an IETF repo, I think it will be hard to stop 
> them and I’m not convinced they would be doing something wrong. 
> Or am I an anomaly and misbehaving when I communicate with fellow draft 
> authors off-list using direct email? Is *all* communication between 
> draft authors and design team members required to be public? This is 
> news to me. 

This is fine.  But the purpose of the document is to address Working Group procedures.  We can't stop private communication and nor should we, but under the auspices of "official business", it is good to keep formal deliberations public.

This wouldn't stop a Working Group from forming a design team that uses a private repository.  But then it wouldn't be following the guidance in this document.  That too is fine by existing rules, even if I would personally prefer to retain the accountability conferred by keeping discussion public.

> I have to say I’m very much opposed to over-specifying and 
> over-constraining how WGs use GitHub in order to prevent hypothetical 
> problems. 

I don't see this as specifying anything, just explaining the perspective the draft adopts and how that fits into the existing formalisms.