Brian <brian0918@...> writes:
Neil Harris wrote:
We will probably need to have the ability to rate versions as being
"stable version candidates", otherwise it will be difficult to move
from an older stable version to a newer.
By being able to rate/tag a newer version as a stable version
candidate, it could then be voted/rated/approved to either eventually
become the next stable version, or to be supplanted by another
candidate. Users should be able to see not only the history of all
versions, but of (say) all versions ever marked as stable, or the
larger set of versions marked as candidates for stability.
For simple things like spelling errors, this system would be way too
complicated for approving a newer stable version.
Hmmmm... that's an interesting corner case. But I think regardless that Neil's
proposed review process is the way to go. By vote or bureaucrat action, a
particular version of an article is nominated for review, users vote on it, and
if it is accepted it becomes the "stable" or "approved" version, with
various
view privileges (e.g. always shown by default, with older AND newer versions
only accessible from a special tab). The editing process continues "in the
background" however, with later additions to the article eventually converging
into a new review candidate, which then becomes the new approved version of the
article. Using your example of the [[Christmas]] article, Brian, the version
which became "Featured" would be the one users see by default and remain that
way until an expanded or otherwise improved version of the article came along.
This process should also curb revision wars and make editing a much more
deliberative process, since editors will no longer be able to control what users
see by default by grabbing control of the top version of an article.
With that said, one problem I noticed with the current review feature
implementation (aside from allowing only 1 rating per user of an article, and
thus implicitly limiting each article to a single "stable" version) is that it
does not force users to vote on a particular revision (though I guess this could
be achieved by locking the article). Thus you could get X votes for revision
1000, and Y votes for revision 1001, but the 2 sets of review data cannot be
aggregated because the revisions may be substantially different.