Difference between revisions of "UniAudio Development"

From NikiWiki
Jump to: navigation, search
(added experience database and Uniaud API suggestions)
(added appropriate versions stuff)
Line 16: Line 16:
 
** It would be nice to have a list of "tested" vs. "untested" hardware, nut just a list of what should work
 
** It would be nice to have a list of "tested" vs. "untested" hardware, nut just a list of what should work
 
* Standardize the build environment with the help of Christian Langanke
 
* Standardize the build environment with the help of Christian Langanke
 +
* Make it easier for testers and users to find appropriate versions
 +
** Follow a strict version numbering scheme
 +
** Record changes, preferably in "non-developer speak"
 
* Document the Uniaud API so other developers can put it to use
 
* Document the Uniaud API so other developers can put it to use
  
 
=== How to raise money ===
 
=== How to raise money ===
 
* still empty
 
* still empty

Revision as of 14:25, 16 February 2007

This document is used to collect ideas what must be changed to start again with UniAudio development. This is by no means a complete document, so please help to finish it!

How to improve development

  • Always try to make the audio hardware available to the developer or have a tester you can trust
    • Usually, it does not cost that much to purchase a sound card
      • Especially compared to the actual money that was spend on the developer!
    • If the card is not onboard, we should try to make it available to the developer
    • If not, we have to find a tester that helps the developer
    • If there is no tester, and the developer has no hardware, than it we should not work on that
  • Create a document that describes in full detail what a tester has to do and how
    • There are various ways that UniAudio outputs usefull information, they have to be listed and explained
  • Record user and tester reports in an "experience database" so the developer(s) can relate changes to effects more easily--also at later points for previous versions
  • We need clear milestones
  • Have a test plan for every major release
    • This can only work if we have a number of testers for UniAudio
    • It would be nice to have a list of "tested" vs. "untested" hardware, nut just a list of what should work
  • Standardize the build environment with the help of Christian Langanke
  • Make it easier for testers and users to find appropriate versions
    • Follow a strict version numbering scheme
    • Record changes, preferably in "non-developer speak"
  • Document the Uniaud API so other developers can put it to use

How to raise money

  • still empty