Manners matters.

I was checking out this fabulous new book called Open Advice after seeing a link on a mailing list. The book is a collection of reflections by experienced (and often well-known) free and open source software contributors on things they wish they’d known when they started in FOSS.

I found a particularly wonderful section among a wealth of other wonderful text. In fact, I probably could have opened the book at random and found something just as quotable and insightful. But this piece struck a sympathetic nerve, probably because one of my pet issues is treating each other with kindness. This excerpt is from the chapter called “Good Manners Matter” by the amazing Rich Bowen, and I’ll reproduce it here, thanks to the author’s and editors’ enlightened use of the CC BY-SA 3.0 license:

I had been doing technical support, particularly on mailing lists, for about two years, when I first started attending technical conferences. Those first few years were a lot of fun. Idiots would come onto a mailing list, and ask a stupid question that a thousand other losers had asked before them. If they had taken even two minutes to just look, they would have found all the places the question had been answered before. But they were too lazy and dumb to do that.

Then I attended a conference, and discovered a few things.

First, I discovered that the people asking these questions were people. They were not merely a block of monospaced black text on a white background. They were individuals. They had kids. They had hobbies. They knew so much more than I did about a whole range of things. I met brilliant people for whom the technology was a tool to accomplish something non-technical. They wanted to share their recipes with other chefs. They wanted to help children in west Africa learn how to read. They were passionate about wine, and wanted to learn more. They were, in short, smarter than I am, and my arrogance was the only thing between them and further success.

When I returned from that first conference, I saw the users mailing list in an entirely different light. These were no longer idiots asking stupid questions. These were people who needed just a little bit of my help so that they could get a task done, but, for the most part, their passions were not technology. Technology was just a tool. So if they did not spend hours reading last year’s mailing list archives, and chose instead to ask the question afresh, that was understandable.

And, surely, if on any given day it is irritating to have to help them, the polite thing to do is to step back and let someone else handle the question, rather than telling them what an imbecile they are. And, too, to remember all of the times I have had to ask the stupid questions.

Well said, Rich. Any of us helping users or newcomers to any endeavor, whether it’s Fedora, some other FOSS project, or a volunteer organization in your town, can learn from Rich’s experience above, assuming that we haven’t already lived it ourselves. Any user can be the contributor of tomorrow. It pays real dividends to extend them a helping hand.

I do highly recommend you check out Open Advice at the website. It’s chock full of insight, anecdotes, and lessons about the powerful, transformational, and exciting journey of free and open source software. The book is a free download, but you can also purchase a copy from Lulu (and, according to the site, from Amazon soon).

SELF 2011 day 1.

Max posted a good summary of SELF day 0 that included our dinner and confab last night, and since we’re in agreement there’s no need for me to belabor his points. The upcoming release cycle will be an opportunity for community leaders throughout Fedora to renew their commitment to regular communication, transparency, and visibility at all levels. So on to SELF day 1:

Today was Cloud day here at the Southeast Linux Fest, and I know a couple of Fedorans here made it to some of those sessions. However, I ended up getting together with Max, Robyn, Jared, Eric ‘sparks’ Christensen, and a couple other people to talk about finance and events. One of the important topics was how we can make sure sponsorship requests and other financial matters for FUDCon events are handled quickly, efficiently, and fairly, while still maintaining a strict bottom line.

You’ll see some of the work captured on the EtherPad for the meeting, and links to some wiki tweaks made, here. I know Jared and Max will be posting more information about that session, and since I had to leave in the middle of the session for a conference call, I don’t want to jumble up or misstate the proceedings. Nevertheless, I was happy to see this dialogue happening in a candid and open way (besides the EtherPad and wiki work, our room was open to anyone who wanted to stop by and listen or participate).

I also had a chance to listen in on a little documentation brainstorming that Jared and Eric were doing after lunch. I spent my remaining time going over my slide deck and making some last minute tweaks for maximum goodness. As it happened, I had a very healthy turnout for my session on PyGObject (that slide deck is CC BY 3.0, by the way), good questions and feedback from the audience members, and even a number of very gracious compliments from attendees.

I love doing these educational “fill in the gap” sessions designed for the beginner-to-almost-intermediate audience. I believe lots of people out there are like me — somewhat skilled in simple sysadmin tasks but haven’t been able to make the leap to writing their own applications because of the learning curve. They just need a helping hand to explain the necessary missing pieces in a friendly and non-threatening way.

A gentleman talked to me after my session about “backing up into the right answers” as a learning experience, when you have no other alternative. That’s certainly a good way to explain how I learned GUI programming with PyGTK and PyGObject! But I’d rather help other people avoid awkwardly driving around backward and save them the time it took me to wrap my head around the basic concepts, and get them into 2nd, 3rd, or 4th gear (moving forward, not backward!) faster than me. We agreed that we both had plenty of occasions when we could have used that sort of tutelage, and I hope my session bridged the gap for some of the attendees.

After my session, I had a couple brief chats with attendees and other folks, and then suddenly it was time for the speaker dinner, which was delicious. I briefly wished I had a nice cigar to follow that excellent steak they served us, but decided to head upstairs to write a blog post instead so I could meet my self-imposed regiment of one per day. Now I’m going to go join the rest of our SELF folks at the pre-party and unwind.

And hey, if I’m lucky I might be able to watch Robyn spank the tar out of Greg and Max at poker again.

Making the most of the planet.

With a title like that, I could go two ways with this blog post, right? One way would be to encourage people to do stuff that’s good for the Earth, like recycling and so forth. There are probably lots of people who could do that better than me. Instead, this post is going to be about making the most of the Fedora Planet, which carries information about contributors and their work to each other and to audiences outside the Fedora Project.

I personally like to see a mixture of information on the Planet that tells me about our contributors, their work, and the things they’re doing in Fedora. Often I see stuff appearing on the Planet that isn’t really relevant to any of those topics though. When I reached out to a couple different Fedora contributors recently to ask them about posts, I found they didn’t know they could aggregate part of their blogs, based on a category or tagging, as opposed to the feed of all their content. The contributors in question were both interested in how they could do this properly, and I found that reaching out to them directly, with an offer to help, was a great way to discuss this topic in a constructive and educational way for both parties.

Why is that a helpful feature of blogging? Because it allows the writer to express themselves however they like on their blog without worrying which aggregators the content will end up feeding. A single writer may be feeding content to several different planets or other aggregators, and should have the option of where their content ends up. By having a category that maps to an aggregator, it’s easy for the author to declare where they want their content will be carried. It also gives the author a chance, when publishing, to be thoughtful about their content and where it’s most pertinent. This is also helpful for the community, because category specific feeds keep each aggregator (the Fedora Planet is just one example) more useful for everyone reading it.

I’ve been using WordPress for a long time for my blogging, and WordPress has  a very easy way to set up categories for content, and provide a specific feed for each one. Interestingly though, both of the contributors I helped in the past week were using Blogspot. As I found out when I made a test Blogspot blog later, Blogspot does not make this process quite as simple or straightforward, although the feature does exist and work fine.

So, armed with that knowledge, I set up a couple extra wiki pages with instructions for how to set up category specific feeds for a WordPress blog, and how to do the same thing for a Blogspot (or Blogger) blog. I also linked these pages to the general instruction page for the Planet. Hopefully, these pages will be useful to contributors adding themselves to the Fedora Planet. Even if you’re already on the Planet, if you’re not familiar with the process of categorization or labeling, you might find these pages helpful.

Note that none of the above information is meant to stop people from discussing topics relevant to our community, but not specific to Fedora, on our Planet. My hope is that using categorization like this will continue to improve the quality of content on the feed, and even help bloggers contribute information to more aggregators.

Respecting impairments.

This tip is a short one, but it applies to a lot of people in the Fedora Project, since we all share responsibilities for writing stuff on the Fedora wiki.

I often see instructions or guidance on the wiki where the writer wants to provide a link. Often those instructions say something like this:

• For more information, see this URL…

Yikes! Hold on a minute here — Fedora, like many other operating systems, has users and contributors who are blind or have severe visual impairments. They may not be able to “see” your link, and in their cases, you’re giving an instruction they can’t possibly follow. This usage is very common in English, so it can be a hard habit to break. I know it’s still an effort for me not to fall into this habit.

Fortunately solving the problem is easy. Use one of the following phrases instead:

• For more information, visit this URL…
• For more information, refer to this URL…

Ah, that’s much better, and now everyone can follow your instructions. It’s easy to fall into the trap of thinking this issue is one of “political correctness” or social niceties, but I believe it’s simpler and less controversial. Fixing this particular usage makes the wiki more accurate. People don’t “see” a reference, they refer to it. In the case of a URL, they can refer to it by visiting it. This particular language fix doesn’t make the wording awkward or bloated, so it’s well worth using the more accurate version here.

Happy wiki-ing!

The extra mile (of track).

Depending on your background, where you live, and your personal predilections, you may or may not be used to any kind of overnight noise. When staying in a hotel, this is a concern for any guest. Even if you frequently stay in hotels, each new location is an unfamiliar environment, and humans just like any animal are predisposed to be less comfortable in a place they don’t know.

Because there are railroad tracks that run nearby the Courtyard Tempe Downtown, the planning group for FUDCon Tempe wanted to do a little extra to make your stay comfortable. We bought disposable earplugs (the kind you can roll and insert) — you can pick up a pair Friday night to help you sleep easier.

It’s impossible to predict whose sleep is bothered by train noise. For example, my family stayed once at a bed and breakfast located right next to the old L&N railroad line where it ran through downtown Henderson, Kentucky. During our stay, my wife didn’t seem to have much problem sleeping through the train noise. (It’s probably fair to say she’d been conditioned over years of my snoring.) On the other hand, it really bugged me and our kids, so we gave them earplugs. Problem solved!

Anyway, just wanted to let people know that we had comfort aid available for anyone who thinks they might need it. If you decide to use earplugs, though, remember to turn your alarm device up so that you can hear it! We’ll be opening FUDCon promptly at 9:00am Saturday.

Insight into Insight.

As you may remember, Gentle Readers, not too long ago I changed roles in Red Hat to work more on management and administration within the platform engineering department, where I work for Tim Burke. Even if you haven’t run into Tim at one of our Fedora Users and Developers Conference (FUDCon) events in North America, you can see him in a recent customer testimonial video he did for the Fedora 14 release, as well as some of the media around the release of Red Hat Enterprise Linux 6.

Tim and I joke about being in a battle royale to see who can be the biggest camera hog in Red Hat media. I have to admit he’s probably pulled ahead this fall season! With my new role, I’m a lot less likely to be on camera saying wonderful things about Fedora, even though I have a lot to say. If you have ideas for how I can remedy this inequity, comments are open.

One of the Fedora related things I’m still involved with is Fedora Insight, a Drupal instance I and a few others are trying to learn and launch. We want the capability to pass on interesting tidbits from the Planet, Fedora Weekly News, and even original media in a simple way.

And we love Drupal, especially because it’s packaged in Fedora and EPEL, and because of its very practical and compatible approaches to licensing (GPL!). However, we could use some help with our work.

Theme

Unfortunately our theme ninja suffered some data loss, and to add insult to injury, the work wasn’t pushed to our upstream repo. But, since we’re quick to find the silver lining in any cloud, we realized things weren’t all bad! In the meantime, the fabulous new Fedora Project web site has been launched. We’d really like our Insight appearance to match the updated look of fedoraproject.org, so we see this as an opportunity, not a setback.

We could use the help of one or more web design ninjas to help us visualize the new theme. Then our coders can turn it into working CSS, just as they’ve done with other web sites. Actually, if you have the ability to do mockups and CSS, you’d be twice as ninja-ish, and we’d bake you twice as many cookies! Basically, the things we are working on now are:

1. Mockups for a site that complements fedoraproject.org
2. A set of CSS files, maybe a subtheme based on Zen or NineSixty, that make that dazzling mockup a reality

Plus, you get to work with really friendly people from around the world. And we may actually send you cookies, no kidding.

Administration

We are learning as we go when it comes to subjects like Drupal Views and CCK. I actually bought a bunch of Drupal books and (slowly, in my shrunken spare time) I’ve been making my way through them to understand the system better. I actually created my own module to allow our Drupal instance to authenticate to the Fedora Account System — and it works well, believe it or not! Drupal has a powerful system of hooks that allow you to customize almost every step of input and output, and I took full advantage of their ample documentation to learn how to use those hooks.

For a lot of what we need to do, we could use more experienced experts to advise us. So if you’re an intermediate or expert Drupalista we could use your participation! In some cases, we might be asking you to teach the uninitiated about how some of the powerful functions of Views or CCK might help us achieve our goals. In others, we might ask for module suggestions or implementation hints. But no matter what, you’d be lending a hand to fellow FOSS champions.

Rather than being quite as directly task-oriented, this work would be more a matter of just camping on our mailing list and maybe responding to an email or two if you find a problem you can help solve. We also hang out on IRC Freenode at #fedora-mktg if you are hip to IRC.

Other stuff

Of course, we’re also looking for good ideas for making use of the platform. To me, that’s not so much about just bringing in random modules that we might think are cool. Instead, it’s looking for ways that Drupal could be made to serve the Fedora community. Then together we can figure out the best, most scalable, most open, and most effective way to make that happen.

The opensource.com staff worked with Acquia on their Drupal instance and I think that site turned out wonderfully. You can see Drupal in use all over the place, including everyone from the White House to Warner Bros. artists (talk about a wide range!). It’s not as steep a learning curve as some content management systems, and has a fantastic community backing it. So we’re looking forward to doing more with it, and we’d love to have others join us on the team.

How we work

We work in an open, transparent way — that means we prefer talking to each other on the list, not private email. Talking to each other publicly is a lot like having a party in a common area. Anyone can come by and become part of the conversation and join the team. By having public conversations we can keep each other informed about what we’re doing and the issues we run into. That also makes it easy for us to help each other, which is what free and open source software is all about.

My friend Mel often says, “If it didn’t happen on the list, it didn’t happen.” Collaborative communication is a powerful tool for teamwork. Even if you’re a little shy, don’t worry — we don’t bite and we are happy to see newcomers! Just ask Peter Borsa, who just joined us. He’s already becoming a valuable team member of our team and I know he would love to have help too.

What to do

Join the logistics mailing list and introduce yourself. It’s that simple! We have regular meetings but you can usually find some of us in our IRC channel, #fedora-mktg. See you there!

Communicate more, not less.

A couple unrelated comments and discussions I saw over the past few days prompted me to write about how the open source way should affect conversations in Fedora. Our modus operandi in Fedora is “default to open.” It keeps us accountable to each other, honest in our assessments, and (hopefully) constructive in our relations with each other.

Most importantly, though, open communication lets others know what we’re thinking and doing, and gives everyone a chance to participate and assist. Without open conversation, it’s infinitely harder to tell what people are up to in Fedora, or any open source work. Sure, you could watch myriad commit lists or RSS feeds, but the trouble with that is there’s no human context around it. And often those automated messages can be confusing or surprising unless someone’s established a prior context around them. The cornerstone of collaboration is communication, and the success of open source depends on collaboration.

Here are some of the opportunities I’ve sometimes observed in open source efforts (not just Fedora) to encourage positive growth toward openness. Sometimes I run into these opportunities personally, and regularly remind myself that increasing communication (rather than simply work output) can often be the best answer.

Do you feel like a lot of work is hanging on you personally? Nothing contributes to burnout quite like when you feel you’re a single point of failure. Making your work more open forces you to confront areas where you’re having trouble, and to ask for help. You can’t be a force for positive change unless you embrace the fact that you can’t do everything yourself. Lydia Pintscher hosted a wonderful article by Asheesh Laroia the other day about how Fedora Design team lead Máirín Duffy avoids this problem by effectively turning “to do” items into open calls to action for the community.

At times it may take more time to tell people about the work than it would to do it. But explaining and documenting are, more often than not, the key to spreading knowledge of, and participation in, an activity. Yes, it is possible no one will help even after you explain and document how to do something. But it’s certain no one will help if you don’t. Building an architecture of participation is to create opportunities for others.

Do you see an area that’s not getting enough attention in your team, even though it’s assigned to someone? The best answer isn’t necessarily to cajole that person, even if you feel like they’re responsible for it. Sometimes the best thing you can do for them is to ask for help on their behalf. There are numerous outlets where you can call out for help: (1) write a blog post that’s carried on one or more aggregators (like Planet Fedora), (2) send status messages on social networking using identifying hash tags about your subject, or (3) make contact with other open source groups outside your project that work on related material, to see if someone’s interested in helping.

Real life happens to all volunteers, and it’s not always possible for them to cover all their responsibilities — volunteer activities frequently take a backseat when available time shrinks, whatever the reason. In Fedora, our teammates are our friends, and we do what we can to make them and our team successful. That might mean helping them find someone to take over for them, if they’re too swamped to follow through.

If you see this happening as a pattern on a team, perhaps it’s worthwhile to examine the scope of the work you’re doing. Do you have enough people to cover it? Consider contracting efforts around a smaller target for a time, while you look for new contributors who are interested in participating. Doing a few things well can be much more rewarding for the team than leaving lots of things incomplete or finishing lots of tasks in a less satisfactory way. (This is also true in the scope of a single contributor — each of us can likely get more satisfaction and pride out of a few jobs well done, rather than many jobs not so well done.)

Are you having substantial conversations privately where the community can’t participate? You could unknowingly be sapping energy from your own team! Remember, one of the reasons we’re involved in free and open source software is that more eyeballs, heads, and hands are inevitably better than a few. Agree on the problem you’re trying to solve first, so you can have a productive conversation about how to solve it. Then make sure you have that conversation in a mailing list, where everyone can see it’s going on, and offer input and assistance.

Community maven/wunderkind Mel Chua has frequently written, “If it didn’t happen on the list, it didn’t happen.” More and more I’ve come to appreciate that wisdom, because frequently the biggest frustrations, confusions, and misunderstandings arise simply because people don’t know what their teammates are thinking or doing. The more open we are in our communications, the less likely we’ll cause those types of problems. Of course, open communication doesn’t equal “no arguments.” But you can choose to have an argument purely about the merits of different types of solutions, rather than arguing about that, plus conflicts over perceived slights, plus issues of hidden agendas, plus… Get the picture?*

Do you feel the need to encourage teammates toward positive transparency? You can help others be transparent by simply asking non-loaded questions in a public forum. Make it clear you’re supportive of their work, and that you’d like to know more about it so you help either by participating, or encouraging others to participate. You don’t even need to mention transparency, since it’s implicit in your public question. In fact, doing so can often be detrimental, with the exact opposite effect of what you intended. If someone communicates with you privately, let them know you’d like to share that with the community, and if it meets with approval, do so promptly and fully. It usually only takes a couple of minor, non-judgmental efforts to help teammates understand the value of “default to open,” so everyone can benefit.

Many times, I find people aren’t transparent simply because they’re tentative. No one wants to be publicly embarrassed, after all! This is why it’s so important to nurture a culture of positivity and constructive behavior in an open source team or project. No one should be afraid to speak up for fear they’re wrong. Being wrong is an opportunity to learn, and not just for the people involved in the conversation. The opportunity also exists for those reading along on the list, or who come across the conversation later thanks to a search engine. Encouraging people toward transparency requires both halves of this strategy to be effective — you can’t simply make requests unless people feel they (not just their open communications) are welcome.

Anyway, these are just some idle thoughts I was having today while exercising and thinking about open communication. I’d love to hear trackbacks and comments from people about their personal experiences and approaches with communicating more openly and transparently, especially specific experiences and how it improved the outcome.

* Admittedly, it’s much easier to defuse those problems later if everyone assumes good intentions, but in my experience, most forms of electronic communication make that quite difficult. But that’s a behavior we can all still aim to practice every day!

Helping the defenders, errata.

Some additional information regarding my last post about helping Red Hat with a Fedora trademark issue: It turns out that materials using the old Fedora logo aren’t necessarily irrelevant. In fact, any evidence of our using the word “Fedora” in connection with our distro before January 30, 2007 is valuable. Check out this email from Pam Chestek, who deals with IP issues in Red Hat’s legal department, for more details.

In a couple personal emails to some helpful contributors, I may have mentioned that only the new logo was useful (thus limiting us to a window from about late 2005 through January 30, 2007. However, that was incorrect, and if you have earlier evidence of our use of the word “Fedora” (whether it has the old logo, the new logo, or simply the word “Fedora” in connection with the Fedora distro), it’s useful!

You can find the mailing addresses you need in this original posting to the advisory-board list.

You can help the defenders.

For years, Red Hat Legal has given free services to the Fedora Project such as counsel on licensing and IP issues like patents and trademarks. Now they’re asking for help from us, the Fedora community.  Here’s a brief snippet of what I wrote to the advisory-board list this morning:

Red Hat Legal provides numerous services as counsel to the Fedora community, including defending Fedora trademarks against possible encroachment. Occasionally, people who have no connection to our community attempt to use the Fedora trademark to signify business efforts that have no connection to the Fedora Project, our distribution, or the Fedora community. Red Hat Legal is currently working on just such a defense. They’ve asked me to pass on a request for assistance in gathering physical evidence of our use of the Fedora logo worldwide prior to January 30, 2007.

Please go read the full announcement to see what you can do to help. For example, there’s a specific issue of Linux Magazine from March 2006 that would be very helpful to have, or other magazines prior to January 30, 2007 that show our current Fedora logo in association with the Fedora Project or distribution. But there are other goods that would be helpful too. The announcement has a list of criteria, what Red Hat Legal specifically needs from you, and the addresses where you can send it.

UPDATE: Check out this updated information about how you can help even more easily. It turns out that evidence of our using the word “Fedora” in conjunction with the distribution at any time earlier than January 30, 2007 is useful, whether our current logo (which we started using in late 2005/early 2006) appears there or not.

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.