To me, it would look a lot like Basecamp with tickets. You'd open a thread like a typical nested message board-- say "Red Widgets Project -> 2019 release 2 ->

To me, it would look a lot like Basecamp with tickets. You'd open a thread like a typical nested message board-- say "Red Widgets Project -> 2019 release 2 -> [Maintenance Team] Support Blue Widgets". There would be a series of posts, probably the first one being "We need blue widget support for customer xyz". At the bottom of the post would be links to one or more tickets for the described task. Then there'd be followup messages, discussing the feasibility of blue widgets, clarifying what blue widgets need different, or noting things they discovered in the process. Maybe late in the process, they add other tickets for "fix blue widgets turning yelliw" or "prevent SQL injection on the blueness value", and each one appears at the bottom of the message that spawned it. The tickets can have individual lifecycles, but the discussion threads would move back and forth based on activity like message boards do. Importantly, they remain both browsable and searchable, even if you have to click through a bunch of pagination. Maybe the threads can be flagged as "task complete" or other statuses to improve searchability. The discussion that goes around a ticket-- how to reproduce, the decision making process, context associated with the issue-- has long term value. In a ticket-centric system, this all gets attached to the ticket, which disappears into the void when it's marked complete. This model leaves i intact, and treats the tickets as decoration.