Update:
I’ve edited the example ticket, as if it was a real one. However, it shouldn’t be treated as one, the italic text is nothing more than filling material and could as well be “blablabla…”.
The subject of my question was:
Is it possible to create a new (temporary) sub-forum “Road map Version 4 Plug-ins”?
Can this forum serve as a repository for feature requests, each under one topic (so called “tickets”)?
Should those tickets have a formal structure and layout?
How should these tickets be build up in order to facilitate a formal request to the development departement?
When I was reflecting about the new version 4 of plug-ins, I came to the conclusion that a vast amount of features and properties (at least 15 that come spontaneously to my mind) of track have to be considered. I thought it would be a nice idea to have all these things exclusively in one place, where they could be easily commented, modified, pushed, deleted and summarized.
It would be especially valuable if the developers took part in the process by declaring and commenting what is achievable within their ken and scope.
Maybe an other example helps to illustrate the complexity.
We address the developers with a simple feature request for a preview button. I fear, if we aren’t explicitly saying what we (as plug-in writers) want they will react quite cooly. After a considerable time one may ask back for details such as “Shall this button appear in every version 4 plug-in?”, “Where does the sound for the preview come from?” and “Is the preview played by Nyquist or Audacity?”. If we had made a formal ticket with our picture in mind, the experts had less to ask back and could catch up requests that are not easily implemented.
Our ticket for the preview button could state, that we want a header flag to enable and disable the button. When it is pressed, the plug-in should be called again on the same track and the preview is played by the plug-in itself. A visitor who reads this ticket may notice that Nyquist doesn’t know how long the global setting for previews (10 s normally) is. That would be a point under “Dependencies” where a property “preview-length” would be added or some other mechanism to get this value.
Any ideas that bring us easier and faster to our goal are appreciated.
Very few developers visit the forum.
The system that is currently in place for communicating formal proposals to the developers is through a “Proposal” page on the Audacity wiki. This is where we need to arrive.
There is a list of all such proposal pages here, some of which have now been implemented: Missing features - Audacity Support
Even when a formal proposal has been written there is no guarantee of a quick response from a developer - they all have their day jobs and life outside of Audacity as well as their own personal areas of interest in Audacity development. The process can be painfully slow, but nevertheless great things have been achieved.
You may have noticed that the Nyquist board is one of the quieter corners of the forum. In the last 4 months there have been only 12 topics discussed, so I don’t think that we need to separate an area off further. What I would propose is that posts that relate to these areas should be “tagged” by their subject title. For example we could prefix the the topic title with “version 4: …”
Taking the example of your “ticket”, it could be posted in this section of the forum with the topic title:
“Version 4: new Entry in the property list of track”
Relevant “tickets” could then be found quite easily by looking in the Nyquist board home page: Nyquist - Audacity Forum
The forum software also includes a feature for adding a “post icon”. Unfortunately I don’t think this feature is accessible for vip’s, but I can add post icons to all “version 4” topics so that they are more visible for sighted users.
I can also add a “sticky” post (one that stays at the top of the topic list) with an index of links to all “version 4” topics.
I don’t think that we need to go overboard with formality at this stage, though clear separation of the main points, as per your example ticket, will make the job of transferring the information to a formal wiki proposal much easier. The wiki proposal will need to be clearly structured.
Yes, I suggested about ten posts ago to open a wiki page. However, there will be a great deal of properties and “Version 4” features, that hardly go on one page and neither on separate pages, without overflowing the category.
I guess you are best able to sort those tickets out and bundle them, as soon as they are ready to be uploaded. The first step is anyway to launch the property list itself, i.e. a proposal for it.
I’ve been experimenting recently and patched the file that is responsible for the passing of the s variable.
Now the track variable is also passed with the same memory address of s, i.e. the same sound. A property list is also rudimentary initialised. It holds for the time being only the samplerate, the length and the number of channels (2 = mono!). Much more isn’t available in NYX.C. I guess that an new external modul will eventually gather the information we want. The specialists will know where to look for.