# So, why the taboo against resurrecting old threads? **URL:** \ **Category:** The BBQ Pit\ **Created:** [September 19, 2005, 3:10am UTC](https://boards.straightdope.com/t/so-why-the-taboo-against-resurrecting-old-threads/322311 "2005-09-19T03:10:01Z")\ **Posts on this page:** 10\ **Page:** 2
**Author:** ![tomndebb](https://avatars.discourse-cdn.com/v4/letter/t/b9e5f3/32.png) [@tomndebb](https://boards.straightdope.com/u/tomndebb)\ **Post date:** [September 20, 2005, 1:11am UTC](https://boards.straightdope.com/t/so-why-the-taboo-against-resurrecting-old-threads/322311/21 "2005-09-20T01:11:47Z")
> [@ltfire](#): > > I asked in ‘About This Message Board’, why the date that the OP posted couldn’t be placed under the OP’s name. Then, you’ve got a chance to go right on by, and not waste 10 minutes before you notice that the thread had whiskers. In general, the Reader is opposed to user modifications. Any modification that steps outside the vB code adds a feature that must be saved and re-inserted when software upgrades are applied. This means that the techs need to save the changes, find out where the changes will be re-inserted after the upgrade, the upgrade must be installed and tested, the usermods have to be applied over the tested “vanilla” software, then the usermods must be tested. (And if a usermod introduces a bug, each usermod must be tested separately to determine which modification or combination of modifications led to the problem.) This adds time to upgrades and complexity to the system and introduces potential bugs to the board. The Reader simply prefers that the system be run as close to “vanilla” as possible to avoid the hassle. ---
**Author:** ![wring](https://avatars.discourse-cdn.com/v4/letter/w/838e76/32.png) [@wring](https://boards.straightdope.com/u/wring)\ **Post date:** [September 20, 2005, 1:35am UTC](https://boards.straightdope.com/t/so-why-the-taboo-against-resurrecting-old-threads/322311/22 "2005-09-20T01:35:03Z")
is this thread too old to respond to? ---
**Author:** ![Q.E.D](https://avatars.discourse-cdn.com/v4/letter/q/51bf81/32.png) [@Q.E.D](https://boards.straightdope.com/u/Q.E.D)\ **Post date:** [September 20, 2005, 2:09am UTC](https://boards.straightdope.com/t/so-why-the-taboo-against-resurrecting-old-threads/322311/23 "2005-09-20T02:09:56Z")
> [@Lute Skywatcher](#): > > Doing so would require different rules for different forums, given that in Café Society it’s permissible to revive old threads depending on the circumstances. Yeah, but still pretty trivial. Just need to do a different SQL query for each forum rather than for all fora as a group. ---
**Author:** ![Scott\_Plaid](https://avatars.discourse-cdn.com/v4/letter/s/258eb7/32.png) [@Scott\_Plaid](https://boards.straightdope.com/u/Scott_Plaid)\ **Post date:** [September 20, 2005, 3:03am UTC](https://boards.straightdope.com/t/so-why-the-taboo-against-resurrecting-old-threads/322311/24 "2005-09-20T03:03:46Z")
> [@Lord Ashtar](#): > > I still think that the mods and admins should write a script to close any thread older than three months (or whatever date they determine is adequate). Sure, the first pass will take a long time, but assuming it’s run on a daily basis it won’t take that long after that. Nio way, Jose. I suppose that this is a good rule to hold for GD, and pit threads, but the problem is, some Cafe threads deserve a second chance. For example, I have bumped multiple Cafe threads which have gone on to having one or two more pages added. I think it would be too much work to implement it for GD and the pit, but not the others. 😛 ---
**Author:** ![ltfire](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@ltfire](https://boards.straightdope.com/u/ltfire)\ **Post date:** [September 20, 2005, 8:11pm UTC](https://boards.straightdope.com/t/so-why-the-taboo-against-resurrecting-old-threads/322311/25 "2005-09-20T20:11:25Z")
> [@tomndebb](#): > > In general, the Reader is opposed to user modifications. Any modification that steps outside the vB code adds a feature that must be saved and re-inserted when software upgrades are applied. This means that the techs need to save the changes, find out where the changes will be re-inserted after the upgrade, the upgrade must be installed and tested, the usermods have to be applied over the tested “vanilla” software, then the usermods must be tested. (And if a usermod introduces a bug, each usermod must be tested separately to determine which modification or combination of modifications led to the problem.) This adds time to upgrades and complexity to the system and introduces potential bugs to the board. The Reader simply prefers that the system be run as close to “vanilla” as possible to avoid the hassle. I’m sorry, but when I read computer speak, my eyes fog over. This is the answer TUBADIVA gave, which is the reason I brought it up again. Follow me here. Right now, In GQ, at the top of the entry page, is the following, on the left. THREAD / THREAD STARTER. Under that is the following, QUESTION RE: MAID SERVICES Under that is the OP, JOE MAHMA. I just suggested that either along side, or, under the OP’s name could be placed the date that it was submitted. Seems to me that it’s simple, but you are saying the computer gods will throw lightning bolts from on high if you tried to implement that, correct? ---
**Author:** ![Lord\_Ashtar](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@Lord\_Ashtar](https://boards.straightdope.com/u/Lord_Ashtar)\ **Post date:** [September 20, 2005, 8:34pm UTC](https://boards.straightdope.com/t/so-why-the-taboo-against-resurrecting-old-threads/322311/26 "2005-09-20T20:34:12Z")
> [@Scott Plaid](#): > > Nio way, Jose. I suppose that this is a good rule to hold for GD, and pit threads, but the problem is, some Cafe threads deserve a second chance. For example, I have bumped multiple Cafe threads which have gone on to having one or two more pages added. I think it would be too much work to implement it for GD and the pit, but not the others. > > 😛 Then it could be implemented in only those fora. I still don’t see what all the fuss is about. Since we’ve gone P2P, anyone who’s not around anymore is marked as a guest. If someone calls someone else out on a position that they no longer hold, they have the opportunity to come in and explain what their new position is and why they hold it. In fact, I think the only threads that shouldn’t be bumped are threads where one poster pits another. There’s no need to be dragging up bad feelings like that from two years ago. I would think that threads in any other forum should be allowed to be bumped. This is, of course, just MHO, YMMV, etc. ---
**Author:** ![SkipMagic](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/skipmagic/32/20706_2.png) [@SkipMagic](https://boards.straightdope.com/u/SkipMagic)\ **Post date:** [September 20, 2005, 9:07pm UTC](https://boards.straightdope.com/t/so-why-the-taboo-against-resurrecting-old-threads/322311/27 "2005-09-20T21:07:45Z")
> [@ltfire](#): > > Seems to me that it’s simple, but you are saying the computer gods will throw lightning bolts from on high if you tried to implement that, correct? No, what he’s saying is that the change you’re suggesting is not part of the vBulletin version the Reader purchased. Because it’d be a user modification, it wouldn’t be supported by vBulletin; so, if something goes wrong while implementing the hack, we’re left to our own devices to find a solution. This, of course, takes valuable time and increases the chance that the board will end up unusuable for an amount of time. In addition, the next time an upgrade to vBulletin comes along (either a functional upgrade or one for security, etc…), that modification must be reapplied–and there’s no guarantee that the modification will work with the upgrade, thus taking a chance that the software will break down again and, as said before, not be supported by vBulletin. Generally, the wisest thing to do is keep the software package as close to the original form in which it came. (With the exception of the vBulletin-supported upgrades.) Any software hack can prove to be troublesome from support and end-user points-of-view. ---
**Author:** ![tomndebb](https://avatars.discourse-cdn.com/v4/letter/t/b9e5f3/32.png) [@tomndebb](https://boards.straightdope.com/u/tomndebb)\ **Post date:** [September 20, 2005, 9:26pm UTC](https://boards.straightdope.com/t/so-why-the-taboo-against-resurrecting-old-threads/322311/28 "2005-09-20T21:26:29Z")
> [@](#): > > Seems to me that it’s simple, but you are saying the computer gods will throw lightning bolts from on high if you tried to implement that, correct? Not lightning bolts, necessarily. The change is probably simple, in and of itself. The problem comes from the way that software works. All the stuff you see on the screen is the result of code. To make the screen look different, change the code. That part is easy. However, vB software is purchased from a company that is supplying code to a lot of different customers. Each time they fix a bug or add an enhancement, they send out new code to replace the old code. If you have changed the old code, when you replace it (in order to get the new improvements), your changes get replaced with the code sent from vB that does not have your change. For each change that you make, you need to keep a record of the change so that you can change the new code to do the same thing. (And sometimes, the new improved code works differently, so the change may not go in the same part of the code.) If you only change one thing in the code, making that change over and over as you get improvements from vB is not a big deal. However, once you have honored one request to change the code, you are open to having a lot of people ask for other changes. Pretty soon, you are not just making one change for every upgrade, but lots of changes. The more changes you have, the more likely that some changes will interfere with other changes–especially if the improvement code from vB is quite different from the code that was originally changed. There are no thunderbolts or disasters involved with a single change. Making changes based on requests from users, however, opens the door to a lot of potential problems. The Reader tends to eliminate the potential problems by simply keeping the door closed. This does not mean that your request was unreasonable. It does mean that your request will probably not be honored. ---
**Author:** ![ltfire](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@ltfire](https://boards.straightdope.com/u/ltfire)\ **Post date:** [September 20, 2005, 11:00pm UTC](https://boards.straightdope.com/t/so-why-the-taboo-against-resurrecting-old-threads/322311/29 "2005-09-20T23:00:27Z")
> [@tomndebb](#): > > Not lightning bolts, necessarily. > > The change is probably simple, in and of itself. The problem comes from the way that software works. All the stuff you see on the screen is the result of code. To make the screen look different, change the code. That part is easy. > However, vB software is purchased from a company that is supplying code to a lot of different customers. Each time they fix a bug or add an enhancement, they send out new code to replace the old code. If you have changed the old code, when you replace it (in order to get the new improvements), your changes get replaced with the code sent from vB that does not have your change. > > For each change that you make, you need to keep a record of the change so that you can change the new code to do the same thing. (And sometimes, the new improved code works differently, so the change may not go in the same part of the code.) If you only change one thing in the code, making that change over and over as you get improvements from vB is not a big deal. However, once you have honored one request to change the code, you are open to having a lot of people ask for other changes. Pretty soon, you are not just making one change for every upgrade, but lots of changes. The more changes you have, the more likely that some changes will interfere with other changes–especially if the improvement code from vB is quite different from the code that was originally changed. > > There are no thunderbolts or disasters involved with a single change. Making changes based on requests from users, however, opens the door to a lot of potential problems. The Reader tends to eliminate the potential problems by simply keeping the door closed. > > This does not mean that your request was unreasonable. It does mean that your request will probably not be honored. Well now, THAT changes everything! 😃 ---
**Author:** ![GargoyleWB](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/gargoylewb/32/199_2.png) [@GargoyleWB](https://boards.straightdope.com/u/GargoyleWB)\ **Post date:** [September 21, 2005, 6:41pm UTC](https://boards.straightdope.com/t/so-why-the-taboo-against-resurrecting-old-threads/322311/30 "2005-09-21T18:41:03Z")
I never worry…I always know that no matter how deep my longing for an old thread about tonsil stones or vaginal chunks, there will soon be a new one started to keep me squirming in revolted glee 🙂 [Previous page](https://boards.straightdope.com/t/so-why-the-taboo-against-resurrecting-old-threads/322311.md?page=1)