Wikipedia talk:Stable versions proposal/selecting

message: ===Semi-automation - recent stable version detector===
...I also suggest semi-automation.  "Stable" versions are generally just that: stable; they haven't been edited in a while.  An automated mechanism could go through the history and mark revisions with a tentative measure:
:k * e^(-c*age) * e^(d*[time before next edit])
where c is the decay rate (more recent versions should be prefered) and d is the stability unit.  both c and d could be inferred statistically per article, since some article are edited a lot(high d) and others not-so-much(low d), and some articles are about current events(high c), and some are about dead events(low c).
Revisions with a high such measure are candidates for the next "stable" version, to be selected by community approval. Kevin baas 19:37, 24 January 2006 (UTC)
thread_title: Software tools

message: ...I also suggest semi-automation.  "Stable" versions are generally just that: stable; they haven't been edited in a while.  An automated mechanism could go through the history and mark revisions with a tentative measure:
:k * e^(-c*age) * e^(d*[time before next edit])
where c is the decay rate (more recent versions should be prefered) and d is the stability unit.  both c and d could be inferred statistically per article, since some article are edited a lot(high d) and others not-so-much(low d), and some articles are about current events(high c), and some are about dead events(low c).
Revisions with a high such measure are candidates for the next "stable" version, to be selected by community approval. Kevin baas 19:37, 24 January 2006 (UTC)
thread_title: Semi-automation - recent stable version detector

message: I like this idea, but the big problem with publishing a version of the article in the way you propose is that the history is lost. Worse still, protecting the release page, while important, prevents us from making later necessary changes such as severe errors that were missed. Moving the article is not an option, since it can no longer be edited for future releases.
What we need, pursuing the software development analogy, is branching. We need a way to branch off a version from the current version that will have the same history but will no longer be edited except for "fixes"; that is, new content will not be added, extensive refactoring will not be done, it will just be fact-checked and small fixes done. This could be enforced by a strict review process. This will enable it to become more "polished" over time while the current version continues to grow in depth and organization. At a later time another "release" could supplant the old one, perhaps with an option of viewing the previous "release" if desired.
The end result would be the same we see with software: the release version becomes very reliable and is suitable for public use at all times, but without all the cutting-edge content (our equivalent of features) of the current version. Deco 01:29, 7 December 2005 (UTC)
replies: text: good idea. how about still having protected pages but fixes (republication) of those protected release articles are a speedy process just like we have Wikipedia:Speedy delete. -- Zondor 01:59, 7 December 2005 (UTC)
replies: text: While I see what you're getting at, I think it would become outdated fairly quickly, and unless the articles were to be specifically and thoroughly checked, I don't think they would be likely to be any more accurate than the live 'pedia. Ambi 04:47, 7 December 2005 (UTC)
replies: text:  Let's be more clear about the goals we have. The purpose of the proposal is to produce an end product that is to be consumed. ie. To be printed and to be used in schools in which students rely upon. Any article that is left unprotected is not considered fully trustworthy because at any given time, it could be subjected to vandalism no matter how quick we respond to it. Yes, they have to be thoroughly checked if it is ever to be used in court cases. If the stable versions are still left unprotected, we are still at the original problem in trying to reach Wikipedia:1.0 because how can you starting printing them while they are still being edited (unprotected)? Articles can continuously be improved forever but it has to come to an end at some point. Protection is a declaration of the final revision. Plus, they can always be republished. Once we get 10,000 strong finally revised articles, we just click Print and Wikipedia:1.0 finally becomes a reality. -- Zondor 06:56, 7 December 2005 (UTC)
replies: text: This is what I envisioned with this, too. Are we going to try to establish "stable versions" of every article in full, though, or are we going to only work on print-sized segments of articles likely to be included in a print distribution? I suspect the latter would be of more use for a print edition and would scale much better, enabling us to produce a much more accurate final product.  Ambi 10:28, 7 December 2005 (UTC)

text: I want to stress that it's not sufficient to republish the article, because while the working article might have additional corrections, it is also likely to have new content or reorganization that has not been reviewed as thoroughly as the content of the release version (as it should - that's the purpose of the working version.) It may be desirable to copy some fixes from the release version back into the working version (or vice versa), but this may involve nontrivial modification of the changes due to content drift. Deco 22:53, 7 December 2005 (UTC)
thread_title:  Good idea, but what we really need is branching 

message: Hmmm...some kind of meritocracy.
*proportional to total number of edits?
*barnstars increase vote weight?
*community approve/disapprove votes on user page affects weight of user's vote? could increase anomosity - maybe just approve, and each user has a limit on how many users they can approve.  i don't know, this is tough.
*community vote on vote weigh increase/decrease? (this would make it rare).
Kevin Baastalk 18:33, 28 January 2006 (UTC)
thread_title: Vote weighing