Are we changing policy so that non-crashing issues are now included here (in the essentials section)? If so there are others that could be considered as candidates for this section. GA
- We've never had and probably will never get watertight criteria for what is an essential and what isn't. Non crashing issues have always been candidates for being essentials. I'm sure we've had some as essentials in the past.
- A reproducible crash is always an essential fix.
- A regression in a previously working feature is generally an essential fix. It is much more serious than a defect in a new feature, since it is a reason a user might have to not upgrade.
- An obvious bug anticipated to be relatively easy to track down and fix is generally an essential fix. An old bug that is hard to track down is generally not, unless its impact is severe. Obviously we'd like to clear hard to track down bugs and old bugs too, but we don't have the man power for that.
- A feature that some users think does not behave as it should, but that is not actually a bug is generally just an aim to. It works as designed, but the design is being questioned. It doesn't reflect as badly on the project as a bug.
- Some user issues that are 'cheaper' to fix than to use-as-is are candidates for being essentials. They need discussing on audacity-devel. For example, if lame installation were a hugely complex procedure for the user, we'd want to fix that - assuming a small amount of effort by the developers could save a very significant amount of work supporting users - that could justify holding up a release to fix. The idea is that we'd save a lot of time for the team as whole. Generally such issues are aim tos.
Gale, these are just my thoughts. If you or anyone else has suggestions for making it simpler or more effective, by all means suggest ways to change this.James 15:15, 17 October 2007 (PDT)