Bug / Feature request workflow

General Discussion
1

@BrennanSingularSound @persist

Hello dear admins,

Is there a way to flag a bug as “fixed” or something like “solution accepted” ?
I thought that adding a #fixed to my bug report would automatically assign it to this new category, but it’s clearly not the case.
Is it related to the fact, that as new user I am not trusted enough ? Or do you have a workflow of your own that I should follow to flag something as solved ?

Today when I read topics, I have often no idea if the the problem or the feature request has been implemented or not. This is quite painful, and if nothing is done it will only grow with time.
I know discourse is not a bug tracker, but in order to organize the forum and make it a useful source of information, a solution has to be found…

  • Deleting the post after it is is solved is not a solution
  • Editing the post, and appending something like - Fixed in the title could be a workaround, but has a lot of limits

Even if I am not a discourse long time user, I feel like categories are the only way to address the issue.
You may provide categories like:

  • #fixed or even #firmware-vX.Y.Z (to be able to specify which version includes the fix).

And of course you could have categories like:

  • #rejected
  • #short-term-plan
  • #long-term-plan
  • …
    It means that some of the categories should be assignable by anyone and some others only by admins, moderators, power-users you name it…

What do you think of this proposal ?

2 Likes
2

If everyone would use it, it might be a great idea.

To my knowledge, Singular Sound uses Basecamp to manage their workflow. At one point they used to use JIRA to track bugs and feature recommendations but I don’t know if they’re still using it.

An interim possibility would be to use the Discourse tags (If they could be set up and used according to each category).

Before starting down this path, it might be good to hear what other users have to say about your suggestion, the use of tags and whether or not they would use the feature if implemented.

1 Like
3

Yes, of course exposing a real bug tracker and keeping discourse for discussions around the product usage and best practices would be a great improvement, but this would come at a cost. Yet it would be a way to provide a much much better follow-up… For both Singular Sound and users.

Adding tags to discourse to provide a kind of status on the requests is, in the current state, probably necessary, but can only be a temporary workaround.

4

Gonna be some tedious work updating all chats with this info.

I’d rather see the effort go into making the product better and generating good release notes that indicate the fix is really done.

5

The problem is that discourse is very nice place to to discuss new features and best practices but not very well adapted to bug tracking and follow-up…

1 Like
6

This topic in itself illustrates why I am asking for a better follow-up mechanism. I have no idea what the follow-up will be on this follow-up request :crazy_face:…

@DavidPackouz, I add you in the loop as this is an organizational topic.

As it doesn’t seem we may have a real bug-tracker exposed to the users anytime soon (even in a simplified form), the only short-term realistic solution may be to have tags attached to topics in order to ease navigation and filtering, as well as provide extra useful information.

Currently, even as member, I have no possibility to create tags. It is not a problem, it just means that only admins can create them as stated in discourse documentation, enabling then their selection in the topic creation/edition:

image

And another important feature, is that apparently discourse can restrict who can tag to a particular trust level.

As a start, here is my proposal:

Status tags

Feature requests

The idea is to provide a high-level idea on the commitment to a particular feature request.
These tags should be set by Singular representatives only. (Maybe it will require that they are granted ultimate trust level…). I think they are quite self-explanatory:

  • #rejected
  • #short-term-plan
  • #long-term-plan
  • #firmware-product-vX.Y.Z
  • #done (for anything not directly linked to a product, like this request for example)

Bugs

All feature requests tags could be used on these topics, plus the following:

  • #acknowledged (Singular representatives only as well)
  • #fixed (Singular representatives only as well): fixed on dev side but not released yet.
  • #workaround (Any user with sufficient trust level, TBD)

Some tags could be added regarding criticality and urgency, TBD…

Categorization tags

The idea is there to be able to provide extra filtering features as well as ensure a mutual good understanding. This categorization should evolve, but as a start I would suggest the following. Any user with basic trust level should be able to set them:

  • #2x2
  • #6x6
  • #quantized
  • #freeform
  • #MIDI

I don’t think we should multiply the number of categories, but those I propose here are focused on the Aeros. Probably some others should be considered to include other Singular products…

Topic lifecycle example

Just an example to show how easy it could be:

  1. I notice a bug, create a new topic, and just add some categorization tags, let’s say #freeform and #2x2.
  2. Someone from Singular sees the bug report and eventually agrees to the fact it is a bug (#acknowledged).
  3. After a first review the bug is seen as quite important and someone from Singular adds the #short-term-plan
  4. Later-on someone proposes an interesting #workaround
  5. The bug is requalified as #long-term-plan
  6. Eventually the bug enters the final triage, and becomes really planned, the tag #firmware-aeros-v3.1.2 is added

This is just an example, there may be a lot of other potential simpler flows.

Workload

  • Admins have to create all relevant tags once and for all
  • The firmware tag has to be created per firmware version (for each product)
  • Each time a release is about to be delivered, admins have to browse the relevant #firmware-product-vX.Y.Z topics, thanks to the filtering feature, ensure that it is consistent with the changelog or requalify these topics.

Conclusion

I do not see this system as a very big overhead for admins (correct me if you feel I’m wrong) while keeping things manageable, although it could provide a certain level of visibility as well as provide extra filtering possibilities for both Singular and users…

7

You’ve put a lot of thought into what you’re proposing but so far, it appears that not many users are requesting or supporting what you are asking for. My countervailing opinion:

  • Users that post their bugs or feature requests are usually following the threads they originate or the posts or comments they add to a thread. If they’re interested, they can readily see how Singular Sound is responding as well as what other users are thinking.
  • The change logs that accompany the firmware release usually document which issues have been addressed or capabilities have been added).
  • For the sake of consistency across the forum, if this were to be done for the AEROS, it should probably be implemented for the BeatBuddy Manager (BBM), the BeatBuddy (BB), and the Maestro.
  • I’d be happy if users would use the appropriate Discourse category consistently. Not all do.
  • Despite yours being the only request, Singular Sound acted on your request for a hash to accompany firmware releases (an extra step and perhaps an unnecessary one as there have been no other users requesting the hash).
  • After visiting other user forums (Cockos being one of them), I don’t see what you’re asking for being implemented in those communities. My point? This is a user community—not a developer community.

I’m not opposed to an improvement to this forum if and when it benefits the majority of users.

8

@persist

When you browse the topics you have no clear idea if finally things have been implemented or not, if your not the requestor. Not only it doesn’t help people posting, but also people who are not member (i.e. potential future customers) and who wants to have an idea if the company is reactive in actually solving issues.

Although the direct link is not clear at all between the changelog content and topics (as a changelog normally refers to ticket numbers), this is exactly what no one wants to do. Especially when potentially relates to something implemented one year ago…

Absolutely, as I said for the categorization tags. Yet the resolution flow (and tags) should be the same.

This is a pure basic software releasing practice, that I should not even have to request. Name me one company not doing that. From Microsoft to Kemper to cover a wide range… Including any js, ruby, java libraries … any packaging system from apt to any app store to docker images, snaps, AppImages… make your choice.

Fully agreed, this is why initially I asked if it was possible to have a separated bug-tracker to keep the forum at usage and best practice level… A dedicated tool for that is always better. I’ve got numerous example of companies providing bug-trackers along a dedicated forum…
Regarding specifically cockos (that do not know as I am using Ardour which oviously has a bug tracker) even if initially they had a bug tracker, it seems that it’s true they turned to a forum where you report bugs. But clearly what they expect from a bug report goes far beyond putting one or two tags in it…

9

@persist

Why not, as a first and easy step, introduce the “Solved” discourse plugin, which seems available for free for all hosting plans ?

10

@persist

Any news ?