Since my election to the Gentoo Council, I’ve become the de facto meeting chair and secretary. Over the past 6 months or so, I’ve learned a lot about what works well in online meetings (often by virtue of doing the opposite). By no means have I mastered this, but here’s some of my discoveries along the way.

What works well:

• Send out a draft agenda in advance (say, 1 week). This helps avoid confusion and disorganization at the meeting, and it also allows you to have no “open floor” section at all, because all topics should have come up when you posted the draft. Settle on a final agenda a couple of days in advance.
• On the draft, say who should attend the meeting to discuss each topic.
• Be specific about the topic, so you stay focused during the meeting.
• For each topic, have a very specific goal of what will be accomplished at that meeting. If it’s a decision, exactly what will the vote be? If it’s a discussion, what points do we want to get out of it, and why is it happening during the meeting instead of on mailing lists?
• Prepare. All of the information needed to make a decision should be readily available by the time the meeting comes along. To aid this, say on the draft agenda what information will be needed.
• Stay relentlessly on topic. Cut off diverging threads early on, before everyone gets involved.
• During the meeting, get an action plan for each topic: What’s the next step? Who’s responsible for it? When will they have it ready? Make sure the person responsible personally commits to this–don’t just assign it to them.
• Take notes, and post a public summary. This summary informs and reminds people of the progress made and what progress needs to be made next. By being posted publicly, it also allows for discussion, clarification and correction.
• Keep track of unresolved topics, and keep bringing them up over and over so they can’t slip through the cracks.

What works poorly:

• Request topics on a mailing list, but don’t collate them into an agenda until after the meeting’s started.
• Do your best to ensure that people relevant to a topic don’t even know it’s going to be discussed, or don’t tell them what information you need from them.
• Have vague topics, so nobody’s really sure what you’re supposed to be talking about or what you want to get out of it. Feel free to branch out into anything that seems related, or really anything at all.
• If a topic isn’t resolved by the end of the meeting, forget about it. If it’s important, it’ll come up again, right?
• Don’t tell anyone what the results of the meeting were. If you have to release something, make it as hard to comprehend as possible, like an IRC log instead of a summary.

It took a lot of pain and wasted time for me to figure out the value of doing things right, and I’m still working on getting some of the above points right, so I want to save you that same pain.

Do you have any more points to add? Please do so in the comments. Thanks!

I wrote an article discussing the role of distros in Google’s Summer of Code for this week’s LWN.net. Here’s an excerpt to whet your appetite:

Aren’t they just writing packages? What would they do with a Summer of Code project?

Read on to find out.

Today I reworked the mesa and xorg-server ebuilds to do things the cool way with the latest git sources. Mesa added an autoconf build, thanks to Dan Nicholson, which makes the ebuild a lot simpler and less error-prone by being more standardized. There’s no XCB support yet–if nobody else adds it, I’ll probably do it eventually. It’s just autoconf, no automake, so the installation side of the ebuild stayed pretty complex. There’s a few strange things going on with what headers mesa installs that I haven’t looked into besides just deleting them.

Also, these updates incorporate the first major step to removing the extra copy of the mesa source code used to build xorg-server. The GLcore module is now built within mesa instead of xorg-server, thanks to George Sapountzis. This created a circular dependency between xorg-server and mesa, so I made a new ebuild called mesa-glcore. Unfortunately this means that libmesa.a still gets built twice. The other half of getting the mesa source out of the xorg-server build is libglx, and I’m hoping someone does it soon (hint, hint!).

This work is all available in the Gentoo x11 overlay, which you can add with the simple command `layman -a x11`.

This meme on popular commands seems pretty interesting. I’m normally not into this stuff, so here goes.

donnie@comet $ history|awk ‘{a[$2]++} END{for(i in a){printf “%5d\t%s \n”,a[i],i}}’|sort -rn|head
61    ls
36    cd
35    sudo
33    nano
28    grep
24    e
23    qlist
15    man
15    git
14    cmake

Despite what you might expect, cmake has nothing to do with the build system. I had it set up before I’d ever heard of that cmake. To make sense of the above, you’ll need to see a couple of aliases.

donnie@comet $ type cmake
cmake is aliased to `PATH=”/usr/lib/ccache/bin:${PATH}” make’
donnie@comet $ type e
e is aliased to `pquery –raw -n -v –attr=license’

You can see that cmake is for when I want to compile stuff faster using ccache, and e is for searching through packages using pkgcore. Also, nearly every time I run sudo it’s because I’m emerging (installing) a package. The qlist command is for querying installed packages. In all, I spend a whole lot of time dealing with packages, which isn’t terribly surprising since I’m a distro packager.

You can also tell that I spend a lot of time reading documentation and searching for information from my use of man and grep.

Nowadays all my projects are maintained in git with the exception of a few Gentoo repositories. People have been writing about how great it is all over the place lately, so I’m not going to talk it up any more. When I make quick changes in these projects or any other files, I generally use the nano editor. For more involved sessions, I’m gravitating more and more toward emacs since starting to use it for its amazing XML editing mode called nxml-mode.

Please let me know whether you got a bit more value out of this meme post than some other ones because of the explanations that accompany it.

Recently I mentioned Paul Graham’s essay on how to disagree, which described types of disagreement. This post will instead really tell you how to disagree without making enemies, and more generally how to get along well with people.

Here’s a summary of Dale Carnegie’s outstanding book (with the same title as this post), which has been a top-selling communications book for the past 70 years. These techniques don’t sound terribly original or mind-blowing. Instead, they are elegant and straightforward, which makes them easy to remember. I’ll also tell you which principles I think are the most important.

Fundamental techniques in handling people

1. Don’t criticize, condemn or complain.
2. Give honest and sincere appreciation.
3. Arouse in the other person an eager want.

These ideas lay the groundwork for everything else. The overall focuses of the entire book are:

• Encourage the positive things people do, instead of disparaging the negative.
• Talk about what other people want, instead of what you want.

6 ways to make people like you

1. Become genuinely interested in other people.
2. Smile.
3. Remember that a person’s name is to that person the sweetest and most important sound in any language.
4. Be a good listener. Encourage others to talk about themselves.
5. Talk in terms of the other person’s interests.
6. Make the other person feel important–and do it sincerely.

The most important points from this group are 1 (be interested in others) and 5 (talk in terms of their interests).

12 ways to win people to your way of thinking

1. The only way to get the best of an argument is to avoid it.
2. Show respect for the other person’s opinions. Never say, “You’re wrong.”
3. If you are wrong, admit it quickly and emphatically.
4. Begin in a friendly way.
5. Get the other person saying “yes, yes” immediately.
6. Let the other person do a great deal of the talking.
7. Let the other person feel that the idea is his or hers.
8. Try honestly to see things from the other person’s point of view.
9. Be sympathetic with the other person’s ideas and desires.
10. Appeal to the nobler motives.
11. Dramatize your ideas.
12. Throw down a challenge.

Important points here are 3 (admit your mistakes), 4 (begin friendly), and 8 (step in their shoes).

9 ways to change people without giving offense or arousing resentment

1. Begin with praise and honest appreciation.
2. Call attention to other’s mistakes indirectly.
3. Talk about your own mistakes before criticizing the other person.
4. Ask questions instead of giving direct orders.
5. Let the other person save face.
6. Praise the slightest improvement and praise every improvement. Be “hearty in your approbation and lavish in your praise.”
7. Give the other person a fine reputation to live up to.
8. Use encouragement. Make the fault seem easy to correct.
9. Make the other person happy about doing the thing you suggest.

The first 5 points here are the most important, although all of these ones are important.

Conclusion

Best of luck to you in applying these principles to your own life!

Live-git packages for much of X.Org (the important parts, anyway) are now available in Gentoo’s x11 overlay, thanks to James Cloos. I hope you’re all very happy that he’s merged his work into the main project overlay–I know I am. Gentoo users can add this overlay by installing layman and running `layman -a x11`. All the live-git packages are in package.mask, so you’ll need to unmask them–portpeek is one easy way of doing this.

xorg-server-1.5 prereleases are also in there. So far that’s just 1.4.99.901, but more should show up soon. They’ll remain in the x11 overlay until they build against packages that have actually been released, at which point they’ll move to package.mask in the main tree. Any xprint users, feel free to contribute patches to fix its build. I know Debian already has some patches for this, so that would be a good place to start.

Paul Graham’s writing is hit-or-miss for me. His most recent posting, called “How to Disagree,” definitely hit home. Everyone involved in a community should read it. It describes a hierarchy of disagreement types from irrelevant insults to arguments that actually refute to the main point. After you read it, you will recognize which responses are baseless claims and which ones deserve consideration. This will also help in understanding debates of all sorts that you aren’t involved in but just observe.

PackageKit is this amazing idea of having a tool for managing packages that works identically on every distribution. It’s got both a GUI and a command-line tool, called pkcon. Check out some screenshots. To reach that goal, it has to actually work on every distro.

Wouldn’t it be great if PackageKit worked on Gentoo? You could make that happen! Three major package managers work with Gentoo: portage, paludis, and pkgcore. Working on this as a Summer of Code project means you’d write a PackageKit backend for one of these package managers, in the process learning the API of each and working with PackageKit founder Richard Hughes, me, the developers of one of the package managers, and the broader Gentoo and PackageKit communities.

Three potential applicants have already talked with me about this, so space is limited. You can reach me by email or on IRC (irc.freenode.net/#packagekit as dberkholz) if you’d like to talk about your ideas.

Summer of Code applications are only open until April 1, 0000 UTC, so apply now!

People were so busy complaining about my pie chart that most of them apparently didn’t have a chance to think about the meaning of the actual data. To try helping people look at the information rather than its presentation, here’s a bar chart of the same information:

I don’t recommend looking at it because you may go blind, but I’ve made available the (extremely ugly) script that created this.

I ran a quick, informal poll on the internal Gentoo developers’ list last week, and tonight I began analyzing the results. 50 developers responded to my 9-question survey, and I’m going to post the results of 1 question at a time.

First question: What are the top 3 issues facing Gentoo?

Technical issues are way down on the list. Developers’ top 5 issues are manpower, publicity, goals, developer friction, and leadership. It’s good to see that we’ve been addressing at least a couple of them with the newly energized public relations project and work on the Code of Conduct. Other issues that have been ongoing for quite a while now are the lack of distro-wide vision and goals. The Council could provide those by increased activity and taking stronger stands in particular directions, and that’s part of the reason I did this survey—to figure out which directions our developers care about. I think part of the problem is that nobody sits around pondering directions and ideas. Everybody’s busy working in their own little areas and not thinking about the big picture. Manpower, or lack of it, is another issue I’m indirectly addressing in my push for greatness, which I’m going to post more about at some point (I promise!).

To create this chart, I used Google’s excellent chart API. The neat part about the API is that it’s simply a URL, so you can construct it with any language. I used a shell script since I was already fiddling around with awk. Any answer with less than 4 respondants was grouped into Other to make the rest of the chart readable.