UniAudio Development: Difference between revisions
added appropriate versions stuff |
Corrected some text and added item |
||
| Line 1: | Line 1: | ||
This document is used to collect ideas what | This document is used to collect ideas about what has to change to start with UniAudio development again. This is by no means a complete document, so please help to finish it! | ||
=== How to improve development === | === How to improve development === | ||
| Line 7: | Line 7: | ||
** If the card is not onboard, we should try to make it available to 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 not, we have to find a tester that helps the developer | ||
** If there is no tester, and the developer has no hardware, than | ** If there is no tester, and the developer has no hardware, than we should not work on that | ||
* Create a document that describes in '''full detail what''' a tester has to do and '''how''' | * Create a document that describes in '''full detail what''' a tester has to do and '''how''' | ||
** There are various ways | ** There are various ways in which UniAudio outputs usefull information, those 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 | * 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 | * We need clear milestones | ||
* Have a test plan for '''every''' major release | * Have a test plan for '''every''' major release | ||
** This can only work if we have a number of testers for UniAudio | ** 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, | ** It would be nice to have a list of "tested" vs. "untested" hardware, not 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 | * Make it easier for testers and users to find appropriate versions | ||
| Line 20: | Line 20: | ||
** Record changes, preferably in "non-developer speak" | ** 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 | ||
* have more then one developer on the project (less dependency, multiple eyes on the same problems, fall back, knowledge exchange) | |||
=== How to raise money === | === How to raise money === | ||
* still empty | * still empty | ||
Revision as of 16:54, 16 February 2007
This document is used to collect ideas about what has to change to start with UniAudio development again. 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 we should not work on that
- Usually, it does not cost that much to purchase a sound card
- Create a document that describes in full detail what a tester has to do and how
- There are various ways in which UniAudio outputs usefull information, those 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, not 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
- have more then one developer on the project (less dependency, multiple eyes on the same problems, fall back, knowledge exchange)
How to raise money
- still empty