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

[Alissa Cooper <[e-mail]>]

Isn’t this really an objection to the entire WG and its charter, and not to this document specifically?

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
>