米 Wired、GitHub を使って記事を制作 27
ストーリー by reo
論文もGitHubで管理するかな 部門より
論文もGitHubで管理するかな 部門より
hylom 曰く、
米 Wired 誌が、GitHub を使って記事を制作する実験を行った (eBook USER の記事より) 。
制作されたのは「Lord of the Files」(ファイルの王) という記事 (その Git リポジトリ) 。この記事のライセンスは Creative Commons の by-nc-sa 3.0 で公開されており、日本語訳もすでに作られている。
記事の内容は、GitHub の歴史や創業者インタビューなどを含む物だ。3:30 に記事を公開したところ、9:00 にはすでに 12 回もの変更が行われるなど活発な編集が行われたという。いわゆる「編集合戦」が発生した (しかも誰もがコミットコメントに明解な詳細を書かない) ほか、フォークした人たちによってアポストロフィやクォートなどが別の文字に変換されてしまったりといったトラブルも起きたほか、いわゆる「荒らし」も登場したそうだ。しかし、多くの人が原稿をチェックしたことでスペルミスから不正確な内容の指摘など、有用な結果も得られたという。
GitHub の創業者であり CTO の Tom Preston-Werner 氏は「GitHub は記事の編集には最適化されていない」と述べているものの、そのような目的に向けた機能強化についても検討をしている模様。
漫画とか映画とか (スコア:2)
テキストベースのバージョン管理システムだと難しいかもしれませんが
ネームを切っておいといたらみんなでペン入れとか、そういう作り方も楽しそうですね。
映画も絵コンテを撮影したものを皆で完成させていくとか
政党のマニフェストを (スコア:2, すばらしい洞察)
Re:政党のマニフェストを (スコア:3)
頻繁に改正される法律の条文も差分を比較表示できるようにバージョン管理して欲しいですね。
ついでに、国会で議題に上がるような政治案件もバグトラッキングシステムで管理して欲しいです。
案件ごとにプライオリティーをつけて優先度の低いツマラナイ議論に時間をかけるのは避けて欲しいですね。
Re:政党のマニフェストを (スコア:1)
Git管理してほしい
もちろんちゃんと個人名でコミットしてもらって
予想される未来
１．誰もコミットしない未管理ファイルだらけになる。
２．過去履歴ごと差し替えられる。
３．コンフリクトの解決が誰にもできなくなる。
# 実行フラグ属性は管理するのでしょうか
Re: (スコア:0)
改変自由なマニフェストか。
まあ実際自由に改変されてるから確かにコミッタの名前を明示くらいはしてほしいものだが
考えたことはあるけれど (スコア:2)
gitでも何でもいいんだけど物書きにも使ってみようかなと思ったことはありますよ。
変更履歴が残るし簡単に元に戻せるし、あと編集との共同作業がやりやすいだろう
というのがもっとも良さそうな点。
問題は、gitなどバージョン管理を使うことができる編集者は滅多にいないという点で
実際にやったことは無いですけど。
現実的にはWikiとかのほうが、より一般的かもしんない。でもWikiはそのままじゃ
使えないだろうなあ
Re:考えたことはあるけれど (スコア:1)
実際に運用されている方はいるみたいですよ。
Geekなぺーじ:オーム社開発部での開発体制 [geekpage.jp]
Re:考えたことはあるけれど (スコア:1)
Wiki風マークダウン記法で原稿を作って、HTMLやIDML(InDesign互換形式)、ePubに変換して出力できるcpub [xmldo.net]ってのがあるらしいですね。
CPubについて書いてみた [blogspot.com]
CPubってなんだ？ [hatena.ne.jp]
# SlashDot Light [takeash.net] やってます。
Re: (スコア:0)
> 問題は、gitなどバージョン管理を使うことができる編集者は滅多にいないという点で
WordやExcelの履歴管理機能ですらまともに使われたためしがなくて履歴管理機能を要望される始末だからね。
Re:考えたことはあるけれど (スコア:1)
なぜあれが使えないかというと、そのWordファイルを開かないと履歴が見れないから、というのは
意見として聞いたことありますね。なるほど、とは思いましたが
ロード違い (スコア:0)
×制作されたのは「Load of the Files」(ファイルの王) という記事
○制作されたのは「Lord of the Files」(ファイルの王) という記事
# ファイルだから Load したくなる気持ちも分かるので AC
Re: (スコア:0)
「指輪物語」に倣って、「ファイル物語」でもいいかもね。
Re:ロード違い (スコア:1)
LIVE-GON(リベゴン)
Re: (スコア:0)
おっと、失礼。ご指摘 thx です。
# やはり深夜に編集するのはよろしくないな。
Hiroki (REO) Kashiwazaki
翻訳 (スコア:0)
例えば原文が英語でどんどん改稿されて行った場合、その日本語訳は各バージョンにつき訳の第何版とかいうことになって……。
すげー大変そう。
Re: (スコア:0)
日本語版ウィキペディアの翻訳記事が古い英語版から翻訳したきり放置されているとか独自に加筆されて別物になっていくとかよくありますね。
gitではなくgithubである理由 (スコア:0)
某社もgitではなくgithubを導入しているそうなのですが、このメリットってなんなのでしょうか?
Re: (スコア:0)
gitとgithubって比較はおかしい気もしますが、それはそれで置いておいて…
githubは一部では既にSNS的な感じに使われているので、単なる
リポジトリサービスというよりコミュニケーションサービスに近い状況になってます。
なので単なるツールではなく、ソリューションとしてみれば結構便利だと思いますよ
＃ソースの読み逃げはダメ！…なんて話は今のところありませんが
Re: (スコア:0)
そのうち、forkするときはcommiterカードをコンプするまでまでガチャを回し続ける羽目になったりするわけですね。
Re: (スコア:0)
「いきなりpull requestするなんて礼儀知らずです！まず挨拶するもんじゃないんですか？」
「無断forkされるのでprivateにしますね＾＾」
「issue乱立禁止！」
＃これがまかり通っていたんだから、某SNSはある意味すごいわな
Re: (スコア:0)
gitとgithubを比較した理由は、ゲーム系の某G社やD社もGithub enterpriseというのを使っていると聞いたからです。
技術会社なら、普通にgitでいいと思うのに、なぜgithubをわざわざ導入するかというところに興味があります。
wiredの場合は、一般人でもなんとか使えるツールであった必要はあると思いますが。
というか、この記事の日本語の修正、改善提案って、どういう手続きでやればいいのだ。
Re:gitではなくgithubである理由 (スコア:2)
ゲーム会社さんはデザイナーがぞろぞろいて素材やなんかをコミットするでしょうから
使い易さは見た目は他の技術系よりずっと重視されると思いますけど。
Re: (スコア:0)
githubって、gitを使わずにコミットできるの?
Re:gitではなくgithubである理由 (スコア:2)
デザイナーが使うツールにはあまり詳しくないですが、ゲーム会社さんがよく使っている
Autodesk MayaやPhotoshop類にはSubversionのプラグインが普通にあったりするので
gitのプラグインも探せばあるかもしれません。
ゲーム会社の場合、存在しないツールは内製してしまうことも多々あるし、プラグインで
gitに対応する形になると思います。
Re: (スコア:0)
炎上マーケティングで注目を引くためではないでしょうか。
http://opensource.srad.jp/story/12/01/25/0741213/ [srad.jp]
常識的に考えて、あらかじめ法務に根回しを完了していない限り公開後わずか数時間でライセンスを変更できるわけがありませんよね。
まあそれはともかく、技術者ならOpenPNEとmixiを比較したりWordPressとライブドアブログを比較したりWikiとウィキペディアを比較したりするのに当然違和感を覚えるものと思っていましたがそうでもないのですね。
Re: (スコア:0)
GitHub Enterprise [github.com]は社内向けソリューションなので、そこで話題になっている件とは違いますよ。
電子書籍 (スコア:0)
国会図書館法を改正して電子書籍に納本義務を課してもらいたいものだ。もちろん改訂があった場合はその差分も。