Galeon, A History

All my essay really argues is that each preference
(or feature in general) should have a careful rationale
and the maintainer needs to understand what it's for.
This is honestly a pretty self-evident point in my view.

Go back and read my initial post in this thread.
Now draw the line between when extra code is worthwhile, and when the cost is too high. Or better, give a process and method for drawing the line. What I propose
here is something like "best maintainer judgment."
In that proposal I freely admit that sometimes people will
screw it up; but that isn't a reason to avoid trying,
unless someone can propose a better process.

There's no tradeoff between [insert your favorite goal here, such as usability] and configurability
in theory, given infinite resources to rewrite, redesign,
bugfix, and test. There is a tradeoff in real life;
if nothing else, every piece of code you add brings up code complexity, and
thus trades off with something else you could have
spent your complexity on. Our current process is that the maintainer is responsible for making this judgment.

Tradeoffs are fundamental. Some people think it's a coincidence that software with a simpler UI (including simpler prefs) empirically tends to have fewer bugs, be developed in less time, have less bloat, and
have nicer defaults; some people realize it isn't.
It's one reason Apple can add tons of features with
pretty small devel teams, and GNOME 2.x is enjoying
some of the same benefits. Many of the
people who were developing in the 1.x days buy
my argument, because they experienced this contrast firsthand, having tried both approaches.

Alan Cooper's book argues for doing fewer features
and doing each one better. It's just a basic time tradeoff;
if I'm busy implementing (or maintaining) feature Foo I can't improve feature Bar instead. And if you add a
thousand pointless features it creates a kind of unmanageable codebase that you can't make large-scale
changes to or understand as a whole from either a
code or UI standpoint.

Often someone whines about metacity missing some
feature and I say
"well if you like [insert more configurable WM here]
better, you should use that" - and often they
say "but metacity is nicer and more stable."
The thing is, there's a relationship between
the feature being missing and the niceness.
It's not a coincidence.

If you read the list of "costs of a preference" in my
essay, I think it's fair to say that documentation
doesn't eliminate them. Especially since users don't read anything.
But of course I'm personally responsible for the gconf
feature that lets people document every last setting, so
sure, I'm all for docs.