EpoCanvas 貢獻與官方文件編輯規範

[!IMPORTANT] 你可以提出修訂建議，但「提交建議」不等於「規則已生效」。只有經過內容審閱、必要的程式碼或測試核對，並正式合併至專案的版本，才可以被引用為官方說明。

1. 哪些內容可以貢獻

目前可提出貢獻的內容包括：

• docs/community/：社群公約、評論、隱私、帳號、安全、授權與申訴等公開政策；
• docs/standards/：指標、內容撰寫、版本、文件生命週期與系統邊界等工程規範；
• docs/roadmap.md 與 docs/operations/：專案狀態、發布流程與事件處理說明；
• 程式碼、測試、設定或資料結構的可重現問題；
• 普通文章中的錯字、來源補充、技術勘誤與讀者體驗回饋。

普通文章位於 src/content/posts/，其觀點與敘事不會自動成為社群政策。若一篇文章提出了規則建議，仍須轉入相應的官方文件並完成審閱，才會成為可引用的專案契約。

2. 提出問題與修訂的方法

你可以透過專案的程式碼提交、Issue/變更請求或 contact@epocanvas.com 提出建議。提交時請盡量包含：

1. 可定位的頁面、檔案、章節或 API 路由；
2. 目前文字與實際行為的差異，包含可重現的步驟或最小案例；
3. 你建議採用的文字、規則或驗收方式；
4. 可能受影響的讀者、資料、權限、第三方服務與相容性；
5. 若是勘誤，說明來源、測試結果或其他可核對證據。

請不要在公開 Issue、評論或變更請求中貼上密碼、API 金鑰、會話令牌、完整個人資料、支付資料或尚未遮蔽的漏洞利用細節。安全問題請改依安全問題通報規範私下提交。

3. 官方文件的編輯要求

官方文件至少應符合以下要求：

• 明確標示適用範圍、更新日期與必要的版本資訊；
• 區分 SOURCE-VERIFIED、TEST-VERIFIED、LIVE-VERIFIED、KNOWN-GAP 與 PROPOSED，不把規劃寫成現況；
• 涉及 API、權限、個人資料、支付或第三方服務時，附上對應的程式碼、設定、測試或失敗邊界；
• 使用正體中文作為目前官方政策與工程規範的編輯基線，並保留專有名詞、程式碼與路由的準確拼法；
• 讓標題層級、表格、連結、程式碼區塊與圖片替代文字可以被鍵盤與輔助技術理解；
• 不以徽章、截圖、單次請求成功或歷史提交推導出未被服務端驗證的權限與承諾。

目前不要求同一批變更同步翻譯所有語言版本。語言版本的適用順序與狀態，請參考翻譯與多語言維護政策。

4. 審閱與正式生效

一般錯字、連結或格式修正可以由維護者進行輕量審閱。若變更涉及下列任一項，應在合併前完成相稱的工程核對：

1. 評論、帳號、會話、Reaction 或管理權限；
2. 個人資料、公開欄位、保留期限或刪除流程；
3. 支付、退款、通知或第三方服務的責任邊界；
4. 資料庫 migration、API 請求/回應、路由或建置流程；
5. 社群公約、處置、檢舉或申訴的實質改變。

審閱結果應說明變更範圍、驗證命令或證據等級。文件變更應以可追溯的 Git Commit 保存；若同時修改程式碼，應讓文件、測試與實際行為在同一個發布範圍內可以互相對照。

5. 署名、授權與撤回

提出建議不會自動轉移你的著作權。提交到專案的補丁、文件文字與程式碼，須符合內容授權與版權說明及相關第三方授權。若你引用他人內容，請保留來源、授權與必要的修改說明。

若你後來發現貢獻包含錯誤、敏感資料或權利問題，請盡快聯絡維護者並提供可定位資訊。站方可以先暫停公開、修訂或移除有問題的部分；已經進入建置產物、備份、通知或審計紀錄的副本，不一定能立即全部撤回。

6. 爭議與規範衝突

若普通文章、介面文案、程式碼註解與官方政策互相矛盾，應先依社群政策總覽及相應政策頁處理，再向維護者報告差異。若官方政策與服務端實作不一致，文件應標記已知差異，並以當下服務端驗證結果作為實際權限依據，直到修訂完成。

最後更新：2026-10-20。

EpoCanvas 贡献与官方文档编辑规范

[!IMPORTANT] 你可以提出修订建议，但“提交建议”不等于“规则已生效”。只有经过内容审阅、必要的代码或测试核对，并正式合并至项目的版本，才可以被引用为官方说明。

1. 哪些内容可以贡献

目前可提出贡献的内容包括：

• docs/community/：社群公约、评论、隐私、账号、安全、授权与申诉等公开政策；
• docs/standards/：指标、内容撰写、版本、文档生命周期与系统边界等工程规范；
• docs/roadmap.md 与 docs/operations/：项目状态、发布流程与事件处理说明；
• 代码、测试、配置或数据结构的可复现问题；
• 普通文章中的错字、来源补充、技术勘误与读者体验反馈。

普通文章位于 src/content/posts/，其观点与叙事不会自动成为社群政策。若一篇文章提出了规则建议，仍须转入相应的官方文档并完成审阅，才会成为可引用的项目契约。

2. 提出问题与修订的方法

你可以透过项目的代码提交、Issue/变更请求或 contact@epocanvas.com 提出建议。提交时请尽量包含：

1. 可定位的页面、文件、章节或 API 路由；
2. 目前文字与实际行为的差异，包含可复现的步骤或最小案例；
3. 你建议采用的文字、规则或验收方式；
4. 可能受影响的读者、数据、权限、第三方服务与兼容性；
5. 若是勘误，说明来源、测试结果或其他可核对证据。

请不要在公开 Issue、评论或变更请求中贴上密码、API 密钥、会话令牌、完整个人资料、支付数据或尚未遮蔽的漏洞利用细节。安全问题请改依安全问题通报规范私下提交。

3. 官方文档的编辑要求

官方文档至少应符合以下要求：

• 明确标示适用范围、更新日期与必要的版本信息；
• 区分 SOURCE-VERIFIED、TEST-VERIFIED、LIVE-VERIFIED、KNOWN-GAP 与 PROPOSED，不把规划写成现状；
• 涉及 API、权限、个人资料、支付或第三方服务时，附上对应的代码、配置、测试或失败边界；
• 使用简体中文作为目前官方政策与工程规范的编辑基线，并保留专有名词、代码与路由的准确拼法；
• 让标题层级、表格、链接、代码块与图片替代文字可以被键盘与辅助技术理解；
• 不以徽章、截图、单次请求成功或历史提交推导出未被服务端验证的权限与承诺。

目前不要求同一批变更同步翻译所有语言版本。语言版本的适用顺序与状态，请参考翻译与多语言维护政策。

4. 审阅与正式生效

一般错字、链接或格式修正可以由维护者进行轻量审阅。若变更涉及下列任一项，应在合并前完成相称的工程核对：

1. 评论、账号、会话、Reaction 或管理权限；
2. 个人资料、公开字段、保留期限或删除流程；
3. 支付、退款、通知或第三方服务的责任边界；
4. 数据库 migration、API 请求/响应、路由或构建流程；
5. 社群公约、处置、举报或申诉的实质改变。

审阅结果应说明变更范围、验证命令或证据等级。文档变更应以可追溯的 Git Commit 保存；若同时修改代码，应让文档、测试与实际行为在同一个发布范围内可以互相对照。

5. 署名、授权与撤回

提出建议不会自动转移你的著作权。提交到项目的补丁、文档文字与代码，须符合内容授权与版权说明及相关第三方授权。若你引用他人内容，请保留来源、授权与必要的修改说明。

若你后来发现贡献包含错误、敏感数据或权利问题，请尽早联络维护者并提供可定位信息。站方可以先暂停公开、修订或移除有问题的部分；已经进入构建产物、备份、通知或审计记录的副本，不一定能立即全部撤回。

6. 争议与规范冲突

若普通文章、界面文案、代码注释与官方政策互相矛盾，应先依社群政策总览及相应政策页处理，再向维护者报告差异。若官方政策与服务端实现不一致，文档应标记已知差异，并以当下服务端验证结果作为实际权限依据，直到修订完成。

最后更新：2026-10-20。

EpoCanvas Contribution and Official Documentation Editorial Guidelines

[!IMPORTANT] You can propose revisions, but “submitting a suggestion” does not mean “the rule is in effect.” Only after content review, necessary code or test verification, and formal merging into the project’s version can it be cited as an official statement.

1. What Content Can Be Contributed

Content currently open for contribution includes:

• docs/community/: Public policies such as community covenants, comments, privacy, accounts, security, licensing, and appeals;
• docs/standards/: Engineering guidelines covering metrics, content writing, versions, document lifecycle, and system boundaries;
• docs/roadmap.md and docs/operations/: Project status, release processes, and incident handling instructions;
• Reproducible issues in code, tests, configurations, or data structures;
• Typos, source additions, technical errata, and reader experience feedback in general articles.

General articles are located in src/content/posts/, and their views and narratives do not automatically become community policy. If an article proposes rule suggestions, it must still be transferred to the corresponding official documentation and undergo review to become a citable project contract.

2. How to Submit Issues and Revisions

You can submit suggestions via project code commits, Issue/Pull Requests, or contact@epocanvas.com. When submitting, please try to include:

1. Locatable page, file, section, or API route;
2. Discrepancies between current text and actual behavior, including reproducible steps or a minimal case;
3. Your suggested text, rules, or acceptance criteria;
4. Potentially affected readers, data, permissions, third-party services, and compatibility;
5. If it’s an erratum, explain the source, test results, or other verifiable evidence.

Please do not post passwords, API keys, session tokens, full personal data, payment information, or unmasked exploit details in public Issues, comments, or pull requests. For security issues, please submit them privately according to the Security Vulnerability Disclosure Guidelines.

3. Official Documentation Editorial Requirements

Official documentation should meet at least the following requirements:

• Clearly indicate the scope of application, update date, and necessary version information;
• Distinguish between SOURCE-VERIFIED, TEST-VERIFIED, LIVE-VERIFIED, KNOWN-GAP, and PROPOSED, and do not present plans as current status;
• When involving APIs, permissions, personal data, payments, or third-party services, include corresponding code, configurations, tests, or failure boundaries;
• Use Traditional Chinese as the current editorial baseline for official policies and engineering guidelines, and preserve the accurate spelling of proper nouns, code, and routes;
• Ensure that heading levels, tables, links, code blocks, and image alt text are understandable by keyboard and assistive technologies;
• Do not infer unverified permissions and commitments from badges, screenshots, single successful requests, or historical commits without server-side validation.

Currently, simultaneous translation of all language versions for the same batch of changes is not required. For the applicability order and status of language versions, please refer to the Translation and Multilingual Maintenance Policy.

4. Review and Official Publication

General typos, link, or formatting corrections can undergo a lightweight review by maintainers. If changes involve any of the following, commensurate engineering verification should be completed before merging:

1. Comments, accounts, sessions, reactions, or administrative permissions;
2. Personal data, public fields, retention periods, or deletion processes;
3. Payment, refunds, notifications, or liability boundaries of third-party services;
4. Database migrations, API requests/responses, routes, or build processes;
5. Substantive changes to community covenants, dispositions, reports, or appeals.

Review results should describe the scope of changes, verification commands, or evidence level. Document changes should be preserved with traceable Git Commits; if code is modified simultaneously, documentation, tests, and actual behavior should be cross-referencable within the same release scope.

5. Attribution, Licensing, and Withdrawal

Submitting suggestions does not automatically transfer your copyright. Patches, document text, and code submitted to the project must comply with the Content Licensing and Copyright Notice and relevant third-party licenses. If you cite content from others, please retain the source, license, and necessary modification notes.

If you later discover that a contribution contains errors, sensitive data, or rights issues, please contact the maintainers as soon as possible and provide locatable information. The site may temporarily suspend public access, revise, or remove problematic parts; copies that have entered build artifacts, backups, notifications, or audit logs may not be immediately fully withdrawn.

6. Disputes and Policy Conflicts

If general articles, UI copy, code comments, and official policies contradict each other, they should first be handled according to the Community Policy Overview and corresponding policy pages, then report discrepancies to the maintainers. If official policies are inconsistent with server-side implementation, the documentation should mark known discrepancies, and the current server-side verification results should serve as the basis for actual permissions until revisions are completed.

Last updated: 2026-10-20.

Contribution à EpoCanvas et directives de rédaction des documents officiels

[!IMPORTANT] Vous pouvez soumettre des suggestions de révision, mais « soumettre une suggestion » ne signifie pas que « la règle est en vigueur ». Seule une version ayant fait l’objet d’une révision de contenu, d’une vérification nécessaire du code ou des tests, et officiellement fusionnée dans le projet, peut être citée comme explication officielle.

1. Types de contributions acceptées

Actuellement, les contributions peuvent inclure :

• docs/community/ : Politiques publiques telles que la charte communautaire, les commentaires, la confidentialité, les comptes, la sécurité, les licences et les plaintes ;
• docs/standards/ : Normes d’ingénierie telles que les métriques, la rédaction de contenu, les versions, le cycle de vie de la documentation et les limites du système ;
• docs/roadmap.md et docs/operations/ : État du projet, processus de publication et instructions de gestion des incidents ;
• Problèmes reproductibles liés au code, aux tests, à la configuration ou à la structure des données ;
• Fautes de frappe, ajouts de sources, corrections techniques et retours sur l’expérience lecteur dans les articles ordinaires.

Les articles ordinaires se trouvent dans src/content/posts/ ; leurs points de vue et récits ne deviennent pas automatiquement des politiques communautaires. Si un article propose une suggestion de règle, celle-ci doit être transférée vers le document officiel correspondant et faire l’objet d’une révision pour devenir un contrat de projet citable.

2. Méthodes pour soumettre des problèmes et des révisions

Vous pouvez soumettre des suggestions via les soumissions de code du projet, les Issues/demandes de modification ou à contact@epocanvas.com. Lors de la soumission, veuillez inclure autant que possible :

1. La page, le fichier, la section ou la route API localisable ;
2. Les différences entre le texte actuel et le comportement réel, y compris les étapes reproductibles ou un cas minimal ;
3. Le texte, les règles ou les méthodes d’acceptation que vous proposez ;
4. Les lecteurs, données, permissions, services tiers et compatibilité potentiellement affectés ;
5. S’il s’agit d’une correction, la source, les résultats des tests ou d’autres preuves vérifiables.

Veuillez ne pas publier de mots de passe, de clés API, de jetons de session, de données personnelles complètes, de données de paiement ou de détails d’exploitation de vulnérabilités non masqués dans les Issues publiques, les commentaires ou les demandes de modification. Les problèmes de sécurité doivent être soumis en privé conformément aux directives de divulgation de sécurité.

3. Exigences de rédaction pour les documents officiels

Les documents officiels doivent au moins satisfaire aux exigences suivantes :

• Indiquer clairement le champ d’application, la date de mise à jour et les informations de version nécessaires ;
• Distinguer SOURCE-VERIFIED, TEST-VERIFIED, LIVE-VERIFIED, KNOWN-GAP et PROPOSED, et ne pas présenter les plans comme des situations actuelles ;
• Lorsqu’il s’agit d’API, de permissions, de données personnelles, de paiements ou de services tiers, joindre le code, la configuration, les tests ou les limites d’échec correspondants ;
• Utiliser le chinois traditionnel comme base de rédaction actuelle pour les politiques officielles et les normes d’ingénierie, et conserver l’orthographe exacte des termes techniques, du code et des routes ;
• S’assurer que les niveaux de titre, les tableaux, les liens, les blocs de code et les textes alternatifs des images sont compréhensibles par le clavier et les technologies d’assistance ;
• Ne pas déduire des permissions et des engagements non vérifiés par le serveur à partir de badges, de captures d’écran, de succès de requêtes uniques ou d’historiques de soumissions.

Actuellement, il n’est pas exigé que toutes les versions linguistiques soient traduites simultanément pour un même ensemble de modifications. Pour l’ordre d’application et le statut des versions linguistiques, veuillez consulter la politique de traduction et de maintenance multilingue.

4. Révision et entrée en vigueur officielle

Les corrections générales de fautes de frappe, de liens ou de formatage peuvent faire l’objet d’une révision légère par les mainteneurs. Si une modification implique l’un des éléments suivants, une vérification technique proportionnée doit être effectuée avant la fusion :

1. Commentaires, comptes, sessions, réactions ou permissions d’administration ;
2. Données personnelles, champs publics, périodes de rétention ou processus de suppression ;
3. Paiements, remboursements, notifications ou limites de responsabilité des services tiers ;
4. Migrations de base de données, requêtes/réponses API, routes ou processus de construction ;
5. Changements substantiels à la charte communautaire, aux mesures disciplinaires, aux signalements ou aux plaintes.

Les résultats de la révision doivent décrire l’étendue des modifications, les commandes de vérification ou le niveau de preuve. Les modifications de la documentation doivent être conservées via des commits Git traçables ; si le code est modifié simultanément, la documentation, les tests et le comportement réel doivent pouvoir être mis en correspondance dans le même périmètre de publication.

5. Attribution, licence et retrait

La soumission de suggestions ne transfère pas automatiquement vos droits d’auteur. Les correctifs, le texte de la documentation et le code soumis au projet doivent être conformes à la licence de contenu et aux informations de copyright ainsi qu’aux licences tierces applicables. Si vous citez du contenu d’autrui, veuillez conserver la source, la licence et les explications nécessaires concernant les modifications.

Si vous découvrez ultérieurement que votre contribution contient des erreurs, des données sensibles ou des problèmes de droits, veuillez contacter les mainteneurs dès que possible et fournir des informations localisables. L’équipe du site peut suspendre la publication, réviser ou supprimer les parties problématiques ; les copies déjà intégrées dans les artefacts de construction, les sauvegardes, les notifications ou les journaux d’audit ne peuvent pas nécessairement être toutes retirées immédiatement.

6. Litiges et conflits de normes

En cas de contradiction entre les articles ordinaires, les textes d’interface, les commentaires de code et les politiques officielles, il convient de traiter la situation en se référant d’abord à l’aperçu des politiques communautaires et aux pages de politiques correspondantes, puis de signaler les divergences aux mainteneurs. Si une politique officielle est incohérente avec l’implémentation côté serveur, le document doit signaler la divergence connue et se baser sur le résultat de la vérification côté serveur actuel comme référence pour les permissions réelles, jusqu’à ce que la révision soit terminée.

Dernière mise à jour : 2026-10-20.

Normas de Contribución y Edición para la Documentación Oficial de EpoCanvas

[!IMPORTANT] Puedes proponer sugerencias de revisión, pero “enviar una sugerencia” no significa que “la regla ya esté en vigor”. Solo después de una revisión de contenido, la verificación necesaria de código o pruebas, y su fusión oficial en la versión del proyecto, podrá ser citada como una declaración oficial.

1. Contenido que se puede Contribuir

Actualmente, el contenido al que se puede contribuir incluye:

• docs/community/: Políticas públicas como el pacto comunitario, comentarios, privacidad, cuentas, seguridad, licencias y apelaciones;
• docs/standards/: Normas de ingeniería como métricas, redacción de contenido, versiones, ciclo de vida de la documentación y límites del sistema;
• docs/roadmap.md y docs/operations/: Estado del proyecto, proceso de lanzamiento y descripciones de manejo de incidentes;
• Problemas reproducibles en código, pruebas, configuración o estructuras de datos;
• Errores tipográficos, adiciones de fuentes, correcciones técnicas y comentarios sobre la experiencia del lector en artículos generales.

Los artículos generales se encuentran en src/content/posts/, y sus puntos de vista y narrativas no se convierten automáticamente en políticas de la comunidad. Si un artículo propone una sugerencia de regla, aún debe ser transferido a la documentación oficial correspondiente y completar la revisión para convertirse en un contrato de proyecto citable.

2. Cómo Reportar Problemas y Proponer Revisiones

Puedes enviar sugerencias a través de las contribuciones de código del proyecto, Issues/Solicitudes de Cambio o a contact@epocanvas.com. Al enviar, por favor, incluye la mayor cantidad posible de la siguiente información:

1. La página, archivo, sección o ruta de API localizable;
2. La diferencia entre el texto actual y el comportamiento real, incluyendo pasos reproducibles o un caso mínimo;
3. El texto, las reglas o el método de aceptación que sugieres;
4. Los lectores, datos, permisos, servicios de terceros y compatibilidad que podrían verse afectados;
5. Si es una corrección, explica la fuente, los resultados de las pruebas u otra evidencia verificable.

Por favor, no publiques contraseñas, claves API, tokens de sesión, información personal completa, datos de pago o detalles de explotación de vulnerabilidades no ocultos en Issues públicos, comentarios o solicitudes de cambio. Los problemas de seguridad deben enviarse de forma privada según las Normas de Divulgación de Seguridad.

3. Requisitos de Edición para la Documentación Oficial

La documentación oficial debe cumplir al menos con los siguientes requisitos:

• Indicar claramente el alcance, la fecha de actualización y la información de versión necesaria;
• Distinguir entre SOURCE-VERIFIED, TEST-VERIFIED, LIVE-VERIFIED, KNOWN-GAP y PROPOSED, y no presentar la planificación como el estado actual;
• Cuando se trate de API, permisos, datos personales, pagos o servicios de terceros, adjuntar el código, la configuración, las pruebas o los límites de fallo correspondientes;
• Utilizar el chino tradicional como línea base de edición actual para las políticas oficiales y normas de ingeniería, y preservar la ortografía precisa de términos técnicos, código y rutas;
• Asegurar que los niveles de encabezado, tablas, enlaces, bloques de código y texto alternativo de imágenes sean comprensibles para el teclado y las tecnologías de asistencia;
• No inferir permisos y compromisos no verificados por el servidor a partir de insignias, capturas de pantalla, éxitos de una sola solicitud o commits históricos.

Actualmente, no se requiere que el mismo conjunto de cambios se traduzca simultáneamente a todas las versiones de idioma. Para el orden de aplicabilidad y el estado de las versiones de idioma, consulta la Política de Traducción y Mantenimiento Multilingüe.

4. Revisión y Entrada en Vigor Oficial

Las correcciones generales de errores tipográficos, enlaces o formato pueden ser sometidas a una revisión ligera por parte de los mantenedores. Si los cambios involucran cualquiera de los siguientes puntos, se debe completar una verificación de ingeniería proporcional antes de la fusión:

1. Comentarios, cuentas, sesiones, reacciones o permisos de administración;
2. Datos personales, campos públicos, períodos de retención o procesos de eliminación;
3. Límites de responsabilidad para pagos, reembolsos, notificaciones o servicios de terceros;
4. Migraciones de bases de datos, solicitudes/respuestas de API, rutas o procesos de construcción;
5. Cambios sustanciales en el pacto comunitario, disposiciones, informes o apelaciones.

Los resultados de la revisión deben especificar el alcance del cambio, los comandos de verificación o el nivel de evidencia. Los cambios en la documentación deben guardarse con un Git Commit rastreable; si se modifica el código simultáneamente, la documentación, las pruebas y el comportamiento real deben poder cotejarse dentro del mismo ámbito de lanzamiento.

5. Atribución, Licencia y Retiro

Proponer sugerencias no transfiere automáticamente tus derechos de autor. Los parches, el texto de la documentación y el código enviados al proyecto deben cumplir con la Licencia de Contenido y Declaración de Derechos de Autor y las licencias de terceros relevantes. Si citas contenido de otros, por favor, conserva la fuente, la licencia y las explicaciones de las modificaciones necesarias.

Si posteriormente descubres que una contribución contiene errores, datos sensibles o problemas de derechos, por favor, contacta a los mantenedores lo antes posible y proporciona información localizable. El sitio puede suspender temporalmente la publicación, revisar o eliminar las partes problemáticas; las copias que ya han entrado en artefactos de construcción, copias de seguridad, notificaciones o registros de auditoría no siempre pueden ser retiradas por completo de inmediato.

6. Disputas y Conflictos de Normas

Si los artículos generales, el texto de la interfaz, los comentarios de código y las políticas oficiales se contradicen entre sí, se debe proceder primero según la Visión General de las Políticas de la Comunidad y las páginas de políticas correspondientes, y luego reportar las diferencias a los mantenedores. Si las políticas oficiales no son consistentes con la implementación del lado del servidor, la documentación debe marcar las diferencias conocidas y utilizar el resultado de la verificación actual del lado del servidor como base para los permisos reales hasta que se complete la revisión.

Última actualización: 2026-10-20.

EpoCanvas: Richtlinien für Beiträge und die Redaktion offizieller Dokumente

[!IMPORTANT] Sie können Revisionsvorschläge einreichen, aber ein „eingereichter Vorschlag“ bedeutet nicht, dass die „Regel bereits in Kraft ist“. Nur nach einer Inhaltsprüfung, notwendiger Code- oder Testverifizierung und der offiziellen Zusammenführung in die Projektversion kann er als offizielle Beschreibung zitiert werden.

1. Welche Inhalte können beigetragen werden?

Derzeit können Beiträge zu folgenden Inhalten eingereicht werden:

• docs/community/: Öffentliche Richtlinien wie Community-Charta, Kommentare, Datenschutz, Konten, Sicherheit, Lizenzen und Beschwerden;
• docs/standards/: Technische Spezifikationen wie Metriken, Inhaltserstellung, Versionierung, Dokumentenlebenszyklus und Systemgrenzen;
• docs/roadmap.md und docs/operations/: Projektstatus, Veröffentlichungsprozesse und Anweisungen zur Ereignisbehandlung;
• Reproduzierbare Probleme in Code, Tests, Konfigurationen oder Datenstrukturen;
• Tippfehler, Quellenhinweise, technische Korrekturen und Feedback zur Leserfahrung in gewöhnlichen Artikeln.

Gewöhnliche Artikel befinden sich unter src/content/posts/. Ihre Ansichten und Erzählungen werden nicht automatisch zu Community-Richtlinien. Wenn ein Artikel Regelvorschläge enthält, müssen diese noch in die entsprechenden offiziellen Dokumente überführt und geprüft werden, bevor sie zu einem zitierfähigen Projektvertrag werden.

2. So reichen Sie Probleme und Revisionen ein

Sie können Vorschläge über Code-Commits des Projekts, Issue-/Pull-Anfragen oder an contact@epocanvas.com einreichen. Bitte versuchen Sie, bei der Einreichung Folgendes anzugeben:

1. Die lokalisierbare Seite, Datei, der Abschnitt oder die API-Route;
2. Die Diskrepanz zwischen dem aktuellen Text und dem tatsächlichen Verhalten, einschließlich reproduzierbarer Schritte oder eines minimalen Beispiels;
3. Der von Ihnen vorgeschlagene Text, die Regeln oder die Akzeptanzkriterien;
4. Potenziell betroffene Leser, Daten, Berechtigungen, Drittanbieterdienste und Kompatibilität;
5. Wenn es sich um eine Korrektur handelt, geben Sie die Quelle, Testergebnisse oder andere überprüfbare Beweise an.

Bitte posten Sie keine Passwörter, API-Schlüssel, Sitzungstoken, vollständige persönliche Daten, Zahlungsdaten oder unmaskierte Details zu Schwachstellen in öffentlichen Issues, Kommentaren oder Pull-Anfragen. Sicherheitsprobleme sollten stattdessen gemäß den Richtlinien zur Offenlegung von Sicherheitsproblemen privat eingereicht werden.

3. Redaktionelle Anforderungen an offizielle Dokumente

Offizielle Dokumente sollten mindestens die folgenden Anforderungen erfüllen:

• Den Geltungsbereich, das Aktualisierungsdatum und die notwendigen Versionsinformationen klar kennzeichnen;
• Zwischen SOURCE-VERIFIED, TEST-VERIFIED, LIVE-VERIFIED, KNOWN-GAP und PROPOSED unterscheiden und Planungen nicht als aktuellen Status darstellen;
• Bei Bezugnahme auf APIs, Berechtigungen, persönliche Daten, Zahlungen oder Drittanbieterdienste den entsprechenden Code, die Konfiguration, Tests oder Fehlergrenzen beifügen;
• Traditionelles Chinesisch als aktuelle redaktionelle Basis für offizielle Richtlinien und technische Spezifikationen verwenden und die genaue Schreibweise von Fachbegriffen, Code und Routen beibehalten;
• Sicherstellen, dass Überschriftenebenen, Tabellen, Links, Codeblöcke und Bild-Alternativtexte von Tastaturen und assistiven Technologien verstanden werden können;
• Berechtigungen und Zusagen, die nicht serverseitig verifiziert wurden, nicht aus Badges, Screenshots, einmaligen erfolgreichen Anfragen oder historischen Commits ableiten.

Derzeit ist es nicht erforderlich, dass alle Sprachversionen einer Änderung gleichzeitig übersetzt werden. Die Anwendungsreihenfolge und der Status der Sprachversionen finden Sie in den Richtlinien für Übersetzung und mehrsprachige Pflege.

4. Überprüfung und offizielles Inkrafttreten

Allgemeine Tippfehler, Links oder Formatkorrekturen können von den Betreuern leicht überprüft werden. Wenn eine Änderung eine der folgenden Punkte betrifft, sollte vor der Zusammenführung eine entsprechende technische Überprüfung abgeschlossen werden:

1. Kommentare, Konten, Sitzungen, Reaktionen oder Administratorberechtigungen;
2. Persönliche Daten, öffentliche Felder, Aufbewahrungsfristen oder Löschprozesse;
3. Zahlungen, Rückerstattungen, Benachrichtigungen oder die Verantwortlichkeitsgrenzen von Drittanbieterdiensten;
4. Datenbankmigrationen, API-Anfragen/-Antworten, Routen oder Build-Prozesse;
5. Wesentliche Änderungen an der Community-Charta, Maßnahmen, Meldungen oder Beschwerden.

Das Überprüfungsergebnis sollte den Umfang der Änderung, den Verifizierungsbefehl oder das Evidenzniveau angeben. Dokumentenänderungen sollten in nachvollziehbaren Git-Commits gespeichert werden; wenn gleichzeitig Code geändert wird, sollten Dokumentation, Tests und tatsächliches Verhalten innerhalb desselben Veröffentlichungsbereichs miteinander abgeglichen werden können.

5. Namensnennung, Lizenzierung und Widerruf

Das Einreichen von Vorschlägen überträgt Ihr Urheberrecht nicht automatisch. Patches, Dokumententexte und Code, die dem Projekt übermittelt werden, müssen den Inhaltslizenz- und Urheberrechtshinweisen sowie den entsprechenden Drittanbieterlizenzen entsprechen. Wenn Sie Inhalte anderer zitieren, geben Sie bitte die Quelle, die Lizenz und die notwendigen Änderungsbeschreibungen an.

Sollten Sie später feststellen, dass Ihr Beitrag Fehler, sensible Daten oder rechtliche Probleme enthält, kontaktieren Sie bitte umgehend die Betreuer und stellen Sie lokalisierbare Informationen bereit. Die Website kann problematische Teile vorübergehend aussetzen, überarbeiten oder entfernen; Kopien, die bereits in Build-Artefakte, Backups, Benachrichtigungen oder Audit-Logs gelangt sind, können möglicherweise nicht sofort vollständig zurückgezogen werden.

6. Konflikte und Richtlinienkollisionen

Wenn gewöhnliche Artikel, UI-Texte, Code-Kommentare und offizielle Richtlinien widersprüchlich sind, sollte dies zuerst gemäß der Community-Richtlinienübersicht und den entsprechenden Richtlinienseiten behandelt und dann den Betreuern gemeldet werden. Wenn offizielle Richtlinien und die serverseitige Implementierung inkonsistent sind, sollte das Dokument die bekannten Unterschiede kennzeichnen und das aktuelle serverseitige Verifizierungsergebnis als Grundlage für die tatsächlichen Berechtigungen verwenden, bis die Überarbeitung abgeschlossen ist.

Zuletzt aktualisiert: 2026-10-20.