Add Last Updated Date for each checklist item

[jdegbau]

Would it be helpful to add a "last updated" date to each checklist item?

I know this might lead to some trust issues if an issue doesn't need to be updated frequently, but it could help users feel more confident that they're getting the most up-to-date information.

It might also help determine when a checklist item needs to be updated, or at least re-vetted.

[dmleong]

Are you thinking maybe of unchecking a section if some information has been pushed to that section?

I think this might be useful, although since this is saved in localstorage, a strong cookie purge would uncheck everything (it might be useful to also document somewhere that localstorage is used and we aren't selling people's data if it's not on there already)

[brianlovin]

Are you thinking maybe of unchecking a section if some information has been pushed to that section?

That's a good idea. Should be trivial to just make localStorage store a timestamp instead of a true/false value and then evaluate that against the section's lastUpdated.

It would be great if we could get help adding this into the build process somehow. Basically any commits that touch one of the /config/*.js files should trigger an updatedAt timestamp if the PR lands...that's probably quite complicated, huh?

it might be useful to also document somewhere that localstorage is used and we aren't selling people's data if it's not on there already

Maybe a one-liner in the /about page would solve this?

[joachimesque]

it might be useful to also document somewhere that localstorage is used and we aren't selling people's data if it's not on there already

Maybe a one-liner in the /about page would solve this?

Yes! I think it should be at least a two-liner, so we can also tell about the Google Analytics tracking, what is tracked, and a link to their Privacy Policy and the optout page.

We can also add a button to clear the localStorage, so they don't have to try to find it in their browser.

[joachimesque]

It would be great if we could get help adding this into the build process somehow. Basically any commits that touch one of the /config/*.js files should trigger an updatedAt timestamp if the PR lands...that's probably quite complicated, huh?

Sounds complicated… Why not adding a test when submitting a PR, to check that there's a diff on the date in the JSON file, so the PR cannot be merged if the date hasn't changed?

[brianlovin]

Sounds complicated… Why not adding a test when submitting a PR, to check that there's a diff on the date in the JSON file, so the PR cannot be merged if the date hasn't changed?

Not sure the best workflow here, to be totally honest :P