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

[Alissa Cooper <[e-mail]>]

Personally I would rather see this document switch to informational and move forward with publication. I don’t think the label “BCP” makes much of a difference, the point is just to document practices to make it easier for IETF WGs to get their work done. I would be curious what the WG thinks. 

Thanks,
Alissa


> On Mar 10, 2020, at 4:37 PM, Barry Leiba <[e-mail]> wrote:
> 
> In the spirit of what Warren says below (and an offlist conversation
> I've had with him), may I suggest that -- for the moment, at least --
> we avoid out-of-hand rejection of his DISCUSS as inadmissible, and
> instead have at least some of the discussion, with the goal of finding
> whether there's something we can say more or differently in the
> document that would allay his concerns?
> 
> Warren can always go back to "abstain" after that discussion... or
> even "no objection" if the discussion bears fruit.
> 
> Barry
> 
> On Tue, Mar 10, 2020 at 2:52 PM Warren Kumari <[e-mail]> wrote:
>> 
>> On Tue, Mar 10, 2020 at 2:39 PM Alissa Cooper <[e-mail]> wrote:
>>> 
>>> Isn’t this really an objection to the entire WG and its charter, and not to this document specifically?
>> 
>> Not really, but I will grant you that it is close...
>> 
>> A document which explained how to manage discussion between working
>> group mailing lists and GitHub issues and pull requests; how text
>> contributions are expected to be made; labeling and naming
>> conventions; maintaining readable draft snapshots; using tooling and
>> automation; informing participants about IETF policies; and other
>> information would be useful -- but this does more than that - it
>> pushes a (fairly) complex solution, and implies that it is the best
>> practice.  All of the above could still happen with documents at
>> www.github.com/billy-joe-bob, not www.github.com/ietf-important-wg,
>> with much less faff, and putting chairs in a "special" position.
>> 
>> W
>> 
>>> 
>>> Alissa
>>> 
>>> 
>>>> On Mar 10, 2020, at 2:36 PM, Warren Kumari <[e-mail]> wrote:
>>>> 
>>>> I'm going to take option C: "This cannot be an exhaustive list, but
>>>> this set should be taken as exemplary of the common causes for
>>>> DISCUSSes seen by the IESG in the past.".
>>>> 
>>>> W
>>>> 
>>>> On Tue, Mar 10, 2020 at 2:01 PM Eric Rescorla <[e-mail]> wrote:
>>>>> 
>>>>> Hi Warren,
>>>>> 
>>>>> I've got some thoughts about the merits of this DISCUSS comment, but before I do that, which of the DISCUSS criteria [0] do you think applies to this DISCUSS?
>>>>> 
>>>>> -Ekr
>>>>> 
>>>>> 
>>>>> [0] https://ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Tue, Mar 10, 2020 at 10:45 AM Warren Kumari via Datatracker <[e-mail]> wrote:
>>>>>> 
>>>>>> Warren Kumari has entered the following ballot position for
>>>>>> draft-ietf-git-using-github-05: Discuss
>>>>>> 
>>>>>> When responding, please keep the subject line intact and reply to all
>>>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>>>> introductory paragraph, however.)
>>>>>> 
>>>>>> 
>>>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>>> 
>>>>>> 
>>>>>> The document, along with other ballot positions, can be found here:
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-git-using-github/
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ----------------------------------------------------------------------
>>>>>> DISCUSS:
>>>>>> ----------------------------------------------------------------------
>>>>>> 
>>>>>> I originally balloted Abstain, but this is (and has been) bothering me enough
>>>>>> that I'm changing it to a discuss.
>>>>>> 
>>>>>> This feels like additional centralization / control / process, without good
>>>>>> justification. I happen to use GitHub for my documents (along with discussion /
>>>>>> agreement with co-authors), but in personal repos. Our documents include
>>>>>> something like: "[ This document is being collaborated on in Github at
>>>>>> https://github.com/wkumari/<draft-name>me>.  The most recent  version of the
>>>>>> document, open issues, and so on should all be available there.  The authors
>>>>>> gratefully accept pull requests. ]"
>>>>>> 
>>>>>> This document contains a lot of text about setting up, administering, etc a WG
>>>>>> organization / repos -- but there is no good justification (that I could find)
>>>>>> on what advantages this has over simply encouraging people use GitHub (because
>>>>>> it is easy, and well known), and keeping things in their own repos. If WG
>>>>>> documents include a pointer (like above) to the repo, everyone can find it, and
>>>>>> we don't need all this. This smacks of scope-creep / chairs having control and
>>>>>> process where it a: isn't needed and b: isn't helpful.
>>>>>> 
>>>>>> 
>>>>>> ----------------------------------------------------------------------
>>>>>> COMMENT:
>>>>>> ----------------------------------------------------------------------
>>>>>> 
>>>>>> I spent a while trying to decide between Abstain and DISCUSS.
>>>>>> 
>>>>>> I'm uncomfortable with much of this document:
>>>>>> 1: This a BCP, and strongly implies that this is the "right" way for working
>>>>>> groups to manage themselves and documents streams. The charter says: "Whether
>>>>>> working groups choose to use GitHub or the documented policies to support their
>>>>>> work will remain entirely at their discretion." - while the document does let
>>>>>> WGs choose, the BCP track strongly implies that this is the "best" way. I
>>>>>> happen to put documents that I author in git (hosted on GitHub), and use that
>>>>>> to collaborate with my co-authors, but this is *our* choice, imposing our
>>>>>> working process on others is a mistake - we have used the "as long at it can be
>>>>>> turned into the canonical format we don't care how you make it" paradigm for a
>>>>>> reason. If people create the XML in vim or emacs is, and should be entirely
>>>>>> their decision - telling people that the "right" editor is vi is wrong - and a
>>>>>> BCP does that...
>>>>>> 
>>>>>> The charter also says: "The documents produced by this group will not alter the
>>>>>> Internet Standards Process (BCP 9). They will describe how to work within it."
>>>>>> but the document sails very close to the wind in many places - e.g: "Working
>>>>>> Group chairs MAY request a revision of an Internet-Draft being managed on
>>>>>> Github at any time, in consultation with document editors." It has always been
>>>>>> clear that chairs can request revisions to WG documents; this doesn't change
>>>>>> it, but mentioning things like this simply muddies the water / makes more
>>>>>> places for people to have to check. Section 7 is an example place where is is
>>>>>> really dangerous - and I think comes close to trying to change BCP9.
>>>>>> 
>>>>>> 2: The focus on GitHub makes my deeply uncomfortable -- I get the argument that
>>>>>> it is the standard / best known hosted git provider (and, in my *opinion* the
>>>>>> right one for us to use), but there are many places where term "GitHub" applies
>>>>>> to "self hosted" solutions like GitLab / Gitea / etc. This feels very close to
>>>>>> the IETF recommending that WG participants sign the blue-sheets with a Bic pen
>>>>>> when all we need is some sort of writing implement. Just as one example:
>>>>>> "GitHub facilitates more involved interactions,..." this is true of gitea,
>>>>>> gitlab, bitbucket and many other tools -- calling out GitHub gives one tool
>>>>>> prominence and is not appropriate for the IETF to do.
>>>>>> 
>>>>>> 3: We require that all decisions be made on mailing lists - when people happen
>>>>>> to use GitHub to collaborate on documents and happen to use the issue tracker
>>>>>> to track issues, it is clear that this is just for their personal convenience
>>>>>> -- having WG "owned" repos *will* lead to instances where decisions get made in
>>>>>> the issue tracker, and not communicated tp the mailing list - this will end up
>>>>>> with two classes of users: those that keep checking the issue tracker, and
>>>>>> those that follow the mailing list and are surprised by the decisions made.
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> 5: Moving state (primarily issues) from a personal repo to a WG one when a
>>>>>> document is adopted is non-trivial -- "You can only transfer issues between
>>>>>> repositories owned by the same user or organization account. You can't transfer
>>>>>> an issue from a private repository to a public repository." and they have to be
>>>>>> (AFAIK), moved individually - this will likely lead to loss of state (I may
>>>>>> also have missed it, but I don't see anywhere in the document that talks about
>>>>>> migrating a document / repo from an individual to a WG hosted version, and what
>>>>>> should happen). I have a document which moved from hosted at
>>>>>> www.github.com/wkumari/<document name> to
>>>>>> www.github.com/capport-wg/<document-name> - this involved administrative
>>>>>> annoyance, loss of state, and annoyance - for no benefit that I could see. 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.
>>>>>> 
>>>>>> 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).
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Ietf-and-github mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/ietf-and-github
>>>> 
>>>> 
>>>> 
>>>> --
>>>> 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
>>>> 
>>> 
>> 
>> 
>> --
>> 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
>>