Difference between revisions of "For Developers"
From Audacity Wiki
(Building first.) |
(link.) |
||
Line 12: | Line 12: | ||
Audacity aims to be a '''simple to use''' but '''powerful audio editor'''. We're open to exciting new features, bugfixes (yes please!) and new ideas, and at the same time, we need to do things a certain way. | Audacity aims to be a '''simple to use''' but '''powerful audio editor'''. We're open to exciting new features, bugfixes (yes please!) and new ideas, and at the same time, we need to do things a certain way. | ||
− | * We want to avoid making Audacity over complex. The majority of our users are newish to audio editing. The simple things ought to be easy to do for them. The more advanced things can be there, but should not 'get in the way'. Many of our users do not read the manual. Follow our ''[[Design Topics|design guidelines]]'' to make the user interface consistent and more discoverable. | + | * We want to avoid making Audacity over complex. The majority of our users are newish to audio editing. The simple things ought to be easy to do for them. The more advanced things can be there, but should not 'get in the way'. Many of our users do not [https://manual.audacityteam.org/ read the manual]. Follow our ''[[Design Topics|design guidelines]]'' to make the user interface consistent and more discoverable. |
* We don't know that you will stay around after you have contributed code, so new code should follow our ''[[CodingStandards|coding standards]]'' so that it is more maintainable by us. | * We don't know that you will stay around after you have contributed code, so new code should follow our ''[[CodingStandards|coding standards]]'' so that it is more maintainable by us. | ||
* To get the best from contributing to open source, you should become aware of the ''[[Community|community]]'' beyond the developers who support users, get feedback, test and document Audacity. The experience they have can often help what you write be better, and save you time too. | * To get the best from contributing to open source, you should become aware of the ''[[Community|community]]'' beyond the developers who support users, get feedback, test and document Audacity. The experience they have can often help what you write be better, and save you time too. |
Revision as of 22:51, 13 November 2019
|
Guides and Connecting
Why subscribe? We have found time and again that good programmers are overly reluctant to ask for actual help. It is usually our fault, not yours, if you can't compile. Our instructions and guides are not always good and up to date. Especially if you have difficulty compiling Audacity, reach out to one of us on the mailing list, and talk us through how far you get. Together we can work to fix it, and to fix the compiling instructions, so that other people have an easier time in future. |
Topics for Developers
Building
- Our code on GitHub
- Building On Windows
- Building On Linux
- Building On Mac
- Building On Cygwin (Deprecated/Not Maintained)
- Building The Manual
Developer Documentation
Development Activity
- Next Release that we are working on
- Wording changes required in the app
- Wish-lists for 2.3.2
- Active Development Projects
Quality Assurance
- Coding Standards
- Code Review
- Using Bugzilla
- Bug Lists
- Bug Counts
- Bugzilla
- Design Topics
- Wording and punctuation guidelines
- Website ToDo
Builds for alpha testing not listed now
Ideas? Want to Contact Us?
Didn't find what you were looking for? Here are various ways to contact us.