Recently in Community Category

Perlbuzz news roundup for 2012-10-15

| No Comments

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

Perlbuzz news roundup for 2012-10-09

| No Comments

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

Perlbuzz news roundup for 2012-09-17

| No Comments

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

Perlbuzz news roundup for 2012-08-27

| No Comments

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

Perlbuzz news roundup for 2012-07-30

| No Comments

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

Perlbuzz news roundup for 2012-07-23

| No Comments

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

Perlbuzz news roundup for 2012-07-09

| No Comments

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

Perlbuzz news roundup for 2012-06-25

| No Comments

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

Perlbuzz news roundup for 2012-06-18

| No Comments

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

  • Perl for Big Data: "Hadoop is overrated. Come see what modern Perl can do." (blog.yapcna.org)
  • Why I use Perl: Reliability (modernperlbooks.com)
  • Any language would be improved if it had Perl's testing and library culture. (news.ycombinator.com)
  • YAPC::NA 2012's legacy for future organizers (blogs.perl.org)
  • Evolving tests and code in small steps (modernperlbooks.com)
  • mod_perl 2.07 released, works w/Perl 5.16 (blogs.perl.org)
  • HTML::Tree 5.00 fixes memory leak problems (blogs.perl.org)
  • "Our meritocracy is broken." -- @schwern at #yapcna
  • "The people who want to use Perl are those we should be building the community for." -- @schwern at #yapcna
  • Larry Wall had to hack a 25-year Perl ribbon at #yapcna. (twitter.com)
  • perlybook.org generates epub/mobi ebooks of Perl module documentation.
  • Ovid's "Beginning Perl" available online for free (blogs.perl.org)
  • "There are no stupid questions" says Mojolicious' @tempire. "Nobody will be mean to you in #mojo IRC channel." Bravo for publicly stating.
  • When subgroups of your community find it necessary to say "We will not be mean to you," your community has a Big Problem.
  • Arduino/Dancer-enabled mobile-enhanced door (blogs.perl.org)
  • Boston Ruby works to be beginner-friendly (openhatch.org)
  • Reflections on YAPC::NA 2012 (blogs.perl.org)
  • How @mithaldu put the YAPC videos on YouTube (blogs.perl.org)
  • Rakudo Perl 6 on Android (blogs.perl.org)
  • YAPC::NA recap from Sawyer_X (blogs.perl.org)
  • Calculating technical debt with Perl::Critic (elliotlovesperl.com)

Before you write a patch, write an email

| 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.

« Code craft | Main Index | Archives | Conferences »