New Year is traditionally the time when people re-assess their priorities, and all too often have to make decisions that may not be too comfortable.  So it is with CWG members.  Jucato (Juan Carlos de Torres) has struggled for some time to keep up with his commitments, and has finally and reluctantly decided that he must leave the CWG.  Martin Fitzpatrick (mfitzp), too, has found it progressively more difficult to reconcile the demands on his time, and has also decided that he must step down.  We thank both of them for the time they have given, and wish them both every success in their undertakings.  In their place we have two new members, Ingo Malchow and Jeff Mitchell.

Ingo is best known for his involvement in forum.kde.org, but is now heavily involved in all matters kde-www. The up-coming new websites have been taking much of his time recently, and he is also committed to helping advance significant improvements to userbase.kde.org.  Jeff, on the other hand, has most recently been visible in organizing Camp-KDE, where many of you will meet him in a few days’ time.  He is also deeply involved in many aspects of Amarok development and promotion.  Ingo and Jeff are both known to be good, sensitive, discrete listeners – an attribute that we consider to be absolutely essential.  Lydia, Richard and I, the remaining CWG members, are confident that they will be valuable members of the team.

I’ll end by reminding you of our contact details.  Emails can be sent to community-wg@kde.org, and messages to individual members of the CWG are acceptable.  If you use IRC, it could be useful to include your nick in the message, so that we can catch you on-line if necessary.

The Charter of the CWG is at http://ev.kde.org/workinggroups/cwg.php and the Code of Conduct can be found at http://www.kde.org/code-of-conduct

A wiki is supposed to be an easy place for all to contribute to documentation, but when we held an IRC meeting about UserBase, back in October, it was clear that not everyone found the wikis welcoming or comfortable.  We’ve started several initiatives to solve, or at least alleviate, some of the problems.

Getting Started

First, we have made sure that ‘Help’ in the navigation panel  points to http://userbase.kde.org/Help:Contents – where general guidance is found.  Then, right at the bottom of the page is a Category link.  Clicking on that takes you to a page that lists other pages that you might find helpful – some to help you quickly find what you need, and others to help you get started contributing.  At the moment the English pages are, I believe, fully represented.  Currently you will see some translated pages listed there, but work is in hand to improve this, giving languages their own Category links.  Watch this space!

Getting Help

So – you’ve found your way around a bit, and know roughly what you want to say, but you’re still finding the whole thing a bit daunting.  Well, the first thing is to remember that you are not working in a vacuum.  Sign on to #kde-www on irc.freenode.org and there will always be someone around to help.  Even better – starting next weekend we have a Klassroom course on contributing to UserBase.  Sign on at http://forum.kde.org/viewtopic.php?f=4&t=84864.

Tell me about the course?

The aim is quite simple – to make you familiar and comfortable with the tools of mediawiki editing and the layout of a typical UserBase page.  This course is for you if

• You are a user without development skills and want to make your contribution by helping others to enjoy KDE software
• An application that you use frequently has little, or outdated, documentation on userbase, and you know you could help people get more out of it.
• You are a developer, and your application is under-represented, or not represented on UserBase.
• You are a developer and have documentation elsewhere but want an easier place to work with it.

You will work on a UserBase page, asking questions on a dedicated forum thread.  You will see questions asked and answers received by other students.  You will do the work at times when it suits you.  Help pages have been prepared to give you all the tools you are likely to need.  In fact, the aim is to make it as un-threatening as possible.

Sign up

This week is sign-up time.  We look forward to seeing you on http://forum.kde.org/viewtopic.php?f=4&t=84864 or come along to #kde-www to ask questions.

Happy Christmas, everyone.  Time enough for work in a few days

A quick note to tell of a small but important change.  We have occasionally met some administrative difficulties on our wikis.  Nothing out of the way, if only we had been able to contact the contributors.  However, the problems arose because the contributor was not logged in.  We have no way of talking to him/her.  In view of this the deicision has been taken to require login before any edit can be done.  On UserBase alone we now have 1074 registered users, so clearly registering is an acceptable process, and it will certainly make life much easier for our various maintainers.  The change will affect each of our wikis, starting over the next few days.

I’ve quite a bit to report on progress and planned changes, so more about that in a day or two.

subtitle: Is UserBase selling you short?

If you follow my blogs you’ll know that one of my preoccupations in UserBase is with navigation.  More than once I’ve seen a mailing list message that UserBase contains no information about a particular problem, whereon I’ve had to reply with a link to the information.  The search facility built in to the wiki is not good, and we have plans to do something about that, but that alone isn’t enough.

When I first saw Dolphin I fell in love with Breadcrumb Navigation, and I have wanted something like that for UserBase ever since.  I began manually adding breadcrumbs, but stopped when it was pointed out that scalability was a big problem.  We now have over 1000 pages.  It just isn’t a solution on that scale.  Now we are looking at possible mediawiki extensions to deal with the problem.  There are several, and at the moment we have not made the decision as to which best suits our purpose.  However, most of them do rely on pages being allocated to Categories, so for the last week I have concentrated on getting those categories working.  I’m mopping up the last few English pages now, and when I’ve discussed with our active translators I’ll help them get the translated pages categorized as well.  That’s the good news part.

While I’ve been doing this, I’ve had an enormous shock.  I found pages that I had forgotten existed.  Worse, everyone else seems to have forgotten them too.   Once we get our navigation improved all those are going to be so much more visible – and you will not be happy with the result.  I really need your help.  I need you to look for the page for your application, then also use the Category link at the bottom of the page to check for related pages.  I need you to check for these things -

• Are the screenshots horribly out of date?
• Is a revision, either of the application or required SC version, mentioned and is it up to date?
• Are there links to related UserBase pages that are no longer relevant?
• If there are links to external project pages, are those links still correct?

Then there are at least two applications that have compile instructions on UserBase.  From the start we agreed that those are not for the average user.  After consulting the developer mailing list it was agreed that the UserBase page should carry a link to a page under http://techbase.kde.org/Projects, and the compile instructions moved there.

We have so many plans to improve UserBase over the coming months.  It would be a pity if that improvement caused embarrassment by exposing such problems, so please take a good look at your pages.  You are always welcome to contact me by email, or to catch me on #kde-www.

The third and final part of my wanderings today concerns the development of our wikis.  I told you last time that the forum team have set up a sandbox wiki for us, and a good deal of work has come out of that during that past two weeks. A special thanks is due to neverendingo, who has done so much work for us.

When we started this I had not realised that the reason our wikis are consistent in looks is because they share the same skin.  Even when I first heard that, I didn’t entirely realise the consequences of this.  Basically, apart from content itself, anything that is done to one of the wikis will also affect the others.  The downside of this is that we really should have agreement among all the wiki maintainers before things get changed, and that really means that we need to be exchanging views far more often.  #kde-www is the easiest place for this to happen.  The upside,though, is huge.  As long as we can get those communication channels working, it means that any and every issue we can identify and fix on our sandbox can be used to the benefit of all our wikis, giving noticeable improvements to them all for minimal effort.

One issue that we have looked at concerns the Recent Changes RSS feed, which has been broken since our Mediawiki installation was upgraded to 1.14.0.  I had hoped that upgrading to 1.15 would fix it – but it doesn’t.  We have 1.16alpha installed on our sandbox – the version that is due to be release in the next few weeks (and it is remarkably stable, as far as our limited use can tell) – but that doesn’t fix it either.  From reading posts in the archives of the Mediawiki mailing list it seems that the decision-makes at Mediawiki don’t think it’s worth putting time and effort into fixing RSS when Atom feeds are totally reliable, and, they say, more powerful.  I have been watching voth RSS and Atom feeds for both UserBase and Userbase-testing for a while now, and I have to say that the Atom feeds are great.  That begs the question, though, of whether RSS feeds should be offered on our wiki pages.  Because they are so well known, not to offer them might seem very strange.  However, offering something that is known to be really badly broken is embarrassing.

The other issue that has been taking our time is that of developing systems to help with translations.  We are getting a great deal of help from the two developers of the translation extension, which naturally feeds back to improve the extension for everyone else.

As we have talked to translators it has become clear that we are not going to get a one-size-fits-all solution, so we are looking at a two-pronged attack.  The main, and intended, usage of the extension is to do it on-line.  The source is marked up as translatable, and from then on changes are tracked so that the translators can see what needs updating.  It’s a new way of working, so there is a small learning curve, and there are still a few wrinkles to iron out, but it’s looking very promising indeed.

For those who prefer to work with familiar tools, the extension does allow export and import of .po files.  Again, there are wrinkles, but the main system is actually working now.  This system is also one that would be useful for creating docbook files.  There is a downside, though, to using this method for translations.  What if we have more than one translator for a language, and one starts to work on it on-line but the other has downloaded it for off-line translating?

Apart from the RSS issue, I don’t think we’ve found anything so far that can’t be fixed, one way or another.  If you have any involvement with our wiki sites, please do join us on #kde-www whenever you can, to be part of the development.  I have high hopes that we can make a huge contribution to the wikis.

Reading my newest Linux Format I was delighted to hear that there is a project in Sheffield, South Yorkshire, that uses donated/recycled computers.  I live in West Yorkshire, but in the south-west corner, so Sheffield is a mere 40 minutes drive away.  Naturally I followed this up – an opportunity too good to miss.  If you live in the mid- to north of England, take a look at http://www.access-space.org/?c=recycling

I was curious to know more about the activities of Access Space – and amazed and delighted at what I saw there.  The most surprising thing was http://www.open-source-embroidery.org.uk/ !  The Html Patchwork, no less.  Every cell of the patchwork represents the hexadecimal colours, and every contributor gets web space to tell about their work and activities.  The resulting patchwork was displayed in Sweden this summer, but if you live in or near San Francisco you can see it during October to next January, at the Museum of Craft and Folk Art.

Then there’s LOSS – The Linux Open Source Sound project.  Electronica is not my kind of music, but I did sample a few tracks – they appear to all be Creative Commons licensed.  For a smile you really should listen to the Jake Harries -Eh? track.  The CD was recorded in 2006, but I did notice that at least one upload was in 2009, so presumably the project is still active.

Part III – coming shortly – has news about developments related to UserBase in particular and our wikis in general.

Two weeks since I last wrote, and so much has happened that this feels a bit like a scatter-gun approach, to tell about everything.  Anyway, let’s start by looking at UserBase’s current statistics.

We now have 935 pages of content (how soon can we make it 1000?), disregarding the discussion pages, which have attracted 1,806,159 views!  A tremendous number.  Our registered member number has gone up too, to 819.  Still only a small proportion of members actively contribute, but that is noticeably more than it was a few months ago.

These are the top-10 contribution statistics for the past seven days (yes, eleven again):

Once more our translators account for a large number of edits, but it’s good to see some new names among the content providers as well, and the list can’t include the names of people who send content to me and ask me to add it.

When I look at the Popular Pages statistics, I am somewhat surprised at what I find, though.

Most viewed pages:

The kde-pim applications clearly are heavy attractors.  Although I expected that to some extent, I expected to see more emphasis on some of the other categories, such as Internet, or Multimedia.

I mentioned in my last blog that #userbase was soon to become #kde-userbase.  Well, all that has changed.  Let me tell you the developments that changed it.

The forum team kindly set up a sandbox mediawiki so that I could explore the possibilities and test extensions.  It wasn’t long before we realised that several things that concerned us regarding UserBase did in fact affect TechBase and Community wikis as well.  That makes a nonsense of keeping our conversations separate.  There may of course be smaller issues that we want to discuss separately, but that’s no big issue.  The only sensible thing to do is to keep our main discussions about the wiki in a place where the other wiki folk can join in if they think it useful.  In view of that we are changing our channel, not to #kde-userbase, but to #kde-www, and it will happen this evening (28th October).  A re-direct will exist for a few weeks, in case people follow the link from the old blog, but I hope that everyone concerned with the wikis will join us there.

Let me start with a few relevant facts about my life.  As some of you will know, I spend 60-70 hours every week helping with mailing lists, forums and userbase.  It is a huge part of my life.  However, in a few weeks’ time I will be 70, and I have a serious heart condition.  I may be here for a few years yet, or I may be gone tomorrow.  And what will be my legacy to KDE?  At the moment it’s a handful (albeit a big handful) of wiki pages.  That’s not what I want my legacy to be.

I have a dream for that, and it’s realisable.  I want to leave a system that will spell an end to ancient documentation.  A system that is easy to use and light on time required to maintain it.  A pipe-dream?  No, I don’t think it is.  Several people have said that drafting documentation on a wiki is much easier than working directly to docbook, but getting the parts to talk to each other really makes it difficult.  I’ve talked to Albert Astals Cid about what would help language translation, and I’ve talked to Burkhard Lück about what the docbook team need, and I do believe we could get a usable system, and without much delay.  Here’s what I propose:

Stage 1 – the system is triggered by changes to userbase pages.  It first addresses language needs.
Question: is it possible to create RSS feeds for certain groups of pages?
Problem:  currently the Recent Changes RSS feed is broken, sending multiple copies of alerts.  That would have to be fixed first.

Stage 2 – A mediawiki extension outputs a .po syntax file for the changed page.  I         understand that http://www.mediawiki.org/wiki/Extension:Translate would do that.  Reading through the page, it looks as though a set of tools already exist that implement export and import.

Stage 3 – the exported .po file arrives in SVN, where the system follows normal development lines.  It may save translators considerable time if a diff of the last two versions is sent as well.  This information is readily available through the History pages.

Stage 4 – the mediawiki tool poimport.php is used to import the returned .po file into userbase.

Stage 5 – starts the docbook cycle.  The mediawiki extension http://www.mediawiki.org/wiki/Extension:XML_Bridge creates docbook XML from mediawiki pages.  The proposal page http://www.mediawiki.org/wiki/DocBook_XML_export explains how it works.  The resulting output could be made available through docs.kde.org, on distribution disks, and on userbase.

If scripting is needed to make these stages flow, Sayak Banerjee, of forum fame, has agreed to write the scripts for us.  Many thanks to Albert, Burkhard and Sayak for working with me on this.

So – where does that leave us?  Well, before extensions can be added they have to be tested.  For me to do that I need Mediawiki setting up locally, and for that I need a LAMP stack.  None of this is familiar to me, and I’d be working alone, without any form of help.  I could do it, but in a reasonable time-frame?  I doubt that.  So what are the options?  I’m assured that the system would be an enormous time-saver for the i18n and docs teams, so what is the best way forward from here?  Is it possible, for instance, that I could have access to a LAMP stack somewhere else, to be used as a sandbox?  I need all the help and ideas I can get.