7.1 Discussions

GitHub Foundations GH-900

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Domains, Scoring, and Candidate Profile 1.3 Official Resources and Hands-On Prep

2 Version Control Fundamentals

2.1 Purpose and Benefits of Version Control 2.2 Git vs GitHub 2.3 Repositories, Commits, and History 2.4 Branches, HEAD, and the Default Branch

3 Working with GitHub

3.1 Accounts, Organizations, and Enterprise Options 3.2 GitHub Flow 3.3 Markdown for Issues and Pull Requests 3.4 GitHub Desktop and GitHub Mobile

4 Repository Structure and Key Files

4.1 Repository Structure and Community Health Files 4.2 Creating Repositories with Templates and Branches 4.3 Adding and Managing Files

5 Repository Insights and Maintenance

5.1 Insights, Stars, Dashboards, and Dependency Insights 5.2 Repository Maintenance and Collaboration Best Practices

6 Issues and Pull Requests

6.1 Issues 6.2 Pull Requests 6.3 Linking PRs, Templates, Filters, and Assignments

7 Discussions, Notifications, and Documentation

7.1 Discussions 7.2 Notifications and Workflow Management 7.3 Gists, Wikis, and GitHub Pages

8 GitHub Actions

8.1 Actions Purpose, Workflows, and Events 8.2 Jobs, Steps, Runners, Secrets, and Reusable Actions

9 GitHub Copilot

9.1 Copilot Suggestions, Agents, Agent Mode, and Multi-Model Support 9.2 Copilot for Individuals, Business, and Enterprise

10 Codespaces and github.dev

10.1 Codespaces, Customization, and Dev Containers 10.2 github.dev vs Codespaces

11 Manage Projects with GitHub

11.1 GitHub Projects and Layout Options 11.2 Configuring Projects, Labels, Milestones, and Workflows 11.3 Saved Replies and Assignees 11.4 Project Insights

12 Account Security and Access

12.1 Two-Factor Authentication and Passkeys 12.2 Access Permissions and Roles 12.3 Enterprise Managed Users and Copilot Policy

13 Privacy, Branch Protection, and Organization Admin

13.1 Privacy, Visibility, and Branch Protection 13.2 Organization Settings, Teams, and Roles

14 Open Source, Sponsors, and InnerSource

14.1 Open Source Benefits and GitHub Sponsors 14.2 How GitHub Supports Open-Source Projects 14.3 InnerSource

15 Marketplace, Discovery, and Collaboration Models

15.1 Following Users and Organizations 15.2 GitHub Marketplace 15.3 Forks, Templates, and Discoverable Repositories

Key Takeaways Explain This Topic AI

GitHub Discussions are the forum for open-ended conversation; GitHub Issues track actionable work that someone can complete, assign, and close.

An administrator must enable Discussions for a repository or organization before anyone with access can create or participate.

Every discussion belongs to a category with a format: open-ended discussion, question and answer (comments can be marked as the answer), announcement (only maintain or admin can start threads), or polls.

People with triage permission can convert an issue into a discussion (comments are preserved), lock a thread, and mark a Q&A comment as the answer; maintainers can pin up to four discussions globally and four per category, or close a discussion that is resolved or no longer useful.

Repository discussions cover one repo; organization discussions span many repos and live in a chosen source repository whose permissions control who can moderate.

Last updated: August 2026

Why GH-900 splits discussions from issues and pull requests

Domain 3 of GitHub Foundations (GH-900)— Collaborate using GitHub , 10–15% of the exam—opens with a compound skill: describe how to use issues, pull requests, and discussions . Chapter 6 already owned issues and pull requests. This section owns discussions . The product distinction is the exam's favorite Domain 3 trap: an issue is a work record you intend to finish; a discussion is a conversation that often has no clear owner and no required deliverable .

GitHub's About discussions page is the product source. GitHub Discussions lets maintainers, contributors, and visitors gather in one place—without a third-party forum—to share announcements, plan with community input, ask and answer questions (and mark them answered ), and gauge opinion with polls . You use repository discussions for topics that belong to one repository and organization discussions for conversations that span multiple repositories.

If a scenario is "track a crash until it is fixed," the answer is still an issue. If it is "propose a merge," the answer is a pull request. If it is "should we rewrite the CLI?" or "how do people use this library?" with nobody assigned, the answer is a discussion.

Open-ended conversation versus actionable work

GitHub's community-conversation guidance is the decision table GH-900 wants. Discussions fit big-picture ideas , brainstorming, discovery, and collecting feedback before you commit the idea to an issue. Issues fit bug reports, planned improvements, and other scoped work . Pull requests comment on a proposed change to files.

Need Use a discussion Use an issue
Ask how to use the project when no file change is required Yes Convert later if it becomes a task

Announce a release, RFC, or event Yes (often an announcement category) Poor fit; leaves a forever-open work item

Gauge interest with a poll Yes No
Track a bug until a pull request fixes it No Yes
Assign an owner, milestone, and auto-close keywords Not the tool Yes
Keep Q&A searchable with a marked answer Yes (Q&A category) A closed issue is a weaker FAQ

A healthy community uses both. When a discussion yields a bug or a feature that is ready to implement, create an issue from the discussion so work gets an owner. The reverse is equally important: when someone opened an issue titled "Welcome newcomers" or "Should we adopt a code of conduct?" with no implementation ticket, convert the issue to a discussion instead of leaving a fake bug open forever.

Enabling Discussions (an administrator must turn it on)

Discussions are not on by default for every repository. GitHub is explicit: anyone with access to a repository or organization can create and participate in discussions there — however, an administrator must enable GitHub Discussions for that repository or organization first.

For a repository , a user with access to Settings enables the Discussions checkbox under Features . For an organization , an organization owner enables discussions in organization Settings , then chooses a source repository that will store the threads. Disable the same checkbox to turn the forum off.

Exam trap: "Anyone with read access can invent a Discussions tab on a repo that never enabled it." They cannot. Enablement is an admin (or org-owner) action. After enablement, participation is broad: visitors who can see the repo can usually join the conversation, which is why public open-source projects treat Discussions as their community Q&A.

Organization owners can further restrict who may create discussions in organization-owned repositories. Creation permission and moderation permission are not the same thing.

Categories and formats

All discussions must be created in a category. Categories are how a forum stays searchable instead of becoming one undifferentiated firehose. People with maintain or admin permissions on the repository (or on the organization's source repository ) define those categories. Each category has a unique name and emoji , an optional description, and a format :

Open-ended discussion — general conversation (Ideas, General, Show and tell).

Question and answer — a question that can have a comment marked as the answer .

Announcement — maintainers share news; only people with maintain or admin permissions can create new discussions in this format, but anyone can comment and reply .

Polls — multiple options the community votes on. You cannot move a discussion to or from the polls category.

Each repository or organization can have up to 25 categories . You can nest categories inside sections (a category belongs to at most one section). GitHub ships useful defaults you should recognize by name:

Default category Purpose Format
Announcements Updates and news from maintainers Announcement
General Anything relevant to the project Open-ended discussion
Ideas Ideas to change or improve the project Open-ended discussion
Polls Multiple-choice votes plus discussion Polls
Q&A Questions the community answers Question and Answer
Show and tell Creations, experiments, or tests Open-ended discussion
Q&A with marked answers

In a question-and-answer category, a maintainer (and others with triage permission) can mark a comment as the answer . GitHub highlights that comment and its replies so later visitors find the solution without rereading fifty posts. You can also mark a threaded reply as the answer. You cannot mark a minimized comment. Unmarking is allowed if a better answer appears. This is the GitHub-native replacement for "search Stack Overflow and hope"—and it is a high-yield GH-900 fact: marked answers exist on Q&A discussions, not on issues .

Announcements and polls

Use announcements for releases, breaking-change notices, and events you do not want every newcomer to re-create as a duplicate thread. The posting restriction is the exam discriminator: maintain or admin to start , community to discuss. Use polls when you want a lightweight vote—"which logo?"—not a tracked feature request. Polls are a distinct format; do not say you can recategorize a poll into Q&A.

Labels still work. Each repository has one shared set of labels for issues, pull requests, and discussions, so a good first issue label namespace is the same pool a discussion might reuse for triage. Labels do not turn a discussion into an assignable work item.

Loading diagram... When to open a discussion versus an issue

Pin, lock, close, and convert

GitHub Discussions includes maintainer tools. Triage permission on the repository (or on the org source repository) is enough to moderate : mark answers, lock threads, and convert issues. Write permission is what you need to delete a discussion. Do not say only owners can pin a FAQ.

Pin. Pin a discussion above the list so newcomers see it first. You can pin up to four discussions globally for the repository or organization, and up to four discussions per category . Global pins still appear in addition to category pins. Pinning does not change the category. Unpinning does not delete the thread.

Lock. Lock a conversation that is no longer constructive, that violates the code of conduct or GitHub's Community Guidelines, or that you want to freeze as an announcement. After lock, people with write access can still comment; you can optionally allow emoji reactions . Lock is not the same as close.

Close. Close a discussion that is resolved , no longer relevant , or a duplicate . Closing is the forum analog of "this thread is done" without deleting history. You can pick a close reason from the close control.

Convert an issue to a discussion. From the issue sidebar, choose Convert to discussion , pick a category, and confirm. GitHub creates the discussion from the issue content , so comments are not thrown away. Convert when the thread started as a "bug" but is really a question or an RFC. Creating an issue from a discussion is the opposite direction—use it when brainstorming produced real work.

Transfer. You can transfer a discussion to another repository owned by the same user or organization , if you can create discussions on the destination (for an org destination, that means the org's source repository). You cannot transfer from a private repository to a public one. You cannot transfer announcements . Changing an organization's source repository does not move existing organization discussions to the new source.

Repository discussions versus organization discussions

Repository discussions live on one repo's Discussions tab and are the right home for "how do I configure this package?" Organization discussions are for topics that are not specific to a single repository —onboarding the company, choosing a default linter across services, or an org-wide RFC. Enabling them requires picking a source repository . Threads then appear on both the organization's Discussions page and that source repository's Discussions page. Permission to participate or manage follows the source repository : write on the source repo is what you need to delete an organization discussion, the same way write on a repo is required to delete a repository discussion.

Exam scenarios and traps

"How do I install this?" with no owner → discussion in Q&A, then mark an answer. Not a forever-open issue.

"Ship a changelog to the community, no extra threads" → announcement category. Ordinary members cannot create those threads.

Discussions tab missing → an administrator has not enabled the feature.

"Convert" preserves the conversation. Closing an issue as wontfix because it was a question is the wrong moderation move.

Organization-wide chat is not a second product. It is Discussions on a source repository .

Polls cannot be recategorized into Q&A. Announcements cannot be transferred.

Pin limit is four global plus four per category, not unlimited.

Lock still allows write-access comments; it is not a delete.

If you can look at a one-line scenario and answer "forum thread or work item?" then name the category format and the admin enablement step, you have Domain 3's discussions skill.