New Thing: Kubuntu Documentation

For about a year I've been intending to contribute to Kubuntu Documentation, beyond the occasional update or correction of the wiki -- not that that isn't important too! But the docs which are distributed (accessed through the Help menu or F1) with all of our applications are the basic way we interact with our users all over the world. As the applications change and our settings, and suite of applications change over time, the documentation needs to be kept both current and correct. This is the role of the Documentation team. Once we're done, the docs are turned over to the Translation team, who are heroes!

Since David Wonderly (DarkwingDuck in IRC) took the leadership of the team, he's created a nice guide to contribution, at https://wiki.kubuntu.org/Kubuntu/Documentation. As I discovered during crunch time, it wasn't perfect - by the time you consult it, it will be, I'm sure!

One thing which was not stressed to me, and turned out to be important, was pulling to keep the update current. If you are working in a team, it's important to do this step frequently so that you are working on current copies of the documents.

David has documented the steps well, so I don't need to go through them here, but as in any technical process, it's important to set up your process and follow that faithfully. So always update before uploading (pushing), always fix conflicts first, and so forth.

Also, communication is important. We use a Whiteboard on Launchpad, and I discovered that I wasn't saving after claiming work items. There is no SAVE button -- just a green checkmark. Use the green checkmark! And talk to people in IRC about your intentions as well. Stepping on someone's work makes two unhappy people, and wasted worktime as well.

To sum up, getting started in Kubuntu/Ubuntu documentation involves some technical steps, such as setting up Bazaar and your SSH key, getting the Repository branch(es) you'll be working with, and keeping them up-to-date. However, they are clearly described, and help or hand-holding is available on IRC. Just follow the steps as described, and you'll have success, as I did.

The documents themselves are edited in a text editor (I use Kate, naturally), saved as usual, then committed locally, and finally pushed to Launchpad. Once uploaded, they can be checked by one of the developers and committed on Launchpad. Once you have pushed, remember to update your status on the Whiteboard, and mention it on IRC as well, if you are working in a team. #kubuntu-devel for Kubuntu, and #ubuntu-doc for everybody.

Finally, thanks for contributing to documentation! Your fellow users thank you.

Are you a Listowner? Try listadmin CLI tool

I don't consider myself a very techie person, and generally chose the GUI tools over text-based commands in a console, with few exceptions. However, my life keeps getting busier, and spending time on mindless tasks like deleting list spam seems like a waste. Especially when there is a command-line interface (CLI) tool which promises both speed and control.

This will only be useful if you are a listowner, and your list is administered using Mailman, and you use Linux/Unix/BSD. But if this fits you, give it a try! In your package manager, select listadmin, or use apt-get install listadmin or the equivalent in your distribution. To start the application, in your console, type listadmin. If it's the first time you've run listadmin, you'll first see a series of questions which when answered will fill in the file $HOME/.listadmin.ini. I found it easier to edit this file by hand until I found the correct way to enter the password and listnames. You can edit this file in any text editor; I prefer Kate.

Here's my file, with some sample lists:

username valorie.zimmerman@gmail.com
password XxXxX
spamlevel 8

# If you uncomment the following you will only have to press Return
# to discard a message:
#
default discard

# Uncomment the following to get a terse transaction log:
#
# log "~/.listadmin.log"
volunteers@mailman.linuxchix.org


password XxXxXx
alsachat@lists9.rootsweb.ancestry.com

Username in this case is the email account you use in Mailman to administer the list; password is the password exactly as you type it - no extra spaces or symbols, and list address takes a bit more explanation. I successfully figured out the listname so it worked by using the Mailman administration weblink for the subdomain and domain part. For instance, my Linuxchix link is http://mailman.linuxchix.org/mailman/admindb/listname, which becomes listname@mailman.linuxchix.org. For Rootsweb lists, it's http://lists#.rootsweb.ancestry.com/mailman/admindb/listname, which becomes listname@lists#.rootsweb.ancestry.com, where # is the server number. The same procedure works for KDE lists: https://mail.kde.org/mailman/admindb/listname becomes listname@mail.kde.org.

The coolest thing is that if you set up your ini file as I did, you can do ALL your Mailman lists in one run, no matter how many servers the lists live on, and how many passwords you use. Be sure to use a blank line after the last list in a group, then create another group as shown above.

For more information, see the author's description: http://heim.ifi.uio.no/kjetilho/hacks/#listadmin and the Manual: http://heim.ifi.uio.no/kjetilho/hacks/listadmin.txt

KDE: Finding the Unloved

Hi folks, It's that time again. We in the CWG are trying to find those parts of KDE that do not have someone to take care of them, as well as those teams that are in need of help. Our goal is to find people who are interested in those unloved applications, teams, or areas in KDE. Please add to the list here: http://community.kde.org/KDE/Finding_The_Unloved. Thanks!

Don't Make Me Think

Don't Make Me Think is the title of an excellent book on building websites by Steve Krug. If you are building any sites, you need this book. But even if you don't, it's worth a look, because it's really about how people respond to processes.

So often we make designs/processes based on some sort of logic, but forget to test them out with people. Krug stresses, over and over, that everything in a site needs testing. I believe this is true in community work, web-stuff, application design, windowing systems, game design, documentation, and on and on.

One of the points that I noticed, although he didn't stress it, is that small changes need testing, because when you emphasize one thing, even things you didn't touch are de-emphasized. So lots of small tests, quite frequently. Don't make a big deal of it; just grab someone, let them test your site/app/process/interface/form/design, and then fix what is obviously wrong.

Lather, rinse, repeat.

Contributions of Non-Technical People

First, congratulations to Bambi, Romain Perier for his new Kubuntu Developer status. He's one of our wonderful packagers who create the new KDE packages we need to run the latest Kubuntu. Bambi does some development, and this is important. And we need non-technical contributions too!

In fact, if you run and love Kubuntu, we want and need your creativity, your testing, your bug reports, your corrections on the wiki, your help on artwork, documentation, promotion (like this blog!), your helpful voice in IRC, identica, twitter, Google+ -- the sky is the limit! Community work is as important as the code, because people create the love, create the community, create the software.

As a non-technical person, I wanted to give back to Free and Open Source software, which I've been using for about 10 years. My process was to think beyond Linuxchix, which had been my homebase for those 10 years. I thought about my favorite application, which is Amarok. I looked around in the documentation, to see how I could help out. I noticed that the user documentation was outdated and not well-maintained. So after reading the mail list for a few months, I got my courage up, and asked about helping on the list. I was immediately greeted, and asked to join the IRC channel to talk about my ideas. Once I connected to Freenode and set up my identity there, I was made most welcome in #amarok, which made me feel wonderful, and more confident that I could contribute. It ended up that I headed up the Documentation team, and have been writing and editing the newsletter as well as the Userbase documentation. Through this process, I worked with the KDE WWW team, and learned more about how both Kubuntu and KDE work. Basically, I became part of the community team, even before joining the Community Working Group.

In Kubuntu, I haven't done as much as I would like, but I plan to get more active in the documentation team; editing if nothing else. The Kubuntu Council granted me membership, which is also Ubuntu Membership, based on my work with the LoCo, my help in #kubuntu, and work with the Ubuntu-Women. And Canonical sponsored a trip to Orlando, Florida to Ubuntu Developer Summit (UDS) last year.

I'm writing this blog post from Desktop Summit in Berlin; my lodging and travel sponsored by the KDE e.V. In June, they sent me to Randa, Switzerland for a sprint. Some of the wonderful rewards for contributing. If I can do it, you can do it!

Google Summer of Code, and Season of KDE: Past the mid-point

We have now passed the mid-term evaluations for both GSoC, and SoK. Our students are doing a wonderful job in GSoC -- all 51 students passed! We've had a couple of disappointing reports from SoK, which I would like to follow up on. Please, students and mentors, if you are having difficulties with research, coding, or support, contact us administrators. Lydia isn't alone; we are all here to help you.

This past week I was at the Community Leadership Summit and OSCON. A meeting of GSoC mentors and admins during lunch one day was fun, and I'm looking forward to the Mentor Summit in October. I'm so pleased with the creative support that Google is providing to KDE and the rest of the FOSS projects. This last year, they added the spectacular Google Code-In, and it seems likely they will offer that contest again this fall. New in 2011 is the Documentation Sprint, which I've applied to attend. If accepted, I'll be in Mountainview for a week, for the Sprint then the Mentor Summit.

Thank you Google, thank you KDE mentors, thank you wonderful students, and thank you to Lydia, Jeff and Ingo, my fellow administrators. This has been a great ride.

PS:

Teamwork!

Kudos to the Kubuntu packaging team, who are doing so much with so little! By so much, I mean that they are not only packaging all of KDE 4.7 release candidate, but also the 4.6 updates. With JR Riddell off working on Bazaar for Canonical, it's been a tremendous job for an all-volunteer crew. Many of these folks are in school, doing a Google Summer of Code project, or have summer jobs too.

I've seen them really challenged not only to get the software packaged so it builds and runs, but also running down licensing information, which is sometimes difficult to find or confusing to provide. Yet they have been so fun to watch, as they joke back and forth in IRC while working at top speed, and checking one another's work.

If you've ever thought about learning to package, or know how but have been taking a break, stop by #kubuntu-devel and offer your help. You will find work waiting for you.

Thanks again, Kubuntu team. You totally rock!