Skip to main content

Support Ticketing

Platform specific steps​

Ticketing tips​

Good tickets are​

  • Reproducible
  • Limited in scope to the issue at hand
  • Informational

I.e., someone unfamiliar with the project can ascertain the issue you are having, or the feature you desire. "I am attempting to do X on page (link), I have tried to do Y, but am seeing Z (screenshot) instead of the desired result."

Good tickets contain​

  • Links and error messages
  • Relevant corresponding files, including: screenshots, design mockups, SOW, etc.
  • Steps to replicate the issue
  • Potential fixes to resolve it

Before creating a ticket​

Ask yourself​

  • Does the request, as it came from the client, make sense to me?
  • Is the client actively participating in this discussion?
  • Is there a clear ask, or do we need to refine?
  • Can I recreate the issue?
  • Are there related tickets? OR
  • Has this come up before?
  • What are the budget / timeline constraints?

Does the developer​

  • Need time to set up local environments or get familiar with the project?
  • Have the access needed to assess the issue? (Servers, Valid Passwords in Vault)
  • Have the access needed to fix the issue? (UMD, JHU, Howard University, etc.)

Before starting a ticket​

Ask yourself​

  • Do I have the information, tools, context and access I need?
  • Are there any older tickets related to this issue?
  • Is this a bug or a feature request?
  • Is there a better solution to the problem? a.k.a., What really is the problem here?

Tickets may inspire​

  • Discussions about IA and Design
  • Widgets, Layout Updates
  • Larger implications on the site environment APIs, Styles and Themes
  • Alterations to legacy sites
  • Discussions on scope and budget. Not "can we do this" but "should we do this"

Before a ticket is considered ready for QC​

Ask yourself​

  • What is the QC, approval and deployment process for this project?
  • Does the client need to review and approve an update?
  • Have I included a link for stakeholders (PMs/clients/designers) to view the fix?
  • Are the caches cleared?
  • What else needs to run in order to see the updates?
  • Do I need to provide further context on how to review the update?
  • Have I created Test content that needs to be deleted later?

Have I documented​

  • The fix I enacted, in broad strokes, so another developer:
    • Understands what is going on?
    • Can modify it later, pick up the ticket, etc.?
    • The full breadth of the issue and fix, in case it comes up again?
  • Next steps to get this to production?

Before a ticket is closed​

Ask yourself​

  • Have I billed this time to the proper project?
  • Have I closed any hotfix branches, deleted any irrelevant tests, etc.?
  • Has the client been alerted, and signed off on the task?
  • Does this ticket have any future implications that need to be addressed?