What's changed: New GH-100 Chapter 2 (user support & standards = admin vs GitHub Support triage, support bundles/diagnostics, dev-process standards [branching/reviews/releases/workflows] backed by rulesets; deployment & licensing = GHEC with EMU / Data Residency + EMU / personal accounts / GHES, seat + metered billing, monitoring license usage and reclaiming unused seats, SCIM/EMU linkage)
2.1Supporting Users and Standardizing Developer Processes
Understand distinguishing issues an admin can resolve from those for GitHub Support, generating support bundles and diagnostics, and defining standards for developer processes—workflows, branching, reviews, and releases.
An enterprise admin handles day-to-day support and setting standards so dev teams work efficiently and safely. GH-100 tests triaging issues (admin-resolvable vs GitHub Support) and defining developer-process standards for the org.
2.1.1Admin vs GitHub Support
Rather than sending everything to Support, handle what admin settings/permissions can fix yourself—access adjustments, policy/ruleset configuration, user/team management, feature enablement. Conversely, platform outages, product bugs, deep account issues, and systemic GHES troubles go to GitHub Support. On GHES, generating a support bundle or diagnostics to provide to Support speeds investigation. The key is judging "within my admin scope vs vendor handling."
2.1.2Developer-process standards
Admins recommend and set up process standards so teams work consistently—branching strategy (trunk-based / GitHub Flow), PR review standards (required reviewers/checks), release practices (tags/releases/environments), and shared workflows (CI/CD). These are technically backed by rulesets and branch protection (Chapter 1), org templates, and starter workflows (GH-200). Standardization reduces quality variance and onboarding cost.
Common: (1) Triage issues into admin-resolvable (permissions/policy/user management) vs GitHub Support cases (outages/bugs/GHES system failures). (2) On GHES, generate a support bundle/diagnostics for Support. (3) Admins set developer-process standards (branching, review standards, releases, shared workflows), backed by rulesets/branch protection/starter workflows.
Watch out: (1) Sending permission/policy-fixable issues to Support slows things—check your admin scope first. (2) Support bundles may contain sensitive info—handle carefully. (3) Standards as "recommendations" alone aren’t followed—combine with enforcement (rulesets). (4) Process standards (people/ops) and technical enforcement (rulesets) differ but complement each other.
2.1.3Section summary
- Triage: admin-resolvable (permissions/policy/users) vs GitHub Support cases (outages/bugs/GHES)
- On GHES, generate a support bundle/diagnostics for Support
- Define developer-process standards (branching/reviews/releases/workflows)
- Back standards technically with rulesets/branch protection/starter workflows
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. A member reports they "can’t access a specific repo." As an admin, what should you do first?
Q2. For a systemic GHES issue you ask GitHub Support to investigate. What speeds the investigation?
Q3. Which is appropriately part of admin-defined "developer-process standards"?
Q4. A standard was communicated as a recommendation but isn’t followed. Most appropriate response?
Q5. Which is a typical issue to send to GitHub Support?
Q6. Which is a correct caution when handling a support bundle?