On 8/2/19 10:03 PM, Benjamin Kaduk wrote:
I'm not going to fault groups that organically started using github.
(Though I hope they got AD approval before doing so.) Broadly speaking
I'm supportive of groups looking for better tools and better ways to
conduct discussions, though it's imperative that they follow process
(e.g. decisions are made on the mailing list) and that they maintain
openness and neutrality (e.g. github users should not be favored.)
I think I need to drill down into what "favored" means. It will presumably
be multifaceted and subtle, but are you thinking along the lines of "feel
more comfortable with the tools" or "'vote's get more weight" or "issues
raised get more prompt attention" or "non-github-users get ignored" or
other things? In particular, if we somehow could limit what happens to
"feel more comfortable with the tools", would that be problematic? (I make
no claim yet about how practical such a scenario would be to attain.)
I think it's problematic if people have to use github to participate
effectively in a WG, or even if github users have significant advantages
at providing input to the WG, especially if the privacy risks haven't
been evaluated and addressed.
It's one thing to ask people to learn new tools once in awhile. It's
another thing entirely if IETF participants are expected to have their
privacy compromised as a consequence of being able to participate.
I'm still trying to understand where things went wrong (in your
perception): should we have instead chartered a WG to consider how WGs
could use VCS in general (without prejudging as to external services or
self-hosted), with an early task being to determine whether external
services, and github in particular, are appropriate for use in the IETF?
Closer to that, I think. And if I were writing the charter I think I
would specifically task the group with identifying and evaluating risks
to IETF resulting from use of externally-hosted VCSs vs. self-hosted VCSs.
In a later reply you say "we shouldn't presume that github is the solution
just because it's currently popular", but I'm not sure that that matches up
what is happening. My perception is that yes, there is a presumption, but
that github is *a* solution, one of potentially many, and with a further
presumption that the WG cannot override existing BCP-documented procedures,
including that work is ultimately taken to the mailing lists. This one
got a WG because the people showed up to do the work.
Yes, but again, just because people showed up to work on github first
doesn't mean it's a good choice for IETF, and the charter of the git WG
does seem to presume that.
If we had two other WGs, one to discuss using tooling for using vim to
write XML sources for I-Ds directly, and another discussing tooling for
using emacs to write Markdown sources for I-Ds, is the main difference from
the GIT WG just that the tooling in question involves an external service?
I'm not sure if I'm missing anything from your argument/stance.
There are certainly additional risks (to both IETF in general and WG
participants) that result from IETF using and depending on an external
service that it does not control, and for which the terms and conditions
of use are subject to change at a whim, so that's part of my concern.
For a self-hosted service presumably IETF can establish terms which are
reasonable and consistent with its interests; if the service is
external, this is more difficult.
There are even more risks to IETF with depending on a vendor that has a
lot of influence in the market, and quite plausibly, a significant
conflict of interest with IETF's purpose.
Keith
