GitHub、全組織向けにイシューフィールドをパブリックプレビューへ提供開始
本文の状態
日本語全文を表示中
詳細モードで約3分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
GitHub Changelog
GitHub が全組織および GitHub Enterprise Cloud のデータ居住地域対応環境において、優先度や工数などの型付きメタデータを定義する「イシューフィールド」機能をパブリックプレビューとして利用可能にした。これにより、組織レベルで設定したフィールドがすべてのリポジトリのイシューに自動的に表示され、検索やフィルタリングが可能になる。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
Issue fields は現在、github.com およびデータ所在地を指定可能な GitHub Enterprise Cloud 上のすべての GitHub オrganization でパブリックプレビューとして利用可能です。組織レベルで優先度 (Priority)、工数 (Effort) または任意のカスタムフィールドといった型付きメタデータを定義すると、それが自動的にすべてのリポジトリのすべてのイシューに表示されます。
フィールドは 4 つのタイプ（シングルセレクト、テキスト、数値、日付）をサポートし、特定のイシュータイプにピン留めすることもでき、プラットフォーム全体で動作します。フィールド値によるイシューの検索やフィルタリング、プロジェクトビューでの列としてのフィールド追加、タイムライン上の変更追跡、REST および GraphQL API を介した自動化、または Webhook イベントによる自動化が可能です。
3 月の初期プレビュー以降、1,000 以上の組織が Issue fields を採用しており、その中には GitHub 上で最も大規模な企業やオープンソースプロジェクトも含まれています。チームは作成ワークフローにフィールドを組み込み、ボット、GitHub Actions、および統合ツールを使用して、手動での労力なしにフィールド値の一貫性を保っています。
初期採用者から寄せられた主なテーマは以下の通りです：
- 数百のリポジトリにわたる優先度と工数の追跡を手動で同期することなく、構造化され照会可能なメタデータへとスプレッディングなラベルシステムを置き換えること。
- 自動化が構築できる一貫したスキーマを提供すること。
- チームからはこれをイシューとプロジェクトの間の欠落していたリンクであると表現されています。
これらの利用状況に基づき、いくつかの改善を実施し、フィードバックに基づいて継続的に改良を進めていきます：
パブリックリポジトリの可視性制御：組織は非メンバーに対してどのフィールドを可視化するかを決定できます。
REST API パラリティ：既存の GraphQL サポートに合わせるため、REST API を介してイシューを作成する際にフィールド値を設定できるようになりました。
マイグレーションツール：ラベルまたはプロジェクトフィールドから値を一括コピーするための Copilot スキルです。
すべての組織には、すぐに使用できる 4 つのデフォルトフィールドが自動的に付与されます。組織管理者は、設定 > プランニング > イシューフィールド からフィールドのカスタマイズや新規追加、各イシュータイプに表示するフィールドの構成を行うことができます。
詳細については、イシューフィールドのドキュメントをご覧ください。フィードバックはコミュニティディスカッションで共有してください。それが次回の開発に直接反映されます。
「Issue fields are now in public preview for all organizations」という投稿は、最初に The GitHub Blog で掲載されました。
原文を表示
Issue fields are now available in public preview to all GitHub organizations on github.com and GitHub Enterprise Cloud with data residency. When you define typed metadata like Priority, Effort, or any custom field at the org level, and it automatically shows up on every issue, in every repository.
Fields support four types (i.e., single select, text, number, and date), can be pinned to specific issue types, and work across the platform. You can search and filter issues by field value, add fields as columns in project views, track changes in the timeline, and automate via REST and GraphQL APIs or webhook events.
Since the initial preview in March, over 1,000 organizations have adopted issue fields, including some of the largest enterprises and open source projects on GitHub. Teams are building fields into their creation workflows and using bots, GitHub Actions, and integrations to keep field values consistent without manual effort.
The most common themes from early adopters include:
Replacing sprawling label systems with structured, queryable metadata unifying priority and effort tracking across hundreds of repositories without manual syncing.
Giving automation a consistent schema to build on.
Teams describe it as the missing link between issues and projects.
Based on that usage, we shipped several improvements and will continue iterating based on feedback:
Public repository visibility controls: Orgs can decide which fields are visible to nonmembers.
REST API parity: Set field values when creating issues via the REST API, matching existing GraphQL support.
Migration tool: A Copilot skill that bulk copies values from labels or project fields.
Every organization automatically gets four default fields that work out of the box. Organization admins can customize fields, add new ones, and configure which fields appear on each issue type from Settings > Planning > Issue fields.
To learn more, see the issue fields documentation. Share feedback in the community discussion—it directly shapes what we build next.
The post Issue fields are now in public preview for all organizations appeared first on The GitHub Blog.
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み