First of all, let me thank @sindresorhus and everyone else for your titanic efforts to make these lists so awesome, it is greatly appreciated!!!

The problem I'd like to address though, is a challenging task to keep the lists relevant as things can move very fast and projects become deprecated, obsolete, outdated, unmaintained etc. As an example I can mention the list of AngularJS seed projects, many of which are sadly quite old and full of what nowadays considered bad practices.

Showing some of these old projects to a newcomer without proper warning can actually be considered harmful, as people can mistakenly learn some bad practices from there without being aware that they are. Especially with AngularJS this feels like a problem with people misjudging the framework based on the outdated information, when modern best practices actually solving many of those old problems. Given the current fast pace of the JavaScript ecosystem and the overwhelming and growing amount of information, this problem will likely only get worse.

On the opposite side, the most modern, recent and relevant projects can sadly blend and get lost amidst other older ones, making it hard for the reader, especially beginner, to find them.

So I'd like to suggest to discuss possible ways to mitigate this challenge, and help the reader by adding various meta-data beside the links that would help to decide which links to check first.

I have previously proposed to timestamp the list entries here as one possible meta-data that may be easy to automate and @sindresorhus rightfully suggested it belongs here. It is based on the assumption that the resource was considered "awesome" at the time when the link was put and the reader would quickly see when that happened.

I think that would really help the reader with the type of resources whose awesomeness might change fast in time. I'm sure the author would not put many of those links now but wants to keep them for historical or whatever reasons.

It is not a perfect solution and might not be so helpful for other types of resources, where other clues may be needed. However, it is a simple information that would keep things more transparent, and may have different use for different people. Also it would help the maintainers to feel less guilty and less responsible for the content by clearly saying how old it is.

As @sindresorhus pointed, this metric may be flawed e.g. for npm packages, where other information could be useful such as:

• the number of downloads;
• the number of stars;
• the number of open issues;
• the date of the last commit;
• the size of the package with all dependencies.

Especially the package size with dependencies and how long it takes to download is what I found very hard to estimate in advance.

Of course, any meta-data generation should be fully automatic and should not add any burden to the author. If anything more can be done to save the author's time -- the better!