-
Notifications
You must be signed in to change notification settings - Fork 6.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(knowledgbe/blog): removed deprecated knowledgebase #4999
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It hurts to remove this content knowing the time spent translating it.
But it's important to remove this old junk.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will no doubt find out (from complaints) that some content in there is, in fact, relied upon. But it may be that the best way to do that is to remove it and field complaints. Some suggestions that you should feel free to ignore:
- Maybe add a redirect for everything we're removing to a single page that says the content has been removed and why, but here are a few links where you might find what you're looking for (MDN, StackOverflow, whatever we think is appropriate).
- Maybe removal is step 2 and step 1 is leave a big banner at the top of all the pages for a month telling people it will be removed and where they can supply feedback or maybe provide suggestions for "this page should be redirected to this other page at MDN or whatever".
These are kind of idealized approaches, but I realize we may constraints that make them onerous or impossible.
Lastly, going to ping widely on this one: @nodejs/tsc @nodejs/website @nodejs/documentation
Similar to what happened with the /learn/ removal on nodejs.dev, I truly believe it's hard to measure what outside content relies upon, but more than happy to re-iterate removed content in a "request"-based fashion.
Sounds like a good idea. I was thinking about adding an I will make a PR to the
This is a really good idea, it would require applying the banner on all these pages, and honestly, people could still not notice the banner, or if they do, just ignore them and not open any complaint. I'm usually not a fan of purging content, but I'm inclined to purge this. I don't have any specific reasoning, neither I know who uses this. So I'm open to listening to how many people believe we should follow suggestion N.2; otherwise, I'm just going to remove the content. If we receive any complaint, then, well, then it's then. Of course, I'm doing this approach knowing this is legacy content that isn't indexed anywhere (on our website) except by vague robot indexing done by search engines. (For example, https://www.google.com/search?q=How+to+use+fs.createWriteStream%3F&rlz=1C5GCEM_enDE1016DE1016, we are the top result, but other sources are providing better content). |
Also, it is essential to mention that most of this content (if not all) is currently covered by the API docs. |
Also:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with or without Trott's suggestions
It seems there are unrelated Markdown changes, probably prettier Extension... |
Which unrelated files? (the change to remove the link on guides is intentional, but yes the rest was just prettier) |
I'm proceeding with merging as it is, as I'm low on capacity. If issues appear we can immediately revert and approach the current ideas. |
This PR removes the deprecated/outdated knowledgebase and translated blog posts.