On 1/5/21 5:51 PM, Theodore Ts'o 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!
I would only make that claim if participants were expected,
encouraged, or could participate more effectively if they
submitted contributions in nroff, xml, or Word, respectively.
But if such contributions were expected or favored, I'd make that
claim equally for any of those tools.
I certainly would not argue that IETF should encourage WG editors
to use nroff or that contributions in nroff are in any way
appropriate. Though I found nroff reasonably effective in its
day, even better than xml2rfc in some ways, it's yet another
obscure and specialized interface that is not particularly well
suited to collaboration.
(And even though nroff was perhaps the best tool to write I-Ds for
a long time, especially for UNIX/Linux users who might already
have reason to be familiar with the format, I don't actually
recall anyone ever being expected or encouraged to contribute to a
discussion about a document using nroff.)
Right. And I don't think that occasionally working out tricky problems on the back of a napkin (or on a laptop) in a restaurant or bar is a Bad Thing, as long as it's subject to review on a mailing list. But we have had cases in which participants were effectively excluded in various ways - such as by holding lots of interim meetings (f2f or virtual) such that participation was effectively limited to people paid by their employers to participate. Over-reliance on GitHub [for example, using it as a medium of discussion] is just another way that capable participants can be effectively excluded.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.
Yes it does "seem" like that, and probably works that way in practice, so long as it happens rarely enough that it doesn't effectively limit participation - reducing the people "in the loop" so to speak to those who use that particular tool.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.
Interesting analogy. But while we've proven for decades that we can work effectively without github, I'm not sure we've figured out how to collaborate globally without a common language. Of course discussions do occur in languages other than English, but I've rarely seen mailing list discussions in languages other than English.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.
(I do think it's unfortunate that non-English speakers are at somewhat of a disadvantage in IETF. But one person who was not a native English speaker said to me "Using English is a lot like using a standard protocol". Who knows, maybe automatic translation is now good enough that we could each subscribe to mailing lists in our preferred language. It would be an interesting experiment.)
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.
Mostly I'm ok with editors using whatever tools they
mutually agree on, as long as this doesn't effectively exclude
some people from being editors. As long as the editors are
reasonably flexible in what arrangements they'll except it
probably works out ok. (My guess is that the choice of
editing/collaboration tools won't be as contentious as the
prose.)
My issue is mostly with the editors or WGs encouraging ordinary participants to use tools that effectively limit participation.
To take a step back: For literally decades I've wondered: How
can IETF reduce barriers to participation? When I first started
in IETF the biggest barrier to participation was the need to have
access to email and the cost of occasional travel to meetings (you
could participate effectively without actually attending, but it
really helped to have met people in person at least once). Over
the years I've seen participants expected to jump through more and
more hoops, and overcome more and more barriers, in order to
participate effectively: Higher meeting fees (until 2020's virtual
meetings and fee waivers [thanks!], but now timezones are actually
a bigger barrier); HTML emails making annotated replies harder
(sigh); many new constraints imposed on drafts by the submission
tool (some of them previously enforced by hard working humans);
xml2rfc (which if not absolutely required is still often
expected); the language police; and now github. Most of these
seemed like Good Ideas at the time, I don't think any of them were
originally malicious in intent. But together it appears MUCH
more difficult to participate in IETF now than ever in its
history. And while I want to acknowledge the hard work that many
have put in for decades to lower these barriers (I remember when
there were NO remote participation options though occasionally
there would be a speaker in a WG meeting via a very expensive
international cell phone call); to me that seems like despite all
that work, and despite all of the amazing advances in technology,
the situation has still worsened considerably.
I keep wanting to find ways to let people contribute in the ways
that are most natural to them, using tools that are familiar to
them, or at least something close to that.
Keith
