> USABILITY > > All bugs marked with the following markers in the status whiteboard > should be fixed: [Hixie-P0]
Hixie is currently going through a process of working out the key standards bugs, under the criteria we decided. As I understand it, this process is related to, but separate from, the P-priority system, which may have other criteria to consider. > The goals of our performance criteria are for a user who switches from > the at-that-point current version of IE to the Mozilla 1.0 build to > not experience a regression in performance that is greater than a > factor of two. (Ideally, of course, there would be no regression at > all. This is simply a goal for a 1.0 release.) Because we have decided to have a stable branch in Q1 next year, and call it Mozilla 1.0, things have become unavoidably more date-driven than they used to be (that's not to say we won't slip if we're not happy.) The Performance team, and anyone who wants to help them, will be fixing dependencies of the performance tracking 1.0 metabug as fast as they can up to the wire. That's all we can ask. > STANDARDS COMPLIANCE > > 1. All bugs marked with the following markers in the status whiteboard > should be fixed: [Hixie-P1] [Hixie-P2] [Hixie-P3] [Hixie-P4] See above. But we are not going to get anywhere near the level of compliance outlined by this document by Q1 next year. As Brendan said in his manifesto, this will take years at the current fix rate. If you want the fix rate to pick up, you have to pitch in :-) > 5. All CSS2, CSS3, XML, DOM2, DOM3, HTTP, etc, bugs that break a > feature in such a way as to prevent adoption should be fixed (removing > the feature altogether counts as a valid fix for these bugs). We'll certainly consider removing features that are extremely broken at that stage (like fixed positioning was turned off for Netscape 6.0.) Gerv
