Document your org’s Use cases for INI terms and tools recommendations

[ddavisjones]

Defining how our organizations plan to utilize the content produced by INI will help us prioritize workstream activities and produce outcomes that are most meaningful to INI participants.

[jasonbrooks]

see #62 (comment)

[petermetz]

Tool (DCI lint) author here: My use case for a machine readable spec file is to sperate the technological concerns from the governance ones, e.g. as a tool author I can fix bugs/add features to the software that does linting, but for the questions/concerns/recommendations regarding the word list people would come to the INI.
Having this sort of separation of concerns would save a lot of duplicated effort in the different tools if they all maintained their own machine readable spec files, managed the pull requests to those, etc.

[celestehorgan]

Use case:

I am an open source organization that is looking to remove harmful language from my project to be more inclusive of all my contributors. However, I am not a language expert nor do I have the time to do the research.

As an open source organization leader, I want an external list of terminology I can reference and implement in my projects.

[waynebeaton]

It would be handy to have a list of the actual words that I should search for.

It would be handy to be able to leverage a machine readable form of the word list to automate our search through the Eclipse Foundation's documentation. My thinking is that if I run this periodically, it will discover any new words that are added to the list.

For example it would helpful if master-slave included a search-list (or similar) that contains master and slave (and, perhaps, variants like masters and slaves).

FWIW, I cobbled together a bash command-line to try a first pass at scanning all of our documentation (mostly asciidoc):

$ grep -oPiI "`wget https://inclusivenaming.org/word-lists/index.json -O - | jq -r ".data | .[] | select(.tier != \"0\") | .term" | tr '\n' '|'`|slave" -R .

It's a first pass and there's room for improvement (e.g., adding word boundaries in the expression). I can explain this if anybody cares, but the expression itself is not really the point.

The regular expression that gets generated from the word list is of this form:

abort|blackbox|blackhat-whitehat|blackout|blast-radius|cripple|disable|Evangelist|fair hiring practice|fellow|grandfathered|hallucinate|man-hour|man-in-the-middle|master|master inventor|master-slave|mastermind|parent child|red team|sanity-check|segregate|tribe|white-label|whitebox|whitelist|

In my expression, I tack an extra (missing) term on the end (which actually solves two problems).

If we had the list of actual search terms, it would be relatively simple to do more sophisticated things with, for example, an Eclipse plug-in (e.g., add warnings in the Problems view).