Preparing my talk about conflict management for the Desktop Summit

This is my favorite place to prepare my talk for the Desktop Summit in Berlin. It is about conflict management in communities and teams. Watch it on Aug. 6th from 12:00 until 12:30, room: Audimax.

Last chance: Vote on openSUSE strategy

The vote on the openSUSE strategy is closing on 30th of june. So official openSUSE members have the opportunity for ONE more day to express their opinion.

Take your chance. It is here: go, read the document one more time and cast your vote!

And if you are not sure if it is important, here you find some hints.



And BTW:

Visiting Randa: The multi sprint

Last Saturday I visited Randa to see my friends working hard on the future of KDE. There were about 60 developers in the house, hacking and discussing everywhere.

Hacking everywhere - The nepomuk and multimedia crowd

Especially for my they did some lightning talks to give my an overview. (I haven't expected less.)

The audience is listening

Sebas was explaining the whys and the hows about plasma active.
Miliam talked about new features of KDevelop like the plasma based dashboard and python language support.
Frederik Gladhorn presented some work about accessibility.
Harald Sitter gave an overview about KDE multimedia covering Phonon, Amarok, Tomahawk kde'n'live and more.
Finally the Fluffy gang reveled there plans to go Flinky.

Also some "work" was done outside.

Platform_11 team at work

Finally Sebas gave us a demo of the plasma active tablet. The usability was not so bad. Even my 3yo daughter could change activities.

My impression during the short time was that a lot of work was done yet and a lot was waiting to be done. I am sad I could not stay longer. But it was a pleasure meeting you all again. See you in Berlin.

Strategy is alive

CC by nc sa mikep @flickr

There was a long pause during the strategy process. Now the strategy team is working on it again. News are coming the next days. Stay tuned.

Contributions that matter

CC-BY-NC-SA by __Dori__ @ flickr

In the last days I read two post on planetkde and planetsuse, written by (to me) new contributors with the best intention to help their projects. However the response of the community was not as positive as they would have expected. What happened?

3 types of potential new contributors

Some lines from my last years Akademy paper.

"Krogh, Spaeth and Lakhani analyzed the characters of potential new contributors in mailing lists.[12] Based on that work three types could be found.

• Proactive problem-solver: They use the program, find a bug, and work out the solution. In the first mail to the list they send the patch. These people are very successful in communities and often become continuous contributors.
• Waiting volunteer: This group offers their abilities to the community and waits until they get a job allocated. In general this character is not very active. Most communities can not integrate them successfully.
• Visionary: They use the program and have ideas on how the program should be improved. Although visions and aims are important in communities, the character-type visionary is not successful. In the past his/her visions were not identical with the ideas of the code developers. The resulting costs of conflicts exceed the benefits of the discussion."

Even the headline of one of the post gives you a hint which type might be behind the post in question. Visionaries often use words like "it should", "you have to" etc. instead of "I have done" or "I am going to do".

Results matter - words do not

In open source communities the developers decide what they do. They want to get work done. In most cases they have a vision for their project and not enough time to do as much as they would like to. That's one of the reasons why achievement is the currency. Talking and writing visions is not. If you want a change - do it.

This does not mean, that your contribution is not appreciated. The contrary is the truth.

Contributions that make a difference

KDE as well as openSUSE have special pages to guide new contributors. They propose your first steps into the project. (You will find other useful information about how to start contributing at openhatch a plattform to bring new contributors and projects together.)

Contributions that make a difference are contributions which are important and valuable from the perspective of the community; things the developers want to get done. Help them and you will succeed. Junior Jobs (JJ) are a good starting point as well.

Start now doing things!

There is really a lot to do. Your contribution is very welcome. Visions are important in communities, but they are not the best point to start with.
Instead, grab a task the community needs to be done. Inform yourself first, invest some time and love. Then contact the mailing list and post your questions or ask for a mentor. Present a solution and be amazed by the positive feedback you might receive.

Good luck!

P.S.: If you have an idea how the program could be improved use the provided tools (the brainstorm section in the KDE forum is the place for your are locking for; more experienced users could open a feature request at bugs.kde.org; openSUSE has openFATE.) or contact the developers on the mailing list.

GSoC idea 3: Store annotations within PDF

As I mentioned in my previous post I can't mentor GSoC students myself and therefore are looking for a developer to jump in for me.

GSoC idea 3: Store annotations in PDF file

Application/component: Okular/Poppler

Brief explanation:

It is possible to store annotations with Okular. They are saved in separat files. One of the most wanted bugs is 151614 (123 comments, 739 votes). It would be awsome to have that feature in our wonderful Okular.

Expected results:

1. Store annotations in the PDF file.
2. If that is not enough apped support to modify the PDF (insert, delete pages etc.)

In my next life I will become a developer and the I could mentor that project myself. Until this happens I am really hoping someone else steps up.

GSoC idea 2: Improved (more elegant) keygeneration in KMail/Kleopatra

As I mentioned in my previous post I can't mentor GSoC students myself and therefore are looking for a developer to jump in for me.

GSoC idea 2: Improved (more elegant) keygeneration in KMail/Kleopatra

Application/component: KDEPIM/KMail and Kleopatra

Brief explanation:
Signing and encrypting emails is very old, however only a minority is using it. One reason might be, that it is not easy enough for regular users to use it. The importance for private and business users is still high. Private companies started to sell proprietary, secure e-mail services (e.g. in Germany DE-Mail and e-brief). There are good key creation, signing and other key management functions present in KDE software. The goal of this proposal is to make it easy and fast to work with signed and encrypted emails.

Expected results:

1. Analyze and optimize the key creation, signing etc processes, make it dumb easy to create and use a key/signature. One way could be to add a button “Generate Key” (next to “Change”) in the KMail – Identity settings – Cryptographie; start the key creation wizard from Kleopatra and take the name and email address from that identity (at the moment you have to enter them manually). The user just has to enter the passphrase and is done. Offer a button “Save private key and revoke key on usb” or something like this and “send public key to server” / “Make key public”. Add the key creation (or import possibilities) into the identity / account creation wizard of KMail. Add the possibility to create revoke keys within the gui (when sending the key to the server, there is an information message yet.) 
2. Guide the user through the whole process of signing and encrypting/decrypting emails. Offer possibilities to learn about the topic in an easy and fast way (offline help, online help / wiki, videos, tutorials etc). Show how they use the keys, how they get their keys signed, how they sign other keys etc. 
3. Integrate other free/open services like CAcert. 

These are just some ideas. If there is someone interested I could go more into details if necessary.