Manage Disagreements

CM vs. SCM, rev 14 showed an example of disagreements over a long period of time, thus not likely to achieve convergence. This effect shows up in the page developing in so-called 'thread mode' (as opposed to 'document mode', in a terminology coined a long time ago, for the purposes of the debate, in the original Wiki)

How should one (re-)act, from the point of view of SCM, or in the context of a (CM) wiki? By feeling empowered (as Brad^? suggested, but didn't do himself, as far as I can tell), and bulling in one's own point? Probably not... as in the case of a disagreement, this would be likely to lead to instability (editing wars), or empoverishment (the defeated or the wiser leaving the ground)...

My own suggestion is to acknowledge the different opinions, and to identify them, e.g. with some kind of label or maybe better yet branch type (one of the uses for branches: long transactions, between consistent states of the overall system, thus encapsulating an inconsistency, in its own protected space). Of course, in this wiki space, there is no direct support for branches, but one can build one at least by means of conventions.

I believe in fact that, in the spirit of si vis pacem para bellum (if you want peace, prepare for war), supporting divergence is the best strategy to (eventually) achieve convergence. Or in other words, the more you control, the less you manage.

I even would offer two labels: the CM view point, that CM and SCM are essentially one and the same thing, SCM been just applied to the Software domain; and the SCM view point, that SCM is an essential breakthrough from CM.

Other related dichotomies in my opinion are prescription vs. description, invasive vs. non-invasive, control vs. manage, modern vs. postmodern, closed vs. open...

I admit my opinion is once again not meant to be consensual.

-- MarcGirod - 14 Oct 2006