Discussion about Writing a good feature request

(Sorry for the lengthy reply but there is a lot of sauce in this proposal.) :slight_smile:

@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. :sweat_smile:

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. :slight_smile: 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.

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?

1 Like

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 :slight_smile: 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.

1 Like

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!

1 Like

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 :slight_smile:

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. :slight_smile: 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:

  • Many drafts are written in first person. The authors make them “theirs” in various ways. Referring to “users” or even “you” is much better, and personal preferences or other personal details are not really interesting unless they can be made generic to many.
  • Very few explain the problem in the section titled “What problem(s) would this feature resolve?”. Most keep explaining how great the feature requested would be. Specifying the problem a feature request is very useful, even crucial.

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.

1 Like

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