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

[Warren Kumari <[e-mail]>]

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