Actions日本語このページはコミュニティーの尽力で英語から翻訳されました。コミュニティーについてもっと知り、仲間になるにはこちらから。載せるコンテンツの基準、新しい文書を載せるための申請手続き、申請する側への要望やガイドラインについて、詳しく記述しています。これは大規模なプロジェクトを対象としています。新しいページや記事を提案するには、「私たちが書くものは何か」ページのコンテンツの提案の節を参照してください。使命は、信頼できる標準化団体によって公開された仕様書にあり、少なくとも一つの安定したブラウザーで対応しているウェブ標準技術を文書化することです。これらの基準は、ウェブ業界全体による十分な関心、安定性、そして「実装する意図」を示すものです。したがって、これらの技術は、私たちが文書化に時間と労力を費やしても問題ない技術だと考えています。これより早いと、ウェブ技術や機能は、関心の低さから取り消される可能性があったり、とても不安定で大きく変化する可能性があったりして、不必要に多くの書き換えが必要になります(私たちは可能な限りこれを避けようとしています)。ウェブ以外の標準技術ウェブ以外の標準技術とは、上にまとめた私たちの基準に従わない技術のことです。文書としてそれらを検討することはありません。私たちのミッション・ステートメントは、「オープンなウェブ上でプロジェクトを簡単に構築するために必要な情報を開発者に提供すること」です。これは、たとえそれがオープンなウェブ標準でなくとも、ウェブ開発者にとって有用な技術を文書化し、標準化トラックなどに載せることを検討すべきであると示唆しています。含めることを検討したいのであれば、以下の基準に一致することを確認する必要があります。検討するためには、ここに記述した基準を満たす必要があります。私たちはオープンな技術を支援しています。私たちは、単一の組織によって管理され、関心を持つあらゆる人に開放されておらず、複数のプラットフォームやシステム間で相互運用できないような、閉じた技術のエコシステムを支持しません。私たちは、技術はオープンに作成されることで、誰にとってもよりよく動作すると信じています。ウェブで公開され、ウェブ技術に関連するものであること私たちの中心的な任務はウェブ標準技術です。ウェブに関連のない技術、あるいはウェブ開発者の関心を引くことのない技術の文書化を始めても、この点には意味がありません。関心と採用の兆候が示されていること私たちは、業界からの関心や採用の兆しがない技術を文書化することに時間を費やしたくありません。文書化することを検討してもよいかもしれません。非推奨または代替される兆候がないことこの点とも関連しますが、ライフサイクルの後半にあり、すでに関心が薄れつつある技術の文書化に時間を費やしたくないという思いもあります。他の場所で確立された文書化リソースがないことウェブ標準ではないものの、ウェブ技術の上に構築され、ウェブ業界でとても人気のあるライブラリーやフレームワークがたくさん存在しています。一般的に、これらはすべてすでに確立された文書化されたリソースがあるため、私たちはこれらの文書を一切作成していません。人気のあるフレームワークの公式リソースと競合するのは愚かなことです。することは時間の無駄であり、おそらくその技術を学ぼうとする開発者を混乱させる結果になるでしょう。チームは、オープンウェブプラットフォームの文書化に集中しています。文書化の対象として検討したい場合、文書を書き、完成後もそれを維持することをいとわないコミュニティが集まっている必要があります。私たちのチームは、そのような場合、編集やフィードバックなどの指導を喜んで提供しますが、それ以上のリソースは持ち合わせていません。「公開の場」で行われます。精通し、オープンソースで一緒に作業することに抵抗がないことが望まれます。この節では、提案に含めるべき内容を記述します。いうタイトルの提案書(英語)を提出する必要があります。提案書には、次のような情報が必要です。技術、その中核となる目的/用途、ターゲットとなる開発者層。この技術について、どのような業界やコミュニティの話題があるのか。多くのウェブ開発者が使用しているのか。業界ではどのような採用が進んでいるのか。多くのウェブ開発者がこの情報を欲しがったり、必要としたりしているのか。この情報のターゲット層はどの程度か。補助的な統計データがあれば役立ちます。ブラウザーとどのように関連しているのか。役立つ詳細は以下の通りです。使用するが、一般的にウェブに出力しないのか。ポリフィルでウェブブラウザーが対応しているか。その技術をカバーする、既に利用できるドキュメントやリソースは何か。追加する文書はどれくらいの規模か?要素/メソッド/属性などのガイド、チュートリアル、参照ページなどの予定数を列挙してください。大まかな目次を提供してください。この資料には、基本的な文書化ページを超える、どのような「高度な」機能が必要だと考えられるか。埋め込み動画、インタラクティブなコードサンプルなどを入れることを想定しているか。誰が文書化するのか?彼らは誰で、なぜその仕事にふさわしいのか。文書の管理はどうするのか。この段階で何百ページもの詳細な情報を提供する必要はありません(むしろ、提供しない方が良いでしょう)。この点については、それぞれ数段落程度で十分です。プロジェクトの主要言語は、米国英語である必要があります。提案書に記載された技術や提出された情報を検討し、次のいずれかの回答で対応します。文書化される基準を満たしているとは思えません。Docsで文書化するのに適しているかどうかわからないため、さらにいくつかの質問をさせてください。載せるのが適切だと考えています。その技術が良い候補であれば、文書化に向けてチームが支援します。文書化対象として認められたら、次のステップに進みます。新しい技術を文書化するプロジェクトを成功させるために、次のものを所有していることが必要です。専用チーム最初の文書を作成するだけでなく、将来的に必要な更新を行うための保守を行う専門チームがあることを確認してください。どのくらいの作業量があるのか、そのために何人必要なのか、考えてみてください。大きなプロジェクトであれば、執筆者が数名いて、作業が技術的に正確かどうかをチェックする技術レビュアー、言葉をきれいにするコピーエディター、コード例を書く人などがいると、より効果的でしょう。人しかいないかもしれません。うまくいくのであれば、どのようにチームを構築してもかまいません。側でガイダンスを提供します。人)任命してください。組織で作業するために必要なパーミッションを返すのを手伝います。確認するためのマイルストーンなどを作成しましょう。プロジェクトが大規模な場合は、チームメンバーの一人をプロジェクトマネージャーとして任命することを検討すべきです。product)を包含する最初のリリースのためのサブプロジェクト計画を書くことも検討すべきです。次の追加でそれをフォローアップすることができます。書いた、レビュー済み、完了)、誰が何の作業をしているのかを記録しておくことが必要でしょう。文書をどのように書くことが期待されるかを述べたものです。あなたが書いている文書に追加のガイドラインがある場合は、このガイドを追加し、最新の状態に保つことを期待します。残るためには、妥当なレベルの文章の質を維持することが期待されます。担当者は、何が期待されているのかを明確にするために、一緒に作業します。プロセスを経たのであれば、この技術のために何を書くかという大まかなアウトラインは既に保有しているはずです。この点については、文書階層をどうするか、すべての文書をどこに配置し、リンクさせるかを考え、サイト構成計画に落とし込む必要があります。プロジェクトごとに異なりますが、おおよそ次のようなものをお勧めします。--------その他の種類のリファレンスページ|------ガイド/チュートリアル|------例プロジェクトで使用する各ページの種類には、他の人が構造をコピーできるようなページテンプレートがあることが望ましいです。これらは早い段階で決めておくとよいでしょう。ページの種類の節を参照してください。担当者と連絡を取ってください。残るように整備する必要があります。他の人があなたの技術の文書化に変更を加えた場合、あなたのチームのメンバーがその変更を確認し、コンテンツがまだ良いものであることを確認する必要があります。追跡することができます。技術に変更があり、文書の更新が必要になった場合、あなたのチームは、元の文書と同じ基準を維持しながら、適切に更新を行う必要があります。6ヶ月間積極的な変化が見られず、文書化が次のような状態であると思われる場合。時代遅れになりつつあるこの場合、この技術の文書は死んだとみなされます。チームの代表が話し合った後、その文書は削除されます。質の悪い、不完全な、あるいは時代遅れの文書でサイトを埋め尽くすわけにはいかないので、このような問題には厳しく対応する必要があることをご理解いただければと思います。