KDE prides itself as being a community.  Is that justified?  I have seen good, hard-working people driven away from projects because they were receiving behaviour from other members of our community that they would not accept from general users.  The Code of Conduct, it seems, is for others, not for ourselves.  We have a number of people in our community that regularly use aggressive behaviour, attacking the work of others without even bothering to ask why their particular dislike was implemented.  What’s worse, they are often very respected members of the community, for the work they do – but why are they allowed to behave like this?  The CWG (and I include myself here, as I was part of it for quite a long time) have done nothing about it – because generally they don’t interfere unless there are complaints from the victim.  “We can’t offend such a valuable contributor!”  So we allow things to continue.  When a victim simply disappears from the scene, so does the problem – until next time.

It’s time for some serious questions.  What should we be doing when one respected member of the community attacks others?  I’m not talking about words spoken in the heat of the moment, then retracted, but of repeated attacks, apparently designed to make the victims feel worthless.  Often the perpetrator has treated several people in the same way.  We are, or can be, better than this.

Why do we have a Development category on UserBase, when we said quite clearly, many times, that UserBase is for users, not for developers?  The answer is quite simple – developers were once users, and some, a few, users will become developers.  We don’t aim to have any how-to-develop information on UserBase, but it seems to me that it is only sensible to have brief information about the tools that are available and where to find information and support for them.  Unfortunately, I don’t use those tools, and I’m finding it very hard to get up-to-date information about the status of some of the tools.

The Development page has several gaps:

• KBugbuster
• KFileReplace
• Kommander
• KImageMapEditor
• KLinkStatus
• KXSLDbg

How can you help?  In a number of ways.  If you use one or more of these you could

• Write a page about it – ideally in Mediawiki markup, but plain text together with screenshots would be a great help.  We have a new scratchpad area,
• Use the app’s Talk page to give me links to decent material, both for the use of the app
• and for any related Techbase pages
• We have a new scratchpad area called Draft where you can start any outline for such information.

A few minutes of your time could help new developers get started, and who knows?  You may find yourself welcoming one of those into your project.

Less than three weeks ago, at the WebWorld2011 sprint, we decided that we should open editing to all, no longer requiring registration.  During that time there has been an increase of spam, but we had a few genuine edits from people who were not logged in, and on that basis we decided that we would simply deal with the spam and keep editing open.  Yuri Chornoivan has taken the brunt of it, because much of it arrives during the night in my time-zone.  Last night, though, the situation took a turn for the worse.

Previous to that, we were getting registrations that posted pages with external links.  They were a nuisance, but easily spotted, and in numbers we could handle.  The last 24 hours has brought a threefold increase, and of a very different kind.  These are all from unregistered users, and consist of content of existing pages being deleted and inanities inserted.  This moves into an entirely different league, and is intolerable.  I have therefore requested that the sysadmins close editing again.

To those of you who used unregistered editing to add useful information, I thank you, and hope you will continue to add your wisdom.  Registering is still a fairly open process.  You do not have to wait for a confirmation email, or even to give an email address, though we do recommend that you do, as there are advantages such as allowing us to re-set your password if needed.  (Your email address is not visible to other users, at any point.)

I’m sad that we have to take this step, but if any of you read Mediawiki mailing lists you will be aware that many wikis are suffering similarly.  I would like to think that we could open editing again at some future time.

You start to write about your application –

OK, you will need a front page and a couple of sub-pages – that doesn’t sound so bad, does it?  Many people have done just this on UserBase.  Some write directly onto new pages, some are happier to draft their work first, so use sub-pages of their User-space pages, and that works fine.  With our without the help of the UserBase Admins, the content can then be pasted into the correct tree structure and the draft removed – and everyone’s happy.  But what if you want to write a whole manual?

As the Amarok team have discovered, it’s a whole new ball-game.  You start with a Contents page, listing all the pages you think you’ll need, and you start to build.  Before you finish I’ll guarantee that you’ve thought of something that would have been better on a page of its own.  As it happens, that’s not a big problem – you can edit the contents page and create a new page that way.  But wait – what seemed good organisation to start with is less convincing now, and maybe it would be better to move things around, re-organise a little.  Hmm – not so bad!  There’s a little icon for Move – ah yes, it moves the page to the structure you want and even leaves a re-direct behind, in case someone uses the old link.

Sounds pretty good, doesn’t it?  Unfortunately this is where it starts to come unstuck.  Once you’ve finished, the Translators move in – and where should their links point?  If they translate from the original they probably will use the original link, which is now a re-direct.  That’s not good.  We have to clean up re-directs, in that case, and that’s when we find that moved pages have been moved yet again, causing double-redirects – an even bigger job for cleaning up.  You see, we can’t just delete them – there could be a number of pages that link to the old page, so we have to track all links, and in the case of the double-redirect we have to do that for both levels of old pages.  It can be quite difficult to follow, but it’s a necessary part.  Happily we have almost finished the double-redirects – heaven preserve us from triple-redirects!

“So you said I could make it easy for myself?”

We think so.  It’s experimental, yes, but it should help anyone starting new documentation.  Most of what you see on UserBase is in the “Main” namespace, but today we have opened up a new namespace called “Draft”.  You can start your documentation there without worrying about the issues I’ve just talked about.  Move things around as much as you like – just remember that in the end any page links will need sorting!

The idea is that when the pages are ready we can simply move the whole structure into the Main namespace if any redirects have been dealt with, but if it has proved more complex and things have been moved around a lot we can use Copy/Paste to create the Main pages from the Draft ones, fixing links as we go and losing all the redirects on the way.

One last thing – you have to be the main writer for your documentation, and you are used to an entirely different kind of mark-up, finding that attempting Mediawiki mark-up gets you utterly confused.  We can handle that too – and again the Draft namespace is the best place to do it.  Put your plain text there.  Add any markup that will be obvious to us, for instance <bullets>,  and we will help you get it looking the way you want.

Using Draft  should remove a good deal of anxiety and hassle, but we need you to try it out.  Take a look at Draft and let us know what you need to make it even better for you to draft your documentaion.  See you there!

There is a strange sort of time-warp.  We can’t remember which day it is, yet the week is disappearing fast.  Most of the time I’ve been working with a group on UserBase issues.  Matthias (Pipesmoker) Meßmer has been on-call to fix many theming or display issues that we identified, while Niklas (Nikerabbit) Laxström, our wonderful Translate extension author, has added new features for our delight.

In the past, we used “Special:myLanguage” markup to help “other-language-speakers” to get the correct language page, but when you were working on a page, adding a link with that markup did not show the essential red-link that warns you that the page is not yet created.  Now it does show a red-link, which makes life so much easier for all contributors.

Another “big deal” for us was that there were times when it was decided that a page had been poorly named, or wrongly inserted into the page structure.  Because some of our translators are so diligent, we acquired translations of the page almost immediately, and before the problem was realised.   Once a page had translations added it was not possible to move it.  Now, thanks to yet another of Niklas’ efforts, a page together with all its translations can be moved to a new location.

You may remember that Claus Christensen is our Danish translator for UserBase.  He and I have worked mainly on improving accessibility.  Over the lifetime of UserBase we have added a great deal of help for users and contributors, yet people have found it difficult to find the exact function they needed.  We decided that extra sidebar links were necessary.  Again, Matthias and Niklas had to help the more arcane needs, but finding your way around should be very much easier.

Previously we have thought that it is not necessary to translate help pages, on the grounds that in order to translate you have to have a good grasp of English.  Recently, though, Zhao Han pointed out to me that for people who use other-script languages it can be helpful to see translations of help pages, so we worked on that too.

Lots of small changes have happened too, mostly the sort that you don’t notice when they are right, but you would have seen when they were not so good.

Finally, Hans (Mogger) Chen decided that UserBase needed its own strong logo.  He designed a possible logo, then took it to Eugene (it-s) Trounev, who assessed the practicalities and started on “the real design”.  So – watch out for that before the end of the week.

Oddly enough, even through all the long days of activity, we still have managed to have fun.  Eugene’s prowess in the kitchen is now known, and I’m sure he’ll be in much demand in the future too.  I’ve never tried handling food on a swinging barbecue before – and probably won’t again!  You need more hands than an octopus to hold everything steady.  We’ve had wonderful warm, sunny weather, so whenever the head needed clearing we’ve sat outside and discussed things, but we’ve been careful, because the first day some of us were sunburned before we realised what was happening.

I’m so impressed with the amount of work we’ve managed in the time, and will be pushing for a repeat sprint to bring the next set of improvements.