Skip to content

Latest commit

 

History

History
92 lines (56 loc) · 5.46 KB

DESIGN.md

File metadata and controls

92 lines (56 loc) · 5.46 KB

DESIGN.md

Objectives

競プロ用のアルゴリズムの解説を集めた百科辞典を作ります。

Goals

  • 競プロの中級者や上級者がより効率的に知識を収集管理できるようにします。
  • 情報が正確であること、管理が容易であること、貢献者が明示されていることの、すべてを同時に目指します。

Non-Goals

  • 競プロの初心者のための教科書を作るのではありません。
  • 学術のための資料を作るのではありません。

Background

解決したい課題について

競プロ界隈では個人ブログが広く用いられていますが、これには「内容が古くなったまま残りやすい」「間違いが修正されにくい」「情報が散らばりやすい」「管理コストが管理者個人に集中する」などの問題があります。より効率的な知識の集積のため、この問題の解決を目指します。

Overview

Markdown で記事を書き GitHub で管理し、GitHub Pages により公開します。議論は GitHub の Issues で、編集やレビューは GitHub 上でのプルリクエストで行います。

Detailed Design

比較: 情報の発信や管理のためのツールについて

競プロ界隈で用いられる情報の発信や管理のためのツールとして、代表的なものは以下のようになります。

  • 個人ブログ
  • SNS
  • 質問サイト
  • 共有 wiki
  • 招待制 wiki
  • GitHub

個人ブログについて。 「比較的簡単に利用できる」「長文や数式が書きやすい」などの長所があります。 しかし、すでに述べたように、これらには「内容が古くなったまま残りやすい」「間違いが修正されにくい」「情報が散らばりやすい」「管理コストが管理者個人に集中する」などの短所があります。 Codeforces のブログもここに含めて考えるべきでしょう。

SNS について。 コンテストの感想や数行程度の解説はたいていツイートの形で公開されます。「とても気軽に利用できる」「コメントが付けやすい」という長所と同時に「数式や長文が書きにくい」「後から内容を編集できない」「検索が難しい」「外部から閲覧できないことがある」などの短所があります。 特に Twitter が多く利用されますが、Slack や Discord が選ばれることもあります。

質問サイトについて。 質問と解答という形をとるため、個人ブログなどとは別物と考えるべきでしょう。 「自分の知りたい内容を質問できる」一方で「必ずしも解答があるとは限らない」のが特徴です。 競プロ専用のサイトとしては procon-qa があります。

共有 wiki について。 「誰でも記事の追加や修正ができる」という長所はありますが「内容の正確性が保証されない」「誰が貢献したのかが不明瞭になりやすい」という短所があります。 Wikipedia や yukicoder Wiki があります。

招待制 wiki にはついて。 適切に運用すれば「管理コストが特定の個人に集中しない」「レビューなどによって内容の正確性を保証できる」という長所を持ちます。 データ構造Wiki があり、内容は充実しています。

GitHub について。 広義の招待制 wiki のように使えます。「編集権限を要求しなくても編集に参加できる」「編集時のレビューを行いやすい」という長所があります。 Library-Checker はとても成功した例です。

GitHub と GitHub Pages を使う

Markdown ファイルを GitHub 上で管理し、GitHub Pages を使って公開します。 Jekyll をそのまま利用し、数式の表示は Jekyll で行います。

GitHub と GitHub Pages を使った公開の長所としては

  • 「プルリクエスト経由で、誰でも自由に記事の追加や修正を提案できる」
  • 「プルリクエストのマージには承認が必要であり、記事の内容が保証される」
  • 「修正やレビューの過程や貢献者がコミットログやレビューコメントなどの中に残る」

があります。これらは個人ブログの形式が抱えていた問題を解決するために役立ちます。 他にも「GitHub Actions として機械的なチェックを走らせられる」「誰でも fork してバックアップを残し複製を作れる」のような長所もあります。

一方で短所としては「数式のプレビューが Web 上ではできない」「git や GitHub の操作ができる人しか編集に参加できない」などがあります。特にプレビューの問題は重大ですが、多くの長所とのトレードオフとして受け入れることとします。

YAML front matter を使う

YAML front matter として、それぞれの記事の説明の対象についての基本的な情報を機械可読な形で記述するようにします。 書き手にとっては「最低限必要な情報が何であるかが明示される」という利点が、読み手にとっては「基本的な情報が統一的な形で提示される」という利点があります。