Here's a thesis:

The problem I see with making ticketing systems accessible to users isthat you periodically need to have a genuinely private conversationamong the sysadmins in response to user requests. I'm not sure how oftenthis happens in typical organizations; ours is somewhat atypical in howwe structure support, and possibly as a result it seems to happen fairlyoften here.

If your ticketing system is (internally) public, then you can't havethese conversations in the ticket; you have to find some

On the surface, the (c)Pickle module looks like a good, simple wayfor your Python program to save and load its data; much like XML , it means you don't have to write a parseror even save and load routines as such, just some file and objectmanipulation code. However, through my experience in writing DWiki I'vecome to understand that this temptation would be a mistake (one thatI've actually half-made; DWiki 's caching layer uses pickling)

To follow on from yesterday's entry , suppose thatone is using (c)Pickle to save data in your Python program, and you wantto version your data somehow. I can think of a number of approaches:

• take the 'pickle as stored JSON' approach; serialize your complexobjects to simple objects (dictionaries, lists, etc), add versionnumbers, and only pickle the simple objects. Then you can do all ofthe usual version mismatch fixups when you de-serialize the reloadedsimple objects