15

The Stack Exchange Blog is a great place with a wealth of information but, as site ecosystems change, the content in the blog becomes outdated and can actually cause confusion. That doesn't mean that the information should be removed, though... as it gives the history of the site and helps us know where we've been.

I'm recommending that we create something like the Historical Lock banner for outdated blog posts:

This blog post has been preserved for historical significance, but it no longer reflects current policy, so please do not use it as reference for current site policy. [optional: For current policy on this subject, please see this more recent blog post/MSE post].

I know that this may be something that's difficult to address because there's so many posts, but if the most egregious of them could be annotated like this, I think it would be really helpful. It would preferably be linked to a newer blog post or MSE post that explains the current policy.

As an example, Joel wrote a post back in 2010 about the Beta ecosystem and explaining that beta sites would closed after a certain amount of time if they didn't meet certain activity guideposts. Since that time, we've come to see (as detailed in Ana's post in 2015: Graduation, site closure, and a clearer outlook on the health of SE sites) that low site traffic and questions are irrelevant to site quality as long as a site has active moderation. As of the time of Ana's post, no sites were slated for removal, regardless of low traffic numbers.

I'm posing this request because I do occasionally see users posting these outdated blog posts as reasoning for something or warning. Particularly with this one, I've seen users on Beta sites worrying that their site will be closed due to inactivity. I think their concerns would be tempered if they knew that the blog post didn't represent policy.

If others know of blog posts like this one that are grossly out of date, feel free to comment with a link.

Improve this question

1 Answer 1

Reset to default
8

The main problem with labeling posts correct or incorrect is that policy and community norms are always evolving, sometimes daily; sometimes very slowly. So it becomes problematic when the posts are "mostly correct" or "half correct" or simply outdated enough to be (technically) correct but not really the concern it once was. These will be the vast majority of the cases.

We have the same problem with meta posts. Information is always changing, and even with thousands of people wiki editing these posts, they're still not 100% current thinking.

The reality of the situation is that there's a point where you have to get back to work and keep moving forward. If you spend an inordinate amount of time documenting and updating, agility and progress suffer disproportionately.

It's unfortunate, but it's just a pragmatic reality of the workplace.

This isn't to say [status-declined], but just to point out this is more difficult in execution than a simple banner placement.

Improve this answer
5
  • 1
    Surely an incremental approach is called for? We don't need to dig through and Fix All The Things, but when specific blog posts repeatedly cause problems and there's something else that already exists that we could link to (like the case the OP raises), doesn't it make sense to edit in that link? People do that on meta, but we don't have access to do it on the blog.
    – Monica Cellio
    Commented Jul 3, 2017 at 19:32
  • This is certainly true! Heck, I could imagine that, in future, we might inadvertently have old post leading to newer ones leading to yet newer ones, all with different policy. :) As to MSE, I certainly see questions asked here that are then duped to old questions and, often, the response from the asker is "But that's 6/7/8 years old, is that really still the only policy on this?"... and sometimes we have maintained the policy and kept it fresh and sometimes it's not something that's even been addressed at all.
    – Catija
    Commented Jul 3, 2017 at 19:32
  • 1
    @Monica Yes, I suggested (again very recently) that we pipe blog posts through meta or even adapt meta as the blogging platform itself— for exactly the benefits you cited. Declined. So we're stuck with a workload where "somebody" (who?) has to decide when/if a post is causing enough problems to warrant a call to action, and who is going to do it, how we'll fill in the void, how we'll address the confusion it causes, and if it's worth the effort and diversion of limited resources at all. A one-voice, wiki-less blogging system sucks for exactly that reason. That is why we created Stack Exchange.
    – Robert Cartaino
    Commented Jul 3, 2017 at 19:46
  • 1
    Incidentally, if there is a very specific copy change or action you feel should be performed on a blog post, the best chance of getting that done is to make a drop-dead-simple feature-request. That doesn't necessarily get it done (for the reasons I cited above), but it gets it closer than any other workflow we have now.
    – Robert Cartaino
    Commented Jul 3, 2017 at 20:03
  • I prefer general guidance and communities to work out the specifics. Through, sometimes communities seems to go against general guidance and a firm nudge is necessary.
    – Braiam
    Commented Jul 4, 2017 at 23:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .