Provide means to flag non-inclusive language

[fviernau]

Flagging non-inclusive language in ORT can make it easy for companies to enforce their respective policy. ORT may examine the code as well as the VCS history (e.g. prior to open sourcing a project).

Details TBD, as starter see e.g. [1].

[1] https://github.com/dialpad/inclusive-language

[nicorikken]

Woke is a tool that already exists to help with checking inclusive language. Also relevant the Inclusive Naming Initiative that facilitates discussion on inclusive language to hopefully come to a more definitive set of terms that should be avoided.

I dislike the ever expanding scope of ORT, but if this feature is desired it shouldn't be too hard to integrate the Woke software in ORT.

[tsteenbe]

@nicorikken Bit of background on this feature - for compliance purposes we always wanted to be able to check project's Git history and source code for internal (product) code names prior to open-sourcing. We also wanted to do inclusive naming checks and both of them needs a string-based search scanner.

Not sure if Woke can also check VCS commit history.

[nicorikken]

At least it is possible via git bisect, which is a use-case that is discussed here: https://github.com/get-woke/woke/issues/85#issuecomment-864507254

[sschuberth]

I dislike the ever expanding scope of ORT

I'm also a bit skeptical here... esp. when going as far as checking for things like inclusive language.

for compliance purposes we always wanted to be able to check project's Git history and source code for internal (product) code names prior to open-sourcing

I believe the whole "prior to open-sourcing" workflow is one that's different enough from our original / main "open source compliance" workflow that it at least justifies another tool in ORT (maybe something like a "publisher" / linter), and is probably not something that should be mangled into the advisor. Or, the existing advisor should be largely refactored to be explicitly designed to support very different kinds of advises (more than just vulnerabilities and defects currently).

[tsteenbe]

@sschuberth it would not be an advisor but more a new scanner plus new evaluator helper functions as non-inclusive language or "compliance string" checks are commonly only done on the source code / VCS history

[sschuberth]

@fviernau, @tsteenbe, now that we have a ProjectSourceRule, would it be fair to close this very specialized use-case in favor of saying it's up to the user to write evaluator rules that use ProjectSourceRules to inspect the project's source code / VCS history?

[sschuberth]

Closing this as agreed on in today's Community Meeting as it's too specific for a first-class feature and can already be implemented via Evaluator rules.