[opensuse-wiki] QA process - FlaggedRevs VS Sandboxing
Team, we still need to agree on either Sandboxing or FlaggedRevs as our QA process for the openSUSE Wiki - I'm the assignee to start this discussion... so, here it is. During our Meeting last Friday, the general concensus was to go for the Sandboxing approach, but I know that there are other opinions as well from parties not joining the Meeting and thus I'd like to give another possibility to discuss the Pros and Cons of both Approaches before we decide which one to implement finally. During our meeting last Friday, we came up with the proposal to get the opportunity to test both approaches in a testing environment to give the Wiki Team an actual idea. Frank, would it be possible to set this up? This isn't urgently needed but would certainly be desired. So far the foreword :-) As I outlined several times before, I myself am for Sandboxing (I mean this was an integral part of my initial concept-proposal) as our QA Process. I'll explain it again: 1. New articles would need to be created in a Namespace Sandbox, so e.g. Sandbox:Nvidia. As soon as the author feels the article confirm with the Guidelines and sufficient from a content perspective, he'd present the new article in Sandbox for reviewing purposes. This would be done utilizing a (to be created) Wiki Forum at forums.o.o where we may use a crowd of 35.000 proofreaders (at best). The author gets feedback that way and the article should evolve. After a certain time, the new article will be moved and categorized into the main Namespace and thus be part of approved openSUSE documentation. The decision to move the article would be the responsibility of a Wiki Moderator. Thus I proposed to define the role of a Wiki Team Member as a supporter/moderator (this also makes sense for e.g. the mentoring program we'd like to implement - different story) 2. Existing content? We need to distinguish between minor and major edits here and define those within the Guidelines. A minor edit covers spelling corrections, add a link as a reference etc. Within the Guidelines we encourge editors to do only minor edits to existing pages. Whenever a major edit needs to be done/is desired, the author requests a working copy of the article in Sandbox where he can work on it. Once it's done, the new article needs to pass the reviewing process, just like a completely new one, and the decison IF that article is finally sufficient to replace the existing one in main Namespace is the sole courtesy of the Wiki Team. We certainly may need to restrict this approach to the main Namespace (content interesting for the end user), but the decision about the structure of the Wiki is ongoing - started by Henne. Thus we need to look how that works out in the end (and restrict the Sandboxing approach just to parts of the Wiki structure we'll agree on). Yeah, that's it! I feel this as a valid approach to stop the uncontrolled growth of the openSUSE Wiki and to ensure proper quality of articles confirm with the Guidelines from a design, formulation and conception perspective. To get feedback about this approach I interviewed Martin Gräßlin from wiki.ubuntuusers.de - they have imho one of the best wikis out there from a usability and quality perspective and they use this approach for ages. Martin told me that the acceptance factor is awesome and the process is easy to handle for the Wiki Team. That's what I can tell you, i.e. forward to you as an actual experience. The alternative would be to go for the FlaggedRevs MediaWiki Extension proposed by cboltz and afaik supported by Rajko_m. FlaggedRevs, in short, provides the opportunity to have several revisions of articles in parallel and the one approved by the Wiki Team is shown to the user, the others are hidden until one of them gets approval and replaces the currently shown one - at least that's how I myself understood this approach. The Cons from my perspective are the additional maintenance of a MediaWiki Extension that has writable access to the database (according to Frank). Also I do not see how we should utilize a Wiki-Forum then (at least not obviously) and I myself feel no real advantage over the Sandboxing. That said, the intention is to give this discussion another period to evolve, so please, FlaggedRevs supporterrs, jump in and explain. Finally I'd like to close this discussion with an ultimate decision about the QA process we're going to implement - at some point in time we need to go forward and we need an agreement for either approach to cover/explain it within the Guidelines. Just now, the tendency by the team is to go for Sandboxing (checked in the Meeting - see transcript http://en.opensuse.org/Wiki_Team/Meetings/2009_10_30-transcript) but I'll certainly go along with whatever decision made by the team - I'd just like to have a decision. I'd propose to discuss this for a timeframe of one week as of now and afterwards we vote - sounds sufficient? Thanks, R -- 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
Hello Rupert, Am Donnerstag 05 November 2009 14:41:56 wrote Rupert Horstkötter:
we still need to agree on either Sandboxing or FlaggedRevs as our QA Im voting for Sandbox.
2. Existing content? We need to distinguish between minor and major edits here and define those within the Guidelines. A minor edit covers spelling corrections, add a link as a reference etc. Within the Guidelines we encourge editors to do only minor edits to existing pages. Whenever a major edit needs to be done/is desired, the author requests a working copy of the article in Sandbox where he can work on it. The point with minor/major edit is not easy. AFAIK every User can say in the Editbox if this is an Minor Edit or not. So it is difficult to clarify that.
-- Sincerely yours Sascha Manns openSUSE Member openSUSE Ambassador openSUSE Marketing Team openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://saigkill.wordpress.com ClaimID: http://claimid.com/saigkill -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org
Hello, on Donnerstag, 5. November 2009, Sascha 'saigkill' Manns wrote:
Am Donnerstag 05 November 2009 14:41:56 wrote Rupert Horstkötter:
we still need to agree on either Sandboxing or FlaggedRevs as our QA
Im voting for Sandbox.
I still think that sandboxing an existing article (to do bigger changes in it) will cause some maintenance headache and therefore vote against copying existing articles to sandbox before doing big edits. New articles are a different story - maybe sandboxing could be useful for them until they are complete. Therefore I'm neutral when it comes to sandboxing of _new_ articles (and also on the method of making a new article "official"). IMHO it should be allowed to start an article directly in the main namespace if it is complete from the beginning on.
2. Existing content? We need to distinguish between minor and major edits here and define those within the Guidelines. [...]
The point with minor/major edit is not easy. AFAIK every User can say in the Editbox if this is an Minor Edit or not. So it is difficult to clarify that.
This is the main problem with major/minor edits - you have to trust the users (all of them!) that they really declare their changes correctly. Additionally, lots of minor changes sum up to a major edit ;-) With (only) sandboxing, we might end up with QA for new articles (sandbox), but no working QA for editing existing articles (maybe some people follow Special:Recentchanges, but you never know if a specific change was noted/checked by someone because there is no flag for it). And this is where the FlaggedRevs would be useful IMHO. To sum up my mail: - use FlaggedRevs for QA of existing articles - do NOT use sandboxing for major edits of existing articles - optional: sandbox for new articles Regards, Christian Boltz -- Das einzige Instrument, das ich beherrsche, ist MP3-Player. [Kristian Köhntopp] -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org
On Thursday 05 November 2009 07:41:56 Rupert Horstkötter wrote:
Team,
we still need to agree on either Sandboxing or FlaggedRevs as our QA process for the openSUSE Wiki - I'm the assignee to start this discussion... so, here it is. During our Meeting last Friday, the general concensus was to go for the Sandboxing approach, but I know that there are other opinions as well from parties not joining the Meeting and thus I'd like to give another possibility to discuss the Pros and Cons of both Approaches before we decide which one to implement finally.
To decide which approach is better we have to consider software at hand, which is Mediawiki, that is different from inyoka used by ububtuusers.de, and man power that has to carry on tasks, from wiki preparation for new publishing quality assurance method, to regular maintenance and moderation. We (I for sure) have no idea about inyoka and its properties, but I know much more about Mediawiki. That makes all comments on ubuntuusers.de solutions valid only on content organization, but not on implemented administration methods. What is easy there, can be labor intensive here, and even more, what is possible there, can be impossible here. More about wikies http://moinmo.in/WikiEngineComparison. See row Permissions. Limited.
During our meeting last Friday, we came up with the proposal to get the opportunity to test both approaches in a testing environment to give the Wiki Team an actual idea. Frank, would it be possible to set this up? This isn't urgently needed but would certainly be desired.
Anyway, I will install vanilla Mediawiki and FlaggedRevs, to see what they offer. The http://www.mediawiki.org/wiki/FlaggedRevs has enough details. The most of the work will be to copy enough content, create multiple users and play with configuration. Apropos copy content, that doesn't work well. I can have only current revision.
That said, the intention is to give this discussion another period to evolve, so please, FlaggedRevs supporterrs, jump in and explain.
The flagged reviews offers multiple features that we want trough other extension requests and it is configurable, so it can be win win situation. Christian noted one configuration that would force approved version to appear, as that seemed to be wanted feature, but that is configurable. The variables: $wgFlaggedRevsOverride - Whether flagged revisions override the default revision or simply give a tag notice to the stable version. - The notice is what will satisfy the need to see current revision by forum users, and at the same time any user can select stable revision. - Nobody is forced to anything, but at the same time everybody is notified of status. $wgFlaggedRevsNamespaces - Sets what namespaces to allow for reviewing. - This makes possible to have Sandbox: and FlaggedRevs at the same time, and compare efficiency, labor involved in maintenance, etc. ...
Finally I'd like to close this discussion with an ultimate decision about the QA process we're going to implement - at some point in time we need to go forward and we need an agreement for either approach to cover/explain it within the Guidelines. Just now, the tendency by the team is to go for Sandboxing (checked in the Meeting - see transcript http://en.opensuse.org/Wiki_Team/Meetings/2009_10_30-transcript) but I'll certainly go along with whatever decision made by the team - I'd just like to have a decision.
The vote during meeting was between "something that sounds known" and "something never seen", and the votes reflect that. I know that sandboxing on Mediawiki means a lot of maintenance work, so I look at it as the last resort solution.
I'd propose to discuss this for a timeframe of one week as of now and afterwards we vote - sounds sufficient?
Hopefully, the weekend test of FlaggedRevs will tell, is that actual tool that we look for.
Thanks, R
-- 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
Rajko_m, thanks a lot for your effort to explain this FlaggedRevs Extension and your point of view in more detail - this is much appreciated. Please see my comments below. 2009/11/6 Rajko M. <rmatov101@charter.net>:
On Thursday 05 November 2009 07:41:56 Rupert Horstkötter wrote:
Team,
we still need to agree on either Sandboxing or FlaggedRevs as our QA process for the openSUSE Wiki - I'm the assignee to start this discussion... so, here it is. During our Meeting last Friday, the general concensus was to go for the Sandboxing approach, but I know that there are other opinions as well from parties not joining the Meeting and thus I'd like to give another possibility to discuss the Pros and Cons of both Approaches before we decide which one to implement finally.
To decide which approach is better we have to consider software at hand, which is Mediawiki, that is different from inyoka used by ububtuusers.de, and man power that has to carry on tasks, from wiki preparation for new publishing quality assurance method, to regular maintenance and moderation.
We (I for sure) have no idea about inyoka and its properties, but I know much more about Mediawiki. That makes all comments on ubuntuusers.de solutions valid only on content organization, but not on implemented administration methods. What is easy there, can be labor intensive here, and even more, what is possible there, can be impossible here. . More about wikies http://moinmo.in/WikiEngineComparison. See row Permissions. Limited.
During our meeting last Friday, we came up with the proposal to get the opportunity to test both approaches in a testing environment to give the Wiki Team an actual idea. Frank, would it be possible to set this up? This isn't urgently needed but would certainly be desired.
Anyway, I will install vanilla Mediawiki and FlaggedRevs, to see what they offer. The http://www.mediawiki.org/wiki/FlaggedRevs has enough details. The most of the work will be to copy enough content, create multiple users and play with configuration.
Thanks for taking action here, much appreciated. I'm eagerly waiting for the results. If you'll do this on a publicly accessible server, may you provide access to other Wiki Team Members as well to play with the setup?
Apropos copy content, that doesn't work well. I can have only current revision.
That said, the intention is to give this discussion another period to evolve, so please, FlaggedRevs supporterrs, jump in and explain.
The flagged reviews offers multiple features that we want trough other extension requests and it is configurable, so it can be win win situation. Christian noted one configuration that would force approved version to appear, as that seemed to be wanted feature, but that is configurable.
The variables: $wgFlaggedRevsOverride - Whether flagged revisions override the default revision or simply give a tag notice to the stable version.
- The notice is what will satisfy the need to see current revision by forum users, and at the same time any user can select stable revision. - Nobody is forced to anything, but at the same time everybody is notified of status.
$wgFlaggedRevsNamespaces - Sets what namespaces to allow for reviewing.
- This makes possible to have Sandbox: and FlaggedRevs at the same time, and compare efficiency, labor involved in maintenance, etc.
This all sounds perfectly fine to me and if FlaggedRevs really turns out to be the win win situation we're looking for I'm certainly all for implementing it.
...
Finally I'd like to close this discussion with an ultimate decision about the QA process we're going to implement - at some point in time we need to go forward and we need an agreement for either approach to cover/explain it within the Guidelines. Just now, the tendency by the team is to go for Sandboxing (checked in the Meeting - see transcript http://en.opensuse.org/Wiki_Team/Meetings/2009_10_30-transcript) but I'll certainly go along with whatever decision made by the team - I'd just like to have a decision.
The vote during meeting was between "something that sounds known" and "something never seen", and the votes reflect that.
Absolutely aligned. That's the reason I decided that we'll discuss this for another period of time before we come up with a decision - I myself as the meeting moderator had the bad situation that nobody in favor of FlaggedRevs actually was available in our Meeting last Friday - bad chance. I anyway have to admit that I'm not eligible for having the best understanding about the technical implementation details. There are much more knowledged people within this group (you and others) and I'm perfectly aware of that certainty - I myself try to be helpful in driving the big picture forward and as I said already, it's not at all my desire to implement what I myself (personally) feel appropriate but what actually IS the best approach for our success - just to make this VERY clear.
I know that sandboxing on Mediawiki means a lot of maintenance work, so I look at it as the last resort solution.
I'd propose to discuss this for a timeframe of one week as of now and afterwards we vote - sounds sufficient?
Hopefully, the weekend test of FlaggedRevs will tell, is that actual tool that we look for.
Thanks, R
-- 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
-- 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
On Friday 06 November 2009 08:04:50 Rupert Horstkötter wrote:
I anyway have to admit that I'm not eligible for having the best understanding about the technical implementation details. There are much more knowledged people within this group (you and others)
More others then me :-)
and I'm perfectly aware of that certainty - I myself try to be helpful in driving the big picture forward and as I said already, it's not at all my desire to implement what I myself (personally) feel appropriate but what actually IS the best approach for our success - just to make this VERY clear.
I appreciate your persistence. You don't have to convince me that you are looking for the best solution that you are aware of. I didn't find ubuntuusers.de, you did, so you are looking for solution that will fit the goal, happier openSUSE users. I have no public place to run experiment with wiki, so report will be all that is available. -- 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
Hopefully, the weekend test of FlaggedRevs will tell, is that actual tool that we look for.
I got problem with FalggedRevs installation that is challenge to my modest understanding of wiki software. It worked at first, adding new options to special pages, then I got glitch with file imports and after I interrupted endless upload, I got problem with page presentation. None of the pages will show up, instead I can see debug message that is pretty clear, but I don't see where the function with a problem is stuck. Now I'm removing last traces of extension and I'll try installation again. The other problem was population of the wiki with articles that I picked up from openSUSE wiki. When openSUSE wiki allowed export then my local wiki complained on files size, and it took some time to locate and fix problem on my side. The openSUSE side is probably due to server memory limitations, and I don't think that there is need to change setup, as there is no real need for large exports, and other possible problems that may occur are not very likely to happen. -- 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)
-
Christian Boltz -
Rajko M. -
Rupert Horstkötter -
Sascha 'saigkill' Manns