レビューと公開フィードバック
仕様の公開レビューは、その関連性と品質を確保するために重要です。仕様やチャーターのレビューを通じて、W3Cの作業の品質向上に貢献することができます。
仕様 ![Atom](https://www.w3.org/2008/site/images/icons/atom30)
W3C グループは、notifier を通じて public-review-announce を使用し、公開物の広範なレビューを求める手段の一つとしています。W3C は、仕様が初めて公開された瞬間から標準として公開される直前まで、仕様のレビューを歓迎しています。各 W3C テクニカルレポートには、前の方に「この文書のステータス」というセクションが含まれており、このセクションにはコメントの送信先に関する情報が記載されています。
仕様が標準化プロセスのどの段階にあるかに応じて、W3C は異なるタイプの入力を求めます:
- 初回公開ドラフト: W3C は、一般的な支持の声明と技術的なフィードバックを求めており、技術の開発に関心のある人々のワーキンググループへの参加を奨励しています。
- 実装の呼びかけ: これは、文書がコミュニティからの実装経験を集めるのに十分安定していることを W3C が示すシグナルです。
- 提案勧告のレビューの呼びかけ: W3C は、安定した技術レポートについて W3C メンバーシップの承認を求めています。
深い技術的なレビューは、プロセスの早い段階で最も評価されますが、誰でもいつでもバグを見つけ、それについてのフィードバックを W3C に提供することができます。W3C プロセスは、公平性、応答性、進展を促進するように設計されています。推奨トラックの要件およびレビューとレビュー責任について詳しく学びましょう。
バグの報告
仕様のエラーは、使用を通じて時間とともに明らかになります。仕様にバグを発見したと思われる場合は、以下の手順をお勧めします:
- 仕様が標準(「W3C 勧告」)である場合、仕様の表紙ページには正誤表ページへのリンクが含まれます。正誤表ページには、これが既知のバグであるかどうかが示され、そうであれば修正案が記載されている場合があります。正誤表ページには、バグがリストにない場合の対処方法も説明されています。
- ドラフト文書の場合、文書の「ステータスセクション」には仕様に関するフィードバックの送信先に関する情報が含まれています。
一般に、バグの理解を助けるために提供できる情報が多いほど良いです。
今後のチャーター ![RSS](https://www.w3.org/2008/site/images/icons/rss30)
W3Cの新しい作業を開始するプロセスの一環として、W3C会員はドラフトチャーターをレビューします。同時に、W3Cはドラフトチャーターに対する公開コメントも募集しています。ドラフトチャーターのアナウンスのアーカイブを参照してください。
仕様の実装
標準化プロセスの一環として、W3Cはグループが実装経験を示すことを要求します。W3Cは標準化の一環として実装経験を求めており、一般の参加を歓迎しています。
テストスイートの使用または開発
W3Cは、仕様の機能の相互運用可能な実装を示すために、ソフトウェア開発者のコミュニティと協力してテストスイートを作成します。W3Cのテストスイートの使用について詳しく学びましょう:
- テストスイートのためのライセンス
- The Webプラットフォームテストプロジェクト、これには可能なテストスイーツが含まれます。
または、テストスイートを開発する場合:
実装の評価
W3Cは現在、ソフトウェア、コンテンツ、個人、その他の組織に対する認証プログラムを持っていません。しかし、W3Cは、標準に対応していると主張するコンテンツやソフトウェアを評価し、その結果をコンテンツやソフトウェアの責任者に報告することを奨励しています。評価の過程で仕様にバグがあると思われる場合は、バグを報告するよう招待しています。
W3C オープンソースの利用や貢献
W3Cはオープンソースソフトウェアの強力なサポーターであり、ユーザーです。W3Cは、W3Cオープンソースプロジェクトの完全なリストを参照し、貢献することを奨励しています。