The good thing is that there is no real problem here. In most working groups a limited number of people actively participate. Those people know how to contribute. For those who just browse through groups from time to time it got more difficult to see where the center of attention currently is. While participation on IETF mailing lists is free of charge, it still consumes a fair amount of time. Ciao Hannes -----Original Message----- From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of Theodore Ts'o Sent: Tuesday, January 5, 2021 11:52 PM To: Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> Cc: IETF Discussion Mailing List <ietf@xxxxxxxx> Subject: Re: Old directions in social media. 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. Cheers, - Ted IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
