[opensuse-wiki] Sandbox implementation
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. :-) 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. 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. 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. 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. John Perry -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org
All,
2009/11/5 John E. Perry
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.
IC, you clearly understood the tightrope walk we need to achieve :-) Couldn't be expressed better actually.
:-)
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.
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. 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.
If I understood Rajko_m correctly "forcing into the Sandbox" may be tricky to do with the MediaWiki software.
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.
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.
Let's make this a short one: Please, Rajko_m, have a look at John's proposal and comment. I myself am looking forward to Rajko_m's testing of MediaWiki and FlaggedRevs this weekend. His proposal in the main thread sounds perfectly sufficient to me and he provided some valuable insight into both the configuration possibilities of the FlaggedRevs Extension and the Cons we may have with the Sandboxing approach. Please, let's concentrate on his efforts first and wait for the outcome before we get deeper into alternative approaches. I already "smell" that Rajko_m will come up with a win win situation next week anyway :-) If it turns out to be not successful in the end we still can jump into alternative approaches. That said, John, thanks for thinking about it and sharing this. Best, R
John Perry -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org
-- Rupert Horstkötter openSUSE Community Assistant http://en.opensuse.org/User:Rhorstkoetter Email: rhorstkoetter@opensuse.org Jabber: ruperthorstkoetter@googlemail.com -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org
Rupert Horstkötter a écrit :
everyone contribute with little or no restriction but restrict people's ability to put stuff in.
be aware that already not so many people write in, the smaller restriction may set this to zero... who write jdd -- http://www.dodin.net http://valerie.dodin.org http://news.opensuse.org/2009/04/13/people-of-opensuse-jean-daniel-dodin/ -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org
On Friday 06 November 2009 08:34:02 jdd wrote:
everyone contribute with little or no restriction but restrict people's ability to put stuff in.
be aware that already not so many people write in, the smaller restriction may set this to zero... who write
That is what I'm afraid of, too. When comes to technical stuff there is very few contributors, the most of activity on the wiki is social component. -- 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
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
participants (4)
-
jdd -
John E. Perry -
Rajko M. -
Rupert Horstkötter