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)
I don't think the last point ("cheaper" issues) is clear as to whether that should be essential or aim-to. The paragraph as written did not quite follow through for me. LAME is a good example though, as we did have definite plans for a Windows installer for LAME, which would save a great deal of support hassle. Basically it got sidelined due to the delays deciding on the location of an offshore LAME page, and then forgotten due to lack of manpower. In my view this should have been done for 1.4. As it is now, it should probably be a priority not aiming for 1.4, i.e. maybe it gets done in 1.5.0? GA
LAME installer is ceretainly a candidate for being an essential, and could be worth discussing on the list. If LAME issues will cost you and Richhard 50hrs over the lifetime of 1.4, and developers can avoid that completly with 3hrs work on the installer now, then it should in my view be an essential. Those 50 hours will lead to better error reports on other issues, which in turn will save at least 3hrs of developer time over the lifetime of 1.4. It makes clear 'economic sense'. The argument is a little complex in some ways, and in real life there are more imponderables and unknowns, but that is what I was getting at.
Generally a clear economic benfit is harder to show, so the default when trying for the economic argument should be aim-to. It's only where a convincing case of the economic benefit can be made that we should promote an issue like that to an essential. JC
Generally I agree with what you've written about guidelines. IMHO though, up to a fortnight ago we were (wrongly?) interpreting essentials as "crash-only", but once a release timetable has been abandoned I suppose it makes sense in practical terms to take a slightly laxer view. The wording on the arrow key errors and what you now see on importing 1.2.x projects is verging on the bizarre IMO and reflects badly on the program, so I am going to have a go at the "destroy" message on the Wording page (even assuming it can be made to refer only to 1.1.x and earlier as intended). GA
We did previously have non-crashing issues in the essentials. The failure to open Monty's projects, with the proviso that he supply a sample soon, was an essential. It was a bug but not a crash. The icon issue reported by Vaughan, assuming it is not just a problem with his fork or with a custom theme of his own that he has enabled, would in my book always have been an essential. It's a regression. It's also a bug, in that it's not what the programmer intended, and it should be easy to track down. Making it an essential is not 'being laxer'. JC