[Ietf-and-github] Warren Kumari's No Objection on draft-ietf-git-using-github-06: (with COMMENT)

[Warren Kumari via Datatracker <[e-mail]>]

Warren Kumari has entered the following ballot position for
draft-ietf-git-using-github-06: No Objection

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/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Balloting closed for this document a while back, and so this is purely a
symbolic act, but with the change from BCP to Informational, I'm changing my
position from Abstain to No Objection. I still don't love this document, but
the authors and WG have carefully considered the questions raised, and made
changes to address them. The status change addresses my largest source of
discomfort and I'm signaling that with a (pointless) ballot position update...

---
Previous (2020-03-11) position:

I still don't love this, but I changed from DISCUSS to Abstain -
https://github.com/ietf-gitwg/using-github/pull/46 ,
https://mailarchive.ietf.org/arch/msg/ietf-and-github/vnXiskU2VGIx8VenEP34GWGfOwM/

I recognize that my opinion does not trump WG / IETF consensus, so I'm holding
my nose on this one. While I'm on this soapbox, I'd like to thank the authors
for listening to, and trying to address my concerns.

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