HOWEVER, that doesn't mean it can't be done. In fact, if there are ways to visually simplify git and make it more intuitive for non-programmers, those techniques could wind up making git even better for programmers too.
I could also imagine a convergence of the git model and the wiki model someday -- where anyone can edit (like Wiki), but where there are branches, merging, etc. Obviously, a lot of internal wiki's don't need such complicated version control, but for things like Wikipedia, it could be amazing.
I think there are a lot of areas for working on writing collaboration -- group projects in school, business proposals, technical manuals, all sorts of things.
And the main attraction for users over, say, Google Docs, is that your changes don't overwrite others'. The fact that your edits create a "branch", that then others can accept/reject/modify/merge, is a vast improvement in creative collaboration.
If you take that approach and update with precise but plain english vernacular (redundant?) and domain specific examples, then you are halfway there to making it understandable by regular people.
The most important thing to help people really get it is to promote small commits to their work. The real value of git only makes sense when you start making small commits. Having worked as an editor in a past life, having something like cherry-pick and interactive rebase would have been most dope. In a way, maybe editors are the best audience for driving adoptions among writers in general. For professional editors, version control is a painkiller. For writers, it is a painkiller if the writer is an obsessive editor. For those who write and commit once, but don't go back and review commits and refactor, it doesn't provide much value.
Think about how Apple Time Machine made a stab at operating system backups and snapshotting. Was it perfect? No. But it was a step in the right direction.
Loren and others may not solve all the problems right out the gate, but they will lay the groundwork for new approaches to teaching version control to writers and other audiences.
Progress has slowed a bit since work has ramped up, but now that intern season is over I'm expecting to make some progress
That's the goal. I want git to handle everything behind the scenes, and everything that the user touches just 'makes sense' - ie its not all that different from what they're already doing. A 'save' button makes a git commit, editing somebody else's content automatically creates a new branch, 'submitting' that content on the new branch creates a pull request .. etc.
Wikipedia is largely prose, but of a nonfiction variety. This would be a good intersection for git, which was born out of code.
You could call it..."geeky"...too bad it wouldn't be for geeks.
For general writing collaboration I would seriously consider not allowing arbitrary branches. Most people just get confused managing multiple independent outstanding branches that potentially branched from different points in the history.
One restriction could be that each user gets a single branch (their suggested change). As changes get merged into HEAD each user's branch must be rebased (with a click) before they can add more changes to it. From a programming point of view this is restrictive; why can't I suggest two independent features? But keeping track of dependencies is precisely what's hard for people.
Yep, absolutely true.
> One restriction could be that each user gets a single branch (their suggested change). As changes get merged into HEAD each user's branch must be rebased (with a click) before they can add more changes to it.
Heavily considering this approach.
When do writers need to branch their stories/articles into two forks? If they do that, why not just copy the document and work on it there? The large bodies of text don't have the filesystem dependence that programs do; it doesn't matter what the manuscript is called if nothing #include s it or require()s it.
Instead, it can be quite valuable to have a collaborative text editor: your colleagues' changes are shown in real time as they make them. If you go on a plane ride, they're synced when you get more internet access, with conflicts clearly shown and deliminated so you can resolve them simply.
The collaborative editing would be useful in the later phases of a book -- i.e., working with an editor and copyeditor, it's be great to have a really efficient way to review changes made to the actual text (instead of reviewing a hard-copy with hand-written corrections, and then hoping those corrections are accurately hand-merged into the text...).
But for most of the life of a manuscript, it's just the author working completely solo (from what I've seen). In the standard flow, there's no editor until the book (in a fairly complete and polished draft) is sold to a publisher. A literary agent may read drafts along the way, but normally wouldn't touch the text, just write up higher-level feedback.
On the other hand, the task of designing a narrative that flows well at the scope of a novel is really hard, and can take a lot of large-scale trial and error to improve. She usually does have several "branches" of her current project, as well as large chunks that she has cut from the current draft but doesn't discard (and sometimes may be re-added).
Her first published novel shed more than 300 pages that were never re-added on its way to the final version... it's hard to keep track of all that. It wasn't like "drop this chapter", generally, more like "remove this subplot from the hundred or so places it shows up".
I'm not sure how well the git model would address the problems -- the big problem is scale, and visualizing large structures made up of lots and lots of tiny little words. They are plenty of pain points worth attacking, though, except that most writers don't have much cash to spend on tools.
An easy way to trace a plot throughout the novel. Interestingly, a tool, that enables this could even be used by literature students, when analyzing texts for an interpretation (been there, studied that). The only problem with this is copyright and the inability to get your hands on a digital os-/reader-independent format, to work with in the first place.
I worked mostly with texts from medieval times and it was a pain to get hold of (good) digital versions. May be, that this is because language processing approaches are not that widely used in my former field of study.
So to wrap it up - a great tool, enabling authors with this could enable also a better understanding of novels for literature students alike.
Version control is a capital-P Pain In The Ass for group writing projects. Anything that improves the version control problem in collaborative writing solves a very real need. Perhaps not a huge TAM at first glance, but a real need nonetheless.
My final hope is to see a Hollywood movie made out of it one day, because many recent SF movies lack good story.
My other idea is to make the story branch into different directions. I would write the main storyline, but another writer could come and fork it at some point. The reader would be left with a choice at some point: would you like this character to take that decision or the other - and after choosing, the reader could read the forked variant.
This is the first time I'm publicly writing about this idea. I'm still undecided what technology to use to create it.
I've used git with my sci-fi novel, Planet Oz, since I first drafted it back in 2008. Quite glad I did since it makes the editing process much easier to track.
Can't wait to begin the Kickstarter in October.
I've got friends working on projects a bit like this. Markdown served from github pages is nice, as you edit and compare diffs in markdown, but you can get it automatically rendered into a nice readable form too.
My own view though is that the most likely way to fail is to lose motivation, and having interminable discussions over minutia early on while writing is likely to suck away your energy. I'd probably get at least the skeleton of the whole story into your repos before encouraging others to contribute.
Can you give me some URL?
That's if you want someone to PLAY the choice in the story. Which is slightly different from what you're talking about.
I'd love to know when this book gets off the ground - I enjoy both sci-fi and correcting other people's English.
My feeling would be that having one platform with both features would be better than having two very similar things here.
I much prefer a system that's geared to projects and not specific types of document too. For example, if this supported housing a collection of documents and an image or two - with changes able to be made on each file, it would be amazing. Google Docs I edit with others quickly tends to devolve into three different types of sharing/permissions issues, and I'm left frustrated or wondering why some people can access one thing or another.
There's definitely room to innovate here.
Nailed it. That's what I'm building :)
1) It assumes writers write like programmers code. This isn't true. At least with scripts, what typically happens is the writer will write an entire script, send it to their boss for revisions, and then rewrite it. They would consider it a pain in the ass if they had to make "commits" for every page they wanted to add, and especially if their bosses had to review each change (mostly because bosses are executives who just want to leave their mark by making unnecessary changes on things).
2) In either book or script writing (or whatever) small grammatical changes are unimportant, and there will be way more of these than we would care to look at. Who cares about reverting a change of "its" to "it's"?
I see this kind of thing as being useful for writing an informal, informational book in the form of an extended blog post (see http://gettingreal.37signals.com/) but otherwise, I can't really see it being that useful for professional writers.
Also, something that I think would be REALLY useful (that I'm honestly surprised I haven't seen is a Final Draft - meets - Google Docs (screenplays editable by multiple people via online, all stored online). Dunno if anyone's seen anything like this.
Sources: My dad is a TV writer.
MS Word and Libre office aren't powerful enough for scientific writing and aren't universally embraced or consistent across operating systems.
Github for writers is desperately needed. Draft doesn't do nearly enough
Source: physical science graduate student
We have had success with large collaborations working on it, 15 authors should not be a problem.
Check it out and feel free to contact me.
regarding your points, when i set up `meld` to show the text she sent vs what her professor or coleague sent back, she is amazed. So there is usefulness.
Second, have you ever used Kwrite in KDE? you don't have to commit or anything. just type. and it shows the diffs marks on the left. pretty hand. and avoid commits and all.
about point #2, just make branches and tags more practical. Also, try to merge back those 'word fixes' in other branches ' heads. would be awesome even for programmers.
source: optimist :)
* Draft http://draftin.com
* Editorially http://editorially.com
* Quip http://quip.com
* Loren's Penflip http://www.penflip.com
* Google Docs (obviously not new)
Made my day, thank you.
So pandoc could be used for transforming a text into many different formats (even ebook formats).
Might be an interessting thing to look at for the creator of "git for writers" ;-)
* Changes are tracked by line which is equivalent to a paragraph in a book. If I go in and add a comma to a paragraph and my coauthor simultaneously changes a word in that paragraph that can create issues.
* Errors are very difficult to solve for my coauthor. When Github Window's app encounters an error, it basically says "Just open up the command line and you should be able to figure out how to solve this". Of course this isn't feasible for a non-technical audience.
If your product can fix these two issues (which it looks like it is trying to) it could be very valuable.
The diffing problem is solved quite easily with the Google Diff, Match, Patch algorithm and our Smart View technology. When GitSense was created, it was obvious that we all work differently and we all have different needs which was why we made it insanely customizable. If you are not familiar with the Google Diff, Match, Patch algorithm, you can learn more about it here:
I've also put some screen shots of what the diff results for two markdown files would look like at:
The context aware source code that is used in GitSense to display the diff can be found here:
i do all of the git work, and i just have my friend add my edits to his document, then he sends it back and i diff the two for potential errors... he requested it be this way because he is stuck in his ways, but we've agreed to go full git on book two in the series...
that said, when i first started sending him diff files we both saw this as a problem... my solution?
i just wrote a script that i run on the diff to just highlight the changes made, then send him the new edited diff.
When using Markdown, I usually split paragraphs over multiple lines (usually between sentences) which makes diffs much easier to read, while still rendering as a single paragraph.
A compromise might be to break lines on sentence boundaries: edits are often constrained within sentence or paragraph boundaries, and then diff would give more meaningful output for most sentences.
^-- This one sentence is two lines long, though, so perhaps my idea is not that good. Diffs would still be easier to read than if each paragraph were one line.
A diff tool that understands paragraphs is an essential tool for this project.
Single line paragraphs don't put such a difficult choice in front of you. If your diff software is any useful, it'll highlight your change within the line.
I want to leave comments on individual words, sentences, paragraphs, etc., with suggestions for changes. And that's something that git doesn't allow, because the smallest change you can comment on is a file, with no ability to comment on specific parts of it.
I've used Latex+vim+git to write scientific papers recently. It is unfortunately much too complicated for my colleagues to adopt. They're holding onto MS Word which is far inferior in terms of markup, citing, and VCS.
I've been converting my Latex documents to ugly word documents for collaborating and editing. The MS Word editing isn't great either. The strikethrough method breaks up flow. I've also had problems deleting side comments in Libre office. And the MS Word experience isn't always the same on Macs.
I think there is also a "real-time" feature that it provides (not sure about that), so there is usually more than one eye on the doc as the chapter is being typed.
I believe Operational Transforms are the way to go, but I have no basis for that.
Check out this interview where one of the Github trainers, Brent Beer, talks about these ideas. You might want to get in contact with him.
Yep, they're doing it, just not quickly enough :)
Neat, I'll check out the interview. Thanks!
When it comes to diffs for text, just add "--color-words":
git diff HEAD~1 --color-words my_file.md
But I agree with other stuff, that for non-techies Git + GitHub may be to hard to start.
I can't wait to see what he comes up with.
I'm doing 'fragment diffs' (doesn't really have a name) - but basically, all the text is displayed as you would read it (sentences and paragraphs), with diffs displayed inline and colored. Added content in green, removed content in red - doesn't matter if it's characters/words/sentences/paragraphs - it all works.
Screenshot is not the best, but something like this:
Code is easy enough to read in a unified diff because lines are usually short (unless java). Prose flows a lot more fluidly, and there is no formal grammar for human language. I have had the displeasure of having to read "redlines" (prose with inline diffs marked in red strikeout) and I find them completely impenetrable.
If you're using markup then encouraging the period-double-space could be a harmless way of easily breaking the document up by sentences
I like it! There are two things I would still like though. One would be page rendering in the browser. We often have to iterate several times on a paper adjusting figures, text, padding, etc. to get everything to fit within the page limit. I could write the paper in this and then export it to tex, but that defeats the purpose. The second thing is support of popular LaTeX packages. It looks like I can upload arbitrary tex documents, but that's going to get messy if I have to upload the same packages for every paper I'm writing.
We use github for our papers right now. Less than ideal.
Have you tried our pdf exporter to check page length? We are trying to build it out to where you, as a user, don't have to worry about packages. If there is a journal you would like to submit to and we don't currently have the journal setup as an export template, please contact us and we will be happy to add it.
It's funny how authors worry so much about page length and figure placement, and then the first thing a journal does is remove all of the formatting the author has put in place.
http://www.roughdraft.io/ - Also, I like it.
I don't think it's a bad idea to proceed with it, I would just find a way to differentiate it from what's out there.
To my point: to be totally useful along the whole typical writing process with traditional publishers (authors -> technical review -> authors -> editor review -> authors -> punctuation/misc review -> authors -> editor) you'll need at some point to export as Word documents. Ideally, collaborate in Git like environment, export as Word, receive a new Word with all those colored revision and import into Git like stuff.
It is true that writers need editors but editors are certainly not writers. If there was a system where all of the contributors acted more like 'editors' rather than writers than I personally think it would be an awesome version control program.
The down side is, many such organizations (e.g., military) have standardized on Word, which is terrible for collaborative review, editing, and version control of long documents. (Of any documents?) She would have been extremely happy had her employer allowed them to use LaTeX or similar.
I hope you signed up - I want to that editing process easier!
I believe that sentence no verb.
EDIT: Actually posting the link might help. (Although redacting it has a nice sense of irony too).
I like to explain the fiction creation process as "writing code that targets the Human BIOS."
1.Ediff is a nice tool to use for resolving Git conflicts;
2. Org mode works very well with this workflow, provided you use one paragraph per Unix line;
3. Latex generation can be very nice from org-mode sources, and the org-mode -> Latex exporter allows a nicer separation of content from presentation than you get with vanilla Latex.
I'd love to hear of anyone who has success with a similar, but vi-based workflow.
I break sentences by ending with two spaces. (this doesn't matter since Latex is markup) The only issue arises when ideas span across multiple sentences, but I believe there is a flag for controlling the number of lines around a diff. (sorry, I'm new to git) But this sort of proves the point that an easy wrapper for git should be created for scientific writing.
The two main problems I have are:
1. adoption by collaborators (they can't surmount the learning curve)
2. diffing sentences is very different from lines of code
I wonder if some key CS concepts are so fundamentally ingrained, but that writers think about their work flow differently.
But Markdown as UI... is less than ideal. It's great for hackers, but there's already a GitHub for hackers, and it's called GitHub. No matter how much prose.io prettifies it, you still get those damn asterisks all over the place.
Personally, I write in TextEdit, Helvetica 12pt. That's not a universal answer, but it works for me. (Previously I used MacWrite Pro, ClarisWorks and Word 5.1 at different times, but the basic appearance was the same.) Anything that makes a bold word look like "* * this * *" breaks 20 years of habit, and I won't do it.
Markdown as backend storage, fine. But not as the primary editing interface.
I went down this road, and it works surprisingly well.
If you're trialling different solution for writing technical developer documentation, see a more precise description of the workflow that I pushed on my blog yesterday: http://kray.me/pro/doclegit-git-documentation-server/
(sorry for the copy quality, english not my first langage, corrections by mail are welcomed)
While the software developers are comfortable learning and using Markdown or other markup syntaxes, I eventually would like to spread this approach to other technical people in the company. In previous attempts at teaching basic scripting (Awk, Ruby, Python) to engineers who are comfortable writing complex logic operations in Excel and who can dabble in VBA - I found a lot of resistance to the idea of learning a new syntax. So I expect the evangelism required to get these colleagues to write in Markdown will be greater than showing them Lyx, which at least looks like one of the editing modes in Word.
That's interesting - hadn't thought about storing in markdown and just displaying as html. Hmmm.
If the latter, you run into a problem pretty quickly - MS Word. It's still one of the most popular document editing tools out there. More recent versions do store content in zipped XML, but are you willing to put the work into parsing that content at a level sufficient to let it integrate into the kind of flow you discuss?
(EDIT: That said: if your target is those creating text-based documents, then I think this is an excellent idea. )
I'm looking for very specific features on the level of Latex libraries that would never make it into a for profit application.
I've recently switched to papers to help with this. It seems to have a strong community and supports both MS word, libre office, and vim. Jury's still out though.
Also, if there could be some cross-compatibility with MS Word's Track Changes (I know, I can dream...) that would be great.
Not 100% sure on how to solve the "legally binding" part if the other party declines digital signatures, but it'd be a good way to get the contract written and agreed on.
I am also working on something similar called Papyrus. It lets authors create and edit ebooks simultaneously.
(I guess it goes without saying, I do not have any experience or knowledge about the writing process authors follow)
That'd be an awesome tool for witers, bloggers, editors, etc.
Keep up the good work! =)
I'm sure they're familiar with the idea and they seem like the best team to bring it online. They're still a startup looking for growth opportunities: this one seems obvious.
It isn't all reasons mentioned in this article ... the most awesome about github are the developers. This is the biggest reasons why a "github for writers" could fail
Writers work on English text (or other languages) which is text files.
What does this do that Github itself (or equivalent - bitbucket, etc) does not?
Check it out! It's awesome!
I am thinking of accounting systems such as ledger-cli which let you keep your accounts in plain text files.
Am I right?
Long after that, in fact. Forking an open source project was a desperate measure to free it from unresponsive/difficult/differently opinioned maintainers, that could leave a rift in the community for years (see Lucid/XEmacs). GitHub made forking something that was normal, common and expected.
Writers usually write alone, what they need is:
A (desktop) tool with basic WYSIWYG markup (paragraphs, bold/italic, that sort of thing) with version control, visual diffs, export into common formats. Maybe a pull request or two.
master <-> publication
develop <-> draft
feature <-> chapter
release <-> edition
hotfix <-> redact
support <-> copyright