Trục 7: Quản trị
Điều lệ GCC
GCBoK được phát hành bởi GitCover Commons gUG (GCC). GCC là một pháp nhân phi lợi nhuận theo § 60a Abs. 1 AO, được Finanzamt Bad Homburg v. d. H. công nhận (quyết định ngày 27.05.2026).
Các mục đích điều lệ (§ 52 Abs. 2 Satz 1 AO):
- Khoa học và nghiên cứu (Nr. 1)
- Giáo dục, giáo dục phổ thông và giáo dục nghề nghiệp (Nr. 7)
- Tư vấn người tiêu dùng và bảo vệ người tiêu dùng (Nr. 16)
- Tinh thần quốc tế và sự hiểu biết giữa các dân tộc (Nr. 13)
Điều lệ đầy đủ, quyết định công nhận và thông tin quyên góp: trên trang đích GCC.
Quy tắc cộng đồng GCC
GCBoK tuân theo các nguyên tắc mã nguồn mở:
- OSS-first - Tất cả các đặc tả đều là mã nguồn mở
- CC BY-SA 4.0 (mục tiêu) - Phân phối tự do kèm ghi công
- Apache 2.0 - Cho các thành phần mã
- Đánh giá cộng đồng - Đóng góp qua Gitea Pull-Requests
- Không khóa nhà cung cấp - Tài liệu tham chiếu trung lập với nhà sản xuất
Quy trình thay đổi GCBoK
Các thay đổi đối với GCBoK tuân theo một quy trình được xác định:
- Đề xuất - Issue trong repo Gitea
gcbok-content - Đánh giá - Thảo luận cộng đồng, kiểm tra chuyên môn
- Bản nháp - Pull-Request với các thay đổi đề xuất
- Phê duyệt - Đánh giá bởi ban điều hành GCC
- Hợp nhất - Tích hợp vào nhánh main
- Phát hành - Thẻ phát hành được đánh phiên bản
Từ đánh giá cá nhân đến kết quả có thể chứng minh
Quản trị ở đây không có nghĩa là ý kiến trong tài liệu, mà là kết quả có thể chứng minh trong hồ sơ lưu trữ. Các chỉ dẫn cá nhân của người phê duyệt - đánh giá riêng, trọng số, tiêu chí cân nhắc - là tài liệu đầu vào: Chúng được bảo vệ, không được đánh phiên bản và không xuất hiện trong kho tài liệu. Cái được tạo ra là kết quả quyết định: một ADR, một mẫu, một bộ quy tắc hoặc một bằng chứng.
Đối với chuỗi bằng chứng, điều này có nghĩa là: kho Git chứng minh điều gì đã được quyết định và cách nó có thể được chứng minh - không phải cách nó đã được cân nhắc nội bộ. Sự tách biệt này đồng thời bảo vệ quyền riêng tư của người hành động và giá trị chứng cứ của hồ sơ.
Quy tắc cho tác nhân: Tuân thủ chỉ dẫn, ghi lại kết quả - không trích dẫn cũng không tái tạo bản thân đánh giá, chừng nào HITL chưa cho phép rõ ràng.
Đánh phiên bản
GCBoK sử dụng Semantic Versioning (MAJOR.MINOR.PATCH):
| Thành phần | Ý nghĩa |
|---|---|
| MAJOR | Thay đổi khái niệm không tương thích |
| MINOR | Chương mới, định nghĩa mới (tương thích ngược) |
| PATCH | Sửa lỗi, làm rõ |
Tự tham chiếu Git-native
GCBoK được đánh phiên bản trong Git - tác phẩm tham chiếu về tuân thủ Git-native tự nó được lưu trữ trong Git. Đây là một sự tự tham chiếu có chủ đích: tác phẩm về tác phẩm được đánh phiên bản trong chính tác phẩm.
Khung chiến lược: Quyền sử dụng IP
AFJD (Axel Franz Johann Druschel) với tư cách cá nhân là người nộp đơn, nhà sáng chế và chủ sở hữu lâu dài của toàn bộ các quyền bảo hộ. IP vẫn thuộc về AFJD - GCC được trao quyền sử dụng trên cơ sở hợp đồng (không chuyển giao quyền sở hữu).
| Khía cạnh | Chuyển giao quyền sở hữu (không được chọn) | Quyền sử dụng theo hợp đồng (được chọn) |
|---|---|---|
| Chủ sở hữu IP | GCC | cá nhân |
| GCC là bên cấp phép? | Có -> đe dọa tư cách phi lợi nhuận | Không -> tư cách phi lợi nhuận của GCC được đảm bảo |
| Bảo vệ trước việc tiếp quản | Thấp | Cao (IP vẫn thuộc cá nhân) |
Chi tiết đầy đủ: Xem Quyền bảo hộ.
Tách biệt PII: dữ liệu cá nhân tập trung, tham chiếu trong các tenant
Dữ liệu cá nhân (PII, DSGVO/GDPR) không được phân tán qua các repo tenant. Mỗi pháp nhân
quản lý toàn bộ PII trong một repo PII trung tâm (Top-Root, ví dụ REPOS/AFJD/PII/) — dữ liệu gốc và
liên hệ, ghi chú phong tỏa, ghi chú lưu trữ/xóa, sự đồng ý và dữ liệu được
bảo vệ đặc biệt. Trong các repo Tenant-/OSS-/Work- chỉ có tham chiếu: uuidV7 của người đó
dưới dạng person_uid (kiểu uuidV7, không phải tên thuộc tính) cộng với thông tin tham chiếu cục bộ (chức năng/vai trò, quyền).
Vì sao: giảm thiểu dữ liệu (DSGVO Art. 5), nhận dạng duy nhất (tên thật không duy nhất) và các quyền của chủ thể dữ liệu có thể thực thi trên thực tế (truy cập/xóa/chuyển giao) — một dữ kiện PII tồn tại một lần, mọi nơi khác tham chiếu đến. Bản quét thô (giấy tờ tùy thân/chữ ký) vẫn ngoài Git.
Công cụ: Giải pháp GitCover.PII (UI tự quản lý tương tự tài khoản Google: các khía cạnh bắt buộc theo DSGVO,
ghi chú phong tỏa, lưu trữ, dữ liệu liên hệ) liên kết GitCover.IdP (IAM) và GitCover.Ledger (bằng chứng).
SSoT quy chuẩn:
OSS/TOP/.gitcover/specs/pii-separation.md.
Trật tự & chuẩn hóa: Các hoạt động xử lý trước tiên được xác định theo quy định GDPR (legalBasis, Art. 6/9 DSGVO) và sau đó thông qua tham chiếu (ở đâu/bằng cách nào) — legalBasis là điểm neo (không phải một danh sách mục đích tự do). Các sự cho phép (“sự cho phép của người dùng”) được ghi lại về mặt kỹ thuật dưới dạng GCPN và chỉ được tham chiếu. Các tình huống DSGVO được chuẩn hóa dưới dạng ENUMs/UNIONs trong GCBoK; một danh mục OSCAL + các bộ tạo tác OPA (SSoT: .gitcover/policy/pii-gdpr.catalog.json, pii_legal_basis.rego) được tính năng GitCover.PII tiêu thụ (Policy-as-Code).
Chủ quyền dữ liệu thay vì Vendor Lock-In: Các dữ kiện phát sinh trong PII sẽ có thể thay thế tùy chọn M365-/MS-User-Account-Graphs — dữ liệu cá nhân không được quản lý trong một nền tảng đám mây mà trong repo Git. Điều này cho phép tuân thủ Git-native (có thể kiểm toán, tự tham chiếu) và toàn quyền chủ quyền dữ liệu của người dùng mà không có Vendor Lock-In. Các dữ kiện PII đồng thời là nền dữ liệu cho tính năng OU (GitCover.Discovery/plans/ADR-005), tính năng này cung cấp cho System.DirectoryServices (Microsoft Active Directory) cấu trúc OU/provisioning — ở đó chỉ có người qua person_uid; GitCover.IdP vẫn là Authorization Server.