Bug days in openSUSE

We had quite successful openSUSE Bug Day organized by A. Naumov on Saturday, November 27, and once rolling we continued through Sunday.

The goal was to clear old bugs that refused to die for quite some time.

You can see what is done in the wiki article.

November 28th, evening by US Central Time:

• openSUSE 10.2:  Start 40 bugs now we have 14 bugs left.
• openSUSE 10.3:  Start 162 bugs now is 87 bugs left.
• openSUSE 11.0:  Start 526 bugs now is 346 bugs left. 

We started with 728 bugs and now we have 447, which is 281 bug lesser.

I hope that A. Naumov will repeat call for the next Bug Day right next weekend.

DKMS in openSUSE

AJ requested DKMS which is the good news.

What is not so good are some comments that oppose need for DKMS.


Free and Open Source Software (FOSS) ideals are nice, and very special word in that name is Free, like freedom. Creating obstacles that will limit users ability to use what works for them will not help us, nor FOSS. We can recommend opensource software and install it by default, but we can't make sure that it works for everyone, in which case giving that as the only choice is forcing users to give up on Linux, or go elsewhere. Does that help to build user base?

With alternatives that are not very strict in enforcement of ideals (and ironically, bring few times more new users to the free and open source software), those that are not happy with openSUSE have no trouble to find what they need.

DKMS is solution for only one of obstacles, and there is many more. If we can't offer some stuff for legal reasons, there is no need to create other problems for people that want to run openSUSE.

Gist of openSUSE:Stubborn

Jos Poortvliet wrote:

"Being stubbornly focussed on getting something done is the only bad habbit we allow in openSUSE :D
...  However, being stubbornly annoying about something YOU don't want to work on is frowned upon - as is putting down others on what they do, no matter how useless you think it is.  ..."

Nice said Jos.
It is a gist of openSUSE community.

Aversion to change is normal

Writing answer to a recent mail list discussion it occurred to me that aversion to change is the way to preserve energy. When there is no motion, then there is no need for more energy, so it is intrinsic property of any life form, which explains why it is so omnipresent, and by definition normal (as in usual, or average)  behavior.

The only problem with aversion to change is that it sometimes stands in the way to achieve better efficiency and preserve energy. Someone with better overview of particular process finds procedure that increases efficiency (preserve energy), but we have to put some effort (energy) to learn it. With aversion to change in the action we will resist learning and keep lower efficiency. Good is that this prevents easy change in the opposite direction, to lower efficiency, as at least some of affected will analyze procedure and reject bad one. Bad is that we will use more energy every moment of our life.

Nobody will tell you that he is not for a progress, but everyone will rationalize why the change is not good and should be postponed, or completely avoided. I would put all individual reasons in two categories:

• nitpicking on side effects of a new method, that will be presented as key obstacles that have to be removed before method can be applied, and 
• incompatibility with workarounds for deficiencies in the old one, which will be presented as unacceptable regressions in efficiency, and the reason to reject idea altogether until that is solved.

To be honest, I've seen better method making people slower, but that was either learning phase, attempt to subvert "new thing" in hope it will go away, or combination of both. Also, I've seen bad ideas presented as revolutionary improvements, which was sometimes undetectable without being insider, or simply trying new thing for some time and see what it brings.

Life is like a road, when you see obstacle try to avoid it, but also check another route, and compare results. Use what is better. It is that simple and it is no different with anything else.

Wiki: change postponed

or why we don't do that, it is a FOSS world?

Well, we (contributors) are stretched all over the place, and there is still a lot to do, but keeping wiki hidden on side will not bring more contributors either. New date according to Rupert's post on the opensuse-wiki@opensuse.org mail list is July 12th.

Wiki editing is not a big fun in the beginning, there is more then a few things to learn about to be able to play with, but on the other hand if you don't need fancy formating, then you can start almost instantly. Learn how to start article, then few formatting tips, like mark titles,  and you are good to go.

Title in the MediaWiki is title quoted with equal signs, like == Title ==, add more = and title is smaller.

You also have to know wiki editor requires to write from the beginning of the line. Any (white) space on the begin will convert your writing in a preformatted text  written in a fixed font, so there is no way to indent first line of paragraph without dirty tricks, not even for a single space.

Also, learn to use preview button, it will make you look good in the eyes of the wiki maintenance people that hate recent changes page filled with changes that are not actually changes, but someone that uses save button all the time.

There is of course more, but to correct typo, grammar or spelling, you have to know even lesser. Correcting typos is one of the ways to help, and if you ask me, just as important as being able to create fancy layout, because there is no layout that will make an article with typos look good.

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.

Fighting aversion to change

Today free time spent on http://wiki.opensuse.org trying to create support portal and learning on the run properties of current portal design. Template:Portal that is used as boilerplate for new portals, even generalized as it is, has a great potential, but to use it to its full potential, one has to forget all the tools we used before, like navigational templates based on Template:Navbar. We can use it, but every child template require manual updates, which can be laborious undertaking when number of affected pages grows. Besides its capacity to take links is very limited if we want to have it readable.

We have now CategoryTree MediaWiki extension that can list categories and as soon as someone adds new article to a category, it will be listed. It lists whole category trees in a very compact format that uses screen space efficiently. All that authors and wiki maintainers have to take care is that every article is properly categorized.

Old habits and old tools (that we know) just stand in the way to achieve more with lesser effort.

Amusing when you realize

That ... Aversion to Change applies further then GUIs, and suddenly you see your image in:

... the people who are the most stern advocates of normal users moving away from Windows, trying out alternatives, are the same people who are usually lost whenever they themselves have to change their way of doing things.

or in other words "Me and the new openSUSE wiki development".

You can see preview on temporary development copy of the wiki at http://wiki.opensuse.org . It will be switched with http://en.opensuse.org later this year, so if you link to it, please make sure that your visitors are aware that fact .