投稿とコメントのガイドライン
このガイドラインは、最初に make/core で提案されました。質問やフィードバックがある場合は、Slack に参加して #core で質問してください。
はじめに
Make WordPress Core ブログ (make/core) は、WordPress コアチームの公式ブログです。何千人もの人に読まれていますが、その多くはコアの複雑なしくみを知らなかったり、コアの開発プロセスを理解していないかもしれません。
ほとんどの make/core の投稿は、2つの目的のうちどちらかを果たす必要があります。
- 開発者コミュニティからのフィードバック (テストを含む) を受ける
- 開発者が変更点を把握し、それに応じた計画を立てられるようにする
このガイドラインは、開発者コミュニティ内のできるだけ大勢のメンバーに有益なものとなるように、未経験者を想定して書かれています。
投稿
記事を書くタイミング
make/core に投稿することは、コミッター、コンポーネントメンテナー、その他のコア貢献者にとって、頻繁に行われるべきです。スケジュールに沿って書かれるべき投稿の種類はたくさんあります。
- API の変更。 make/core で告知すべき API 変更の例としては、新しいフィルターやアクション、フックの順番の変更、クエリーの大幅な強化 (ブーン・ゴルジュのルール)、フックのパラメータの目的の変更、新しい汎用ヘルパー関数、その他リリースにおける重大な変更などがあります。これらの投稿は、開発者が今後の変更点を確実に把握できるように、ベータ期間の最初の1週間以内に make/core で公開されるべきです。関連する変更点をひとつの投稿にまとめることは、投稿が長くなり過ぎない限り、認められます。たとえば、「WordPress 4.2におけるカスタマイザーの変更点」という投稿は、各コミットについての個別の変更点ではなく、1つの投稿でかまいません。もし疑問があれば、提案した投稿について話し合うために、毎週の開発チャットを使用してください。
- ミーティングのお知らせ。 定期的な 開発チャットのミーティングは告知する必要はありませんが、要約の投稿は定期的にリリースを追いかけていない開発者にとって役に立ちます。その他のミーティングでは、make/core にミーティングの告知をする必要がありますが、毎週告知をする必要はありません。
- ミーティングのメモ。 定期的または一度限りのミーティングを開催していますか ? ミーティングのメモを make/core に投稿し、参加できなかった人が簡単にフィードバックできるようにしましょう。開発チャットでは、参加できなかった人のために、ほとんどの場合は要約記事を添付しています。コンポーネントチャットやプラグインチャットも、ミーティング後に要約記事を投稿してください。
- 機能プラグインに関する記事。 あなたの機能プラグインのアイデアを世界に紹介するには、毎週の開発チャットか、不定期に開催される機能プラグインチャットのいずれかが最適です。一度提案されたら、アイデアの段階によっては、make/core に投稿することも良いでしょう。リリースリードから依頼された場合、マージの提案も make/core に投稿されるべきです。
make/core でのフィードバックは、Trac チケットでのフィードバックよりも常に大きいこと覚えておいてください。変更のアナウンスや投稿を早い段階で頻繁に行うことは、コミュニティ全体にとって有益なことです。
査読
初めての投稿でも100万回目の投稿でも、投稿を公開する前にコミッターに校正を依頼することが強く推奨されます。査読 (コードレビューのようなもの) は、あなたの言葉が明確で意図したとおりに書かれているか確認することに役立ち、また、うまく翻訳されないかもしれないフレーズを特定することに役立ちます。いくつかの投稿 (毎週の要約など) は必ずしも査読を必要としませんが、もしあなたが make/core に投稿するのが初めてなら、お願いしても損はないでしょう。
機能プラグインのマージの提案は、投稿する前に「必ず」リリースリーダー (または指名された人) に読んでもらうべきです。リリース開発者ノートは、公開する前にリリースリーダー (または指名された人) に読んでもらうべきです。
校正者や査読者の貢献を認知する方法については、以下の「適切なクレジット (props) を与える」のセクションを参照してください。
スタイルと内容
make/core ブログはコアチームの公式な声明です。そのため、個人的な感想は記事の本文に書かず、コメントに残してください。さらに、一人称の代名詞は避けるべきです。
同様に、どのグループが発言しているかが明確でない限り、投稿では 「私たち」という言葉は避けるべきです。 たとえば、ミーティングの参加者をリストアップし、要約の投稿で「ミーティングに参加した私たち」が決定を下したり、行動計画に合意したことを記すことです。
ロードマップを提案したり、コメントを求めたりする場合は、タイトルと冒頭の段落の両方で、ドラフトや提案のステータスを強調してください。 これにより、提案のステータスに関する混乱を避けることができます。
make/core を読んでいる人の多くは、英語を第一言語としていません。そのことを念頭に置いて、投稿のフレーズを決めてください。make/core では、スマートではなく、シンプルに書くことが常に好まれます。一般的には、WordPress と同じようなトーンであるべきです (親しみやすい)。
オープンソースにおけるテキストベースのコミュニケーションやグローバルなコラボレーションのためのベストプラクティスについては、WordPress 貢献者トレーニングサイトのページを参照してください。
適切なクレジット (Props) を与える
最終的に投稿が公開されるとき、それは一人の名前で発信されます。しかし、投稿は多くの場合、複数の投稿者の努力によるものであり、それらは評価されるべきです。また、投稿を公開可能な状態にするために誰が協力したかを示すことは、読者に重要な文脈を提供し、議論する際に誰を相手にするのかを理解するために役立ちます。
投稿の一番下に、以下のような脚注を入れてください。
「歴史的背景を提供してくれた @desrosj と @jeffpaul、校正してくれた @chanthaboune と @andreamiddleton に感謝します。」
タグ付けとその他の仕様
以下の投稿の種類ごとに、いくつかの注意点があります。
- コンポーネントに関連した投稿。 ほとんどすべての投稿は、コンポーネントに関連しています。コンポーネントに関連する投稿には、コンポーネント名をタグ付けしてください。複数のコンポーネントを扱う場合は、複数のタグを使用してください。
- API の変更。 すべての API の変更には、関連するリリース番号、コンポーネント名、そして開発者向けの注意事項であることを示す「dev-notes」のタグを付ける必要があります。
- リリースに関するお知らせ。 特定のリリースに関連するすべての投稿 (要約、ミーティングの概要、API の変更、今週のコアなど) には、関連するリリースをタグ付けする必要があります。
- 機能プラグインやその他プロジェクト。 これらのタイプの投稿には、それぞれプロジェクト名で一貫したタグを付ける必要があります。たとえば、「MP6」という管理画面の再設計に取り組んでいるのであれば、関連するすべての投稿に「MP6」のタグを付けましょう。
- ミーティングのお知らせ。 ミーティングについて事前に投稿する場合 (別名、要約メモではない)、読者が自分のローカルタイムで会議が行われる時間を正確に知ることができるように、time ショートコードを使用します。
提案
コア貢献者コミュニティからフィードバックを得て、変更の可能性を評価することを目的としてアイデアを書き上げる場合、書かれていることが提案であり最終決定ではないことを明確にすることが重要です。これを達成するために、提案はタイトルの最初に「提案」という単語を含み、最終決定がまだなされていないことを説明する文章を本文に含めなければなりません。
投稿へのコメント
投稿へのコメントは180日 (約6ヵ月) 後に自動的に閉じられます。コメントを開いたままにしておく必要がある場合は、#keep-comments-open タグを使用できますが、これはコメントを永久に開いたままにするのではなく、特定の期間を念頭に置いて使用する必要があります。
コメント
アイデアに関する議論や批判は、WordPress の長期的な成功のために重要です。これを支持するため、すべての make/core の投稿はコメントがオープンな状態になっています。そのため、他のコメント投稿者や読者の多くが英語を母国語としていないことを理解した上で、コメント投稿者は敬意とプロ意識を持って投稿する必要があります。時には、誤解が生じないように、過剰なコミュニケーションや丁寧な対応をすることも意味があるかもしれません。
失礼なコメントやプロフェッショナルでないコメントは、コアチームの判断で編集されることがあります。
コメントの編集は、少なくとも2名のブログ管理者の承認を得て行うものとします。コメントを編集する場合、表現された意見をできるだけ残すことを意図して、問題のある部分のみを編集します。編集した管理者は、編集の理由と編集した管理者の名前を記した編集者ノートを付けます。さらに編集した管理者は、編集前のコメントのスクリーンショットを残し、必要に応じて make/core のメディアライブラリにアップロードしてください。
コメントは、明らかに適切なモデレーションが行われていないスパムと判断された場合のみ削除されます。
最終更新日: