--Wurblzap 10:38, 2 Feb 2006 (PST)
- UI consistency and ease-of-use
- Replace links by buttons (less data loss, more intuitive)
- Distinguish required fields from optional fields
- Use two kinds of CSS classes for everything:
- Entity (Error message, bug ID, summary, field label, ...)
- Value (severity "critical", status "RESOLVED", ...)
- Customizable workflow
- Customizable status list
- Freely maintainable table of allowed status changes
- Customizable resolution list
- Make "duplicate" relation a relation instead of a resolution
- Unlimited hierarchy in place of products/components
- Classifications replaced by non-hierarchical "tags"
Non- or semi-technical side-goals:
- Define set of CSS classes
- Yet another re-thinking of the review process
Some of the goals seem to me to need a major overhaul of Bugzilla's core. Especially the (in my mind much needed) workflow takes Bugzilla pretty much apart. This is the kind of change which, when complete, warrants a major version number bump. It seems to me this cannot be done by way of the same kind of branching like we do for release candidates.
I'd say we need to branch major version 2 at some point, so that the trunk is what ends up to be Bugzilla 3. In this scenario, normal development will happen on the "2" branch; the trunk will be pretty much broken for a year or so, being open for Extreme Measures.
Alternatively, we could do the overhaul (read: re-write) independently, in a different repository. We could drop it onto the trunk when it's ready.
|Get rid of SendSQL and friends||2.26|
|Re-work the front page||2.24|
|Re-work the bug view page||2.24|
|Finite state machine re-write||Customizable status list||3.0|
|Maintainable table of allowed status changes|
|Re-write Flag.pm and FlagType.pm||2.24 only if not a lot of work required, otherwise 3.0 (if needed there)|
|Remove globals.pl||Remove versioncache||Only if not a lot of work required, otherwise never (read: don't put it into 3.0)|
|CSSification||CSS class set definition||2.24|
|Template by template|
|Customizable status list||pre-3.0|
|Maintainable table of allowed status changes||pre-3.0|
|Remove versioncache||Only if not a lot of work required, otherwise never (read: don't put it into 3.0)|
- AJAXification is not a goal as such in my opinion. I don't mind putting it to use where it's useful; I just don't think we want to put much work into AJAXifying something which is working well already at this time.