(Sorry for the lengthy reply but there is a lot of sauce in this proposal.) 
@chalkwalk you make very good points and I have the impression that we are in agreement on the basics. If the Bitwish processes and documentation are still in flux it is partly because the project is only a few days old, and so far there are only two admins thinking about these processes in their free time.
@bjorn and I have never met, never worked together before, and in fact we don’t even know each other. Still, we seem to share a philosophy of work-in-progress and constant improvement through iteration. @bjorn please correct me if my assumptions are wrong. 
Let me highlight some point that I think we should discuss further.
Right now our tags are a mess, but I think it’s fine because it is just the beginning of the project, and consolidating tags usually takes some time. For what is worth, Discourse allows to organize tags by group, mark tags as synonyms, require certain tags in specific categories, and also restrict the use of certain tags to certain groups of users (i.e. admins and moderators).
Although I can see why having a small number of tags is beneficial from the point of view of the dev team, here we use tags also to help users navigate feature requests. If you are in a quest to improve the piano-roll or you come from cubase , having specific tags will help you discover requests that otherwise might be just buried by the most voted or most discussed requests.
Probably there is a way to combine the few stable tags useful for the Bitwig team with the large collection of dynamic tags useful to Bitwish users. This deserves a discussion on its own.
The process and the resources to maintain the process need to be align, otherwise we are kidding ourselves. Your proposal (which I like) makes me realize that right now there is a high entry barrier to become a moderator. In a project that is a few days old, someone goes from new user to moderator of all Drafts or Features . That’s quite a jump for most users, just like it is quite a statement to say “I know Bitwig”.
What if we would would organize features by subcategories like Arranger, Grid, Modulators… and then we would offer moderator roles per subcategory? This would make the moderator role for a specific subcategory more accessible, and the moderation / curation work could be distributed more naturally by areas of expertise.
And maybe this “short, canonical list” that @chalkwalk mentioned above would be the subcategories (leaving tags the freedom to be many and messy, as tags frequently are).
I thought about this point when putting Bitwish together before its launch. I can see pros and cons in doing so:
- The advantage of letting people vote drafts too is that it’s easier to see what are the most popular drafts, and we can focus on improving the most voted drafts. For instance, now it’s clear that MSEG needs some love, because it is the third most voted request and yet it’s a draft.
- Another advantage of allowing to vote drafts is that Bitwish feels welcoming to new users. Most of them won’t know how things work here and they will just want to give their vote to that feature that is still a draft. Now they can vote quickly, and maybe leave til next time. If they cannot vote the feature they love and they see other features with votes they may be confused, even upset, and they may just put pressure to the drafters to get the job done so that they can finally vote.
- The disadvantage, as you point out, is that people may get lazy about improving a draft if they are already accumulating votes. However, I believe this relax will change when the 90 day deadline (which can be changed) approaches, and the risk of having the draft closed becomes imminent. Closing the draft doesn’t mean anything for the request, the content will be there and the topic can be reopened, but the votes will be lost.
One possibility is to remove voting from drafts, and then rely on the Top algorithm, which takes into account many factors like views, likes, and number of replies.
I agree… but I also see the point of users who are saying that keeping a bigger scope helps highlighting an area where users think improvements are needed. We are seeing people making this point on https://bitwish.top/t/better-piano-roll/35 and to a lesser extent in Chopping / slicing audio in the Sampler. I can see how this reasoning will keep coming.
I was thinking that in justified situations and to the discretion of the moderators we could have “umbrella feature requests”. That is, something like https://bitwish.top/t/better-piano-roll/35 that would only consist of a list of related feature requests, each one with their own topic. This way users would be happy because they can invest one vote in highlighting that the piano roll or whatever needs improvement, while at the same time Bitwig devs and also users would have the atomic feature requests that actually compose that umbrella feature requests, and they could consider them one by one.
I fully agree with this. However, I think that this is where number of votes and a deadline to complete drafts put things in the right perspective. As a volunteer moderator with a limited time, I put my focus on the most voted drafts, also on less voted requests that I believe are on point (i.e. A Pure Data Grid block). If an incomplete draft isn’t getting many edits nor many votes during 90 days… Well, it will be closed and archived (and essentially removed from sight) until someone cares to bring it back.