Audiotool board archive

The feature request and bug report boards have always had topics pinned to the top explaining how to contribute to them and specifically asking to use the search function and not to create duplicates. Anyway I just edited them a bit to stress those points more.

Wrong board. Not a feature request.

Sorry. Reinstated.

Thanks for your suggestions.

I'm not in favor of deleting fixed entries. They often serve as a source of information for users having similar problems. We sometimes have those "happens to me again" posts and it's really helpful to not start the research from zero. They will be pushed down automatically by active topics that stay on top.

Duplicates may contain valuable information for getting a problem fixed or even workarounds. Ideally they wouldn't exist at all but even the most aware user cannot always know which bugs share the same cause. I simply close them to keep the information together as close as possible. I try to keep the most active and informative thread open. This isn't always the oldest, though.

Deleting a declined request isn't a good idea either: Sometimes the circumstances have changed and an idea that was previously impossible or inappropriate is now feasible. This also protects us from some duplicates we'd have to decline over and over again (at least as long as some users use the search ... which we should definitely improve).

I close bug reports that were caused by a temporary situation (like a server outage) where it simply doesn't make sense to resurrect it after several days because the cause has most likely changed.

(TBC)

Rather than deleting the entries we should provide a way to filter them (e.g. by their tags). Users and devs could hide closed issues. This presumes that all issues are tagged correctly and consistently. I'm working on this but there's a lot of old stuff I simply don't know how to handle. There are mostly four states:

1 - new: no tag attached, we haven't read it yet or don't know how to proceed
2 - feedback required: unusable state; ongoing discussion
3 - accepted: the "open"-tag means that an entry is understood well enough that we accepted it as starting point for our internal processing (tech-details, assigned priority, category, dependencies, etc.).
4 - ended: fixed, rejected, not a bug, cannot reproduce, duplicate - some might be resurrected if the circumstances change

The filter should be able to show new=1+2, open=3, done=4

I like your idea of categorizing the feature requests and bugs by component (app, website). We do that internally but not in the board. I'm not sure how to present that to the user. Separate boards would introduce a third level for navigation. This also would require every entry to be categorized which can be hard to decide and introduces more work for the moderators whenever the user fails to make a "right" decision (-> move entry). Using tags would allow to keep the existing structure but might get messy with the existing tags we use for the state (and I don't know if regular users may edit the tags).

Another challenge would be to define those components: "Website" and "App" is easy. But what about "Timeline", "Pulverisateur", "Player", "Account", "Booster" ... the more components we define the more overlapping we will have to handle. Shall there be a "Unknown" component for everything we didn't cover? Users might decide to throw everything in there.

I'll just stop now and leave this discussion open for further ideas.

This should be covered by https://www.audiotool.com/board/feature_requests/add_a_search_filter and https://www.audiotool.com/board/feature_requests/ordering_options_for