Evergreen DokuWiki

Also see:

• Frequently Asked Questions about Evergreen

• Frequently Asked Questions about Evergreen's Features and Technical Infrastructure

• Frequently Asked Questions about Open Source

• Evergreen and Open Source Glossary

• Evergreen Roadmap

You, the original suggester, play a key role in the initial advocacy for a new or improved feature for Evergreen. The clearer your request, and the more use cases you can demonstrate for the feature, the more likely it is to be eventually adopted. Think of yourself as the personal advocate for that feature: the lead person (even in a group of people) who will frame the original request, respond to questions, and follow up to make sure it happens.

On the other side, Evergreen developers will ensure that features considered for implementation are recorded and tracked, and that requestors get clear responses to their questions.

As the Evergreen community widens from PINES–the "birth home" of Evergreen and its largest champion and user–to include other libraries and communities, this Evergreen Feature Request Procedure provides a clear and equitable route for suggesting features for Evergreen software and helps the Evergreen community collectively build a roadmap for future development.

Each feature request is assessed fairly on its relative merits by a stakeholder group within the Evergreen development community, which includes:

• Libraries actively developing Evergreen
• Libraries running Evergreen
• Libraries planning to implement Evergreen
• Evergreen software developers

This feature request procedure enables the stakeholder group to determine if, how, and when a particular feature will be integrated into the Evergreen software.

1. Review the Evergreen roadmap first to see if the feature is in the pipeline
2. If you have a development list for your organization–such as the PINES development list–consider posting the feature there, for discussion within your organization.
3. Otherwise, send a message to the general Evergreen discussion list to submit requests regarding features that do not currently exist on the Evergreen development roadmap: mailto:open-ils-general@list.georgialibraries.org (You may need to subscribe first)
4. Provide as many answers as possible to the following questions:
   1. What is the feature?
   2. What does it do, what problem does it address, how do you see it functioning?
   3. Where does it "fit" in the Evergreen software suite – staff client, cataloging, circulation, reporting, public catalog, or somewhere else?
   4. Is it similar to a feature you have seen in other software?
   5. Who does the feature benefit — library users, library staff, or a specific community (teens, catalogers, homebound users)?
   6. Does the feature benefit your library specifically or could it apply to other libraries? Some? Many? Most or all of them?
   7. Can you provide a use case for the requested feature? In other words, can you describe the feature’s workflow, who would use it, how you see it functioning? Tell us a story.

1. If the feature is in the pipeline, but you want it to happen sooner, assess whether you might have access to resources to make that happen (time, money, developers)–either on your own or in concert with other organizations. The Evergreen stakeholders can help you with that determination.
2. We generally give priority (within reason) to proposals that provide software code that implements the proposed feature and meets the Evergreen requirements for code quality, integration, and legality.

1. The Evergreen community evaluates the request to determine if the use cases are already covered by an existing feature and to determine the cost of implementing this feature.
   1. Discussion on the list may ensue. It helps if requesters can take part in this discussion to clarify their requests.
2. If the developers believe the feature already exists, they will contact the original requester to confirm that the alternate implementation does indeed cover the requested feature. They will also verify that the feature is described in Evergreen documentation.
3. If the developers do not have enough information to make a determination regarding the development cost or priority of the requested feature, they will contact the requestor for additional information.
4. Low-effort, high-gain requests will be verified with the original requestor to ensure the developers understood the request–"You wanted it this way, right?"–and will then be added to the development timeline (see the Evergreen roadmap).
5. Requests the developers believe are more technically involved or of less immediate utility to the broader Evergreen community will be sent to the stakeholder group 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.
6. The Evergreen stakeholders will then determine, by discussion, vote, or acceptable alternative means, the relative usefulness and priority of the request feature.
7. If the feature request is determined to require extra funds to complete, a budget estimate and request will be created and shared with the interested stakeholders.
8. If resources are subsequently allocated to developing this feature, the Evergreen Software Development Team will insert the feature into the appropriate position in the software development timeline, as well as add it to the Trac system (a database used to track features and bug fixes).
9. In either case, the original requester will be contacted with the status of the request.

For questions about this process, post a message to one of the Evergreen discussion lists (see http://open-ils.org/listserv.php ) or email the developers at mailto:feedback@open-ils.org. IRC users can also stop by channel irc://irc.freenode.net/Evergreen for real-time chat (which is also logged at http://open-ils.org/irc_logs/ ).