[ProgSoc] TFM: Time For Modification Redux

Nathan de Vries nathan at atnan.com
Tue Nov 10 17:39:10 EST 2009


On 10/11/2009, at 1:10 PM, Roland Turner wrote:
> Harsh. Self-defeating for chapters that aren't about LaTeX or SVN  
> and it
> eliminates the immense benefits that turn out to exist in allowing
> reviewers/readers to make small corrections fast.

I agree with this. We've discussed rewriting the TFM before and it  
always becomes a nerd-fest of questions about what SCM & markup  
language to use, but this ignores the fundamental issues that have  
held back a rewrite. Namely:

1. It's hard to get people to sit down and churn out content
2. It's hard to know what content to throw out and what to keep
3. It's hard to get people collaborating

Notice that none of these things have anything to do with technology?  
Not only that, but SVN & LaTeX make all 3 problems even harder to solve.

Nicholas' suggestion of using Markdown (or a Markdown derivative) is  
more realistic, because people are used to writing emails and Gruber  
designed Markdown with that in mind. It becomes less about the markup  
and more about what you're writing.

If you're thinking "but you can't write a book in Markdown", the Git  
Community Book is a great example of one.

This is what a raw chapter looks like:

http://github.com/schacon/gitbook/raw/master/text/08_Basic_Branching_and_Merging/0_%20Basic_Branching_and_Merging.markdown

This is what it looks like using the simplistic Markdown formatter of  
Github:

http://github.com/schacon/gitbook/blob/master/text/08_Basic_Branching_and_Merging/0_%20Basic_Branching_and_Merging.markdown

This is the final HTML exported result:

http://book.git-scm.com/3_basic_branching_and_merging.html

And the final PDF / print result:

http://book.git-scm.com/book.pdf

The hidden advantage of using Github is that anyone set as a  
collaborator on the project can inline-edit the chapters and hit save,  
and it's all version controlled. Others who want to work locally can  
check out the project and work in their editor of choice, pushing and  
pulling changes as they see fit.

Seems like a much more sane option to me.


Cheers,

Nathan de Vries



More information about the Progsoc mailing list