As a Web Developer, I want to know when particular browser feature support was released for each browser, so I can decide whenever I may use it according to my compatibility requirements.
I have written a simple Tampermonkey script that do this (see screenshot), it adds the date as tooltip and (by double click) number of years feature is supported by particular browser.
I think it would be useful for many people as built-in site feature:
https://gist.github.com/SergeAgeyev/d780cc50b3612f022a6b4a702e9643b2
If relevant, you

can make a checklist for tasks.
Hey, interesting mock-up! Thanks @SergeAgeyev :+1:
cc @atopal, is this a new opportunity to assess or to user test?
I've been advocating for something that solves this issue for a long time. My 50 year old, but healthy for my age eyeballs have trouble reading that.
user.js script (tampermonkey) with this mockup is available on Gist, so you may check how it works:
https://gist.github.com/SergeAgeyev/d780cc50b3612f022a6b4a702e9643b2
To show indicators just double click on any part of the table on mdn site.
@jpmedley You may also use tooltips to show detailed information on each particular item.
Hey @chrisdavidmills (cc @Elchi3), I noticed you transferred this from the sprints repo, but shouldn't this be going to the Kuma repo, since that's where we handle the rendering? I would just think that this repo should have only issues related to the data, not the display of said data on MDN pages? (Not that I mind, just want to make sure!)
Oh and I'm totally down for this!
@vinyldarkscratch hi!
I did wonder about that, but I thought it would be good to drop it here to discuss the general concept and whether it would be good for the project first of all, before we got to thinking about the rendering.
If you folks wanted to handle it a different way, then I am fine with that — whatever is best for you.
Hmm, I'd definitely want to user test that. Not sure whether cramming more data into the tables is the solution, might be better to either offer that as a tooltip, or reverse it, have the age in the cell and the version number as the tool tip.
One thing we found out in user testing is that version numbers alone is probably the worst choice. Most people have either no idea that is the version number for a browser, or even if they do, they don't know when a specific version was released. Adding the date as a tool tip is probably a quick change we can make with minimal impact on anything else. I'd certainly support that.
We have tool tips filed at https://github.com/mdn/kumascript/issues/1119
I agree tool tips would be a good first step here. I don't know how this prioritizes against other work, though. How high does this opportunity rank, @atopal?
Against what outcome, Florian? Considering the priority outcomes for this year, this would probably not rank at all.
Against what outcome, Florian?
One thing we found out in user testing is that version numbers alone is probably the worst choice.
This sounded like users are unsatisfied now? So maybe against that?
Yeah, for Q2 and beyond we can look at the task completion rate outcome to see if this should be given priority.
+1 on showing the age instead of the version number, thought I'm not sure how this would work from a data standpoint. Would we still record version numbers in the BCD and calculate the age in the rendering macro?
Would we still record version numbers in the BCD and calculate the age in the rendering macro?
Yes, this would be the plan.
Given the changes to the MDN team, I don't expect any resources will be available to make major improvements to the compat tables soon and, in any case, the tables themselves are not part of BCD directly. In the interest of pruning issues and PRs that aren't actionable, I'm going to close this one.
(But if you think I've judged this wrongly, please let me hear about it.)