Evergreen Feature Request Procedure
August 2005
As the Evergreen Software Development Team progresses towards the Beta and Production releases, the need for a formal feature request process has become evident. The purpose of the Evergreen Feature Request Procedure is to streamline this process, and to provide a clear and equitable route for any additions to, or suggestions relative to, the Evergreen software. It is paramount that each feature request is judged fairly on its relative merits and priority, by both the Evergreen Software Development Team and the PINES Subcommittees.
This procedure will enable the Evergreen Software Development Team and the PINES Subcommittees to determine if and when a particular feature will be integrated into the Evergreen software.
-
All requests regarding features that do not currently exist on the Evergreen development road map shall be submitted to:
pines-dev pines-dev@list.georgialibraries.org
OR
open-ils-general open-ils-general@list.georgialibraries.org
-
All feature requests must be accompanied by two sets of information:
-
The type and size of the target audience of the requested feature. The type of the audience will be one of patron, staff or specific staff type, such as catalogers. The size of the audience will be a realistic estimate of the number of users that the feature will directly serve or a percentage of the audience type that the feature will directly serve. These estimates will be vetted by both the Evergreen Software Development Team and the PINES subcommittees.
-
Specific and realistic use cases of the feature being requested. This requirement is essential to the success of the feature request process. Without realistic use cases, the development team will be unable to design a useful and integrated process around the request, and the PINES Subcommittees will be unable to determine the true merit and priority of the request. This also allows the requesters to evaluate their requests, and can help them to add their own view of the priority of the feature request.
-
The Evergreen Software Development Team will evaluate each request, in the order received, to determine if the use cases are already covered by an existing feature and to determine the software development costs. If the Evergreen Software Development Team believes the feature is already covered by existing functionality in the software, the original requester will be contacted to explain that the feature is believed to be implemented in an alternative fashion and to confirm that the alternate implementation does indeed cover the requested feature. Also, if the Evergreen Software Development team does not have enough information to make a determination regarding the development cost or priority of the requested feature, they will attempt to solicit enough information from the requester to make such a determination. If the software development team believes the request is minor, easily incorporated, and would take minimal development time, then the request will simply be inserted into the appropriate position in the development timeline.
-
After the Evergreen Software Development Team has evaluated the feature request, it will be sent to the PINES subcommittees for evaluation. Along with the original feature request, the development team will supply a summary of the technical evaluation including the development team's estimation of the development cost of the requested feature and any further comments the development team may have.
-
The PINES Subcommittees, in consultation with the PINES staff and Evergreen Software Development Team, will then determine, by discussion, vote, or acceptable alternative means, the relative usefulness and priority of the request feature. If the feature request is determined to require extra funds to complete, a budget estimate and request will be sent by the Evergreen Software Development Team to the PINES Program Director. If the feature request is accepted, and the needed funds are available and approved, the Evergreen Software Development Team will insert the feature into the appropriate position in the software development timeline.
It is our belief that this process, when followed by all interested parties, will not only streamline the process of accepting and prioritizing feature requests, but will help to provide clear and easily understood reasoning behind the relative prioritization, avoiding any misunderstandings surrounding the implementation, or deferral until a later release, if applicable, of all features that users would like to propose.