WEB Advent 2008 / Less Whining, More Coding

How many times have you heard or seen someone griping about PHP? Maybe the documentation was wrong, or they couldn’t figure out how to install it, or maybe they just didn’t like the way something worked. You see whining everywhere: forums, blog posts, mailing lists, even on Twitter! Well let me tell you what to do about the problem.

First, stop whining. Really, shut up. You’re not helping.

Second, start coding. PHP—both the project itself and the community—needs you.

Without volunteers, there is no PHP. Although no one “owns” it and therefore no one can kill it, projects and languages die every day. Take a look at the dead projects on SourceForge sometime. However, reports of the death of PHP have been widely exaggerated. PHP is moving forward, but it could move a lot faster with more useful help. There are never enough dependable volunteers for an open source project, especially one the size of PHP. Any Open Source project starts to die the moment it stops moving forward, and the only way to do that is with fresh blood. People get busy, get burnt out, start companies, and have kids. We always need new people with time and enthusiasm. Just like any project there are a huge number of things that have to be done, and you don’t have to be a C guru to get involved. From bug triage to writing tests to writing docs to helping with websites to answering questions on mailing lists, there is something that everyone can do to lend a hand.

So how do you become a part of the solution instead of the problem? Getting involved in PHP, like most open source projects, requires two things; trust and hard work. But there are some general rules about working in open source that you need to understand before jumping into the fray.

1. Don’t be a flake. If you offer to help, follow through. Some of the ways you can help the community might take a lot of time, so don’t volunteer for more than you can handle. I would recommend starting small and if you enjoy helping, you’ll discover your involvement snowballs.
2. Be respectful. Don’t demand hand-holding; try to figure stuff out on your own first. Remember there are very few people who get paid to develop PHP, most have full time jobs and life as well. Ask nicely, be patient. Document anything new you learn, even if it’s in a blog post (although we’d prefer it to be in the manual somewhere), so the next person who wants to come on board can find the information.
3. Work in the open. No “Code Hoarding.” You don’t have to use PHP’s repository (we are moving to subversion however, which should make life better) but for goodness sake make your code public somewhere for whatever you work on! Open lines of communication via mailing lists, IRC, or whatever floats your boat are also a must.
4. Please don’t abandon work. If you are in the community and find yourself needing to limit your involvement, well that’s life. Tell people you’re too busy and need to cut back. And at the very least make sure there’s enough documentation and information lying around that someone could pick up the torch in a reasonable amount of time.

Are you scared yet? If you’re not running in the other direction I have a list of concrete ways you can help the PHP community, and none of them require a degree in rocket science (or even computer science). There are distinct “areas” of involvement with PHP as a project and I’ve listed them here in a rough approximation of time and or brains and or sanity (or lack thereof) needed for helping with each position. The number one rule for any of these positions is you need to earn the trust of other PHP users and developers. The only way you can do that is by showing interest, show commitment, and actively participating.

Support

1. Description: probably the quickest way that people burn out in open source and the closest “link” to direct users, (you know those two issues are connected), support is usually where the most help is needed. Support involves helping people who are new to the language learn the skills they need to not only finish their project, but write code that is secure and not cringe-inducing. This might mean some hand holding, some manual pointing, even a round of “Why using PHP 4 is a bad thing,” “the error suppression operator is evil,” and “E_ALL is the proper error reporting level.”
2. Requirements: the best way to be useful with support in PHP is to find one thing you know you’re really good at, and answer questions and help fix problems that relate to that specific thing. If you’re a regular expressions wizard, help with regex questions. If you know how to compile PHP properly on Ubuntu, then help with that. Trying to answer all of the questions to problems will make the most skilled programmer lose his mind, but every time you answer someone’s problem correctly, that’s one less question other people have to deal with.
3. How to get involved:
   • Join a mailing list and answer questions. php.general and php.windows are great places to give people a hand.
   • Join forums on unofficial PHP sites and answer questions correctly (and speak up when poor examples, tutorials, and help are given—the Web is flooded with bad PHP code).
   • Spend some time in a PHP IRC channel (there’s a big one on freenode (##php) and others elsewhere) but remember that most channels have their own “rules” for how to act, ask first and listen to the general tone of whatever channel you decide to spend time in.

Web Sites

1. Description: surprisingly enough, PHP has a lot of web sites that need to be kept up to date and running, and guess what they’re written in. Although most of the sites are in “maintenance mode” there are issues that need to be addressed. Most of the code uses register globals, magic quotes and include_paths from php.ini. Yes, it’s crufty. Do you have what it takes to uncruft? All of the code is PHP and in CVS, so it’s a fairly low barrier to entry. Another big project that someone with way too much time could get involved in is to help consolidate and improve the PHP bug tracker. You could work on the mirror test script if you’re into PHP CLI code… the list goes on and on.
2. Requirements: the ability to write secure (XSS on PHP’s website would be very bad), readable PHP code. You need to be brave enough to dig through some very old stuff and make it better without breaking everything that already works. You also have to be willing to send patches for a while until you’ve developed some trust among the people who take care of the sites.
3. How to get involved:
   • Join the php.webmaster mailing list.
   • Scan bugs.php.net for “quick fixes” and post patches to the mailing list.
   • Talk to the web site guys in #php.doc on EFNet
   • Profit?? Well maybe not, but you’ll probably get a coveted @php.net mailing address plus a CVS account for your efforts.

Testing

1. Description: the bastard stepchild of jobs on any software project, testers need to run their own applications on PHP and report bugs, write PHP tests, file bugs when tests break, and test PHP releases… a lot. This kind of ties into the bugs area below, because you need to know how to file good bugs.
2. Requirements: the ability to install PHP on your system, in your sleep, and to be one of those people for whom failing tests mean nightmares. If you run some esoteric operating system like, say, Windows, that is even better. Know how to report bugs properly.
3. How to get involved:
   • The very easiest way: download a PHP snapshot or release candidate, install it, and run your PHP application. If it breaks, report the bug! If more people would do this, fiascos like PHP 5.2.7 would not happen because the magic_quotes_gpc issue would have been caught and fixed (it was broken in at least 3 RCs).
   • Install PHP and run the tests for it. If you keep up with release candidates, alphas, and betas that’s even better. If you have your own application with its own tests that you run on PHP, well that’s just fabulous. Run those too. Yell every time something breaks. Send in your PHP test run results when the run-tests script offers.
   • Check gcov.php.net to find areas of PHP that don’t have test coverage. Write tests for them. PHP test writing is described at http://qa.php.net/write-test.php.
   • Write tests for your favorite PECL extension. Send them to the pecl.dev mailing list (they’ll be so happy with you) run tests every time there is a release.
   • Report bugs for failing tests!

Bugs

1. Description: report, triage and fix bugs. Reporting involves accurate bug reports with reproducing scripts. Triage involves digging through bug reports, trying to replicate them, throwing bogus ones out the window and writing good tests for real bugs. This is a job that no one likes; it’s boring and you'll make people mad by telling them they need to stop reporting a bug and read the manual.
2. Requirements: To report bugs, all you need is a current PHP install with the issue and a short reproducing script. This is important part. If the people writing the code can’t see the issue, no one can figure out how to fix it. Short means 20 or fewer lines. Keep chopping stuff out of that failing script! http://bugs.php.net/how-to-report.php is a great place for more information. To triage bugs you need a CVS account at php.net. You get this after participating for a while, in other ways. The PHP people need to know if you are trying to be malicious, or are just someone willing to do some work.
3. How to get involved:
   • Join some php.net mailing lists and read. Maybe even comment a bit (intelligently).
   • Report bugs.
   • Write test cases for bugs that don’t have them. Be generally useful and participate on php mailing lists.
   • If you have a CVS account, help with bugs in the tracker. See if you can reproduce them, check for good test scripts.

Docs

1. Description: translate documentation, write documentation, and clean user notes in the manual. PHP’s documentation is all marked up with docbook, so you’ll need to become familiar with XML (lucky you) and the Phd build system.
2. Requirements: the ability to write in English (or translate to another language). The ability to write or learn to write docbook (it’s just XML). The obsessive need to make sure that the PHP documentation is the best on earth.
3. How to get involved:
   • Join the phpdoc mailing list and hang out on EFNet in #php.doc
   • Read up on how to translate and write PHP documentation—there are some temporary docs available at http://wiki.php.net/doc/scratchpad/howto and some in depth, although somewhat out of date docs at http://doc.php.net/php/dochowto/—yes even the howto document needs help.
   • Send some patches to the mailing list—in no time they’ll be telling you to request a CVS account and giving you more work to do. ;)
   • Maybe you know of a PECL extension that has no docs and needs them—http://wiki.php.net/doc/scratchpad/pecldocs can help you get started. Document them, send them to the doc mailing list. Profit! Errr… get your own CVS account!

PECL

1. Description: write and maintain PHP C extensions.
2. Requirements: at least the basics of C and the ability to read source code enough to figure out what is going on.
3. How to get involved:
   • Join the pecl.dev mailing list (at php.net) and hang out on EFNet in #php.pecl
   • If you want to help with an existing extension:
     • Check the bug list, fix a bug, send a patch to the mailing list.
     • If the maintainer is active, your patch should get looked at right away. If there is no maintainer or the maintainer is NOT active, kick the list a few times and ask to be a developer or maintainer (we give extensions away all the time).
   • If you have an idea for a new extension:
     • Write a little bit of code so you have the base for your extension.
     • Send a letter to the pecl.dev mailing list about it, they’ll get you set up with everything you need.
     • Make sure the license you choose (and any library license) is compatible with the PHP license, if it is not you will need to put your project elsewhere, SourceForge and Google Code are good choices.

Core

1. Description: actually help write C code for the PHP core.
2. Requirements: working knowledge of C, understanding of how PHP works, a desire to work with some very smart people.
3. How to get involved:
   • Join the php.internals mailing list. Spend a long time just reading it. Do not make stupid feature requests, wax philosophical, or vote before you’ve written a line of code. Just read.
   • Join the php CVS mailing lists (there’s one for zend and one for php-src). Just read.
   • Fix a few bugs and submit patches to the list. The more patches you fix, the faster you’ll get karma. Volunteer for fixing more things… the more you code the better PHP will be.
   • Not good at fixing bugs and still want to help? Start with the great Unicode conversion going on in PHP 6. Read the docs; find an extension that hasn’t been converted.
   • If you're well-versed in databases, volunteer to help with PDO which really needs some love. There are all kinds of work to be done, and as long as the patches work, you’re always welcome.

Remember, we’re not asking you to do everything on the list. Pick one thing and make that your contribution: run your application on every PHP Release Candidate, spend one hour a day in IRC answering questions, spend one hour a week triaging bug reports, and if you want a name for yourself in the annals of PHP, a good code monkey to help work on the PHP bug tracker would be loved by every developer. If everyone who uses PHP would contribute back just a little bit, the results would be astonishing. Make being a part of the solution your resolution this New Year’s. Less bitching. More coding.