Two Discourse features that can help a tiny bit:
Automatically bumping old topics on a category. We could enable it on Drafts, so that every day one old topic would be bumped. Currently there are 52 topics in Drafts, and so far the number keeps increasing.
Assign plugin. Moderators could assign drafts to themselves, making easier the distribution of work without stepping on each other’s feet. Also making easy to see which drafts are not assigned to anyone yet.
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?
Alright, we seem to be in agreement on making Bitwish accessible (low bar for submitting initial drafts) and then apply high quality standards through moderation.
Yes, there is a risk that after an initial burst thins will get quieter. Also that earlier voters won’t revisit their choices even if there are newer requests. The good news is that we have tools to check what is going on, and then react to problems as they come.
I think right now the main problem is to understand how Bitwish can be useful to the Bitwig team, as you have pointed out. I contacted them a couple of days ago. Let’s see if/when/what they respond.
I have started to rewrite the first post of this topic. For now, there is only a skeleton / table of contents. I’ll continue in a couple of hours, after dinner. Feedback very welcome!
Heh yes you seem to have got the measure of me, at least in this regard xD
Tags: I agree, we need to establish which tags are needed before considering restricting them. Does this forum include a mechanism for members to request creation of new tags?
Moderators: I think the learning curve for new mods could be eased with really specific documentation, which is already under discussion and development 
I have myself been considering the idea of adding feature subcategories. From the perspective of a moderator this would make the workload smaller if they can be allocated to some specific categories though of course the process would remain largely the same. Do you think there could be value in there being different moderator roles within the process? Like having editors, discussion facilitators, user admins etc. Some people could cross over and have the requisite permissions for multiple roles but not necessarily so.
Draft voting: I feel a similar way in the sense that for new users it could be disheartening not to be able to vote on a great feature request that’s still in draft. I think over time as there become more and more published features, people might have more faith that it will happen and come back later, or maybe even feel more motivated to get involved and help to complete the draft. Perhaps if we start seeing patterns of engagement of this nature then we could consider restricting voting to only published features.
I like the idea of bumping old drafts. It could motivate somebody to work on a draft which they might not otherwise have seen. I think also the shorter “time-out” period will help to keep the flow moving out of drafts, even if only because several get closed.
I wonder also about having a separate category for timed-out drafts. It would keep the drafts category as more of a working category rather than an archive of old dead drafts that weren’t completed.
I have written the first paragraphs and “Drafting together”. Tomorrow more.
Nice, reads very clearly thank you. I wonder if we could include something about not writing from the first person. E.g. “it is suggested that…” rather than “I’d like it if…”
I had literally written “third person” in this sentence but then I removed it. I’ll add it now, thank you!
I have started drafting Best practices: Title, Tags, and Description.
Next: best practices for each of the sections.
If you would like to delegate any specific parts of writing these documents then let me know. I don’t want to complicate things by working on areas you’re already intending to write
I guess they meant “passively voiced” rather than third person; in any case: this is looking great! Thanks for all your hard work.
@chalkwalk yes I considered wording it that way but I wasn’t sure how widely understood that concept would be compared to “third person”. But yeah definitely, passive voice would sound more professional
This is getting more technical than this draft is intended to be. Given that avoiding first person is already specified, I have omitted the 3rd person / subjective voice dilemma altogether. I think the point is clear in the current draft.
By the way, I have completed the first pass. Any feedback?
EDIT: Ah, no, somehow I missed " What problem(s) would this feature resolve?". Tomorrow.
I’ll take some time to read over the weekend after some rest and will post some thoughts. Are you open to edits on this document or would you prefer feedback in comments?
Edits welcome! I have tried to keep it concise.
@chalkwalk do you think your points have been addressed or is there anything that we have overlooked? Other ideas? I’m very thankful for your thoughtful feedback!
Yes, I agree. I have been thinking about opening a new topic to discuss other things we could offer here complementing the community wishlist. Bitwish sits on top of a very powerful platform (Discourse) and there are many community features not covered by other Bitwig community channels.
A few weeks later… I’d say Writing a good feature request is doing a good service. However, there are two points that we keep seeing in new requests, and perhaps it would be good to stress them with a notice at the top, for those who won’t read the entire text:
What do you think?
I think you could probably reiterate that things should be written in the third person. It’s not necessarily inherently harmful to write in the first person, but consistency helps tremendously, and it encourages considering the points from the perspective of others.
As for solving a problem, I guess a lot of feature requests aren’t being considered from a problem solving perspective. They are either “random thoughts” or replicas of things seen in other DAWs; this is presumably driven by a desire to retain an existing workflow wholesale.
Perhaps we can describe more clearly how to frame a feature request? In particular to encourage participants to think clearly about what problem is caused by the lack of the feature (beyond: without feature X I don’t have feature X which is important to me), and specifically how that feature effectively solves the problem in question.
Perhaps there could also be a couple of reminders at the top of the template which would be removed when the request is moved to #features