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

[Eric Rescorla <[e-mail]>]

On Tue, Mar 10, 2020 at 11:17 AM Joel M. Halpern <[e-mail]>
wrote:

> While I personally think this document should be approved (even though I
> have 0 desire to use github), I think we should be careful about what
> lens we use in looking at concerns.
> In particular, the discuss-criteria document does not deal with process
> documents.


This seems like a legitimate perspective, but when I read the DISCUSS
criteria, it seems to say that they apply to "Protocol Actions"  and this
document is listed in the Protocol Action section of the IESG Agenda (this
is confirmed by the draft announcement) [0]. So, if the IESG (or Warren)
wants to say that they don't think that the DISCUSS Criteria apply to
process BCPs, that seems like the place to start.

As written, if one were being a literalist, one would
> probably conclude that no AD could put a DISCUSS on any clear process
> document that made it thought IEtF last call.
>

I actually read this differently, which is that the DISCUSS criteria don't
apply at all to !Protocol actions and so ADs are free to DISCUSS for any
reason. However, for the reason above, I think that the DISCUSS Criteria do
apply here.

-Ekr

[0] https://datatracker.ietf.org/doc/draft-ietf-git-using-github/writeup/


>
> While one might argue that would be good, I am quite certain that was
> not the intent when the IESG adopted those rules.  Personally, I would
> like the ADs to be able to use judgment when reviewing process
> documents, just as they do with technical documents.
>
> Yours,
> Joel
>
> On 3/10/2020 2:01 PM, Eric Rescorla 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] <mailto:[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/ <http://www.github.com/wkumari/><document
> >     name> to
> >     www.github.com/capport-wg/
> >     <http://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] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/ietf-and-github
> >
> >
> > _______________________________________________
> > Ietf-and-github mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ietf-and-github
> >
>