Hey all,
Similar to what we will be doing in the requests section, we will be reviewing and tagging the Aeros Bugs as well with the following tags:
- fixed
- in-dev-timeline
- under-investigation
- not-a-bug
- resolved
As always,
Keep rockin’ 
2 Likes
In order to streamline it would be nice to tag as well duplicates (this is true as well for requests).
Hello @JusDandy ,
I guess you’d better create a bug report here… This is completely off the subject of this topic (even if legit). I do not see why anyone from Singular Sound would reply to you here.
1 Like
I’m a little forum challenged how do I do this?
Sorry I see your link
Hey there @JusDandy, yes please post in the related section of the forum, always start a new topic by pressing the blue circle with a plus sign
But first, make sure to be in the correct part of the forum, and maybe double-check someone hasn’t already requested it! I’ve seen that you have opened separate posts so I imagine you’ve figured this out, I will delete the erroneous posts on this topic, thanks.
That’s a good point, will see how I handle this, as many things can be duplicated in batch requests, but still not be a total duplicate
Brennan did I put my post in correct place the 2nd time?
Indeed!
1 Like
Yep, I agree this not always the case that two redundant topics completely overlap. Yet I see it happen all the time…
One good practice to push within the forum to ensure you can more easily flag duplicates, is to encourage people to dedicate one topic to one problem/request (1-1 mapping), and avoid wish-lists in topics.
One possibility to enforce this is to use discourse templates…
We can look into that! Thank you.
Apart from that I have the same to say as what I already said in Organization of the Forum: Aeros Feature Requests…
I could argue on the meaning of fixed and not a bug vs rejected, but I think you’ll got my point in that other topic… It lacks a flow and clearly defined statuses.
Hey there,
It’s been a fluid process as of yet to see what works and what doesn’t, didn’t want to write up definitions that weren’t 100% yet. That being said, now that things are more set, we can clearly define them for you, I’ll write something up and update the OP.
Thanks for your feedback.
Hello @BrennanSingularSound
As suggestion…
- Dark blue node represent final states
- Greenish nodes informative states
- Light blue nodes optional states
- Yellow notes represent associated tags
Even if you don’t want to adopt this flow, what I would expect is this kind of explanation, clarifying the meaning of tags, when they occur within the process, and possible flows…
It could easily get more complex (I didn’t represent triage actions for example, and it could be interesting… how something gets promoted from short-term plan to next release or from long term plan to short term… vote from users for part of it ?) but it looks like self-explanatory and quite concise while providing a huge improvement in term of visibility… Moreover I doubt it’s implying more work to maintain than the set of tags you have suggested…
Another point is that it unifies flow between feature requests and bugs…
Hey again, thanks for your suggestions, this is the method we are sticking with for now. We appreciate your feedback, as it helps make our end results better and come out quicker!
This topic will be closed now, the link to the new Aeros Bug Tagging system post is in my last reply. Please forward any responses there, thank you!
In case you can’t see that click here