On Thursday 05 November 2009 11:39:25 John E. Perry wrote:
One of the beauties of a wiki is that much more information can be put into it because anyone can put information into it.
That said, if it's done without care and some control, we find a mess after a short time. So we need to try to keep the principle of letting everyone contribute with little or no restriction but restrict people's ability to put stuff in.
:-)
Contradictory, ain't it :) The problem is that not many people feel that they should go around and instruct others how to do stuff, and even bigger problem is missing templates for new users. I had some text, once, that I would simply copy and paste, modify to particular situation, but that was not Mediawiki style of template, that anyone can use.
I like the sandbox idea; but putting limits on its availability to the open public, either as contributors or as users, violates the original wiki principle.
Sincerely, it is lesser about principles, more about software properties, that has very limited support for restrictions. It is all build around Q/A method that counts on fact that if everybody can write, after some number of iterations, any text will reach maturity. Our problem is that we don't have many people willing to write, so iterations are very slow, and article is usually obsoleted before it reaches maturity. The most aggravating thing is when you see how much time people spend writing in mail lists, forums, IRC, blogs etc.
How about a parallel-tree implementation? There would be two trees, one rooted as "sandbox" and one as "certified", or some such.
Every new contribution is flagged as "sandbox" and linked into the sandbox tree, but also linked appropriately by the contributor and/or editors into the category and/or project trees. Users would normally search on verified, conformant resources in the "certified" tree, but would have the clearly marked option of searching on unverified, tentative sandbox resources, too.
That kind flagging seems to be possible with Mediawiki extension FlaggedRevs, where history of articles (page that you can reach when you click on History link at top of the article) is that tree that you propose, with checked/approved version marked as stable.
Browsing indexes would contain all contributions, but the sandbox stuff would be highlighted, and maybe even turned on/off at the user's option.
Access to the sandbox tree would be for editors and moderators, and all new contributions would be forced into the sandbox tree. As moderators, negotiating with editors and contributors, approve contributions, the "sandbox" link would be removed, leaving the contribution clean and already in its proper place in the wiki, and now available to the default search and unmarked as tentative or developmental or whatever.
There would have to be a parallel sandbox portal, too, so editors wouldn't have to search through the entire wiki for the prospective contributions they want to work with. This parallel tree would mirror the certified tree, to make it easy for editors and moderators to see how it would fit into the certified wiki.
Things to discuss would be how easy to make sandbox material available to normal users, how to ease discussions between team members and contributors, who gets to remove the sandbox flag, whether and how to distinguish "major" from "minor" edits, and likely other matters that don't come to my mind at the moment. And, of course, the first discussion would have to be whether this is even worth discussing in detail.
Let me see what mentioned extension brings to the vanilla wiki (without openSUSE styling), and how hard is to learn to use it.
I don't believe this proposal is premature, since implementation methods could influence opinions on the merits of FlaggedRevs vs. sandbox ideas, and indeed I believe I perceive a melding of the two concepts here.
As mentioned in another email, some control has to exist, and if FlaggedRevs can provide to reader (page visitor) with information about article version status then we have all you described, and what is necessary for better Q/A.
John Perry
-- Regards, Rajko OpenSUSE Wiki Team: http://en.opensuse.org/Wiki_Team People of openSUSE: http://en.opensuse.org/People_of_openSUSE/About -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org