Using inclusive language in our patterns to make sure that everybody feels welcome

[spier]

I saw in another project that they were automatically checking the writing for inclusive language using the in-solidarity-bot.
That seems like a great idea, and something that we should apply to our patterns to, in order to make sure that everybody feels welcome and motivated to contribute.

I don't know exactly how these work but this is what I found in the other project:

• https://github.com/jpoehnelt/in-solidarity-bot
• https://github.com/SAP/project-portal-for-innersource/pull/25/checks?check_run_id=3035586556

[spier]

@Michadelic I was wondering if you could share your experience with the in-solidarity-bot, assuming that you set it up for the project-portal-for-innersource?

Also any feedback about this issue here in general?
Specifically i am wondering if you think said bot could be useful for our patterns here?

[Michadelic]

Hi @spier, that does not ring a bell, i assume that was centrally set up for all SAP repositories by our OSS team.
I will ask my colleague @SebastianWolf-SAP about this and let you know.

In general, i think it's a useful tool for checking inclusive language, however there are only very few works/phrases checked. I think it would make sense to combine it with other tools to check for cursewords, typos, and so on (if not yet in place).

[SebastianWolf-SAP]

Yes, we enabled it for the complete SAP organization on GitHub. I was quite skeptical as it applies only simple regular expressions, but as it doesn't block any PRs or other contributions, it was worth a try. So far we haven't received that many reactions. Overall, the little feedback that we got was quite positive - however, we got some requests to enhance the configuration so that e.g. "masterdata" is still accepted without any warnings. The change is currently piloted in a single repository (see https://github.com/SAP/project-sailor/blob/main/.github/in-solidarity.yml). If it works out properly, we will enable this configuration globally.

Similar custom-made checks can be integrated easily (as long as the check fits into a regex), so if you want to extend it, there shouldn't be much of an issue...

[spier]

Thanks for the extra info @SebastianWolf-SAP. I understand how it works now.

I just checked for the 7 default rules of the in-solidarity bot manually, and we don't have any offences to those in this repo yet.

I think @Michadelic's suggestion to combine this with something that looks for curse words as well sounds interesting.
Haven't looked for such a bot/tool yet but I am sure they are around.

With regards to typos/spelling:
I have looked into spell checkers once (as part of #272). So far I couldn't fine one that strikes a good balance between being too strict and too lax checks.

Again, thanks for your explanations regarding the in-solidarity bot, much apprecited!

[tsadler1988]

Suggestion: check for usages of 'he/she' and suggest using 'they' as an alternative. In Patterns especially we will often talk about a hypothetical individual.

[spier]

Suggestion: check for usages of 'he/she' and suggest using 'they' as an alternative. In Patterns especially we will often talk about a hypothetical individual.

@tsadler1988 I tried out textlint today, specifically the rules called alex.
Looks like it could help a bit with creating more inclusive language.

This is the output for the RFC pattern:

/patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md
  31:14   error  [desire] Be careful with `desire`, it’s profane in some cases                                  alex
  31:113  error  [just] `just` may be insensitive, try not to use it                                            alex
  78:80   error  [herself-himself] `herself` may be insensitive, use `themselves`, `theirself`, `self` instead  alex

What I don't know yet:
How to treat cases were you want to ignore the error reported by the linter?
Especially if we use the linter in our CI, we probably want all checks to pass before merging.