それを送ってフィードバックを求めるとよいでしょう。パッケージ名を繰り返すのではなく、簡潔かつ有益なものである必要がある、となっています。概要は、完全な文章ではなくパッケージを記述するフレーズとして機能します。追加の大文字や最後のピリオドは不要です。library技術的に言えば、動詞のフレーズに対して、これは名詞のフレーズから文章を差し引いたものです。パッケージ名と要約をこの決まり文句に代入できるのがよい見つけ方です:パッケージの名前は概要を提供します。つに分けた別の書き方をした方が良いでしょう。documentationこれらの要約が、手が加えられた決まり文句に続きます。いう要約を持つ場合、要素はフレーズにすべきで、決まり文句に合うようになります:パッケージ名は、プログラム一式に対する役割を表しています。長い説明文は、ユーザーがパッケージをインストールする前に利用可能な最初の情報です。ユーザーがインストールするか否かを決めるのに必要な情報を、すべて提供する必要があります。ユーザーがパッケージの概要を既に読んでいると仮定してください。長い説明文は、完全な文章から成る必要があります。技術寄りではない書き方でこれを記述するのが重要です。パッケージの利用者が必然的に技術者ではない限り、です。server)?スペルミスや文法の間違いを避けるよう、注意してください。スペルチェックを確実に行ってください。他のパッケージのアドオンだった場合、パッケージがアドオンであるということを概要文に書く必要があります。パッケージが直接インストールされるべきではないが、他のパッケージから引っ張ってこられる時には、付記しておく必要があります。パッケージが実験的である、あるいは使われない方が良い他の理由がある場合、同様にここに記載する必要があります。追加することをお勧めします。あると考えられています。バージョン管理システムの場所についての追加フィールドがあります。タグがつけられているバグを修正するパッチを探している場合)。ソースから現在のバージョンパッケージを生成ユーザにとって有益であるよう意図されています。バージョンを自動ビルドするなどがあるかもしれません。メインブランチを指すのが良いでしょう。アクセス可能なリポジトリを指すのではなく、匿名アクセスが可能なリポジトリを指すようにすることを意味します。ファイルに対するポリシーを補完します。エントリは、そのリビジョンでの変更それだけを記載します。最後のバージョンから行われた、重要な、そしてユーザに見える形の変更を記述することに集中しましょう。誰が、どうやって、何時なのか通常あまり重要ではありません。丁寧に明記するのを忘れないようにしましょう。些細で明白な変更を詳細に書く必要はありません。複数の変更点を一つのエントリにまとめることもできます。逆に言えば、大きな変更をした場合には、あまりに簡潔にしすぎないようにしましょう。プログラムの動作に影響を与える変更がある場合には、特に確認しておきましょう。ファイルを使ってください。平易な英語を使いましょう。すれば読者の大半が理解できます。バグをクローズする変更を説明する際には略語や、テクニカルな言い方やジャーゴンを避けましょう。技術的に精通していないと思われるユーザによって登録されたバグを閉じる際には気をつけましょう。礼儀正しく、断言をしないように。エントリに変更したファイルの名前を頭に付けたくなることがあります。個々のすべての変更したファイルを一覧にする必要性はありません。変更点が小さくて繰り返される場合です。ワイルドカードを使いましょう。バグに触れる際には、何も仮定しないようにしましょう。文字列を追加しましょう。記載するべきではありません。システム上でそのようなことがどのように扱われるかを多少は知らされているでしょうから。設定ファイルの場所を変更したのであれば、それは一言添えておくべきです。エントリでクローズされるバグは、実際にそのパッケージリビジョンで修正されたものだけにすべきです。関係ないバグを閉じるのは良くない習慣です。使うべきではありません。そのようなことは、大抵の場合対象としている読者は気づくことが無く、パッケージで実際にあった変更点の情報について読みたい人々を悩ますことでしょう。どの様にバグ報告システムを使えばいいのかについて、詳細な情報はバグへの対応を参照してください。修正されたバグを承認するのは、古い慣習です。エントリ中でその事実に触れるだけで十分です。エントリ中のよくある間違いや間違ったスタイルの例を挙げます。bugs.これは、全く読み手に何も有用なことを教えてくれません。代わりにバグ追跡システムを使ってください。次に、何故この報告がバグではなかったのかについての説明がありません。説明文を考えられないのなら、それぞれのバグのタイトルを入れるところから始めてください。ファイルにも書くことができます。これは、ユーザにパッケージ内の著しい変更点について知らせるのに好ましいやり方です。列挙するより良いです。ユーザは容易にそのような注意書きを見逃すからです。書くような簡潔な要約ではなく、必要に応じて完全な段落で記述してください。実行してチェックするのは良い考えです。ファイルとしてインストールされます。ネイティブパッケージ中でも常にこの名前です。ファイルをインストールしてくれます。ファイルを更新する必要はありません。何か特にユーザが知るべき目新しいことがあったときにのみ、更新してください。ファイルをパッケージに入れてリリースする必要はありません。Policy.メンテナスクリプトは冪等でなければなりません。回呼ばれた場合、何も悪いことが起きないのを保証する必要があるという意味です。パイプへ向けられる)。あることに依存してはいけません。質問や対話的な設定はすべて最小限に止めておく必要があります。パッケージを使いましょう。段階にのみ、配置することができます。メンテナスクリプトは、できる限りシンプルなものにしておきましょう。シェルスクリプトを使っているものだと考えています。シェバン行にしておく必要があります。テストを確認してください。されたパッケージが完全に削除されたことを確認してください。メンテナスクリプト中で直接/間接を問わず作成されたファイルを削除する必要があるということです。は素晴らしいツールですが、しばしば適当に扱われています。ページに記載されています。使うのを決めた時、あなたが読むべきものです。ここではベストプラクティスを記述しています。使い方についての一般的な考慮すべき事柄を含んでいます。現れて以来、広く乱用され続けています。ディストリビューションに寄せられました。パッケージメンテナはネイティブの英語話者ではありません。正しいフレーズのテンプレートを書くのは彼らにとっては容易ではありません。(むしろ乱用してください)。テンプレートを査読してもらいましょう。それ自体にすら対して、悪い印象を与えます。可能な限り技術的なジャーゴンを避けましょう。いくつかの用語があなたにとっては普通に聞こえても、他の人には理解不可能かもしれません。その場合には、冗長さとシンプルさのバランスを取るようにしましょう。ベースのテンプレートを使ってください。取っ掛かりとして良いでしょう)。いう名の通知システムを使って翻訳作業者にコンタクトを取ってください。ほとんどのアクティブな翻訳作業者たちはとても反応が良く、変更を加えたテンプレートに対応するための作業をしてくれ、あなたが追加でアップロードする必要を減らしてくれます。Last-translator).翻訳作業者に締切りを伝えるのは常にお勧めです。それによって、彼らは作業を調整できます。日未満の猶予は不合理であると考えられています。短い猶予期間は強すぎるプレッシャーを翻訳チームに与えるので、非常に些細な変更点に対してのみに留めるべきです。