Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

How to request Github / Copilot access

Expand
titleHow to request Github / Copilot access
Tab Pane | Vectors (Formerly: SP Tab pane)
anchor2603186
iconicon-sp-flag
nameTest
Tab Pane | Vectors (Formerly: SP Tab pane)
anchor2603186
iconicon-sp-flag
nameTest

Organization Creation & Naming Conventions

Panel
title
How to request Github / Copilot access


Image Modified


  • User creation request for GitHub & GitHub Copilot


    Info
    titleRequest format

    User email list

    Organization you have access approval  (approval email from existing organization owner)

    New organization request with justification

    License required (Github or Github copilot)


Image Modified



Expand
titleOrganization Naming Conventions
Panel
titleOrganization
Creation &
Naming Conventions



In the GitHub hierarchy, an Organization is the shared workspace that sits above Teams and acts as the owner of your Repositories.

If a Team is a "group of people," an Organization is the "company building" that houses the people, the projects, and the security front door.

  1. Centralized Asset Ownership
  2. The "Front Door" (Access Management)
  3. Shared Resources & Policy Enforcement
We avoid "Org Sprawl." New Organizations are only created for distinct Business Units or large-scale Projects.


  • Naming Convention (Org): SQO-<business-unit> (e.g., SQO-INFRASTRUCTURE,  SQO-INTEGRATION , SQO-SYENSQOAI).



  • Naming Convention (

Org): SQO-<business-unit> (e.g., SQO-INFRASTRUCTURE,  SQO-INTEGRATION , SQO-SYENSQOAI).
  • Repo):  Syensqo-[platform]-[app name/project name]   
     

    • platform:   (Azure), (GCP), (AWS), (Multi-cloud), (on-prem).

    • Example: Syensqo-Azure-infra-Subscription-Mgmt




Expand
titleOrganization Creation Justification
Panel
titleWhy do you need organization

We avoid "Org Sprawl." New Organizations are only created for distinct Business Units or large-scale Projects.


Policy: Strategic Organization Provisioning

To maintain a lean, secure, and manageable environment, we strictly adhere to a "Zero Sprawl" policy. New Organizations are not granted by default;

they are reserved exclusively for distinct Business Units with independent P&Ls or large-scale, cross-functional projects that require isolated governance.

Before a new Organization is provisioned, the requesting party must demonstrate that existing structures cannot meet their technical or regulatory requirements.


New Organization Request Form

Please provide the following information to the Architecture and Governance committee for review.

 


1. Existing Infrastructure Audit

  • Current Footprint: Does your department or parent Business Unit already have an existing Organization?

  • Integration Analysis: If yes, why can your requirements not be met by creating a new Project within the existing hierarchy?

2. Team Composition & Scale

  • Headcount: What is the estimated number of internal users, external contractors, and administrators?

3. Strategic Justification

  • Business Necessity: Explain the unique business driver for this separation (e.g., a legal divestiture, a joint venture, or a distinct brand identity).

  • Security & Compliance: Are there specific regulatory requirements (e.g., HIPAA, PCI-DSS, or data residency laws) that mandate a "Hard Isolation" from the rest of the company’s infrastructure?

4. Workload Profile & Roadmap

  • Current Scope: Describe the primary applications, services, or workloads to be hosted immediately.

  • Utilization Forecast: Provide a 12-to-24-month roadmap. What are the upcoming projects, and what is the expected growth in resource consumption (e.g estimation of license required,  CI/CD pipeline usage?

  • Lifecycle: Is this a permanent Business Unit or a time-bound project? (If time-bound, provide an estimated decommissioning date).




Expand
titleTeam & Permission Management
Panel
titleTeam & Permission Management

In GitHub Enterprise Cloud,

Team is much more than just a list of people. It is a fundamental organizational tool used to manage permissions, streamline communication, and group members based on their real-world roles or projects.

  1. Access Control at Scale
  2. Nested Teams (Hierarchy)
  3. Mentioning and Communication
  4. Required Reviews
Team & Permission Management
  • Team Structure: Always nest teams under the Parent Org.

Image Modified


  • Permissions:


    • Maintainer: For dev/ops lead (manage settings, no billing)
    • Write: For Developers (standard CI/CD access).

    • Triage/Read: For Stakeholders and Auditors.

    Info
    titleInfo

    Rule: Never grant individual permissions