Members (folks submitting the tickets who want to see status) and Volunteers (folks around the shop doing work) are equally important audiences for this solution. It’s not like a business where we can fire a tech if they don’t bother updating their tickets - if any solution is annoying to interact with on the “working” side, it simply won’t get used and we’re right back where we started that problem reports never have a current status.
The reason we have the problem report form is a lot of members never bothered reporting problems on Discourse or via email, which led to seldom-used machines being broken or janky or otherwise offline for long periods of time before a volunteer willing and able to remedy the situation found out about it. It’s probably true we could have set it up to post to Discourse instead of Slack, but this way was a shorter route to a working solution (there are a lot more examples floating around for Slack integrations than Discourse) and like on any ticket system, tier-0 problem report traffic is noisy. There are several a day, which would cause most anyone to tune out of a Discourse topic about them.
Members’ lack of visibility to problem status is definitely an issue, but I feel it’s a less acute issue than volunteers’ lack of visibility to existence of problems. We’re moving up the hierarchy of needs here.
It’s possible the current system is too biased toward convenience for volunteers, but for better or worse it’s a stake in the ground against which any new solution will be judged by the folks using it.
We do have some folks working on grants, and we’re not afraid to pay out of pocket for the right solution. It’s tough to set a budget on this from a management side since we have no idea what kind of numbers we might be talking. A couple thousand a year might be doable, a couple thousand a month probably not. I’d be nervous about depending on a grant for operating expenses, due to the risk of losing a tool we rely on at grant renewal time.
We could implement a multi-level report management system in Discourse or between Slack and Discourse, but it’d be a fair amount of work for what’d ultimately still be kind of kludgey. Just forgetting about the whole thing and migrating wholesale to a better system is surely preferable, but we need a new solution to be able to do that 
ps: on reinventing wheels: We all like to make things ourselves, but for infrastructure things we need to be mindful of sustainability. Making a cool new tool can be a fun project, but creating a system that survives loss of its initial champion is often less so. Openpath, for example, replaced a trashcan full of semi-custom hardware running homebrew software that was always an administrative nightmare.
pps: on requirements gathering: It sounds like I don’t need to tell you this Stephen, but for others who might be engaging: When a stakeholder gives a requirement, you often have to ask “why?” a few times to find out what they’re really getting at. For example, when I said Slack integration would be nice, the actual requirement I’m getting at would be better stated as It should be really convenient to see and interact with tickets from my phone in real time, preferably without installing yet another app.
