| There’s an interesting gap between the interest of the dev and the user here. The user wants a human to understand their sometimes multi-layered requests. The dev wants these requests to be de-layered and broken into separate issues for tracking and documentation. There really isn’t a good system today (that I know of) that would facilitate this process with both the user and the dev in mind. From a perspective of information structuring and prioritization, tickets are perfect (for the dev), yet they lack a “natural” (e.g. email, phone or chat) support exchange where an issue is several issues rolled into one. Or once an issue is resolved there’s the “oh btw while I have your attention” moment where an unrelated issue is discussed but the interaction between the same people is ongoing. To handle this properly in an email-to-ticket-system the dev would need to ask the user to resend the request in a different mail or themselves open a new issue, which is exactly the overhead the system tries to avoid in the first place. Or either party would need to remember the issue ids to keep a running list, all of which seems undesirable. In the case of a small team/single dev product it’s that human interaction that’s not paid for so the burden is put on the user, at the cost of a reduced interactive experience. Is there any better way of solving this? Or are systems being built to support this a bit better than how the Jiras/Redmines of this world are (not) handling it today? |