7.1 Discussions

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.

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:

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.

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.