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

[Eric Rescorla <[e-mail]>]

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
>