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

[Eric Rescorla <[e-mail]>]

Warren,

Thanks for your response. While it's true that the list cannot be
exhaustive, it seems to me that your DISCUSS comments pretty clearly fall
within the "non-criteria" bucket, specifically

"Disagreement with informed WG decisions that do not exhibit problems
outlined in Section 3.1 (DISCUSS Criteria)
<https://ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-disc>.
In other words, disagreement in preferences among technically sound
approaches."

and potentially

"Reiteration of the issues that have been raised and discussed as part of
WG or IETF Last Call, unless the AD believes they have not been properly
addressed."

I note that the non-criteria do not contain the escape hatch you cite here,
but rather say clearly:
"None of the following are criteria for which the IESG should DISCUSS a
document; though they might reasonably form the basis of a non-blocking
comment on a document."

-Ekr




On Tue, Mar 10, 2020 at 11:37 AM 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
>