Before you write a patch, write an email

April 27, 2012 Community 3 comments

(Originally posted to my non-Perl blog)

I often get surprise patches in my projects from people I’ve never heard from. I’m not talking about things like fixing typos, or fixing a bug in the bug tracker. I’m talking about new features, handed over fully-formed. Unfortunately, it’s sometimes the case that the patch doesn’t fit the project, or where the project is going. I feel bad turning down these changes, but it’s what I have to do.

Sometimes it feels like they’re trying to do their best to make the patch a surprise, sort of like working hard to buy your mom an awesome birthday present without her knowing about it. But in the case of contributing to a project, surprise isn’t a good thing. Talking to the project first doesn’t take away from the value of what you’re trying to do. This talking up front may even turn up a better way to do what you want.

There’s nothing wrong with collaborating with others to plan work to be done. In our day-to-day jobs, when management, clients and users push us to start construction of a project before requirements are complete, it’s called WISCY, or Why Isn’t Someone Coding Yet? As programmers, it’s our job to push back against this tendency to avoid wasted work. Sometimes this means pushing back against users, and sometimes it means pushing back against ourselves.

I’m not suggesting that would-be contributors go through some sort of annoying process, filling out online forms to justify their wants. I’m just talking about a simple email. I know that we want to get to the fun part of coding, but it makes sense to spend a few minutes to drop a quick note: “Hey, I love project Foo, and I was thinking about adding a switch to do X.” You’re sure to get back a “Sounds great! Love to have it!” or a “No, thanks, we’ve thought about that and decided not to do that”. Maybe you’ll find that what you’re suggesting is already done and ready for the next release. Or maybe you’ll get no reply to your email at all, which tells you your work will probably be ignored anyway.

I’m not suggesting that you shouldn’t modify code for your own purposes. That’s part of the beauty of using open source. If you need to add a feature for yourself, go ahead. But if your goal is to contribute to the project as well as scratching your own itch, it only makes sense to start with communication.

Communication starts with understanding how the project works. The docs probably include something about the development process the project uses. While you’re at it, join the project’s mailing list and read the last few dozen messages in the archive. I can’t tell you how many times I’ve answered a question or patch from someone when I’ve said the same thing to someone else a week earlier.

Next time you have an idea to contribute a change to an open source project, let someone know what you’re thinking first. Find out if your patch is something the project wants. Find out what the preferred process for submitting changes is. Save yourself from wasted time.

We want your collaboration! We want you your help! Just talk to us first.

Perlbuzz news roundup for 2012-04-16

April 16, 2012 Community, CPAN, Perl 5 No comments

These links are collected from the
Perlbuzz Twitter feed.
If you have suggestions for news bits, please mail me at

  • K=R=P (Kindness = Repeat business = Profit) says @tom_peters. I say that for open source, K=U=G+S, Kindness = Users = Growth+Success.
  • You probably don’t want to be using use_ok() (
  • Interpolate, concatenate or join? (
  • Quick-n-dirty tool to send messages to HipChat (
  • Painless RSS processing with Mojo (
  • RT @chromatic_x If you use SQLite for your CPAN distribution’s tests, consider an in-memory database. Helps parallelism/Reduces disk IO.
  • Explaining web programming via Plack (
  • Common Perl pitfalls (
  • Test::WWW::Mechanize adds scraping functions (

Perlbuzz news roundup for 2012-04-09

April 9, 2012 Code craft, Community, CPAN, Perl 5, Perl 6 No comments

These links are collected from the
Perlbuzz Twitter feed.
If you have suggestions for news bits, please mail me at

  • The Perl Unicode cookbook (
  • bdfoy’s got some ideas for code (
  • How @rjbs spent his Perl QA Hackathon (
  • The homepage for ack is completely redesigned. Hooray for open source, making up for my lack of design skillz. (
  • Tricks to compiling mod_perl 2 to OS X Lion (
  • Have you seen perl-reversion? (
  • Using WWW::Mechanize and mech-dump to get my scratchy 45s (
  • DBD::Firebird releases v1.0 (
  • Recap of the Perl QA Hackathon (
  • Reading about what people are working on = happy. (
  • Whatever task you have, it’s probably already on CPAN (
  • The Perl Foundation wants to give you money to work on Perl (
  • More niche modules, “incredibly useful for about 5 people on earth”: (
  • Did you know prove has –shuffle to run tests in random order? Has randomizing tests uncovered bugs for you?
  • MetaCPAN has a new logo (
  • RT @dukeleto This is a huge step forward in #perl dependency management: “carton bundle” support! (
  • RT @aaronlerch Some devs think “I’ll just copy and paste this code block.” Now you have two problems. Now you have two problems.
  • Would love to see this Perl::Critic talk (
  • “The Python site talks about the value the reader gets out of Python, while the Perl site talks about Perl” (
  • How to get ahead in open source: Wear sunscreen. (
  • Help Open Source Bridge select session proposals (
  • MetaCPAN at the QA hackathon (
  • Perl Foundation helps fund critical Perl 5 dev (

On being a snot

February 14, 2012 Community No comments

In response to all the kerfuffle about [Why I Left Perl]( because of strict dogma about strict, Chris Prather wrote a [well-reasoned discussion]( about how there are no standards for what “best practices” is in Perl. One of his key points was:
> *The big reason for leaving Perl, though, was people in the Perl community, who had become annoying scolds.*
I agree 100%, and I’ve long been frustrated with people who do that, who take a dump on others for not doing it the right way. I’ve tried to get people to see why that’s so damaging to community, and along the way there have been times I’ve been that annoying scold. And for that I apologize. If you’ve ever felt that I talked down to you, or scolded you for something, I’m sorry. Nobody deserves that.
I try to keep the [words of the wise Larry Wall]( in mind at all times:
> *There ain’t nothin’ in this world that’s worth being a snot over.*
As far as I’m concerned, there is no person, no matter if he’s a newbie or been around for years, that deserves to be insulted. It doesn’t matter if it’s “for his own good” or “the good of the community”, it’s never the right answer to insult or degrade someone. That’s why I apologize if you’ve ever felt talked down to. Nobody deserves it, even if the cause is right, and I thank Chris’s post for reminding me.
A while back [I posted about the acronym THINK]( that asks if what I’m about to say is:


Unfortunately, it’s always the Kind that falls first online. It gets left behind in the pursuit of Intelligent. Maybe I should write something that makes “THINK” pop up whenever a blog comment box opens up.
For more on the whole “how poorly we treat newbies”, I also suggest reading “use strict ‘answers'”.

Perlbuzz news roundup for 2011-12-19

December 19, 2011 Code craft, Community, CPAN, Perl 5, Perl Foundation No comments

These links are collected from the
Perlbuzz Twitter feed.
If you have suggestions for news bits, please mail me at

Perlbuzz news roundup for 2011-11-21

November 21, 2011 Advocacy, Community, CPAN, Perl 5 No comments

These links are collected from the
Perlbuzz Twitter feed.
If you have suggestions for news bits, please mail me at

Perlbuzz news roundup for 2011-11-07

November 7, 2011 Code craft, Community, CPAN, Perl 5, Perl 6 2 comments

These links are collected from the
Perlbuzz Twitter feed.
If you have suggestions for news bits, please mail me at

Mark Jason Dominus on giving fish

November 2, 2011 Community, Opinion 4 comments

By Mark Jason Dominus, from a talk in 2003, reprinted here with permission. Sadly, it’s still relevant today.

The #perl IRC channel has a big problem. People come in asking questions, say, “How do I remove the first character from a string?” And the answer they get from the regulars on the channel is something like “perldoc perlre“.

This isn’t particularly helpful, since perlre is a very large reference manual, and even I have trouble reading it. It’s sort of like telling someone to read the Camel book when what they want to know is how to get the integer part of a number. Sure, the answer is in there somewhere, but it might take you a year to find it.

The channel regulars have this idiotic saying about how if you give a man a fish he can eat for one day, but if you teach him to fish, he can eat for his whole life. Apparently “perldoc perlre” is what passes for “teaching a man to fish” in this channel.

I’m more likely to just answer the question (you use $string =~ s/.//s) and someone once asked me why. I had to think about that a while. Two easy reasons are that it’s helpful and kind, and if you’re not in the channel to be helpful and kind, then what’s the point of answering questions at all? It’s also easy to give the answer, so why not? I’ve seen people write long treatises on why the querent should be looking in the manual instead of asking on-channel, which it would have been a lot shorter to just answer the question. That’s a puzzle all right.

The channel regulars say that answering people’s questions will make them dependent on you for assistance, which I think is bullshit. Apparently they’re worried that the same people will come back and ask more and more and more questions. They seem to have forgotten that if that did happen (and I don’t think it does) they could stop answering; problem solved.

The channel regulars also have this fantasy that saying perldoc perlre is somehow more helpful than simply answering the question, which I also think is bullshit. Something they apparently haven’t figured out is that if you really want someone to look in the manual, saying perldoc perlre is not the way to do it. A much more effective way to get them to look in the manual is to answer the question first, and then, after they thank you, say “You could have found the answer to that in the such-and-so section of the manual.” People are a lot more willing to take your advice once you have established that you are a helpful person. Saying perldoc perlre seems to me to be most effective as a way to get people to decide that Perl programmers are assholes and to quit Perl for some other language.

After I wrote the slides for this talk I found an old Usenet discussion in which I expressed many of the same views. One of the Usenet regulars went so far as to say that he didn’t answer people’s questions because he didn’t want to insult their intelligence by suggesting that they would be unable to look in the documentation, and that if he came into a newsgroup with a question and received a straightforward answer to it, he would be offended. I told him that I thought if he really believed that he needed a vacation, because it was totally warped.

Mark Jason Dominus has been doing Perl forever. He is the author of Higher Order Perl which belongs on the shelf of every Perl programmer. Follow him on Twitter at @mjdominus.

Perlbuzz news roundup for 2011-10-31

October 31, 2011 Community, Conferences, CPAN

These links are collected from the
Perlbuzz Twitter feed.
If you have suggestions for news bits, please mail me at

There’s only one useful way to handle your detractors

October 6, 2011 Advocacy, Community, Opinion 4 comments

This is a repost from my main blog, but it applies to all of us working on Parrot and Perl 6. Keep on keeping on, ignore the trolls, and keep moving forward to completing the vision.
Here’s a Reddit/Slashdot/whatever thread that never happened:

Internet crank on Reddit: “Hey, Steve Jobs, I guess that new iPad looks cool, but I think iPad is a stupid name, it makes me think of sanitary napkins.”

Steve: “Yeah, well, here’s why we called it that. (Long explanation justifying his choices)”

Crank #2: “Well, why didn’t you call it the iTablet? I think that would have been a good name. What does everyone else think?”

Crank #3: “What does it have to be iAnything? I’m tired of the i- prefix.”

Steve: “We thought about that, but … (More explanation about his choices)”

Crank #1: “And really, isn’t it just a bigger iPod Touch? I would never carry that around with me. And come on, you’re just trying to redo the Newton anyway LOL”

Steve: “My logic behind the iPad is (vision, business plan, blah blah blah)”

Can you even imagine Steve Jobs in this sort of time-wasting and emotionally draining tit-for-tat in a thread on Slashdot? On reddit? In some blog’s comment section? Of course not. Justification of his plans would take away from the amazing things that he needed to achieve.
Naysayers are part of every project. How many people do you think pissed on Jimmy Wales’ little project to aggregate knowledge? Nobody’s going to spend their time writing encyclopedia entries! And yet there it is. On a personal level, if I listened to everyone who thought I was wasting my time improving on find + grep you’d never have ack.
We all have to persevere in the face of adversity to ideas, but there’s more than that. We need to ignore our detractors. Despite how silly and time-wasting it is to argue your motivations and reasons for undertaking a project, many of us feel compelled to argue with everyone who disagrees with us. I suggest you not waste your time.
On the Internet, the attitude is “Why wasn’t I consulted?” Every anti-social child (measured by calendar or maturity) with a keyboard thinks it’s his responsibility to piss on everything he doesn’t like. They’ll be there always. You can no more make them go away than you would by arguing with the rain.
What are you hoping to achieve by arguing with someone who doesn’t like your project? Do you expect that he’ll come around to your way of thinking? It won’t happen through words.
Not only does arguing with your critics waste your precious time, but it tells them, and every other crank reading, that you’re willing to engage in debate about what you’re doing. Don’t encourage them! Let them find a more receptive target.
I’m not saying that factual misstatements need to be ignored. If something is provably incorrect, go ahead and counter it with facts. However, most of the time these message thread pissing wars get down to “I would not be doing what you are doing, and therefore you are wrong for doing so.”
The only thing that has a chance of silencing your critics is success at what you do. Arguing with the naysayers doesn’t get you any closer to that.