Thanks for taking the time to give such an extensive reply. Regarding overall intent of the project; while the forum format is great for so and discussion my concerns fall mostly around how we (meaning the community), you (meaning the person operating and moderating the forum) and the Bitwig team can all get maximum value. One complication is that you’ll likely get a big spike in interest where everyone delivers their long standing feature requests, followed by a long tail of dedicated users adding their pet requests (of variable value). This also means that most users will vote based on what features where available on registration and not adjust their voting over time to track their desires as the feature list grows. This means a high initial moderation load followed by spotty engagement. Similarly, many users while likely submit a request then consider “my work here is done” (FYI Bitwish emails were getting spam filtered). Given this engagement model, it seems to me that we either need to set the bar high, or have a high moderation cost. My inclination is to think the latter may be simpler in terms of total cost vs number of useful feature requests captured. In the end though, quality of content is what will bring the bitwig team on board.
In terms of tags and sub categories, I think the middle ground you suggested with freeform tags combined with fixed sub categories makes a lot of sense. This allows for a granular subdivision without interrupting the tagging mechanism. In the best case the bitwig team could convey their (internal) requirements for feature tracking, perhaps a template that use is categorisation, and that could be applied here. Moreover the lower the cost to them off adopting issues verbatim, the more likely they are to use this respiratory as an “official window into client wishes”.
Circling back to “high moderation cost”, in forums like this, with official engagement, the official team members have to capture the requests and turn it into something acceptable to the internal dev team. The more of this burden is carried for them, the more likely they are to engage: a creative engineering and artistic team will have 100s of feature requests in mind, many are likely repeats of what we have here: a success story will be the addition and prioritisation of a feature, so my thinking is: optimizing the process to make that happens is what matters the most. I believe u/nickallen74 on Reddit and probably others are official representatives: I wonder if we can start a conversation with them to get some clarity of how we can best deliver value to them? Without official engagement this forum will end up as nothing more than an sounding board/echo chamber.
As for voting in drafts, and drafts in general, I imagine lots of people will register, make a single request, perhaps vote, then not return: from their perspective they did their part. The tricky part is that their desire to “push from draft to feature” won’t necessarily reflect the features value. Perhaps the 3 month time limit should be reduced to 3 weeks, and any feature left in draft at that stage can be archived, but could be reviewed by moderators. These moderators may choose to file a new, clearer proposal using the concept that was proposed. This is another high moderation cost, but my expectation is that there will be a ceiling in the number of requests we’ll see, so the work is bounded. The problem with not allowing voting on drafts, is that people will likely not vote during many sessions on the site: my guess is that a typical user will vote in one session, meaning only on requests that are available at the time. During the early rush, this probably funneled votes into a small set of requests which would have been even more limited if we said “features only”. Perhaps, once more proposals get promoted, draft voting can be disabled?