Suggestion: link timestamping

[dmitriz]

May I suggest to put the time, when the link was last updated, next to it?
As some of the links grow old and outdated, it is becoming hard to know which ones are most recent.

At present I have to go and scan through the git history which feels crazy :)
Maybe there is a smart automatic way to do it?

[sindresorhus]

For what purpose? Why do you need to know which ones are more recent?

[dmitriz]

You are right, I should have put the goal first. :)

The real problem for the reader, especially with limited time, is to have some sort of quality comparison clue to help quickly decide which links to check first.

Timestamping is one such clue that can be useful for some lists.
For example, this list of Angular seed projects has many projects 2 years old, and things have really moved a lot in Angular. I suspect also the links are old, so seeing that quickly would save people time if they don't want to see such old projects (with Angular, you most likely don't).

It is frustrating to see mostly old projects with no clear indication from outside until you actually go and check it, and not forget to check the dates first and go through the history looking when the project was substantially updated, as opposed to just bumping the version.

I know, that list is not managed by you, so no blame here :)
Also I understand that people do it in their free time, and can get busy or move to other priorities. In that case, again, having clear timestamps would help to see that.

It is possible that this is less of a problem with your lists, as long as you commit your time to keep managing the quality. Then again, you probably need to be some sort of "magician" to ensure that hundreds to thousands links are not only of high quality now but also stay this way. Or maybe you are running magically automated quality-assessment scripts against those projects :)

By timestamp you would simply tell your reader --- "Look, this is when I put the link, now it is your choice to check it or skip it. I put it because it was awesome back then, but no guarantees now." Kind of taking some burden away from maintainers, which can be a good thing. :)

This may be less of a problem with your lists as you keep most of the sublists small, (except npm packages, for which the quality clues are much more subtle and harder problem to deal with). But people will copy from you, get excited, put their awesome links, but will not share your quality commitment in long terms. Which is when those timestamps would really help the reader.

Just an idea.

[sindresorhus]

I agree with the sentiment in theory, but for packages, using timestamp as a quality metric is flawed, especially in the Node.js world. Most of my packages are tiny and focused, meaning they can actually be done. Even though a module of mine haven't been updated in 2 years doesn't necessarily mean it's outdated or abandoned, it's just done. Also not useful for this list as I live and breath Node.js and I'm aware of the status of most of the packages here and keep the list continually updated if anything better arises.

I do see this being useful for lists for projects with high churn, like JS frameworks, or where the author isn't able to ensure high quality. Can you open this issue on https://github.com/sindresorhus/awesome instead with your above comment as issue description? Better to discuss there as this is a general awesome list problem.

[dmitriz]

Glad you see it this way, totally agree.

The reason I didn't post it on the meta-awesome-list was because for that meta-list, it actually doesn't seem useful to know how recent the link to list is. Which is why I posted here.

Then again, if you think it is more appropriate to discuss there, I'll be happy to.

[sindresorhus]

Even though it's not directly related to the awesome list, that issue tracker is also for general awesome list issues.

[dmitriz]

Yes, totally makes sense.