It needs to
know who performed which tasks on which pieces of a project - whether they change anything or not.
I don't agree; I see no need for any statements to the effect of "looks good to me." They're harmless, but they serve no real purpose.
Even in this first exercise it might be useful to anticipate people sharing work on a project; both horizontally (one task for all pages) and vertically (all tasks for some pages.) I think it would be essential to plan for it in the future unless you believe in total anarchy oiverwhelmed by massive redundancy. One person checking out some page or pages for some unknown reason doesn't help that much. Especially when many tasks produce no diffs.
It needs to be able to distribute
uncompleted units of work that vary based on what the task is from a table to a set of illustrations to a paragraph.
I don't think there is any such thing as an uncompleted unit of work -- or perhaps more accurately I don't think there is any such thing as a /completed/ unit of work. A work should always be in a state of continuous improvement, and that which is served to the public will always be just the state of the work at the time it was served.
If I say I'll check the chapter headings, or the illustrations through chapter 5, then that's a unit of work. It comprises a specific scope and probably has a beginning and an end. But you're right, if someone says "we need to update projects 400 to 600", (or even one project),l that's not a unit of work.
And synchronize the text
assigned with the images associated with it.
This is the job of the project files, not the version control system. As an example, in ePub the .opf file brings all the files together, and defines their relationship to each other; in our case it will probably be the structure of the files in the repository, but it is /never/ the job of the version control system.
It will be interesting to see how you orchestrate a project-oriented structured filesysytem simultaneously with a repository on the same projects.
It needs to be able to know about users who try to perform the same task
on the same text repeatedly - which may or may not be appropriate depending on the task.
Perhaps metrics can be gathered -- I'm just not sure what they would be good for, or how we would use them.
At a minimum, what tasks have been accomplished for what pieces of which projects, by whom, when. More importantly, what hasn't been done so people can choose non-redundant work (which I think will be preferred by many.) Assuming again non-anarchy...d .
I'm not sure that I'm ready to agree that it's appropriate to make
technology decisions based on an assumption that crowd-sourcing in any form is unworkable and won't be considered.
I'm convinced that crowd-sourcing /is/ workable given leadership. I'm just hoping someone out there is prepared to give me enough rope to hang myself. ;-)
I see, for instance, someone working on a table from a textbook during the ride to work on the train on their ipad. (which by the way is a unit of work you need to be able to identify, issue, and merge on a non-random sufficiently-repeating basis.) Or checking all the Greek phrases in a Bible commentary (of which we have a few, sometimes done at a substandard level.)