Re: Old directions in social media.

[John C Klensin <[e-mail]>]

(top post)

Ted,

I agree with all of this as long as github (or whatever) is a
tool for document editors to do their work and as long as all of
the substantive [1] decisions that inform that work are
documented and, as needed, debated, on the relevant mailing
list.  I am almost certainly not speaking for those who are more
convinced that github is a wonder and efficient tool when I
suggest that we cross some very unfortunate boundary when what
appears on a mailing list is equivalent to "anyone who does not
agree with the reasoning and conclusions reached in XYZ needed
to speak up".  In that regard, it makes no difference whether
"XYZ" is github, "our last interim meeting in a timezone that
was inconvenient for some readers", or something else -- the
effect is exclusionary and makes claims of consensus far more
dubious.

    john



[1] It has been the practice of many WGs and document editors
over the years that suggestions that are purely editorial in
nature can be made by off-list communication with the editor(s).
Using github or, for that matter, smoke signals for similar
input does not seem harmful as long as those editors are
comfortable with it.

--On Tuesday, January 5, 2021 17:51 -0500 Theodore Ts'o
<[e-mail]> wrote:

> On Tue, Jan 05, 2021 at 03:30:52PM -0500, Keith Moore wrote:
>> 
>> No, GitHub unfairly biases against participants who aren't
>> already familiar with one particular set of open source tools
>> and culture.
> 
> Some I-D's are written in NROFF, some in XML; does that mean
> they are biased against people who don't know NROFF or XML?
> Some standards organizations use Microsoft Office to draft
> their documents.  Bias! Unfair!
> 
> Hardly.
> 
>> 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.
> 
> I'm not aware of any working group where the only way to
> propose a change is by submitting a Github pull request.  I
> would expect discussions on the mailing list would talk about
> the changing in wording of a paragraph or too, or some kind of
> meta change in English (let's use the word XXXX instead YYYY
> everywhere in the document since it's clearer...).
> 
> If large numbers of discussions are happening outside of the
> mailing list, whether it be on a Github forum, or on Slack,
> sure that can be a problem.  Although that happens when people
> chat over a restaurant table back when it was to have
> face-to-face meetings; so long as such discussions are
> confirmed on the mailing list, I don't think we've ever
> disallowed discussions of a spec in venues where not everyone
> was able to participate --- such as at a restaurant during a
> face to face meeting.
> 
> To have the document editor use a particular tool, and to allow
> *optional* access by those who happen to know that tool?  That
> seems completely reasonable to me.  The fact that people who
> can use a particular tool to reduce effort required of the
> document editor seems to be a *feature*, not a bug.  Does that
> give them an advantage? Perhaps, in the same way that a person
> who is fluent in English has an advantage to those that don't.
> But I don't view that as a fatal bias in the process because
> some speak English fluently (or understand NROFF, or XML, or
> BNF), and some do not.
> 
>> > 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.
> 
> I'd suggest that we leave that decision to the document
> editors.  If there are people who are actively choosing
> GitHub, I'd gently suggest to you that perhaps they have a
> difference of opinion than yours; and we should let the people
> who are doing the work use what tools they find most powerful.