Recently I went through the proposal process for a PEAR package (Services_W3C_HTMLValidator) and figured I would write down some thoughts.
Simple Guidelines for Proposing a PEAR Package ( and getting it approved ):
1. Lose your ego (if you have one). Your code might be good, but there are plenty of people out there who will find flaws with it. The sooner you realize others can help you, the sooner you can move on to accepting help and improving your code.
2. Choose an appropriate package name. And be sure you understand why the underscores are in package names. Examine what packages are out there, and note their category and naming scheme — the package name should quickly convey the purpose of your package. Also make sure you look to see if your package is already in the repository.
3. Follow the coding standards. PEAR developers will nitpick you to death – it’s best to just correct this ahead of time. The biggest ones are: Use 4 spaces, not tabs! Take a look at PHP_CodeSniffer and run your code through this before you submit any code.
4. Document your code. If you expect anyone else to use your code, you MUST document it. Provide internal documentation using PHPDoc syntax – AND externally using general terms anyone can understand.
5. Provide useful examples. You must have examples which work and are easy to understand – and you MUST have examples which cover the basic functionality your package provides.
