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

[Brian E Carpenter <[e-mail]>]

Hmm Warren. This seems to match https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-undisc much better than https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-disc

Regards
   Brian Carpenter

On 11-Mar-20 07:51, Warren Kumari 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
>>>
>>
> 
>