I realized that some folks around the Fedora community may wonder why they don’t see me around as often this week and next week. I’m still alive and well, but I’m traveling in the Czech Republic. I’m currently in Brno for some Red Hat departmental meetings. Following that, I’ll be attending the Devconf.cz event. Then I’ll be back in the Brno office for a few days of other work and team meetings. I’ll be back in my home office on Monday, February 15th and around as usual at that point.
The upcoming holiday break seems like a good time to break my silence on the blog. I haven’t had much time for writing of my own lately. I’ve been using most of that time writing and editing for the Fedora Magazine. That’s been quite rewarding, and our readership there keeps growing. But I want to use my own blog to draw the community’s attention to the holiday season. With the holidays come vacation time for me and the Fedora Engineering team.
My good friend John Poelstra is fond of saying, “It’s OK to disappoint people, but it’s not OK to surprise them.” That wisdom is a big reason why I like to set expectations over the holidays.
Working at Red Hat is a fast paced and demanding job. Working full time in Fedora is itself demanding on top of that. These demands can make downtime at the holiday important for our team. At Red Hat, there’s a general company shutdown between Christmas and the New Year. This lets the whole organization relax and step away from the keyboard without guilt or fear. Of course, vital functions are always staffed. Red Hat’s customers will always find us there to support them. Similarly, our Fedora infrastructure team will monitor over the holidays to ensure our services are working nominally, and jump in to fix them if not.
Some people like to spend time over the holidays hacking on projects. Others prefer to spend the time with family and friends. I’ve encouraged our team to use the Fedora vacation calendar to mark their expected “down time.” I encourage other community members to use the calendar, too, especially if they carry some expectations or regular responsibilities around the project.
No matter how you decide to spend your holidays, I hope you have a peaceful and pleasant remainder of 2015, and a successful and prosperous 2016!
I feel like my recent blog posts have all been about openings. But it’s nice to be able to offer them. Each internship on our job site is linked in the bullets below, so you can apply for any for which you feel qualified.
- Software engineering internship – This internship focuses primarily on Python software development. You’ll take designs and build them into widgets for our Fedora Hubs project. You’ll collaborate with our applications team on back-end technology for the community. You’ll also work with our infrastructure team on production deployment. This internship also includes other related projects, not limited to just Hubs. The intern is preferably in Westford, MA for the summer. But that’s not strictly required for a well-qualified candidate with experience working in a global open source project. (In other words, if you can succeed at keeping touch daily with the team as a remotee, don’t let the location throw you.)
- User experience and design internship – This intern will work directly with our designers Máirín Duffy and Ryan Lerch on research and design for Fedora projects such as Hubs. You’ll do user research and work on improving interaction in our web apps and other associated projects. You’ll collaborate with the other interns, our whole development team, and the Fedora community at large. This job is in Westford, MA.
- Web development internship – This intern will work primarily (but not exclusively) on web apps at the front end. You’ll turn design into reality, and streamline existing applications to designer specs to build a more unified project. As with our other internships, you’ll be able to explore and work on other projects too. You’ll work with our design team, the community Websites team and our application developers to create and improve web tools our contributors will use for years. This job is preferably in Westford, MA for the summer. But we’ll consider remote for an exceptionally qualified candidate.
These jobs should end up being quite competitive. So I encourage you to get your application in as soon as you can!
Last year, we were fortunate to have superb interns who produced fantastic results. Meghan Richardson worked on many of the initial designs for Hubs in its early stages, interviewing potential users and then creating the workflows and feel for this new tool. Nate Yazdani worked on statscache, which compiles data from our messaging bus to make it available quickly to other apps, without constantly crushing our data store.
Red Hat is a fantastic company at which to intern, and we pride ourselves on an open and inclusive culture. These are not “fetch coffee” jobs — you’ll work on real problems alongside real experts.
We can’t wait to see what you can do!
Here’s a fantastic opportunity in open source for folks from underrepresented backgrounds. The Fedora Engineering team has an Outreachy internship available December 2015 to March 2016. Applications are being accepted at the Outreachy site. The deadline is 1900 UTC Monday, November 2, 2015.
Are you familiar with Outreachy? It’s a program designed to boost participation in open source by underrepresented groups. My employer, Red Hat, is sponsoring this internship. The Fedora Project, which my team at Red Hat supports, is proud to partner in offering it. This Fedora internship is an opportunity to work directly with our senior software engineers on a major project called Fedora Hubs.
Hubs is an initiative to bring better and more timely information to Fedora’s large community of participants and contributors. Several of our engineers will collaborate with you throughout the internship period on this project. We’ll use Hubs as a foundation for regular, daily mentoring of our Outreachy intern. You’ll use best of breed technologies like Python, Bootstrap, jinja templates, and more. Best of all, you’ll work alongside the team in real time.
You can read more about the internship and qualifications here on our wiki. The page also has general information about Fedora, such as our mission and how we work together.
But this internship isn’t just extending your skills, or working with awesome people. (Even though that’s a great incentive!) It’s also about bringing the open source way to thousands of people. This project lets contributors build sub-communities, or hubs, around their interests. “Standing on the shoulders of giants” is one of the greatest benefits of open source. The same goes for using open source to build communities. It’s a natural fit and a wonderful outcome for a successful internship.
Are you interested in diving deeper into Hubs, to see what this internship is about? Check out this recent blog post from our own Máirín Duffy on the purpose, design, and mockups of the Hubs project.
Here’s my point (TL;DR): Write to be read.*
Where do I get off?
As you read this, don’t forget: I’m speaking from experience as a bad writer of email! I’ve made every mistake I point out here, and most of them countless times over.
I have lots of room to improve as a writer. But in the same way, I’ve improved greatly over time. Years ago, my email messages tended to be long and flowery. They were filled with unnecessary qualifiers, adverbs, parentheticals, and asides. You name the writing sin, I committed it. It made my writing hard to read. That meant I often had to repeat myself in writing, on the phone, or face to face to make a point. Finally I realized this was due to my poor writing habits.
I learned that beautiful writing wasn’t necessarily wordy. Beautiful writing is successful writing. In open source and in business, successful means you get your point across. This is doubly true in an environment where everyone’s drowning in email. While there are certainly occasions that call for florid prose, the office or mailing lists usually don’t. I realized to truly affect colleagues, I needed to think more about writing to their expectations.
What makes for good email
If you work in open source, you probably use mailing lists. A mailing list efficiently shares information equally with many people at once. Your goal in writing to the mailing list is to inform and influence the list readers. Those people are your audience.
But your audience probably doesn’t have an infinite amount of time for email. At least, they don’t if they’re productive. I assume most people want to be productive, in open source or otherwise. They spend no more time on email than necessary. Instead, they spend their time on productive work — coding, creating, testing, doing.
This doesn’t mean email is wasted time. Ideally, email helps you stay informed, and be more productive. Those aren’t the only hallmarks of useful email, but they’re important for our purpose here — understanding our audience. The information you get from email should help you (1) reduce wasted effort, and (2) produce better work. If these things don’t happen, email stops being productive.
But here’s the rub: even an informative email may be unproductive! For example, if email causes you to waste more effort than the improvements it brings, it’s into unproductive territory. I find this often happens when email is hard to read. Here are some reasons why this might happen:
- The information is too dense. If you’re making too many points at once, your writing becomes hard to follow. Sometimes this happens because you haven’t been careful with logic. Sometimes it happens because you haven’t organized your thoughts.
- The information is in fragments. I see this happen on mailing lists when writers make points inline, instead of taking time to write a cohesive reply. After one or two replies, the discussion becomes much harder to follow.
- The information is hard to find. When the language obscures your point, your email becomes unproductive. This can happen sometimes to writers not using their native language. But I find it happens just as often to native speakers, even mechanically “good” writers. That’s the case I concentrate on here.
Are we reading what you’re writing?
Have you ever spent a long time writing a big email, only to get little or no response? (No one loves the sound of crickets.) You probably started out with great intentions. You wanted to be informative and helpful. But you defeated your own purpose with sheer volume of information.
Perhaps you thought, I want to explain myself perfectly. That way, no one will misunderstand my point. But in doing so, you buried the real point in the explanation! Now you’ve made it harder for your busy audience to understand you. It’s arguable whether you even solved the problem you wanted to. After all, concise writing often makes your point more clearly.
In a way, you optimized for a corner case (as a developer might put it). And by doing so, you left your core audience behind. They’re the very people you hoped to inform or influence! Worse yet, over time that core audience becomes less engaged with you, your thoughts, and your writing.
Take me for example: like a lot of people, I’m busy. I’ll bet your core audience members are, too. If it takes me 15 minutes to read your lengthy email to pull two points from it, I may well give up before I succeed.The more time I spend to decipher an email, the more time I lose for more productive tasks. That 15 minutes is a lot of productive time to spend on one message!
But the problem grows worse over time. I usually have expectations about whether email will return the time I invest in reading it. Just like any investment, past returns don’t guarantee future ones. But they do tend to guide strategy. So I may start to set expectations about the value of your email. The more often I run into this problem, the more likely I’ll ignore or defer a future lengthy email you wrote.
Writing to be read
You might think, Why do I need people with limited time or attention to read my email? If you can’t take the time to read, then I don’t need your comments.
This kind of tunnel vision is where some people go wrong. The more you restrict your audience with artificial limits, the less effective you become at achieving your goal. You want to reach as many in your audience as possible, whether they have limited time or not.
Here’s another point: isn’t your time limited, too? Of course it is! We’re all roughly the same in this respect. No one wants their time used unproductively. In other words, most people in your audience probably have limited attention to give email. So your email should be as effective as possible.
This is why you should write to be read. Make your points as simply as possible. Build your points succinctly and concisely. And most importantly, mercilessly self-edit.
Maybe you’re not used to self-editing. Perhaps you tend to spin a stream of consciousness into email. Or perhaps you couch your writing in qualifiers and asides. These bad habits probably limit your audience precisely as I describe above. A lot of smart people may avoid your email as a result. You’ve missed your chance to influence them, or spark new ideas.
In a follow-up post, I’ll show ways to predict whether your writing is likely to be read. I’ll show you how to find some common warning signs and fix your writing when they show up. Believe me, this is like any skill — a muscle you can build through exercise. I’ll show you exercises that help you get read more often and with more accuracy.
* TL;DR = too long; didn’t read.
** I believe it’s not ironic to have a TL;DR in a post about being TL;DR. If you want an explanation, you’ll read on. Hopefully I’ve written that explanation clearly enough you can follow my reasoning easily. If not, I’ve overestimated my right to this soapbox!
Getting started at Flock
Like everyone on the Fedora Engineering team, I was in Rochester for the Flock conference last week. After several flight delays on our direct flight from DCA to Rochester, Justin Forbes, Ricky Elrod, and I finally arrived a little after 9:00pm — about four hours late. Thankfully Josh Boyer came to pick us up at the airport.
Flock had a team of organizers within OSAS (and Josh also assisted throughout). As a former FUDCon organizer, though, I know the value of extra hands showing up to do work. Since old habits die hard, I showed up expecting to help out behind the scenes. That means I didn’t get to see a huge amount of content I was personally interested in. But in return hopefully everyone had a smoother Flock experience, especially speakers.
When I arrived, I reported to Tom Callaway, Ruth Suehle, and Josh. They got the conference rooms opened, and I helped set up the speaker workstations. We worked pretty late, well after midnight. Things were looking a little bleak at that point, with execrable network bandwidth, no projectors, no screens, and no audio for the ballroom.
Fears and worries abate
Nevertheless, the next morning Josh and I got up early and grabbed coffee at nearby Tedward’s. This place was a godsend, although their 7:00am opening time forced us to walk around a bit until we could get in.
We went down to do some additional setup. The organizers had worked with Remy DeCausemaker to get a bunch of loaner projectors from RIT so we’d be ready for the first sessions at 10:00am. (EDIT: According to Remy, Tim Duffy and Dan Schneiderman are the heroes of this particular day; see comments below.) So at least our speakers would be in OK shape. I helped Josh and Tom get everything ready in those rooms, while Ruth made sure registration and other logistics were under control. I missed Matthew Miller’s keynote, but I’d seen at least some of the material previously.
After lunchtime, things continued to drastically improve. The rental projectors showed up, along with small screens for each room and big speakers for the ballroom. The wireless internet improved quite a bit when a switch flip occurred due to our conference starting up. (It was dismal Tuesday night!) We had all the speakers trained on how to record their talks locally, to get around the constrained network bandwidth.
Suddenly things were looking up! Not surprisingly, the Fedora Engineering team dinner that night at The Old Toad was much more enjoyable. Since I wasn’t overly worried about the conference experience for the speakers and attendees any longer, it was easier to relax and enjoy the company of the team. I was so happy that we were able to get together in one place, since we really only get to do that once a year. (Incidentally, our friend Stephen Smoogen was absent from Flock due to family commitments — we missed you, Smooge!)
I continued to monitor speaker rooms most of Wednesday and Thursday. I managed to make it to a couple sessions where I wasn’t sure there would be any senior Fedora leadership around. For example, I attended the Fedora Magazine session by Chris Roberts as well as most of the Fedora Hubs session by Máirín Duffy and Meghan Richardson.
I attended and loved Major Hayden‘s (of Rackspace fame) Thursday keynote on fighting impostor syndrome. It was one of the most practical that I’ve seen on this topic. I feel impostor syndrome is just a fancy way to refer to insecurity, a common trait for conscientious people. But that doesn’t make the strategies Major outlined any less useful or thoughtful. He gave a great talk — engaging and humorous without diluting the material. If you have a chance to invite him to a conference to speak, definitely do so!
I gave my own talk on Remote Ninjutsu on Thursday afternoon. The slides for the talk are here, although the video will be more useful for context. All the Flock 2015 videos are supposed to be available at some point in the next couple of weeks. Stay tuned for announcements about them.
The Thursday night social event at the Strong National Museum of Play was fantastic. It was a great way to blow off steam and enjoy the company of fellow Fedorans. I’m not sure how the organizers managed to find such a perfect venue!
Workshops and Flock wrap-up
On Friday I enjoyed the keynote by Jon Schull of eNable, the community that is flipping the script on prosthetics provision through 3D printing. It was a very moving look at how people are applying open source to make the world better for people in need.
Then the workshops beckoned. Now that I’d finished my Flock duties helping speakers and attendees, I was able to attend several sessions that were relevant to me personally, including the Fedora/CentOS rel-eng joint session, and my own on revamping the Flock software stack.
Once again, the Friday night social event at the George Eastman House was marvelous. It was a beautiful, grand mansion and the tour was quite interesting. I’d love to go back there sometime to see the exhibits I missed!
Flock conferences are always especially great for their hallway track. So many discussions can be had or progressed that way with high bandwidth. The challenge is always to move that discussion to a transparent context if it involves people not present, though. I’ve been seeing many trip reports from people’s blogs about Flock, and resulting list discussions, so I think that process is well underway.
Of course, that means Flock is a very engaging event. It takes a lot of attention and brainpower to shift focus for all those conversations! As a result, by Saturday afternoon I know I was fairly exhausted — in a good way, though. Several other people I know felt likewise, and commented on how well the conference had gone. In fact, I heard a number of comments that this was the best Flock, and even Fedora premier event, yet. The OSAS folks deserve special recognition for pulling off a fantastic conference.
Sunday started with a couple meetings, including with Matthew Miller and Jan Ku?ík, our new Fedora program manager. Then, after seeing a few other friends and colleagues off, I got to the airport. I relaxed in a lounge over beers with Kevin Fenzi, Jan Zeleny, and Stephen Tweedie, before we went to our respective flights. Then after a quick flight home, it was the usual “fun” making my way down I-95 from the airport to home. Monday morning was right around the corner…
Here’s to another great Flock, and to doing it again next year!
The team I manage at Red Hat, the Fedora Engineering team, includes people who work on Fedora system administration, release tooling, application development, and design. We have a job opening for an engineer to work with our infrastructure applications team on some challenging, fun, and forward-looking problems:
- Building and enhancing our tools for producing and shipping cloud images for a variety of providers (experience definitely required!)
- Working with the Fedora Cloud SIG and other community members to resolve issues related to the Fedora Cloud edition and associated tools and processes
- Collaborating with the rest of the Fedora team to automate, automate, automate All the Cloud Things
- Working with the rest of the team on non-Cloud related projects too, such as Fedora Hubs
- Staying abreast of and aligned with work going on throughout Red Hat related to Fedora and cloud technology
- As with all Fedora Engineering jobs, communicating openly and continually with the whole community, and building community around everything you do using open source best practices
Our team uses a lot of Python. We create code upstream that is widely consumable beyond just Fedora, and we deploy our work on both Red Hat Enterprise Linux and Fedora. We do that work openly: collaboration via git repositories, rapid and constant communication via IRC, frequent discussion through our mailing lists, and taking opportunities to gather and build community around our work. Simply put, we love open.
Although the description says the job is in Westford MA, USA, in reality we’re a highly distributed team. While this job is originally conceived as an entry- or journeyman-level engineer in the Westford (or possibly Raleigh NC) Red Hat office, we’re also open to experienced remotees outside the USA. The right candidate is a team player, fully engaged and passionately committed to delivering results with their colleagues, wherever they might be.
Does this sound interesting to you? Go read the full description of the job, and then apply online.
As you might have seen, the Red Hat Summit is happening this week. As usual, I’m here volunteering on the staff, helping with training, the booth, manual labor, and whatever else I can do to assist our awesome event gurus. I love seeing and meeting customers and partners at this event, so I look forward to it every year.
Of course, it comes at a price. I’m not really around on IRC and slow to get to email compared to a normal work week. To make matters worse (or better, depending on your perspective), I’ll be on vacation for about a week and a half following the event. For that reason I put my outage on the vacation calendar on Fedocal.
Now, I don’t think this will unduly impact anything in Fedora. There’s little that depends on me personally since mainly I just try to help things happen for my teammates. But I wanted to make sure the community is aware and knows what to expect.
- Bad drivers at a lower layer (not PulseAudio’s problem)
- Bad hackery in the distro (ohai *buntu)
- People parroting years-old Internet “wisdom” (does that happen?)
But in a well-integrated system, PulseAudio is awesome. That’s definitely the case with Fedora Workstation. That includes Fedora 22, which is what I’m using now.
I’m attending a number of conference calls this week. Lots of them. The last two days have been eight hours of meetings. For example, today I’m at a Fedora Hubs workshop with fellow community members. I usually use my laptop to attend these conference calls. I use it with a USB headset attached. But having a headset on for that long is uncomfortable.
I also have a desktop computer in my office hooked to a big speaker set. So I use PulseAudio to route sound from my conference calls to those speakers. Now I don’t have to wear a headset to listen in.
I do this using the paprefs and pavucontrol utilities. I find these utilities very useful for more audio control. I can watch and move streams, all though an easy, comfortable GUI.
Thanks for the memory, PulseAudio
But that’s not all!
I was in the conference call, but there were updates available on the desktop computer. I decided to see what happened when I rebooted to get the updates. (Since my laptop was on the call, it wasn’t a problem.) I restarted the desktop, and the sound automatically moved back to the laptop speakers! That was cool — I didn’t lose any of the conference.
But it got better. After updates finished and the system restarted, I logged in. The sound automatically went back to the desktop speaker system! I was really impressed.
PulseAudio can track where audio streams are going, and send them back to the original devices when restarted. I love this feature! I remember the early days of Linux audio. It seemed like every single operation was hit-or-miss. I’m glad I don’t have to mess around with the system at that level anymore. I can just concentrate on my tasks, and things Just Work(tm).
Are you (1) coming to Flock 2015; (2) located, or planning to be, in the Boston, MA or Westford, MA area; and (3) interested in taking a free, power and wifi-equipped bus if offered?
If so, then pre-register by 1900 UTC Friday, June 5, and make sure you indicate in your registration you are located in the Boston/Westford area. I’ll collect the final number of these signups on Friday afternoon US/Eastern time. We’ll use that number to determine whether or not it’s economical to book the bus.
The announcement about the bus will be made next week, so there will be plenty of time to make appropriate travel plans either way.