On 1/30/2012 3:23 PM, don kretz wrote: [snip]
And "checking out" something might be a little imprecise for some - to me it suggests sole ownership for some period of time. What is your intended use of the word in this context?
"Checking out" is one of those phrases which unfortunately has been used inconsistently in this context. For RCS/SCC systems one "gets" a set of files from the repository in a read-only state, one "checks out" a file setting a lock on the file and making it read/write, and one "checks in" a file which replaces the old version with the new version and releases the lock. In concurrent versioning systems one "checks out" a file or set of files as a working copy; the files are read/write, but there is no lock on them. when you want to refresh your local working copy with the most current version you "update" your files, and when you want to store your changes in the repository you "commit" your changes, which merges them back into file in the repository. I cut my teeth on RCS, so my inclination is to understand "check out" in the RCS sense which means, as you suggest, obtaining an exclusive lock for a limited period of time. (Kind of like copyright grants a monopoly for a "limited time.") Because I don't think RCS is a good model for this project, I think we should all use "check out" in the CVS sense, which means "getting a non-exclusive working copy." When comparing the two systems, however, it's hard to find a consistent use.
In order to track the status of a project over time, one needs to determine cumulatively who has done what to which pieces.
Agreed. This is what a version control system gives us.
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.
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.
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 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.
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 think I'm as strong an advocate of Agile Development as anyone, but at least the strains of it that I'm familiar with still advocate working from user requirements back into software requirements that determine technology choices. Itchy fingers want to make code, but I'd like to try to keep the focus on the user end so we don't end up letting the system determine what users are required to do, rather than vice versa.
I can agree with this, although I think there are devils in the details. I'm just hoping to get a bit of a playground so I can start shaking those little devils out of the dirt.
OTOH, if we can feed Lee the requirements for a user-side-based API for issuing text-with-images based on a realistic variety of tasks, and accept back the results and incorporate them into a flexible workflow process.using Hg or git or whatever, I'd love to be second in line behind him
Hang on, because it's going to be a bumpy ride :-).