Extension:LiquidThreads/Milestones

This is essentially a "task list" of all of the things that need to get done before the LiquidThreads updates can be considered "mostly complete".

Schedule
At the moment, I'm not in a position to guess when most of these steps will be done.

However, I'm setting myself the goal of having the first task in "Backend updates" ("Write new storage layer") finished by the end of next week (That is, by April 2). To do this, I want to have a first pass finished by Monday (March 28), which will then be fully tested, working and documented by Friday. If that works out, I would like to aim to have it fully integrated into the new object model in the two weeks following — and have that all done, including a migration path, by Easter (April 21).

Step 0: Planning
This phase is complete. This included:
 * interaction and feature design for the new interface,
 * identifying issues with the present backend,
 * planning a new data model for the back-end,
 * planning code refactoring, including breaking a number of classes up,
 * determining priorities and scheduling, and
 * object model planning and development.

It was done by Brandon and Andrew, in consultation with much of the Wikimedia tech team.

Step 1: Backend updates

 * Write new storage layer
 * LiquidThreadsPost, LiquidThreadsPostVersion, LiquidThreadsTopic, LiquidThreadsTopicVersion, LiquidThreadsChannel objects need to be written to spec. This involves small amounts of code, but large amounts of thinking. I've got the basic model sorted out for the Post/PostVersion objects, but it required a lot of fiddling and trial and error. Topic/TopicVersion objects will be simpler to write, because these problems are now solved.
 * Establish strong, code-level documentation on the new storage layer interface.
 * Write, document and finalize new database schema.
 * Integrate new storage layer into the codebase. This will be a reasonably major, but boring and uncomplicated venture. This is a candidate for bringing in contract help, depending on how big the job turns out to be.
 * Plan, implement and maintain a migration path from old LiquidThreads installations to the new storage back-end.
 * Test thoroughly, including developing and maintaining unit tests for the storage backend.

Step 2: Documentation insanity

 * Add code-level documentation, including usage notes and examples, to all methods, particularly those in the LqtView class. This will involve cleaning up (in particular) the deep-link functions.

Step 3: Front-end work
(Needs more detail) This work is a candidate for bringing in external contractors, at least to help on the front-end code.
 * (Possibly) Refactor some of the code in LqtView to suit the new display paradigms.
 * Implement the interface changes suggested by Brandon. In some cases, this will essentially involve rewriting entire functions.