Are FAQs Non-Perishable?



  • One of the departments in our organization just contacted IT with this request (slightly paraphrased to keep my job):

    We have received a complaint that the Frequently Asked Questions for the Department of [Redacted] are not up to date because some of them show an update in 2009 or 2010. The actual information is accurate and does not need to change, I just need to show an update date that is in 2013. I will be submitting my changes to the FAQs for you to review, but the only change will be to the update date.

    I am open to suggestions on how to solve this problem.



  • With one like this:




  • Pepper throughout the document notes like "for more information about xyz, contact jane@initech.org" or "if any problems occur while rebooting this server, contact bob@initech.org". Then you'll be forced to update it every time someone retires. Lo, your problem of pointless "updating just to change the update date" updates is solved!



  • Simple, add a little text saying "information on this page is accurate as of [date]" and update that date whenever someone has checked the FAQs to make sure they are still current.

    It seems like a stupid thing to have to say, but it can be important for legal reasons to make sure that whenever you certify that something is true, you say what date you certified it to be true on. And on the same note, it's important for marketing reasons for that certification date to be more recent than 4 years ago.

    tl;dr; change the "update date" to a "certification date".



  • If the "update date" means "last date when we made sure the content is up to date", I don't see any WTF in just changing it to 2013, after (important detail) making sure all the content is actually up to date.



  • Dynamically generate the date on the page, but make it 4 months ago so people don't get suspicious.



  • @lincoln said:

    Dynamically generate the date on the page, but make it 4 months ago so people don't get suspicious.


    Now that is a GREAT way to guarantee future WTFs. Imagine another 4 years from now when the FAQ info really has changed, but nobody knows how long it's been since it was valid since the data just updates automatically every 4 months. Or 10 years from now. I like your long-term investment approach to generating content for this website.

    Or, if you're a conscientious jerk who wants to keep us from being entertained, you could just get the intern to read the FAQs and make sure they are accurate every 6 months (bonus points if you can swing it right around the start of the semester when the work-study folks come around)



  • @lincoln said:

    Dynamically generate the date on the page, but make it 4 months ago so people don't get suspicious.

    No need to be dynamic, I'm sure you can do it with pure CSS.


  • BINNED

    Go find a place to work that isn't run by idiots?



  • @anotherusername said:

    Pepper throughout the document notes like "for more information about xyz, contact jane@initech.org"
    You're missing a great opportunity there. The contact details should be that of the person who complained that the FAQ was not up to date!



  • @PedanticCurmudgeon said:

    Go find a place to work that isn't run by idiots?

    Any idea where that may be?



  • So you're really complaining that someone asked you to update a timestamp because it's getting to be several years old?

    Really? This is a problem for you?

    Glad you're not on one of my teams.



  • @OldBrooklyn said:

    One of the departments in our organization just contacted IT with this request (slightly paraphrased to keep my job):

    We have received a complaint that...

    Are your departments that responsive when someone complains about content on the site being wrong? If so, then I'd say this is a minor WTF ("it's good to care, but complaints should be triaged") rather than the situation I usually see ("suddenly, nothing happened").

     



  • @dynedain said:

    So you're really complaining that someone asked you to update a timestamp because it's getting to be several years old?

    Really? This is a problem for you?

    Glad you're not on one of my teams.

    No one asked me to update the timestamp (they are going to take care of it themselves by pretending to update the FAQ).  I think it's stupid to have a "last updated on" date that is phony.  You don't see a problem with this?  I'm glad I'm not on your team, too.



  • @OldBrooklyn said:

    @dynedain said:

    So you're really complaining that someone asked you to update a timestamp because it's getting to be several years old?

    Really? This is a problem for you?

    Glad you're not on one of my teams.

    No one asked me to update the timestamp (they are going to take care of it themselves by pretending to update the FAQ).  I think it's stupid to have a "last updated on" date that is phony.  You don't see a problem with this?  I'm glad I'm not on your team, too.

    If someone has read and validate the info is still correct, what's wrong with updating a timestamp? Especially if this is publicly visible information that can be perceived to be out of date when 3-4 years old.

    Something that is tech-related and 4 years old is most likely out of date unless it's documentation on a legacy product/platform.



  • @dynedain said:

    @OldBrooklyn said:

    @dynedain said:

    So you're really complaining that someone asked you to update a timestamp because it's getting to be several years old?

    Really? This is a problem for you?

    Glad you're not on one of my teams.

    No one asked me to update the timestamp (they are going to take care of it themselves by pretending to update the FAQ).  I think it's stupid to have a "last updated on" date that is phony.  You don't see a problem with this?  I'm glad I'm not on your team, too.

    If someone has read and validate the info is still correct, what's wrong with updating a timestamp? Especially if this is publicly visible information that can be perceived to be out of date when 3-4 years old.

    Something that is tech-related and 4 years old is most likely out of date unless it's documentation on a legacy product/platform.

    As Snooder pointed out, it's using the word "updated" that doesn't seem right. "Updated" implies that the FAQs themselves have been updated.

    As a user it's impossible to tell if a set of FAQs/guidelines/whatever that have not been updated in 4 years are current or out-of-date. It's entirely appropriate to have some date stamp on the page that says that the content has been checked and is still valid and correct.



  • @RTapeLoadingError said:

    it's using the word "updated" that doesn't seem right. "Updated" implies that the FAQs themselves have been updated.
    All FAQs were checked for freshness on Dec 3, 2013.

     



  • @El_Heffe said:

    @RTapeLoadingError said:
    it's using the word "updated" that doesn't seem right. "Updated" implies that the FAQs themselves have been updated.
    All FAQs were checked for freshness on Dec 3, 2013.

     

    Is that a "Use By" or "Best Before" date?



  • @RTapeLoadingError said:

    Is that a "Use By" or "Best Before" date?

    "Sell by".

    I don't see a problem with this. Perception is what is important so need to keep things up to date. Just the other day I came across a website that proudly claimed that it "will be updated in October 2010". Must have left my phone in the Delorian.



  • @OldBrooklyn said:

    One of the departments in our organization just contacted IT with this request (slightly paraphrased to keep my job):

    We have received a complaint that the Frequently Asked Questions for the Department of [Redacted] are not up to date because some of them show an update in 2009 or 2010. The actual information is accurate and does not need to change, I just need to show an update date that is in 2013. I will be submitting my changes to the FAQs for you to review, but the only change will be to the update date.

    I am open to suggestions on how to solve this problem.

    I don't see the WTF. Especially in IT it is not unreasonable to assume that 4 year old information might be not fuly accurate and/or outdated. The suggestion someone else made of a "this FAQ is accurate as of xx-xx-xxxx" is a perfectly reasonable one.

    Reverse it, say that there would be a 4-year old FAQ which was outdated and following a practicular piece of it would crash/delete/DoBadThings™ to something. Say a customer would literally follow this advice and come to you for help.
    You'd probably slap yourself on the head for not updating the FAQ, but also be annoyed that someone blindly followed old instructions without consideration.


  • Discourse touched me in a no-no place

    @dtech said:

    I don't see the WTF.
    Notwithstanding your valid arguments, the WTF on the OP's part appears to be the fact there is only one timestamp relating to the information, and what appears to be needed is two:


    • Last updated
    • Last checked for validity


    Most of the other valid suggestions on this thread seem to revolve around changing the meaning of the timestamp from the first meaning to the second (which should, of course, include instances that would have been caught for the first.)

    So the (reasonable) suggestions are either

    1. Change the meaning of the timestamp to 'last verified on' and just retain the one timestamp (which would be updated on an update as well.)
    2. If it's important to know when it was last updated, but still have confidence the information remains accurate, introduce a second timestamp of 'last verified on'


    The second is usually overkill in most circumstances, so the first is probably the way to go.

  • BINNED

    @clively said:

    @PedanticCurmudgeon said:
    Go find a place to work that isn't run by idiots?

    Any idea where that may be?

    I used to work at a smaller company that wasn't run by idiots until it was bought out by a Fortune 500 company.


  • BINNED

    @clively said:

    @PedanticCurmudgeon said:
    Go find a place to work that isn't run by idiots?

    Any idea where that may be?

    I just saw your other thread. So you're a small business owner...



  •  Some medical sites (such as WebMD) put "Reviewed on" timestamps on their articles, meaning a medical professional has checked that it's accurate and up-to-date. It doesn't matter to readers whether any changes were made, only that its currency was verified.



  • @OldBrooklyn said:

    One of the departments in our organization just contacted IT with this request (slightly paraphrased to keep my job):

    We have received a complaint that the Frequently Asked Questions for the Department of [Redacted] are not up to date because some of them show an update in 2009 or 2010. The actual information is accurate and does not need to change, I just need to show an update date that is in 2013. I will be submitting my changes to the FAQs for you to review, but the only change will be to the update date.

    I am open to suggestions on how to solve this problem.

    Add the following FAQ entry:

    Q: Are the Frequently Asked Questions for the Department of [Redacted] not up to date because some of them show an update in 2009 or 2010?

    A: The actual information is accurate and does not need to change.



  • @OldBrooklyn said:

    One of the departments in our organization just contacted IT with this request (slightly paraphrased to keep my job):

    We have received a complaint that the Frequently Asked Questions for the Department of [Redacted] are not up to date because some of them show an update in 2009 or 2010. The actual information is accurate and does not need to change, I just need to show an update date that is in 2013. I will be submitting my changes to the FAQs for you to review, but the only change will be to the update date.

    I am open to suggestions on how to solve this problem.

    Necroposting note: the OP is 3 December, right, not 12 March? CS's date format is leaving me very confused.

    I have the opposite problem. A (buggy) license I'm working under requires me to put the date and person of the last modification to a file in the file itself. One thing this has forced me to do is rewrite the parser for some of the files just to implement a comment syntax, but the thing that amuses me most is that if someone forgets to update it, then when I update the date/person, I have to set it to now and me, because modifying the file to have a different last-modified date is still modifying it. This also has the side effect that the timestamps are pretty much completely useless.

    I'm reminded of the joke "days since this notice was last updated" notices, which are always set to 0, and which are frequently out of date.

    (We've since solved the problem by adding VCS hooks to update the date/person on every commit; if they never get out of date, we never encounter the problems caused by trying to fix out of date timestamps.)

     


  • Discourse touched me in a no-no place

    @ais523 said:

    Necroposting note: the OP is 3 December, right, not 12 March? CS's date format is leaving me very confused.
    http://forums.thedailywtf.com/user/EditProfile.aspx -> Site Options -> Date Format.



  • @ais523 said:

    Necroposting note: the OP is 3 December, right, not 12 March? CS's date format is leaving me very confused.



    It's December 3rd, yes

    @ais523 said:

    I have the opposite problem. A (buggy) license I'm working under requires me to put the date and person of the last modification to a file in the file itself. One thing this has forced me to do is rewrite the parser for some of the files just to implement a comment syntax, but the thing that amuses me most is that if someone forgets to update it, then when I update the date/person, I have to set it to now and me, because modifying the file to have a different last-modified date is still modifying it. This also has the side effect that the timestamps are pretty much completely useless.

    Or, you could just pretend that the timestamp isn't part of the file and update it to the correct time-stamp instead of being pedantic about it.

     


Log in to reply