Wiki structure: New tools

or basic inventory of what we have.

Temporary openSUSE Wiki is created few moths ago to allow test of new tools and content reorganization  without disrupting daily operation of openSUSE Wiki. It is running on MediaWiki version 1.15.1. The basic software is already much better then the old version 1.5, but the goal is not only to have one time cleanup, but also to organize wiki that will provide benefits for all involved parties: visitors, writers and maintainers. To achieve this we added few extensions to the basic MediaWiki listed here .

Semantic MediaWiki  is complex extension that has its own extensions.It can become one of our flagships, but at the time of this post I don't know much about it.

We already have working implementations of the following extensions:

CategoryTree is navigational tool, intended to provide compact list of other pages that user might want to visit. It is based on MediaWiki categories , which means that creation and maintenance of categories and its structure, is one of the primary tasks for all involved.

FlaggedRevs will allow better content quality control. It is set to show casual visitors only article revisions that passed quality control process. Editing is not prevented, so anyone can change page content, but that is hidden from visitors until some of reviewers check the article.

MultiBoilerplate is meant for simplified creation of articles, providing ready to go templates for different types of articles that wiki user can choose from drop down list.  The openSUSE version is patched to allow different sets of templates for different namespaces.

InputBox provides 3 functions:

• Different modes search boxes, 
• Creation of pages using predefined templates, which overlaps in functionality with MultiBoilerplate to some extent, but allows article writer tight control over used template.
• Adding comments to existing pages which can be used, for instance, to simplify collection of user comments, user contributed tips, simplify contribution to hardware compatibility list.

DynamicPageList is navigational tool that lists selected content of one or more categories. It overlaps with CategoryTree when it shows content of a single category.

ParserFunctions  allow some kind of macro language to be used in templates.


SimpleFeed  is used to import feeds from other pages to the wiki. It was used in old wiki for the right column news.It can be used to import news to any of the portal pages.

VideoFlash is simple extension that allows author to embed YouTube and other Flash videos in the wiki pages.

SyntaxHighlight will make easier reading of the code snippets on the wiki page.

Tools for users and administrators:

SpecialInterwiki   is a tool for wiki administrators.

Hermes Notify is our notification agent.

Wiki:Structure

Attempt to create structure in the wiki, or to classify all articles, is next logical step after years of, to be modest, disharmony in the current wiki, but how far we should go and what content can be structured with reasonable amount of work, and what should be left to self organization.

Article Ontology is Overrated: Categories, Links, and Tags talks among other things about application domain of ontology.

Now applied to our wiki, we have:

1. mix of both stable well defined categories and new topics that are in flux,
2. relatively restricted domain - Linux and openSUSE, but we go into a lot of details there,
3. mix of topics that cross boundaries of disciplines, 
4. participants are more or less not experienced,
5. there is a limited number of people interested in the work on the wiki, specially to spend time learning how it works 

To me it seems that we are a bit more on "let it organize itself", which will mean make basic structure and rules for maintenance crew, so that copy-editors can straighten out stray articles on important topics without author complains, and don't be to much upset when the rest lives its own life.

Support burnout

or yet another way to shoot yourself in the foot.

Supporting people with problems too long creates support burnout. Those that suffer from it can't find that by themselves, and even resist to accept facts when confronted. It manifests in to much attention to details that should provide better support, but actually stand in a way for the primary goal of any support effort, a happy user.

Today I had one more touch with that.
One of people that supports open-slx version of openSUSE wanted to add Support Database (SDB) to the new wiki Main page and he did it. I objected, but did nothing to remove the entry. First it is visible only in a draft page (our wiki is using FlaggedRevs, a MediaWiki extension), so normal visitors will not see it, and second I want to  discuss this on the wiki mail list.

Why giving so prominent place to Support Database is bad?

SDB has many articles from those that solve problems with openSUSE, to few that explain how to use Linux for daily tasks. What will be opinion of a new user that just installed Linux thing and has no required background knowledge to explain large disproportion between articles about problems vs. advices how to do regular daily tasks using new applications and functionality. I know that I would not feel comfortable with software that has many problems and few useful functions, and I have no reason to think that that majority will have different opinion.

Ditto, SDB should be easy to find, but giving people with problems few other options before they start digging trough it, like it was done in Support article. I must admit that now reading article again, I can see my support burnout in the tone of the article and the fact that SDB link was first in the section "Non interactive", before Spyhawk (Remy) added documentation  link as a first and saved the day.

In my opinion, we (openSUSE) have to keep advices about daily tasks and problem solutions for irregularities separated as much as it is possible in the visitor eyes, which fits fine with current description in Help:Namespaces :

• Main - Presentation of the current version of the openSUSE distribution. Everything for consumers of our distribution.
• SDB - Help, Howtos, support. If you have a problem with the distribution you will find help here.

What can be better presentation of your new operating system then articles that will explain how you can do all that you did before and of course much more. 

Wiki: Background

One particular article that is correlating to my experience working on openSUSE wiki is Ontology is Overrated: Categories, Links, and Tags or in short "how chaos is organizing itself".

In other words, we did not enough to organize our chaos and we have wiki that we made, and deserve. Are we, openSUSE users only to blame?

IMO, yes and no.

Users of openSUSE are not well aware of FOSS concepts, which include a lot of own involvement in creation and maintenance of distribution. There is no such thing as a free beer, you pay with currency or with own work.

Some 5 years after start of openSUSE, users reporting bugs is the major group that is contributing to SUSE. There is no many community members outside the SUSE GmbH that are software developers, packagers, document writers, translators, graphic artist, and many other specialists that can make complex product like software distribution.When I say not many I have in mind that as of today we have almost 12000 registered users, 4600 of them agree on Guiding Principles, but only 395 are members. The members are those that make significant contributions. For distro that offers thousands packages of software titles that is way to small.

The other party to blame is Novell and SUSE, that pursing own interest limited to have community as testers for new Linux related technologies did underestimated value of healthy community behind and all services that such community can provide. Until recent creation of Boosters, there was no organized effort to change nature of openSUSE community from consumers of free software to contributors in many more areas then bug reporting and packaging.

Ubuntu rise is not accidental. Mr. Shuttleworth based his project on relatively small company that complemented existing Debian distribution with final, user friendly, touch up. The other  services that one distribution provides to end users like packaging and security audits are, so far I know, done by Debian, and that is a lot more work as it multiplies with number of software titles that one wants to provide in a distribution.

Expanding use of portal page concept

The openSUSE wiki Portals have few sections that are included from subpages.

For instance introductory section of Portal:Wiki is actually on a subpage Portal:Wiki/Intro and it is used in article itself, but also in the Main page, just as  Project and Distribution portals intro pages.

Using subpages in the similar way are created other sections of any Portal page. Nice about this is that nothing prevents to use parts of portals anywhere we need them.

What if we can expand this concept to many more types of articles?

We gain ability to use parts of articles in any area; not only to link, but to reuse text. For instance, when we create list of used software to solve some problem then transclusion of intro pages in the list will tell reader, not only what is used, but also short introduction to software.

A bit expanded concept would keep current Template:Infobox on a subpage. That will make possible to list it in the right column of another article. Reader that has to install some software in order to perform task described in the article will have all information at hand that will assist him in installation.

Often used descriptions for procedures like "switch to root", or "switch runlevel" can be collected as subpages to one page for related actions and then just reused everywhere in the wiki. This will end tens of similar descriptions for those two all over the wiki.

How to make authors and copy editors aware of that?

It is relatively simple. Make them aware of option to use templates offered by MultiBoilerplate MediaWiki extension, and give them templates with example articles.

PS.

The openSUSE wiki version of MultiBoilerplate extension is improved by C. Boltz with ability to have different templates for different namespaces, so we have ability to be selective, depends on type of content that is offered.