On Tuesday 15 December 2009 07:03:29 Frank Sundermeyer wrote:
Hi Team,
before officially announcing the new wiki instance (wiki.opensuse.org) there are still a few things to do or to clarify.
see http://wiki.opensuse.org/Special:Version for details
PLEASE: Do not start adding content to wiki.o.o, yet. Let's wait until everything is in place (hopefully some time this week). However, you are welcome to test the new wiki - please delete articles once you do not need them. I will delete every remaining article before we officially start. Preferred place for testing should be your user page (I will not delete pages in the USER namespace).
1. Sysop: ---------- I think
Javier Jonathan Rajko Remy Rupert Shayon Sascha Spyhawk (I do not know the real name ;-))
should have sysop rights in the new wiki. Agreed? Have I forgotten someone?
Since you have to have been logged in once, before I can make you sysop, please log in at http://wiki.opensuse.org/ ASAP. Once you have done so, drop me a note including your wiki login name.
In case of problems logging in, please delete all opensuse cookies.
2. Home page: ----------------- Do you want to keep the right column or should I remove it? How should the wiki homepage be named?
We may use "Welcome to openSUSE wiki" as "Welcome to openSUSE.org" is a bit ambitious. Once when wiki was the center point of openSUSE.org current was OK, but now we should limit the scope of welcome message.
3. Namespaces: -------------- ATM we have the same namespaces as on en.o.o (SDB / SDB_Discussion, FAQ, howto). Let me know if you want to keep these and which ones I should add.
*** Talking about namespaces and categorization without discussing information architecture of the openSUSE project, is picking in the dark random pieces that can help information flow, but also can be minor, irrelevant, or directly counter productive. We can use experience of projects of similar size and diversity to name some pieces that they have and we are currently missing, or are mixed with other content. *** "howto" is actually "FAQ Talk" and I would return it to its original name as it acts like that. When one has article in current howto namespace the link above, where usually stands word "Article" in the Main namespace, tells "FAQ", so workaround is not really working as it should. I'm sure that whatever we/someone intended to do with Howto namespace is done without actually understanding purpose of namespaces in the Mediwiki, which is to allow search to be separated from other parts of the wiki, in other words to work faster, and to allow articles with a same name to be used for different purpose. So, in my humble opinion as Main namespace *is* collection of Howtos, with or without special name on it, making another one helps perpetuating confusion where to write, similar to one with SDB. See http://en.opensuse.org/SDB-Howto-FAQ for details. *** IMHO, SDB should be the place that store outdated articles that we don't want to remove. I'm sure that we want to allow users of outdated software access to such articles. The reason for this proposal is: 1) current status of SDB that is actually such storage with very few new articles that can be moved to Main namespace with lesser effort then cleaning up whole SDB from obsolete content and moving that content to some other storage. 2) it can be removed from default search, so that users don't see advices related to SUSE 9.1 and earlier. *** "Portal" is obvious one for miscellaneous portals. The purpose is that information in portal (article names) don't appear in the search as duplicate. *** "Development" could be one name space that is really needed. Developers need wiki for YaST, Packaging, Factory, Standards, Build Service, and what not, but that is stuff that is not for everyone, so removing it from default search can help wiki visitors to find articles that present first line help; something that is from help desks known as level 1 help, while developers can include that in their preference, use Portal:Development and find it easily. *** "Artwork" is not very developed, but such namespace can help to store references to images, marketing stuff and probably more. Kept off default search scope it will help not to present Printer-spool.ico as one of valid results to someone looking how to fix printer problem. Artwork contributor can include it in his preferences, or create entry page for browsing by artwork categories. *** "HCL" is the same thing as the other. User looking for hardware support will have entry page to browse HCL, or add it to search in his preferences, while the rest of the visitors will not see HCL articles in their search results. *** "Community" for social events. *** "News" for all types of news, and specially for Weekly News.
4. FlaggedRevs ------------------
Configuration: Rajko, any hints/input from your side is welcome.
We can go the same way as: http://en.wikibooks.org/wiki/Wikibooks:FlaggedRevs_Extension show settings and decide which to change. We need due to ICS login: 'email' => false, # user must be emailconfirmed? 'uniqueIPAddress' => false, # If $wgPutIPinRC is true, users sharing IPs won't be promoted Although, it is questionable do we need autopromote functionality at all. So, far I can understand what I see on recent changes it is enabled by default in a new Mediawiki version. When we see the new wiki running we can discuss: wgFlaggedRevTabs = false; // add stable/draft revision tabs $wgFlaggedRevComments = true; // can users make comments that will show up below flagged revisions?
CSS: I will try to adapt the CSS to our skin.
The FlaggedRev tools and icons are currently not present, which I can see on my locally installed wiki as it uses the current openSUSE skin. The InputBox is fine as far as I checked it. The rest I had no time to check.
User Rights: Who should have which permissions in FlaggedRevs? Please see http://www.mediawiki.org/wiki/Extension:FlaggedRevs#User_rights
Maybe this is the answer (from Wikibooks settings). // So that administrators/bureaucrats have same permissions as editors by default $wgGroupPermissions['sysop']['review'] = true; $wgGroupPermissions['sysop']['autoreview'] = true; $wgGroupPermissions['sysop']['autoconfirmed'] = true; $wgGroupPermissions['sysop']['patrolmarks'] = true; $wgGroupPermissions['sysop']['autopatrolother'] = true; $wgGroupPermissions['sysop']['unreviewedpages'] = true; $wgGroupPermissions['sysop']['validate'] = true; or, like with autopromote, just manually give appropriate rights. The FlaggedRevs add groups Editor and Reviewer.
5. Lucene Search ---------------- This is the only requested extension that is currently not installed. Adding this would require a considerable change to the server configuration. We have tested the SphinxSearch extension (Sphinx is even faster than Lucene). The only difference I noticed was an increase in speed. The search interface remains the same, and the result list is sorted a bit differently than with the standard wiki search. Apart from that, no changes. Honestly I do not see any benefits using an external search engine rather than performance (and that AFAIK has never been a problem). Whatsmore, the internal wiki search has improved, too, since MediaWiki 1.5.8
Let we try without any external search engine, as there are other methods to improve search like namespace separation, taking care that articles are categorized, build category tree, add portals, and without using them there is no search engine, besides Google, that can help us.
6. Use of Semantic MediaWiki ---------------------------- Has anything been decided on this topic?
It is complex and we will have to read http://semantic-mediawiki.org/wiki/Help:User_manual and experiment with it to be able to give any comment.
7. Everything I missed ---------------------- If there is any other thing you need (configuration option, skin, css) let me know.
Solve cooperation of ICS login and user ban functionality. We have to be able to give feedback to ICS login management to ban and delete users IDs used to spam wiki, and possibly track back to original email address and sent complaint to ISP/mail provider. If not yet (judging by openSUSE namespace): http://www.mediawiki.org/wiki/Manual:$wgCapitalLinks and $wgCapitalLinkOverrides - Per namespace configuration for $wgCapitalLinks if more then tomorrow :) -- 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