Chapter 10. The formal proposal process

Table of Contents
Step 1: Requirements for a proposal
Step 2: Initiating a discussion
Step 3: Using PEPr
Changing a proposal

In the early times of PEAR, all new packages were proposed by an informal email to the PEAR developers mailing list. Over the time, the number of new proposals increased quite dramatically, making it hard to keep track of all the proposals.

A web-ased proposal handling system was established to solve these problems. The system is called PEPr. It is pronounced like the spice and stands for "PEAR Proposal system".

This chapter describes the requirements and the workflow for a PEPr-based proposal. After that we will provide you with information, on how to actually start a proposal. Finally, you will learn what to do once the proposal is finished.

After reading this chapter, you will will be able to start a proposal for your code right away.

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 PHP 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 10-1. 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