Contributions of late.

Here’s a smattering of stuff I’ve been doing in the Fedora Project lately. Although I don’t get to spend as much time on Fedora in my new job, I’ve been putting aside some off hours and a portion of Friday (or as I like to call it, my “no meetings day”) to make extra headway.

• Completed some additional package reviews for Insight, including drupal6-date and drupal6-calendar.
• Packaged and pushed out to testing the ever-popular 960.gs theme for Drupal 6: drupal6-theme-ninesixty (thanks to partner in crime David Nalley for his review help!)
• Set up a cron job for the Insight test system so folks working on the theme see the latest stuff every half hour
• Provided a package review for the transifex-client package to assist folks working on the Transifex migration
• Updated xmlstarlet in Fedora to inherit bugfixes from upstream

Jiffy Pop meeting minutes.

For some reason this week I feel like blogging about some of my time-saving tools. I’m certainly not a superstar when it comes to eliminating wasted time. But when I was FPL I had to figure out ways to be more effective so I could spend more time on the tasks that truly required it.

If you run meetings online, you probably already know there are cool projects like Debian’s meetbot to make the process easy. You can give instructions to the bot during the meeting, which are recorded in the minutes, using commands like #info, #agreed, #action, and so on. We use meetbot in Fedora as well, for just about every meeting we run. We even use it to log hackfests and other groovy online get-togethers.

But how do you get those minutes out to subscribers of the team’s mailing list? I’ve seen some people encounter problems doing this quickly. Those problems cause stress, because you want to do a good job for your teammates. If the process is hard, it’s tempting — heck, sometimes it’s necessary — to put it off, so you can do other priority tasks. Then you feel guilty about it later when the minutes aren’t out on time. Wouldn’t it be great to eliminate that stress and guilt?

Now, I have zero doubt that someone could automate a no-time-required solution, and maybe some folks out there use such a system. But in my case, I do like to look over the minutes first, and sometimes prepend a little text at the top. For instance, I might want to add an explanation or extra pointer for context, or a note about something that went wrong mechanically. If you’re in a similar situation, or just not ready for full on automation for some reason, here’s how I do minutes very quickly. Maybe it will help you in the future:

1. I have my IRC client and my email client, Mutt, up in separate windows.
2. When the meeting ends, I send the command #endmeeting, and meetbot outputs information about where to find the minutes and log.
3. I immediately start a new email in Mutt, with the subject “<Name of meeting> recap <date and time>”. This calls up Emacs for me, but it doesn’t matter if you’re using a different email client.*
4. I copy the three lines (Minutes, Minutes text, and Log) that meetbot outputs, usually with a mouse. (If you’re in screen or something, use its copy function.)
5. I paste the lines into my email and align them properly if needed.
6. I use the mouse to copy the link address for the text-format minutes.
7. In Emacs I run a shell command using Alt+1, Alt+Shift+!.** The command is curl -s -o – <paste the link address from step 6>. This command retrieves the text-format minutes straight from the internet into the buffer.
8. I trim the headers as needed.
9. I send the email. (Here’s an example from today.)

That looks like a lot of steps, doesn’t it? But since almost everything there is copying and pasting, the actual time to complete this is under 2 minutes. (If you’re a fast typist and good with your editor, it’s more like 30 seconds.) Thus the title for this post!

Many thanks to Kevin Fenzi and the Infrastructure team for providing meetbot functions for our use in Fedora. They’re a big, big help every week for me personally.

_{* Well, it does matter a little. When I used Evolution, there wasn’t a way to insert the output of shell commands easily into my compose window. That’s totally sensible because Evo isn’t designed for the 0.1% of people who like running shell commands. It’s barely more work to just use a terminal and then Evo’s function to insert file content.}

_{** The Alt+1 means that the following shell-command, run by Alt+Shift+!, will dump its standard output into the current buffer, which is where the email’s being composed. If you were using a terminal with some other email program, you could do curl -O <paste link address> which would retrieve the minutes to a file. Then you could paste the file into your email compose window.}

Fedora 14 Alpha is go!

As John posted last night, Fedora 14 Alpha was declared ready for release next week. Although there was a one-week slip to handle the fact that our blocker list wasn’t clear, Fedora developers and testers in the community have worked hard together both to resolve the remaining issues and make sure that our Alpha would pass the release criteria. There were a number of developers who hopped in to fix things quickly to yield package builds that would clear the runway, so thanks to all of you guys.

I also wanted to take a moment to say how impressively the QA team has beefed up the definition of these criteria. Not only that, but the team continues to take opportunities to refine them whenever we hit a question that’s difficult to answer under the current criteria. We still can improve our effectiveness at turning the combination of the blocker bug list and the criteria into getting response from developers where needed, but that’s more of a shared issue. As with our criteria and our schedule, we continue to improve these processes in an iterative way, and openly to boot.

Here’s one place where everyone will be able to pitch in — making sure that any common issues in the Alpha are properly noted. We have a wiki page for common Fedora 14 issues, and it’s very important for us to keep it updated for all those trying out the pre-releases. If you’re in doubt whether it’s a common issue, that’s OK. There are some notes on that wiki page on how to add your issue:

• Add it yourself, if you have wiki access. Please follow the style and guidelines explained in the comments in the page source. (You’ll see them when you start to edit.)
• Or, add the CommonBugs keyword to the bug report. Someone from the QA team will then inspect the issue to determine whether the bug should be listed as a common bug. To expedite your request, add a comment to the bug that includes
  1. a summary of the problem
  2. any known workarounds
  3. an assessment on the impact to Fedora users

If in doubt, we’d rather see the issue than not.

The Alpha release is meant for advanced users and Fedora participants to download and test. It’s not code-complete, meaning a few things may be broken. We want and need your help to identify, report, and resolve these problems. As always, the best way to do that is to file bugs! Random blog entries, tweets/dents, and mail may be interesting, but to track the problems to resolution, bugs are the right way to go. We look forward to your participation as always — if you’re not already installing from the pre-release tree, you’ll be able to pick up the official images next Tuesday, August 24.

In summary, nice job to everyone involved, and I’m looking forward to switching a few systems here at home to F14 Alpha!

Criteria and documentation.

John Poelstra wrote in his blog about how objective criteria support sustainability in an open source project. It was insightful and I wanted to follow up about how that extends to process documentation as a whole.

Lots of people talk about documentation as “that thing you do when you’re finished building something.” But in an open source project, where you’re trying to attract people to help you build or make, that’s an unworkable approach. It’s something you do to make sure that people with skill and energy, who want to help you, have what they need to get started. You want to ensure they can learn the required bits without you having to hold every individual hand, because if you do that, you can’t work on the project yourself. By writing everything down somewhere, you give people the opportunity to self-serve when it comes to learning the basics.

Sometimes acronyms are obfuscatory, but sometimes they help. The “standard operating procedure,” or SOP, is an acronym we do use quite a bit on some of our teams, because it’s a great shorthand for saying, “the stuff you need to know to accomplish a task with minimal or zero help.” An up-to-date SOP document makes it possible for anyone to carry out mechanical steps, observe and report the results, and take follow-up actions if needed. Our Infrastructure team has one of the most comprehensive collections of SOPs in the Fedora Project. But other groups are starting to catch up, like Release Engineering and QA. (Some teams don’t categorize their SOPs like this, which is fine — the point is not what they’re called, but that people can find the procedures and follow them.)

It’s tempting to think that some processes are so important or fiddly that we can’t turn them into SOPs. But I believe those are precisely the ones we should be investing in documenting. It boils down to these simple ideas, which I believe are intrinsic to the open source way:

• The more we believe our work can’t be reproduced by someone else, the harder it is to get anyone to help with it.
• By extension, the more we believe our work can’t be reproduced by someone else, the less likely we will solve the “eaten by raptors” problem*.

People like Mel Chua have written (and practiced!) exhaustively on combating this problem, and often the solution is as simple as “teach someone now, and make it the student’s job to document while learning.” Paradoxically, teaching someone with a lower level of general skill can be more helpful than teaching someone who needs less tutelage. Doing so can expose the specific prerequisites, which otherwise might be just hazy notions (“the practitioner needs to have a high skill level in ___”).

Ideally, anyone in Fedora ought to be able to be absent at any point in our release cycle without unduly affecting any of our release processes. The more we make it possible for any contributor to follow a process like judging against criteria, producing media and art, spinning release candidates, and so forth, the closer we get to that goal. The result is a more sustainable Fedora Project.

*The “eaten by raptors” problem, simply put, is that having institutional knowledge locked up with a small number of people represents substantial risk in a project. This is especially true when the number is one, or if the project is an open source effort. To mitigate the risk that your project will suffer if any member is eaten by velociraptors, eliminate knowledge silos wherever possible.

A spoonful of sugar.

Kevin,

Thanks for your thoughtful posting about being helpful in the Fedora support channels. I think among the keys to understanding what someone seeking help needs — let’s just call this person “Nathan” to make this blog post easier to read — are:

1. Good listening skills
2. Good empathizing skills

Essentially, a good helper need to be able firstly to turn off any immediate reactions or conclusions to which they might jump about Nathan’s situation. Not concentrating on assumptions about Nathan’s problem or skill set allows the helper to concentrate more on the actual facts needed, and elicit them from the person seeking help. Once the helper has a good idea of what Nathan’s problem really is, and what skills to solve it Nathan might lack, it’s easier to decide what level of help is required — or spoon feeding if you prefer.

Then the helper needs to empathize with Nathan to some degree — put himself in Nathan’s shoes, and allow that understanding to guide how he deals with Nathan’s needs. Often people forget this step and as a result the communication can turn a bit sour. But by making the effort to step outside ourselves to determine how Nathan might view our advice, we can increase the effectiveness of our help by orders of magnitude.

Help in any support venue affects not only Nathan, but the helper too — and in addition, even people who are just watching that help happen in the support venue are affected too! The better each individual interaction is, the better the overall environment for everyone, including newbies, experienced users, helpers, and lurkers. And of course, a more positive environment means more fertile ground for encouraging contribution to free software.

Every helper needs to understand his own level of comfort with listening and empathy, and let that guide his interactions with Nathan. That’s what I like so much about Kevin’s blog post. It shows a level of personal insight to determine Kevin’s comfort level and honest evaluation of where he thinks he can be effective as a helper.

All of us who help support people of any kind, regardless of experience level, should have a somewhat regular checkpoint of introspection, where we honestly think about our own effectiveness at listening and empathy. Then we can adjust our dealings with those we support to maximize the constructiveness of our interactions, and thereby have a direct, positive effect on the culture of free software.

Fedora 12 Alpha!

Today marks the Fedora 12 Alpha release, hot off the presses! You can pick up a copy to try all the latest technologies here:

http://fedoraproject.org/get-prerelease

I’ve been running the Alpha version for about a week or so on one of my home machines. While there are some minor foibles here and there, most of it seems to be working like gangbusters — and better than ever. The PackageKit “command-not-found” plugin is pretty cool, and I’m also enjoying some of the other sweet new features like the new Virtualization Manager upgrades.

Not everything is guaranteed to work perfectly, because there are some pretty new bits in there. But we do encourage people to at least grab a Live ISO image and run it from a CD or USB stick. And of course, it’s very important that you FILE A BUG if you find something that’s wrong! Remember kids, Twitter and Identi.ca are not substitutes for good open source practices — they’re a good way to encourage people to check your work, though, if you’re looking for a second opinion. I hope everyone trying F12 Alpha will blog a little bit about the bits they find that they like — and if you don’t like something, tell us about that too, and let us know how it can be made better. Then file a bug about it!

You can tell I’m big on the bug filing today. That’s because we seriously want your help in testing the release. Yours, and everyone you know! The more problems we can find and knock out before the Beta, the better Fedora 12 “Constantine” will shine in November! I, for one, started using the command-line bugzilla client for doing this quite often, and it’s very convenient when I’m in a terminal or otherwise not using a Web browser. You just run bugzilla login and bugzilla new — the latter with a bunch of required options — and you’ll get a reply with your bug number assigned.

I hope you enjoy this very early sneak preview of what’s coming Fedora 12! And thanks as always to our awesome Release Engineering and Infrastructure teams for their usual fantastic job at getting Fedora out the door into the hands of our millions of users.

Speaking of which: Only 10 weeks into our release, our latest stable offering, Fedora 11 “Leonidas,” has surpassed one million registered updating IP addresses, as noted on our statistics page. That’s almost 40% higher than our uptake from the previous and very well-regarded Fedora 10 release. I also see that our number of completely unique IP addresses registered for updatesm from Fedora 7 through Rawhide is now at slightly over 15 million for the first time. There’s some helpful information floating around about how that might translate to user numbers, but for my part, I just love being able to just look up these numbers in our completely open and transparent infrastructure — another reason to enjoy being part of a project dedicated to building 100% free software for you and yours.

Sad daily confessional: I meant to have this out in the morning but the upcoming Red Hat Summit has me hopping more than usual. Sorry about the delay and hope to see you in Chicago next week!

Update: Fixed the “sweet new features” link above, thanks Rahul!

Fedora teams’ call to action.

The Fedora Project has always been aimed at encouraging participation. Free/libre and open source software continues its forward momentum and increasing pace through the growth of community and contribution. And Fedora plays a large role in that motion, through our rapid release cycle, our dedication to working with upstream software communities, and by making sure that everything we build is 100% free and redistributable. But we are not just a distribution — we are a project made up of teams, and individuals: people working together in pursuit of common goals. The more people that help, the more we can accomplish. And therefore, as free/libre and open source software advocates we need to constantly ask ourselves, Am I doing what I can to make it easy for others to help?

On many Fedora teams, we have a robust membership from all around the world. We can see the effects of solid leadership and the lowering of barriers resulting in wider participation and contribution. But in some places we could be doing better. In that vein, I ask team leaders and principal contributors: How many steady contributors do you have working on your immediate team? How many people can you count on to perform key tasks? And at the risk of sounding morbid, I’ll ask a very important question that’s simply a good way of summing up this idea: What would happen if you got hit by a bus tomorrow?

OK, I warned you that was a little morbid. Forget about the risk of death, or at least injury, but focus on the central idea. Maybe we could sum up in a more humorous fashion. My 6-year-old son loves dinosaurs, so here’s a different way to ask that question: What if you were eaten by dinosaurs?

Yes, it’s even more unlikely than the bus scenario. By restating the question in a silly way, I hope it keeps you from worrying in concrete terms about your loved ones or your insurance. That way, you can treat the question as an abstract problem in community building. But that question still has concrete solutions. The point is, if for some reason you as a team leader or participant were suddenly out of the picture without warning, what would happen to the work your team does?

If you’re doing a solid job of lowering barriers, the answer should be “almost nothing.” The team should be able to keep chugging along, more or less. Certainly all contributors are important — you’d be missed, and we’d make it a point to hunt down those pesky velociraptors and make them pay! But the overall team’s ability to be healthy and vibrant shouldn’t hinge on any one person as a linchpin.

Can other people do your work if you’re out of commission? Can Fedora continue without you manning the wheel? If not, it’s time to step back and look at what you’re doing to improve that situation.

• Are the procedures for your team well documented, in an organized fashion, somewhere people can find and read them? For many people, documentation is never as fun as the “real work,” at least not for people who don’t love writing documentation itself as the real work. (Shout out to our Docs team for being in the latter category.) But if you were eaten by dinosaurs, that very documentation helps people find the information they need to keep your work going. Rather than have contributors flounder around trying to find random people on IRC to figure things out, you can promote efficiency and motivate new contributors by having material that will tell them how to work through processes.
• Does your team have a plan, that includes goals for the immediate future? Every team has a couple of goals its members want to accomplish. Some are very broad vision statements, but to encourage participation you need at least a couple of achievable near-term goals toward which your team members can work. By tracking their progress in regular meetings, and reporting that progress to the overall Fedora Project, you make it possible for interested people to pitch in where needed. This process also encourages the team to be honest with itself. The ability to look back on a release and say, “We achieved goals X and Y, but still need to do some hard work to attain Z,” is a powerful motivational force. Never underestimate the empowerment that comes from a job well done.

These two items are completely equal in importance. Just as important as the plan is to make sure you are building a team of contributors that helps you get there! The most successful community projects ensure that the most knowledgeable people don’t make a point of performing every difficult task. Instead, they make it a point both to spread that knowledge so others can help with the work, and to enlist the team’s help to establish and support achievable goals.

If you find that you as a community team leader spend a lot of your time saying, “I wish I had time to work on this cool new idea, but I have too much of this other, established work to do,” then it’s time to evaluate how you’re doing as a community builder. If you make it possible for other people to help — and, along the way, to succeed in achieving their own goals as participants — you are doing far more for Fedora in the long term. And in the event that you do get mistaken for a convenient, bite-sized package of Oscar Mayer lunch meat by a passing T. rex, you also make it possible for Fedora to continue that forward momentum we talked about earlier!

So in the vein of this post, I want to issue a challenge to each of our teams, to do two things during the next 10 days that will help make Fedora 12 the best release yet, and help make the Fedora community an even better place to contribute to free software:

1. Check to see that all the processes you use are documented on the Fedora Project wiki — and if not, make plans to do so. Don’t worry about skillful writing; worry only about documenting what you do.
2. Come up with one or two simple goals that your team wants to achieve by F12 release, and announce them to the community via the Planet (and any other way you’d like).

We’re embarking on our 12th release, and all signs point to the next release, just like the others before it, to be the best one yet. We have an enormous and amazing community of participants and contributors, who do more than just spread the word — they lead by example. Let’s each of us make sure we’re doing all we can to ensure our teams’ and our teammates’ success, by giving them the tools they need to help as fully as possible.

Viva Fedora!

How about that desktop?

I figured while I’m in a super-bloggy mood today I’d add this tidbit. Someone asked me a question about what might be missing from distributions like Fedora that would help it reach more users. This question isn’t new and I’ve given the subject a lot of thought over the last few years (even before being the project leader).

Red Hat and Fedora already invest a huge amount of time in desktop tech. We work upstream to make sure that ALL free software desktops are compelling, not just Fedora. When someone else has a compelling desktop in their free community distro, it means our work has been worthwhile.

Often people bring this point up in response to Fedora’s stance on software freedom. We believe strongly in software freedom, and that including proprietary software actively undermines our goals. We also have a goal of complete global freedom of reuse and redistribution, an objective with which proprietary software also often conflicts. We also believe in choice and that’s why we make it easy for third parties to provide very simple ways for people to get those technologies on their own in places where it’s free and legal.

Worsed than damned lies?

A word about statistics: Fedora continues to be completely open and transparent about the ways we gather statistics and the ways we present them. We don’t document these statistics for purposes of competition, but because we believe our community and our sponsors are invested and interested in knowing some of the end results of the work they do in Fedora. We also use these statistics to help us construct and refine additional community-building strategies and initiatives, which are themselves also openly and transparently produced.

In particular, there are statistics available which show the number of unique IP addresses that have checked in for updates for each of our distributions from Fedora Core 6 up through Fedora 9 and current Rawhide (and soon, Fedora 10). Although totaling those numbers is interesting, it is not meant to indicate a measure of users, only a total number of connections to repositories. No one in Fedora claims a specific number of users based on these statistics. We do know that each of our releases tends to be installed on machines located at 3 to 4 million unique IP addresses. Any one IP address, though, could represent:

• one machine that has been upgraded to a newer release
• two or more machines owned by the same person behind a NAT/router/firewall
• two or more machines owned by different people behind a NAT/router/firewall
• two or more completely separate sites where the IP address has been re-used (cable/DSL pool)

Obviously this makes determining the total install base of Fedora across all releases somewhat difficult. We understand completely that IP address counting is not a scientifically valid way of determining a total number of users. That’s why we don’t claim a number of users from these counts; we only present them as what they are, sums of unique IP addresses.

Anyone who’s ever heard me speak to this issue knows it’s never been my intention, nor interesting at all to me, to debate over user statistics. I am extremely satisfied that we have a geometrically (in some cases exponentially) growing number of account holders, contributors, and Ambassadors involved in Fedora, all of which numbers we can openly and transparently document. This is far more compelling for the community, I think, than simply throwing large round numbers about, especially when those numbers aren’t supported by completely open, transparent, and documented recording and reporting methods.

Our leadership position, I believe, is based on the total contributions our community makes to the entire free and open source software ecosystem, through our continuing, unwavering policy of upstream collaboration, and our continual efforts to lower barriers to contribution across the entire project.

_{NOTE: This is a refinement of a post I made earlier to the fedora-marketing-list, in response to some inferences people have made with which I don’t agree. I’m refraining from naming names not to lend those inferences credence, but because I think they were made with good intentions. While I think it’s important that people understand the truth about these numbers, I don’t wish to hurt anyone’s feelings. Treat all statistics statements with caution unless you can see them backed up with facts and methodologies.}