Stuart Jarvis

Today is Ada Lovelace Day, a day to celebrate the contributions that women have made – and do make – to the worlds of science and technology. (If you don’t know who Ada Lovelace was then you’re not a real geek – check Wikipedia.)

As a scientist, I inhabit what has been seen as a male-dominated world, but that is changing. Here at NOCS, I joined the PhD program as part of an intake that was around 50% female and that is reflected in other PhD years too and – largely – among the younger postdocs.

KDE does relatively well among free software communities when it comes to attracting female contributors, but that shouldn’t hide the fact that compared to the wider world we still do pretty badly. The issues are likely complex and will take a long time to change, but I’m sure we can all think of a few examples of possible causes. None of the ones I can think of actually came from KDE or its contributors, which is a good sign.

So, female or male, what’s stopping you from joining KDE?

Tags: community, Science

This is possibly a little offtopic for many KDE peeps, but relevant to the stuff I do with KDE. It may be relevant to you if you write articles, announcements, press releases – or even blogs

I spent the last couple of days attending a “results-based writing” course hosted by my university. The main aim was to learn some things about writing concisely for scientific papers and finding a good structure for my thesis, but the lessons are applicable to all many kinds of writing. Writing a thesis takes a lot of endurance and strong writing ability, as you have to keep the reader interested and informed for thousands upon thousands of words encompassing complex topics and formed scientific opinion. While many online education sources do indeed offer some great tips on compiling a good thesis paper, it is best to take a look into face to face courses as well as you can ask questions of the teacher and other students and involve yourself verbally as it plays out.

The training I attended was provided by Cognitrix and was excellent. These are key points that I took away from the course:

• Know your audience
• Identify the concepts and how they link
• Don’t try and hide uncertainty with vague language
• See the opposite point of view
• Cut the waffle
• If you can’t say a sentence in one go then it is too long

They maight seem obvious, but many scientific papers fail on a lot of them. More detail on each follows below.

Know your audience

What jargon can you include? What explanation is necessary? On the Dot I insert hyperlinks to applications, jargon or concepts that I think might not be widely known, but mostly base that on what I understand.

Identify the concepts and how they link

We took a science paper, wrote its concepts out on paper and drew arrows to link them. Those with the most outgoing links are probably good starting points; those with mostly incoming links conclusions. Some items were not linked at all (these were mostly irrelevant and could be removed). Others had few links coming in and needed more background.

Don’t try and hide uncertainty with vague language

I know I’ve tried this in the past when I haven’t quite understood something. Not on the Dot, because there are far too many knowledgeable people reading and I’d get found out If you can’t explain something well then you probably don’t understand it properly yourself.

Try and imagine the opposite point of view

Particularly useful for science. Scrutinize statements like “it is obvious” to see whether they are true. Do you need to provide justification?

Cut the waffle

Some of us (I am guilty) can be a bit verbose. Being brutal with every word, we cut a sentence from 50 to 19 words with no loss of information.

If you can’t say a sentence in one go then it is too long

If you can’t remember at the end of a sentence how it started then the information is hard to take in. A good test is whether you can say the sentence aloud without pausing for breath.

Summary

Applying some of the above, I just cut the length of this post by 21%. I’m going to be trying to apply these lessons not just in my dayjob but also in my work with KDE. So you should read a bit less from me

Tags: background, communicating, Dot, offtopic, promotion, Science

That might seem a bit of a silly question, but it’s one that has kinda come up for discussion a bit recently as we’ve, quite unusually, decided to turn away a few articles about application development and maintenance releases.

Guidelines for application release articles

The result of that discussion is in the advice on the Dot article submission page and set out in the guidelines on the wiki. Since not everyone visits every page on the wiki all the time, here’s the most pertinent part of that guidance:

We cover, as much as possible, all feature releases of anything but very rarely development/maintenance releases except:

• The software compilation (devel and maintenance)
• First new platform ports (devel)
• Really exciting new features (devel)
• Significant new application (devel)
• “Maintenance” releases which DO include new features (e.g. Amarok, sometimes)

Of course, we take many other articles other than application release announcements and the general guidance on the Dot submission page covers them.

Is this a change in policy?

Possibly. In the past this hasn’t really been well defined, resulting in some inconsistency – for example turning down articles about beta releases of an application for which we’ve previously reported beta release. It’s more a case of defining a policy rather than changing an existing one.

Why?

It comes back to the question of who the Dot is for. It really serves two main audiences:

1. Contributors to and users of KDE software
2. The wider tech press (a lot of Dot stories get picked up elsewhere)

Group 1 covers a range from casual users to early adopters, beta testers and developers. Some of these (early adopters to developers) are going to be interested in development releases. However, most of these probably also read the planet and/or the relevant mailing lists.

Group 2 generally don’t report on development or maintenance releases for individual applications (with certain exceptions)

So, group 1 probably don’t need development releases on the Dot to know about them; group 2 probably don’t really care.

Proper maintenance releases without new features should go largely unnoticed by users – so they don’t really need to know about them until they appear as distro updates.

Exceptions

With regard to development releases, there can be more general interest in particular cases. First, the software compilation is bigger news because it is a lot of stuff (and lots of new features). Second, first development ports to Platform 4 are more interesting since some people are really wanting those (e.g. K3B and Kaffeine).

With regard to maintenance releases, the exceptions are when some horrific bug is fixed or, again, the software compilation where there are going to be a lot of bugfixes.

We’re unlikely to want to carry articles where the interesting point is that it is a new development or bugfix release, but where there is an interesting story and the release is incidental (such as in the examples above) then of course it could be interesting to carry it.

Summary

Hopefully that helps explain the new guidelines and putting this on the Planet makes a few more people aware than having it on the Dot submission page or the wiki alone. Comments and questions are welcome and if you’re not sure about an article idea you can always send an email to dot-editors@kde.org asking for our opinion before you spend time writing something.

Tags: background, Dot

If you’re reading this via Google Buzz then this post was brought to you by WordPress, Identi.ca, Twitter and Google. That’s either impressive or horrifying…

Social Media tools suck

On the one hand, it’s kind of nice that interoperation is possible at all, but on the other it’s a silly chain with many unnecessary points of fail. I can use WordPress to blog and that plays quite nicely with Identi.ca – I can syndicate the posts to Identi.ca and likewise list my dents here – things talk to each other. I can also syndicate from Identi.ca to Twitter, but Identi.ca (and therefore I) know nothing about replies at Twitter. From Twitter posts get passed to Google Buzz, but I know nothing about what happens there unless I happen to log in to the GMail web interface. Chances are that there are some people on Twitter wondering why I’ve @replied to them about something they never posted – markey on Twitter != markey on Identi.ca for example.

Identi.ca is made usable and useful by the KDE microblog widget – I simply wouldn’t use it if I had to actually visit the website and log in – that takes longer than the dent. Web interfaces suck. Similarly, I can interact with GMail via KMail (or I could, actually I prefer to have Google forward my mail to another server, a throwback from the days when GMail either didn’t support IMAP or it was a bit funky). GMail’s web interface, while better than other webmails, sucks. Twitter and Buzz, without convenient desktop interfaces that I use already, simply do not get visited by me on even a weekly basis.

In terms of Social Networking, I have Facebook (which I got bullied in to years ago and kinda use, infrequently), LinkedIn (dunno if I’m going to do much with that, another sucky web interface) and Flickr (only for KDE promo). Facebook and Flickr are made more bearable by the excellent digiKam image export tools

Infrastructure for KDE Promo sucks

Similarly, the KDE community wiki sucks – as a collaboration tool (it’s fine for storing info and userbase and techbase are both awesome). I need to discuss things by mail, then open a browser, log in (which requires a round trip to my openid provider if I want the same account on all the wikis). Then I need to remember how to use wiki markup. That’s my excuse for the various things I should have done on the promo wiki and haven’t done. There are things we can do better with the wiki, but the basic problems remain.

Collaborative writing tools suck too. Email is rubbish for actually keeping track of stuff. Google docs is amazing in its way, but it’s another web interface, doesn’t work in Konqueror (or does it nowadays?), is not free and is slow compared to a desktop app. Kobby (and Gobby) also don’t meet our needs – yet…

Really, I want a single “KDE Promo” app that deals with all the above. I’d like a pony too, please You can call it Kommunicator or Kollaborator if you like. The app, not the pony. He’s called Shergar.

There is hope…

Sorry if all that sounds a bit gloomy. There are some good points too The KDE microblog widget rocks. Kopete sorts out my soup of instant messaging accounts, making MSN, Yahoo, Google Talk, and Facebook Chat not suck to the extent that I don’t need to care or even know what network I’m chatting to someone on. Kontact makes my email, calendars and contacts portable thanks to the magic of Kolab PIM data structures.

Ok, the point I’m trying to get to is that all these amazing new social tools we have are limited because they don’t interoperate by open standards, only allow some limited syndication. I want to operate my Identi.ca and Twitter and Buzz accounts as one. I don’t want to have to point Google Buzz at Twitter because they didn’t implement the Identi.ca API yet. I want my Facebook stuff and my Linked in stuff in a single view in Kontact or a Plasma Widget, not in some web browser or web browser widget.

Frank Karlitschek covered some similar ground a bit more coherently in his Camp KDE talk – be sure to check out the other talks too. Together with grappling with the Promo pages on the community wiki and discovering Google Buzz, that’s what has really prompted this post. The new services we’re seeing are exciting and can be useful and Google are helping to remove some of the suck from browser-based apps, but you have to wonder why they fix the browser rather than just using the desktop. ownCloud may have some of the answers, complemented by KDE software (reimplementable by anyone else by using open standards too). Perhaps we can even succeed in, as it were, “freeing the web from the browser”. Only time will tell.

Tags: Camp KDE, community, Free Culture, promotion, rant, suckage, web technology