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 …
@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:
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:
- I notice a bug, create a new topic, and just add some categorization tags, let’s say
#freeform
and #2x2
.
- Someone from Singular sees the bug report and eventually agrees to the fact it is a bug (#
acknowledged
).
- After a first review the bug is seen as quite important and someone from Singular adds the
#short-term-plan
- Later-on someone proposes an interesting
#workaround
- The bug is requalified as
#long-term-plan
- 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…