Inactivity Time Limit for TRS/IP threads

I actually looked into the Trope Repair Shop recently after being unable to submit a ticket. I saw that more than a quarter of the existing threads have been inactive for at least a month. I'm thinking there should be some sort of system to auto-morgue these threads after a month of inactivity.

I mean like an automated feature. I could imagine bumping/removing all these threads manually would be a pain in the ass.

edited 26th Aug '12 2:13:41 PM by EarlOfSandvich

I believe there is one already. Or was it two?

There was a feature to auto-lock-and-remove threads that went inactive for a specific amount of time. People complained about the process being automated, because it didn't allow them their last chances to get the thread's issue resolved.

It also caused weird problems because the threads weren't bumped before locking, making it very difficult to even find them in the Morgue to try and deal with them.

Personally, I'm against eliminating a thread when the trope is in the middle of having something done, such as wick cleaning or transplant or splitting or whatever. If people want room to create a new thread, they should help do the work to finish an old thread.

Yeah, too many people seem to think that all you have to do is submit something to TRS, and your job is done. The issues have to be resolved, which often involves hard work that people don't want to do. Making it so that nothing ever happens in TRS because discussions always get auto-closed, just so that it's easier to submit new pages to TRS, where nothing ever happens because the discussion will inevitably be auto-closed, doesn't seem like an ideal solution. Make yourself a To-Do note if TRS is full; that's what I do.

(I also try to prioritize and submit what looks like the easiest-to-resolve issues from my queue first.)

Willbyr clocks all IP threads after 30 days of inactivity, which works really well. Septimus is or was working on something similar in TRS.

Agree, and that's why automated c/locking wouldn't be a good thing: Threads in the middle of cleanups, threads which need crowners, and threads where the level of misuse for a trope is so high that it mustn't be shelved would all get mixed up with ones where a prompt for discussion was needed to determine if there is a problem, threads which are done but not locked, or something like that.

"Was" - ccoa is doing it now.

Also, before anybody says "threads need to be resolved" 1) there is such a thing as a crowner and Pending Final Action signal, and exempting them from an autolocker would be reasonable 2) not all threads can be resolved.

I personally prefer an autoclocker here, so that some flexibility is left over.

The mods often do not put Pending Final Action or other icon tags on the threads that need them, though.

An autoclocker, that bumps threads, would be reasonable. Automatically ending all attempts to fix a trope, without even bumping first, is not reasonable and has caused tons of problems. I and others have had to pick through old discarded threads and bring up unfinished wick moves (even from renames!) to Special Efforts to get them resolved. This was not good at all.

I'll be honest — I have a few threads languishing in TRS and YKTTW because hardly anybody has been willing to help do the actual work of sorting misuse out of examples and wicks, so I'm left with thousands of wicks to do myself, even if I can't keep up with newly added misuse. People just seem to be waiting like vultures for the day these threads are locked for inactivity so they can introduce their (equally-doomed) thread proposal.

edited 26th Aug '12 12:39:25 PM by ArcadesSabboth

Auto-locker, I'm dead-set against. An auto-clocker, that could help, but I dunno if Eddie would want to code it to set different times. 30 days is plenty of time for an IP thread to come to some sort of decision, and that could even be shortened, but I think TRS needs at least 45 days.

TRS can work with 30 days. The current backlog is mostly because we slipped behind too much.

Yeah, come to think, autoclocking does sound like a much better idea. Still think that thirty days should do it in order to incentivise renewed efforts. IP can be made in such shorter notice, given how things are run there*

edited 27th Aug '12 7:30:31 AM by EarlOfSandvich

A "last chance" can easily be given by having it be a double-elimination process. At the 30 day mark a thread gets an automatic bump. Only one. Now the thread is back on the first page, and people can see it. Now the thread only has seven days to get X posts (X is up for discussion) or it's banished for good.

And then everyone agrees that something should be done, but nobody wants to put in the time or effort to do it, so the thing falls off the map, and something else gets added, and everyone agrees that something should be done, but nobody wants to...and the cycle goes round and round and nothing actually gets fixed.

I can see clocking and locking threads where there's no agreement about what, if anything, should be done. But that takes human judgement, and all-too-often, that's not the problem. The biggest problem is that nobody wants to fix things. They just want to whine about how something is broken, and hope that others will fix it.

And yes, I'm occasionally guilty of this myself, but after watching TRS for a while, I've realized that just adding new tropes without fixing the ones that are there is not a useful approach. We don't need to lock old threads; we need to create an environment where people fix things that are broken. I actually think that lowering the limit on the number of threads, again, might be a more productive approach.

^While I agree on lowering the cap, I feel that the "nothing gets fixed" attitude is something broader and harder to fix.

Regardless of how it can be fixed, making it easier to ignore work that needs doing (and worse, legitimizing!) is only going to make it worse.

Is this still wanted?

No. We need to deal with the shit we start, not abandon it halfway. Hold TRS hostage again if you have to.

Agreed, I don't think this is necessary.