Skip to content

GitHub Responsibilities

Purpose

This document defines the responsibilities of the Information Systems (IS) as Owners of the GitHub organization and to clarify what remains delegated to engineering teams.

Scope

This applies to the organization hosted on GitHub and all repositories within it.

IS Owner Responsibilities

  1. Identity & Access Management
    1. Invite and remove organization members
    2. Enforce organization-wide authentication policies (e.g., 2FA, SSO)
    3. Manage outside collaborators (vendors, contractors)
    4. Handle account recovery and access exceptions
  2. Security & Policy Enforcement
    1. Define and enforce org-wide defaults:
    2. Branch protection rules
    3. Required pull request reviews
    4. Required CI checks
    5. Enable and manage security tooling:
    6. Dependabot
    7. Secret scanning
    8. Code scanning (if licensed)
  3. Moderation & Conduct
    1. Manage organization-level blocks
    2. Respond to conduct or harassment complaints
    3. Act as neutral arbiters for disputes involving GitHub access or moderation
  4. Audit, Compliance & Billing
    1. Access and retain audit logs
    2. Support compliance reviews and investigations
    3. Manage GitHub billing, plans, and license assignments

Explicit Non-Responsibilities

IS Owners are not responsible for:

  1. Code review or approval
  2. Repository-level technical decisions
  3. Issue triage or project management
  4. Release management
  5. Development workflows

RACI Matrix (Clear Separation of Duties)

Activity IS Owners Engineering Managers Team Maintainers Engineers
Org settings R A C I
Member lifecycle R A C I
SSO / IAM R A I I
Org moderation R A C I
Billing & licenses R A I I
Repo creation C R R I
Repo admin rights I R R I
Branch rules (repo) C R R I
PR reviews I C R R
Issues & releases I I R R

Legend: R = Responsible; A = Accountable; C = Consulted; I = Informed

Transition Checklist (Order Matters)

Phase 1: Preparation

  • Identify 2–3 IS staff to become GitHub Owners
  • Document current Owners and their roles
  • Inventory existing teams and repo permissions
  • Confirm SSO / 2FA posture

Phase 2: Permission Stabilization

  • Ensure all repos have:
    • At least one team with Admin
    • At least two maintainers per critical repo
  • Confirm no repo relies on an individual Owner for access

Phase 3: Ownership Transfer

  • Add IS staff as Owners
  • Verify IS access to:
    • Org settings
    • Moderation
    • Billing
    • Audit logs

Phase 4: Demotion of Engineers

  • Gradually demote engineering Owners → Members
  • Validate engineers retain necessary repo-level admin rights
  • Confirm no workflow breaks

Phase 5: Communication & Freeze

  • Announce governance change
  • Publish RACI + policy
  • Freeze Owner role changes without IS approval

Internal Policy Memo (Engineer-Facing)

Subject: Change to GitHub Organization Ownership Model

Background

To strengthen governance, reduce perceived power imbalances, and align GitHub administration with institutional IT and security practices, ownership of the GitHub organization will transition to Information Systems (IS).

What Is Changing

  • IS will be the only GitHub Organization Owners
  • Engineers will remain Members
  • Engineers will continue to have full repository-level control via teams

What Is Not Changing

  • Day-to-day development workflows
  • Repo admin rights for engineering teams
  • Autonomy over code, reviews, issues, and releases

Why This Change Is Being Made

  • Clear separation of governance from development
  • Neutral handling of moderation and disputes
  • Alignment with IAM, security, and compliance responsibilities
  • Reduced risk of perceived or actual conflicts of interest

Expectations Going Forward

  • Operationally critical information must be communicated explicitly
  • GitHub notifications are informational only
  • Org-level actions (blocks, enforcement) are handled by IS

Effective Date

TBD

When to Contact Information Systems (Quick Guide)

  • Problems accessing the GitHub organization or repositories.
  • Account lockouts, 2FA or SSO issues.
  • Concerns related to organization-level moderation or conduct.
  • Billing, licensing, or compliance questions.
  • Requests for organization-level policy or security changes.

Engineering teams should not contact IS for routine repository management, code review disputes, or development workflow questions.

GitHub Notifications: What They Are and Are Not (FAQ)

What are GitHub notifications?

GitHub notifications are best-effort informational signals delivered via the web interface or email based on individual user settings.

Do notifications guarantee awareness?

No. GitHub provides no audit trail or confirmation that notifications were delivered, seen, or acknowledged.

Does watching a repository imply responsibility?

No. Watching a repository does not create an obligation to monitor activity or guarantee receipt of notifications.

Are release notes guaranteed to notify watchers?

No. Release notifications depend on individual watch preferences and notification configuration.

Can notifications be used as evidence?

No. Notifications should not be relied upon as proof of awareness, intent, or acknowledgement.

Guiding Principle

Operationally significant information must be communicated explicitly through direct, documented channels. GitHub notifications are supplemental and informational only.