提案の提出

新しい提案を提出する前に、以下の点をご検討ください。

多くの個人および企業（大小問わず）が、現在リリースされている機能セットのまま、本番プロジェクト（新規開発と既存システムの両方）でSailsを喜んで使用しています。その大きな理由は、Sailsが開発会社を運営していたコアチームによって開発されたことにあります。Sailsは、さまざまな種類のアプリケーションを概念から本番環境まで開発し、その後、数年間にわたる保守を通じてそれらのアプリケーションのバックエンドとして機能するために使用されました。

Ruby on Railsの典型的な例と同様に、Sailsは当初から、コンベンションオーバーコンフィギュレーション方式を用いて、開発者フレンドリーでありながらエンタープライズフレンドリーになるように設計されました。**コンベンション**により、新しいSailsアプリの構築や、異なる既存のSailsアプリ間の切り替えが迅速かつ容易になり、**構成可能性**により、Sails開発者は柔軟性を持ち、基盤となるツールチェーン（構成、プラグイン/オーバーライド、Express、Socket.io、Node.js、JavaScript）の全機能を使用して、それらのアプリを成熟させることができます。

Sailsの最初の1年間で、**構成可能性**の要件はさらに重要になりました。ユーザーベースの拡大と、あらゆる種類の異なるプロジェクトや、さまざまな好みに持つ開発者によるSailsの使用開始に伴い、機能要求の数は急増しました。Sailsは2013年にコアを書き直し、本質的に相互運用可能になることで、この問題を解決しました。

• SailsアプリはNodeアプリであるため、数百万ものNPMパッケージをhttp://npmjs.orgで利用できます。（そして最近では、http://node-machine.orgでキュレーションされた、自動的にドキュメント化された数百もの機械機能も利用できます。）
• SailsはExpressとConnectと同じreq/res/nextパターンを使用しているため、Lusca（Paypalのセキュリティミドルウェア）やmorgan（HTTPロギングユーティリティ）など、これらのミドルウェアフレームワーク用に記述されたミドルウェアをアプリで利用できます。
• SailsはConsolidateを使用しているため、Jade、Dust、Handlebarsなど、Expressと互換性のあるビューエンジンを使用できます。
• Sailsは使い慣れたMVCプロジェクト構造を使用しているため、あなたやチームの他の開発者は、アプリの動作、データベーススキーマを迅速に理解し、一般的な構成オプションの場所についても大まかに把握できます。
• SailsはGruntを使用しているため、https://grunt.dokyumento.jp/pluginsにある数千もの利用可能なGruntプラグインをアプリにインストールして使用できます。
• Sailsのフックシステムを使用すると、GruntをGulpに置き換えるなど、アプリの機能の大部分を無効化、置き換え、またはカスタマイズできます。これにはSailsコアの一部も含まれます。
• Waterlineのアダプターインターフェースを使用すると、Oracle、MSSQL、Orient DBなどのデータベースにモデルを接続できます。
• Skipperのアダプターインターフェースを使用すると、S3、GridFS、AzureなどのBLOBストレージコンテナに、受信するストリーミングファイルアップロードを接続できます。
• Sailsのジェネレーターシステムを使用すると、sails newまたはsails generate *を実行したときにSailsコマンドラインツールが生成するすべてのファイルとフォルダーを完全に制御できます。

現在、Sailsの新しい機能のほとんど（ただしすべてではありません）は、コアに変更を加えるのではなく、既存のプラグインインターフェースの1つ以上を使用して実装できることを理解することが重要です。要求する機能がその規則の例外である場合は、先に進んでください。ただし、提案の中で最も重要なのは、現在不可能な理由を明確に説明することです。

Sailsのコアメンテナーはすべての機能提案をレビューし、これらのPRでの議論にできる限り参加します。ただし、これらの提案の中には、数ヶ月間開いたままにする必要があるやり取りが必要になるものもあります。したがって、機能を提案する場合、その機能の動作方法（使用方法、構成方法、特に実装方法、つまり、実現するために変更が必要なモジュール、テスト方法、メジャーバージョンまたはマイナーバージョンの破壊的変更となるかどうか、公式Sailsドキュメントに必要な追加と/または変更など）を完全に指定する責任はあなたにあることを理解しておくことが重要です。

それを踏まえ、新しい機能、または既存機能の拡張機能の提案を提出するには、以下の手順に従ってください。

0. まず、ROADMAP.MDのbacklogテーブルを確認し、そのファイル内の未解決のプルリクエストを検索して、変更が既に提案されていないことを確認してください。
   • PR（プルリクエスト）がマージされている場合、コアメンテナーが（A）プルリクエストの提案と議論を確認し、（B）その機能がSailsコアに適していることに個人的に同意し、（C）@mikermcneilと決定を確認したことを意味します。また、提案がROADMAP.mdのバックログに含まれていることも意味します。つまり、コアチームは、（そのプルリクエストが当社のコーディングスタイルの規則とこのセクションのガイドラインに従っている場合）Sailsコアに機能を追加するコード変更を含むプルリクエストのマージを喜んで行うということです。
   • PRがマージされずに閉じられている場合、コアチームが、機能要求をSailsコアの一部にするべきではないと決定したことを意味します。提案が閉じられているからといって、Sailsでその機能が決して実現不可能になるわけではありません。単に（A）マージするには仕様を変更する必要があるか、（B）プラグイン（フック、アダプター、ジェネレーター、ビューエンジン、grunt/gulpタスクなど）として実装する必要があることを意味します。
   • PRが未解決の場合、（A）最近投稿されたか、（B）アクティブな議論が進行中であるか、（C）コアメンテナーがまだ確認する時間がなかったか、または最も一般的なケースとして（D）1人以上のコアメンテナーが提案を確認し、潜在的に対応した可能性がありますが、チームが確実な「はい」または「いいえ」の判断を下すのに十分な情報がないと判断したことを意味します。この4番目のシナリオは非常に一般的です。バックログにマージするのに十分な徹底的な仕様を策定するには、多くの時間を要することがあるためです。コアメンテナーは、時間がある限り提案をレビューして貢献しますが、最終的には、機能を要求する開発者がそれを完全に仕様化する責任があります。
   • Sailsのコアメンテナーの中には、（他のメールも受信したいので）GitHubからのメールを注意深くフィルタリングするものもいますが、多くのコントリビューターは、新しいコメントが投稿されるたびにGitHubの通知を受け取ります。彼らへの敬意として、機能提案を*bump*したり:+1:したりしないでください。代わりに、機能に対する現実世界のユースケースを簡潔に（3〜5文）説明してください。
1. まだ存在しない場合は、ROADMAP.MDを編集するプルリクエストを作成します（これを行う最も簡単な方法は、GitHubにログインした状態でROADMAP.mdを開き、「編集」ボタンをクリックすることです）。
2. 機能の非常に短い説明を付けて、**バックログ**テーブルに新しい行を追加し、変更をプルリクエストとして提出します（これを行う最も簡単な方法は、上記のようにGitHub UIを使用し、変更を加えてから画面の指示に従うことです）。
3. プルリクエストの説明で
   • まず、提案する機能の概要を簡潔な説明（3〜5文）として書き出します。この説明は、あなたが仕事、クライアント、会社、非営利活動、または独立した趣味プロジェクトのために構築または保守しているSailsアプリがこの機能または変更によって容易になるような、説得力のある現実世界のユースケースを中心に展開する必要があります。
   • 次に、コードファイルへの関連リンクを使用して、Sailsコアを変更せずに（既存のプラグインメカニズムの1つ以上を使用せずに）機能を実装することがなぜ困難または不可能であるかを明確な文章で説明します。そうでない場合、この機能をプラグインとして実装できる場合は、提案の記述を見直してください（コアチームがそれを受け入れる可能性は低いです）。1つ以上のプラグインの作成者であり、あなた自身または他のユーザーがSailsコアにあなたの作業を含めることで利益を得られると感じている場合は、コアチームに直接連絡してください（上記の「プロジェクトに関する高度な質問や懸念事項の提出」に関する指示を参照してください）。
   • 最後に、時間があれば、この機能の仕様（構成、使用方法、および実装方法）の最初の試みを行ってください。徹底的な仕様の最初のドラフトを作成する時間がない場合は、機能要求にその点を明記し、同じまたは類似のユースケースを持つ他のコントリビューターが提案を完成させることを明確にしてください。

これらのガイドラインを満たしていない提案は、提出者にこの貢献ガイドを確認するよう求める回答とともに閉じられます。これがあなたに起こった場合、個人的なものではないこと、そして再び起こる可能性があることを理解してください。Sailsの既存のプラグインシステムには膨大な労力が費やされていることを考慮してください。したがって、コアへの提案された変更は、既存のプラグイン、既存のアプリ、およびフレームワークの将来の開発にどのように影響するかを注意深く検討する必要があります。多くのSailsコントリビューターは、Sailsのさまざまなシステムがどのように相互作用するかを熟知しており、喜んでお手伝いしますが、そのプロセスを効率的にするために、すべての新しい機能と拡張機能が共通のルールに従うことが重要です。

機能提案がマージされた場合...

提案がマージされたからといって、必ずしも機能の実装を担当するわけではありません。そして、間違いなく、将来その機能に影響を与える可能性のある変更を永遠に保守する責任はありません。その特権はMikeとコアチームの残りのメンバーに予約されています。そのため、提案された機能の使用、構成、および実装のビジョンを1日目から明確に示すことが非常に重要です。このような詳細な提案を作成することは容易ではなく、多くの場合、実際の開発よりも多くの労力を必要とします。しかし、提案が承認されると、それはプロジェクトのミッションの一部になります。つまり、実装されてマージされると、コアチームはそれをSailsの一部として保守することにコミットします。