Per the TSC meeting two weeks ago

CC @nodejs/tsc in case they have comments

Move the "Version Support" link from the footer to the header (will require mobile design adjustments)

I don't think we should have "Version support" link on the header. Hierarchically, "Download", "Docs" and "Version support" are not on the same level. I understand that we have it on header, but I don't see any value (please correct me if you do) in moving this to a header.

Add a “pill” on the front page below the JSConf pill promoting support options for Node. Have this pill link directly to the HeroDevs site using the URL https://herodevs.com/.

I don't see any JSConf pill on the homepage of nodejs.org, can you share what you see? I personally don't think we should do this.

Adjust the link on the releases page (https://nodejs.org/en/about/previous-releases ) to be the following: https://www.herodevs.com/support/node-nes?utm_source=NodeJS+&utm_medium=Link&utm_campaign=Version_support_page

Sounds good to me. No objection from my end.

Personally I think it's almost more important than downloads or docs - people need to know the support status of their production applications far more than they need to know how to download node (that they might get through lots of other means), or the docs (that they'll probably google directly to and never just "browse").

@anonrig you're right, the pill USED to be jsconf, now it's the Next10 survey link

@anonrig you're right, the pill USED to be jsconf, now it's the Next10 survey link

FWIW the pill is Next-10 until the end of the month, followed by JSConf until August? (Maybe September, I don't remember exactly). If we even were to change the pill, it wouldn't be for a while

I don't think we've done two pills before, won't that clutter the UI for the user? CC @nodejs/nodejs-website for opinions.

To clarify, I understand the intent here, and it might even be goodhearted; But unfortunately, adding a banner of "Get support to EOL versions of Node' "Oh, just signup at HeroDevs product"; Sorry, no that's a hard pass.

Also, most of users are not interested on EOL versions, shouldn't even being using EOL versions and the information of support of EOL versions shouldn't be at the front page, it is at the very least misdirecting and/or confusing. (This is my personal understanding, I might be grossly incorrect here!)

I don't see any JSConf pill on the homepage of nodejs.org, can you share what you see? I personally don't think we should do this.

The JSConf is the OpenJS Foundation conference; We had history of promoting our Foundation's Officially-organized Events in the past. Be it Node.js training certification provided by LFX or OpenJS World or (now, as OpenJS World isn't a thing anymore), JSConf.

Move the "Version Support" link from the footer to the header (will require mobile design adjustments)

Also not, sorry. The Header is already cluttered enough. It is an UX aspect that the header must have a finite amount of options. It is visible enough by being on every's page footer, and right on the About page. We even (if not yet merged, I do recall we did it already) added it on the Download page for every time you select an EOL version.

I chatted with @ljharb on DM, and he explained me the reasons behind this change. I'm fine with this proceeding, although I do believe we shouldn't add this to the header, nor make it a pill.

The home download page is due to a redesign (once @canerakdas finishes the creation of the simple version of the downloads page)

If we follow the design below:

I do think we could add a text/copy for ESP/EOL. What do we feel about this alternative?

@MattIPv4 if you're asking "in the hypothetical case where a Foundation staff and a TSC member are giving contradictory requests, what should I do?", it's the same as if there were disagreement between any other project member, and you can ask escalate to the TSC to resolve the situation (as I said, hopefully by finding a compromise, or by voting if it comes to that).

And obviously, neither TSC members nor Foundation nor anyone can require you to do something, you're always free to align or not your volunteer work on what others are asking – though if you work on something that does not have consensus, it's unlikely to land.

if you're asking "in the hypothetical case where a Foundation staff and a TSC member are giving contradictory requests, what should I do?", it's the same as if there were disagreement between any other project member, and you can ask escalate to the TSC to resolve the situation (as I said, hopefully by finding a compromise, or by voting if it comes to that).

Indeed, and I appreciate the answer!

A joint Foundation+TSC meeting, with a quorum of voting TSC members present, decided to move forward here.

I feel that I might have missed context...or at least from my impression, what happened was:

1. The TSC wasn't explicitly supportive of this design. Feedback was requested with the context that this design was part of the contract and if we don't do anything we might lose funding for infra, and with that context, the question was whether we object to the design. The question was formulated in a way that is difficult to think through in real time to say no. At least, that is how I perceived the communication.
2. It was missed that Yagiz still had a standing objection, and Yagiz wasn't at the meeting to bring it up again. I don't think the standing objection was brought up in the meeting, at least not this week. Even if it was...
3. When there is a standing objection, a TSC meeting is an invalid device to "decide to move forward", according to https://github.com/nodejs/node/blob/main/GOVERNANCE.md#tsc-meetings - a vote needs to be casted.

I think the lesson that we need to learn, once again, is that TSC meeting - especially the private section - is the wrong venue to get consensus, at most it can be used for getting a sense of the temperature in the room. Asynchronous communication would work much better for people to evaluate a decision and think it through, and avoid ignoring standing objections.

@ovflowd as a TSC voting member, I've raised my concerns/thoughts on this on #7773 (comment). I'm -1 on everything except updating the link.

This shouldn't have progressed without a formal TSC meeting and a vote (if required) since I have an explicit -1 comment here. Now we have a CTA button which is bigger than our "install" button.

Sorry @anonrig this got overridden by the Foundation and the TSC. Apparently your block as a TSC holds no value in this situation (as far as I understand); Check with @mcollina there was a meeting.

I want to publicly apologize for my earlier comment. It was written in a hurry and very poorly worded. While I clarified my intent in a follow-up comment here, I want to reiterate that what I meant to convey was that the block appeared to have been resolved—either due to a TSC decision or contractual obligations that were discussed elsewhere.

Looking back, I recognize the way I phrased it was not only dismissive but also factually incorrect. That was never my intent, and I’m genuinely sorry for the confusion and the tone I used.

FYI the homepage ESP button is now blocked/hidden by all major browser-based ad blockers: easylist/easylist@9138523

Edit by @avivkeller:

View w/ Adblocker

FYI the homepage ESP button is now blocked/hidden by all major browser-based ad blockers: easylist/easylist@9138523

Indeed. Even my AdBlocker is blocking it :D

I wanted to share a positive suggestion I saw on Bluesky, which might be a viable option to include in our new documentation generation: https://bsky.app/profile/nicr.dev/post/3lsayzmdmm223

I wonder if it would make more sense to have it as a banner on top of all the EOL docs pages instead.

That would certainly also be very helpful, and hopefully much less controversial.

Indeed, that would ensure that the people who are most at risk see it, while keeping it not as “in-your-face” as people have described.

I don’t have an ad blocker but it seems to me the rule can still block any links to herodevs on the website and thus hurting traffic. The damage done by the initial design may continue to affect any future attempts we make if our goal is to bring the traffic up to generate enough income for the foundation to fund the CI infra.

Also, for what it’s worth, per the ESP guidelines, our requirements are as follows:

• Projects should have a prominent Version Support Page
• Referral links to partners must be placed within the top ⅓ of the page
• The Version Support Page must link to partner pages for the versions our partners support
• When documenting which versions are no longer receiving patches, consider adding a link with copy: “read more about extended support options” that directs to an EOL page.
• Project-specific referral links will be provided as part of the onboarding process.

(https://github.com/openjs-foundation/cross-project-council/blob/main/project-resources/ESP/ECOSYSTEM_SUSTAINABILITY_PROGRAM.md)

So, if we did change the link to the EoL blog post, like mentioned in the PR, it doesn’t seem like it would violate any obligations, fwiw.

I believe we can close this issue as we have a few follow-ups:

• Implement real-time (on-load) updates to API docs live-environment api-docs-tooling#327
• Dedicated Partners/Sponsors Page + Updates on the Home Page #7909
• Dedicated EOL page #7906

And there's a PR open for a temporary solution, pending TSC approval: #7883