Okay, I should try and explain my thoughts about version control and the wiki.
I think that what Citizendium is trying to do with Approval and stable versions is not working. As a mere author, I haven't been involved in approval directly, but observing what is going on with the article on Set theory shows the whole process to be totally absurd.
What Citizendium is trying to do goes against the fundamental nature of what a wiki is all about. This is not a criticism of Citizendium, this is a criticism of wiki software. What the approval-and-draft model seems to be is a very primitive branch and merge system that users of version control systems will be familiar with. Once you've used a good version control system, you wonder how anyone gets any work done without them? This is a trait of many software developers: I can't understand how normal people get any work done with the awful tools they have to process information. The answer is that they think laziness is a virtue, whereas if I'm feeling "lazy" it is because the process I'm involved in is broken.
You must have experienced this occasionally: you know someone who has a totally byzantine system of working and you wonder how they get any work done. I have had just that experience. I know of a company that has something like a thirty-step process that they need to do in order to actually do work for their customers: they have to send something like four e-mails, print something out, enter it into a database, deliver it in triplicate, confirm some things with sales, other stuff with clients, send this, enter it into another management system. Next thing I hear they aren't doing very well and are losing money and having to sack people. No wonder. If you have to do all this - let's define a technical term for it - crap every time you want to actually do some work for a client, you've built in a solid motivation not to actually do work for clients, and thus not make money. Byzantine processes don't work. When sane people come up against byzantine bureaucracy, they either automate it or quit.
One way some people try and fix byzantine processes is by adding social rules to the process. This is a bad solution, because now you have two problems: a byzantine process and a set of complex rules that everyone has to follow in case the process doesn't work. Then when the process doesn't work, everyone runs around blaming one another for not adhering to the stupid rules that have been dreamed up to make sure the process works.
Boil the approval process down, and here is what you actually have:At some point, one or more people decide that a particular revision is ready to go and ought to be marked as stable.
That is all it is.
Now, to do that, one needs to do an elaborate dance of proposing approval, marking it as awaiting approval, then when the final version gets blessed, that needs to be implemented. And this needs to not interfere with ordinary people changing things.
There's already a technical solution to that. It's called a distributed version control system. I use one every day. It works great. The reason programmers use version control systems is to keep our history
(because if everyone does something stupid you can just say "last Friday's version, please"). We also use distributed version control systems to keep track of different versions
of code. If I'm twiddling about with something new and experimental, I don't necessarily want to roll it out to clients along with the stable releases until it is good and ready.
Non-programmers do both of these things. They just do them badly. If you open up someone's My Documents folder and they've worked on an academic thesis, you'll find a bunch of files like this:
- Thesis chapter 4.doc
- Thesis conclusion notes.doc
- Thesis FINAL.doc
- Thesis NO REALLY FINAL.doc
- Thesis Corrected.doc
- Thesis submitted version.doc
Which one is the one they are actually going to hand in? God knows. Which version is the conservatively written one they send to their tutor and which is the one with all the saucy bits and swear words in? Again, god knows.
In a version control system, you know what the latest one is because it is the one there. And as for all those wacky alternative versions? Those go on branches
The great thing about a branch is that you can go off into a branch, make as many changes as you like, and then when you are done, pull your changes on the branch back into the trunk it branched off. But let's say you've got your experimental branch. What about the stuff you put on the main branch? How does that get to your experimental branch? You are there, writing your thesis and working on the experimental branch too. But then you spot a spelling mistake that's peppered through both versions? That's tiresome, right?
Not if you've got a good version control system. You switch back to your main branch, fix the mistake and check it in. Then you can also pick that revision off the main branch and copy it into the experimental branch. It's like you are working on two versions, but the versions are the same in some ways
but different in others. You can do this, but so can others.graphics stable
How does this work on the big scale? Simple. Look at the Linux kernel. This is a big project - as big as a big encyclopedia, and probably as important. There is one guy in charge - Linus Torvalds. Imagine he is a giant dam at the mouth of a river. He's the Hoover Dam or the Thames Barrier or something. He decides what goes into the releases. Or maybe he and a few others do. Doesn't really matter. Now, like any good manager, Linus delegates. In the Linux kernel, people work on all sorts of different things that make a computer work. Some people might work on code for graphics - to make graphics cards and displays work - and others work on, say, scanners. At the end of each release cycle, though, Linus wants to have good quality code from all these contributors. The distributed version control system they use - git - lets that happen. He chooses someone he trusts for each different area of responsibility, and pulls changes from those people
. They, in turn, choose who they want to pull from. Newbies can still participate, but they have their code raked over the coals properly - old and trusted hands can commit without so much oversight.
Linus doesn't have anything special. He isn't in charge of a special server. He just chooses who to pull from. There are no technical controls at all. If Linus gets hit by a bus tomorrow or decides that maintaining the kernel isn't very interesting, he can do something else, and someone else can emerge.
I think we should move wikis over to distributed version control. I've been thinking it for a while. Seeing the goofy approval policy inaction - sorry, in action - was the last straw. I'm not blaming anyone. We're trying to use a wiki for something rather too complicated. If Hayford and Matt struggle with the approval system, should that not give us pause for thought? It might be too complicated. Over-complex. Bureaucratic. There has got to be a better way.
The reason I put up Gitizendium
is to try this out.
People are already using Git and DVCS to run websites, albeit a bit smaller than encyclopedias. The website for git - git-scm.com
is itself stored in git. You can download the source code, faff around with it as much as you like, and when you are done, you point the person who owns the site to your revisions and he can cherry-pick the changes he likes.
For more reading, have a look at HgInit
. It is a tutorial rich in explanations for Mercurial, another distributed version control system very much like git. And read this thread on the possibility of a distributed Wikipedia
There's a lot more to be said about this, but I'm not sure what people think. Happy to answer any questions.