Tag Archives: communication

Not why but why not.

When you’re working on any project that’s Fedora related, and you need to ask questions of a team, the default should be to communicate the question on a public forum. If the conversation isn’t open and transparent, there needs to be a good reason why not. “Default to open” is a pretty well-known mantra in FOSS so this shouldn’t be too surprising or controversial.

There are certainly times where private discussion is warranted. Dispute settling (not to mention disclosure) is often best done privately. If you have to relate personal or security sensitive details of some sort, putting them on a list for eternal archiving may not be appropriate. There are other good examples out there. But in all these cases, it’s important to minimize their impact on public communication. In other words, strive to filter those bits that are best kept private, and keep the rest in an open and transparent discussion.

Every communication of an idea, discussion of implementation details, and canvassing for opinions is a chance to involve others in what you’re doing. If you keep it private, you’re missing out on one of the chief benefits of the open source way — involving others and enabling them to help you as well as themselves. The question is never “Why does this discussion need to be open?” — it’s “Is there any good reason this discussion shouldn’t be open?” And if necessary, as a follow on, “How can I separate the private part of this discussion so it doesn’t keep the rest from being open?”

As the Fedora community continues to grow and spread, we need to continue to teach this aspect to new members — and those who are experienced must lead by example.

Truer words, no. 54.

Good article by my buddy John Poelstra with which I vehemently agree. I’ve been doing something similar with email for a couple years now using offlineimap, synchronizing a few times a day rather than keeping an app open all day or making myself the slave of instant notifications about new email. It’s made a huge difference in my productivity. I’m not perfectly disciplined about this, but more often than not these days, I tend to ask myself before syncing my email, “Is there something coming that you need in order to make progress on your most important task right now?” Often the answer is no.

Sometimes I might be tempted to pull email out of habit, or because I need a break from my current task, or because I’m procrastinating. In all these cases there are better remedies available. Habits can be an indicator of not thinking through what you’re doing, and I’m trying to get better at that in general — so breaking this habit is something I work at constantly. If I need a break, I try to just switch tasks instead, or in the case of overall fatigue, I leave my office for a few minutes to get some perspective. Sometimes a short walk or playing with the family dog lets me come back refreshed and ready to focus. Procrastinating is a special problem that I just try to meet head on, although again I’m not the epitome of doing that well.

Email and communication are vitally important in my job, but they are not the only important thing I need to do in my job. It’s important to keep your tools in perspective and remember that the thing that makes you valuable to your employer is not just your ability to communicate — it’s the ability to communicate something worthwhile. And communicating something worthwhile often requires you to be able to focus and think clearly without yielding to the distraction of your communication tools.

Defaulting to open.

One of the fundamental principles I think our community expects from Fedora is that we default to open wherever possible. In other words, unless carrying out a process in an open and transparent way would be impossible (legal reasons, for example), we should do it. And by and large, we really do.

The primary tool for that openness is communication. You can’t be open without talking with people — in advance, to encourage discussion, debate, and an informed decision; during the process, so everyone involved knows the status, tunes expectations properly, and has an opportunity to contribute; and after the work is done, so the community understands and appreciates it.

In any large organization, it’s easy to miss opportunities for better communication. The less open the organization is by nature, of course, the more often that happens. But it’s a reasonable expectation that a collaborative project like Fedora with the levels of openness and transparency we embrace shouldn’t suffer from this problem too often.

If your team is working on an issue that affects another team, by default your modus operandi should include communicating with that team. The best time to do that is when you’re trying to decide how to move forward. If you’ll indulge some business-speak, making your stakeholders’ or customers’ concerns part of your decision making process is important no matter what business you’re in — even if you’re not a business that defaults to open. In a business that does default to open, even though your list of stakeholders or customers may be a bigger list, it’s still an imperative.

Got a question about why a team works the way they do? Wondering why something happened the way it did? Ask them directly, or cc: their list. Mailing lists are tough animals with which to wrestle, especially if you add several to a thread. But that’s not a reason not to have the conversation. Set a followup or reply-to list, and let people know in the opening message where you expect the further discussion to happen.

Contemplating making a change that affects other teams? Get their thoughts early in the process, to avoid the appearance of throwing something over the wall. (Throwing things over walls is for closed or non-collaborative groups, not us!)

Sure, there’s a gray area between consulting enough people early, and trying to achieve unanimous consensus. Unanimity is great when you can achieve it, but it’s not strictly necessary for everything that needs to happen in a project, especially one that needs to move boldly forward as we like Fedora to do. But that gray area is a wide one, and there’s a good distance you can cover without overly inflicting stop energy on a good idea.

Speaking as a fellow contributor, I’d like to see every team in Fedora continuing to make a concerted effort to talk across team lines. That communication needs to start with your own team of course: minimizing private discussions wherever appropriate; keeping teammates engaged in daily and long-term work; and moving discussions where you need more input and discussion off of IRC and onto your mailing list, just to name a few examples. But just as importantly, when necessary let’s renew our efforts to communicate with our fellow teams, to make sure we’re making good decisions, and that overall we are having a positive effect on each other’s contributions in Fedora.

This post was prompted by a couple instances recently where I saw teams not reaching out for each other to ask questions or give information. I haven’t seen evidence of any widespread trends; in general, Fedora team members do a great job of communicating across teams. These instances were exceptions to the rule, but it would be fantastic if those exceptions never happened at all. (Zero may be an unattainable goal, but that doesn’t make it the wrong goal.) I’m not calling out specifics simply because they wouldn’t change the value of the ideas and practices discussed here.

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.

We love stinkin’ badges.

For a few years now our FUDCons have always included attendee name badges. Often people coming to FUDCon are meeting face to face for the first time with people they know from online interactions. Name badges make it easy to put a face to a name or IRC nick.

At FUDCon Tempe, though, we’ve added a little twist. Name badges this time around will feature a QR Code that includes a little bit of contact information for each attendee. This code can be scanned by certain smartphone apps, so if you meet someone and you’d like to keep in contact later, you can scan each other’s badges to make it easier to do so. The excellent suggestion for using a QR Code came from contributor Juan Rodriguez (nushio), and all-around superstar Ian Weller provided the script to create the badges.

Here’s how the QR Code works:

  • If you included your Fedora Account System (FAS) username in your signup, either with a wiki link or as a comment, we’ve used that to construct the contact information in the QR Code (your @fedoraproject.org email, and your User:Username page on the Fedora wiki).
  • If you didn’t include that information, your QR Code will only indicate the name shown on your badge. It’s still minimally useful, in that you can let someone scan the code to get the spelling of your name correct.

The information on the badge is based on what you made public in the wiki, since we don’t want to just start throwing people’s email addresses around if they haven’t given us one. (If you want to give anyone details beyond your Fedora email or wiki page, you can do that manually.

The badges were printed this weekend using the template Ian set up, and here’s a demo. Hint: if you have a barcode scanning app on your phone, you can probably test my badge directly from your computer screen!

Example QR Code on a FUDCon Tempe badge

We even left a line on the badge for informative or funny comments. Unfortunately in a couple cases these comments were much longer than we could include on the badge. If your comment fell into this category, you may find it truncated or missing on the badge. You can feel free to write it in by hand once you get your badge, but I recommend you avoid writing over the QR Code, so it stays useful. As I mentioned earlier, we were careful not to put any information on the badge you didn’t already provide publicly through the Fedora wiki. But if for some reason you don’t like the idea of this QR Code, you’re welcome to mark it out with a dark marker or pen to render it useless. (That’s a pretty effective opt-out measure.)

We look forward to seeing you at FUDCon, start gearing up your blogs!

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!