todo.txt

1 Comment

Reposting from an email I sent a while back:

As several people have asked about my todo list within the last 2 weeks, I thought I’d share the goodness with everyone.

I’ve been using todo.txt for about a year now. http://todotxt.com/

Don’t let the website fool you. todo.txt isn’t (primarily) a gui app, or a phone app. The todo list is in a plain text file. There’s a dozen different tools that you can use to manage it, but I just use the command line:

t ls – what’s in my list?
t add ITEM – Adds ITEM to my todo list
t pri ## A – Makes item ## priority A
t do ## – Marks item ## as done, moves it to DONE list for later reference
t ls blarg – Lists todo items that match ‘blarg’
t lsp A – Show me all the things that are priority A
done – An alias to ‘cat ~/Dropbox/todo/done.txt’ which shows me what I’ve done most recently

If you happen to store your todo list in your Dropbox directory, you can then also use the free Android app to manage your todo list from your phone. (I’ve heard it also work with google drive, or owncloud, or a variety of other things.)

As someone who has used every possible todo list out there, including a dozen issue trackers, and writing a few different todo list webapps, sticking with a single tool for a whole year is unprecedented. Being able to work from the command line made all the difference for me, since that’s where I always am anyways.

OpenStack PTG, trip report

last week, I attended the OpenStack PTG (Project Teams Gathering) in Atlanta.

Even more in depth: PTG info at https://www.openstack.org/blog/2016/05/faq-evolving-the-openstack-design-summit/

TL;DR:

1) This is a hugely productive event, with project teams getting an enormous amount of work done without the distractions that are usually present at a conference.

2) I remain very concerned about how this event will effect the
character of OpenStack Summit – removing the bulk of the engineers from that event, and making it more product/marketing/sales focused. Time will tell

At the gathering, I did 23 interviews with Red Hat engineers about what they did in the Ocata release. You can see some of those interview on the RDO YouTube Channel. I’m not done editing them all yet, but they will appear over the coming weeks as part of various blog posts, as well as all of them appearing in that YouTube playlist.

I am constantly blown away by the passion, expertise, and
professionalism of the folks I get to work with. Wow.

Anyways, more about the PTG.

I was (and, really, still am) very skeptical about this new format.
Splitting OpenStack Summit into four events rather than two has already had significant impact on travel budgets, not just at Red Hat, but also at other companies involved in OpenStack. A lot of companies, for example, didn’t send anyone to FOSDEM, and we had a hard time staffing the OpenStack table there. Usually people work one shift at the table, but this year several of us worked 4 and 5 shifts to cover all the slots.

I am concerned that splitting the engineers off into their own event
will significantly change the character of OpenStack Summit from being a community-centric, tech-centric event, to more of a sales and marketing event, light on technical depth.

But this event, for what was intended, has already been amazing.
Everyone is commenting on how much is getting done, how much less distracted the team meetings are, how much better the teams are gelling than they have at any previous event. This is a working event, and people are here to get work done. They are meeting all day, every day, working on plans and blueprints, and fighting out agreements on things that would take weeks in email, and everyone seems VERY pleased with outcomes.

So, perhaps the trade off will be worth it. Time will tell. Regardless, Erin Disney and her team put on an amazing event that fulfilled, and exceeded, its goals.

On Wednesday  night, everyone that has ever contributed a patch to RDO was invited for drinks and hors d’oeuvres at the SideBar, and while there the RDO Ocata release announcement was sent out.

We had about 50 people in attendance, who ate and drank up all of my budget in about 2 hours.

Here’s some pictures.

 

Too many beginners

Last weekend at FOSDEM I gave my “Write A Better Manual” talk. I got a question afterwards that I’ve never actually received before:

We’ve done such a great job of attracting new members to our community that it’s causing a problem. Our lead developers are spending all of their time mentoring beginners, and no code is getting written. What do we do?

Once I got over my “I wish I had your problem” moment, we had a great conversation about concrete ways that you can address this problem. And, of course, it is actually a problem, because it can lead to the demise of your project every bit as much as not enough new community members.

Here’s some things that you can do, even if you don’t have exactly this problem:

Turn the beginners into mentors

Someone has just come to your community, and asks a question. It’s one of the questions that you get every day, like “how do I find my IP address?” or “how do I connect to a wireless network?” or “where is the toilet?”

Rather than answering the question yourself, ask the not-quite-beginner to answer it. This does many things at the same time. It saves you the time and trouble of answering. It indicates your confidence that this person is part of the team. It lets this person know that it’s ok for them to start mentoring other people. And the next time the question is asked, you won’t even have to say anything – they’ll just answer it. You’ve taken the first step to making a mentor out of the mentee.

Take shifts

Mentoring beginners is amazingly rewarding, but it’s also exhausting. You shouldn’t have everyone doing it, and you shouldn’t have the same people doing it all the time. Take turns. Even go so far as making a rotation schedule – one week on, 3 weeks off. Your mentors will come back rejuvenated and ready to start up, and will get “off shift” just about the time that it’s starting to be frustrating.

Know when to quit

Even if you don’t take specific shifts, mentors should be told that they can, and should, take breaks. Mentoring is incredibly important, but it’s only part of your “job”. Work on code for 3 hours for every hour you spend answering questions on IRC. Or something like that. You’ll find that if you set yourself a specific quota of mentoring time, you’ll look forward to it more, and you’ll be more effective at it.

If you’re not good at it, don’t do it

Finally, some folks just aren’t that great at mentoring. Either they’re not very patient, or they’re not great at communicating, or maybe they’re just too valuable at writing the code or the docs, and should stick to that.

These people should be encouraged to stick to what they’re good at, because, frankly, some people do more harm than good when it comes to talking to beginners.

Celebrate your problem

But, at the end of it, recognize that most projects would love to have the problem you’ve got. Celebrate your beginners. Bring them along. Eventually, they will “graduate” and become the core of your community.

 

 

Project Leader

I was recently asked to write something about the project that I work on – RDO – and one of the questions that was asked was:

A healthy project has a visible lead(s). Who is the project lead(s) for this project?

This struck me as a strange question because, for the most part, the open source projects that I choose to work on don’t have a project lead, but are, rather, led by community consensus, as well as a healthy dose of “Just Do It”. This is also the case with RDO, where decisions are discussed in public on the mailing list, and on IRC meetings, and those that step up to do the work have more practical influence than those that just talk about it.

Now, this isn’t to say that nobody takes leadership or ownership of the projects. In many senses, everyone does. But, of course, certain people do rise to prominence from time to time, just based on the volume of work that they do, and these people are the de facto leaders for that moment.

There’s a lot of different leadership styles in open source, and a lot of projects do in fact choose to have one technical leader who has the final say on all contributions. That model can work well, and does in many cases. But I think it’s important for a project to ask itself a few questions:

  • What do we do when a significant number of the community disagrees with the direction that this leader is taking things?
  • What happens when the leader leaves? This can happen for many different reasons, from vacation time, to losing interest in the project, to death.
  • What do we do when the project grows in scope to the point that a single leader can no longer be an expert on everything?

A strong leader who cares about their project and community will be able to delegate, and designate replacements, to address these concerns. A leader who is more concerned with power or ego than with the needs of their community is likely to fail on one or more of these tests.

But, I find that I greatly prefer projects where project governance is of the people, by the people, and for the people.

BAHA 5 Power

Back in December I received my replacement hearing device, the BAHA 5 Power.

The photo shows the last three generations of the BAHA. The one on the left i the one I was replacing – the “Intenso”. The one in the middle is, I think, the BAHA 3, which is what I had as a loaner while waiting for the replacement. The one on the right is the 5.

One of the features of the 5, which makes it practically magical, is that in high noise situations it can make it possible to hear voices. I was a little skeptical, but I had the first opportunity to test this on Friday night when I attended a gathering of Asbury Math department alumni. The room was very noisy, and I turned on the “noisy room” setting. For a moment, everything got a lot louder, and then after a few seconds – I presume it had to calculate ambient noise of whatever – the roar  of the crowd lowered, and I could clearly hear the person next to me – professor Ron Welling, who taught me Abstract Algebra back in 1991 or so – and understand his words.

I’m reminded of meeting Vint Cerf, and his wife, in 1996 or 1997. Someone asked him to think back over the technology advances in his lifetime, and say which one was the most amazing. Rather than talking about the Internet, he said that the most amazing, almost magical, was his wife’s cochlear implant, which let her hear and understand speech, after decades of hearing nothing. At the time I had a Xomed Audiant, which was a very early generation of what I have now.

Each generation of this technology gets more amazing. The new one even does Bluetooth! But the voice enhancement and noise reduction is truly amazing. I expect it to make attending conferences much more bearable.

 

Anansi and the Gum Doll (recording)

I haven’t done these in a long, long time, but I just found a book of Anansi stories on Amazon, and I’ll be posting a few of these a week to practice for the interviews I need to do over the next few weeks.

So, to start, here is ‘Anansi and the Gum Doll’.

Those of you who grew up somewhere other than Africa might recognize this story as being the same as ‘The Tar Baby‘ which is the Uncle Remus version of the same story. Most of the Anansi stories have a matching story in Southern US folklore, although for a variety of reasons most of these have picked up racist overtones over the last 200 years. This is one of many reasons that I prefer the Anansi stories.

 

White Teeth, by Zadie Smith

White Teeth, by Zadie Smith

I just got done reading White Teeth, by Zadie Smith. I read it because I heard her acceptance speech for an award for her latest novel, Swing Time, and she was brilliant.

I recommended the book to my family before I got very far in it, because it was obvious that it was going to be a great read. I love books that are about the complexities of multi-cultural relationships, and “third culture” kids. That is, kids from one culture, living in another, and not truly part of either.

However, it quickly became obvious that it would be … uncomfortable to think of having recommended this book to one’s mother, as the subject material is often somewhat, shall we say, off-color.

Anyways, the story did end up being very beautiful. But like real life, it was also very ugly. And very sad. And very happy. And tragic, and funny, and … all other manner of contradictions. It also had the most beautiful ending of any book I’ve read for the last year, at least.

So, while I do indeed recommend the book, I can’t guarantee you won’t be offended by the subject material, since it does go out of its way to offend on matters religious, ethnic, moral, and political.

The Margin Is Too Narrow