Chapter 3. Feature Requests

Chapter 3. Feature Requests
Home Prev	Part III. Tickets	Next

Feature request = a system change or enhancement requested by a Sitka Site.

Process

Ticket is received from the library.
Make sure the request includes all necessary information and that we have a clear understanding of exactly what the library is asking for.
1. Email the library for clarification if required.
Update the ticket as follows:
1. Include a descriptive subject line.
2. Specify "Feature Request" in subject line.
3. Add appropriate EG-Tags tags.
Search RT for existing tickets.
1. Link to or merge into existing tickets as appropriate.
Search Launchpad for an existing bug/wishlist report.
1. If there is no existing bug/wishlist report, create one.
2. If there is an existing bug/wishlist report, click This bugs affects XX people. Does this bug affects you. On the pop-up click Yes, it affects me.
In RT move the ticket to the Feature Request queue and update the ticket as follows:
1. Add the launchpad bug # to the Launchpad Bug field.
2. Add the EG Release tag for the expected Evergreen release, if indicated on Launchpad.
3. Add the appropriate EG Modules tag.
4. Add the appropriate Bug-tags tag. Most likely this will be Waiting for Upstream Fix or Community Fix available.
5. Set ticket priority
  1. Low = 1 library request, or obscure feature (may be related to workflow, or library process)
  2. Medium = +1 library request, or useful feature that more sites will benefit from
  3. High = +1 library request, interrupts workflow, or is a bug that requires significant development to resolve.
  4. Urgent = important or essential feature lost through upgrade
Email library to advise issue has been reported to the Evergreen community.

Note

Use this text as the starting point for your response to the library:

"Thank you for your suggestion. This has been reported as a wishlist bug to the Evergreen community and we will monitor the bug report to see if anyone decides to develop or fund the development of this feature in the future."

You can also include information about the status of the bug report if applicable. Such as:

There is a lot of heat for a particular bug so we are hoping to see a fix soon.
There bug is several years old and has no heat so unlikely to be developed anytime soon.
The bug includes a comment that an organization is funding development of the feature.
A fix for the bug is available and we expect it to be included in our next upgrade, assuming we encounter no issues when testing.

A specific timeline for getting a new feature should never be given unless we know for sure that a fix is included in an upgrade or backport and we have already completed testing to ensure the feature works.