"Habitual Capitulation:" We should ritually, systematically, near automatically capitulate,… …to just about any basically sensible specification effort from trustworthy sources (not trying to trick us, damage us, etc). Software developers should adopt standards for their functionality, not their substrate, if it is reasonably within their capability.

The reasoning goes like so:

The technique is this:

Basis principles of "Habitual Capitulation:"

In fact, groups may even want to intentionally sabatoge their own specifications with nonsense, in order to demonstrate to themselves that imperfection will be embraced, as long as they get to implementation.


I write this on the heels of two blog posts:

…but the "habitual capitulation" phrase came to me a few weeks ago.

I like it. But is there no place for constructive criticism at all? How about if get to we complain and critcize a new proposal anyway, but just have an understanding that criticism is not a veto and that people should go ahead and get coding even if the issues haven't been addressed? I like to complain about a new proposal even when I like 95% of it (like i'm doing now, for example). CrotchetyCapitulation??

I think timing is important. Give an idea time to grow and accumulate enough positive energy before criticising it. There's always a balance: We want progress, and progress requires change. At the same time we don't like to waste time on dead ends. Enthusiasm facilitates change, and criticism prevents us from going into dead ends. If we feel that we don't have enough progress, then we need to ask: Is there not enough change, or are we ending in too many dead ends? If there's not enough change, we need to cut back that criticism somewhat.

There are enough ColdBlankets out there. MutualInspiration is the key. PeerReview comes later.

In answer to Bayle, I'd say no. If Lion had gotten 3 "Yes, let's use this" answers right away, energy isn't wasted answering questions. He put forth the energy to get this far, and it seems to be complete, not in brainstorming mode, so embrace it!

To address BayleShanks:

ConstructiveCriticism? is fine.

If you say something like, "Well, we need something to account for X– how about these tokens to account for it?" …that's a constructive criticism.

If it becomes: "Well, you didn't incorporate my idea, so I'm going to recommend to people not to use your spec," that's not in line with HabitualCapitulation.

If you say something like: "I reject this on the grounds by which I reject everything that is XML-RPC; Here's how you could do it in REST" – that's probably not constructive, and it's probably going to introduce an XmlRpcVsRest? debate. So, I would think it probably shouldn't be said.

If you wanted to, instead, make a REST specification, and champion it yourself, though, (which is a lot of effort,) that should be capitulated to, as well. There's no reason we need to have only one spec. "Specifications can be multiple, and still work. (RSS proves it, though we groan.)"

Alex, will respond in turn in another spare moment.

Define external redirect: XmlRpcVsRest CrotchetyCapitulation RestVsXmlRpc ConstructiveCriticism

EditNearLinks: PeerReview ColdBlanket