My job is to write those specs, so I know what you are talking about. And I think, as much as we want to encourage new, smart programmers to participate, it wouldnt hurt to have more people come up with clever ideas - we dont just need to clone stuff from other environments - the basic framework we already have. But we want to make programs and frameworks that actually make sense, that actually solve real problems and just make life easier instead of just “having a GUI config tool for [foobar]”

Actually, I’ve gotten several paid contracts specifically for writing specs. The customer knew what he wanted so far as the end result, his programmers were only thinking in terms of implementation and not the final goal, and I wrote a spec listing the goal, breaking it down, providing implementation strategies, rationalizations for each, priorities for each, and a number of general remarks and suggestions for some low-level details that I knew a lot of coders tend to botch up (like networking code). Turned out great, given that the applications exist and do what the users wanted. (Although I wish I could have pushed UI design a bit more heavily on the apps…)

Actually generating a list of goals isn’t *too* hard. Users know what they want to do. The problem is when a user knows what they want to do and thinks up a sub-optimal way of doing it, and then starts asking for that specific method instead of explaining their end desire. I think that, in this community, that’s probably more important than technical specs, since we’re programmer oriented. The trick is figuring out what people want to do and the best way to do it, then layout out some general implementation details and strategies and let the coders work out the lower-level details.

Example - user complains that they hate getting offline errors in Evolution and that dialing into the internet with their modem is a pain. Offline errors aren’t the problem, and the manual dialing process is as simple as it can get - a click or two. The problem is that the computer doesn’t automatically recognize that the user’s operations requires ‘net connectivity and doesn’t initiate that connectivity, but instead requires the user to recognize that and do it manually. So, the high level goal here is to get network-requiring apps to initiate an Internet connection automatically.

Some goals then are a) security of the infrastructure, b) ease of use, c) robustness, d) developer friendly. Security means that random apps can’t quietly connect to the ‘net and start doing bad things. Ease of use means that the user shouldn’t have to do a lot of work - the automatic initiation of connection removes some mental overhead, but that doesn’t mean it requires fewer steps. Robustness means that apps can reliably detect when ‘net access is available and that they don’t try to connect to the net if a connection is already available. Developer friendly means that it’s easy for developers to get the functionality working in their apps.

That translation there is often the hard part in projects like GNOME, because it’s the idea of thinking top-down that gets hard. If the developer focuses on the bug report (offline in Evolution is annoying) vs the over-all problem (user has to know when and how to connect to the Internet) then the problem won’t be solved properly.

The people that break down those requests like this could offer implementation suggestions, although it probably isn’t needed. Personally, I’d tie this all into something like NetworkManager, add some client library calls that basically provide two functions - HaveInternetConnection() and ConnectToInternet(). Library uses D-BUS to talk to NetworkManager. ConnectToInternet() would select the network interface best able to connect to the net if one isn’t already active and pop-up a confirmation dialog for the user, specifying the app that requested it using the application user-friendly name and icon. Library should be devoid of any dependency garbage other than D-BUS itself so that it is friendly to KDE, OOo, Mozilla, and so on.