[Wikipedia-l] Stable versions policy

Tue Dec 20 14:09:58 UTC 2005

Wikipedia Romania (Ronline) wrote:
>
>
>
> Oh, it would change very significantly. Under the first model, if stable
> versions are to be locked, then obviously no-one could edit them, thus going
> against the principle of Wikipedia. If the second proposal is to be adopted,
> which involves creating a new namespace/subpage for stable versions, it
> would still reduce the freedom of editors. Wikipedia was founded on the
> principle that *anyone* could edit the encyclopedia, and that their edits
> would be immediately seen. If the stable versions proposal becomes policy,
> there will be two versions of each article. Of course, the stable version
> would become the most respected version, while the "open" version would
> become sort of a draft. Therefore, when someone makes an edit to the
> editable version, his edit won't be immediately reflected in the stored
> version, even if it's an update. And when there's two versions of an
> article, readers will always choose the stable version, and thus, any edits
> to the editable version basically become unnecessary until they become
> incorporated into a new stable version, which according to the proposal,
> takes a large amount of consensus. Thus, Wikipedia's open, immediate nature
> becomes very cumbersome and it would become sort of like a Nupedia - a
> peer-reviewed encyclopedia instead of a true open encyclopedia.
>
> I think the proponents of these policies hide behind the fact that they are
> only "minor changes", but I think that all of the new proposals - from
> banning anons from creating articles, to semi-protection to stable versions,
> are all slippery-slope attempts to somehow make Wikipedia more restricted to
> combat vandalism. Combating vandalism is a worthy cause, but freedom comes
> first. We're the free encyclopedia, after all.
>
> Ronline
>
>   
No, I believe that the core values are that Wikipedia is intended to 
be/become an encyclopedia, and that it should be free, as in freedom to 
use and make derivative works (and to fork, if necessary). Freedom to 
edit is hugely important, but secondary to those core goals.

Having stable versions, and using those as a basis for moving forward, 
achieves all of these goals, with the primary two foremost. Thinks how 
open-source software gets made: anyone can contribute patches, but not 
everyone has CVS commit, and releases are in turn made of selected sets 
of patches (not necessarily the most recent ones, either).

If we get it wrong, then the policy can always be changed back, or, at 
the very worst, someone can still fork the project, and the two styles 
of development can continue to cross-pollinate.

The virtue of the multi-version approach is that it allows both the 
"pure-Wiki" and the "sifter" approaches at once, but without forking the 
project.

-- Neil