how about typography.symbols instead of me.symbols

[mbutterick]

I’d argue that the inclusion of specific author names in .proselintrc is generally unwise.

For example, butterick.symbols:

1. They're not butterick.symbols. I didn’t invent them. They are typography.symbols.
2. What if I changed my mind about them tomorrow? .proselintrc will be inaccurate.
3. What if a rock falls on me next week? .proselintrc will take on an elegiac air.
4. What if you want to add typography rules from my archenemy, kcirettub? Are you going to have kcirettub.symbols filed elsewhere from butterick.symbols? What if they conflict?

And so on.

An .rc file is about configuration. Therefore, the names in the .rc file should ideally create a logical, coherent, descriptive hierarchy, without reference to human beings, who are undependable.

[suchow]

Hi Matthew, big fan of your work.

I agree with you and think an overhaul of the organizational scheme for rules is in order — one that reflects the structure of language usage, not authority. I'd still like to attribute the advice to its source, because you all deserve credit for what I see as discoveries about what makes for successful communication. I think the best case would be to partner with people like you, including a link from snippet of advice to a fuller description (e.g., the relevant page of your book).

This issue is related to #325.

in re 1, we're on the same page.

in re 2, our policy would be to use the latest, deferring to you, the expert.

in re 3, that would be sad.

in re 4, yes, this is a problem that we've already started to have. See in particular garner.cliches, write_good.cliches, and gnu_diction.cliches. I think merging these in the reorganization would help.

[mbutterick]

you all deserve credit for what I see as discoveries about what makes for successful communication. I think the best case would be to partner with people like you, including a link from snippet of advice to a fuller description

Another dimension here is that your use of my name (and others) connotes a participation (that does not exist) and a correctness (that has not been verified). I have no idea whether a proselint report about butterick.symbols actually conforms to my advice. For all I know, you’ve implemented my advice incorrectly and proselint users are saying “wow, this butterick must be an idiot.”

Compare: in your academic research, you don’t “partner” with your sources. You cite them. The reason citation is a wise system is that it draws a boundary between the writer and the source, and allows the reader to compare them.

Of course, “a link from snippet of advice to a fuller description” is a citation. Though I’m fine with having my work cited — that is one purpose of a reference work — it should also be made clear where my advice ends and proselint begins. butterick is neither here nor there.

[suchow]

Closing this because it has been resolved through a complete overhaul of the error-code naming scheme. It now reflects the structure of advice found in usage guides like Butterick's (e.g., there is a typography module). References are cited in the full JSON output, and all the statements we make about our connection to these references is that they have inspired our work. I hope that one day Proselint captures the advice of experts like Butterick so thoroughly that they endorse the tool wholeheartedly. We certainly aren't there yet — a few more decades of work is needed.