
Ask HN: What is the best way for Technical Support to submit bug tickets to dev? - jernkalv
I recently took over the management of our technical support team. We&#x27;re primarily a web-based team. We have a number of web products, ranging from a CRM tool to some APIs via AWS.<p>I&#x27;m wondering, for any of the IT Managers, Developers, Product Owners or Engineers out there, is there a set of best practices for submitting bug&#x2F;ER tickets to engineering?<p>Our goal will be to decrease as much friction in the ticketing process as possible.<p>We&#x27;d like to know what to include on bug tickets. What can we provide so engg. can hit the ground running?
======
DrScump
What conceptual model are you using?

Where I used to work, we wanted a process by which problems, or _apparent_
problems, with products could be submitted by anybody in the company with any
sort of a technical nexus, including technical support, pre-sale support,
technical publications, field consultants, QA, and r&d itself.

We came up with a bug database system that provided two pathways for
conceptual problem reports to be accepted as bugs. R&d itself could enter bugs
directly for products within their own purview. For the rest of the company,
however, we would we wanted some filtering and independent analysis before
necessarily accepting an unexpert opinion about an _apparent_ misbehavior to
be logged as a bug directly.

Therefore, we had a parallel _problem_ reporting system that was available to
all technical personnel outside of r&d. Problems would be evaluated by
technical support and or r&d personnel before being escalated to a bug. Also,
since a given bug could reveal itself in more than one apparent misbehavior,
multiple problems could map to a single bug.

When there was any contention as to whether an apparent misbehavior was to be
accepted as a bug in code, in documentation, or to be dismissed as a
misinterpretation on the part of the customer and/or the reporting party
within the company, the issue came before a Bug Committee which included
representation from Support and R&D (at least). Then, it could be escalated to
a bug or closed.

The benefit of this dual-path model was that there was a low-friction process
that would capture problem reports from a broad population and document them
for everyone to see paired with a more formal and rigorous process to
identify, documents, and track agreed software defects.

Bug entries would include a source control system reference for each affected
source version tree and comments by the fixer(s).

