Customizability vs. Shipping a Good Product

[Gervase Markham]

Max Kanat-Alexander wrote:
> 	In particular, I found the section "The Question of
> Preferences" very enlightening, and I think all Bugzilla developers
> should read at least that section of the article.

Some of the arguments in that section were the reason I opposed adding a 
user preferences panel to Bugzilla. And now, on b.m.o., we have 11 
preferences, including preferences for several things ("Field separator 
character for .csv files" - guys, CSV stands for "Comma-Separated 
Values"!) which Havoc would raise his eyebrows at.

> 	Lately, we've had a lot of focus on making Bugzilla very
> customizable. That's OK, but we also need to focus on making Bugzilla a
> good product "out of the box". That is, we *can not* just avoid that
> subject by saying, "Well, users can customize their own installation."
> We should be *shipping* the best possible bug tracker that we can.

I see you are more looking at our bloated Parameters section here rather 
than User Preferences. And I agree, it has many of the same problems. E.g.:

docs_urlbase: would it really have hurt us to always make the docs 
available at <url_base>/docs?

sslbase: who puts the HTTP version of their Bugzilla on one domain and 
the SSL version on another?

cookiepath: Could we really have not DTRT and worked this out from 
<urlbase>?

timezone: Is there really no programmatic way of asking a database 
server what timezone it's in?

proxy_url: If the webserver's OS can't access the web, there's probably 
a reason for it.

And that's just the first page, which is "Required Settings" (most of 
which seem that they are nothing of the sort)!

(Note: my point here is not to debate the reasoning for the above, which 
is off the top of my head and may be wrong in the odd case. Look at the 
big picture.)

Gerv