1. Onboarding & Governance

How to request Github / Copilot access


Raise SYRA ticket from : https://syensqo-dwp.onbmc.com/dwp/app/#/page/w9ph6wjq/category/1039/SBE/SBE
User creation request for GitHub & GitHub Copilot Request 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)

Organization Creation & Naming Conventions

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

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.

Centralized Asset Ownership
The "Front Door" (Access Management)
Shared Resources & Policy Enforcement

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

Naming Convention (Repo): Syensqo-[platform]-[app name/project name]
- platform: (Azure), (GCP), (AWS), (Multi-cloud), (on-prem).
- Example: Syensqo-Azure-infra-Subscription-Mgmt

Team & Permission Management

In GitHub Enterprise Cloud,

a 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.

Access Control at Scale
Nested Teams (Hierarchy)
Mentioning and Communication
Required Reviews

Team Structure: Always nest teams under the Parent Org.

Permissions:
- Maintainer: For dev/ops lead (manage settings, no billing)
- Write: For Developers (standard CI/CD access).
- Triage/Read: For Stakeholders and Auditors.
Info
Rule: Never grant individual permissions

Page tree

1. Onboarding & Governance