Discussion about Writing a good feature request

About Bitwish
1

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:

  1. The title of the feature request should be clear and descriptive.
  2. The body of the request should be as concise as possible.
  3. There should be a request for a single feature per request (as opposed to “also feature Y and Z”.
  4. Tags would ideally be taken from a relatively short, canonical list.
  5. 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.

  1. 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.
  2. 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.
  3. 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).
  4. 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.
  5. 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.

1 Like
2

Thank you so much @chalkwalk for your thoughts. A question before getting into details. Have you checked the process we have defined so far? It is based on the same principles that you mention. Writing a good feature request and Promoting a draft step by step

3

I have indeed read both of those. What wasn’t clear to me, as a user, was: what exactly do I need to do. Moreover is the process described in place? Which agents carry out which steps? In other words: what do I do/should I expect once I submit a draft: do I take action? does someone else take action? Are these actions driven by automation? Do I need to request a review etc. I’m talking about a more formal and structure process to help navigate the process.

1 Like
4

I have moved your ideas to Writing a good feature request and I have made the first post wiki editable, so we can all work on the definitive page informing users about how Bitwish works.

Next, I will reply to your proposal in detail. Again, I’m very thankful for all the thought you have put on this.

5

(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.

6

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.

7

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
8

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.

9

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!

10

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
11

I have written the first paragraphs and “Drafting together”. Tomorrow more.

12

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…”

13

I had literally written “third person” in this sentence but then I removed it. I’ll add it now, thank you!

1 Like
14

I have started drafting Best practices: Title, Tags, and Description.

Next: best practices for each of the sections.

15

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:

16

I guess they meant “passively voiced” rather than third person; in any case: this is looking great! Thanks for all your hard work.

2 Likes
17

@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

18

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.

19

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?

20

Edits welcome! I have tried to keep it concise.