When to Submit a Ticket

• If it is a bug, submit a ticket. 
• If the idea relates to current goals/milestones that need immediate attention or planning, submit a ticket.
• If the idea should be considered soon, and requires the overhead of ticket system for tracking, approval, etc.
• If there is a process or tool issue that if addressed now, would improve progress towards current goals or work items, check in a ticket.

When Not to Submit a Ticket

We currently subscribe to the Joel Spolsky philosophy on backlogs.  Once entered into JIRA, a ticket requires maintenance (entering and updating fields) and re-evaluating whether the ticket should be scheduled.   Tickets are for work items that may need near term consideration, and that also require the overhead of evaluations, approvals, and workflows to complete.  For this reason, we do not create tickets for everything.  Here are guidelines for when NOT to submit a ticket.

• If the idea is really a small to-do list item that does not requires approvals, QA etc., do not submit a ticket
• If the idea/minor issue is unrelated to current goals, or key customer needs, but you want to make sure the idea/minor issue does not get lost, add the idea to the idea tracking pages (or create a new one):
• Dynamics/Modeling
• Programming Infrastructure
• Solver Infrastructure
• Output/Reports
• Project Infrastructure
• If you are not willing to defend why we should address the ticket soon, or it is not needed by a customer soon, do not submit a ticket.
• If the issue is a minor change or issue related to ancillary data, documents, or products, do not submit a single ticket, see idea pages above