Concern over adding publication dates to external links

[chrisdavidmills]

I was reading @dipikabh 's proposal about "See also" section guidelines. I think it is mostly excellent. The one part that concerns me is the bit about putting publication dates on external links.

This all started from this comment in her review of my CSS scroll-driven animations work.

In general, I understand why we might want to put dates on links, and sources. However, I am concerned, because the linked articles may be updated, and there is a risk of ending up with a maintenance nightmare of out-of-date date references. I do have a bias here — I get quite a lot of my information from developer.chrome.com and web.dev posts, which tend to be written early in the lifecycle of a technology and as a result get updated a lot when the spec changes or new features are added. They always put an "Updated" date next to the publish date when this happens. I wonder how common that is on other publications that we might commonly link to.

I think something like this would work well:

• Animate elements on scroll with Scroll-driven animations on developer.chrome.com

Seeing that the link is to a reputable source helps build reader confidence, and they can find out how up-to-date it when they get there anyway.

If we are determined that we want to put "Last updated" dates on external links, how concerned are we about maintenance? Do we have any thoughts about what a maintenance plan might look like?

[dipikabh]

Thanks for flagging this concern, @chrisdavidmills. It seems valid from maintenance aspect.

I still like the idea about giving some indication to readers about how old or new a article is, especially when there is a list of external articles in the "See also" section. The date gives a quick scanning handle to readers to choose from the list (plus we also sort chronologically the list when authoring/updating, a one time effort - from latest to oldest) and also a quick sense of the content they might be looking for.

Keeping the maintenance aspect in mind, how about we mention only the year but not the month and date? That would more or less cover the scenario you've described about a spec undergoing changes until it finally stabilizes (and as a result, the associated posts). So even if a post is updated numerous times in a year, we'd reduce our requirement to keep the date absolutely up-to-date.

[chrisdavidmills]

Thanks for the response @dipikabh. I think just putting the year would be a good compromise; this still gives the reader an idea of if the article is recent or old (which is the kind of litmus test we're going for, really?), while cutting the maintenance burden down a bit.

[dipikabh]

Agree. I'll open an issue and a PR to fix the style guide and whatever little occurrences of complete dates we have at the moment in "See also". I'll link back here shortly. Thanks, Chris.

[dipikabh]

I've opened this PR mdn/content#27656 to update our writing guidelines as well as the few occurrences of the long date format we had.

[Josh-Cena]

If a blog post is expected to be updated through the years, I think it will qualify as a "timeless doc page" and does not need a date at all. The intention was that one could easily search, say, "2007", and remove all posts from 2007 because they are likely outdated (I surely don't want to read "learn more about this exciting new ES5 feature!"). However, from my experience, not all v8.dev/developer.chrome.com posts are neatly up-to-date and sometimes they just have patches like "Update MM/DD/YYYY: this content X is no longer accurate". In this case it would be good to remind readers when the post is from.

[OnkarRuikar]

What about StackOverflow links or documentation links that are internal truths?

---

With this feature following things will be possible:

• we can easily find out and replace old links, e.g. say find modern replacements for links before 2007
• we can automate updating the update year of the pages using a script that sends HTTP HEAD request and read Last-Modified response header.

[chrisdavidmills]

What about StackOverflow links or documentation links that are internal truths?

With this feature following things will be possible:

* we can easily find out and replace old links, e.g. say find modern replacements for links before 2007

* we can  automate updating the update year of the pages using a script that sends HTTP `HEAD` request and read `Last-Modified` response header.

+1 to automating this; nice thoughts @OnkarRuikar. This would be really good for MDN content because we could do it solely based on the appearance of an external link, using the HTTP header. We wouldn't need to pollute the content with any macros or non-standard syntax that other content consumers would have difficulty parsing.