Citizendium Forums
October 22, 2014, 09:30:55 UTC *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: This forums is now a read-only archive. Project members may post on the new forum. Non-members may use only the "Open Forum" group, but still must register before posting (it's easy!). Posts will otherwise be deleted.
To edit your displayed name, click on Profile > Account Related Settings. To edit your signature, click on Profile > Forum Profile Information.
Click here to return to the wiki
 
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: Approval process: on centralised version control and doing the impossible  (Read 1210 times)
Tom Morris
Forum Participant
***
Posts: 354



WWW
« on: May 30, 2010, 18:15:00 UTC »

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.doc
  • Thesis2.doc
  • Thesis3.doc
  • 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.
Logged

Jess Key
Forum Regular
*****
Posts: 1176


« Reply #1 on: May 30, 2010, 21:13:22 UTC »

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.

I don't think there is anything wrong with the approval policy. The only problem was that the instructions were written with certain incorrect assumptions. These instructions have now been clarified, and the process should go a lot more smoothly.

The current process is simple. Once an article is nominated for approval, the version of the article is marked down in the metadata. Lets call that version A. The community then has a chance to look over it, spot any mistakes, perform copyedits, etc. During this time versions B, C and D are created. If the Editor chooses, they can change their nomination so that a more recent version than version A is to be approced, lets say they choose version B. When the time comes to carry out the approval, the Constable moves version D to the draft page so it can be developed further for the next approval, and copies version B to the main page as the approved version.

I honestly think that if anything, your Gitizendium project would just complicate everything. Feel free to prove me wrong.
Logged

Matt Innis
Chief
Constable
*****
Posts: 2131


« Reply #2 on: May 30, 2010, 21:33:30 UTC »

Tom, I am not a computer or software manager of any sort, but I can see that your idea certainly has potential.  Because, most of us get lost about half way through the description, we cannot consider pros and cons of your suggestion, so this is something that is going to have to go through the people that make the software decisions and the rest of us will have to trust that you've considered the pros and cons.

I'm also thinking that you are decribing the process of developing articles rather than anything that has to do with the approval of articles or the mechanics of locking the article.  I am completely comfortable with all three processess.  Hayford complains a lot, but he gets it done. 

Our only problem is that authors and editors don't familiarize themselves with the process.  If they really look at the CZ:Approval Process, constables have nothing to do with deciding what gets in and what doesn't - or what day it gets approved.  Constables just lock the version that the editor 'properly' nominated.  If it wasn't 'properly' nominated, then a constable can clarify the rules for the editor/editors/authors.

Basically, though, it's all written in about three paragraphs on the CZ:Approval Process page.  Everyone should make themselves familiar with them... maybe as a prerequisite to working here Smiley  But, we all know that practice makes perfect and none of it really makes a lot of sense until we actually experience an approval.  So I'd suggest everyone participate in as many as they can, whether as authors or editors.
Logged

Hayford Peirce
Forum Regular
*****
Posts: 3117



« Reply #3 on: May 30, 2010, 22:38:47 UTC »

I don't think there is anything wrong with the approval policy. The only problem was that the instructions were written with certain incorrect assumptions. These instructions have now been clarified, and the process should go a lot more smoothly.

If one does one Approval every six months, then it's a strangle, kluge-like, imbecilic, incomprehensible puzzle that can only be solved by following explicit and perfectly explained directions.

If one does two Approvals a day for three weeks in a row, say, then after a while all of these strange individual actions begin to make sense and one can begin to see *why* certain actions are being done and *what* they will accomplish.  So in that sense, Chris is absolutely right: the process will go much more smoothly now.

In the meantime, I have rewritten the Instructions, mostly by copying in the new material from Chris, but also adding a little stuff of my own.

Could you, Chris, Matt, and everyone else, please take a look at these instructions and see if there is *anything* at all, no matter *how* tiny, that should be fixed, repaired, added, subtracted, or otherwise edited.

Thanks!
Logged

Daniel Mietchen
Forum Member
**
Posts: 25


« Reply #4 on: June 01, 2010, 23:28:05 UTC »

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:
Current example.
Logged

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.15 | SMF © 2011, Simple Machines Valid XHTML 1.0! Valid CSS!