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

["Joel M. Halpern" <[e-mail]>]

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.  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.

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
>