Mailinglist Archive: opensuse-wiki (174 mails)

< Previous Next >
Re: [opensuse-wiki] New wiki host: Final preparations
  • From: "Rajko M." <rmatov101@xxxxxxxxxxx>
  • Date: Tue, 15 Dec 2009 22:36:15 -0600
  • Message-id: <200912152236.15624.rmatov101@xxxxxxxxxxx>
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-wiki+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups
References