Jargon Is Bad
We use a lot of jargon when discussing, designing and creating our software. When we're working on something that's complex or new, new words and phrases (or new meanings on old ones) will crop up in our language when discussing it with each other. The world outside our creative circles remains innocent to these new bits of language floating about. This is all well and good .. until the jargon starts creeping outwards and meets people using the software.
In Plasma, we try to keep the jargon we've invented to help us work together out of the user interfaces. It's not a cashew, it's a toolbox. It's not a Plasmoid, it's a Plasma Widget. It's not "Plasma" it's "the desktop shell" or "the workspace" (if we're being more inclusive and talking about KWin, etc as well). It's not a Containment, it's an Activity if it's on a main, full-screen layer (e.g. desktop or dashboard) and something descriptive for the context (e.g. Panel) if elsewhere. It's not always easy because to us these words are just second-nature.
There's a lot more jargon in KDE, though: nepomuk (search service!), krandr (screen settings!), kwin compositing (desktop effects!), akonadi ... If we can keep the jargon out of what we see when using the software, it will help people immensely. We should instead be using terms that describe what it does or why I should care about it when I'm using it.
KDE has a great history of configuration options. Sometimes, however, we use that as a cop out and instead of making a good decision or a hard decision we make no decision and instead put an option in there. Besides the cost on the code itself (more code paths, etc, etc) there's a cost to the usage of the software.
Every option shown to the person using the software is something they have to read and understand. Then they have to choose whether to interact with that option or not. Is it what they are looking for? What happens if they toggle it? Where is that thing I'd like to control? At some point, people will give up, get frustrated or both. At best it slows them down, at worst it causes them to stop using the software all together.
So when deciding which options should be there, know the audience and its needs (e.g. technical applications will often have a lot more gadgetry to them) and be ready to make hard decisions. If it turns out that it does indeed need to be made optional, it can be added later. Taking back an option once offered is really hard, though. It makes people sad.
The good news is that if a few hard choices are made, including the occasional "no, I'm not going to make that optional even though you and your friend have asked for it nicely", there will be lots of room for other options that are highly valuable and useful.
So think twice before doing the "just make it configurable" dance. It's one step towards how we can have our cake (great configurability) and eat it too (have good looking and highly usable software).