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

Warren Kumari via Datatracker <noreply@ietf.org> Tue, 10 March 2020 17:45 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ietf-and-github@ietf.org
Delivered-To: ietf-and-github@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 078073A0101; Tue, 10 Mar 2020 10:45:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-git-using-github@ietf.org, git-chairs@ietf.org, ietf-and-github@ietf.org, Christopher Wood <caw@heapingbits.net>, caw@heapingbits.net
X-Test-IDTracker: no
X-IETF-IDTracker: 6.120.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Warren Kumari <warren@kumari.net>
Message-ID: <158386231480.15427.9414945774814479191@ietfa.amsl.com>
Date: Tue, 10 Mar 2020 10:45:14 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-and-github/Ws7KFcN4HnRickVIMVn_KeEGar4>
Subject: [Ietf-and-github] Warren Kumari's Discuss on draft-ietf-git-using-github-05: (with DISCUSS and COMMENT)
X-BeenThere: ietf-and-github@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Discussion of using GitHub in IETF activities, particularly for Working Groups" <ietf-and-github.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-and-github>, <mailto:ietf-and-github-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-and-github/>
List-Post: <mailto:ietf-and-github@ietf.org>
List-Help: <mailto:ietf-and-github-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-and-github>, <mailto:ietf-and-github-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Mar 2020 17:45:16 -0000

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