Step 1: Requirements for a proposal

The following enumeration lists the most important things that need to be done or be made available before starting a new proposal.

• Finding a name for the package It is obvious that each package needs to have a unique name. To get a "feeling" for proper package names, you should browse the list of existing packages. Choosing a name for the package is an iterative process and it is likely that you will change the name at a later stage of the proposal process.
• Finding a category for the package Similar to each package having a unique name, it has to be placed in one of the categories, which are listed in the package browser as well.
• Writing a package description For starting the proposal you will need to write a description of the package. This description does not need to mention every detail of the package, but it should at least outline the basic concept and feature set. When your package has been accepted, you will have to come up with a single-line summary and a fulltext description.
• Choosing a license for the package Each package has to be licensed under an accepted OpenSource license. If you are unsure about the license, you should opt for the New BSD License. The PEAR Group has issued a License Announcement, which provides further details concerning this topic.
• Writing examples and documentation Without proper usage examples and documentation, neither will the PEAR developers be able to evaluate your package nor will users be able to make use of your package.
• Listing dependencies Making a list of dependencies basically means that you write down all external entities such as other PEAR packages, certain operating systems or external applications, which are required to use your proposed package.

  Example for a dependency list

  If your package does only work on Linux, requires the DB package, version 1.8.4 or higher of the Log package and at least PHP 4.3.0, your dependency list looks like this:

  Linux
  DB
  Log >= 1.8.4
  PHP >= 4.3.0