Package-maintenance: Suggestion: Provide alternate phrasing dictionary

[lgraubner]

A lot of common used phrasing is offending and should be avoided. For example master/slave can be replaced with primary/secondary (or anything else). See this medium article for example. There are a lot more phrases.

I'd suggest providing a dictionary with alternate phrasing which can be discussed here or somewhere else. Package owners should be advised how to avoid pitfalls and be as inclusive as possible.

(just saw @bnb comment at #59 which leads me to suggest this)

[balupton]

"Should be avoided" is a statement of values rather than fact, which is evidenced by the nature of the problem. As such, this should be opt in per community/person, rather than enforced as a standard cross-community.

I think I saw some repos already on github that offer such listings and suggestions, some even scan your text and provide politically correct alternatives. Listing them would definitely be useful for those who share the sentiment.

https://github.com/get-alex/alex
https://github.com/nodejs/inclusivity/issues/9

[wentout]

I'm very sorry, seems I just can't understand.
I'm not so good in English, I think I'd better understand raw terminology than a way to reveal the meaning of what happens inside.

Moreover

If some progamm, let me say quoted, directly from my level of language "is controlled by the other programm", which terminology I must use?
I didn't got this from that article.
Moreover, technically the "Primary" DB can be write protected and configured "only for reading" for all readers other than "Secondary" DB. And that "Secondary" might be chained to consume data from underlying layer of DB set, which itself is allowed for writing. So it might be hard to explain but secondary DB is allowed to fail and primary is not. So which DB is main and "for what this is a main DB" is only a subset of explanation model for example utilising System Analyst role.

I just trying to say it might be really hard for non natives to understand the difference between the "main" and the "primary". And, as for me, saying "everybody must use ruled dictionary", emm... is another rule about necessary additional effort to communicate normally. For sure I will try to keep it in mind to make my thoughts understandible, because this is important for me to avoid any offends. But if I will fail on that way, how will I demonstrate I was thinking only of a good mood? And again, if it will be necessary for somewone to explain some hard topic to me about my code, I will not fail with raw terms, but I will definetely fail if some generally used keywords will be missing to avoid my "hidden offends".
Sorry for lack of explanation, it is hard to translate.

[lgraubner]

@balupton You are right. Maybe it shouldn't be forced but I think it would be nice to have appropriate links to resources covering this topic.

@wentout I think this is a weak argument. Just because those phrases became "common" they shouldn't be considered as the only solution to describe the underlying concept. I think there can be descriptive alternatives. Hopefully some become common as the current ones. And in the case you don't understand something just ask. I believe there will always be someone willing to explain.

[wentout]

Thank you, I think I understand.

As for me, I'm trying to get rid of that sort of terms in my native language too. However, it is really tough effort, for some terms we don't have direct translations. And, therefore, completely no linking to the context of the non tech meanings. And we just use english keywords directly without any translations at all, putting them between native language words while explaining how some tech works. And therefore I just sometimes still unable to translate normally. For me it just might be tech term with no other meanings or contexts at all. Sometimes I'm unable to predict there can be other context.
So my second question was about how can I protect others from myself if I will unfortunately fail to abnormal terms trying to explain something.

[ljharb]

Note that node (and a growing number of projects in the industry) has a code of conduct - following it is not “opt in” or optional.

[mcollina]

I think advising package owners to use a certain type of language is mainly out of scope for this initiative. Changing some language does not make a package more maintainable.

I personally find this type of unasked advice of bad taste, and opening issues asking for the maintainers to do more work is at the opposite direction of this initiative. I have recevied this type of “advice” in the past, and they typically came with a bad tone and language - these issues often assume that a maintainer used term XYZ because they are in favor of ABC. At best, I would see them as “lecturing” the maintainers on how to behave online. Note that these issues only come from people that have never contributed a line of code to the project, and they likely do not follow up with a PR to do the change.
(Note that I think we should change these things, however I’ve a complete distaste on how these changes have been forced on several projects).

I think we should provide information on how creating an inclusive community foster contribution and collaboration. This include adding a CoC, and maybe some rewording. It should also include open governance, and sharing the burden/adding commit bit etc.

[ljharb]

Changing language absolutely can make a package more maintainable, because it excludes fewer (or more, depending) people. Separately, contributing a line of code to a project is in no way a requirement to be helpful nor to be able to ask something of the maintainers - I’ve never contributed a line of code to node, but i don’t think it’s a stretch to say I’ve contributed to node a decent amount.

I definitely agree it’s out of scope of this initiative to file issues in other projects asking them to do work - but it’s very much in scope to provide guidance in best practices, which objectively include having governance, and a CoC that requires inclusive language.

[mcollina]

Separately, contributing a line of code to a project is in no way a requirement to be helpful nor to be able to ask something of the maintainers - I’ve never contributed a line of code to node, but i don’t think it’s a stretch to say I’ve contributed to node a decent amount.

I totally agree with this. I meant individuals that are not part of the project community. I’m sorry for the confusion.

[balupton]

Note that node (and a growing number of projects in the industry) has a code of conduct - following it is not “opt in” or optional.

Correct. My earlier point is that this sentiment should not be mandatory for all communities, but merely optional for people to opt into at their discretion, and optional for communities to opt into at their maintainers discretions, which they then correctly enforce on their people through the tools of oppression, suppression, and repression.

Changing language absolutely can make a package more maintainable, because it excludes fewer (or more, depending) people.

It can also censor what some find meaningful, because another can consider it merely distasteful. When it goes this way, it seems to over-optimise inclusivity, in a way that harms meaningful discussions, and even excludes those willing to have important discussions. Such as the enforced censorship at #59. Hence why other communities can chose to opt out of this sentiment, as they wish to err on the side of facilitating meaningful discussion at the risk of triggering insensible senitivities (as we are talking about censoring perceived violations here, not censoring hate speech which requires the intent of hate from the speaker). Respect does not require submission to the offendee, as sometimes it is the offendee's perceptions that are maladapted, rather than the speaker's intent — optimising for one or the other, which is what agreeable vs disagreeable personality temperments do, both can err too far on one side when applied too broadly (one risks allowing more hateful speech and incorrectly protects haters, one risks allowing more undue censorship and incorrectly protects maldaptive perceptions), hence why differing approaches to this problem exist, not just logically, but in our differing values too. Hence why governments often find the balance at banning/censoring hate speech (which is purely detracting, not worth the cost) yet allows/tolerates/permits distateful speech (which is deemed more valuable (a better benefit cost ratio) than banning it).

[benjamingr]

@balupton first of all, thanks for engaging and expressing your views. I'm going to take off my "package maintainer" and "core collaborator" hat and put on my moderator one for this comment.

At the moment - please consider that you have not engaged a lot with the Node.js core project before and the first time I'm seeing you in this tracker it's talking about politics. That is not to say you're not a competent engineer - only that this is my perspective.

The question of "who's right" isn't interesting to me to be honest. It's about "what would be the best path forward for the JavaScript ecosystem" and "what would make projects more maintainable". I absolutely agree with @mcollina that it's not Node.js's place as a project to enforce its CoC across other projects or the ecosystem.

Node.js does have a CoC, we intend to enforce it and it's been working out quite well for us. The project is friendlier and more productive than it was before the CoC and we're quite happy with it as a whole. We intend to enforce the CoC across the board and moderate any comment that violates it.

That said - I ask that you reconsider your last response. You seem to feel strongly about this view. I request that you step back and consider what you actually want to accomplish here and how the way you've gone about it so far has worked out for you.

Feel free to reach out personally (my email is listed in https://github.com/nodejs/node ) if you want to discuss this further in private.

[lgraubner]

Stepping in to clarify my intent for this suggestion: Even if it might sound like this should be enforced I don't want this to be an additional burden for package maintainers. This would be kinda counterproductive in the sense of this initiative. Therefore I totally agree to @mcollina.

But still I think an inclusive worded package invites more people to contribute and helps the idea of this project. Package owners could be provided with resources and advice what to rephrase. I know this is not the biggest part of engaging people, but it definitely helps.

[Qard]

If you're interested in providing docs/resources around more inclusive writing styles, then I would assume PRs are welcome. 🤷‍♂️

Not everyone in the group is going to want to commit their own time to those efforts, and that's fair. We're all volunteering our own free time here. If you want to see something specific come from this group, you're welcome to step up and help make that happen.

[mhdawson]

@lgraubner to echo the discussion, I think this can fit in with the baseline practices being discussed in https://github.com/nodejs/package-maintenance/issues/119.

If you wanted to write up the text for this best practice along with links to resources that can be used that is probably the next concrete step (I said link to resources as it was mentioned that there are already some resources and even tools so not sure we need to develop a new list, although that still may make sense).

[rexagod]

I'd be happy to work on a parser package that points out words based on their effective valence in a file, bringing such words to the maintainer's notice. After that, I guess it's entirely up to them to modify such words or leave them as they are (hence not enforcing such modifications in any way). It's worth mentioning that I've chose to wotk with the valence of words as a measure to achieve the objective and hence avoid any side effects whatsoever, but I'm definitely open to suggestions!

[Eomm]

@rexagod Could you elaborate?

I though a document would be enough to broad awareness.
I think it is not a matter of "banned-words" only, but of inclusivity

[rexagod]

Correct me if I'm wrong but to me, this seems to be an issue regarding lessening the usage of contextual offensive (negative valence) words, by some method, be it a parser package that analyzes the code or simply just a document that outlines this idea, as you said.

What I was proposing here is a package that does the same and runs on an event (say, compilation, build, hooks, etc.) that shows the user potentially offensive words (the valence measure I proposed should take care of inclusivity) which they may go ahead and make changes to so as to ensure our motive here, while not forcibly levying them to do so.

The reason behind why I propose such a package is the fact that even if someone is about to commit code that does not adhere to our ideas here, be it after a long break or something (after which they could very well forget about the document), this will remind them about any such occurrences. Including this package in CI could point out to the reviewers if there is still room for such changes in the code. In the case of just a document, reviewers/users may overlook/forget about adhering to it and corrections in the future may become very tedious.

We could also keep a document with a detailed text to how one could practice naming in a _more acceptable way_, including good (and bad?) conventional practices and examples, etc. (or whatever you think the doc should include).

[Eomm]

I don't want to block you to write some code, but I feel that this utility would not hit the target at the core and, reading the comment above, it seems that such tools exist.

When I say "target" I refer to:

• the WG scope: a package more maintainable
• "provide guidance in best practices, which objectively include having governance, and a CoC that requires inclusive language." ref comment

For these reasons, I think that a document that explains to maintainers and future maintainers why to adopt a language and a CoC file, etc.. would help the project/package. And I'm not sure how a tool could do that.
The master/slave diatribe is only the peek of the iceberg, I read some report from ethics.org and I was speechless: I don't think at all that writing this doc will be easier than writing a tool, I think it could be interesting instead!

Anyway, I don't want to impose my idea of course.
We should argue to reach the consensus

[rexagod]

Apologies for the delay, @Eomm!

I skimmed through ethics.org and realised that the scope the this issue is way too broad to be handled by a tool. I'm all for collaborating on the document which, as is obvious, won't be any easier than the tool, but definitely worth it!

I'd love to hear any ideas/sources you think would be a good starting point for the formation of this doc, meanwhile I'll dig up a few myself!