Merge pull request #44672 from github/repo-sync

Repo sync

Author: docs-bot

content/issues/planning-and-tracking-with-projects/understanding-fields/about-issue-fields.md

@@ -13,8 +13,9 @@ category:
 
 Issue fields are organization-level fields that provide consistent, typed metadata across all repositories. Unlike project custom fields, issue fields are defined once at the organization level and are available on every issue and in every project across the organization. For more information on creating and managing issue fields, see [AUTOTITLE](/issues/tracking-your-work-with-issues/using-issues/managing-issue-fields-in-your-organization).
 
-> [!NOTE]
-> Issue fields are currently only supported in private projects. Issue fields are not available in public projects.
+## Issue fields in public and internal projects
+
+Only fields with **Public** visibility appear in public and internal projects. Organization-only fields are hidden. For details on configuring field visibility and how visibility changes affect projects, see [AUTOTITLE](/issues/tracking-your-work-with-issues/using-issues/managing-issue-fields-in-your-organization#setting-field-visibility).
 
 ## Adding an issue field to a project
 

content/issues/tracking-your-work-with-issues/using-issues/adding-and-managing-issue-fields.md

@@ -14,6 +14,9 @@ category:
 
 Issue fields appear in the right-hand sidebar of issues, alongside system fields like assignees, labels, and type. You can set values when creating or editing an issue. When you select an issue type while creating an issue, any fields pinned to that type automatically appear in the sidebar.
 
+> [!NOTE]
+> Issue fields are currently available on issues only. Pull requests do not support issue fields.
+
 ## Setting a field value
 
 1. Navigate to the issue you want to update.
@@ -26,6 +29,9 @@ Issue fields appear in the right-hand sidebar of issues, alongside system fields
    * For **date** fields, use the date picker to select a date, or type the date directly.
 1. Changes are saved automatically.
 
+> [!NOTE]
+> Issue fields cannot currently be pre-filled via URL query parameters or set through issue templates. To set field values, use the issue sidebar, projects, the API, or {% data variables.product.prodname_actions %}.
+
 ## Editing a field value
 
 1. Navigate to the issue.
@@ -87,3 +93,20 @@ Issue fields have full REST and GraphQL API support. You can automate field mana
 * **Managing fields**: Create, update, and delete organization-level fields. See the [Organization issue fields REST API](/rest/orgs/issue-fields).
 * **Using fields**: Get, set, and clear field values on individual issues. See the [Issue field values REST API](/rest/issues/issue-field-values).
 * **GraphQL**: Issue field types and mutations are also available via GraphQL. See the [`IssueFields` union](/graphql/reference/issues#union-issuefields), [issue field objects](/graphql/reference/issues#object-issuefieldtext) (such as `IssueFieldText`, `IssueFieldSingleSelect`, `IssueFieldNumber`, and `IssueFieldDate`), and [mutations](/graphql/reference/issues#mutation-createissuefield) (such as `createIssueField`, `updateIssueField`, and `setIssueFieldValue`).
+
+## Automating with {% data variables.product.prodname_actions %}
+
+Issue field changes trigger webhook events on the `issues` event. You can use these as workflow triggers:
+
+* `field_added`: fires when a field value is set or updated.
+* `field_removed`: fires when a field value is cleared.
+
+For example, to run a workflow whenever a field value changes:
+
+```yaml
+on:
+  issues:
+    types: [field_added, field_removed]
+```
+
+The event payload includes the field name, type, value, and previous value. For more information, see [AUTOTITLE](/actions/reference/workflows-and-actions/events-that-trigger-workflows#issues).

content/issues/tracking-your-work-with-issues/using-issues/managing-issue-fields-in-your-organization.md

@@ -34,8 +34,20 @@ When issue fields are enabled for your organization, four default fields are cre
 * **Start date** (date)
 * **Target date** (date)
 
+These default fields are pinned to issue types as follows:
+
+| Field | No type | Bug | Task | Feature |
+|-------|:-------:|:---:|:----:|:-------:|
+| Priority | {% octicon "check" aria-label="Pinned" %} | {% octicon "check" aria-label="Pinned" %} | {% octicon "check" aria-label="Pinned" %} | {% octicon "check" aria-label="Pinned" %} |
+| Effort | {% octicon "x" aria-label="Not pinned" %} | {% octicon "check" aria-label="Pinned" %} | {% octicon "check" aria-label="Pinned" %} | {% octicon "check" aria-label="Pinned" %} |
+| Start date | {% octicon "x" aria-label="Not pinned" %} | {% octicon "x" aria-label="Not pinned" %} | {% octicon "x" aria-label="Not pinned" %} | {% octicon "check" aria-label="Pinned" %} |
+| Target date | {% octicon "x" aria-label="Not pinned" %} | {% octicon "x" aria-label="Not pinned" %} | {% octicon "x" aria-label="Not pinned" %} | {% octicon "check" aria-label="Pinned" %} |
+
 These default fields are fully customizable. You can edit their names, descriptions, and options, or delete them if they don't fit your workflow.
 
+> [!TIP]
+> You can rename options, change their colors, reorder them, or add new values to match your team's workflow. For example, you could change Effort options to T-shirt sizes (XS, S, M, L, XL).
+
 ## Creating an issue field
 
 {% data reusables.profile.access_org %}
@@ -73,6 +85,9 @@ When you delete an issue field, all values set on issues for that field are perm
 1. To the right of the field you want to delete, click {% octicon "kebab-horizontal" aria-label="open field options" %}.
 1. Click **Delete** and confirm the deletion.
 
+> [!TIP]
+> If you don't want to use issue fields, you can delete all default fields from your org settings. This removes them from all issues in your organization. You can re-create fields at any time.
+
 ## Reordering issue fields
 
 The order of pinned fields is managed per issue type. The field order determines how fields appear in the issue sidebar and the issue creation modal.
@@ -100,6 +115,8 @@ Pinned fields automatically appear in the issue sidebar based on the selected is
 > [!NOTE]
 > Fields must be pinned to at least one issue type, or to "Issues without a type", to appear in the issue sidebar. Fields that are not pinned to any type are only accessible via the **Add field** button or in projects.
 
+If a field is not appearing on your issues, check that it is pinned to the relevant issue type or to "Issues without a type". Fields that are not pinned and have no value set are hidden from the issue sidebar.
+
 ## Setting field visibility
 
 For organizations with public repositories, you can control whether each issue field is visible to everyone or only to organization members and collaborators.
@@ -118,7 +135,22 @@ By default, all new and existing fields are set to "Organization only". Visibili
 
 ## Issue fields and projects
 
-Issue fields are available in any project across your organization. For details on adding, removing, and editing issue fields in projects, see [AUTOTITLE](/issues/tracking-your-work-with-issues/using-issues/adding-and-managing-issue-fields#using-issue-fields-in-projects).
+Issue fields are available in any project across your organization, including public and internal projects. For details on adding, removing, and editing issue fields in projects, see [AUTOTITLE](/issues/planning-and-tracking-with-projects/understanding-fields/about-issue-fields).
+
+### Visibility in public and internal projects
+
+Only fields with **Public** visibility are available in public and internal projects. Fields set to **Organization only** are not displayed. When adding fields to a public project, only public-visibility fields appear in the add-field dialog.
+
+If a field's visibility is changed from "Public" to "Organization only" while in use in a public project, the field is automatically removed from the project. To restore it, change the field's visibility back to "Public."
+
+### Migrating from project fields to issue fields
+
+If you already use project-level custom fields for metadata like priority or effort, you can adopt issue fields to centralize those values at the issue level.
+
+* Issue fields are the source of truth. The value lives on the issue and is consistent across all projects the issue belongs to.
+* Project fields are scoped to a single project. The same issue can have different project field values in different projects.
+* Both can coexist. You do not need to remove project fields immediately, but having both can cause confusion if they track the same concept (for example, two "Priority" fields).
+* To migrate, create the equivalent issue field, then remove the project-level field from your project views when your team is ready.
 
 ### Field limits in projects
 
@@ -129,6 +161,6 @@ Projects support up to 50 fields in total, and issue fields and system fields co
 | Resource | Limit |
 |----------|-------|
 | Issue fields per organization | 25 |
-| Options per single-select field | 50 |
+| Options per single-select field | 100 |
 | Pinned fields per issue type | 10 |
 | Total fields in a project (including issue fields and system fields) | 50 |