Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Creating ShelterBuddy Engineering Requests

Start in the ticket, then go to Jira in the lower-right to make sure the two tickets are connected.

Fields available:

  • Project: Always “Shelter Buddy (SB)”

  • Issue Type - Options: 

    • Bug - An expected function of the software isn’t performing as it should, and it’s clearly something that both we and the customer expected to provide for them as part of our service.

    • New Feature - Feature request for functionality that does not yet exist but would benefit the customer. Please note, for 99% of these, they should follow the Known Non-Solutions procedure and not interfere with the devs regular activity (aka, try not to use this)

    • Task - This is an expected function of the software that can only be done by internal Pet Loyalty staff. (example: Kennel card customizations)

    • Improvement - Request for improved functionality based on existing features that would benefit the customer. Please note, for 99% of these, they should follow the Known Non-Solutions procedure and not interfere with the devs regular activity (aka, try not to use this)

  • Summary (This is a Title): “[Shelter Name] - [Summary, <8 words]”

  • Description - detailed description. Include items like URL to the page where the problem is going wrong, steps to reproduce the problem.

  • Reporter - who is submitting the ticket. Put your name here unless submitting on behalf of another PL employee. Be advised that if a non-CS rep is the reporter, then dev may not recognize the request as having come from CS.

  • Attachments (file upload) - Screenshots or other data where necessary.

  • Sync Notes and Comments - Yes. This helps devs get context about the ticket.

Next, click on Jira Ticket attached to the ticket to complete the submission

  • Priority: MAIN detail. Jira priorities are different from Hubspot.

    • High Priority in Hubspot = Critical in Jira. This means that the issue is causing the shelter to be unable to operate.

    • Medium Hubspot Priority = Must Have in Jira. This means that the issue is preventing key ShelterBuddy functionality, like loss of a feature or a bug.

    • Low Hubspot Priority = Normal or Nice to Have in Jira. Normal is slightly higher, so use your judgment and pick which you prefer.

  • Labels: This will expand as we use this system more. For now, there’s only one label we use

    • Support Priority - Use this only for Critical or Must Have tickets.

  • Due Dates (new functionality to be switched on by a certain date) - Only use this if there’s a defined, hard line deadline from the customer. Should probably be limited to “Must Have” tickets.

  • No labels