Re: Old directions in social media.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



hi,

but still no way to export one from Drive?

speaking of cooperative work environments.

avri

On 2021-01-05 6:16 p.m., Fred Baker wrote:
Well, there is a way to write RFCs using Word; the hijinks one has to do in order to get ASCII output are a little daunting to me, but I believe they exist.

Go to https://www.rfc-editor.org/pubprocess/tools/ and search for “Microsoft”



Sent from my iPad

On Jan 5, 2021, at 2:52 PM, Theodore Ts'o <tytso@xxxxxxx> 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.

Cheers,

                   - Ted





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux