Re: Old directions in social media.

[Keith Moore <[e-mail]>]

On 1/5/21 2:58 PM, Kyle Rose wrote:

> On Tue, Jan 5, 2021 at 1:30 PM Keith Moore <[e-mail] 
> <mailto:[e-mail]>> 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.

>
> 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.
GitHub is not at all representative of a good engineering tool, much 
less a good tool for collaboratively editing text.

Keith