タグ

OSSとMarkdownに関するraimon49のブックマーク (7)

  • linguist/vendor/README.md at main · github-linguist/linguist

    This is a list of grammars that Linguist selects to provide syntax highlighting on GitHub. If you've encountered an error with highlighting, please find the grammar in the list below and report it to the appropriate repository. Note: grammars marked with 🐌 are not updated when Linguist is so upstream fixes may take longer to appear on GitHub. 1C Enterprise: 1c-syntax/vsc-language-1c-bsl 2-Dimensi

    linguist/vendor/README.md at main · github-linguist/linguist
  • Sphinx のメンテナになって一年が経過した話 - Hack like a rolling stone

    クリスマスが過ぎてから始まる Sphinx アドベントカレンダーへようこそ (嘘) Sphinx 大型連載第二夜です。 タイトルにある通り、Sphinx のメンテナ活動をして一年が過ぎたので、その話をします。 OSS 開発者のひとつのサンプルケースとして、何かの参考になれば幸いです。 Sphinx のメンテナ活動をはじめました 去年の 12月から Sphinx のメンテナ活動をはじめました。 Python のリリースマネージャ活動が忙しかったからか原作者の Georg の活動が鈍り、 また、その後を継いだ清水川さんも忙しくて身動きが取れなくなっていたことから、 コミット権をもらっていたことだし、パートタイムで手伝うかと思ったことがきっかけでした。 以前からコミット権は持っていたものの、一切メンテナとしての活動をしていなかったので、 徐々にチケットが溜まっていく様子に後ろめたくなったのかもし

    Sphinx のメンテナになって一年が経過した話 - Hack like a rolling stone
    raimon49
    raimon49 2017/01/02
    3,000件以上のIssuesトリアージを少人数でさばくの凄く時間取られて大変だろうなと察せられる。頭が下がる。
  • Is it maintained?

    Is it maintained? Check the activity of open source projects

    raimon49
    raimon49 2015/09/10
    issueへの活動を可視化
  • テクニカルライティングの将来 ー GitHub上のAsciidocで技術書Pro Gitを協働執筆 | POSTD

    Pro Git第2版の驚くべき冒険と最終的なツールチェーン ほぼ6年前、私はApressから執筆が予定より遅れていたPro Gitと呼ばれるの手伝いの誘いを受けました。結局原著者が書き続けないことを決めて、私が最初から書き直して2009年8月頃に最終的に出版されました。最初の3章あたりは、私はWordでを書きました。そして編集者に文書を送って、しばらくして最終的な版を手にしました。 この3章のあとで、私たちが執筆と技術的な編集段階のためにMarkdownに切り替えて、同意された編集のためにだけWordへ戻るように提案したとき、私はやめようとしていました。一旦が完成したら、私はすべての内容をMarkdownへ再び戻したので、それを私が作成したWebサイトにおいてオンラインで発表できました。幸運にも、原著者は著作をクリエイティブ・コモンズ・ライセンスとすることでApressと同意しました

    テクニカルライティングの将来 ー GitHub上のAsciidocで技術書Pro Gitを協働執筆 | POSTD
    raimon49
    raimon49 2014/12/15
    表現力の貧弱なMarkdownからAsciiDoc へ、pushされると自動で電子書籍としてビルドされるO’Reilly Atlasシステム、コミュニティベースの翻訳など。
  • わかりやすいREADME.mdを書く

    GitHubなどに自分のツールやライブラリを公開するとき,README.mdは重要な役割を担っている.レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている,と言っても過言ではない.実際自分が使う側になったときも,まずREADME.mdを読んで判断していると思う. 成功しているプロジェクトを参考にしつつ,自分が実践していることをまとめておく.ここに書いていることはあくまで(自分の中で)最低限的なものである.プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う. READMEの役割 README.mdには大きく2つの役割がある. プロジェクト,ツールの使い方,インストール方法 プロジェクト,ツールの宣伝 元々READMEは前者の役割しかなかったが,GitHubの仕組み上,後者の役割も徐々に重要になっている. さらに

    raimon49
    raimon49 2014/08/01
    テンプレート良い。
  • GitHubで雑誌・書籍を作る

    6. 執筆陣は一流のエンジニア @naoyaさん :雑誌、書籍( 3冊!)、ムック @hirocasterさん:雑誌、書籍、ムック @amatsudaさん :雑誌、ムック @miyagawaさん :雑誌( Vol.2から!)、ムック @kenchanさん :雑誌、ムック @yandodさん :雑誌、書籍( 2冊!) ! ※日の登壇者・運営チームより(登場順。漏れがあったらすみません) ※会場にはもっとたくさん!

    GitHubで雑誌・書籍を作る
    raimon49
    raimon49 2014/06/01
    もはやmd2inaoではなくmd2indesign
  • Paperboy's engineer evaluation system - Gosuke Miyashita

    今年から新たにペパボで導入された、技術者向けの評価制度については、こちらのエントリ で書いたのですが、日、その一次評価が完了しました。 評価のプロセスは、一次はテクニカル・マネージャーによる評価、二次は経営会議メンバーによる評価、と二段階の評価となっています。 自分が担当した一次評価の詳細は、以下のようになっています。 シニア、またはアドバンスドシニアに上がりたい人には、自ら立候補してもらう。 立候補する人は、定められたフォーマットにしたがって、自分がそのポジションにふさわしいと思う理由や実績について Markdown で書き、指定した Git リポジトリに push する。(「定められたフォーマット」と言っても、最初に名前、次に希望のポジションを書いてもらうだけで、それ以外は自由。) 文書提出後、一人一人と面談を行う。 文書の内容と面談の結果にもとづいて、各人が提出した文書の末尾に、結

  • 1
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy