All, Recapping some of what has been already said recently, here is my new official policy on bug reports/feature requests:
May be entertained: Reports of crashing bugs, reports of data corrupting bugs, patches to fix bugs, patches to add new features or enhance existing features (assuming the patches are in-scope and competently implemented), patches to port to new platforms, patches to provide documentation for undocumented functionality, links to useful tutorials and documentation, links to related software that integrates with or is useful in conjunction with Non, financial contributions, sponsorships, commercial partnership offers. Not to be entertained: Requests for new features, requests for new features disguised as bug reports, requests for changes to existing features, requests for fixes to non-crashing, non-data-corrupting bugs (i.e. situations in which the label "bug" is debatable), comparisons to other products, Codes of Conduct or other attempts (veiled or blatant) to suppress freedom of speech, release schedule pacts/pledges. Your loophole to request new features requires that you change your perspective and ask "Is there a way to do [very specific well defined thing] with Non?" You'd be surprised how often the answer is "Yes, like so." (but please be considerate and do read the relevant documentation and search before asking). These types of questions are much less burdensome to deal with than statements in the manner of "I want you to add [very specific] feature to Non [with no explanation of the necessity of the feature and without bothering to consider the possibility that a more general feature already exists either within Non or elsewhere which covers the (unstated) use case in question]." A large percentage of the time, the answer to "Can Non do X?" will be yes, the rest of the time the answer will be "No (and on purpose), but there is a perfectly good program Y which does just that, so just use Y in conjunction with Non, which is kind of the whole point of having a modular system in the first place." Sometimes the answer will be "No (and on purpose), and there isn't a program to do that. It doesn't belong in Non but you're free to write one yourself." It is only in the case where there is literally no other way to do X (fast, light, and effectively) outside of Non and X is seen to be necessary to the goal of music production or of extremely high utility, that I would personally consider it worthy of development. However, it should be noted that my threshold for what I will develop myself and what I will accept in the form of submitted patches is very different. Just because I don't think something is useful enough for me to spend my time doing, doesn't mean I won't gladly accept a patch for it if it makes my life easier and doesn't make the product any worse (i.e. bloat, crashes, slowdowns, additional dependencies). Most of the feature requests I get are in the category of "already possible," either within Non or using another excellent program. 50% of the time that other program is "sox" or more generally, "Linux command line environment." A lot of perceived "bugs" are also just things that are universal gotchas in JACK, in DAWs in general, or in simply music production in general (i.e. difficulty syncing things, difficulty understanding gain staging, etc. predates even the use of computers in music production). Everything regarding audio/MIDI synchronization is in this category. There's really not much that I can do about things like that (unless/until I conquer the laws of physics and the dimension of time). In case any of this seems unreasonable to you, please understand that the Non suite comprises at least 13 projects (not counting NTK) designed, implemented, developed, tested, documented, and maintained by one man in his spare moments (of which he has precious few). And always bear in mind the obligations and responsibilities of a free software developer: Obligations: none whatsoever. Responsibilities: those he chooses to take on at any given moment.
