Bugzilla has several parms for enabling and disabling features. The current list is: - quip - buggroups - buggroupsentry - LDAP - targetmilestone - qacontact - statuswhiteboard - browserinfo - dependencies I also have a patch which adds 'usevotes' to the list. Some of these (buggroup, quip, browserinfo) are checked. Others (target_milestone, qa) are usually checked for the ui, but not in the backend. Some (dependencies) are only checked in one place (Bug.pm's xml output sub), making the param useless. query.cgi's advanced stuff doesn't check any of the params, but thats probably ok, for historical queries, for example. We need to decide which of these params should be kept (Does anyone really want to disable dependencies?), and enforce those which are going to remain optional in both the frontend and the backend.
I was thinking this recently as well. How to enable/disable votes is a serious FAQ, and this param will certainly help. But you are also right about the wider issue - we need to decide which bits of the UI are switchable on and off via params, and which mean people should edit the templates so the field still exists but is never used. Gerv
Yes, this is important. I also think there are situations where you might want to disable dependencies. I've been considering that, actually (on a special case installation). If Bugzilla is used to contain something trivial like helpdesk trouble tickets, their simple dependencies (if any) can be handled by duping -> removing deps makes the UI easier to use. But I agree that we should go through the parameters one by one and reconsider. The above would be trivial to do with a simple template modification, too...
When custom fields arrive ( ;-) ) then thinks like URL and Status Whiteboard will just become default custom fields. But, in the mean time, here's a straw man proposal: Keep: - quip - buggroups - buggroupsentry - targetmilestone - qacontact - statuswhiteboard - LDAP (although we need to make the auth mechanism more modular; it's currently a mess) Add: - usevotes - useunconfirmed (turning this on via votes is non-obvious) The above two items are among our most frequent FAQs. Kill: - browserinfo - this stuff should be in custom templates - dependencies (disabling should be in the UI - it's just cutting a section from edit.html.tmpl) Gerv
Except that while usevotes has global implications (for the footer), use unconfirmed is much more a product thing.
Yes; but, following the principle of usevotes, useunconfirmed's mechanism is much more discoverable if there's a param which says "Turn this on to use UNCONFIRMED. You must then enable it per-product by setting votestoconfirm to > 0." I also think "confirmed by popular vote" is a silly feature. There are enough people with canconfirm around now that it shouldn't be an issue; and it complicates matters. Gerv
True. 111 of bmo's bugs have the string "confimred by popular vote" in them (including this one...), gving about 0.7% of bugs which have been confirmed this way. When you remove the 45 INVALID/DUPL/WONTFIX ones, that leaves 0.04% - ie not enough to be worth it.
Reassigning bugs that I'm not actively working on to the default component owner in order to try to make some sanity out of my personal buglist. This doesn't mean the bug isn't being dealt with, just that I'm not the one doing it. If you are dealing with this bug, please assign it to yourself.
Assignee: justdave → general
QA Contact: mattyt-bugzilla → default-qa
Click the URL field to see bugs we filed for each parameter which should go away, based on one of our Bugzilla meetings: https://wiki.mozilla.org/Bugzilla:Params Other parameters will be left untouched, at least for now. In any case, we should have one bug per parameter, not a meta-like bug.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.