On 1/5/21 2:58 PM, Kyle Rose wrote:
On Tue, Jan 5, 2021 at 1:30 PM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
On 1/5/21 12:46 PM, Kyle Rose wrote:
> There are still two separate last calls for all WG documents: WGLC and
> IETF LC. Even if you never followed the issues or performed periodic
> reviews of document revisions prior to those checkpoints, you can
> always do it then.
Those are the LEAST effective ways of contributing to a document, the
LEAST likely to produce an improvement, and also the most annoying ways
of contributing that are likely in practice to create pushback and limit
one's effectiveness in IETF overall.
This is just the last possible gate, "if you never followed the issues or performed periodic reviews of document revisions prior to those checkpoints". You can always review documents periodically as new revisions are posted to the data tracker, and engage on the mailing list for certain topics. If anything, GitHub keeps noise (nits and whatnot) off the list by moving it to a tool much better suited to offering and vetting those kinds of changes.
No, GitHub unfairly biases against participants who aren't
already familiar with one particular set of open source tools and
culture.
And I'll emphatically disagree with your latter statement also,
because suggesting diffs of text in any form is only an effective
way of contributing at a fairly late stage of a document's
development. And I would submit that nitpicking text too soon is
harmful to producing a good document and impedes getting the
document done and/or degrades document quality.
Having said that I don't disagree that at a late stage of document editing, submitting diffs can be a good way of contributing. But expecting people to do this via GitHub is just adding yet another barrier to participation for most participants, in addition to sometimes making other barriers (like the need to use xml2rfc or some other obscure markup language) worse.
> Yes, they're useful as last resorts, but the fact that they exist is not a justification for
> crippling most potential contributors.
The only crippling being proposed here is to prohibit the use of GitHub. Adding tools that some choose not to take advantage of is not the same thing, no matter how many times you try to frame it like that. I'd agree with a softer statement like "The use of GitHub is not an unalloyed good for every possible contributor", but literally any process change is going to advantage some in comparison to others. I don't see why that alone should be the criteria on which this question is decided. Even on the basis of inclusion, "resistant to change" is not a protected class in any jurisdiction I know of. I like the current approach of WGs individually choosing whether or not to use it on the basis of the preference of participants.
I'm not sure that even I want to prohibit GitHub entirely, but I
think it's fair to recognize that it creates some problems and
exacerbates others. It's a LOUSY user interface.
We're supposed to be a consensus-making organization, and any unnecessary barrier that impairs the ability of some people to contribute effectively makes any claims of consensus dubious at best. Granted that GitHub isn't the only such barrier, but we were a much fairer organization when everyone used email.
GitHub is not at all representative of a good engineering tool, much less a good tool for collaboratively editing text.
More generally, as much as the content of this list would confuse aliens about where it lives, this is not the Internet Buggy Whip Task Force: it's the Internet *Engineering* Task Force. Contributors are (and should be) overwhelmingly engineers, and so it's natural for them to prefer engineering tools and workflows. Stop complaining; be an engineer; figure out the tools; and contribute.
Keith
