I have a few thoughts about how best to keep the requests useful. I’ve been involved in some similar platforms beta testing and there are often interesting ideas (and even big reports) that get lost in the noise because they aren’t presented well. My thinking is, therefore, that if f you want good uptake from the bitwig team, the requests need to be presented with clarity and presented separately. Means a few things:
- The title of the feature request should be clear and descriptive.
- The body of the request should be as concise as possible.
- There should be a request for a single feature per request (as opposed to “also feature Y and Z”.
- Tags would ideally be taken from a relatively short, canonical list.
- Having N very similar items can result in either, the first request getting all the votes, or the votes being scattered among many.
The tricky part is: people aren’t inclined to improve requests they made, especially if they already have votes. That’s too say there is a lot of content in place already and it might be a lot of effort to restructure; the template is a good start, but I think we need a little more structure and enforcement for this to become a high value signal on community sentiment and actionable improvement list (that the bitwig team will take seriously). Here is a corresponding list to the above with suggested actions.
- Documentation and a review process that starts with checking the description: allow moderators to purpose what the title should be. Documentation wise: several example titles of varying quality with descriptions of why they aren’t ideal, and what could be improved.
- Documentation and a review process. While the title is key to have someone even look at a request, if the body isn’t clear it may be ignored. Ideally you need a moderator to read the request, to make minor edits unilaterally, or add comments requesting clarification or alteration. This review, in the best case, would happen in the draft area: I also feel like voting shouldn’t be possible for drafts, only for accepted features, which only become accepted by moderator review and promotion. Documentation wise, examples of well and poorly phrased feature requests with feedback and corrected text.
- Documentation and a review process. In any development process each feature request must be disjoint, and relate to an individual track of work, ideally by an individual engineer on the bitwig side. During review a moderator would indicate that multiple requests are included and either request further requests be added, or they duplicate the requests and edit the titles and descriptions then “transfer ownership” back to the reporter to fill in any missing details (i.e a bit al review).
- Documentation and programmitaclly enforced limitation. Tagging can be very useful, but as a free text field it grows organically allowing it to lose value due to inconsistency or over tagging. How about documenting (and ideally enforcing) a list of tags. If there were only 15 (for example) it would be easy to search and know how and why to tag in the first place.
- Review requests for similarly to others and strongly encourage disjoint proposals be discussed and consolidated. In the end bitwig team will only take one implementation and relying on “first come, first served” isn’t going to be very helpful. It seems like we’d want to group all the (similar) requests alongside eachother such that the community can discuss and reach concensus. Where a new request is a duplicate (in the opinion of moderators), the user is directed to the existing request for conversation: perhaps the moderator should be the one to reword the original text to reflect the discussion?
With any platform like this, consistency pays and the longer you wait to enforce, and the less strictly you enforce, the harder it is to get the corpus in good shape. At present we are in a stage where a human could viable triage all the requests, but as time goes on this will become less and less possible. The result would be a lot of “legacy requests” without structure which may simply get ignored (if bitwig team takes notice) in favour of newer, better structured (but potentially lower value) requests.