Not who is going to decide all of this, but what.

Let's be professional about this. Forget the stone age way of counting by hand: Let an application sort thru it.

Application Parameters:

1) Select threads which captured a certain minimum number of "Up-votes".

=OR=

2) Decide to keep threads based on weather they went "Hot" or not.

=OR=

3) Choose threads beyond a thresh-hold perimeter of activity, for example - active for one or two weeks minimum.

I rather like the first one, keeping only the threads which had the upper 25 percentile of total number of "Up-votes", which would be a good indicator of the quality of the responses and advice. A simple application to analyze the database for such threads would be a nice project assigned by staff here at game dev for a volunteer in the Mods or Staff groups. If they can't find someone to volunteer then pay a firm to handle it, is my recommendation. Of course, if they wanted to be fanatical about it, then they could choose all three parameters.

Feasibility: High!

A college student who completed a full year of programming classes could do this.

Are you jocking? Talk about being shallow!

Prune information by votes? We're talking TEXT here, it's not like it's huge.

Not who is going to decide all of this, but what.

Let's be professional about this. Forget the stone age way of counting by hand: Let an application sort thru it.

Application Parameters:

1) Select threads which captured a certain minimum number of "Up-votes".

=OR=

2) Decide to keep threads based on weather they went "Hot" or not.

=OR=

3) Choose threads beyond a thresh-hold perimeter of activity, for example - active for one or two weeks minimum.

I rather like the first one, keeping only the threads which had the upper 25 percentile of total number of "Up-votes", which would be a good indicator of the quality of the responses and advice. A simple application to analyze the database for such threads would be a nice project assigned by staff here at game dev for a volunteer in the Mods or Staff groups. If they can't find someone to volunteer then pay a firm to handle it, is my recommendation. Of course, if they wanted to be fanatical about it, then they could choose all three parameters.

Feasibility: High!

A college student who completed a full year of programming classes could do this.

Feasibility: very low. Semantical analysis of text to decide if it is meaningful/relevant/obsolete/redundant is nontrivial and you are talking about deleting those threads which are not deemed worthy of being kept. You are going to be getting a huge amount of false positives, and to avoid these you will have to ultimately have humans double-check many problematic threads, which is a lot of work. It's not that simple.

No, I would much rather the search tool be improved instead. There you have a nondestructive approach to searching the database which can be improved and added to as time goes on. Then every thread is available, with the search tool making sure to rate them in order of relevance (or whatever criteria is desired) and the user can dig through the list searching for the information he needs. Sounds like a better and safer approach to me, don't you think?

By the way, all three of your metrics are completely unreliable. All these are going to retain are popular "what language should I use" threads. Most of the valuable threads only get a few replies (maybe one or two pages), possibly no upvotes at all, and are not active for very long, just enough for the community to help the OP solve his problem. And I hate to say it, but for someone who was claiming in his last thread that game development material needs to be handled on a case by case basis, this post can't help but make me chuckle a little.

Bacterius,

Safe testing makes all the difference in determining whether or an application is practicable.

It wouldn't have to select based on text. The criteria would be as I wrote earlier, those non-text issues:

Application Parameters:

1) Select threads which captured a certain minimum number of "Up-votes".

=OR=

2) Decide to keep threads based on weather they went "Hot" or not.

=OR=

3) Choose threads beyond a thresh-hold perimeter of activity, for example - active for one or two weeks minimum.

If the staff here at game dev wants to keep all of the database, then no problem exists. If they however want to select those threads which are already determined by the community as being of higher value, as indicated by how many up-votes and how well affirmed they were in the other two recommended parameters, then my suggestion is a valid consideration for discussion among them. After testing of the application in question, if they find that the results are too severe, then they can lower the value of each parameter by merely changing 1-3 numbers in the coding.

There is no easy solution, so I am sorry if my feasibility of HIGH was misinterpreted as "easy". Feasibility is not the same meaning as easy, just to be clear.

I personally am sure that my recommendation will indeed come to discussion with staff, that's how confident I am that it is a good one.

Folks,

Up-votes of a higher number given to the people who responded in the threads are the best indication of the quality of the advice given in them. The value of the thread is directly tied to the quality of the responses as best indicated by how may Up-votes were given by the community.

This is profound and effective, not shallow.

There are conversations from a few years ago on topics that I like to see new perspectives on. I for one am glad that gdnet keeps all the old threads around.