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.