develop a plan for divisive language from our dependencies

[richterdavid]

Building on #193: we will not be able to fully scrub Knative of known divisive terms while we rely on dependencies that have divisive terms in the APIs that we use. Please develop a plan for addressing this, e.g., tracking current instances and engaging with current dependencies, policies around introductions of new APIs/dependencies, etc.

/assign markusthoemmes

[markusthoemmes]

Related issues

knative/client#1031
knative/client-contrib#79

[markusthoemmes]

I'm leaning towards saying: "We try to influence upstream deps to adjust APIs as appropriate. We track such occasions in issues and apply ignore commands for our linting".

That is in fact what we're actively already doing. Not sure if there is anything more actionable here. WDYT @richterdavid?

[richterdavid]

Sounds like a good start.

There are other things we could do though, such as isolating usage of these APIs behind a proxy/facade/adapter class or module so that they aren't in widespread usage in our codebase, evaluating new dependencies for divise language, or moving off intransigent old dependencies that make no progress on this issue.

[richterdavid]

Basically, are we willing to make engineering decisions based on this issue, or only naming decisions?

[markusthoemmes]

Honestly, I'd tackle this once it becomes a widespread problem. Currently, the only "offender" is cobra in the CLI AFAIK. They have "whitelist" as part of their API and that's used in a few places in the CLI. Far from being widespread though and the upstream community is already aware.

That said, yes I believe we should be somewhat sensible about API usage and our linting tools will force us to deliberately disable it's warnings once we use an offending API. Personally, I'd leave it at that for now, hoping that'd generate enough of a forcing function for people to consider things in a code review to avoid riddling their code with linter ignores.

[richterdavid]

That's understandable, but how will you know if it's becoming, or has become, a widespread problem, and wouldn't it be better to avoid getting to the latter point?

Yes, lint will provide some natural backpressure. Maybe come back to this periodically and re-evaluate, including the spread of lint disablement statements?

[markusthoemmes]

I'll close this as it hasn't become an issue at all. The only offender is still Cobra and that's tracked in the client repository. Whenever something creeps up, we'll have to make a conscious choice in disabling the linting, so I'd say that's good enough.