Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
(shaver's input) |
(Add chofmann, reorganize) |
||
| Line 1: | Line 1: | ||
== | = Code = | ||
== UI == | |||
=== Simpler Layout === | |||
Collapse all the non-requried and less-frequently used fields by default. This would simplify the layout of bug reports and make it less daunting for new participants. Allow user prefs to control what gets expanded and collapsed by default for each user. More familiar, easier for new users, streamline navigation. -- chofmann | |||
=== No default UI changes === | === No default UI changes === | ||
| Line 5: | Line 11: | ||
I don't want any changes to the bugzilla UI. Firefox's needs are clearly sufficiently different from the rest of the world's that accommodating them is painful and invasive. I just want the tools to build a UI and workflow that suits us. -- shaver | I don't want any changes to the bugzilla UI. Firefox's needs are clearly sufficiently different from the rest of the world's that accommodating them is painful and invasive. I just want the tools to build a UI and workflow that suits us. -- shaver | ||
=== | === Text Area Visible On Filing === | ||
When I'm filing a bug, the text area in which I am to describe the bug should be above the fold. Everything else (including the component it's in) is subsidiary to the bug description itself, and should be farther down (or invisible -- why do I care who the default CC: is? why would I ever change the QA contact?) -- shaver | |||
=== Fix Mid-Air Collisions === | === Fix Mid-Air Collisions === | ||
| Line 29: | Line 31: | ||
No mandatory fields; all fields should be able to be multi-valued (this would let us solve the resolved-vs-fixed-keyword problem, as well as "vista and win7 but not win XP", and would let us have bugs in multiple components, multiple assignees for bugs, etc. -- we can argue | No mandatory fields; all fields should be able to be multi-valued (this would let us solve the resolved-vs-fixed-keyword problem, as well as "vista and win7 but not win XP", and would let us have bugs in multiple components, multiple assignees for bugs, etc. -- we can argue | ||
about whether we want to permit that in different parts of our product as a matter of policy, but the mechanism should be there) -- shaver | about whether we want to permit that in different parts of our product as a matter of policy, but the mechanism should be there) -- shaver | ||
=== Deprecation === | |||
Ability to orphan components/bugs/flags/etc. without a ton of noise. I should be able to make "fixed1.4.1" never show up in the keyword autocomplete without having to do a pile of bug-munging. -- shaver | |||
== Server == | |||
=== API === | |||
A full REST+JSON API, so that anything currently possible through the bugzilla web UI (read or write) can be done through another program on another server. -- shaver | |||
=== Server-Side Hooks === | |||
Server-side hooks for basically every action, so that f.e. I could write something that did component watching the way I want without having to even discuss it with upstream, let alone make it sufficiently general to be accepted. -- shaver | |||
== Speed == | |||
=== Parallelization === | === Parallelization === | ||
| Line 37: | Line 55: | ||
Intelligent caching of API and web-UI results, based on modification time for bugs; "generate on change" via the server side hooks would be a DIY option, certainly. -- shaver | Intelligent caching of API and web-UI results, based on modification time for bugs; "generate on change" via the server side hooks would be a DIY option, certainly. -- shaver | ||
= Configuration = | |||
=== Reduce Product and Component Count === | === Reduce Product and Component Count === | ||
| Line 52: | Line 66: | ||
Remove platform and OS, use keywords for them instead (until the multi-value thing is resolved above) -- shaver | Remove platform and OS, use keywords for them instead (until the multi-value thing is resolved above) -- shaver | ||