• Every day, we contribute to shaping our community

    [Masak's recent post on use.perl.org](http://use.perl.org/~masak/journal/39090), called "How can we scale kindness?", boils down my frustration with anti-helpful behaviors like geek pissing contests, [telling newbies "RTFM"](http://perl.plover.com/yak/12views/samples/notes.html#sl-33) and [calling people "fuckhead"](http://petdance.com/perl/geek-culture/). > Every day, we contribute to shaping our community. By extension, I think it's fair to say that allowing anti-helpfulness to stand unanswered is part of shaping our community. I might even expand it to say: > Every day, through action and inaction, we contribute to shaping our community. I understand that every community will have jerks, and the Perl community is no different. However, it's possible to balance the bad signal with good. Answering hostile behavior doesn't have to be, and in fact shouldn't be, a flame war. Instead, bypass the damage of the hostile participants and address the topics as they should be. If a newbie in IRC asks a "dumb" question, and is beaten down by the regulars in the channel, go ahead and answer the question for him. It's a far better response than ragging on the beaters. How do you handle the negative in the Perl community?
  • Attention all Vim-using Perl programmers

    If you use Vim for your Perl programming, here's a new project and mailing list you might be interested in. A few months ago I became the maintainer of the syntax/perl.vim file that comes with vim. I started a [github project for it](http://github.com/petdance/vim-perl/tree/master) for maintaining the perl.vim file, and for starting to get a perl6.vim file together that could be put into the vim core as well. There are a couple of versions of perl6.vim and I need to make sure we get the latest/greatest to Bram for inclusion. Now that github added capability for issue tracking, there's now a [vim-perl issue tracker](http://github.com/petdance/vim-perl/issues), and I created a [Google group for vim-perl](http://groups.google.com/group/vim-perl) as well. This project + group are not intended to be just about the .vim files. I want to discuss all aspects of using Perl and Vim together, so join in and share your tips and ideas. If there are any Emacs, Eclipse, etc equivalents, let me know so I can post about those, too.
  • What happens at a hackathon?

    Piers Cawley has a great article explaining [what happens at a hackathon](http://www.h-online.com/open/What-happens-at-a-hackathon--/features/112997), using the Perl QA Hackathon in Birmingham as the example. This is the second great article that Piers has written about Perl and its culture for the general masses, after ["Healthcheck Perl"](http://www.h-online.com/open/Healthcheck-Perl-The-Perl-Future--/features/112388) back in January. Thanks, Piers! The hackathon was a who's who of QA folks: Ricardo Signes, Michael Schwern, Andy Armstrong, Curtis Poe, Adrian Howard, David Golden, Michael Peters, Jon "JJ" Allen and Antonia Mayer. Makes me wish I'd been there! Ricardo has his own write-ups on the hackathon at ["An overview of the Metabase"](http://rjbs.manxome.org/rubric/entry/1742) and ["Look back at the Perl QA Hackathon"](http://rjbs.manxome.org/rubric/entry/1741).
  • Celebrating women in Perl on Ada Lovelace Day

    There have been a number of posts today for Ada Lovelace Day, honoring women in computing. * Tim O'Reilly posts about [the women at O'Reilly](http://radar.oreilly.com/2009/03/ada-lovelace-day-at-oreilly.html) who make things happen. If it weren't for Edie Freeman, we wouldn't think of the camel and Perl. * Nat Torkington highlights three women, including Perl's own Allison Randal, in [Ada Lovelace Day ABC](http://radar.oreilly.com/2009/03/ada-lovelace-day-abc.html). Brenda Wallace gets a shout-out as well. Brenda's not known for public Perl contributions, but she's well-known as a driver of the Perl community in New Zealand. * Casey West honors Audrey Tang, who should need no introduction. [Casey's blog post](http://caseywest.com/2009/03/24/ada-lovelace-day-audrey-tang/) gives the briefest of summaries of some of Audrey's amazing achievements. * Hundreds more at [http://findingada.com/](findingada.com) I'd like to call out a few more Perl people while we're at it: * Skud (Kirrily Robert) who helped me start Perlbuzz, is at the top of the list. If you've ever used [WWW::Mechanize](http://search.cpan.org/dist/WWW-Mechanize) instead of dealing with the inner workings of LWP, thank Skud. * Jacinta Richardson is half of [Perl Training Australia](http://perltraining.com.au/). Together with Paul Fenwick, they are a huge force in the Perl community in that corner of the world. My understanding is that their marvelous [Perl Tips newsletter](http://perltraining.com.au/tips/) comes from her. * Elaine Ashton was instrumental in getting the CPAN going, and keeping it going today. * Ricardo Signes rattled off names to me: [Jess Robinson](http://search.cpan.org/~jrobinson/), Karen Cravens, [Liz Cortell](http://www.slideshare.net/zrusilla/pulp-perl), [Beth Skwarecki](http://bethskwarecki.com/about/) and "[Elizabeth Mattijsen](http://search.cpan.org/~elizabeth/) who is TOTALLY badass." Perhaps he'll comment to fill in the details. I'd like to also steal a bit from Tim O'Reilly's article as well. He said:
    My first hat tip has to go to my wife, Christina O'Reilly. She's a playwright and choreographer, not a techie. But if you've been influenced by me, you've also been influenced by her.... [S]he's been part of everything I've ever done, in the same way that Elizabeth Barrett Browning said of her husband, Robert Browning: "What I do and what I dream include thee, / As the wine must taste of its own grapes"
    In the same way, let's remember our spouses, partners, and other special women in our lives, starting with Larry Wall's wife Gloria, who you've probably seen at Perl conferences keeping things together for the clan. Whenever you see the work of someone like Josh McAdams, Ricardo Signes, or Casey West, you've got a Heather McAdams, Gloria Signes and Chastity West, and the rest of their families, supporting them. That's community support to remember. Please add your praise of the women of Perl I've forgotten or don't know in the comments below.
  • How to write an announcement for your software project

    In my job as editor of Perlbuzz, I get email all the time asking me to run announcements about all sorts of Perl-related things. They're usually announcements of a new release of some module, or something about an upcoming conference. And usually I don't run them, because they violate the first rule of announcing something: An announcement that says "PerlWhacker v1.5.3 has been released" **is not interesting** to anyone but a small handful of people. The most important part of being interesting is that your announcement has to have an angle. ## Without an angle, there is no reason for the reader to read past the headline The angle is the part of the story that says "This is why this is interesting to you, the reader." There has to be a reason that a story is interesting, not simply a recitation of facts. There has to be a hook, a reason for the potential reader to see a headline, or maybe the first paragraph, and say "Huh, I'd like to read that." Here are some examples. * **Bad**: "Devel::NYTProf version 2.04 got released, here's the change log." **No angle**, very boring, unlikely the reader will pay any attention to the story, if she even clicks it in her feed reader. * **OK**: "Devel::NYTProf v2.04 got released, and it now uses 90% less disk space by using the Zlib compression library." **Sort of interesting**, because the reader can say "Huh, that sounds like a cool hack. Still, what's the effect on the reader? * **Good**: "Devel::NYTProf v2.04 got released, and it uses 90% less disk space, because Nicholas Clark was trying to run NYTProf on the entire Perl test suite and ran out of disk space, and he worked with Tim Bunce on a patch." **That's an angle** because it tells a story that the reader can relate to. * **Great**: "Devel::NYTProf v2.04, and it uses less space, because Nicholas Clark was running the Perl test suite against it, and here's a link to the findings from that research." **Bingo**! ## Assume that the reader knows nothing about what you're announcing. Finally, you must assume that the reader doesn't know what you're talking about. Most of the announcements I see are announcing to a small group of people who are aware of what is being announced, simply notifying that group that something has happened, excluding the readers not yet in the know. I'm going to pick on the announcements for Summer of Code, both because they're excellent examples of how to exclude readers, and because I want the GSoC to succeed wildly. That's why I took the time to [revamp the announcement](http://perlbuzz.com/2009/03/get-paid-for-working-on-perl-projects-in-google-summer-of-code-2009.html) when I ran it last night. The original announcement that Eric Wilhelm ran is this:
    The Perl Foundation has been officially accepted into the Google Summer of Code 2009 program as a mentor organization!

    Hopefully some of you have identified some potential students already. Now we need your help getting them to submit their proposals.

    http://leto.net/dukeleto.pl/2009/03/tpf-accepted-to-google-summer-of-code-2009.html

    The student application period begins Monday, March 23rd and runs through April 3rd. (Students note: you can edit your proposal throughout that 11-day period -- getting it started early and talking to potential mentors greatly increases your chances vs throwing it over the wall at the deadline.) See this page for details:

    http://code.google.com/soc/

    Interested students and potential mentors, please read the GSoC info on the Perl wiki:

    http://www.perlfoundation.org/perl5/index.cgi?gsoc http://www.perlfoundation.org/perl5/index.cgi?gsoc_2009_projects

    If you're interested in mentoring or have a good project suggestion, now is the time to get your info up on the wiki so students will know about your code and where to find you.

    Eric has done a ton of work for GSoC this year and last, and it's safe to say that the Perl involvement GSoC wouldn't be as great, in fact might not even exist, without Eric's work, so this is no knock on Eric. But this announcement has some huge failings, and it leaves questions in the mind of the reader who doesn't know what GSoC is. * What is Google Summer of Code? * Why is it interesting that TPF is a mentor organization? * Why do I care about it? * What's in it for me, the reader? * What is a student? * Why would a student want to join GSoC? * What is a mentor? * Why would someone want to be a mentor? In short, Eric wrote the announcement for the people who already know what GSoC is, and excluded the other 90% who don't. [Jonathan Leto's announcement](http://leto.net/dukeleto.pl/2009/03/tpf-accepted-to-google-summer-of-code-2009.html) has the same failings. It makes sense why Eric and Jonathan wrote they way they did. They've been busting their asses for weeks (months?) working to set things up. They've been working inside the echo chamber of other people that are involved in the project. The parts of the project in the forefront of their minds are the details like how to sign up and how to write a proposal. However, to someone unfamiliar, it's noise until he knows the overview. ## Get people to read your words Whether it's an announcement of your software, or a resume, or a posting in your blog, you have to give the reader a reason to read what you've written. When writing, we tend to focus on the details of the text, expecting that the reader will consume our every word. Problem is, people aren't like that. We skim. We read titles. If it's not interesting we move on. In [my book on job hunting](http://www.pragprog.com/titles/algh/land-the-tech-job-you-love), I hammer home the idea that without a compelling summary at the top of your resume, the reader is not going to spend much time digging the good stuff out of your bullet points at the bottom. It's the same rule with announcements about your software project. Next time you're going to announce something, show the announcement to someone who is not involved with the project, maybe a co-worker or your spouse. Ask him or her to explain what you're announcing. Try to understand how your article sounds to someone unfamiliar with it. Your project's success may rely on it.