In the end, this is one of the dynamic tensions that we're never going to resolve once and for all. Between power and simplicity of the interface, there are some win/win choices, but there are also tradeoffs. This also relates to the tradeoff between speed and quality of development, because the faster you develop, the less time you spend mapping out the possible tradeoffs and finding the best option. I'm going to respond by first playing devil's advocate against Tomeu's position, then suggesting some compromises. Tomeu says that it would be disasterous if engineers start designing the user experience. Scott responds that "developers need not be disqualified from design work, so long as they make an effort to turn off their implementation brains and/or get their work polished/reviewed by someone who knows nothing of the implementation." Let me (for a minute) go further than Scott: developer experimentation may not just be acceptable, it may be the best solution in some cases. On I think every pressing design issue on Tomeu's list (and others that I'd add), there is nobody who isn't at least trying to give some consideration to design issues. In fact, in at least the case of keyboard shortcut work, the entire focus is on a cleaner user experience, and very little in the way of new functionality is proposed. Moreover, as Sugar moves from its heierarchical roots under OLPC to a more open model, the critical resource is not developer time, but contributor enthusiasm. In that context it may make sense to have people implement their crazy ideas, and then figure out if that's what the community wants, rather than trace out an elaborate consensus roadmap beforehand. Of course, at either extreme lies madness. Sugar needs coherent versions, not a pile of poorly-integrated "add feature X" patches (we already have enough of those, most crucially Rainbow). And yet locking down all new development until it has a chance to get a Perfect Consensus (or Dictator Approves) stamp at the next Design Team meeting three months from now is just as much of a death spiral. So we're left in the land of compromises. Tomeu is probably right that just skating along and letting engineers decide will lead to a consistent bias - say, for featuritis over simplicity. The solution is absolutely not to take the power from the engineers and give it to someone else; in open source, power to help decide the project direction is the main wind in our sails. Yet if you try to share that power, in practice you often get such a rainbow of bikeshed-color suggestions that the engineer feels that there's no practical way to take the feedback into account, and so goes back to just doing it their way. Here's my proposal. Insofar as we've substituted for Marco's full-time developer work, we've done it piecemeal. There's not a committee poring over each line of code; different developers do different parts, with community quality control mechanisms. I'd say we have to do the same for Eben's full-time design work. Every developer should be paired up with somebody wearing their design hat, whose job is explicitly not to worry about implementation but about design coherence. This person would help facilitate community discussion, but in the end they'd make a decision if discussion got stuck for whatever reason. They'd try to formulate a long-term goal. The developer would have both significant voice in the community debate, and (more importantly for their motivation) significant autonomy deciding on their own step-by-step approach to the long-term goal. Basically, the first person to volunteer on any given issue would be the design partner for that issue. They I'm absolutely not trying to find a way to eliminate Eben and the other respected design voices from the process. Their voices would still carry serious weight. I'm just trying to find a way to get design input and attention to the issues that need it, but avoid deadlock and keep some autonomy. Jameson