Pods: GitHubラベル

〜ラベルとして「NeedsChangelog」を使用できる可能性があります。 私はマージプロセスの一部として変更ログの更新を行っており、その短命のラベルを使用していません。〜
終わり

歯の細かい櫛を使う時間がありませんでしたが、最初のスキムですぐにギラギラするものは何も見られません。 確かなパスでいくつかの調整、省略、削除を見つけるかもしれませんが、私の本能は、これが提案されている現在のラベルシステムを大幅に改善することになるということです。

「パッチ」は、冗長に思えるので、ワークフローで使用したことのないものです。 PRの場合は、パッチです。 しかし、 @ sc0ttkclarkは伝統的にそのラベルを使用していたので、彼にとってワークフローの価値があるかもしれません。

〜 Component: Multi-siteは良い追加であり、REST APIのような別の領域であり、フィルタリングの目的でタグ付けを開始するのに役立つテンプレートです。〜

終わり

焦点：下位互換性
焦点：互換性/非推奨
焦点：互換性

これらの3つについては、おそらく洗練されています。

Focus: Backward Compatibility
Focus: Deprecation
Focus: Third Party Compatibility

編集：これは行われます

これまでのところ、その小さなこと以外に、私はすべてこれに取り組んでいます。 分類ははるかに優れており、2.7.7でも使用したいと思います。

まず、 @ jimtrueと賛成を得たいと思います。

DiscussionとTeam Discussionの違いは何ですか？ それらをNeeds: Developer Feedback置き換えることはできますか？

Integrationとは何ですか？

これが私の2番目のパスです。 いくつかの新しい追加/変更。 使用されていない場合、先頭に質問マークが付いているものは削除される可能性があります。

Closed: Could not reproduce
Closed: Duplicate
Closed: Invalid
Closed: Out of scope
Closed: Won't Fix

Component: CSS
Component: docs.pods.io
Component: DFV
Component: Front-end Forms
Component: Multisite
Component: Pods Templates/Magic Tags
Component: REST API
Component: support.pods.io
Component: UI
Component: Unit Testing
Component: WP Admin

Focus: Accessibility
Focus: Backward Compatibility
Focus: Deprecation
Focus: Third-Party Compatibility
Focus: I18n
? Focus: Integration
Focus: Performance

? Keyword: Discussion
Keyword: Focus
Keyword: Forums
Keyword: Friends of Pods Priority
Keyword: Good First Issue
Keyword: Has Bounty
? Keyword: Patch: Manually Merged
? Keyword: Patch
Keyword: Plugin Material
Keyword: Puntable
Keyword: Release
Keyword: Support
? Keyword: Team Discussion
Keyword: Tools
Keyword: VIP

Needs: Developer Feedback
Needs: Research
Needs: Tasklist
Needs: Test(s)
Needs: User Feedback
Needs: Verification/Reproduction
Needs: Votes

Priority: Blocker

Type: Bug
Type: Code Standards
Type: Inline Documentation
Type: Enhancement
Type: Feature
Type: Refactor
? Type: Regression

Status: Fixed / Needs Testing
Status: Help Wanted
Status: Hold
Status: In progress
Status: Pulled for Review
Status: Ready for merge
Status: Ready for review
Status: Researched
Status: Unit Tested
Status: Verified/Reproduced

ディスカッションとチームディスカッションの違いは何ですか？ それらをNeeds：Developer Feedbackに置き換えることはできますか？

それほど多くはありませんが、ディスカッションは世界に開かれ、チームディスカッションは内部で行われます。 それほどきめ細かく、単一の一般的なディスカッションラベルで十分である必要はないと思います（重複はおそらく意図的ではありませんでした）。 開発フィードバックは通常、ステータスとして使用されます。通常は、ユーザーフィードバックを保持していて、そのフィードバックを受け取ったチケットです。

統合とは何ですか？

主に他のプラグイン、ライブラリ、テーマなどとの統合を含む機能リクエスト。既存の統合のバグはこの傘下に入ると思いますが、統合が完了すると、「互換性」としてより適切になることがよくあります。 （したがって、統合はおそらくタイプですが、Focusではこれまでのように意味があります）

「Needs：」セクションの方が良いかどうかはわかりません...「Status：」の一部としてのアイデアが気に入ったのは、それがよく使われる方法だと思うからです。

編集：これはすべて対処されました

〜次のキーワードは実際にはタイプである可能性があると思います：リリース、サポート、およびツール。〜

〜それらは他の誰にもよく説明されていないタイプのチケットのようです。〜

終わり

また、スクロールするために、新しいバージョンを投稿するのではなく、最初のメッセージのリストを最新の状態に保つ必要があるのではないかと思います。

終わり。

私はこれのアイデアが好きです：

ニーズ：開発者のフィードバック
ニーズ：研究
ニーズ：タスクリスト
ニーズ：テスト
ニーズ：ユーザーフィードバック
ニーズ：検証/複製
ニーズ：投票

しかし、「ユーザーフィードバック」と「検証/複製」は、上記の@pglewisのように、実際には「ステータス/ワークフロー」です。または、これらをステータス：ブロッカーとして配置することもできます。ニーズはブロッカーの「理由」です。

ステータスワークフローは、理想的にはプロジェクトのスイムレーンまで薄くする必要があります。 このレーベルのリストを見て、こんなにたくさんあるとは思いもしませんでしたが、皆さんがもっとたくさん作ったと思います。

GitHubをサポートとドキュメントの更新に使用する予定がない限り、 support.pods.ioとdocs.pods.ioをここに含めることはできません（これら2つのWebサイトのリポジトリがあります）。 これを行う場合は（私はすべてです）、Docs：とSupport：のプレフィックスを追加し、サポートとドキュメント用にこのリポジトリのGitHubに2つのプロジェクトを作成します。 サポートの問題が実際のコード拡張/機能またはバグ修正に変わることがあるため、同じインターフェイスを使用することは理にかなっています。 確かにもっとありますが、サポートの問題やドキュメントの更新に必要なものを正確に入手できるようにします。

私はこれを調べました、そして私は以下の変更を見たいです：

• タイプ： SupportとDocs Updateを追加します（ SupportからKeyword Supportを削除します）
• コンポーネント：我々は必要ありませんsupport.pods.i Oまたはdoc.pods.ioでComponent 。 これらの2つのレポには独自のプロジェクトがあります。 コンポーネントは、PodsCoreの重点分野に完全に対応している必要があります。
• 優先度： FocusをキーワードからPriorityます。 Blockerは、 Needsから来ているはずの理由がわかっている限り、問題ありません。

したがって、これに正しく従えば、すべてに次のようになります。
タイプ：チケットのタイプを定義します。
ステータス：ワークフローのどこにあるかを定義します。 ユーザーフィードバックまたは検証/複製が必要な場合に、ステータスを「ブロック」または「ToDo」または「保留」にする方法についてはほとんど議論されていません。 ニーズが投票である機能/拡張リクエストのステータスがどうなるかわからない。 たぶん、それらは典型的なかんばんボードと同じフォーマットに従い、アクティブに動作するまでステータスはBackLogです。 ブロッカーは、ニーズが処理されるまで機能できないことを示しています。
コンポーネント：機能/拡張/バグのポッドコアの領域を決定します
キーワードとフォーカスは、追加の説明のためだけですか？

WaffleBotを削除したので、これらのステータスは自動的に追加されなくなりました。

ブロッカーは、ニーズが処理されるまで機能できないことを示しています。

これは、同じ意図でラベルを使用していない場合です。 私は常にBlocker（そしてScottもそうだと思います）をリリース（またはおそらく別のチケット）をブロックする問題に使用しており、実行する必要があります。 パントすることはできません。

私のワークフローには、「ブロッカー」を介して何かを保持しているものとしてマークする理由はありません...現在のステータスラベルはそれを意味するはずです。 「NeedUserFeedback」と「Blocker」は必要ありません。最初のものはすでにブロックしていることとその理由を教えてくれます。

私の投票では、それをそのように使用し、「優先度：*」の下に維持します。これは私にとって完璧な説明です。

〜「フォーカス」もキーワードから優先に移すべきだと思います。〜キーワードを残す

私はこれのアイデアが好きです：

ニーズ：開発者のフィードバック
ニーズ：研究
ニーズ：タスクリスト
ニーズ：テスト
ニーズ：ユーザーフィードバック
ニーズ：検証/複製
ニーズ：投票

これらは主に私にとってのチケットステータスなので、今のところそこに保持することを提案します。 長さが問題になる場合は、一部を省略できます（「ステータス：Dev FBが必要」、「ステータス：検証/再現が必要」）。

「NeedsTasklist」は行けると思います。 ラベルを正当化するのに十分なことは起こらないと思います。 使用したことがあるかどうかはわかりませんが、使用することはめったにありません。 おそらく「NeedsTests」についても同じです。 残りのものはすべて「ステータス：*」の下で私にぴったりです。

また、リストは私にとってうまく形作られています、私たちはおそらく配色について議論する必要があります。

「NeedsTasklist」とともにステータスから削除できる可能性のあるものがさらにいくつかあります。

• 〜「Pulledfor Review」は、おそらく「Ready forReview」の意図しない複製です〜そのままにしておきます
• 「ユニットテスト済み」はステータスではなく（少なくともまだ）、その他のものです...おそらくキーワードに移動しましたか？

そのため、ステータスリストは私には見栄えがします。

「PulledforReview」は、おそらく「ReadyforReview」の意図しない複製です。

同意しない。 PRを作成する場合は、準備ができたら、[レビューの準備完了]を追加します。 しかし、あなたは後でそのレビューをする時間がないかもしれません-しかしそれまでに、スコットはあなたがレビューを始めたかどうか確信がありません。 つまり、Ready forReviewとPulledforReviewを追加するのは2つの異なるグループです。

おそらく「NeedsTests」についても同じです。

より多くのコードカバレッジが必要なため（私はまだこの領域を個人的に詳しく調べていませんが）、このラベルは「修正は良好ですが、ユニットテストがエッジをカバーする/検証することを望んでいます」と言うためのものである可能性があります特定のバグが修正されたため、リグレッションは発生しません。」

「フォーカス」もキーワードから優先に移すべきだと思います。

優先順位は一般的に-低、中、高、クリティカル、ブロッカー-フォーカスに対して（少なくとも私の心の中では）異なるセマンティクスを持っています。 Keyword: Focusラベルは、問題がどのリリースに焦点を当てているかを示すマイルストーンがない限り、それ自体には関連性がありません。 優先順位は文脈に依存しませんが、プロジェクト全体に適用される限りにおいてです。 他の優先順位を追加することは必ずしも良い考えではないと思いますが、同様に、フォーカスが優先順位であるとは思いません。 たぶん私たちが言おうとしているのは、「このチケットはマイルストーンのハイライトです。次のリリースで大声で叫ぶのに最適です」ということです。そうであれば、Focusとは別の言葉で意図を示す方がよいかもしれません。

ブロッカーは、ニーズが処理されるまで機能できないことを示しています。

ここでPhilに同意します-このラベルが付いているIssueが_release_のブロッカーであることを意味すると理解しました。 Needs: *は同じことを示していますが、ジムの説明はStatus: Is Blockedラベルなどに適しているかもしれません。

ところで、ここで暫定リストを削除しても大丈夫ですか：＃5016（コメント）？

@pglewis先に進んで、<details>...</details>に非表示にします）。

support.pods.ioとdocs.pods.ioはここにあるべきではありません

既存の「DocsImprove」タグ（vs Docs：inline）に関する不確実性のために、それらを追加しました。他の場所で処理されている場合は削除できます。

ドキュメントの改善は、「ドキュメント：インライン」「ドキュメント：例」「ドキュメント：ツールチップ」などのように記述した方がよい場合があります。 GitHubでドキュメント（つまり、docs.pods.io Webサイトに書かれたドキュメント）ワークフローを処理していない限り、ここでその理由はありません。 コード内のドキュメントの改善とは、コード内のドキュメント、コード内でのドキュメント、または解析されてWordPress.orgプラグインリポジトリにプッシュされるreadmeのようなものを意味します。

Status: Is Blockedは非常に有益なので気に入っていますが、そのような性質のことを行う場合は、Needs：*も必要です。

私が言ったように、すべてがTypeとStatus取得します。 GitHubで完全なアジャイルプロジェクト管理を行うまでは、優先順位をそこで定義する必要はなく、実際には「ストーリー」を完成させるために必要な作業単位によってより適切に表されます。 私たちは常にFocusを使用して、次のメンテナンスリリースで焦点を当てる必要がある数百の問題の項目を区別してきました。

私の唯一の考えは、UI / CSSラベルに関するものです。これは、私が最も扱っているラベルです。CSSをコンポーネントとして削除するだけで、UIのみに依存することが最も理にかなっているようです。 皆さんがそこに何か考えを持っているかどうかはわかりませんが、CSSは結果であり、修正が必要な具体的なものではありません...それが理にかなっている場合。 UIは、取り組むべき、または改善すべき具体的なものであり、cssは、結果またはその修正方法です。 そうでなければ私はそれが好きです👍

私の唯一の考えは、UI / CSSラベルに関するものです。これは、私が最も扱っているラベルです。CSSをコンポーネントとして削除するだけで、UIのみに依存することが最も理にかなっているようです。 皆さんがそこに何か考えを持っているかどうかはわかりませんが、CSSは結果であり、修正が必要な具体的なものではありません...それが理にかなっている場合。 UIは、取り組むべき、または改善すべき具体的なものであり、cssは、結果またはその修正方法です。

ええ、そこで行われるべき洗練があります。 あなたがその方向で頼りになる人だったので、私は主にあなたやジョリーがフィルタリングするためのバットシグナルとしてCSSラベルを使用しました。

今のところ提案されているようにCSSとUIを残すことに投票しますが、フェーズIの後も確実に改良を続けることができます。

RE：テストが必要

より多くのコードカバレッジが必要なため（私はまだこの領域を個人的に詳しく調べていませんが）、このラベルは「修正は良好ですが、ユニットテストがエッジをカバーする/検証することを望んでいます」と言うためのものである可能性があります特定のバグが修正されたため、リグレッションは発生しません。」

現実には、メンテナンスの修正に遅れずについていき、リリースブランチで作業する必要があり、新しいテストを作成する際の障壁は、単純なものであってもかなり高くなります。 ラベルをそこに残すことはできますが、より多くのリファクタリングが行われるか、実際の単体テストを導入するか、それに専念するためのより多くのリソースが得られるまで、あまり使用されない可能性があります。

「タイプ：テスト」は良い追加ですが、現在追加されているテストは、おそらく独自の問題/ PRペアとして最適です。

私はステータスが好きです：それは非常に有益なのでブロックされていますが、あなたがその性質の何かをするなら、それはニーズ：*も必要とします

そのままにしておいても大丈夫ですが、私は主にステータスを追跡しているので、「ブロックされている」ものをステータスとしてマークする必要はありませんでした。 私が出くわすその方向が漠然としているものはすべて、「保持」によってより適切にカバーされます。

そして、それが何かを明確にするのに役立つ場合、これは私が平均的なバグで使用する典型的なワークフローです：

• トリアージ：無効、サポート、機能/拡張機能を除外します。 タイプをバグに設定
• 通常、ステータスはすぐに「検証/再現が必要」になります
• ライフスパンを通じて、「ユーザーフィードバックが必要」と「開発者フィードバックが必要」の間を行き来する可能性があります
• 検証済み/再現済み
• 調査が必要：それを実現する方法がわかったので、その理由を見つけて理解します
• 調査済み：これを使用しているのはおそらく私だけです。 ある時点で詳細が行われたことを示しており、おそらく内部の詳細が頭の中に保存されています
• 修正済み/テストが必要

同意しない。 PRを作成する場合は、準備ができたら、[レビューの準備完了]を追加します。 しかし、あなたは後でそのレビューをする時間がないかもしれません-しかしそれまでに、スコットはあなたがレビューを始めたかどうか確信がありません。 つまり、Ready forReviewとPulledforReviewを追加するのは2つの異なるグループです。

そのような場合、HoldラベルはPulled forReviewよりも歴史的に優れていると思います。

参考までに、私は過去に、リリースをブロックする問題を示すためにブロッカーを使用しました。

「パッチ」を削除できます。GitHubのUXがPRと問題の間でより混乱しているときに、主に変更ログの内容に戻るために、パッチを使用して「リリース」ビューを表示する方が簡単でした。 必要ありません。

元の問題の説明のリストは、私たち全員が議論した変更で最新のものですか？

元の問題の説明のリストは、私たち全員が議論した変更で最新のものですか？

おそらく完全ではありませんが、必要に応じて自由に改良してください。 完全に親指を立てて、更新されていないと判断したものをすべて確認したら、説明します。

ここで決定するものは何でも、 https：//github.com/dwyl/labelsなどのツールを使用して他のすべてのポッドリポジトリに適用して同期する必要があります。

「回帰」をタイプからキーワードに移動します。 バグは依然として回帰問題のタイプです。

これは現在ほとんど実装されています。 今のところ「キーワード」の下に置いてあるいくつかの雑多なこと。

この時点で解決する主なものは色です。

？クローズ：無効

少なくともこれを保持することをお勧めします。おそらく修正されません。 これらは、他のバグトラッカーのかなり標準的な解決策です。

この時点で解決する主なものは色です。

この時点で色は二次的なものです。ラベルを実装し、後で配色を決定します。

少なくともこれを[無効]にしておくことをお勧めします。おそらく修正されません。 これらは、他のバグトラッカーのかなり標準的な解決策です。

無効を追加します。まだ持っていないので、リマインダーとしてマークしました。

「Won'tFix」は私がただ口調が嫌いなものの1つです。 それに加えて、私の態度は、「修正しない」よりも何かを修正しないというより具体的な理由のあるラベルを用意する必要があるということです。

この時点で色は二次的なものです。ラベルを実装し、後で配色を決定します。

ラベルはほとんど実装されています。

「Type：GitHub」などが必要ですか？ この問題にはタイプがありません。

Type: Project ？

「修正しない」の代わりに「そのままにする」などを使用した場合はどうなりますか？

「修正しない」の代わりに「そのままにする」などを使用した場合はどうなりますか？

それは珍しい状況なので、私たちはそのようなものを必要とせずにこれほど長くそれを作りました。 特定の例が現れるまで、そこに何かを追加するのを待つことに投票します。

また、私はいくつかのグループのためにいくつかの任意の色の決定をしました。 そこには何も石が置かれていません。

この時点でこの問題を解決し、Slackを介してさらに改良を加えることができると思います。

What if instead of "Won't Fix" we used "Leave as is" or something like that?

それは珍しい状況なので、私たちはそのようなものを必要とせずにこれほど長くそれを作りました。 特定の例が現れるまで、そこに何かを追加するのを待つことに投票します。

同意します。 WordPressコアが行うすべてを複製する必要はありません

同意します。 WordPressコアが行うすべてを複製する必要はありません

これは、GHで新しいリポジトリを設定するときのデフォルトのラベルの1つでもあります。デフォルトのラベルがあるhttps://github.com/GaryJones/daterange/labelsを参照して

I agree. Not everything that WordPress core does needs to be duplicated

これは、GHで新しいリポジトリを設定するときのデフォルトのラベルの1つでもあります。デフォルトのラベルがあるhttps://github.com/GaryJones/daterange/labelsを参照して

いつGitHubのデフォルトになったのかは覚えていませんが、ボランティアの寄稿者からのチケットに付けるのはいつもひどいタグでした。 そのタグを使用したGitHubでの問題はほとんど見られませんが、WordPressの世界では、修正されないチケットのほとんどが別の問題でカバーされているか、修正を正当化するためにさらに情報が必要であるか、誰も文句を言わないことを望んでいます（多くの場合） 。

私は嫌いに固執します。 「修正しない」についての私の直接の質問は、「なぜ私たちは何かを修正することを拒否するのですか？」です。 そして、誰かがチケットでそれに対する良い簡潔な答えを私にくれたら、私は「修正しない」ではなく、ラベルが読むべきものであると言うでしょう。

とにかくOut of Scopeの方が良い答えだと思います。 Wo n't Fixは、問題を開いた人に「何も」を意味し、提供するだけです。

多分それは方向に進むかもしれません-「解決策」を自由に提出してください、しかしチームはそれをするのに十分なリソースを持っていません：D多分誰かがそれの短い略語のアイデアを持っています^^

ユースケースは、一部の機能のバグまたはCS違反である可能性があります。つまり、大規模に書き直され、とにかく次のバージョンでリリースされます。

ただし、自由に省略してください。