Posted
Hi Andre
I go right to the main topic, in my opinion using forum for bug tracking, bug reports, issue management is not an efficient approach.
My suggestions are:
1. a dummy github repo for issue reporting so that we can use the builting issue tracking and status checking features also we can check previous issues better and easier than this forum
2. Online Form and Trello mixed: in this scenario we can check the status of features and bugs and issues in a canban board and then after we made sure that the information we want is not there let it be a feature request or bug report, now using an online form like google or microsoft online form we can send you any kind of request feature, issue, bug, ... and not only you can have a database of all the entries with ability to statistically analyzation, but also you can then move the appropriate ones to Trello board with corresponding comment and detail and/or reply the submitter to post hat topic in forum if it's not related to Trello or just a reply if it's bit appropriate at all.
I highly suggest the second approach, and am available to do anything that you might need for that.
about change logs:
would you please make the change log link more visible, in fact it can be a separate menu rather than going to information then change log
secondly, I think it might be good if the release date also be included in change log
my best regards
Navid
Fr., 25.11.2022 - 12:58 Permalink
Thanks for taking the time to evaluate this and offering your help. We already pondered this multiple times. We do have an internal tracking system but have yet hestitated to make it public.
Apart from open source projects, which are of a distributed and collaborative nature by definition, I am not aware of any major software publisher doing this.
Publicly visible tracking of every feature request and bug report would certainly offer maximum transparency and be helpful in a technical sense, but this direct and unfiltered form of communication also adds significant workload, distraction and conflict to the mix. It would inevitably lead to debates and fights over priorities that are difficult to resolve to everybody's satisfaction. Much diplomacy and focus is required to deal with this. We don't currently have the resources to handle these additional tasks.
You can save a bookmark to the change log, by the way. It keeps the same URL indefinitely. One version often also includes multiple builds published at different dates.
Sa., 26.11.2022 - 04:36 Permalink
Thanks for your clearly understandable explanation, I totally understand the situation.
as for the use cases of bug tracking system with public access I disagree and can refer to "Xojo" which is not an open-source product but have this feature and also all the Atlassian products or Jetbrains, these are just some examples, and all provide high amount of as you mentioned "transparency" for details on bugs and features
and for change-logs, I still think that having date in logs and even different entries that each build resolved what might be useful for tracking the changes alongside with a better searchable bug tracking system.
Thanks and have a great weekend
Sa., 26.11.2022 - 11:22 Permalink
Software engineering is a very different market with clear requirements and goals.
With music composition, things are more subjective and personal. Individual priorities and workflows vary widely. Potential features and future road maps are on uncharted territory and thus every decision is more consequential and "political". Opening that up to a democratic process might tear us apart in a dozen different directions where we spend more time arguing in public that doing actual development.
