C# Design Notes / デザイン プロセスについて
Roslynプロジェクトで、GitHubへの移行後初の「C# Design Notes」が公開されたみたいです。
https://github.com/dotnet/roslyn/issues/98
「続に言うC# 7」(順調に行けばC# 7になるであろうもの)に関する話題も初お目見え。単に「こんな仕様を考えています」という話出はなくて、仕様決定プロセス自体をもっとオープンにしていく話や、どういうテーマを持って決めていこうとしているのかという話が含まれています。
今出ている「新機能候補」については、どうせ変わるだろうし、さらっと流す感じで。ここでは、どちらかというと、デザイン プロセスとかテーマの話を中心に軽く和訳しておこうかと。
とりあえず、デザイン プロセスに関する話を書いてたら、気が付いたら全訳してた。今日はここまで（C# 7 で取り組むテーマや、具体的な機能案の話は後日）。
以下、その翻訳内容。
デザイン プロセス
昨年の「C# 6 設計」に関する design notes を、CodePlex 上で公に共有することは大いに成功した。我々がどう考えているかを、コミュニティがリアルタイムに見て、応えることができることは、大変高く評価された。
今回、さらにオープン性を増すことを望む。
- デザインのサイクルの初期からコミュニティを巻き込みたい。(この notes のように！)
- デザイン ノート (現在では GitHub の issue を利用)に加えて、機能の提案書についても、その機能の現在のデザインを反映するよう保守していく（例えば、Markdownドキュメントをチェックインするなどして）。
- デザイン ミーティングの録画を公開するか、あるいは、ストリーミング配信することを考えている。
- マイクロソフト外のメンバーもデザイン チームに追加することを考えている。
デザイン チーム
C# 7 デザイン チームの現在の構成は以下の通り
- Anders Hejlsberg
- Mads Torgersen
- Lucian Wischik
- Matt Warren
- Neal Gafter
- Anthony D. Green
- Stephen Toub
- Kevin Pilch-Bisson
- Vance Morrison
- Immo Landwerth
Anders は chief language arghitect で、「いずれ必要になるであろう」(“should that ever become necessary” で、そういう熟語っぽい？たぶん)、最終的な発言権を持つ。Mads は C# の language PM で、議題をまとめ、ミーティングを取り仕切り、このノート を取っている。
始めに、我々は週に4時間ミーティングを行い、全体的なフォーカス領域を決定する。Visual Basic のデザイン ミーティングがこれと別に行われることは、この最初の期間の間はなくて、今回のこの全体的な決定の多くはほぼ、C# と VB の両方に適応され、協力が必要である。
機能のアイディア
誰でも、GitHub 上の issue として、機能に関するアイディアを提案できる。我々はそれに目を通して、言語デザインへのインプットとして使う。
機能に関する興味の度合いを測る方法として、提案は UserVoice (投票システム)上に掲載する。これは重要で、なぜかというと、この GitHub リポジトリに入り浸ってくれるような方々は、必ずしも、我々の開発者母体の代表者ではないからである。
デザイン ノート
デザイン ノートは「その時点における」ドキュメントで、毎度、GitHub 上の issue として上げていく。しばらくの間、みなさんがその issue にコメントでき、そのリアクションは以降のミーティングに反映される。
オーナーと提案
デザイン チームが機能に関するアイディア取り組むと決めた場合、そのアイディアに関するオーナーを選出する（典型的には、オーナーはデザイン チームのメンバーの誰か）。オーナーは、その機能のデザインに関連するアクティビティを推進する（例えば、フィードバックを集め、各種ミーティングを進めるなど）。もっとも重要な点として、オーナーは提案ドキュメント（機能の現状を記述）の保守し、その機能に関する議論があった複数のデザイン ノート間を相互リンクしていくことについての責任を持つ。
提案は時間とともに発展していくであろうものなので、履歴の追跡があるリポジトリ内のドキュメントであるべきである。最初に提案された時や、大きな改正があった時には、おそらく issue として上げて、コメントを集める場とする。提案の pull-request も可能である。
この過程を楽しみ、バランスを取っていきたい。
その他、オープン性を増すために
その他、何かアイディアがあれば非常に興味がある。(ミーティングの)録画公開やストリーミング配信などデザイン ミーティング自体に対する案、マイクロソフト外の指導的な人物(例えば、産業界の重要人物など)をミーティングに迎える、などなど。もちろん、我々が活用したいような洞察を持つ人が誰かいれば、「ゲスト」（物理的でも仮想的でも）参加についてもオープンである。
しかしながら、これはゆっくりと進めていく。始めからすぐにとは考えていない。
決定
非常に重要な気に留めておいてほしい点として、C# デザイン チームはいまだ、この言語を管理している。これは民主的な(democratic)プロセスではない。我々はコメントは UserVoice 投票から計り知れない価値を引きだしはするが、C# の最終的な統治モデルは優しい独裁者(benevolent dictatorship)である。我々の考えでは、小さく緊密に結びついた、長期的に関われるメンバーでのデザインこそ、C#を優雅で、一貫していて、大きすぎず、いわゆる「designed by committee」(船頭多くして船が山に上るようなもの)ではないものに保つ正しいモデルである。
もしデザイン チーム内で合意が得られなかったなら、典型的にはそれは、ミーティング後に個別でより深い洞察ができるであろう徴候である。たいていは、その日のうちの投票や、言語の「全ての父」(Allfather: 主神)に最終決定を委ねる必要はない。
プロトタイプ
理想的には、議論するすべての機能についてプロトタイプ作成して、その機能から良い感触を得、コミュニティからのフィードバックを可能な限り集められるようにすべきである。それは現実的ではないだろうが、よい機能候補がひとたび見つかれば、飛び込んでみるべきだろう。
プロトタイプ作成のコストが核心である。機能によるだろうが、ときには急ぎで使い捨てなプロトタイプがほしくなるし、またあるときは実際の実装の初期バージョンが必要になる。
これは、デザイン チーム、製品チーム、もしくは、コミュニティの誰かによって行われるだろう。
アジェンダ
ミーティングで何が議論できる状態にあるか決めるのは、通常は Mads の債務である。一般に、デザイン チームのメンバーの誰かが何かをアジェンダに載せたい場合、そのことに納得している。ミーティングで計画通りに終わる保証はない。ここで公になっているノートはただ、実際に議論があった内容の概要をアジェンダとして示している。
コメントを残す