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