Feature Requests

In addition, we have to “formalize” the feature requests a bit.

Instead of me maintaining an informal list of everything I run into (kernstodo), we now maintain a “formal” list of projects. This means that all new feature requests, including those recently discussed on the email lists, must be formally submitted and approved.

Formal submission of feature requests will take two forms:

1. non-mandatory, but highly recommended is to discuss proposed new features on the mailing list.

2. Formal submission of an Feature Request in a special format. We’ll give an example of this below, but you can also find it on the web site under Support → Feature Requests. Since it takes a bit of time to properly fill out a Feature Request form, you probably should check on the email list first.

Once the Feature Request is received by the keeper of the projects list, it will be sent to the Bacula project manager (Kern), and he will either accept it (90% of the time), send it back asking for clarification (10% of the time), send it to the email list asking for opinions, or reject it (very few cases).

If it is accepted, it will go in the projects file (a simple ASCII file) maintained in the main Bacula source directory.

See also

• Implementation of Feature Requests

• How Feature Requests Are Accepted

• How Feature Requests Are Prioritized

Possible Next Steps

Go back to Development Cycle.

Go back to Developer Notes.

Go back to Developer Guide.