• Excerpts

GitHub system for writers

People discussing a collaborative, version control system for writing projects and non-programmers. Some fascinating ideas and user experiences exist in these posts. Good ideas. It's an interesting area of software development that includes the Web and native apps for desktop and mobile.

I'm most interested in Web/native apps for writing, collaborating, and managing content. So that would includes software programs such as blogs, message boards, wikis, editors, content management systems, and knowledge management systems.

• Aug 29, 2013 - Github For Writers
• Hacker News discussion - 137 comments

2012 Wordpress activity

• http://ben.balter.com/2012/02/28/github-for-journalism-what-wordpress-post-forking-could-do-to-editorial-workflows/
• http://postforking.wordpress.com/2012/10/01/introducing-post-forking-for-wordpress/

http://www.wired.com/wiredenterprise/2012/02/github/all/1
https://github.com/WiredEnterprise/Lord-of-the-Files
http://www.wired.com/wiredenterprise/2012/02/github-revisited/

Excerpts

From the original blog post by Loren:
http://madebyloren.com/github-for-writers

Some barriers make it intimidating for non-developers to jump in, even if the platform can technically handle it:

• Tech jargon: non-developers don't understand branches, forks, commits, rebasing, cloning, etc.. and they don't care to learn.
• Command-line first: while GitHub is slowly moving Git functionality into the browser, the primary focus is still on the command-line. The in-browser features are meant to supplement the command-line, not replace it altogether.
• Diffs: GitHub diffs (changes in a file) are designed for code: line-by-line diffs instead of words, sentences, and paragraphs.

GitHub is built by developers for developers.

• The Limitations of GitHub for Writers
• GitHub for Teachers
• We Need a Github of Science

So, I've been working on this crazy idea - I'm calling it Penflip.

The goal is to build a platform with the primary features of GitHub (teams, issues, pull requests, discovery, project management, built on Git) but with an interface optimized for writers, along with some other useful features:

• In-browser editor
• Auto-generated project structure
• LaTeX support: math and science need it.
• One-click publishing: one click to convert to PDF/ePub/mobi/etc, complete with layout and styling.
• Mobile-friendly: because writing can happen anywhere.
• Diffs for writers

Oh, and did I mention that all of this happens in the browser, from any computer, anywhere? And because Git is running beneath the surface, the technically inclined can clone projects onto their computers and use desktop editors instead. But it's not required.

blog post comments

You should check https://draftin.com

draft doesn't seem to mention Latex anywhere? It seems to be entirely based on html. I'm not sure that html would be powerful enough for scientific writing

No it doesn't support Latex, it's only about writing and markdown. But it still solves the problem for many people.

You should check out authorea: https://www.authorea.com

Think this has huge potential for Education > see http://openplan.cc for more.

For LaTeX, check out http://www.mathjax,org

nice. probably the closest thing out there is draftin. here's a nice bog post on some of the metaphors between the git tech jargon and the functions of everyday, word users http://kivo.com/blog/git-for-the-masses

I started using Editorially ( http://editorially.com ) which as collaborating option on which you can write in Markdown.

I guess you know about Ben Balters Wordpress Plugin Post Forking? http://ben.balter.com/2012/02/28/github-for-journalism-what-wordpress-post-forking-could-do-to-editorial-workflows

I do believe a great version control should be use on not only code and writing, it should work on a lot of way. Control versions, share with others, work with other talents etc

Hacker News comments

A lot of programmers already find it awfully hard to wrap their heads around how git works. I can only imagine how hard it will be for non-programmers to (it doesn't suprise me that the successful example used is written by mathematicians).

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.

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.

Learn Git Branching did a really good job of making git easier to understand:
http://pcottle.github.io/learnGitBranching/
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.

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.

Learn Git Branching is best learning tool I ever tried! With this tool and a little practice on the side I was able to learn the basics of git within a couple of hours so that I can confidently branch, merge, push, pull and rebase and I know what I'm doing!

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.

I can also imagine writers will get a great deal of use out of git cherry pick.

You could combine the advantages of git versioning with wiki style collaboration and make a git-wiki like the parent said, but for writers.

The intersection of git and wikis is interesting, it's one of those things that sounds compelling but then the details usually end up making it hugely complicated. 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.

Honestly, I think writers could benefit more from the collaborative editing model than the git branching model. When do writers need to branch their stories/articles into two forks? 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.

My wife is a novelist.
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.

#writing - #github - #collaboration - #blog_jr