Deprecated Files [DONE]

[Elberet]

That's what I want to avoid. Forcing users to behave according to some weird standard isn't good.

[wahaha]

I didn't intend to force anyone to choose a special version or not, it was, according to your original idea, <quote>a recommendation: "Don't download this file, it'll either never complete because it's dead, or you'll just waste your downstream and someone else's upstream."</quote>

The "weird standards" are meant to simulate on which base a user would normally determine a deprecated file, to not make them do that work for ~24000 files.

I see two benefits with that automatic classifying:
- If it is used to hide files, it can quickly resolve the problem of cluttered expanded ep+file-views to any desired degree.
or
- If it is used to sort files into two groups (split by a <hr> or whatever), it could ease focusing on the "important" files.
- Relieves people from figuring out which file's probably the best version.

[Elberet]

Sorry, with "forcing" and "weird standards" I meant that an automatic classification would force those users who add files to the database to add them in a special way so that the newly released file does or does not flag one or more old files as deprecated.

to not make them do that work for ~24000 files.

Admittedly, that's a problem. But I wonder if an acceptable compromise wouldn't be to run a script over the DB that finds possibly deprecated files and flags them, and then let users change that flag through the usual file editing interface.

Regarding the benefits, I think that the first and second have the same effect, with the difference that the second option leaves users the possibility to try their luck and get a deprecated file, while the first prevents them from doing so at the benefit of a shorter files list.

Otoh, maybe there could be a profile setting to select whether deprecated files should by default be separated and shaded rather then hidden, or vide versa.

[wahaha]

I forgot:

- added at least 4 weeks ago.

*nod* ... important condition.

All of these conditions are debateable and depend highly on everyone's personal opinion. The inevitable result is a huge debate here. A user-controllable flag might result in contradicting creqs, but the moderators can deny these easier then endlessly discuss the hide conditions.

Welcome to the huge debate ^__^
Still, I think that debating it once is better than providing the mods with a constant stream of "(un-/)mark deprecated"-creqs.

But I wonder if an acceptable compromise wouldn't be to run a script over the DB that finds possibly deprecated files and flags them, and then let users change that flag through the usual file editing interface.

There's one downside when involving the users:
What if a (user-marked) "(not) deprecated" file has an increased (or decreased) user-count and even some people who (un-)share it?
When the user-set flag normally overrides the automatic classification, which change would be enough to override the user's opinion since it's probably "outdated"?

Sorry, with "forcing" and "weird standards" I meant that an automatic classification would force those users who add files to the database to add them in a special way so that the newly released file does or does not flag one or more old files as deprecated.

Interesting, I didn't yet think about it...

Well, I suggested to "hide* files with less than the x% of the average users/file (20%)" (* make that "mark files deprecated" ) - this could actually make some files return from the deprecated-state when a new file is added.
However, old files could also be marked deprecated, if:

• the new file is a v2**
• the new file has the right CRC whereas the old one is bad**

**as long as the old file isn't "popular" [low user-count, noone sharing it])
I think this is the desired behaviour.

After having looked at some eps of CCS, I'd nonetheless want to tweak the previous suggestions:

• Lame file = deprecated
• If anything's hidden, the notification line should include the languages
  E.g.: "Three more files: A-G (/), no group (/), no group (/)"
• The formula "mark if it has less than x% of the average users/file" should depend on the quality:
  users/ep * (30 + rating)% where the rating would be:
  corrupted = 20
  eyecancer = 15
  very low = 10
  low = 5
  medium or unknown = 0
  high = -5
  very high = -10

Otoh, maybe there could be a profile setting to select whether deprecated files should by default be separated and shaded rather then hidden, or vide versa.

Sounds good.

[Iceman[grrrr]]

as for v2 files, hide v1 when the v2 has more users than v1...
it solves the problem of a new version coming out 3 months after the first

[wahaha]

Need... complex... formula...

The question is: Just more users (50 vs 49) or significantly more users (50 vs 10)? If the latter - what is significant ^^

[Elberet]

A file with >40 users should probably not be hidden or flagged deprecated at all, even if the quality is close to eye-cancer and it's a no-group file.

[kidan]

I think if there is a v(2/3) availiable with a few sources people should be lead to this file, as the older version is somehow outdated and if you're trying to get something you want it in best quality possible, don't you? This way newer version would spread faster, too.

[Iceman[grrrr]]

everything above 40 shouldn't be hidden for sure except for eye-cancer...
of course if it is the only file, show it anyway!

and vor v2, when it has the equal amount of users than the v1, even if it is 10 vs 10, since the user has the same chances to download both, the first should be hidden...