写作方法2013madebyloren.com
我正在为写作者打造一个 GitHub
I'm Building a GitHub for Writers
导读
作者想为写作者做一个「GitHub」：用分支、合并、接受/拒绝修改的方式做协作写作，让每个人的改动不再覆盖别人。对写作者来说，这篇讨论值得一读，因为它逼着我们想清楚：写作协作真正需要的是什么样的版本控制，以及哪些「程序员式」的操作其实并不适合写作现场。
可以直接用的写作要点
- 01
协作写作时，先让每个人的改动成为独立「分支」，再由作者决定接受、拒绝或改写，能避免互相覆盖和被迫返工。
- 02
别把「每次改动都提交、每页都要审」当成规范；对写作者而言，频繁的提交和逐条审阅是负担，颗粒度要按段落或章节来定。
- 03
小的语法修订（如 its/it's）不值得逐条回看，版本记录应聚焦于结构、情节、论点这类有意义的改动。
- 04
按读者和协作者的实际习惯设计写作流程：编剧是整稿写完再交人修改，而不是边写边提交。
HN 评论精选
git 对非程序员门槛高，但可视化简化后可能双赢；分支式协作的核心价值是改动不覆盖他人。
很多程序员都觉得 git 很难理解，非程序员可想而知（那个成功案例的作者是数学家，我一点也不意外）。但这不代表做不到：如果把 git 可视化、做得更直观，这些技巧反而可能让 git 对程序员也更好用。我还设想 git 模型和 wiki 模型某天会融合——像 wiki 一样人人可编辑，同时又有分支、合并。很多内部 wiki 不需要这么复杂的版本控制，但对维基百科这类东西会非常棒。写作协作还有很多可做的方向：学校小组作业、商业提案、技术手册等等。而它相对 Google Docs 的主要吸引力在于：你的改动不会覆盖别人的，你的编辑形成一个「分支」，别人可以接受、拒绝、修改或合并——这是创造性协作的巨大进步。
crazygringo查看英文原文
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. 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.
开源协作+分支叙事：读者可以在关键节点选择走向，读不同的故事分支。
我一直在找这样的东西。我打算写一部科幻史诗小说，用开放许可（大概是 CC BY-SA）发布。我不是英语母语者，希望母语者能来帮忙把文字打磨好。我最终的愿望是有一天能看到它被拍成好莱坞电影，因为最近很多科幻电影缺好故事。我另一个想法是让故事分叉：我写主线，其他作者可以在某个点 fork 出去，读者到某个节点可以选「你希望这个角色做这个决定还是那个决定」，选完就去读对应的分支版本。这是我第一次公开写这个想法，还没决定用什么技术实现。
babuskov查看英文原文
I was looking for something like this. I'm planning to write an epic sci-fi novel and make it available under some open license (Creative Commons BY-SA probably). Since I'm not a native English speaker, I'm hoping those who are would jump in and help me perfect the text. 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.
写作流程不同于写代码，逐条提交与审阅是负担；版本控制应忽略琐碎语法改动。
有意思，但它没有考虑受众。1）它假设作家像程序员写代码那样写作，事实并非如此。以剧本为例，通常的流程是作家写完整稿、发给老板修改、然后重写。如果每加一页都要「提交」，尤其还要老板逐条审阅每个改动，他们会觉得很烦（老板多是高管，只想留下自己的印记，做些没必要的改动）。2）无论写书还是写剧本，小的语法改动都不重要，而且这类改动会多到根本不想看——谁在乎把 its 改回 it's？我认为这种东西适合写非正式的知识型书籍（比如以超长博客文章的形式），但对职业作家我看不出有多大用处。另外我觉得真正有用的是「Final Draft 版 Google Docs」——剧本可以在线多人编辑、全部存在线上。不知道有没有人见过类似的东西。来源：我爸是电视编剧。
dylandrop查看英文原文
This is interesting, but I think it kind of fails to take its audience into consideration. 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.
同类还值得读
被低估的工程技能：把文章写好
Undervalued Engineering Skills: Writing Well
这篇文章讨论为什么“写得好”是被低估的工程能力，以及它如何在团队协作、系统设计和职业发展中持续带来回报。
写作方法2019 · 1,109 分 · 371 评4 条写作要点编辑精选每行只写一句话：让写作和修改都更轻松的排版法
Writing one sentence per line
这是 Derek Sivers 的一篇短文，主张写作时每行只放一个句子，而不是按段落排版。
写作方法2022 · 849 分 · 297 评4 条写作要点编辑精选书面沟通是远程工作的超级能力
Written communication is remote work super power
这篇文章讨论远程工作中书面沟通的价值，评论区则补充了异步与同步沟通的适用场景，并提醒读者：备忘录、结论先行、结构化命令格式等书面沟通传统早已有之。
写作方法2020 · 831 分 · 190 评4 条写作要点编辑精选如何写出有用的文字
How to Write Usefully
保罗·格雷厄姆在这篇文章里给"有用的写作"下了一个可操作的公式：有用≈重要×新颖×正确×清楚，任一项为零，整篇文章就等于零；他还主张敢下确定判断、删掉让自己心虚的句子。
写作方法2020 · 821 分 · 285 评4 条写作要点编辑精选如何写得更清楚、想得更清楚，并学会复杂材料（PDF）
How to write more clearly, think more clearly, and learn complex material [pdf]
这份 PDF 讨论如何把文章写清楚、把思路理清楚，并用写作来学习复杂材料。
写作方法2022 · 779 分 · 153 评4 条写作要点编辑精选