How to process requests that contain many features

We need to decide on this point before more topics like pop up and grow.

We agree on this principle:

So what do we do when a proposal contains in fact several feature requests?

(I’m going to move / quote several comments about this from other discussions.)

From the Better piano roll discussion…

1 Like

Yes, you have a point. On the other hand, we are already seeing that having a request with the title “Better piano roll” is acting as a magnet. If things continue this way, we will end up having one of those threads with 200 comments that is great for ranting but impenetrable for those who want to take action.

One way to combine both needs could be to keep sticking to specific requests in #drafts and #features, and then convert general requests like this one into a task force where people can coordinate votes and efforts across requests. We could rename this topic “Coordination of piano roll requests” or something similar, and move this topics to #about-bitwish for now.


Hi, I am suggesting to convert this discussion in an “umbrella feature request” (and, in general, vague and yet widely supported requests like this one):

You are invited to join this discussion.

Converting this topic [] in an umbrella feature request would meant that we would just list the relevant #piano-roll features, and the actual work would be put in drafting the specific feature requests, each one in their own topic.

1 Like

I like it in principle, but what of the votes applied to such topics? I think at a minimum it should be made clear the intent of such topics is more to promote discussion and branching requests, rather than to vote on like in reddit. What do you think?

1 Like

Technically we have two options for these multi-feature conversations:

I imagine the topic itself very similar regardless of whether it accepts votes or not: a first post with a short intro and links to the related features, followed by a discussion that focuses on extracting more feature requests.

I am with @ultratot that the priority is to promote discussion and branching requests. Topics without votes in #about-bitwish (or a new category just for discussion) would be better for this than #drafts with votes.

It seems like an “about-bitwish” type option is preferable, but not in the about Bitwish category. It seems like a category (without votes) just for such discussions would make more sense (feature-discussions pre-draft-discussions or similar?). You could then set the expectation that in the new category, you have a conversation, the output of which will be several drafts (which follows the normal flow).



Why not simply create a new category without voting for general discussions about feature requests?

“About Bitwish” doesn’t feel right for this type of discussion IMO which seems more appropriate for stuff about Bitwish itself.

1 Like

Yes, this is what we were discussing just above.

So what about this new category:


Discussions leading to feature requests

Placed between Drafts and About Bitwish on Categories - Bitwish

With this addition, the “color schema” (just kidding) for categories trembles. I’m not very happy about the current one, and I’m not sure what tom pick when adding a fourth category. I can come up with something, but if you have ideas, please share them here.

I was thinking about having something like #meta-request for categorizing features. Maybe we can have separate vote for them, and they’ll let us to see overall direction which people think Bitwig should focus and improve on.

The key theme coming out of this discussion seems to be “specificity”. Specifically worded requests about specific feature ideas. Voting on generalised discussions dilutes the potency of the vote as was mentioned previously so I’m in full agreement that the actual requests should be specific in nature with a narrow scope and clearly defined parameters.

With regard to the discussion topics, I like this idea and I think it has potential to create lots of community buzz and new ideas, and hopefully feature requests that would not have been made otherwise. A separate category with no voting as described by others in this thread seems like a practical way of achieving this. It could also be useful as a way of aggregating requests in a similar way to the use of tags.


New category #brainstorm created: Categories - Bitwish

The title and the description can be changed, if anyone has better suggestions.

Nice, I’ll put some thought into the description after some sleep if it is still needed at that point