Do you mean editing done by the publishers? I don’t know anything about that domain.
As far as the writing of academic papers goes, I know a few groups that maintain a CVS, but some portion of mathematicians wouldn’t be technical enough to run one. Of the examples I know, two groups only use a CVS because their PI told them to, over much groaning.
I was just struck how this is a perfect example where the efficient flow would go ‘see problem->fix problem->submit pull request’, rather than having to post here and hoping someone sees it and acts on it.
It occurs to me that the person who makes revision control easy in the same way that social websites made having your own website easy will also make a billion dollars. Dropbox is both a good example of success and a good example of how much more could be done (trying to use dropbox for proper revision control is something I’ve seen attempted and it is not pretty).
It occurs to me that the person who makes revision control easy in the same way that social websites made having your own website easy will also make a billion dollars.
Hell yeah. I have successfully explained to a bunch of not-very-technical managers why they would want version control: “Have you ever spent three days editing the wrong version of a document?” Wide eyes, all slowly nod. Once they understood what it was for, they would have crawled across broken glass for version control. (And since we were using ClearCase, they did pretty much that!)
“Track changes” in Word solves a little of the problem from the other end.
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?
Do you mean editing done by the publishers? I don’t know anything about that domain.
As far as the writing of academic papers goes, I know a few groups that maintain a CVS, but some portion of mathematicians wouldn’t be technical enough to run one. Of the examples I know, two groups only use a CVS because their PI told them to, over much groaning.
I was just struck how this is a perfect example where the efficient flow would go ‘see problem->fix problem->submit pull request’, rather than having to post here and hoping someone sees it and acts on it.
It occurs to me that the person who makes revision control easy in the same way that social websites made having your own website easy will also make a billion dollars. Dropbox is both a good example of success and a good example of how much more could be done (trying to use dropbox for proper revision control is something I’ve seen attempted and it is not pretty).
Hell yeah. I have successfully explained to a bunch of not-very-technical managers why they would want version control: “Have you ever spent three days editing the wrong version of a document?” Wide eyes, all slowly nod. Once they understood what it was for, they would have crawled across broken glass for version control. (And since we were using ClearCase, they did pretty much that!)
“Track changes” in Word solves a little of the problem from the other end.
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?