artsy

artsy

Artsy.net Team

Member Since 10 years ago

New York, NY

Experience Points
0
follower
Lessons Completed
0
follow
Best Reply Awards
253
repos
Activity
Dec
5
4 hours ago
open pull request

anandaroop wants to merge artsy/rosalind

anandaroop
anandaroop

feat: add linting rules in JS and Ruby to encourage inclusive language

In response to the RFC https://github.com/artsy/README/issues/427 I wanted to see how easy it would be add an automation to encourage this cultural norm.

This PR introduces:


👉🏽 Browse through the commits to see what's involved in installing and configuring.


For a project that already uses ESLint, it seems dead simple to install the necessary plugin.

For a project using Rubocop, one does have to upgrade to a recent enough version — ≥1.21 — to get the latest rule. This can be tricky depending on what kind of dependency spaghetti you have. In this case it involved just updating one other lib simultaneously. There also may be a little work involved in enabling/silencing/placating the most recent cops that come along with the upgrade.

anandaroop
anandaroop

That's right — this is one of several changes that was made in order to placate Rubocop in https://github.com/artsy/rosalind/pull/586/commits/0521c3bdb5e822bbe4aa2a3d86ed7fd1cb38d1e3

And that's a consequence of upgrading this project to a recent enough Rubocop to get the new settings.

pull request

anandaroop merge to artsy/rosalind

anandaroop
anandaroop

feat: add linting rules in JS and Ruby to encourage inclusive language

In response to the RFC https://github.com/artsy/README/issues/427 I wanted to see how easy it would be add an automation to encourage this cultural norm.

This PR introduces:


👉🏽 Browse through the commits to see what's involved in installing and configuring.


For a project that already uses ESLint, it seems dead simple to install the necessary plugin.

For a project using Rubocop, one does have to upgrade to a recent enough version — ≥1.21 — to get the latest rule. This can be tricky depending on what kind of dependency spaghetti you have. In this case it involved just updating one other lib simultaneously. There also may be a little work involved in enabling/silencing/placating the most recent cops that come along with the upgrade.

Dec
4
1 day ago
pull request

kathytafel merge to artsy/rosalind

kathytafel
kathytafel

feat: add linting rules in JS and Ruby to encourage inclusive language

In response to the RFC https://github.com/artsy/README/issues/427 I wanted to see how easy it would be add an automation to encourage this cultural norm.

This PR introduces:


👉🏽 Browse through the commits to see what's involved in installing and configuring.


For a project that already uses ESLint, it seems dead simple to install the necessary plugin.

For a project using Rubocop, one does have to upgrade to a recent enough version — ≥1.21 — to get the latest rule. This can be tricky depending on what kind of dependency spaghetti you have. In this case it involved just updating one other lib simultaneously. There also may be a little work involved in enabling/silencing/placating the most recent cops that come along with the upgrade.

kathytafel
kathytafel

Everything looks more or less right to me, but I might like @lidimayra to take a look since she suggested. I have one comment that stood out but I don't think it's a blocker. Thanks for the template @anandaroop.

pull request

kathytafel merge to artsy/rosalind

kathytafel
kathytafel

feat: add linting rules in JS and Ruby to encourage inclusive language

In response to the RFC https://github.com/artsy/README/issues/427 I wanted to see how easy it would be add an automation to encourage this cultural norm.

This PR introduces:


👉🏽 Browse through the commits to see what's involved in installing and configuring.


For a project that already uses ESLint, it seems dead simple to install the necessary plugin.

For a project using Rubocop, one does have to upgrade to a recent enough version — ≥1.21 — to get the latest rule. This can be tricky depending on what kind of dependency spaghetti you have. In this case it involved just updating one other lib simultaneously. There also may be a little work involved in enabling/silencing/placating the most recent cops that come along with the upgrade.

kathytafel
kathytafel

Everything looks more or less right to me, but I might like @lidimayra to take a look since she suggested. I have one comment that stood out but I don't think it's blocker. Thanks for the template @anandaroop.

open pull request

kathytafel wants to merge artsy/rosalind

kathytafel
kathytafel

feat: add linting rules in JS and Ruby to encourage inclusive language

In response to the RFC https://github.com/artsy/README/issues/427 I wanted to see how easy it would be add an automation to encourage this cultural norm.

This PR introduces:


👉🏽 Browse through the commits to see what's involved in installing and configuring.


For a project that already uses ESLint, it seems dead simple to install the necessary plugin.

For a project using Rubocop, one does have to upgrade to a recent enough version — ≥1.21 — to get the latest rule. This can be tricky depending on what kind of dependency spaghetti you have. In this case it involved just updating one other lib simultaneously. There also may be a little work involved in enabling/silencing/placating the most recent cops that come along with the upgrade.

kathytafel
kathytafel

Is this here for a dependency update? This doesn't on a glance seem to do with the task at hand. I might prefer in such a case just a quick note about it?

pull request

kathytafel merge to artsy/rosalind

kathytafel
kathytafel

feat: add linting rules in JS and Ruby to encourage inclusive language

In response to the RFC https://github.com/artsy/README/issues/427 I wanted to see how easy it would be add an automation to encourage this cultural norm.

This PR introduces:


👉🏽 Browse through the commits to see what's involved in installing and configuring.


For a project that already uses ESLint, it seems dead simple to install the necessary plugin.

For a project using Rubocop, one does have to upgrade to a recent enough version — ≥1.21 — to get the latest rule. This can be tricky depending on what kind of dependency spaghetti you have. In this case it involved just updating one other lib simultaneously. There also may be a little work involved in enabling/silencing/placating the most recent cops that come along with the upgrade.

started
started time in 7 hours ago
started
started time in 9 hours ago
Activity icon
issue

anandaroop issue comment artsy/README

anandaroop
anandaroop

RFC: Adopt inclusive language for repository naming as well as allow/deny lists

Proposal:

"RFC: Rename 'master' branches to 'main' #386" was opened in April and speaks to 1/2 the proposal. We have not yet completed the job. This RFC is to get us over the finish line, with both the master/main topic as well as allow/deny lists. It is a small thing to change language, but with profound impact. Let's not perpetuate the master/slave or 'black = bad' tech metaphors.

Reasoning

All the reasoning in #386.

Exceptions:

Also the exceptions in #386. I.e. none.

Additional Context:

As a new joiner, I was surprised when I saw a PR with 'blacklist' because I would have assumed that Artsy had the discussion when that happened in the industry. When asking about it, I was gratified to find out that my assumption was true, by being pointed to this thread from a former employee from 2 years ago referencing this post).

However, we still we have some dangling threads as evidenced by there still being outdated language in our repository. This RFC hopes to introduce some behaviour changes that will make it so we don't have the same conversation in a year.

Master --> Main In investigating the problem, engineering directors noticed that maybe people didn't feel comfortable renaming repositories, so this pull request updates the playbook for that.

Allow/Deny We also noticed that while we are migrating to allow/deny, some of our included dependencies use outdated language. We should not let it stop us that the outdated language comes from outside our organisation if we want to lead with openness, and follow through on myriad commitments to diversity as claimed here. To that end we should make sure in a pull request to notice use of calling a "blacklist/whitelist." If it's inside our org's repositories, we should either fix within that PR or open an issue if it is large surgery. If it's outside our organization, we should update the dependency if the other org has already modernised. If the org has not yet deprecated outdated language, we should either open a pull request or file an issue depending on the size of the problem.

How is this RFC resolved?

  • Pull request templates updated with a checkbox: "I made sure to adopt inclusive language. (by master --> main adoption|allow/deny in our org|allow/deny in other org/adding linter)"

  • Reminder set on this RFC to check in 6 months for progress by searching our org for outdated language.

anandaroop
anandaroop

Yeah I'm also not confident that a checkbox would have the intended effect, without a lot more prescriptiveness about the who/when/what of the action that it's supposed to induce 🤷🏽

But I do feel like the linting approach is super-clear. Who = you when you get the message. When = when you commit. What = whatever the linter is noodging you about.

I thought it could be helpful to see an example of the work involved in adding that linting to a project. So I used Rosalind as a guinea pig and opened https://github.com/artsy/rosalind/pull/586 to demonstrate this approach for both Ruby and Javascript

My takeaways:

  • adding JS linting very easy
  • adding Ruby linting potentially a little more involved but still manageable
  • this approach might still be prone to inconsistency between projects (i.e. configured custom word lists)
  • having a clear exemplar PR like this might help with some of the above
Activity icon
issue

artsy-peril[bot] issue comment artsy/rosalind

artsy-peril[bot]
artsy-peril[bot]

feat: add linting rules in JS and Ruby to encourage inclusive language

In response to the RFC https://github.com/artsy/README/issues/427 I wanted to see how easy it would be add an automation to encourage this cultural norm.

This PR introduces:


👉🏽 Browse through the commits to see what's involved in installing and configuring.


For a project that already uses ESLint, it seems dead simple to install the necessary plugin.

For a project using Rubocop, one does have to upgrade to a recent enough version — ≥1.21 — to get the latest rule. This can be tricky depending on what kind of dependency spaghetti you have. In this case it involved just updating one other lib simultaneously. There also may be a little work involved in enabling/silencing/placating the most recent cops that come along with the upgrade.

artsy-peril[bot]
artsy-peril[bot]

eslint-plugin-inclusive-language

Author: René Winkelmeyer @muenzpraeger

Description: An ESLint plugin to raise awareness for using inclusive language not only in your codebase, but in life.

Homepage: https://github.com/muenzpraeger/eslint-plugin-inclusive-language#readme

Createdover 1 year ago
Last Updated1 day ago
LicenseCC0-1.0
Maintainers1
Releases11
Direct Dependencieshumps
README

eslint-plugin-inclusive-language

An ESLint plugin to raise awareness for using inclusive language not only in your codebase, but in life.

Github Workflow Version

If you're upgrading from 1.x.x. to 2.x.x, please read the migration document here first.

What is inclusive language anyway?

This is a great question to ask.

Lets start with a general definition of "inclusive language":

Inclusive language is language that is free from words, phrases or tones that reflect prejudiced, stereotyped or discriminatory views of particular people or groups. It is also language that doesn’t deliberately or inadvertently exclude people from being seen as part of a group. (Source)

While it sounds obvious to adhere to use language that is inclusive, it may not always be as obvious to apply as you think. Sometimes it can also be subtle, and you're just not aware. Especially when you're using language that is not your first language. I am speaking out of my own experience.

Let me give you a simple example (where I had to unlearn non-inclusive behavior myself): How often do you use the term "hey guys" when addressing a group of people? And how often can you say with 100% certainty that all members of that group identify as male? In English lessons I learned many decades ago that it's OK to use "guys" to address any group. In reality it's not OK, and adjusting (in this case my own) language helps others to be more included in conversations.

There are many terms that we can have really looooong arguments about if they are inclusive, or non-inclusive. And there are many that are really obvious. Depending on your first language, it can be even more difficult to differentiate.

This plugin contains, for now, four terms, where IMHO the tech industry as a whole is coming to/came to a consensus to change (the existing) standards. It will grow, over time. If you want to see some of this for yourself, there is a discussion about these terms here.

Now, if you ask yourself "Do I really need this plugin?"... read further.

Why would I need an ESLint plugin for that?

There may be a high likelihood you won't need it. You still may want to use it though.

First, if you read all this text, and if you haven't been aware of this topic until now, then I've reached my goal for this project. Think about it, read about it (there's plenty of information on the internet), discuss with your colleagues and friends, and hopefully apply a more inclusive language.

Second, if you want to raise awareness, using this plugin is an option (eventually not the only one). Just having it in your codebase, and with that eventually bringing people to this repository and text, is a step. When more people learn, more people will apply these patterns to their own language.

Third, if you want to participate, you can open issues on the repo. Or customize this plugin for your own usage or language, fork the repository, whatever you prefer. I don't care really about npm installs, or stars on this particular repo. I care that you start learning about inclusive language, and how to apply it. It's still a journey for me, unlearning many different behaviours.

Installation

Ok, you're here, so let's come to the technical part.

You'll first need to install ESLint:

$ npm i eslint --save-dev

Next, install eslint-plugin-inclusive-language:

$ npm install eslint-plugin-inclusive-language --save-dev

Note: If you installed ESLint globally (using the -g flag) then you must also install eslint-plugin-inclusive-language globally.

Usage

Add inclusive-language to the plugins section of your .eslintrc configuration file. You can omit the eslint-plugin- prefix:

{
    "plugins": ["inclusive-language"]
}

Then configure the rule use-inclusive-words.

{
    "rules": {
        "inclusive-language/use-inclusive-words": "error"
    }
}

That's it. You can find information on how to customize it in the rule documentation.

New dependencies added: eslint-plugin-inclusive-language.

Generated by :no_entry_sign: dangerJS against f89a7f85ad37ba12feed1eeff4943dd3d1985d06

Activity icon
issue

artsy-peril[bot] issue comment artsy/rosalind

artsy-peril[bot]
artsy-peril[bot]

feat: add linting rules in JS and Ruby to encourage inclusive language [WIP]

In response to the RFC https://github.com/artsy/README/issues/427 I wanted to see how easy it would be add an automation to encourage this cultural norm.

This PR introduces:


👉🏽 Browse through the commits to see what's involved in installing and configuring.


For a project that already uses ESLint, it seems dead simple to install the necessary plugin.

For a project using Rubocop, one does have to upgrade to a recent enough version — ≥1.21 — to get the latest rule. This can be tricky depending on what kind of dependency spaghetti you have. In this case it involved just updating one other lib simultaneously. There also may be a little work involved in enabling/silencing/placating the most recent cops that come along with the upgrade.

artsy-peril[bot]
artsy-peril[bot]

eslint-plugin-inclusive-language

Author: René Winkelmeyer @muenzpraeger

Description: An ESLint plugin to raise awareness for using inclusive language not only in your codebase, but in life.

Homepage: https://github.com/muenzpraeger/eslint-plugin-inclusive-language#readme

Createdover 1 year ago
Last Updated1 day ago
LicenseCC0-1.0
Maintainers1
Releases11
Direct Dependencieshumps
README

eslint-plugin-inclusive-language

An ESLint plugin to raise awareness for using inclusive language not only in your codebase, but in life.

Github Workflow Version

If you're upgrading from 1.x.x. to 2.x.x, please read the migration document here first.

What is inclusive language anyway?

This is a great question to ask.

Lets start with a general definition of "inclusive language":

Inclusive language is language that is free from words, phrases or tones that reflect prejudiced, stereotyped or discriminatory views of particular people or groups. It is also language that doesn’t deliberately or inadvertently exclude people from being seen as part of a group. (Source)

While it sounds obvious to adhere to use language that is inclusive, it may not always be as obvious to apply as you think. Sometimes it can also be subtle, and you're just not aware. Especially when you're using language that is not your first language. I am speaking out of my own experience.

Let me give you a simple example (where I had to unlearn non-inclusive behavior myself): How often do you use the term "hey guys" when addressing a group of people? And how often can you say with 100% certainty that all members of that group identify as male? In English lessons I learned many decades ago that it's OK to use "guys" to address any group. In reality it's not OK, and adjusting (in this case my own) language helps others to be more included in conversations.

There are many terms that we can have really looooong arguments about if they are inclusive, or non-inclusive. And there are many that are really obvious. Depending on your first language, it can be even more difficult to differentiate.

This plugin contains, for now, four terms, where IMHO the tech industry as a whole is coming to/came to a consensus to change (the existing) standards. It will grow, over time. If you want to see some of this for yourself, there is a discussion about these terms here.

Now, if you ask yourself "Do I really need this plugin?"... read further.

Why would I need an ESLint plugin for that?

There may be a high likelihood you won't need it. You still may want to use it though.

First, if you read all this text, and if you haven't been aware of this topic until now, then I've reached my goal for this project. Think about it, read about it (there's plenty of information on the internet), discuss with your colleagues and friends, and hopefully apply a more inclusive language.

Second, if you want to raise awareness, using this plugin is an option (eventually not the only one). Just having it in your codebase, and with that eventually bringing people to this repository and text, is a step. When more people learn, more people will apply these patterns to their own language.

Third, if you want to participate, you can open issues on the repo. Or customize this plugin for your own usage or language, fork the repository, whatever you prefer. I don't care really about npm installs, or stars on this particular repo. I care that you start learning about inclusive language, and how to apply it. It's still a journey for me, unlearning many different behaviours.

Installation

Ok, you're here, so let's come to the technical part.

You'll first need to install ESLint:

$ npm i eslint --save-dev

Next, install eslint-plugin-inclusive-language:

$ npm install eslint-plugin-inclusive-language --save-dev

Note: If you installed ESLint globally (using the -g flag) then you must also install eslint-plugin-inclusive-language globally.

Usage

Add inclusive-language to the plugins section of your .eslintrc configuration file. You can omit the eslint-plugin- prefix:

{
    "plugins": ["inclusive-language"]
}

Then configure the rule use-inclusive-words.

{
    "rules": {
        "inclusive-language/use-inclusive-words": "error"
    }
}

That's it. You can find information on how to customize it in the rule documentation.

New dependencies added: eslint-plugin-inclusive-language.

Generated by :no_entry_sign: dangerJS against f89a7f85ad37ba12feed1eeff4943dd3d1985d06

push

anandaroop push artsy/rosalind

anandaroop
anandaroop

feat(js): install inclusive language plugin for eslint

yarn add --dev eslint-plugin-inclusive-language

anandaroop
anandaroop

feat(js): configure suggested word substitutions

Our RFC suggests 'denylist' as an alternative to 'blacklist', so we add that along with the built-in suggestion of 'blocklist'

anandaroop
anandaroop

test(js): inclusive language in Javascript

This commit is included just for demonstration purposes.

This is the kind of change that would get flagged by the linter, and is only here because it was opted out of linting with --no-verify

anandaroop
anandaroop

chore(js): revert "test: inclusive language in Javascript"

This reverts the previous commit, which skipped linting via --no-verify for demonstration purposes only

anandaroop
anandaroop

feat(ruby): update to a recent Rubocop version with inclusive language rule

  • bump rubocop to >=1.21

  • bundle update --minor regexp_parser rubocop (for minimal deps update that will satisfy this rubocop bump)

anandaroop
anandaroop

chore(ruby): placate latest Rubocop

  • accept autocorrections for new rules that are enabled by default

  • enable all new rules by default

  • accept autocorrections for (or selectively ignore) new rules

anandaroop
anandaroop

feat(ruby): enable inclusive language rule for Rubocop

anandaroop
anandaroop

test(ruby): inclusive language in Ruby

This commit is included just for demonstration purposes.

This is the kind of change that would get flagged by the linter, and is only here because it was opted out of linting with --no-verify

anandaroop
anandaroop

chore(ruby): revert "test: inclusive language in Ruby"

This reverts the previous commit, which skipped linting via --no-verify for demonstration purposes only

commit sha: f89a7f85ad37ba12feed1eeff4943dd3d1985d06

push time in 12 hours ago
Activity icon
issue

artsy-peril[bot] issue comment artsy/rosalind

artsy-peril[bot]
artsy-peril[bot]

feat: add linting rules in JS and Ruby to encourage inclusive language [WIP]

In response to the RFC https://github.com/artsy/README/issues/427 I wanted to see how easy it would be add an automation to encourage this cultural norm.

This PR introduces:


👉🏽 Browse through the commits to see what's involved in installing and configuring.


For a project that already uses ESLint, it seems dead simple to install the necessary plugin.

For a project using Rubocop, one does have to upgrade to a recent enough version — ≥1.21 — to get the latest rule. This can be tricky depending on what kind of dependency spaghetti you have. In this case it involved just updating one other lib simultaneously. There also may be a little work involved in enabling/silencing/placating the most recent cops that come along with the upgrade.

artsy-peril[bot]
artsy-peril[bot]

eslint-plugin-inclusive-language

Author: René Winkelmeyer @muenzpraeger

Description: An ESLint plugin to raise awareness for using inclusive language not only in your codebase, but in life.

Homepage: https://github.com/muenzpraeger/eslint-plugin-inclusive-language#readme

Createdover 1 year ago
Last Updated1 day ago
LicenseCC0-1.0
Maintainers1
Releases11
Direct Dependencieshumps
README

eslint-plugin-inclusive-language

An ESLint plugin to raise awareness for using inclusive language not only in your codebase, but in life.

Github Workflow Version

If you're upgrading from 1.x.x. to 2.x.x, please read the migration document here first.

What is inclusive language anyway?

This is a great question to ask.

Lets start with a general definition of "inclusive language":

Inclusive language is language that is free from words, phrases or tones that reflect prejudiced, stereotyped or discriminatory views of particular people or groups. It is also language that doesn’t deliberately or inadvertently exclude people from being seen as part of a group. (Source)

While it sounds obvious to adhere to use language that is inclusive, it may not always be as obvious to apply as you think. Sometimes it can also be subtle, and you're just not aware. Especially when you're using language that is not your first language. I am speaking out of my own experience.

Let me give you a simple example (where I had to unlearn non-inclusive behavior myself): How often do you use the term "hey guys" when addressing a group of people? And how often can you say with 100% certainty that all members of that group identify as male? In English lessons I learned many decades ago that it's OK to use "guys" to address any group. In reality it's not OK, and adjusting (in this case my own) language helps others to be more included in conversations.

There are many terms that we can have really looooong arguments about if they are inclusive, or non-inclusive. And there are many that are really obvious. Depending on your first language, it can be even more difficult to differentiate.

This plugin contains, for now, four terms, where IMHO the tech industry as a whole is coming to/came to a consensus to change (the existing) standards. It will grow, over time. If you want to see some of this for yourself, there is a discussion about these terms here.

Now, if you ask yourself "Do I really need this plugin?"... read further.

Why would I need an ESLint plugin for that?

There may be a high likelihood you won't need it. You still may want to use it though.

First, if you read all this text, and if you haven't been aware of this topic until now, then I've reached my goal for this project. Think about it, read about it (there's plenty of information on the internet), discuss with your colleagues and friends, and hopefully apply a more inclusive language.

Second, if you want to raise awareness, using this plugin is an option (eventually not the only one). Just having it in your codebase, and with that eventually bringing people to this repository and text, is a step. When more people learn, more people will apply these patterns to their own language.

Third, if you want to participate, you can open issues on the repo. Or customize this plugin for your own usage or language, fork the repository, whatever you prefer. I don't care really about npm installs, or stars on this particular repo. I care that you start learning about inclusive language, and how to apply it. It's still a journey for me, unlearning many different behaviours.

Installation

Ok, you're here, so let's come to the technical part.

You'll first need to install ESLint:

$ npm i eslint --save-dev

Next, install eslint-plugin-inclusive-language:

$ npm install eslint-plugin-inclusive-language --save-dev

Note: If you installed ESLint globally (using the -g flag) then you must also install eslint-plugin-inclusive-language globally.

Usage

Add inclusive-language to the plugins section of your .eslintrc configuration file. You can omit the eslint-plugin- prefix:

{
    "plugins": ["inclusive-language"]
}

Then configure the rule use-inclusive-words.

{
    "rules": {
        "inclusive-language/use-inclusive-words": "error"
    }
}

That's it. You can find information on how to customize it in the rule documentation.

New dependencies added: eslint-plugin-inclusive-language.

Generated by :no_entry_sign: dangerJS against 8c87cb5f23f2bbdba3802b161ac7c91fb9cf6af5

Activity icon
issue

artsy-peril[bot] issue comment artsy/rosalind

artsy-peril[bot]
artsy-peril[bot]

feat: add linting rules in JS and Ruby to encourage inclusive language [WIP]

In response to the RFC https://github.com/artsy/README/issues/427 I wanted to see how easy it would be add an automation to encourage this cultural norm.

This PR introduces:

👉🏽 Browse through the commits to see what's involved in installing and configuring.

For a project that already uses ESLint, it seems dead simple to install the necessary plugin.

For a project using Rubocop, one does have to upgrade to a recent enough version — ≥1.21 — to get the latest rule. This can be tricky depending on what kind of dependency spaghetti you have. In this case it involved just updating one other lib simultaneously. There also may be a little work involved in enabling/silencing/placating the most recent cops that come along with the upgrade.

artsy-peril[bot]
artsy-peril[bot]

eslint-plugin-inclusive-language

Author: René Winkelmeyer @muenzpraeger

Description: An ESLint plugin to raise awareness for using inclusive language not only in your codebase, but in life.

Homepage: https://github.com/muenzpraeger/eslint-plugin-inclusive-language#readme

Createdover 1 year ago
Last Updated1 day ago
LicenseCC0-1.0
Maintainers1
Releases11
Direct Dependencieshumps
README

eslint-plugin-inclusive-language

An ESLint plugin to raise awareness for using inclusive language not only in your codebase, but in life.

Github Workflow Version

If you're upgrading from 1.x.x. to 2.x.x, please read the migration document here first.

What is inclusive language anyway?

This is a great question to ask.

Lets start with a general definition of "inclusive language":

Inclusive language is language that is free from words, phrases or tones that reflect prejudiced, stereotyped or discriminatory views of particular people or groups. It is also language that doesn’t deliberately or inadvertently exclude people from being seen as part of a group. (Source)

While it sounds obvious to adhere to use language that is inclusive, it may not always be as obvious to apply as you think. Sometimes it can also be subtle, and you're just not aware. Especially when you're using language that is not your first language. I am speaking out of my own experience.

Let me give you a simple example (where I had to unlearn non-inclusive behavior myself): How often do you use the term "hey guys" when addressing a group of people? And how often can you say with 100% certainty that all members of that group identify as male? In English lessons I learned many decades ago that it's OK to use "guys" to address any group. In reality it's not OK, and adjusting (in this case my own) language helps others to be more included in conversations.

There are many terms that we can have really looooong arguments about if they are inclusive, or non-inclusive. And there are many that are really obvious. Depending on your first language, it can be even more difficult to differentiate.

This plugin contains, for now, four terms, where IMHO the tech industry as a whole is coming to/came to a consensus to change (the existing) standards. It will grow, over time. If you want to see some of this for yourself, there is a discussion about these terms here.

Now, if you ask yourself "Do I really need this plugin?"... read further.

Why would I need an ESLint plugin for that?

There may be a high likelihood you won't need it. You still may want to use it though.

First, if you read all this text, and if you haven't been aware of this topic until now, then I've reached my goal for this project. Think about it, read about it (there's plenty of information on the internet), discuss with your colleagues and friends, and hopefully apply a more inclusive language.

Second, if you want to raise awareness, using this plugin is an option (eventually not the only one). Just having it in your codebase, and with that eventually bringing people to this repository and text, is a step. When more people learn, more people will apply these patterns to their own language.

Third, if you want to participate, you can open issues on the repo. Or customize this plugin for your own usage or language, fork the repository, whatever you prefer. I don't care really about npm installs, or stars on this particular repo. I care that you start learning about inclusive language, and how to apply it. It's still a journey for me, unlearning many different behaviours.

Installation

Ok, you're here, so let's come to the technical part.

You'll first need to install ESLint:

$ npm i eslint --save-dev

Next, install eslint-plugin-inclusive-language:

$ npm install eslint-plugin-inclusive-language --save-dev

Note: If you installed ESLint globally (using the -g flag) then you must also install eslint-plugin-inclusive-language globally.

Usage

Add inclusive-language to the plugins section of your .eslintrc configuration file. You can omit the eslint-plugin- prefix:

{
    "plugins": ["inclusive-language"]
}

Then configure the rule use-inclusive-words.

{
    "rules": {
        "inclusive-language/use-inclusive-words": "error"
    }
}

That's it. You can find information on how to customize it in the rule documentation.

New dependencies added: eslint-plugin-inclusive-language.

Generated by :no_entry_sign: dangerJS against 8c87cb5f23f2bbdba3802b161ac7c91fb9cf6af5

push

artsyit push artsy/eigen

artsyit
artsyit

fix: Reduce size of fairs and shows header (#5842)

artsyit
artsyit

feature(DX): showing an indicator for webviews (#5839)

  • adding a little indicator

  • fix test

  • nice

artsyit
artsyit

feature(upgrades): upgrade some deps (#5838)

  • boom

  • this was missing

  • types

artsyit
artsyit

handle dismissing modal when webview is presented modally (#5857)

Co-authored-by: Sam Raj [email protected]

Co-authored-by: Brian Beckerle [email protected]

artsyit
artsyit

use short format for exhibition dates, get rid of client side abbreviation (#5827)

commit sha: 37f583924372840b369a071bb91fddb9f523c419

push time in 22 hours ago
push

artsyit push artsy/eigen

artsyit
artsyit

fix: Reduce size of fairs and shows header (#5842)

artsyit
artsyit

feature(DX): showing an indicator for webviews (#5839)

  • adding a little indicator

  • fix test

  • nice

artsyit
artsyit

feature(upgrades): upgrade some deps (#5838)

  • boom

  • this was missing

  • types

artsyit
artsyit

handle dismissing modal when webview is presented modally (#5857)

Co-authored-by: Sam Raj [email protected]

Co-authored-by: Brian Beckerle [email protected]

artsyit
artsyit

use short format for exhibition dates, get rid of client side abbreviation (#5827)

commit sha: 37f583924372840b369a071bb91fddb9f523c419

push time in 22 hours ago
push

renovate[bot] push artsy/force

renovate[bot]
renovate[bot]

Resize article enclosures for RSS feed

renovate[bot]
renovate[bot]

feat: Apply resizing logic to RSS feed items GROW-692 (#9004)

feat: Apply resizing logic to RSS feed items GROW-692

renovate[bot]
renovate[bot]

chore(deps): update aws-s3 orb from 2.0.0 to v3

commit sha: bbf8f6e9b10275831671ee934e49ab61e2060178

push time in 1 day ago
push

renovate[bot] push artsy/force

renovate[bot]
renovate[bot]

Resize article enclosures for RSS feed

renovate[bot]
renovate[bot]

feat: Apply resizing logic to RSS feed items GROW-692 (#9004)

feat: Apply resizing logic to RSS feed items GROW-692

renovate[bot]
renovate[bot]

chore(deps): update dep typescript from 4.3.5 to v4.5.2

commit sha: 0abf6ff03bd1ae0016ed005c04d7b7a7ec4d9ad4

push time in 1 day ago
push

artsyit push artsy/metaphysics

artsyit
artsyit

chore(deps): update node orb from 4.8.0 to v4.8.1

commit sha: 19707d23fdb5a1d6e8d268649150409a550f3666

push time in 1 day ago
Activity icon
created tag

artsyit in artsy/metaphysics create tag staging--2021-12-04--00-46-11

createdAt 1 day ago
push

renovate[bot] push artsy/metaphysics

renovate[bot]
renovate[bot]

chore(deps): update node orb from 4.8.0 to v4.8.1

commit sha: 19707d23fdb5a1d6e8d268649150409a550f3666

push time in 1 day ago
Activity icon
delete

renovate[bot] in artsy/metaphysics delete branch renovate/node-4.x

deleted time in 1 day ago
pull request

renovate[bot] pull request artsy/metaphysics

renovate[bot]
renovate[bot]

chore(deps): update node orb from 4.8.0 to v4.8.1

WhiteSource Renovate

This PR contains the following updates:

Package Type Update Change
node orb patch 4.8.0 -> 4.8.1

Configuration

📅 Schedule: At any time (no schedule defined).

🚦 Automerge: Enabled.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by WhiteSource Renovate. View repository job log here.

Dec
3
2 days ago
open pull request

anandaroop wants to merge artsy/rosalind

anandaroop
anandaroop

feat: add linting rules in JS and Ruby to encourage inclusive language [WIP]

In response to the RFC https://github.com/artsy/README/issues/427 I wanted to see how easy it would be add an automation to encourage this cultural norm.

This PR introduces:

👉🏽 Browse through the commits to see what's involved in installing and configuring.

For a project that already uses ESLint, it seems dead simple to install the necessary plugin.

For a project using Rubocop, one does have to upgrade to a recent enough version — ≥1.21 — to get the latest rule. This can be tricky depending on what kind of dependency spaghetti you have. In this case it involved just updating one other lib simultaneously. There also may be a little work involved in enabling/silencing/placating the most recent cops that come along with the upgrade.

anandaroop
anandaroop

As configured, this would result in the following ESLint error:

Screen Shot 2021-12-01 at 1 04 44 PM
open pull request

anandaroop wants to merge artsy/rosalind

anandaroop
anandaroop

feat: add linting rules in JS and Ruby to encourage inclusive language [WIP]

In response to the RFC https://github.com/artsy/README/issues/427 I wanted to see how easy it would be add an automation to encourage this cultural norm.

This PR introduces:

👉🏽 Browse through the commits to see what's involved in installing and configuring.

For a project that already uses ESLint, it seems dead simple to install the necessary plugin.

For a project using Rubocop, one does have to upgrade to a recent enough version — ≥1.21 — to get the latest rule. This can be tricky depending on what kind of dependency spaghetti you have. In this case it involved just updating one other lib simultaneously. There also may be a little work involved in enabling/silencing/placating the most recent cops that come along with the upgrade.

anandaroop
anandaroop

As configured, this would result in the following error from Rubocop:

Screen Shot 2021-12-01 at 6 22 45 PM
pull request

anandaroop merge to artsy/rosalind

anandaroop
anandaroop

feat: add linting rules in JS and Ruby to encourage inclusive language [WIP]

In response to the RFC https://github.com/artsy/README/issues/427 I wanted to see how easy it would be add an automation to encourage this cultural norm.

This PR introduces:

👉🏽 Browse through the commits to see what's involved in installing and configuring.

For a project that already uses ESLint, it seems dead simple to install the necessary plugin.

For a project using Rubocop, one does have to upgrade to a recent enough version — ≥1.21 — to get the latest rule. This can be tricky depending on what kind of dependency spaghetti you have. In this case it involved just updating one other lib simultaneously. There also may be a little work involved in enabling/silencing/placating the most recent cops that come along with the upgrade.

anandaroop
anandaroop

Examples of linting output below…

pull request

anandaroop merge to artsy/rosalind

anandaroop
anandaroop

feat: add linting rules in JS and Ruby to encourage inclusive language [WIP]

In response to the RFC https://github.com/artsy/README/issues/427 I wanted to see how easy it would be add an automation to encourage this cultural norm.

This PR introduces:

👉🏽 Browse through the commits to see what's involved in installing and configuring.

For a project that already uses ESLint, it seems dead simple to install the necessary plugin.

For a project using Rubocop, one does have to upgrade to a recent enough version — ≥1.21 — to get the latest rule. This can be tricky depending on what kind of dependency spaghetti you have. In this case it involved just updating one other lib simultaneously. There also may be a little work involved in enabling/silencing/placating the most recent cops that come along with the upgrade.

anandaroop
anandaroop

Examples of linting output below…

push

artsyit push artsy/force

artsyit
artsyit

Resize article enclosures for RSS feed

artsyit
artsyit

feat: Apply resizing logic to RSS feed items GROW-692 (#9004)

feat: Apply resizing logic to RSS feed items GROW-692

commit sha: b19b82cdc1ddffdf3260b9f5a759193475548ceb

push time in 1 day ago
Activity icon
created tag

artsyit in artsy/force create tag staging--2021-12-03--23-51-49

createdAt 1 day ago
Activity icon
issue

artsy-peril[bot] issue comment artsy/rosalind

artsy-peril[bot]
artsy-peril[bot]

feat: add linting rules in JS and Ruby to encourage inclusive language [WIP]

In response to the RFC https://github.com/artsy/README/issues/427 I wanted to see how easy it would be add an automation to encourage this cultural norm.

This PR introduces:

Browse through the commits to see what's involved in installing and configuring.

For a project that already uses ESLint, it seems dead simple to install the necessary plugin.

For a project using Rubocop, one does have to upgrade to a recent enough version — ≥1.21 — to get the latest rule. This can be tricky depending on what kind of dependency spaghetti you have. In this case it involved just updating one other lib simultaneously.

artsy-peril[bot]
artsy-peril[bot]

eslint-plugin-inclusive-language

Author: René Winkelmeyer @muenzpraeger

Description: An ESLint plugin to raise awareness for using inclusive language not only in your codebase, but in life.

Homepage: https://github.com/muenzpraeger/eslint-plugin-inclusive-language#readme

Createdover 1 year ago
Last Updatedabout 16 hours ago
LicenseCC0-1.0
Maintainers1
Releases11
Direct Dependencieshumps
README

eslint-plugin-inclusive-language

An ESLint plugin to raise awareness for using inclusive language not only in your codebase, but in life.

Github Workflow Version

If you're upgrading from 1.x.x. to 2.x.x, please read the migration document here first.

What is inclusive language anyway?

This is a great question to ask.

Lets start with a general definition of "inclusive language":

Inclusive language is language that is free from words, phrases or tones that reflect prejudiced, stereotyped or discriminatory views of particular people or groups. It is also language that doesn’t deliberately or inadvertently exclude people from being seen as part of a group. (Source)

While it sounds obvious to adhere to use language that is inclusive, it may not always be as obvious to apply as you think. Sometimes it can also be subtle, and you're just not aware. Especially when you're using language that is not your first language. I am speaking out of my own experience.

Let me give you a simple example (where I had to unlearn non-inclusive behavior myself): How often do you use the term "hey guys" when addressing a group of people? And how often can you say with 100% certainty that all members of that group identify as male? In English lessons I learned many decades ago that it's OK to use "guys" to address any group. In reality it's not OK, and adjusting (in this case my own) language helps others to be more included in conversations.

There are many terms that we can have really looooong arguments about if they are inclusive, or non-inclusive. And there are many that are really obvious. Depending on your first language, it can be even more difficult to differentiate.

This plugin contains, for now, four terms, where IMHO the tech industry as a whole is coming to/came to a consensus to change (the existing) standards. It will grow, over time. If you want to see some of this for yourself, there is a discussion about these terms here.

Now, if you ask yourself "Do I really need this plugin?"... read further.

Why would I need an ESLint plugin for that?

There may be a high likelihood you won't need it. You still may want to use it though.

First, if you read all this text, and if you haven't been aware of this topic until now, then I've reached my goal for this project. Think about it, read about it (there's plenty of information on the internet), discuss with your colleagues and friends, and hopefully apply a more inclusive language.

Second, if you want to raise awareness, using this plugin is an option (eventually not the only one). Just having it in your codebase, and with that eventually bringing people to this repository and text, is a step. When more people learn, more people will apply these patterns to their own language.

Third, if you want to participate, you can open issues on the repo. Or customize this plugin for your own usage or language, fork the repository, whatever you prefer. I don't care really about npm installs, or stars on this particular repo. I care that you start learning about inclusive language, and how to apply it. It's still a journey for me, unlearning many different behaviours.

Installation

Ok, you're here, so let's come to the technical part.

You'll first need to install ESLint:

$ npm i eslint --save-dev

Next, install eslint-plugin-inclusive-language:

$ npm install eslint-plugin-inclusive-language --save-dev

Note: If you installed ESLint globally (using the -g flag) then you must also install eslint-plugin-inclusive-language globally.

Usage

Add inclusive-language to the plugins section of your .eslintrc configuration file. You can omit the eslint-plugin- prefix:

{
    "plugins": ["inclusive-language"]
}

Then configure the rule use-inclusive-words.

{
    "rules": {
        "inclusive-language/use-inclusive-words": "error"
    }
}

That's it. You can find information on how to customize it in the rule documentation.

New dependencies added: eslint-plugin-inclusive-language.

Generated by :no_entry_sign: dangerJS against 8c87cb5f23f2bbdba3802b161ac7c91fb9cf6af5

Previous