I would anticipate that a github-like approach to editing would get you decent coverage of “local” editing issues (e.g., this hyperlink business) while not obtaining decent coverage of “global” editing issues (e.g., the use of “counter^3-argument”, “counter^4-argument” in some places and “counter-counter-counter-argument” in another).
A lot of this just boils down to having an acceptable style guide that an editor can enforce without worrying too much about taking every issue to the author for approval.
I like the way you’re approaching the problem. However, I think the temptation for a familiar conclusion is too great and that you might be missing some possibilities.
See:
A lot of this just boils down to having an acceptable style guide that an editor can enforce without worrying >too much about taking every issue to the author for approval.
The solution you’re putting forth suggests that there needs to be a single person in charge of coalescing the many suggestions and edits.
But the great thing about version control is the ability to branch and tag. There could be an arbitrary number of editors who each have their own branch and set of improvements that they are working on—where non-editor contributors could switch branches and commit changes specific to that branch’s needs.
In the end, all branches would need to merge into the trunk. This process doesn’t necessarily need a single editor either.
One person’s “familiar conclusion” is another’s “best practices”, I suppose.
The solution you’re putting forth suggests that there needs to be a single person in charge of coalescing the many suggestions and edits.
Not really. Many suggestions and edits put forth by random people, e.g., here, aren’t edits that I think an editor should really make. Nor do I really think a single person is necessary; again, a well-defined style guide would go a long way.
I understand how CVSes work, and I have no problem with collaborative editing. But papers are not coding projects. There are a lot of global things going on that need to happen correctly. Even open source projects tend to have lead developers, no?
I would anticipate that a github-like approach to editing would get you decent coverage of “local” editing issues (e.g., this hyperlink business) while not obtaining decent coverage of “global” editing issues (e.g., the use of “counter^3-argument”, “counter^4-argument” in some places and “counter-counter-counter-argument” in another).
A lot of this just boils down to having an acceptable style guide that an editor can enforce without worrying too much about taking every issue to the author for approval.
I like the way you’re approaching the problem. However, I think the temptation for a familiar conclusion is too great and that you might be missing some possibilities.
See:
The solution you’re putting forth suggests that there needs to be a single person in charge of coalescing the many suggestions and edits.
But the great thing about version control is the ability to branch and tag. There could be an arbitrary number of editors who each have their own branch and set of improvements that they are working on—where non-editor contributors could switch branches and commit changes specific to that branch’s needs.
In the end, all branches would need to merge into the trunk. This process doesn’t necessarily need a single editor either.
Cheers
One person’s “familiar conclusion” is another’s “best practices”, I suppose.
Not really. Many suggestions and edits put forth by random people, e.g., here, aren’t edits that I think an editor should really make. Nor do I really think a single person is necessary; again, a well-defined style guide would go a long way.
I understand how CVSes work, and I have no problem with collaborative editing. But papers are not coding projects. There are a lot of global things going on that need to happen correctly. Even open source projects tend to have lead developers, no?