133 lines
5.8 KiB
Markdown

---
id: 03-gitea-organization
title: Gitea Organization
---
# Gitea Organization Management
This document defines the organizational structure, permissions, and management practices for our Gitea instance. It explains how teams are organized, what permissions they hold, and how resources are managed across projects.
## 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, ensuring clear boundaries and streamlined workflows.
### Key Benefits
- **Project Isolation** → Each project has its own organization with dedicated repositories.
- **Technology Separation** → Distinct boundaries between 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 or initiatives.
---
## Organization Structure
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 training/probation
- `Project Development Tools` → Project for Development tool
- `Project Research Development` → Project for Research development
---
## Team Management
### Team Creation Process
1. **Request Submission** → Team Leader submits a team creation request.
2. **HoD[^1] 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
All organizations follow a standardized team structure with **four core team types** (structure can be modified as needed):
#### 👑 Owners Team
- **Purpose:** Provide full administrative control over the organization.
- **Members:** HoD and senior management for that organization.
- **Permissions:**
- Create, modify, and delete resources within the organization.
- Manage organization-wide settings, policies, and access controls.
- Add or remove teams and members.
- Approve major changes and policy updates.
- Full access to all repositories.
#### 👥 Leaders Team
- **Purpose:** Project management and technical leadership.
- **Members:** Team Leaders.
- **Permissions:** (Administrator Access)
- Create repositories.
- Manage team member permissions and assignments.
- Configure repository settings and branch protection rules.
- Review and approve pull requests.
- Oversee project workflows.
#### 💻 Developers Team
- **Purpose:** Core development work and feature implementation.
- **Members:** Game Developers.
- **Permissions:**
- Create branches and submit pull requests.
- Access assigned repositories and project resources.
- Participate in code reviews and technical discussions.
- Implement features and contribute to development.
| **Unit** | **Description** | **Permission** |
|:---------|:----------------|:--------------|
| **Code** | Access source code, files, commits and branches | Write |
| **Issues** | Organize bug reports, tasks and milestones | Write |
| **Pull Requests** | Enable pull requests and code reviews | Write |
| **Releases** | Track project versions and downloads | Read |
| **Wiki** | Write and share documentation with collaborators | Write |
| **Projects** | Manage issues and pulls in projects | Read |
| **Packages** | Manage repository packages | Read |
| **Actions** | Manage actions | Read |
| **Access to External Wiki** | Link to an external wiki | No Access |
| **Access to External Issues** | Link to an external issue tracker | No Access |
#### 🔧 Builders Team
- **Purpose:** Manage build and deployment automation.
- **Members:** Automation accounts (and optionally DevOps engineers).
- **Permissions:** (Administrator Access)
- Manage and run CI/CD pipelines.
- Execute build configurations and scripts.
- Perform automated deployments.
- Hold cross-organization access for shared infrastructure.
---
## 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]: Head of Department