Gentoo: New release, “new” leadership

I wrote an article discussing Gentoo’s new release and new council for this week’s If you’ve read my earlier blog posts and other posts on Planet Gentoo regarding 2008.0, there won’t be a whole lot of new information. It’s designed as analysis of recent Gentoo events for people who don’t already follow Gentoo development.

If you aren’t already subscribed to, get on it. It’s my #1 source for Linux- and open-source-related news, and it saves me huge amounts of time that I would otherwise spend in cesspools like Slashdot. =)

P.S. Anyone going to OSCON, let me know via a comment here or my contact info.

Developers give existing Gentoo council a mandate

I said this briefly on the gentoo-dev list, and I want to expand on it here. The council is Gentoo’s leadership, and it’s composed of 7 people elected by all Gentoo developers using a Condorcet-style ranking vote. Of the 7 people on the old council, 5 of them decided to run again and every single council member who ran was re-elected.

This is significant because the re-election was forced over miscommunication about a meeting, and this created some serious conflicts with a sentence in the Gentoo Linux Enhancement Proposal that created the current structure, including the council. I consider this a mandate, showing that Gentoo developers have confidence in the existing leadership doing what’s best for Gentoo.

This was your chance to say yes or no, and you gave us a resounding yes. Since it isn’t often we hear much from the vast majority of developers, this really means a lot to me in saying which directions we should go, based on who you voted for (graphs here). My interpretation is that you like what’s going on now and where we’re talking about going. I’d really love to hear more input from those of you who don’t normally speak up, though. What can we do for you?

P.S. The 2008.0 release is out.

How to run an effective meeting on IRC

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!

How to disagree

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.

Redux: Gentoo’s top 3 issues

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.

What are the top 3 issues facing Gentoo?

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?

Pie chart

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.

Improving Gentoo’s PR

This won’t be a long post, because I’m tired. Sorry for the dearth of posts on here, but I’ve been busy writing other things—see below.

For anyone who hasn’t heard, I took over as lead of Gentoo’s public relations efforts a little over two weeks ago. Three days earlier, I wrote an LWN article concluding that Gentoo isn’t falling apart, but it’s totally failing to communicate. After writing that article, I realized that somebody had to step up to deal with this problem—who better than me?

My focus right now is showing people that Gentoo development is just as alive as it’s ever been. I’m doing this by opening windows into development through more frequent news postings, with links to discussion forums to respond to the posts. Doing this, combined with writing to people (“You will”) rather than about them (saying “Users will…”), will help build better relationships with our users.

Another part of improving the perception of a lively, active community is updating the look of our website. The old website redesign never made it to fruition, so a few of us have begun taking a look at how far it got, what happened, and what to do now. At a minimum, I’d like to make some slight changes to give our site a face lift. The design hasn’t changed for 6 years now, and it shows.

One major, easily fixable problem with our website is that there’s no obvious place to go for users who want to contribute. There should be a big “Get involved!” or “Help Gentoo!” link right up at the top of the page, next to “Get Gentoo!” All this requires is a little webpage that describes all the ways people can help. In fact, the whole website isn’t task-oriented enough. This needs to change.

In the future, I’m going to begin improving the “press” aspect of PR, based on my notes from an excellent talk by Josh Berkus at OSCON 2006 on public relations for OSS projects. The main ideas here are providing a press kit for reporters with all the basic info they want, building relationships with local reporters by using local Gentoo contacts, putting together some case studies of people and businesses using Gentoo in interesting ways, and improving our process for creating and posting news and press releases.

Finally, any Gentoo users can help improve Gentoo by simply advocating it to Linux users you know, giving demos and talks at Linux user group meetings or conferences, promoting it in articles, or writing in your blog about something Gentoo does really well.