Remove recommendations of Chrome Extensions

[sam-github]

The only Chrome Extension currently recommended is NiM, there are no
other links to the Chrome webstore. This removes the extension from all
locales.

Fixes: #1908

[june07]

Happy Monday to all.

For the record, I just want to note that I disagree with this PR (not that it seems to matter in the least).

Further no reply has been made to any of the concerns raised in #1908, namely:

@fhemberger have things changed with regard to how this is going to be treated moving forward?

If a decision is being made one way or another it would be nice to see a solid explanation outside of simply approving a PR that changes state that has been consistent for the prior ~3 years. The issue began with a

doubt this is GDPR compliant

to

I would prefer if we wouldn't recommend any

Chrome Extensions at all.

Disappointing to say the least.

[ChALkeR]

I think that we should somehow document that no browser extensions should get into the list, to not have misalignment in case if anything appears in the future.

Perhaps a comment <!-- could solve that?

[MylesBorins]

+1 to a default of no browser extensions

[benjamingr]

@june07 I get that this might be disappointing to you as you maintain NiM and it was removed for a practice other extensions follow. Moreover, the exact rational, acceptance criteria or process was never explained to you or written in public.

The truth of the matter is we don't have a precise process for inclusion so we lean heavily towards removing things people find objectionable. This is made even more frustrating by the fact it is clear the participants (me included) believe you are doing the work on NiM out of care and genuine concern for improving the lives of developers within the Node ecosystem which is essentially why most of us are here in the first place.

My major concerns here are:

• As far as I know we don't recommend any of the other several tools for this. I don't really understand why it is our place to recommend tools beyond chrome://inspect for debugging Node. Debugging chrome before chrome://inspect worked well was a pain that is mostly gone.
• The barrier for things being blessed by node (like NPM for example) is very high and Node gets criticised for including any such tools even when they are extremely useful or vital for the development process.
• Node itself does not gather any analytics when people use it that is sent to a third party. NPM for example only gathers analytics when you interact with its registry directly and as far as I know the CLI does not phone home if you configure it with a private registry. Gathering information about users is a real concern some of our consumers have.
• The addition to begin with was done in Re-added NiM link to documentation. Also 25 language additions to debugging documentation. #1938 which I hasn't really received a lot of traction or upvotes. I am not too familiar with the nodejs.org process but this would not have landed in core without two LGTMs.

Given all these objections it might sound like I'm for removing it - I'm mostly ambivalent since I do think it's generally useful and I'd like to see this move in a constructive direction and I empathize with how frustrating this might be from your PoV.

Have you tried reaching to @nodejs/tooling or @nodejs/inspector to see if NiM or some variant can be brought in to the Node.js project and OpenJS foundation?

• The code base is open source anyway so people would be able to use it the same way.
• Publish keys and process would be established in such a way people can verify that the version they have running is the same thing on the website.
• Official status would increase the project's popularity and other people's willingness to collaborate as it would invite them into the OpenJS foundation.

I am not sure if this is viable, worth it or even helpful but I wanted to outline a possible solution if you want it to be included in the docs. I'm sorry if this message came out as long, I felt like we owe you that much given you are interacting in good faith and have contributed to the project a bunch of helpful stuff :]

[sam-github]

@june07 The conversation was indeed wide-ranging, and while there was no consensus on issues specific to your extension, there does seem to be consensus on the Node.js project avoiding any possible problems by no longer recommending Chrome extensions.

@nodejs/website-redesign @nodejs/security @nodejs/collaborators @nodejs/inspector This has only approvals and could land now, but since the website repo may not be as well watched as nodejs/node, I'd like to give any collaborators who disagree with this a chance to speak up. Please review #1908 for background.

[benjamingr]

I am not in favor of removal nor against.

[sam-github]

@ChALkeR wrt #2259 (comment), I could put that in, but it would be only the one list, in the one markdown file, which seems to me overly specific, since this is a policy that affects all of the docs. I'm not sure if there is a global enough place, perhaps one of the website team can tell me if there is.

I think the main thing is that when/if it comes up again, there is a conversation that can be pointed back to, and I think this conversation is sufficient. Beyond that, the website team is here, and they know what the policies are, or enough do that going forward someone should notice.

[boneskull]

It’s unfortunate, but removing this is the right thing to do.

I’m also +1 on re-evaluating the display of any links to 3rd-party tools.

[boneskull]

(@benjamingr fwiw this is outside the scope of the tooling group; we’re focused on the command-line)

[benjamingr]

@nodejs/tsc asking you because leadership - who is the correct team to bring this up to if tooling isn't right?

[sam-github]

Landed in 27851ef

[sam-github]

@benjamingr I don't think there is a team with "sole responsibility", so its not a matter of a single "correct" team.

Anyone with a github account can express an opinion, any collaborator can approve (or not) a PR, and if consensus among collaborators isn't reachable, the TSC may be requested to vote as a last resort.

[june07]

@benjamingr I want you to know that I REALLY appreciate the time you took to offer your feedback. It was very helpful and I think others would do well to follow your example. It makes all the difference when helpful suggestions are offered, explanations given, and overall care/empathy is shown to interactive members of the community. I'm thankful that you seem to understand that I have acted in good faith and have recognized the contributions made, and as such have offered a constructive not destructive response.

I can't stress enough how much your response even though not on my side or in my favor, was appreciated and helped to curb the largely negative (and in my opinion cold, accusatory, and unfriendly to say the least) response from most others, either directly or through their lack of any response what so ever outside of an approval of change. While I understand that people are busy with other "more important" issues, I think the dismissive attitude of some can have very negative consequences to the morale of a community and certainly to individual contributors.

With that said, THANK YOU AGAIN. I'll continue engaging with the Node community with the hope that more are like you. I'll continue working on NiM regardless and may look into the other possible outlets that you so helpfully suggested. With a smile!

[june07]

I will certainly be following up on this idea.

I’m also +1 on re-evaluating the display of any links to 3rd-party tools.

[Trott]

@nodejs/tsc asking you because leadership - who is the correct team to bring this up to if tooling isn't right?

@nodejs/website is responsible for the website but this seems to be outside the purview of their enumerated responsibilities so I would say @nodejs/tsc would have final say if there is no clear consensus.

[june07]

I will certainly be following up on this idea.

I’m also +1 on re-evaluating the display of any links to 3rd-party tools.

#2270