• 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.

#writing - #github - #collaboration - #blog_jr