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