docs: Add Gitea Organization Management document outlining structure, permissions, and team guidelines
This commit is contained in:
parent
b432ce83f3
commit
4a5a2ecc50
145
docs/02-version-control/03-gitea-organization.md
Normal file
145
docs/02-version-control/03-gitea-organization.md
Normal file
@ -0,0 +1,145 @@
|
||||
---
|
||||
id: 03-gitea-organization
|
||||
title: Gitea Organization
|
||||
---
|
||||
|
||||
# Gitea Organization Management
|
||||
|
||||
This document outlines the organizational structure, permissions, and management practices for our Gitea instance. It defines how teams are organized, what permissions they have, and how organizational resources are managed.
|
||||
|
||||
## Organization Overview
|
||||
|
||||
Our Gitea instance serves as the central repository management platform for all development projects. Organizations are structured around **projects** rather than functional teams, providing clear project boundaries and focused development workflows.
|
||||
|
||||
### Key Benefits
|
||||
- **Project Isolation** → Each project has its own organization with dedicated repositories
|
||||
- **Technology Separation** → Clear boundaries between different technology stacks
|
||||
- **Access Control** → Project-specific permissions and team assignments
|
||||
- **Resource Management** → Organized repositories, teams, and settings per project
|
||||
- **Scalability** → Easy to add new projects and development initiatives
|
||||
|
||||
---Continuous Integration/Continuous Deployment
|
||||
|
||||
## Organization Structure
|
||||
|
||||
Our Gitea instance is organized around **project-based organizations** rather than functional teams. Each organization represents a specific project or development initiative, allowing for clear project isolation and focused development workflows.
|
||||
|
||||
### 🎮 **Main Development Projects**
|
||||
Main Development Projects are end-user facing products or core game systems. These include all primary game titles, lobbies, and shared frameworks that are directly part of production or delivery.
|
||||
|
||||
- Full Name Pattern: `Project <Engine/Platform> <ProjectName>`
|
||||
- Name Pattern: `<Engine/Platform>-<ProjectName>`
|
||||
|
||||
**Examples:**
|
||||
- `Project Unity Joker` → Project Game for Joker using Unity Engine
|
||||
- `Project Cocos Core` → Project Core using Cocos Creator Engine
|
||||
- `Project Cocos Joker` → Project Game for Joker using Cocos Creator Engine
|
||||
- `Project Cocos Lobby` → Project Lobby using Cocos Creator Engine
|
||||
|
||||
### 🛠 **Support Organizations**
|
||||
Support Organizations are internal or auxiliary projects that provide tools, resources, infrastructure, or research to assist developers. They are not directly delivered to end-users but are essential for efficient development.
|
||||
|
||||
- Full Name Pattern: `Project <Purpose>`
|
||||
- Name Pattern: `dev-<Purpose>`
|
||||
|
||||
**Examples:**
|
||||
- `Project Developer Probation` → Project for Developer probation
|
||||
- `Project Development Tools` → Project for Development tool
|
||||
- `Project Research Development` → Project for Research development
|
||||
|
||||
---
|
||||
|
||||
## Permission Levels
|
||||
|
||||
### **👑 Owners Team**
|
||||
Holds the highest level of authority within an organization.
|
||||
- Create, modify, and delete any resource within the organization
|
||||
- Manage organization-wide settings, policies, and access controls
|
||||
- Add or remove teams and members
|
||||
- Configure organization-wide permissions
|
||||
- Approve major changes and policy updates
|
||||
- Full access to all repositories and resources
|
||||
|
||||
### **👥 Leaders Team**
|
||||
Responsible for managing project execution within their organization.
|
||||
- Create repositories within the organization’s scope
|
||||
- Manage team member permissions and assignments
|
||||
- Configure repository settings and branch protection rules
|
||||
- Review and approve pull requests
|
||||
- Oversee project workflows and development processes
|
||||
- Access to organization-specific repositories
|
||||
|
||||
### **💻 Developers Team**
|
||||
Responsible for day-to-day coding and implementation.
|
||||
- Create new branches and submit pull requests
|
||||
- Access assigned repositories and project resources
|
||||
- Participate in code reviews and technical discussions
|
||||
- Implement features and contribute to project development
|
||||
- Work only within their organization’s repositories
|
||||
|
||||
### **🔧 Builders Team**
|
||||
Automation account responsible for executing builds and deployments.
|
||||
- Execute CI/CD[^1] pipelines and automated build processes
|
||||
- Run build configurations and build scripts created by developers
|
||||
|
||||
---
|
||||
|
||||
# Team Management Guidelines
|
||||
|
||||
## Team Creation Process
|
||||
|
||||
1. **Request Submission** → Team Leader submits a team creation request.
|
||||
2. **HoD[^2] Approval** → Head of Department reviews and approves the request.
|
||||
3. **Team Setup** → HoD creates the team with appropriate permissions.
|
||||
4. **Member Assignment** → HoD adds members to the team.
|
||||
5. **Repository Access** → Repositories are assigned to the team as needed.
|
||||
|
||||
## Team Structure Guidelines
|
||||
|
||||
### Base Team Structure
|
||||
|
||||
All organizations follow a standardized team structure with **four core team types**:
|
||||
|
||||
#### 👑 Owners Team
|
||||
|
||||
* **Purpose:** Provide full administrative control over the organization.
|
||||
* **Members:** Head of Department (HoD) and senior management for that organization.
|
||||
* **Permissions:** Create, modify, and delete resources within the organization.
|
||||
* **Scope:** Limited to the specific organization they own.
|
||||
* **Size:** 1–3 members per organization (typically HoD and senior technical leads).
|
||||
|
||||
#### 👥 Leaders Team
|
||||
|
||||
* **Purpose:** Project management and technical leadership.
|
||||
* **Members:** Team Leaders.
|
||||
* **Permissions:** Manage team members, review and approve pull requests, configure repositories and workflows.
|
||||
* **Size:** 2–5 members per organization.
|
||||
|
||||
#### 💻 Developers Team
|
||||
|
||||
* **Purpose:** Core development work and feature implementation.
|
||||
* **Members:** Game Developers.
|
||||
* **Permissions:** Create branches, submit pull requests, access assigned repositories, and participate in code reviews.
|
||||
* **Size:** 3–10 members per organization (varies by project size).
|
||||
|
||||
#### 🔧 Builders Team
|
||||
|
||||
* **Purpose:** Manage build and deployment automation.
|
||||
* **Members:** Automation accounts (not human users).
|
||||
* **Permissions:** Execute CI/CD pipelines, run build scripts, and perform automated deployments.
|
||||
* **Size:** 1 automation account per organization.
|
||||
|
||||
---
|
||||
|
||||
## Team Assignment Guidelines
|
||||
|
||||
* **Organization-Specific Teams:** Each organization maintains its own complete set of base teams.
|
||||
* **Owners Team Scope:** Each organization has its own Owners Team, with authority limited to that organization.
|
||||
* **Cross-Project Access:** Builders Team may hold access to multiple organizations for shared infrastructure.
|
||||
* **Role Flexibility:** Team members may belong to multiple teams within the same organization if required.
|
||||
* **Permission Inheritance:** Team permissions are standardized and inherited from the base team structure.
|
||||
* **Isolation:** Owners of one organization cannot access or modify another organization.
|
||||
|
||||
---
|
||||
[^1]: Continuous Integration/Continuous Deployment
|
||||
[^2]: Head of Department
|
||||
Loading…
x
Reference in New Issue
Block a user