diff --git a/.gitignore b/.gitignore index a205baba..309a1bf3 100644 --- a/.gitignore +++ b/.gitignore @@ -12,4 +12,4 @@ urls.txt release.body *.orig node_modules/ -package-lock.json +package-lock.json \ No newline at end of file diff --git a/404.md b/404.md index 7a4a22bd..7641cbba 100644 --- a/404.md +++ b/404.md @@ -6,10 +6,11 @@ title: Page not found toc: false --- -# 404 Not Found +# 404 找不到網頁 -If you typed the web address, check it is correct. +如果您是手動輸入網址，請確認網址是否正確。 -If you pasted the web address, check you copied the entire address. +如果您是複製貼上此網址，請確認是否有複製到完整的網址。 -If the web address is correct or you followed a link or button, email the [Foundation for Public Code staff](mailto:info@publiccode.net) so we'll be able to help you out, as well as correct our mistake. +若網址正確，或您是按下連結或按鈕來的，請寫信給 [Foundation for Public Code 員 +工](mailto:info@publiccode.net)，讓我們協助您，並同時修正我們的錯誤。 diff --git a/AUTHORS.md b/AUTHORS.md index ef7f3f3a..f4042c02 100644 --- a/AUTHORS.md +++ b/AUTHORS.md @@ -2,36 +2,38 @@ # SPDX-License-Identifier: CC0-1.0 # SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS --- -# Authors -* Alba Roza, [The Foundation for Public Code](https://publiccode.net/) +# 作者群 + +* Alba Roza，[Foundation for Public Code](https://publiccode.net/) * Arnout Engelen -* Arnout Schuijff, The Foundation for Public Code -* Audrey Tang, [digitalminister.tw](https://digitalminister.tw/) -* Ben Cerveny, The Foundation for Public Code +* Arnout Schuijff，Foundation for Public Code +* 唐鳳，[數位發展部](https://digitalminister.tw/) +* Ben Cerveny，Foundation for Public Code * Bert Spaan -* Boris van Hoytema, The Foundation for Public Code +* Boris van Hoytema，Foundation for Public Code * Charlotte Heikendorf -* Claus Mullie, The Foundation for Public Code +* Claus Mullie，Foundation for Public Code * David Barberi -* Edo Plantinga, [Code For NL](https://codefor.nl/) -* Elena Findley-de Regt, The Foundation for Public Code -* Eric Herman, The Foundation for Public Code -* Felix Faassen, The Foundation for Public Code +* Edo Plantinga，[Code For NL](https://codefor.nl/) +* Elena Findley-de Regt，Foundation for Public Code +* Eric Herman，Foundation for Public Code +* Felix Faassen，Foundation for Public Code * Floris Deerenberg -* Jan Ainali, The Foundation for Public Code -* Johan Groenen, Code For NL +* Jan Ainali，Foundation for Public Code +* Johan Groenen，Code For NL * Marcus Klaas de Vries -* Mark van der Net, [Gemeente Amsterdam](https://www.amsterdam.nl/en/) -* Martijn de Waal, [Amsterdam University of Applied Sciences (AUAS)](https://www.amsterdamuas.com/), Faculty of Digital Media and Creative Industries, Lectorate of Play & Civic Media +* Mark van der Net，[阿姆斯特丹市政府](https://www.amsterdam.nl/en/) +* Martijn de Waal，[阿姆斯特丹應用科技大學 (AUAS)](https://www.amsterdamuas.com/)，數位媒體與創意產業學院， +戲劇與公民媒體系講師 * Matti Schneider * Mauko Quiroga -* Maurice Hendriks, Gemeente Amsterdam -* Maurits van der Schee, Gemeente Amsterdam -* Mirjam van Tiel, The Foundation for Public Code +* Maurice Hendriks， 阿姆斯特丹市政府 +* Maurits van der Schee，阿姆斯特丹市政府 +* Mirjam van Tiel，Foundation for Public Code * Ngô Ngọc Đức Huy * Paul Keller -* Petteri Kivimäki, [Nordic Institute for Interoperability Solutions (NIIS)](https://niis.org) +* Petteri Kivimäki， [北歐互通性解決方案機構 (NIIS)](https://niis.org) * Sky Bristol -* Tamas Erkelens, Gemeente Amsterdam +* Tamas Erkelens，阿姆斯特丹市政府 * Timo Slinger diff --git a/CC0-1.0.md b/CC0-1.0.md index 7cadbfc4..4029e1ad 100644 --- a/CC0-1.0.md +++ b/CC0-1.0.md @@ -7,12 +7,12 @@ redirect_from: - LICENSE.html --- -# Creative Commons Zero v1.0 Universal +# 創用 CC0 1.0 通用授權 -This license is the legal contract that allows anyone to do anything they like with the content in this entire document. +此授權的法律契約，允許任何人任意使用本文件中的任何內容。 ```text {% include_relative LICENSE %} diff --git a/CHANGELOG.md b/CHANGELOG.md index 8464dc27..71b80820 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,244 +4,248 @@ # script/release-body.sh expects VERSION in the first second-level header # script/update-changelog-date.sh expects DATE-OF-RELEASE and a colon --- -# Version history - -## Version 0.7.1 - -July 31st 2023: 💄 The sixteenth draft change the name of a criterion and clarifies references to code. - -* The criterion "Make the codebase reusable and portable" was renamed from "Create reusable and portable code". -* Added a glossary entry for "Source Code". -* References to "code" which only applied to "source code" now reference "source code" explicitly. -* Clarification of "running code" as "software". -* Minor changes to clarify "code" vs "codebase". -* Simplify guidance to policy makers in Bundle policy and source code. -* Clarify How to test sections of Make the codebase findable and Make the codebase reusable and portable. -* Add a criteria and requirements checklist to the release artifacts. -* Increase automation of the release process. - -## Version 0.7.0 - -May 31st 2023: 📑 the fifteenth draft adds new requirements for documenting review funding and clarifies review process requirement. - -* Add requirement to document who is expected to cover the cost of reviewing contributions. -* Add requirement to have a short description of the codebase. -* Change the focus of contributions adhering to standards to focus on the review of contributions. -* Relaxed MUST requirements to SHOULD in Make the codebase findable. -* Review template now in HTML format. -* Introduction converted to foreword. -* Improved contributing guidelines. -* Improved documentation of scripts. - -## Version 0.6.0 - -April 20th 2023: 🔀 the fourteenth draft adds new requirements for portability and tests and an introduction to each criterion. - -* New requirement in Create reusable and portable code about the development being a collaboration between multiple parties. -* New requirement in Create reusable and portable code about being dependent on a single vendor. -* New requirement in Use continuous integration about publishing results for automated tests. -* Differentiating the two requirements about security to clearly be about providing a method and having documentation about it. -* Rephrased requirements to focus on the codebase rather than contributor behavior. -* Removed the sections Why this is important and What this does not do and replaced with an introduction in each criterion. -* Added general What this does not do section in the introduction of the Standard. -* Added guidance for public policy makers about related policies and license compatibility. -* Added guidance for developers and designers about version controlling files. -* Clarified guidance for developers and designers about prompt responses and search engine optimization. -* Added Further reading about accessibility. -* Aligned criteria URLs with criteria names. -* Improved navigation in the web version. -* Moved tools in Further reading sections to the community implementation guide. -* Moved compliance or certification process to [publiccode.net](https://publiccode.net). -* Change format of the review template to make it easier to update after a new release. -* Improved the text on the landing page and added links to related resources. -* Added spell checker automated test. -* Made minor changes to text for clarity and consistency. -* Moved SPDX headers to yaml header. - -## Version 0.5.0 - -January 25th 2023: 🎨 the thirteenth draft focuses on documenting style guidelines. - -* Adjust the coding style requirement to focus on the codebase using a style guide rather than contributor behavior. -* Moved requirement for codebase names to Make the codebase findable from Use plain English. -* Moved requirement about testing the code by using examples to Use continuous integration from Document the code. -* Split requirement about machine testable standards to clarify that open is more important than testable. -* Adjust how to test findability requirements to be less reliant on search engine algorithms. -* Made minor changes to text for clarity and consistency. - -## Version 0.4.1 - -December 5th 2022: 📝 the twelfth draft clarifies document maturity. - -* Document maturity focuses on whether or not versions of the codebase are ready to use. -* Document maturity no longer requires specific labels for codebases that are not ready to use. -* Audit flow image now generated from an easier to translate format. -* Improved guidance on How to test. -* Add publiccode.yml file. -* Add review template. -* Consistently link glossary terms. -* Add practices and standards to follow in CONTRIBUTING. -* Add Matti Schneider to Authors. -* Add remaining SPDX headers to files. -* Made additional minor changes to text for clarity. -* Some hyperlinks updated. -* Moved examples to the [Community implementation guide](https://publiccodenet.github.io/community-implementation-guide-standard/). - -## Version 0.4.0 - -September 7th 2022: 🔭 the eleventh draft adds a new findability criterion. - -* Introduce new criterion: Make the codebase findable. -* Improve How to test section for most criteria. -* New requirement in Welcome contributors about publishing activity statistics. -* Removed redundant requirement about portable and reusable code. -* Expand open license definition to include both OSI and FSF approved licenses. -* Rephrase MAY requirements to use the keyword OPTIONAL for clarity. -* Expressed intent that the Standard for Public Code should meet its own requirements where applicable and added assessment. -* Add SPDX license identifiers to files. -* Introduced new Code of Conduct. -* Clarify distinction between source code and policy text. -* Restructuring of requirements with bullet point lists. -* Acknowledge the importance of codebase modularity for reuse. -* Move requirements related to Findability to the new criterion. -* Clarify the role of non-open standards when used in a codebase. -* Additional guidance about build-time and runtime dependencies. -* Added roadmap for the development of the Standard for Public Code. -* Update structure of Authors file. -* Add Audrey Tang to Authors. -* Added a list of criteria to the print edition. -* Clarify what the standard means with policymakers, managers, developers and designers. -* Made additional minor changes to text for clarity. -* Some hyperlinks updated. - -## Version 0.3.0 - -May 23rd 2022: 🗎 the tenth draft strengthens documentation and localization. - -* Requirement for localization made explicit in Create reusable and portable code. -* Documentation of governance changed from a SHOULD to a MUST. -* Replace the very subjective (and hard to test) "contributions MUST be small" with requirement to document expectation in contributing guidelines and focus on a single issue. -* Community translations now linked in the footer. -* Revert "Replace BPMN svg with Mermaid flowchart". -* Many minor clarifications to language and sentences made more simple. -* Some hyperlinks updated. - -## Version 0.2.3 - -March 15th 2022: 📜 the ninth draft allows English summaries for policy lacking an official translation. - -* Relax the criterion Use plain English by adding a new requirement allows bundled policy not available in English to have an accompanying summary in English instead of translating the full text. -* Similarly, allow for English summaries for policies not available in English in Bundle policy and code. -* Clarify that term 'policy' includes processes which impact development and deployment in Bundle policy and code. -* Emphasize reusability also on parts of the solutions in Create reusable and portable code. -* Expand guidance to Developers and designers in Create reusable and portable code about deploying to proprietary platforms. -* Add nuance to use of non-English terms in what management need to do in Use plain English. -* Change the pull request process diagram to use Mermaid instead of BPMN to make [community translations](https://github.com/publiccodenet/community-translations-standard) easier. -* Added Maurice Hendriks to AUTHORS. -* Added OpenApi Specification to further reading. -* Made the attributions in further reading sections clearer. -* Made additional minor changes to text for clarity. - -## Version 0.2.2 - -November 29th 2021: 🏛 the eighth draft recognizes that policy which executes as code may not be in English. - -* Document exception to "All code MUST be in English" where policy is interpreted as code. -* Add MAY requirement regarding committer email addresses in Maintain version control. -* Expand guidance to Policy Makers in Bundle policy and code. -* Expand guidance to Developers and designers in Use a coherent style. -* Add "Different contexts" to glossary. -* Add Mauko Quiroga and Charlotte Heikendorf to AUTHORS. -* Add Digital Public Goods approval badge. -* Added "next" and "previous" links to criteria pages of web version. -* Add Open Standards principles to further reading. -* Add Definition of plain language to further reading. -* Move the Semantic Versioning Specification further reading reference. -* Clarify that publiccode.yml is one example of a machine-readable metadata description. -* Changed "your codebase" and "your organization" to be less possessive. -* Made additional minor changes to text for clarity. -* Add instructions for creating a print version. - -## Version 0.2.1 - -March 1st 2021: 🧽 the seventh draft has minor cleaning up after version 0.2.0. - -* New SHOULD requirement on using a distributed version control system and why distributed is important. -* Feedback requirements for rejected contributions are more strict than accepted ones. -* Specify that copyright and license notices should also be machine-readable. -* Advice on how to test that notices be machine-readable. -* Clarify guidance for rolling releases. -* Clear up definition of version control in glossary. -* Add further reading encouraging contribution, SPDX, Git and reviewing contributions. -* Add links to videos about the concept of public code. -* Update BPMN link. -* Reduce link duplication. -* Add Alba Roza and Ngô Ngọc Đức Huy to authors. -* Made additional minor changes to text for clarity. - -## Version 0.2.0 - -October 26th 2020: 🎊 the sixth draft splits a requirement and adds clarity. - -* Split "Welcome contributions" criterion into "Make contributing easy" and "Welcome contributors". -* Rename criterion "Pay attention to codebase maturity" to "Document codebase maturity". -* Changed MUST to SHOULD for requirement of codebase in use by multiple parties. -* Add MUST NOT requirement regarding copyright assignment. -* Clarify role of configuration in reusable code requirement. -* Glossary additions: continuous integration, policy, repository, and version control. -* Replace references to 'cities' with 'public organizations'. -* Clarify aspects of sensitive code by separating contributor and reviewer requirements into separate items. -* Expand further reading, and guidance to policy makers, developers and designers. -* Add Felix Faassen and Arnout Engelen to authors. -* Made additional minor changes to text for clarity. - -## Version 0.1.4 - -November 27th 2019: 🧹 the fifth draft consists mostly of additional minor fixes. - -* Linked License.md file. -* Add Sky Bristol, Marcus Klaas de Vries, and Jan Ainali to authors. -* Made punctuation more consistent, especially for bullet lists. -* Made some minor changes to text for clarity. - -## Version 0.1.3 - -October 8th 2019: 🍂 the fourth draft only patches and fixes minor things for the autumn cleaning - -* Renamed continuous delivery to continuous integration. -* Referencing accessibility guidelines in the language standard. -* A bunch of style and consistency fixes. - -## Version 0.1.2 - -August 22th 2019: 🌠 the third draft focuses on better text and takes community input - -* With some great new contributors comes a fresh author list. -* All links are now HTTPS. -* General proofreading, wording clarifications, and smashed typos. -* Updated criteria: - * Requirement for reuse in different contexts - * Recommendation for explicit versioning - * Recommendation for multi party development - * Recommendation for license headers in files - * Recommendation for vulnerability reporting - * Recommendation for explicit documentation of governance - -## Version 0.1.1 - -May 9th 2019: 🤔 the second draft fixes a few basic oversights and fixes a lot of typos - -* Removed references to the Foundation for Public Code, we're going to have to change the name in becoming an association. -* Updated the introduction. -* Updated the glossary. -* Added the code of conduct. -* We've recommended using the publiccode.yml standard for easier reuse. - -## Version 0.1.0 - -April 16th 2019: 🎉 the first draft is ready, it is all brand new and has snazzy new ideas in it - -* 14 criteria with their requirements and how to operationalize them. -* An introduction with a high level background, what this standard is, and how the Foundation for Public Code will use it. - -This first version was produced together with the Amsterdam University of Applied Sciences and the City of Amsterdam as a part of the [Smart Cities? Public Code! project](https://smartcities.publiccode.net/). + +# 版本歷史 + +## 0.7.1 版 + +2023/07/31: 💄 第十六版草稿修改準則名稱，並釐清程式 code 的稱呼。 + +* 〈程式碼要可重複使用且可攜〉準則改名為〈程式基底要可重複使用且可移植〉。 +* 新增詞彙條目「原始碼」。 +* 對於只適用於「原始碼」意義的「程式 (code)」，現在明確以「原始碼」稱呼。 +* 將「運作的程式碼」釐清稱為「軟體」。 +* 細微修改以清楚區分「程式碼」與「程式基底」。 +* 簡化給政策制定者在〈政策與原始碼要合捆〉中的指引。 +* 釐清〈程式基底可查詢得到〉與〈程式基底要可重複使用且可移植〉的「測試方式」小節。 +* 在發行成品前的要求中，加入準則與需求規定檢查清單。 +* 提升發行流程的自動化程度。 + +## 0.7.0 版 + +2023年5月31日：📑第十五版新增紀錄募資審查的新規定，並釐清審查流程規定。 + +* 新增規定，記錄預期由何者負擔審核貢獻內容所需的開銷費用。 +* 新增規定，程式基底必須要有簡短說明。 +* 原先專注在貢獻內容是否遵循標準，現在則改為注重貢獻內容的審查。 +* 將〈程式基底可查詢得到〉中許多「必須」等級的規定，調降為「應該」等級。 +* 審查範本現在有 HTML 格式。 +* 「前言」轉換為「序文」。 +* 改善貢獻指引。 +* 改善命令稿文件紀錄。 + +## 0.6.0 版 + +2023年4月20日：🔀第十四版草稿新增可移植性與測試的規定，並且每個準則都有一段前言。 + +* 新增規定，在〈程式碼要可重複使用且可攜〉加入多方協作開發的內容。 +* 新增規定，在〈程式碼要可重複使用且可攜〉中加入依賴單一供應商的內容。 +* 新增規定，在〈使用持續整合〉中加入要發布自動化測試結果的內容。 +* 對安全性區分出兩項規定，一是要有提供方法，另一個是要有文件紀錄。 +* 重新撰寫規定，將焦點放在程式基底，而非貢獻者行為。 +* 移除「此措施辦不到的事」以及「此措施為何重要」兩個小節，改換成在每項準則中加入前言。 +* 在本標準前言中，加入通用的「此措施辦不到的事」小節。 +* 為政策制定者加入相關政策與授權相容性的指引。 +* 為開發人員與設計師新增檔案要有版本控制的相關指引。 +* 為開發人員與設計師釐清有關快速回應，以及搜尋引擎最佳化的內容。 +* 新增可近用性無障礙環境的「延伸閱讀」內容。 +* 將各準則的連結與其名稱連動。 +* 改善網頁版的導覽功能。 +* 已將「延伸閱讀」小節的工具移到社群實踐指引。 +* 將標準依循或認證相關流程移到 [publiccode.net](https://publiccode.net)。 +* 變更審查範本格式，讓範本在發行新版後更容易更新。 +* 改善著陸引導頁文字，加入相關資源的連結。 +* 新增拼字檢查自動化測試。 +* 微調文字，讓內容更明確與一致。 +* 將 SPDX 標頭換成 yaml 標頭。 + +## 0.5.0 版 + +2023年1月25日：🎨第十三版草稿焦點著重在文件紀錄風格指引。 + +* 調整程式碼撰寫風格要求，專注於程式基底上，而非貢獻者行為。 +* 將程式基底名稱規定，從〈使用白話的英文〉移到〈程式基底可查詢得到〉。 +* 將測試程式碼的規定，從〈程式碼要有文件〉移到〈使用持續整合〉。 +* 劃分機器可讀的測試標準規定，指明程式碼的開放性比可測試性更重要。 +* 調整可查找性的測試規定，降低對搜尋引擎演算法的依賴。 +* 微調文字，讓內容更明確與一致。 + +## 0.4.1 版 + +2022年12月5日：📝第十二版草稿指出要以文件記錄成熟度。 + +* 寫下成熟度著重於程式基底是否已經可供使用，更甚於版本編號。 +* 寫下成熟度不再需要為尚未準備好可供使用的程式基底加上特定標籤。 +* 稽核流程圖現在以更容易轉譯的格式生成。 +* 改善「測試方式」指引。 +* 新增 publiccode.yml 檔案。 +* 新增審查範本。 +* 一致性連結詞彙表。 +* 在「CONTRIBUTING」中加入要遵循的實務與標準。 +* 將 Matti Schneider 加入作者群。 +* 將剩餘 SPDX 標頭加入檔案中。 +* 再稍微修改些文字，讓文字更明確。 +* 更新部分超連結。 +* 將範例移動到《[社群實踐指 +引](https://publiccodenet.github.io/community-implementation-guide-standard/)》。 + +## 0.4.0 版 + +2022年9月7日：🔭第十一版草稿新增可查找性準則。 + +* 導入新準則：程式基底可查詢得到。 +* 改善多數準則的「測試方式」小節。 +* 在〈歡迎貢獻者〉中加入發布活動統計的新規定。 +* 移除可重複使用與移植的程式碼中多餘的規定。 +* 在開放授權的定義中，加入 OSI 與 FSF 所批准的授權。 +* 重新編寫「得以」等級的相關規定，加入使用「可選擇」這個關鍵字，讓規定更明確。 +* 表達《公共程式標準》應該盡可能符合其自身規定的立場，並加入評估措施。 +* 將 SPDX 授權識別碼加入檔案中。 +* 導入新的行為守則。 +* 解釋原始碼與政策內文的差異。 +* 將規定重新調整為項目要點清單格式。 +* 告知程式基底成熟度對於重複使用時的重要性。 +* 將可查找性相關規定移動到新準則中。 +* 釐清非開放標準在程式基底中的角色。 +* 加入組建日期與執行時期依賴項目的額外指引。 +* 新增《公共程式標準》的發展路線圖。 +* 更新 Authors 檔案的結構。 +* 將唐鳳加入作者群。 +* 將準則列表加到印刷版本中。 +* 釐清標準對於政策制定者、管理人員、開發人員與設計師等不同身分間的意義。 +* 再稍微修改些文字，讓文字更明確。 +* 更新部分超連結。 + +## 0.3.0 版 + +2022年5月23日：🗎第十版草稿加強文件紀錄與在地化內容。 + +* 在〈程式碼要可重複使用且可攜〉中定下明確的在地化規定。 +* 以文件記錄治理方式的規定，從「應該」等級調升為「必須」。 +* 在貢獻指引中，將非常主觀（且難以驗證）的「貢獻內容『必須』小」的規定，改為必須紀錄貢獻所要完成的期待，並一次專注在單一議題上。 +* 社群翻譯連結現在已放到頁尾中。 +* 還原「用 Mermaid 流程圖取代業務流程 BPMN svg」。 +* 細微調整用詞，讓句子更簡單。 +* 更新部分超連結。 + +## 0.2.3 版 + +2022年3月15日：📜第九版草稿允許缺少官方翻譯的政策，改為提供政策的英文版摘要。 + +* 放寬〈使用白話的英文〉準則，加入新規定，允許合捆的政策內文如果沒有英文版，只需要加入英文版摘要，而不用翻譯全文。 +* 同樣地，在〈政策與原始碼要合捆〉中，沒有英文版的政策內文可允許提供英文版摘要。 +* 釐清〈政策與原始碼要合捆〉中，「政策」包含能影響開發與部署的流程。 +* 在〈程式碼要可重複使用且可攜〉中強調解決方案部分內容的可重複使用性。 +* 將〈程式碼要可重複使用且可攜〉當中的開發人員與設計師指引，加入部署到專有平台上的內容。 +* 在〈使用白話的英文〉中，加入管理層在面對非英語詞彙時需要做的事的提點。 +* 變更拉取請求流程圖，從業務流程 BPMN 改用 Mermaid，來讓[社群翻 +譯](https://github.com/publiccodenet/community-translations-standard)更容易。 +* 將 Maurice Hendriks 加入作者群。 +* 將「OpenApi 規格」加入延伸閱讀。 +* 將延伸閱讀小節的特性變得更明確。 +* 再稍微修改些文字，讓文字更明確。 + +## 0.2.2 版 + +2021年11月29日：🏛第八版草稿認知程式碼所執行的政策，不一定是英文。 + +* 在「所有程式碼都必須使用英語編寫」規定中，雖然政策也算是一種程式 (code)，但可以保有例外。 +* 在〈維護版本控制〉中，新增與送交者電子郵件相關的「得以」規定。 +* 將政策制定者加入〈政策與原始碼要合捆〉指引中。 +* 將開發人員與設計師加入「風格要前後一致」指引中。 +* 新增「不同情境」到詞彙表中。 +* 將 Mauko Quiroga 與 Charlotte Heikendorf 加入 AUTHORS。 +* 新增「數位公共財」認可標章。 +* 為「準則」頁面網頁版加入「上一頁」與「下一頁」連結。 +* 將「開放標準」原則加入延伸閱讀。 +* 將「白話語言定義」加入延伸閱讀。 +* 將「語意化版本編號規範」移動為延伸閱讀參考內容。 +* 指出 publiccode.yml 是機器可讀中介資料說明的範例之一。 +* 將「您的程式基底」與「您的組織單位」改為較不具有所有格的寫法。 +* 再稍微修改些文字，讓文字更明確。 +* 新增印刷版的製作指示。 + +## 0.2.1 版 + +2021年3月1日：🧽第七版草稿是 0.2.0 版後的些微清理改善。 + +* 新增使用分散式版本控制系統的相關「應該」規定，並解釋分散式的重要性。 +* 針對未被採用的貢獻需要給予回饋，規定要比被接受的貢獻更加嚴格。 +* 明確指出著作權與授權聲明也應該要機器可讀。 +* 聲明是否為機器可讀的測試方式建議。 +* 釐清滾動發行的指引。 +* 釐清詞彙表中「版本控制」的定義。 +* 新增鼓勵貢獻、SPDX、Git 以及審查貢獻等的延伸閱讀項目。 +* 新增有關公共程式概念的影片連結。 +* 更新業務流程 BPMN 連結。 +* 減少重複連結。 +* 將 Alba Roza 與 Ngô Ngọc Đức Huy 加入作者群。 +* 再稍微修改些文字，讓文字更明確。 + +## 0.2.0 版 + +2020年10月26日：🎊第六版草稿拆分出一項新規定並且釐清內容。 + +* 將〈歡迎貢獻〉準則拆分為〈貢獻要容易〉以及〈歡迎貢獻者〉。 +* 將〈注意程式基底成熟度〉準則改名為〈記錄程式基底成熟度〉。 +* 針對多方使用的程式基底，將「必須」等級規定調降為「應該」。 +* 針對著作權轉讓，新增「禁止」規定。 +* 在可重複使用程式碼的規定中，釐清組態設定的角色。 +* 新增詞彙：持續整合、政策、儲存庫、版本控制等。 +* 將「城市」替換成「公家機關」。 +* 將貢獻者與審查人員規定分開為不同項目，以釐清程式碼中較敏感性的層面。 +* 將政策制定者、開發人員與設計師加入延伸閱讀與指引中。 +* 將 Felix Faassen 與 Arnout Engelen 加入作者群。 +* 再稍微修改些文字，讓文字更明確。 + +## 0.1.4 版 + +2019年11月27日：🧹第五版草稿主要是一些細部修正。 + +* 連結 License.md 檔案。 +* 將 Sky Bristol、Marcus Klaas de Vries 與 Jan Ainali 加入作者群。 +* 讓標點符號使用更一致，特別是項目符號列表。 +* 細部調整文字，讓內容更明確。 + +## 0.1.3 版 + +2019年10月8日：🍂第四版草稿僅針對秋季所作的清理修正一些小地方 + +* 將「持續交付」改名為「持續整合」。 +* 在語言標準中引用無障礙指導原則。 +* 改善一些樣式，與一致性修正。 + +## 0.1.2 版 + +2019年8月22日：🌠第三版草稿專注在提升文字品質，並且納入社群意見 + +* 有好幾位很棒的新貢獻者加入我們的作者群名單，讓氣象一新。 +* 所有連結都是 HTTPS。 +* 一般校對、釐清用字淺詞、修正拼字錯誤等。 +* 更新準則： + * 在不同情境背景下重複使用的規定 + * 明確的版本控制建議 + * 多方部署的建議 + * 檔案授權標頭的建議 + * 漏洞回報的建議 + * 明確以文件記錄治理方式的建議 + +## 0.1.1 版 + +2019年5月9日：🤔第二版草稿修正一些基本的疏漏，以及許多拼字錯誤 + +* 移除出現「Foundation for Public Code」的地方，我們之後可能必須改名才能成為協會。 +* 更新簡介。 +* 更新詞彙表。 +* 新增行為守則。 +* 我們建議使用 publiccode.yml 標準，方便重複使用。 + +## 0.1.0 版 + +2019年4月16日：🎉初版草稿已準備就緒，全新內容，而且有許多有趣的新穎理念 + +* 14 項準則，有各自的規定，以及相關的實施方式。 +* 精要的背景介紹，例如本標準是什麼，以及 Foundation for Public Code 如何使用此標準。 + +最初的版本是由阿姆斯特丹應用科學大學、阿姆斯特丹市政府，以及本基金會合作撰寫，取自 [Smart Cities? Public Code! 專 +案](https://smartcities.publiccode.net/) 的部分內容。 diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index b63243fd..bd491188 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -1,15 +1,14 @@ -# Code of Conduct +# 行為守則 -Many community members are from civic or professional environments with behavioral codes yet some individuals are not. -This document expresses expectations of all community members and all interactions regardless of communication channel. +社群很多成員來自有行為守則的公民社會或專業背景，但有些人並非如此。本文件表達基金會對於所有社群成員，以及所有互動間的期望，無論互動是透過何種溝通管道。 -Be here to collaborate. +來到這裡來是為了協作。 -Be considerate, respectful, and patient. +請對彼此體貼、尊重，以及有耐心。 -Strive to be as constructive as possible. +努力做出有建設性的行為。 -To raise a concern, please email directors@publiccode.net. +若有問題需要提出，請寄送電子郵件到 directors@publiccode.net。 diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 07c6fbab..fb7c7b5e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,103 +1,100 @@ -# Contributing to this standard +# 貢獻此標準 -🙇‍♀️ Thank you for contributing! +🙇‍♀️ 感謝您的貢獻！ -We understand that a standard like this can only be set in collaboration with as many public technologists, policy makers and interested folk as possible. -Thus we appreciate your input, enjoy feedback and welcome improvements to this project and are very open to collaboration. +我們理解這樣的標準，只有在盡可能與公共技術人員、政策制定者，以及有興趣的人士協作下才能完成。因此，我們很感謝您的意見，樂意得到回饋，以及歡迎提供改善此專案的建議。我 +們非常開放任何合作的機會。 -We love issues and pull requests from everyone. -If you're not comfortable with GitHub, you can email use your feedback at . +我們歡迎每個人提出的議題，以及拉取請求。如果您不大習慣 GitHub ，也歡迎將意見回饋用電子郵件寄送到 +[info@publiccode.net](mailto:info@publiccode.net)。 -## Problems, suggestions and questions in issues +## 問題、建議與議題等 -A high-level overview of the development that we already have sketched out can be seen in the [roadmap](/docs/roadmap.md). -Please help development by reporting problems, suggesting changes and asking questions. -To do this, you can [create a GitHub issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue) for this project in the [GitHub Issues for the Standard for Public Code](https://github.com/publiccodenet/standard/issues). +在[發展路線圖](/docs/roadmap.md)中可查看我們勾勒的精要概覽。歡迎回報問題、建議修改，以及發問等，來協助發展。您可以到 [Standard +for Public Code 的 GitHub +Issue](https://github.com/publiccodenet/standard/issues) 頁面中，為本專案[提出 GitHub 議 +題](https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue)。 -Or, sign up to the [mailing list](https://lists.publiccode.net/mailman/postorius/lists/standard.lists.publiccode.net/) and send an email to -[standard@lists.publiccode.net](mailto:standard@lists.publiccode.net). +或者，註冊加入[郵遞論壇列 +表](https://lists.publiccode.net/mailman/postorius/lists/standard.lists.publiccode.net/)， +並寄送電子郵件到[standard@lists.publiccode.net](mailto:standard@lists.publiccode.net)。 -You don't need to change any of our code or documentation to be a contributor! +您不一定要修改我們的程式碼或文件，也能成為貢獻者！ -## Documentation and code in pull requests +## 為文件與程式碼提出拉取請求 -If you want to add to the documentation or code of one of our projects you should make a pull request. +如果您想要在我們的專案中，為文件或程式碼加入新內容，您應該提出拉取請求 (Pull Request，亦可簡稱 PR)。 -If you never used GitHub, get up to speed with [Understanding the GitHub flow](https://docs.github.com/en/get-started/quickstart/github-flow) or follow one of the great free interactive courses in [GitHub Skills](https://skills.github.com/) on working with GitHub and working with MarkDown, the syntax this project's documentation is in. +若您從未使用過 GitHub，歡迎先[認識 GitHub 作業流 +程](https://docs.github.com/en/get-started/quickstart/github-flow)，或是參加 [GitHub +Skills](https://skills.github.com/) 免費且優質的互動式課程，當中會介紹該如何使用 GitHub 以及 MarkDown 語法。 +MarkDown 是本專案文件所採用的撰寫語法。 -This project is licensed Creative Commons Zero v1.0 Universal, which essentially means that the project, along with your contributions is in the public domain in whatever jurisdiction possible, and everyone can do whatever they want with it. +本專案採用創用CC 0 1.0 通用式公眾領域貢獻宣告給予授權；這本質上代表本專案，以及您所做出的貢獻，在無論何種司法管轄情況下，都屬於公眾領域，也就是任何人都可以 +任意使用。 -### 1. Make your changes +### 1. 作出您的修改 -Contributions should [follow](docs/standard-for-public-code.html) the requirements set out in the criteria of the Standard for Public code itself. -Reviewers will also be ensuring that contributions are aligned with the [values of public code](foreword.md#values-of-public-code). -Furthermore, they will review that the contribution conforms to the [standards](#standards-to-follow) and remains coherent with the overall work. +貢獻內容應該[遵守](docs/standard-for-public-code.html)《公共程式標準》自身所列出的準則規定。審查人員同時也會確保貢獻內容，符合 +[公共程式的價值](foreword.md#values-of-public-code)。此外，他們也會審查貢獻是否遵循[標 +準](#standards-to-follow)，且與整體作品有所連貫。 -This project uses the [GitFlow branching model and workflow](https://nvie.com/posts/a-successful-git-branching-model/). -When you've forked this repository, please make sure to create a feature branch following the GitFlow model. +本專案使用 [GitFlow 分支與工作流程](https://nvie.com/posts/a-successful-git-branching-model/)。 +當您對此儲存庫作分支以後，請務必依照 GitFlow 模型建立新功能分支。 -Add your changes in commits [with a message that explains them](https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message). -If more than one type of change is needed, group logically related changes into separate commits. -For example, white-space fixes could be a separate commit from text content changes. -When adding new files, select file formats that are easily viewed in a `diff`, for instance, `.svg` is preferable to a binary image. -Document choices or decisions you make in the commit message, this will enable everyone to be informed of your choices in the future. +將您所作的變更內容加入送交版次，[並附上內容說 +明](https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message)。如果需要作 +出多種類型的變更，請將相關變更依據邏輯分類，不同類型各自放在不同的送交版次中。例如：修正空白、以及文字內容更動，兩者應該放在不同的送交版次中。當新增檔案時，請選用 +容易以「`diff` 」檢視的檔案格式，如「`.svg` 」格式就勝過二進位影像。在送交版次訊息中，請記錄您所作的選擇與決策，如此未來其他人都能知道您當時的抉 +擇。 -If you are adding code, make sure you've added and updated the relevant documentation and tests before you submit your pull request. -Make sure to write tests that show the behavior of the newly added or changed code. +如果您是要新增程式碼，請確保您有新增與更新相關文件與測試項目，之後再提交您的拉取請求。請務必撰寫可以展示新增或修改後程式碼行為的測試項目。 -#### Applicable policy +#### 適用政策 -Currently, the Standard for Public Code is not implementing any specific public policy. +就目前而言，《公共程式標準》並非在執行任何特定的公共政策。 -#### Style +#### 風格 -The Standard for Public Code aims to [use plain English](criteria/use-plain-english.md) and we have chosen American English for spelling. -Text content should typically follow one line per sentence, with no line-wrap, in order to make `diff` output easier to view. -However, we want to emphasize that it is more important that you make your contribution than worry about spelling and typography. -We will help you get it right in our review process and we also have a separate quality check before [making a new release](docs/releasing.md). +《公共程式標準》目標[使用白話的英語](criteria/use-plain-english.md)，而拼字採用美式英文。文字內容基本上以每句一行為原則，沒有文繞圖 +換行，來讓「`diff`」輸出更容易檢視。然而，我們想要強調更重要的是，您應該專注在貢獻內容上，而不是擔心拼字與排版。我們的審查流程會協助修正這一部分，也會另外再次檢查品質才[推出新發行版本](docs/releasing.md)。 -#### Standards to follow +#### 遵守的標準 -These are the standards that the Standard for Public Code uses. -Please make sure that your contributions are aligned with them so that they can be merged more easily. +這些是《公共程式標準》所採用的標準。請確保您的貢獻內容也遵守這些標準，才會更容易合併。 -* [IETF RFC 2119](https://tools.ietf.org/html/rfc2119) - for requirement level keywords -* [Web Content Accessibility Guidelines 2.1](https://www.w3.org/TR/WCAG21/#readable) - for readability +* [IETF RFC 2119](https://tools.ietf.org/html/rfc2119) - 要求等級關鍵字 +* [網頁內容可近用無障礙指引 2.1](https://www.w3.org/TR/WCAG21/#readable) - 易讀性 -### 2. Pull request +### 2. 拉取請求 -When submitting the pull request, please accompany it with a description of the problem you are trying to solve and the issue number that this pull request fixes. -It is preferred for each pull request to address a single issue where possible. -In some cases a single set of changes may address multiple issues, in which case be sure to list all issue numbers fixed. +當您提出拉取請求時，請隨附描述您想要解決的問題，以及該拉取請求所能修正的議題編號。以一個拉取請求處理單一項議題為佳。若一組變動能同時解決多項議題，則請列出所有能一併 +修正的議題編號。 -### 3. Improve +### 3. 改善 -All contributions have to be reviewed by someone. -The Foundation for Public Code has committed to make sure that maintainers are available to review contributions with an aim to provide feedback within two business days. +所有貢獻都必須接受審查。Foundation for Public Code 致力於確保有維護人員能審查貢獻內容，目標是在兩個工作日內提供意見回饋。 -It could be that your contribution can be merged immediately by a maintainer. -However, usually, a new pull request needs some improvements before it can be merged. -Other contributors (or helper robots) might have feedback. -If this is the case the reviewing maintainer will help you improve your documentation and code. +維護人員有時候可以立即合併您的貢獻內容。不過一般來說，新的拉取請求通常需要再經過改善後，才能夠合併。其他貢獻者（或是輔助用機器人）可能會提供意見回饋。若是如此，負責 +審查您貢獻內容的維護人員，將協助您改善文件與程式碼。 -If your documentation and code have passed human review, it is merged. +一旦您的文件與程式碼通過人工審查，就會合併。 -### 4. Celebrate +### 4. 慶祝 -Your ideas, documentation and code have become an integral part of this project. -You are the open source hero we need! +您的構想、文件與程式碼，已成為本專案的一部份。您就是我們需要的開放原始碼英雄！ -In fact, feel free to open a pull request to add your name to the [`AUTHORS`](AUTHORS.md) file and get eternal attribution. +誠摯歡迎您提出拉取請求，將您的名字加到 [`AUTHORS`](AUTHORS.md) 檔案中，讓您所做的貢獻能銘記在本專案中。 -## Translations in other languages +## 翻譯成其他語言 -While the Standard does not have any official translations, you can help maintain existing and add new [community translations of the Standard](https://github.com/publiccodenet/community-translations-standard). +《公共程式標準》沒有官方版本的翻譯，您仍可以協助本標準維護已有的[社群翻譯](https://github.com/publiccodenet/community-translations-standard)，或是新增翻譯。 -## Releases +## 發行版本 -We have dedicated documentation for creating [new releases](/docs/releasing.md) and [ordering printed standards](/docs/printing.md). +我們有提供[發行新版本](/docs/releasing.md)，與[訂購印刷版標準](/docs/printing.md)的專用詳細文件。 -For more information on how to use and contribute to this project, please read the [`README`](README.md). +若要進一步瞭解如何使用，以及協助貢獻本專案，請參閱 [`README `](README.md)。 diff --git a/Dockerfile b/Dockerfile new file mode 100644 index 00000000..e4552ba3 --- /dev/null +++ b/Dockerfile @@ -0,0 +1,50 @@ +# OS: Ubuntu 22.04 + +FROM ubuntu:22.04 + +WORKDIR /var/www/html + +ENV TZ="Asia/Taipei" + +ENV GIT_COMPLETION_URL="https://raw.githubusercontent.com/git/git/master/contrib/completion/git-completion.bash" + +RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone + +RUN apt-get update && apt-get upgrade -y \ + && apt-get install -y software-properties-common ca-certificates lsb-release apt-transport-https \ + && apt-get install -y zip unzip curl vim wget cron + +RUN add-apt-repository ppa:ondrej/php \ + && apt-get update + +RUN apt-get install -y apache2 apache2-utils + +RUN apt-get install -y git curl autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm6 libgdbm-dev libdb-dev + +RUN curl -fsSL https://github.com/rbenv/rbenv-installer/raw/HEAD/bin/rbenv-installer | bash +RUN echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc +RUN echo 'eval "$(rbenv init -)"' >> ~/.bashrc + +RUN ~/.rbenv/bin/rbenv init - +RUN ~/.rbenv/bin/rbenv install 3.1.3 +RUN ~/.rbenv/bin/rbenv global 3.1.3 + +RUN ~/.rbenv/shims/gem install bundler jekyll + +# 中文語系顯示 +RUN apt-get install -y locales language-pack-zh-hans +RUN locale-gen zh_TW.UTF-8 + +RUN apt-get -y autoremove \ + && apt-get clean \ + && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* +RUN a2enmod rewrite && a2enmod proxy && a2enmod proxy_http + +# 中文語系顯示 +RUN echo "export LANG=zh_TW.UTF-8" >> /root/.bashrc +RUN echo "export LC_ALL=zh_TW.UTF-8" >> /root/.bashrc +RUN echo 'PS1="\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\u@\h:\W\$ "' >> /root/.bashrc + +CMD ["apache2ctl", "-D", "FOREGROUND"] +EXPOSE 80 + diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 3a0cfd12..439a13fc 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -2,17 +2,15 @@ # SPDX-License-Identifier: CC0-1.0 # SPDX-FileCopyrightText: 2019-2022 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS --- -# Governance -This standard lies at the core of the codebase stewardship provided by the [Foundation for Public Code](https://publiccode.net/). -We decide if a codebase is ready for community co-development based on this document. +# 治理方式 -The standard is maintained by Foundation for Public Code staff. +本標準是 [Foundation for Public Code](https://publiccode.net/) 在為程式基底提供督導時的核心。我們依照這份文件來判斷，某個程式基底是否已經準備好讓社群共同參與開發。 -[We welcome contributions, such as suggestions for changes or general feedback, from anyone.](/CONTRIBUTING.md) +這份標準由 Foundation for Public Code 職員負責維護。 -Because of the important role that the Standard for Public Code has in our core process we require the highest standards from the Standard. +[我們歡迎任何人貢獻，例如提供修改建議，或是給予一般意見回饋等。](/CONTRIBUTING.md) -We will try to respond promptly to all pull requests. -The pull request is an opportunity to work together to improve our methods and the Standard. -We may not accept all changes, but we will explain our logic. +由於《公共程式標準》在我們的核心流程中，扮演至關重要的角色，所以我們會以《公共程式標準》的最高標準作要求。 + +我們會努力儘速回覆所有拉取請求。拉取請求使我們有機會一起合作，來改善我們的方法與這份標準。我們有可能不會接受貢獻者提出的所有修改，而我們會解釋背後的邏輯。 diff --git a/README.md b/README.md index b90f5e3c..6d346696 100644 --- a/README.md +++ b/README.md @@ -1,107 +1,114 @@ -# Standard for Public Code +# 公共程式標準 -The Standard for Public Code gives public organizations a model for preparing open source solutions to enable collaborations with similar public organizations in other places. -It includes guidance for policy makers, city administrators, developers and vendors. +《公共程式標準》提供公家機關一套準備開放原始碼解決方案的模型，讓他們能與其他地方相似的公家機關協作。該標準包含給政策制定者、市行政官、開發人員與供應商的指引。 -![version 0.7.1](assets/version-badge.svg) -[![License: CC0-1.0](https://img.shields.io/badge/License-CC0_1.0-lightgrey.svg)](http://creativecommons.org/publicdomain/zero/1.0/) -[![Standard commitment](assets/standard-for-public-code-commitment.svg)](#help-improve-this-standard) +![version 0.7.1](assets/version-badge.svg) [![License: +CC0-1.0](https://img.shields.io/badge/License-CC0_1.0-lightgrey.svg)](http://creativecommons.org/publicdomain/zero/1.0/) +[![標準承 +諾](assets/standard-for-public-code-commitment.svg)](#help-improve-this-standard) [![pages-build-deployment](https://github.com/publiccodenet/standard/actions/workflows/pages/pages-build-deployment/badge.svg)](https://github.com/publiccodenet/standard/actions/workflows/pages/pages-build-deployment) -[![Test](https://github.com/publiccodenet/standard/actions/workflows/test.yml/badge.svg)](https://github.com/publiccodenet/standard/actions/workflows/test.yml) -[![standard main badge](https://publiccodenet.github.io/publiccodenet-url-check/badges/standard.publiccode.net.svg)](https://publiccodenet.github.io/publiccodenet-url-check/standard.publiccode.net-url-check-look.json) -[![standard develop badge](https://publiccodenet.github.io/publiccodenet-url-check/badges/standard.publiccode.net-develop.svg)](https://publiccodenet.github.io/publiccodenet-url-check/standard.publiccode.net-develop-url-check-look.json) +[![測 +試](https://github.com/publiccodenet/standard/actions/workflows/test.yml/badge.svg)](https://github.com/publiccodenet/standard/actions/workflows/test.yml) +[![standard main +badge](https://publiccodenet.github.io/publiccodenet-url-check/badges/standard.publiccode.net.svg)](https://publiccodenet.github.io/publiccodenet-url-check/standard.publiccode.net-url-check-look.json) +[![standard develop +badge](https://publiccodenet.github.io/publiccodenet-url-check/badges/standard.publiccode.net-develop.svg)](https://publiccodenet.github.io/publiccodenet-url-check/standard.publiccode.net-develop-url-check-look.json) -The Standard for Public Code is in a draft format. -We are preparing it for a version 1.0 release. -Currently, we are testing it on a small number of codebases. +《公共程式標準》目前為草稿階段。我們正在準備發行 1.0 版，目前仍在幾個程式基底中作測試。 -## Applying the Standard for Public Code to your codebase +## 將《公共程式標準》套用到您的程式基底 -If you want to apply the Standard for Public Code to your codebase, just go ahead, it's an open standard and free for anyone to use. -If you wish to advertise the codebase community's aspiration to meet the criteria of the Standard for Public Code, link the documentation of this commitment from the [standard-for-public-code-commitment badge](assets/standard-for-public-code-commitment.svg). -To see how ready your codebase is, you can do a quick [eligibility self assessment](https://publiccodenet.github.io/assessment-eligibility) that will give you a rough idea of how much work you may need to do to meet all criteria. +若您想要將《公共程式標準》套用您的程式基底，就請放心去做，因為它是人人都能自由採用的開放標準。如果您希望宣傳程式基底社群達成《公共程式標準》準則要求時的熱誠，請使 +用 [standard-for-public-code-commitment 徽章](assets/standard-for-public-code-commitment.svg)連結到這份承諾文件。若要瞭解您程式基底所達成的程度，可以做[自我資格評估](https://publiccodenet.github.io/assessment-eligibility)；它能幫助您大略瞭解，如果想要滿足所有 +準則，還需要下多少功夫。 -The standard *should* be mostly self-explanatory in how to apply it to your codebase. -If anything in the standard is unclear, we encourage you to open an issue here so that we can help you and anyone else who feels the same as you. -For inspiration, look at the [community built implementation guide](https://publiccodenet.github.io/community-implementation-guide-standard/) which contains examples and other tips. +本標準 *應該* 足以自我解釋要如何套用到您的程式基底中。若標準中有任何不明確的地方，我們鼓勵您在此開立議題，來讓我們能協助您以及其他與您抱持同樣看法的人。如果需要 +一點靈感啟發，請參閱[社群製作的《實踐指引》](https://publiccodenet.github.io/community-implementation-guide-standard/)，其中包 +括範例與其他提示。 -If there are any breaking changes in a new version of the Standard for Public Code, the codebase stewards at the Foundation for Public Code will help any implementers of the standard understand how the gaps can be closed. +若新版的《公共程式標準》有任何導致過去作法不再適用的改動，則 Foundation for Public Code 的程式基底執事人員，會協助標準的實踐者理解該如何 +銜接之間的落差。 -If you want to commit your codebase to become fully compliant to the standard for future certification, please contact us at to initiate a formal [assessment](https://about.publiccode.net/activities/codebase-stewardship/lifecycle-diagram.html#assessment). +若您致力讓您的程式基底完全遵循此標準，並想在未來能取得認證，請寫信與我們聯繫： +[info@publiccode.net](mailto:info@publiccode.net)，以展開正式[評 +估](https://about.publiccode.net/activities/codebase-stewardship/lifecycle-diagram.html#assessment)。 -## Request for contributions +## 徵求貢獻 -We believe public policy and software should be inclusive, usable, open, legible, accountable, accessible and sustainable. -This means we need a new way of designing, developing and procuring both the source code and policy documentation. +我們相信公共政策與公共軟體，應該具備涵容、好用、開放、易懂、課責、近用、永續等特質。這代表我們需要一種新的方式，來設計、開發，以及付出心力育成原始碼和政策文件。 -This standard sets a quality level for codebases that meets the needs of public organizations, institutions and administrations as well as other critical infrastructural services. +本標準為程式基底設立品質檢核水準，使其能滿足公家機關、社會機構、行政單位，以及其他重大基礎設施服務的需求。 -The standard lives at [standard.publiccode.net](https://standard.publiccode.net/). -See [`index.md`](index.md) for an overview of all content. +本標準放在線上：[standard.publiccode.net](https://standard.publiccode.net/)。請參閱 +[`index.md`](index.md) 查看整體內容概覽。 -[![Thumbnail for the video on the Standard for Public Code: a printed version lying on a table between two hands](https://img.youtube.com/vi/QWt6vB-cipE/mqdefault.jpg)](https://www.youtube.com/watch?v=QWt6vB-cipE) +[![《公共程式標準》的影片縮圖：兩隻手中間放著本標準的印刷 +本](https://img.youtube.com/vi/QWt6vB-cipE/mqdefault.jpg)](https://www.youtube.com/watch? +v=QWt6vB-cipE) -[A video introduction to Standard for Public Code](https://www.youtube.com/watch?v=QWt6vB-cipE) from Creative Commons Global Summit 2020 (4:12) on YouTube. +[《公共程式標準》的影片介紹](https://www.youtube.com/watch?v=QWt6vB-cipE)，出自 Creative Commons +Global Summit 2020 (4:12)，放在 YouTube 上。 -## Help improve this standard +## 幫忙改善這份標準 -The Foundation for Public Code is committed to maintaining and developing the Standard for Public Code at a level of quality that meets the standard itself. +Foundation for Public Code 致力於維護與開發《公共程式標準》，且使其同時符合該標準自身的品質水準。 -We are looking for people like you to [contribute](CONTRIBUTING.md) to this project by suggesting improvements and helping develop it. 😊 -Get started by reading our [contributors guide](CONTRIBUTING.md). -Since it is such a core document we will accept contributions when they add significant value. -We've described how we govern the standard in the [governance statement](GOVERNANCE.md). +我們正在尋找像您這樣的人，能對此專案做出[貢獻](CONTRIBUTING.md)，像是建議改善方向，以及協助開發等。😊若要開始，請先參閱我們的[貢獻者指 +引](CONTRIBUTING.md)。由於這是相當核心的文件，我們僅接受能帶來重大價值的貢獻。[治理方式聲明](GOVERNANCE.md)中有說明管理該標準的 +方式。 -Please note that this project is released with a [code of conduct](CODE_OF_CONDUCT.md). -By participating in this project you agree to abide by its terms. -Please be lovely to all other community members. +請注意，本專案配合[行為守則](CODE_OF_CONDUCT.md)一同發行。如果要參加本專案，代表您同意遵守守則。請善待社群的所有其他成員。 -## Preview, build and deploy +## 預覽、建置、部署 -The repository builds to a static site deployed at [standard.publiccode.net](https://standard.publiccode.net/). -It is built with [GitHub pages](https://pages.github.com) and [Jekyll](https://jekyllrb.com/). +儲存庫會建置一個靜態網站，並部署至 [standard.publiccode.net](https://standard.publiccode.net/)。網站採 +用 [GitHub 頁面](https://pages.github.com) 與 [Jekyll](https://jekyllrb.com/) 技術。 -The content is made to be built with [Jekyll](http://jekyllrb.com/), which means you will need ruby and ruby-bundler installed, for example: +網站內容透過 [Jekyll](http://jekyllrb.com/) 技術建置。這代表您需要有安裝 ruby 與 ruby-bundler，例如： ```bash sudo apt-get install -y ruby ruby-bundler ``` -If `ruby` and `bundle` are installed, one can run `bundle install` after which the site can be rendered with the `script/serve.sh` script. +一旦安裝好 `ruby` 與 `bundle` 後，就可以執行 `bundle install`，接著再利用 `script/serve.sh` 命令稿轉譯呈現出網 +站成果。 -### Testing +### 測試 -A variety of test scripts are included. -The script `script/test-all.sh` wraps running of all local tests. +本專案內含許多測試命令稿。其中 `script/test-all.sh` 命令稿則統包執行所有本機測試。 -See the scripts in the [script](https://github.com/publiccodenet/standard/tree/main/script) folder. +請前往 [script](https://github.com/publiccodenet/standard/tree/main/script) 資料夾查看命令 +稿。 -### Generating a PDF of the Standard for Public Code +### 生成《公共程式標準》的 PDF 檔案 -In addition to Jekyll, generating PDFs relies upon [Weasyprint](https://weasyprint.org/) and [QPDF](https://github.com/qpdf/qpdf). -[Pandoc](https://pandoc.org/) can be used to transform PDFs into `.epub`. +除了先前提到的 Jekyll 以外，想生成 PDF 檔，還需要依賴 [Weasyprint](https://weasyprint.org/) 和 +[QPDF](https://github.com/qpdf/qpdf)。[Pandoc](https://pandoc.org/) 則可將 PDF 檔轉換成 +`.epub` 檔。 -To generate these kinds of files, the dependencies should be installed, for example: +若要生成這類檔案，則應該要安裝依賴的軟體項目，例如： ```bash sudo apt-get install -y pandoc qpdf weasyprint ``` -The file `standard-print.html` can be converted to a nice looking PDF, along with the other release files, using: +使用以下命令稿，可以將 `standard-print.html` 檔案轉換成美觀的 PDF 檔，同時包括其他發行用的檔案： ```bash script/pdf.sh ``` -## License +## 授權 -© [The authors and contributors](AUTHORS.md) +© [作者與貢獻者](AUTHORS.md) -The standard is [licensed](LICENSE) under CC 0, which also applies to all illustrations and the documentation. -This means anyone can do anything with it. -If you contribute you also grant these rights to others. -You can read more about how to help in the [contributing guide](CONTRIBUTING.md). +本標準採用 CC0 公眾領域貢獻宣告[給予授權](LICENSE)，該授權範圍涵蓋所有插圖與文件。CC0 代表任何人都能任意使用這些內容。如果您是貢獻者，代表您也將 +這些權利賦予他人。若要進一步瞭解如何協助本專案，請參閱〈[貢獻指引](CONTRIBUTING.md)〉。 + +## 軟體中文化 + +本專案為數位部開放原始碼軟體中文化專案項目之一，其中文化與專案應用可參考 [Wiki](https://github.com/moda-gov-tw/publiccodenet.standard/wiki)。 diff --git a/_config.yml b/_config.yml index ff2d05ed..125f94bd 100644 --- a/_config.yml +++ b/_config.yml @@ -7,7 +7,9 @@ plugins: - jekyll-redirect-from - jekyll-sitemap -remote_theme: publiccodenet/jekyll-theme +repository: publiccodenet/jekyll-theme + +remote_theme: Lin-Chia-Cheng/publiccodenet.jekyll-theme include: - "README.md" - "CONTRIBUTING.md" diff --git a/_site/404.html b/_site/404.html new file mode 100644 index 00000000..ec3c3d96 --- /dev/null +++ b/_site/404.html @@ -0,0 +1,238 @@ + + + + + + + + + Page not found, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

404 找不到網頁

+ +

如果您是手動輸入網址，請確認網址是否正確。

+ +

如果您是複製貼上此網址，請確認是否有複製到完整的網址。

+ +

若網址正確，或您是按下連結或按鈕來的，請寫信給 Foundation for Public Code 員 +工，讓我們協助您，並同時修正我們的錯誤。

+ +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/AUTHORS.html b/_site/AUTHORS.html new file mode 100644 index 00000000..fc407efa --- /dev/null +++ b/_site/AUTHORS.html @@ -0,0 +1,274 @@ + + + + + + + + + 作者群, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

目次

+ + + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

作者群

+ +
    +
  • Alba Roza，Foundation for Public Code
    • +
  • Arnout Engelen
    • +
  • Arnout Schuijff，Foundation for Public Code
    • +
  • 唐鳳，數位發展部
    • +
  • Ben Cerveny，Foundation for Public Code
    • +
  • Bert Spaan
    • +
  • Boris van Hoytema，Foundation for Public Code
    • +
  • Charlotte Heikendorf
    • +
  • Claus Mullie，Foundation for Public Code
    • +
  • David Barberi
    • +
  • Edo Plantinga，Code For NL
    • +
  • Elena Findley-de Regt，Foundation for Public Code
    • +
  • Eric Herman，Foundation for Public Code
    • +
  • Felix Faassen，Foundation for Public Code
    • +
  • Floris Deerenberg
    • +
  • Jan Ainali，Foundation for Public Code
    • +
  • Johan Groenen，Code For NL
    • +
  • Marcus Klaas de Vries
    • +
  • Mark van der Net，阿姆斯特丹市政府
    • +
  • Martijn de Waal，阿姆斯特丹應用科技大學 (AUAS)，數位媒體與創意產業學院， +戲劇與公民媒體系講師
    • +
  • Matti Schneider
    • +
  • Mauko Quiroga
    • +
  • Maurice Hendriks， 阿姆斯特丹市政府
    • +
  • Maurits van der Schee，阿姆斯特丹市政府
    • +
  • Mirjam van Tiel，Foundation for Public Code
    • +
  • Ngô Ngọc Đức Huy
    • +
  • Paul Keller
    • +
  • Petteri Kivimäki， 北歐互通性解決方案機構 (NIIS)
    • +
  • Sky Bristol
    • +
  • Tamas Erkelens，阿姆斯特丹市政府
    • +
  • Timo Slinger
    • +
+ +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/AUTHORS.md b/_site/AUTHORS.md new file mode 100644 index 00000000..54ff8fe5 --- /dev/null +++ b/_site/AUTHORS.md @@ -0,0 +1,35 @@ +# Authors + + + + +* Alba Roza, [The Foundation for Public Code](https://publiccode.net) +* Arnout Engelen +* Arnout Schuijff, The Foundation for Public Code +* Audrey Tang, [digitalminister.tw](https://digitalminister.tw/) +* Ben Cerveny, The Foundation for Public Code +* Bert Spaan +* Boris van Hoytema, The Foundation for Public Code +* Charlotte Heikendorf +* Claus Mullie, The Foundation for Public Code +* David Barberi +* Edo Plantinga, [Code For NL](https://codefor.nl/) +* Elena Findley-de Regt, The Foundation for Public Code +* Eric Herman, The Foundation for Public Code +* Felix Faassen, The Foundation for Public Code +* Floris Deerenberg +* Jan Ainali, The Foundation for Public Code +* Johan Groenen, Code For NL +* Marcus Klaas de Vries +* Mark van der Net, [Gemeente Amsterdam](https://www.amsterdam.nl/en/) +* Martijn de Waal, [Amsterdam University of Applied Sciences (AUAS)](https://www.amsterdamuas.com/), Faculty of Digital Media and Creative Industries, Lectorate of Play & Civic Media +* Mauko Quiroga +* Maurice Hendriks, Gemeente Amsterdam +* Maurits van der Schee, Gemeente Amsterdam +* Mirjam van Tiel, The Foundation for Public Code +* Ngô Ngọc Đức Huy +* Paul Keller +* Petteri Kivimäki, [Nordic Institute for Interoperability Solutions (NIIS)](https://niis.org) +* Sky Bristol +* Tamas Erkelens, Gemeente Amsterdam +* Timo Slinger diff --git a/_site/CC0-1.0.html b/_site/CC0-1.0.html new file mode 100644 index 00000000..1f2996ef --- /dev/null +++ b/_site/CC0-1.0.html @@ -0,0 +1,360 @@ + + + + + + + + + 創用 CC0 1.0 通用授權, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

創用 CC0 1.0 通用授權

+ + + + +

此授權的法律契約，允許任何人任意使用本文件中的任何內容。

+ +
Creative Commons Legal Code
+
+CC0 1.0 Universal
+
+    CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE
+    LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN
+    ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS
+    INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES
+    REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS
+    PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM
+    THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED
+    HEREUNDER.
+
+Statement of Purpose
+
+The laws of most jurisdictions throughout the world automatically confer
+exclusive Copyright and Related Rights (defined below) upon the creator
+and subsequent owner(s) (each and all, an "owner") of an original work of
+authorship and/or a database (each, a "Work").
+
+Certain owners wish to permanently relinquish those rights to a Work for
+the purpose of contributing to a commons of creative, cultural and
+scientific works ("Commons") that the public can reliably and without fear
+of later claims of infringement build upon, modify, incorporate in other
+works, reuse and redistribute as freely as possible in any form whatsoever
+and for any purposes, including without limitation commercial purposes.
+These owners may contribute to the Commons to promote the ideal of a free
+culture and the further production of creative, cultural and scientific
+works, or to gain reputation or greater distribution for their Work in
+part through the use and efforts of others.
+
+For these and/or other purposes and motivations, and without any
+expectation of additional consideration or compensation, the person
+associating CC0 with a Work (the "Affirmer"), to the extent that he or she
+is an owner of Copyright and Related Rights in the Work, voluntarily
+elects to apply CC0 to the Work and publicly distribute the Work under its
+terms, with knowledge of his or her Copyright and Related Rights in the
+Work and the meaning and intended legal effect of CC0 on those rights.
+
+1. Copyright and Related Rights. A Work made available under CC0 may be
+protected by copyright and related or neighboring rights ("Copyright and
+Related Rights"). Copyright and Related Rights include, but are not
+limited to, the following:
+
+  i. the right to reproduce, adapt, distribute, perform, display,
+     communicate, and translate a Work;
+ ii. moral rights retained by the original author(s) and/or performer(s);
+iii. publicity and privacy rights pertaining to a person's image or
+     likeness depicted in a Work;
+ iv. rights protecting against unfair competition in regards to a Work,
+     subject to the limitations in paragraph 4(a), below;
+  v. rights protecting the extraction, dissemination, use and reuse of data
+     in a Work;
+ vi. database rights (such as those arising under Directive 96/9/EC of the
+     European Parliament and of the Council of 11 March 1996 on the legal
+     protection of databases, and under any national implementation
+     thereof, including any amended or successor version of such
+     directive); and
+vii. other similar, equivalent or corresponding rights throughout the
+     world based on applicable law or treaty, and any national
+     implementations thereof.
+
+2. Waiver. To the greatest extent permitted by, but not in contravention
+of, applicable law, Affirmer hereby overtly, fully, permanently,
+irrevocably and unconditionally waives, abandons, and surrenders all of
+Affirmer's Copyright and Related Rights and associated claims and causes
+of action, whether now known or unknown (including existing as well as
+future claims and causes of action), in the Work (i) in all territories
+worldwide, (ii) for the maximum duration provided by applicable law or
+treaty (including future time extensions), (iii) in any current or future
+medium and for any number of copies, and (iv) for any purpose whatsoever,
+including without limitation commercial, advertising or promotional
+purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each
+member of the public at large and to the detriment of Affirmer's heirs and
+successors, fully intending that such Waiver shall not be subject to
+revocation, rescission, cancellation, termination, or any other legal or
+equitable action to disrupt the quiet enjoyment of the Work by the public
+as contemplated by Affirmer's express Statement of Purpose.
+
+3. Public License Fallback. Should any part of the Waiver for any reason
+be judged legally invalid or ineffective under applicable law, then the
+Waiver shall be preserved to the maximum extent permitted taking into
+account Affirmer's express Statement of Purpose. In addition, to the
+extent the Waiver is so judged Affirmer hereby grants to each affected
+person a royalty-free, non transferable, non sublicensable, non exclusive,
+irrevocable and unconditional license to exercise Affirmer's Copyright and
+Related Rights in the Work (i) in all territories worldwide, (ii) for the
+maximum duration provided by applicable law or treaty (including future
+time extensions), (iii) in any current or future medium and for any number
+of copies, and (iv) for any purpose whatsoever, including without
+limitation commercial, advertising or promotional purposes (the
+"License"). The License shall be deemed effective as of the date CC0 was
+applied by Affirmer to the Work. Should any part of the License for any
+reason be judged legally invalid or ineffective under applicable law, such
+partial invalidity or ineffectiveness shall not invalidate the remainder
+of the License, and in such case Affirmer hereby affirms that he or she
+will not (i) exercise any of his or her remaining Copyright and Related
+Rights in the Work or (ii) assert any associated claims and causes of
+action with respect to the Work, in either case contrary to Affirmer's
+express Statement of Purpose.
+
+4. Limitations and Disclaimers.
+
+ a. No trademark or patent rights held by Affirmer are waived, abandoned,
+    surrendered, licensed or otherwise affected by this document.
+ b. Affirmer offers the Work as-is and makes no representations or
+    warranties of any kind concerning the Work, express, implied,
+    statutory or otherwise, including without limitation warranties of
+    title, merchantability, fitness for a particular purpose, non
+    infringement, or the absence of latent or other defects, accuracy, or
+    the present or absence of errors, whether or not discoverable, all to
+    the greatest extent permissible under applicable law.
+ c. Affirmer disclaims responsibility for clearing rights of other persons
+    that may apply to the Work or any use thereof, including without
+    limitation any person's Copyright and Related Rights in the Work.
+    Further, Affirmer disclaims responsibility for obtaining any necessary
+    consents, permissions or other rights required for any use of the
+    Work.
+ d. Affirmer understands and acknowledges that Creative Commons is not a
+    party to this document and has no duty or obligation with respect to
+    this CC0 or use of the Work.
+
+
+ +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/CHANGELOG.html b/_site/CHANGELOG.html new file mode 100644 index 00000000..1c417af0 --- /dev/null +++ b/_site/CHANGELOG.html @@ -0,0 +1,534 @@ + + + + + + + + + 版本歷史, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 0.7.1 版
    2. +
  2. 0.7.0 版
    3. +
  3. 0.6.0 版
    4. +
  4. 0.5.0 版
    5. +
  5. 0.4.1 版
    6. +
  6. 0.4.0 版
    7. +
  7. 0.3.0 版
    8. +
  8. 0.2.3 版
    9. +
  9. 0.2.2 版
    10. +
  10. 0.2.1 版
    11. +
  11. 0.2.0 版
    12. +
  12. 0.1.4 版
    13. +
  13. 0.1.3 版
    14. +
  14. 0.1.2 版
    15. +
  15. 0.1.1 版
    16. +
  16. 0.1.0 版
    17. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

版本歷史

+ +

0.7.1 版

+ +

2023/07/31: 💄 第十六版草稿修改準則名稱，並釐清程式 code 的稱呼。

+ +
    +
  • 〈程式碼要可重複使用且可攜〉準則改名為〈程式基底要可重複使用且可移植〉。
    • +
  • 新增詞彙條目「原始碼」。
    • +
  • 對於只適用於「原始碼」意義的「程式 (code)」，現在明確以「原始碼」稱呼。
    • +
  • 將「運作的程式碼」釐清稱為「軟體」。
    • +
  • 細微修改以清楚區分「程式碼」與「程式基底」。
    • +
  • 簡化給政策制定者在〈政策與原始碼要合捆〉中的指引。
    • +
  • 釐清〈程式基底可查詢得到〉與〈程式基底要可重複使用且可移植〉的「測試方式」小節。
    • +
  • 在發行成品前的要求中，加入準則與需求規定檢查清單。
    • +
  • 提升發行流程的自動化程度。
    • +
+ +

0.7.0 版

+ +

2023年5月31日：📑第十五版新增紀錄募資審查的新規定，並釐清審查流程規定。

+ +
    +
  • 新增規定，記錄預期由何者負擔審核貢獻內容所需的開銷費用。
    • +
  • 新增規定，程式基底必須要有簡短說明。
    • +
  • 原先專注在貢獻內容是否遵循標準，現在則改為注重貢獻內容的審查。
    • +
  • 將〈程式基底可查詢得到〉中許多「必須」等級的規定，調降為「應該」等級。
    • +
  • 審查範本現在有 HTML 格式。
    • +
  • 「前言」轉換為「序文」。
    • +
  • 改善貢獻指引。
    • +
  • 改善命令稿文件紀錄。
    • +
+ +

0.6.0 版

+ +

2023年4月20日：🔀第十四版草稿新增可移植性與測試的規定，並且每個準則都有一段前言。

+ +
    +
  • 新增規定，在〈程式碼要可重複使用且可攜〉加入多方協作開發的內容。
    • +
  • 新增規定，在〈程式碼要可重複使用且可攜〉中加入依賴單一供應商的內容。
    • +
  • 新增規定，在〈使用持續整合〉中加入要發布自動化測試結果的內容。
    • +
  • 對安全性區分出兩項規定，一是要有提供方法，另一個是要有文件紀錄。
    • +
  • 重新撰寫規定，將焦點放在程式基底，而非貢獻者行為。
    • +
  • 移除「此措施辦不到的事」以及「此措施為何重要」兩個小節，改換成在每項準則中加入前言。
    • +
  • 在本標準前言中，加入通用的「此措施辦不到的事」小節。
    • +
  • 為政策制定者加入相關政策與授權相容性的指引。
    • +
  • 為開發人員與設計師新增檔案要有版本控制的相關指引。
    • +
  • 為開發人員與設計師釐清有關快速回應，以及搜尋引擎最佳化的內容。
    • +
  • 新增可近用性無障礙環境的「延伸閱讀」內容。
    • +
  • 將各準則的連結與其名稱連動。
    • +
  • 改善網頁版的導覽功能。
    • +
  • 已將「延伸閱讀」小節的工具移到社群實踐指引。
    • +
  • 將標準依循或認證相關流程移到 publiccode.net。
    • +
  • 變更審查範本格式，讓範本在發行新版後更容易更新。
    • +
  • 改善著陸引導頁文字，加入相關資源的連結。
    • +
  • 新增拼字檢查自動化測試。
    • +
  • 微調文字，讓內容更明確與一致。
    • +
  • 將 SPDX 標頭換成 yaml 標頭。
    • +
+ +

0.5.0 版

+ +

2023年1月25日：🎨第十三版草稿焦點著重在文件紀錄風格指引。

+ +
    +
  • 調整程式碼撰寫風格要求，專注於程式基底上，而非貢獻者行為。
    • +
  • 將程式基底名稱規定，從〈使用白話的英文〉移到〈程式基底可查詢得到〉。
    • +
  • 將測試程式碼的規定，從〈程式碼要有文件〉移到〈使用持續整合〉。
    • +
  • 劃分機器可讀的測試標準規定，指明程式碼的開放性比可測試性更重要。
    • +
  • 調整可查找性的測試規定，降低對搜尋引擎演算法的依賴。
    • +
  • 微調文字，讓內容更明確與一致。
    • +
+ +

0.4.1 版

+ +

2022年12月5日：📝第十二版草稿指出要以文件記錄成熟度。

+ +
    +
  • 寫下成熟度著重於程式基底是否已經可供使用，更甚於版本編號。
    • +
  • 寫下成熟度不再需要為尚未準備好可供使用的程式基底加上特定標籤。
    • +
  • 稽核流程圖現在以更容易轉譯的格式生成。
    • +
  • 改善「測試方式」指引。
    • +
  • 新增 publiccode.yml 檔案。
    • +
  • 新增審查範本。
    • +
  • 一致性連結詞彙表。
    • +
  • 在「CONTRIBUTING」中加入要遵循的實務與標準。
    • +
  • 將 Matti Schneider 加入作者群。
    • +
  • 將剩餘 SPDX 標頭加入檔案中。
    • +
  • 再稍微修改些文字，讓文字更明確。
    • +
  • 更新部分超連結。
    • +
  • 將範例移動到《社群實踐指 +引》。
    • +
+ +

0.4.0 版

+ +

2022年9月7日：🔭第十一版草稿新增可查找性準則。

+ +
    +
  • 導入新準則：程式基底可查詢得到。
    • +
  • 改善多數準則的「測試方式」小節。
    • +
  • 在〈歡迎貢獻者〉中加入發布活動統計的新規定。
    • +
  • 移除可重複使用與移植的程式碼中多餘的規定。
    • +
  • 在開放授權的定義中，加入 OSI 與 FSF 所批准的授權。
    • +
  • 重新編寫「得以」等級的相關規定，加入使用「可選擇」這個關鍵字，讓規定更明確。
    • +
  • 表達《公共程式標準》應該盡可能符合其自身規定的立場，並加入評估措施。
    • +
  • 將 SPDX 授權識別碼加入檔案中。
    • +
  • 導入新的行為守則。
    • +
  • 解釋原始碼與政策內文的差異。
    • +
  • 將規定重新調整為項目要點清單格式。
    • +
  • 告知程式基底成熟度對於重複使用時的重要性。
    • +
  • 將可查找性相關規定移動到新準則中。
    • +
  • 釐清非開放標準在程式基底中的角色。
    • +
  • 加入組建日期與執行時期依賴項目的額外指引。
    • +
  • 新增《公共程式標準》的發展路線圖。
    • +
  • 更新 Authors 檔案的結構。
    • +
  • 將唐鳳加入作者群。
    • +
  • 將準則列表加到印刷版本中。
    • +
  • 釐清標準對於政策制定者、管理人員、開發人員與設計師等不同身分間的意義。
    • +
  • 再稍微修改些文字，讓文字更明確。
    • +
  • 更新部分超連結。
    • +
+ +

0.3.0 版

+ +

2022年5月23日：🗎第十版草稿加強文件紀錄與在地化內容。

+ +
    +
  • 在〈程式碼要可重複使用且可攜〉中定下明確的在地化規定。
    • +
  • 以文件記錄治理方式的規定，從「應該」等級調升為「必須」。
    • +
  • 在貢獻指引中，將非常主觀（且難以驗證）的「貢獻內容『必須』小」的規定，改為必須紀錄貢獻所要完成的期待，並一次專注在單一議題上。
    • +
  • 社群翻譯連結現在已放到頁尾中。
    • +
  • 還原「用 Mermaid 流程圖取代業務流程 BPMN svg」。
    • +
  • 細微調整用詞，讓句子更簡單。
    • +
  • 更新部分超連結。
    • +
+ +

0.2.3 版

+ +

2022年3月15日：📜第九版草稿允許缺少官方翻譯的政策，改為提供政策的英文版摘要。

+ +
    +
  • 放寬〈使用白話的英文〉準則，加入新規定，允許合捆的政策內文如果沒有英文版，只需要加入英文版摘要，而不用翻譯全文。
    • +
  • 同樣地，在〈政策與原始碼要合捆〉中，沒有英文版的政策內文可允許提供英文版摘要。
    • +
  • 釐清〈政策與原始碼要合捆〉中，「政策」包含能影響開發與部署的流程。
    • +
  • 在〈程式碼要可重複使用且可攜〉中強調解決方案部分內容的可重複使用性。
    • +
  • 將〈程式碼要可重複使用且可攜〉當中的開發人員與設計師指引，加入部署到專有平台上的內容。
    • +
  • 在〈使用白話的英文〉中，加入管理層在面對非英語詞彙時需要做的事的提點。
    • +
  • 變更拉取請求流程圖，從業務流程 BPMN 改用 Mermaid，來讓社群翻 +譯更容易。
    • +
  • 將 Maurice Hendriks 加入作者群。
    • +
  • 將「OpenApi 規格」加入延伸閱讀。
    • +
  • 將延伸閱讀小節的特性變得更明確。
    • +
  • 再稍微修改些文字，讓文字更明確。
    • +
+ +

0.2.2 版

+ +

2021年11月29日：🏛第八版草稿認知程式碼所執行的政策，不一定是英文。

+ +
    +
  • 在「所有程式碼都必須使用英語編寫」規定中，雖然政策也算是一種程式 (code)，但可以保有例外。
    • +
  • 在〈維護版本控制〉中，新增與送交者電子郵件相關的「得以」規定。
    • +
  • 將政策制定者加入〈政策與原始碼要合捆〉指引中。
    • +
  • 將開發人員與設計師加入「風格要前後一致」指引中。
    • +
  • 新增「不同情境」到詞彙表中。
    • +
  • 將 Mauko Quiroga 與 Charlotte Heikendorf 加入 AUTHORS。
    • +
  • 新增「數位公共財」認可標章。
    • +
  • 為「準則」頁面網頁版加入「上一頁」與「下一頁」連結。
    • +
  • 將「開放標準」原則加入延伸閱讀。
    • +
  • 將「白話語言定義」加入延伸閱讀。
    • +
  • 將「語意化版本編號規範」移動為延伸閱讀參考內容。
    • +
  • 指出 publiccode.yml 是機器可讀中介資料說明的範例之一。
    • +
  • 將「您的程式基底」與「您的組織單位」改為較不具有所有格的寫法。
    • +
  • 再稍微修改些文字，讓文字更明確。
    • +
  • 新增印刷版的製作指示。
    • +
+ +

0.2.1 版

+ +

2021年3月1日：🧽第七版草稿是 0.2.0 版後的些微清理改善。

+ +
    +
  • 新增使用分散式版本控制系統的相關「應該」規定，並解釋分散式的重要性。
    • +
  • 針對未被採用的貢獻需要給予回饋，規定要比被接受的貢獻更加嚴格。
    • +
  • 明確指出著作權與授權聲明也應該要機器可讀。
    • +
  • 聲明是否為機器可讀的測試方式建議。
    • +
  • 釐清滾動發行的指引。
    • +
  • 釐清詞彙表中「版本控制」的定義。
    • +
  • 新增鼓勵貢獻、SPDX、Git 以及審查貢獻等的延伸閱讀項目。
    • +
  • 新增有關公共程式概念的影片連結。
    • +
  • 更新業務流程 BPMN 連結。
    • +
  • 減少重複連結。
    • +
  • 將 Alba Roza 與 Ngô Ngọc Đức Huy 加入作者群。
    • +
  • 再稍微修改些文字，讓文字更明確。
    • +
+ +

0.2.0 版

+ +

2020年10月26日：🎊第六版草稿拆分出一項新規定並且釐清內容。

+ +
    +
  • 將〈歡迎貢獻〉準則拆分為〈貢獻要容易〉以及〈歡迎貢獻者〉。
    • +
  • 將〈注意程式基底成熟度〉準則改名為〈記錄程式基底成熟度〉。
    • +
  • 針對多方使用的程式基底，將「必須」等級規定調降為「應該」。
    • +
  • 針對著作權轉讓，新增「禁止」規定。
    • +
  • 在可重複使用程式碼的規定中，釐清組態設定的角色。
    • +
  • 新增詞彙：持續整合、政策、儲存庫、版本控制等。
    • +
  • 將「城市」替換成「公家機關」。
    • +
  • 將貢獻者與審查人員規定分開為不同項目，以釐清程式碼中較敏感性的層面。
    • +
  • 將政策制定者、開發人員與設計師加入延伸閱讀與指引中。
    • +
  • 將 Felix Faassen 與 Arnout Engelen 加入作者群。
    • +
  • 再稍微修改些文字，讓文字更明確。
    • +
+ +

0.1.4 版

+ +

2019年11月27日：🧹第五版草稿主要是一些細部修正。

+ +
    +
  • 連結 License.md 檔案。
    • +
  • 將 Sky Bristol、Marcus Klaas de Vries 與 Jan Ainali 加入作者群。
    • +
  • 讓標點符號使用更一致，特別是項目符號列表。
    • +
  • 細部調整文字，讓內容更明確。
    • +
+ +

0.1.3 版

+ +

2019年10月8日：🍂第四版草稿僅針對秋季所作的清理修正一些小地方

+ +
    +
  • 將「持續交付」改名為「持續整合」。
    • +
  • 在語言標準中引用無障礙指導原則。
    • +
  • 改善一些樣式，與一致性修正。
    • +
+ +

0.1.2 版

+ +

2019年8月22日：🌠第三版草稿專注在提升文字品質，並且納入社群意見

+ +
    +
  • 有好幾位很棒的新貢獻者加入我們的作者群名單，讓氣象一新。
    • +
  • 所有連結都是 HTTPS。
    • +
  • 一般校對、釐清用字淺詞、修正拼字錯誤等。
    • +
  • 更新準則： +
      +
    • 在不同情境背景下重複使用的規定
      • +
    • 明確的版本控制建議
      • +
    • 多方部署的建議
      • +
    • 檔案授權標頭的建議
      • +
    • 漏洞回報的建議
      • +
    • 明確以文件記錄治理方式的建議
      • +
    +
    • +
+ +

0.1.1 版

+ +

2019年5月9日：🤔第二版草稿修正一些基本的疏漏，以及許多拼字錯誤

+ +
    +
  • 移除出現「Foundation for Public Code」的地方，我們之後可能必須改名才能成為協會。
    • +
  • 更新簡介。
    • +
  • 更新詞彙表。
    • +
  • 新增行為守則。
    • +
  • 我們建議使用 publiccode.yml 標準，方便重複使用。
    • +
+ +

0.1.0 版

+ +

2019年4月16日：🎉初版草稿已準備就緒，全新內容，而且有許多有趣的新穎理念

+ +
    +
  • 14 項準則，有各自的規定，以及相關的實施方式。
    • +
  • 精要的背景介紹，例如本標準是什麼，以及 Foundation for Public Code 如何使用此標準。
    • +
+ +

最初的版本是由阿姆斯特丹應用科學大學、阿姆斯特丹市政府，以及本基金會合作撰寫，取自 Smart Cities? Public Code! 專 +案 的部分內容。

+ +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/CHANGELOG.md b/_site/CHANGELOG.md new file mode 100644 index 00000000..3fd80eae --- /dev/null +++ b/_site/CHANGELOG.md @@ -0,0 +1,163 @@ +# Version history + + + + +## Version 0.4.0 + +September 7th 2022: 🔭 the eleventh draft adds a new findability criterion. + +* Introduce new criterion: Make the codebase findable. +* Improve How to test section for most criteria. +* New requirement in Welcome contributors about publishing activity statistics. +* Removed redundant requirement about portable and reusable code. +* Expand open license definition to include both OSI and FSF approved licenses. +* Rephrase MAY requirements to use the keyword OPTIONAL for clarity. +* Expressed intent that the Standard for Public Code should meet its own requirements where applicable and added assessment. +* Add SPDX license identifiers to files. +* Introduced new Code of Conduct. +* Clarify distinction between source code and policy text. +* Restructuring of requirements with bullet point lists. +* Acknowledge the importance of codebase modularity for reuse. +* Move requirements related to Findability to the new criterion. +* Clarify the role of non-open standards when used in a codebase. +* Additional guidance about build-time and runtime dependencies. +* Added roadmap for the development of the Standard for Public Code. +* Update structure of Authors file. +* Add Audrey Tang to Authors. +* Added a list of criteria to the print edition. +* Clarify what the standard means with policymakers, managers, developers and designers. +* Made additional minor changes to text for clarity. +* Some hyperlinks updated. + +## Version 0.3.0 + +May 23rd 2022: 🗎 the tenth draft strengthens documentation and localization. + +* Requirement for localization made explicit in Create reusable and portable code. +* Documentation of governance changed from a SHOULD to a MUST. +* Replace the very subjective (and hard to test) "contributions MUST be small" with requirement to document expectation in contributing guidelines and focus on a single issue. +* Community translations now linked in the footer. +* Revert "Replace BPMN svg with Mermaid flowchart". +* Many minor clarifications to language and sentences made more simple. +* Some hyperlinks updated. + +## Version 0.2.3 + +March 15th 2022: 📜 the ninth draft allows English summaries for policy lacking an official translation. + +* Relax the criterion Use plain English by adding a new requirement allows bundled policy not available in English to have an accompanying summary in English instead of translating the full text. +* Similarly, allow for English summaries for policies not available in English in Bundle policy and code. +* Clarify that term 'policy' includes processes which impact development and deployment in Bundle policy and code. +* Emphasize reusability also on parts of the solutions in Create reusable and portable code. +* Expand guidance to Developers and designers in Create reusable and portable code about deploying to proprietary platforms. +* Add nuance to use of non-English terms in what management need to do in Use plain English. +* Change the pull request process diagram to use Mermaid instead of BPMN to make [community translations](https://github.com/publiccodenet/community-translations-standard) easier. +* Added Maurice Hendriks to AUTHORS. +* Added OpenApi Specification to further reading. +* Made the attributions in further reading sections clearer. +* Made additional minor changes to text for clarity. + +## Version 0.2.2 + +November 29th 2021: 🏛 the eighth draft recognizes that policy which executes as code may not be in English. + +* Document exception to "All code MUST be in English" where policy is interpreted as code. +* Add MAY requirement regarding committer email addresses in Maintain version control. +* Expand guidance to Policy Makers in Bundle policy and code. +* Expand guidance to Developers and designers in Use a coherent style. +* Add "Different contexts" to glossary. +* Add Mauko Quiroga and Charlotte Heikendorf to AUTHORS. +* Add Digital Public Goods approval badge. +* Added "next" and "previous" links to criteria pages of web version. +* Add Open Standards principles to further reading. +* Add Definition of plain language to further reading. +* Move the Semantic Versioning Specification further reading reference. +* Clarify that publiccode.yml is one example of a machine-readable metadata description. +* Changed "your codebase" and "your organization" to be less possessive. +* Made additional minor changes to text for clarity. +* Add instructions for creating a print version. + +## Version 0.2.1 + +March 1st 2021: 🧽 the seventh draft has minor cleaning up after version 0.2.0. + +* New SHOULD requirement on using a distributed version control system and why distributed is important. +* Feedback requirements for rejected contributions are more strict than accepted ones. +* Specify that copyright and license notices should also be machine-readable. +* Advice on how to test that notices be machine-readable. +* Clarify guidance for rolling releases. +* Clear up definition of version control in glossary. +* Add further reading encouraging contribution, SPDX, Git and reviewing contributions. +* Add links to videos about the concept of public code. +* Update BPMN link. +* Reduce link duplication. +* Add Alba Roza and Ngô Ngọc Đức Huy to authors. +* Made additional minor changes to text for clarity. + +## Version 0.2.0 + +October 26th 2020: 🎊 the sixth draft splits a requirement and adds clarity. + +* Split "Welcome contributions" criterion into "Make contributing easy" and "Welcome contributors". +* Rename criterion "Pay attention to codebase maturity" to "Document codebase maturity". +* Changed MUST to SHOULD for requirement of codebase in use by multiple parties. +* Add MUST NOT requirement regarding copyright assignment. +* Clarify role of configuration in reusable code requirement. +* Glossary additions: continuous integration, policy, repository, and version control. +* Replace references to 'cities' with 'public organizations'. +* Clarify aspects of sensitive code by separating contributor and reviewer requirements into separate items. +* Expand further reading, and guidance to policy makers, developers and designers. +* Add Felix Faassen and Arnout Engelen to authors. +* Made additional minor changes to text for clarity. + +## Version 0.1.4 + +November 27th 2019: 🧹 the fifth draft consists mostly of additional minor fixes. + +* Linked License.md file. +* Add Sky Bristol, Marcus Klaas de Vries, and Jan Ainali to authors. +* Made punctuation more consistent, especially for bullet lists. +* Made some minor changes to text for clarity. + +## Version 0.1.3 + +October 8th 2019: 🍂 the fourth draft only patches and fixes minor things for the autumn cleaning + +* Renamed continuous delivery to continuous integration. +* Referencing accessibility guidelines in the language standard. +* A bunch of style and consistency fixes. + +## Version 0.1.2 + +August 22th 2019: 🌠 the third draft focuses on better text and takes community input + +* With some great new contributors comes a fresh author list. +* All links are now HTTPS. +* General proofreading, wording clarifications, and smashed typos. +* Updated criteria: + * Requirement for reuse in different contexts + * Recommendation for explicit versioning + * Recommendation for multi party development + * Recommendation for license headers in files + * Recommendation for vulnerability reporting + * Recommendation for explicit documentation of governance + +## Version 0.1.1 + +May 9th 2019: 🤔 the second draft fixes a few basic oversights and fixes a lot of typos + +* Removed references to the Foundation for Public Code, we're going to have to change the name in becoming an association. +* Updated the introduction. +* Updated the glossary. +* Added the code of conduct. +* We've recommended using the publiccode.yml standard for easier reuse. + +## Version 0.1.0 + +April 16th 2019: 🎉 the first draft is ready, it is all brand new and has snazzy new ideas in it + +* 14 criteria with their requirements and how to operationalize them. +* An introduction with a high level background, what this standard is, and how the Foundation for Public Code will use it. + +This first version was produced together with the Amsterdam University of Applied Sciences and the City of Amsterdam as a part of the [Smart Cities? Public Code! project](https://smartcities.publiccode.net/). diff --git a/_site/CODE_OF_CONDUCT.html b/_site/CODE_OF_CONDUCT.html new file mode 100644 index 00000000..05df32e9 --- /dev/null +++ b/_site/CODE_OF_CONDUCT.html @@ -0,0 +1,252 @@ + + + + + + + + + 行為守則, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

目次

+ + + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

行為守則

+ + + + +

社群很多成員來自有行為守則的公民社會或專業背景，但有些人並非如此。本文件表達基金會對於所有社群成員，以及所有互動間的期望，無論互動是透過何種溝通管道。

+ +

來到這裡來是為了協作。

+ +

請對彼此體貼、尊重，以及有耐心。

+ +

努力做出有建設性的行為。

+ +

若有問題需要提出，請寄送電子郵件到 directors@publiccode.net。

+ +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/CODE_OF_CONDUCT.md b/_site/CODE_OF_CONDUCT.md new file mode 100644 index 00000000..bd491188 --- /dev/null +++ b/_site/CODE_OF_CONDUCT.md @@ -0,0 +1,14 @@ +# 行為守則 + + + + +社群很多成員來自有行為守則的公民社會或專業背景，但有些人並非如此。本文件表達基金會對於所有社群成員，以及所有互動間的期望，無論互動是透過何種溝通管道。 + +來到這裡來是為了協作。 + +請對彼此體貼、尊重，以及有耐心。 + +努力做出有建設性的行為。 + +若有問題需要提出，請寄送電子郵件到 directors@publiccode.net。 diff --git a/_site/CONTRIBUTING.html b/_site/CONTRIBUTING.html new file mode 100644 index 00000000..c2dae15c --- /dev/null +++ b/_site/CONTRIBUTING.html @@ -0,0 +1,358 @@ + + + + + + + + + 貢獻此標準, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 問題、建議與議題等
    2. +
  2. 為文件與程式碼提出拉取請求 +
      +
    1. 1. 作出您的修改 +
        +
      1. 適用政策
        2. +
      2. 風格
        3. +
      3. 遵守的標準
        4. +
      +
      2. +
    2. 2. 拉取請求
      3. +
    3. 3. 改善
      4. +
    4. 4. 慶祝
      5. +
    +
    3. +
  3. 翻譯成其他語言
    4. +
  4. 發行版本
    5. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

貢獻此標準

+ + + + +

🙇‍♀️ 感謝您的貢獻！

+ +

我們理解這樣的標準，只有在盡可能與公共技術人員、政策制定者，以及有興趣的人士協作下才能完成。因此，我們很感謝您的意見，樂意得到回饋，以及歡迎提供改善此專案的建議。我 +們非常開放任何合作的機會。

+ +

我們歡迎每個人提出的議題，以及拉取請求。如果您不大習慣 GitHub ，也歡迎將意見回饋用電子郵件寄送到 +info@publiccode.net。

+ +

問題、建議與議題等

+ +

在發展路線圖中可查看我們勾勒的精要概覽。歡迎回報問題、建議修改，以及發問等，來協助發展。您可以到 Standard +for Public Code 的 GitHub +Issue 頁面中，為本專案提出 GitHub 議 +題。

+ +

或者，註冊加入郵遞論壇列 +表， +並寄送電子郵件到standard@lists.publiccode.net。

+ +

您不一定要修改我們的程式碼或文件，也能成為貢獻者！

+ +

為文件與程式碼提出拉取請求

+ +

如果您想要在我們的專案中，為文件或程式碼加入新內容，您應該提出拉取請求 (Pull Request，亦可簡稱 PR)。

+ +

若您從未使用過 GitHub，歡迎先認識 GitHub 作業流 +程，或是參加 GitHub +Skills 免費且優質的互動式課程，當中會介紹該如何使用 GitHub 以及 MarkDown 語法。 +MarkDown 是本專案文件所採用的撰寫語法。

+ +

本專案採用創用CC 0 1.0 通用式公眾領域貢獻宣告給予授權；這本質上代表本專案，以及您所做出的貢獻，在無論何種司法管轄情況下，都屬於公眾領域，也就是任何人都可以 +任意使用。

+ +

1. 作出您的修改

+ +

貢獻內容應該遵守《公共程式標準》自身所列出的準則規定。審查人員同時也會確保貢獻內容，符合 +公共程式的價值。此外，他們也會審查貢獻是否遵循標 +準，且與整體作品有所連貫。

+ +

本專案使用 GitFlow 分支與工作流程。 +當您對此儲存庫作分支以後，請務必依照 GitFlow 模型建立新功能分支。

+ +

將您所作的變更內容加入送交版次，並附上內容說 +明。如果需要作 +出多種類型的變更，請將相關變更依據邏輯分類，不同類型各自放在不同的送交版次中。例如：修正空白、以及文字內容更動，兩者應該放在不同的送交版次中。當新增檔案時，請選用 +容易以「diff 」檢視的檔案格式，如「.svg 」格式就勝過二進位影像。在送交版次訊息中，請記錄您所作的選擇與決策，如此未來其他人都能知道您當時的抉 +擇。

+ +

如果您是要新增程式碼，請確保您有新增與更新相關文件與測試項目，之後再提交您的拉取請求。請務必撰寫可以展示新增或修改後程式碼行為的測試項目。

+ +

適用政策

+ +

就目前而言，《公共程式標準》並非在執行任何特定的公共政策。

+ +

風格

+ +

《公共程式標準》目標使用白話的英語，而拼字採用美式英文。文字內容基本上以每句一行為原則，沒有文繞圖 +換行，來讓「diff」輸出更容易檢視。然而，我們想要強調更重要的是，您應該專注在貢獻內容上，而不是擔心拼字與排版。我們的審查流程會協助修正這一部分，也會另外再次檢查品質才推出新發行版本。

+ +

遵守的標準

+ +

這些是《公共程式標準》所採用的標準。請確保您的貢獻內容也遵守這些標準，才會更容易合併。

+ + + +

2. 拉取請求

+ +

當您提出拉取請求時，請隨附描述您想要解決的問題，以及該拉取請求所能修正的議題編號。以一個拉取請求處理單一項議題為佳。若一組變動能同時解決多項議題，則請列出所有能一併 +修正的議題編號。

+ +

3. 改善

+ +

所有貢獻都必須接受審查。Foundation for Public Code 致力於確保有維護人員能審查貢獻內容，目標是在兩個工作日內提供意見回饋。

+ +

維護人員有時候可以立即合併您的貢獻內容。不過一般來說，新的拉取請求通常需要再經過改善後，才能夠合併。其他貢獻者（或是輔助用機器人）可能會提供意見回饋。若是如此，負責 +審查您貢獻內容的維護人員，將協助您改善文件與程式碼。

+ +

一旦您的文件與程式碼通過人工審查，就會合併。

+ +

4. 慶祝

+ +

您的構想、文件與程式碼，已成為本專案的一部份。您就是我們需要的開放原始碼英雄！

+ +

誠摯歡迎您提出拉取請求，將您的名字加到 AUTHORS 檔案中，讓您所做的貢獻能銘記在本專案中。

+ +

翻譯成其他語言

+ +

《公共程式標準》沒有官方版本的翻譯，您仍可以協助本標準維護已有的社群翻譯，或是新增翻譯。

+ +

發行版本

+ +

我們有提供發行新版本，與訂購印刷版標準的專用詳細文件。

+ +

若要進一步瞭解如何使用，以及協助貢獻本專案，請參閱 README 。

+ +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/CONTRIBUTING.md b/_site/CONTRIBUTING.md new file mode 100644 index 00000000..fb7c7b5e --- /dev/null +++ b/_site/CONTRIBUTING.md @@ -0,0 +1,100 @@ +# 貢獻此標準 + + + + +🙇‍♀️ 感謝您的貢獻！ + +我們理解這樣的標準，只有在盡可能與公共技術人員、政策制定者，以及有興趣的人士協作下才能完成。因此，我們很感謝您的意見，樂意得到回饋，以及歡迎提供改善此專案的建議。我 +們非常開放任何合作的機會。 + +我們歡迎每個人提出的議題，以及拉取請求。如果您不大習慣 GitHub ，也歡迎將意見回饋用電子郵件寄送到 +[info@publiccode.net](mailto:info@publiccode.net)。 + +## 問題、建議與議題等 + +在[發展路線圖](/docs/roadmap.md)中可查看我們勾勒的精要概覽。歡迎回報問題、建議修改，以及發問等，來協助發展。您可以到 [Standard +for Public Code 的 GitHub +Issue](https://github.com/publiccodenet/standard/issues) 頁面中，為本專案[提出 GitHub 議 +題](https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue)。 + +或者，註冊加入[郵遞論壇列 +表](https://lists.publiccode.net/mailman/postorius/lists/standard.lists.publiccode.net/)， +並寄送電子郵件到[standard@lists.publiccode.net](mailto:standard@lists.publiccode.net)。 + +您不一定要修改我們的程式碼或文件，也能成為貢獻者！ + +## 為文件與程式碼提出拉取請求 + +如果您想要在我們的專案中，為文件或程式碼加入新內容，您應該提出拉取請求 (Pull Request，亦可簡稱 PR)。 + +若您從未使用過 GitHub，歡迎先[認識 GitHub 作業流 +程](https://docs.github.com/en/get-started/quickstart/github-flow)，或是參加 [GitHub +Skills](https://skills.github.com/) 免費且優質的互動式課程，當中會介紹該如何使用 GitHub 以及 MarkDown 語法。 +MarkDown 是本專案文件所採用的撰寫語法。 + +本專案採用創用CC 0 1.0 通用式公眾領域貢獻宣告給予授權；這本質上代表本專案，以及您所做出的貢獻，在無論何種司法管轄情況下，都屬於公眾領域，也就是任何人都可以 +任意使用。 + +### 1. 作出您的修改 + +貢獻內容應該[遵守](docs/standard-for-public-code.html)《公共程式標準》自身所列出的準則規定。審查人員同時也會確保貢獻內容，符合 +[公共程式的價值](foreword.md#values-of-public-code)。此外，他們也會審查貢獻是否遵循[標 +準](#standards-to-follow)，且與整體作品有所連貫。 + +本專案使用 [GitFlow 分支與工作流程](https://nvie.com/posts/a-successful-git-branching-model/)。 +當您對此儲存庫作分支以後，請務必依照 GitFlow 模型建立新功能分支。 + +將您所作的變更內容加入送交版次，[並附上內容說 +明](https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message)。如果需要作 +出多種類型的變更，請將相關變更依據邏輯分類，不同類型各自放在不同的送交版次中。例如：修正空白、以及文字內容更動，兩者應該放在不同的送交版次中。當新增檔案時，請選用 +容易以「`diff` 」檢視的檔案格式，如「`.svg` 」格式就勝過二進位影像。在送交版次訊息中，請記錄您所作的選擇與決策，如此未來其他人都能知道您當時的抉 +擇。 + +如果您是要新增程式碼，請確保您有新增與更新相關文件與測試項目，之後再提交您的拉取請求。請務必撰寫可以展示新增或修改後程式碼行為的測試項目。 + +#### 適用政策 + +就目前而言，《公共程式標準》並非在執行任何特定的公共政策。 + +#### 風格 + +《公共程式標準》目標[使用白話的英語](criteria/use-plain-english.md)，而拼字採用美式英文。文字內容基本上以每句一行為原則，沒有文繞圖 +換行，來讓「`diff`」輸出更容易檢視。然而，我們想要強調更重要的是，您應該專注在貢獻內容上，而不是擔心拼字與排版。我們的審查流程會協助修正這一部分，也會另外再次檢查品質才[推出新發行版本](docs/releasing.md)。 + +#### 遵守的標準 + +這些是《公共程式標準》所採用的標準。請確保您的貢獻內容也遵守這些標準，才會更容易合併。 + +* [IETF RFC 2119](https://tools.ietf.org/html/rfc2119) - 要求等級關鍵字 +* [網頁內容可近用無障礙指引 2.1](https://www.w3.org/TR/WCAG21/#readable) - 易讀性 + +### 2. 拉取請求 + +當您提出拉取請求時，請隨附描述您想要解決的問題，以及該拉取請求所能修正的議題編號。以一個拉取請求處理單一項議題為佳。若一組變動能同時解決多項議題，則請列出所有能一併 +修正的議題編號。 + +### 3. 改善 + +所有貢獻都必須接受審查。Foundation for Public Code 致力於確保有維護人員能審查貢獻內容，目標是在兩個工作日內提供意見回饋。 + +維護人員有時候可以立即合併您的貢獻內容。不過一般來說，新的拉取請求通常需要再經過改善後，才能夠合併。其他貢獻者（或是輔助用機器人）可能會提供意見回饋。若是如此，負責 +審查您貢獻內容的維護人員，將協助您改善文件與程式碼。 + +一旦您的文件與程式碼通過人工審查，就會合併。 + +### 4. 慶祝 + +您的構想、文件與程式碼，已成為本專案的一部份。您就是我們需要的開放原始碼英雄！ + +誠摯歡迎您提出拉取請求，將您的名字加到 [`AUTHORS`](AUTHORS.md) 檔案中，讓您所做的貢獻能銘記在本專案中。 + +## 翻譯成其他語言 + +《公共程式標準》沒有官方版本的翻譯，您仍可以協助本標準維護已有的[社群翻譯](https://github.com/publiccodenet/community-translations-standard)，或是新增翻譯。 + +## 發行版本 + +我們有提供[發行新版本](/docs/releasing.md)，與[訂購印刷版標準](/docs/printing.md)的專用詳細文件。 + +若要進一步瞭解如何使用，以及協助貢獻本專案，請參閱 [`README `](README.md)。 diff --git a/_site/Dockerfile b/_site/Dockerfile new file mode 100644 index 00000000..e4552ba3 --- /dev/null +++ b/_site/Dockerfile @@ -0,0 +1,50 @@ +# OS: Ubuntu 22.04 + +FROM ubuntu:22.04 + +WORKDIR /var/www/html + +ENV TZ="Asia/Taipei" + +ENV GIT_COMPLETION_URL="https://raw.githubusercontent.com/git/git/master/contrib/completion/git-completion.bash" + +RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone + +RUN apt-get update && apt-get upgrade -y \ + && apt-get install -y software-properties-common ca-certificates lsb-release apt-transport-https \ + && apt-get install -y zip unzip curl vim wget cron + +RUN add-apt-repository ppa:ondrej/php \ + && apt-get update + +RUN apt-get install -y apache2 apache2-utils + +RUN apt-get install -y git curl autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm6 libgdbm-dev libdb-dev + +RUN curl -fsSL https://github.com/rbenv/rbenv-installer/raw/HEAD/bin/rbenv-installer | bash +RUN echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc +RUN echo 'eval "$(rbenv init -)"' >> ~/.bashrc + +RUN ~/.rbenv/bin/rbenv init - +RUN ~/.rbenv/bin/rbenv install 3.1.3 +RUN ~/.rbenv/bin/rbenv global 3.1.3 + +RUN ~/.rbenv/shims/gem install bundler jekyll + +# 中文語系顯示 +RUN apt-get install -y locales language-pack-zh-hans +RUN locale-gen zh_TW.UTF-8 + +RUN apt-get -y autoremove \ + && apt-get clean \ + && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* +RUN a2enmod rewrite && a2enmod proxy && a2enmod proxy_http + +# 中文語系顯示 +RUN echo "export LANG=zh_TW.UTF-8" >> /root/.bashrc +RUN echo "export LC_ALL=zh_TW.UTF-8" >> /root/.bashrc +RUN echo 'PS1="\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\u@\h:\W\$ "' >> /root/.bashrc + +CMD ["apache2ctl", "-D", "FOREGROUND"] +EXPOSE 80 + diff --git a/_site/GOVERNANCE.html b/_site/GOVERNANCE.html new file mode 100644 index 00000000..f3b24b72 --- /dev/null +++ b/_site/GOVERNANCE.html @@ -0,0 +1,249 @@ + + + + + + + + + 治理方式, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

目次

+ + + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

治理方式

+ +

本標準是 Foundation for Public Code 在為程式基底提供督導時的核心。我們依照這份文件來判斷，某個程式基底是否已經準備好讓社群共同參與開發。

+ +

這份標準由 Foundation for Public Code 職員負責維護。

+ +

我們歡迎任何人貢獻，例如提供修改建議，或是給予一般意見回饋等。

+ +

由於《公共程式標準》在我們的核心流程中，扮演至關重要的角色，所以我們會以《公共程式標準》的最高標準作要求。

+ +

我們會努力儘速回覆所有拉取請求。拉取請求使我們有機會一起合作，來改善我們的方法與這份標準。我們有可能不會接受貢獻者提出的所有修改，而我們會解釋背後的邏輯。

+ +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/GOVERNANCE.md b/_site/GOVERNANCE.md new file mode 100644 index 00000000..a6b7595f --- /dev/null +++ b/_site/GOVERNANCE.md @@ -0,0 +1,14 @@ +# Governance + + + + +This standard lies at the core of the codebase stewardship provided by the [Foundation for Public Code](https://publiccode.net/). We decide if a codebase is ready for community co-development based on this document. + +The standard is maintained by Foundation for Public Code staff. + +[We welcome contributions, such as suggestions for changes or general feedback, from anyone.](/CONTRIBUTING.md) + +Because of the important role that the Standard for Public Code has in our core process we require the highest standards from the Standard. + +We will try to respond promptly to all pull requests. The pull request is an opportunity to work together to improve our methods and the Standard. We may not accept all changes, but we will explain our logic. diff --git a/_site/LICENSE b/_site/LICENSE new file mode 100644 index 00000000..0e259d42 --- /dev/null +++ b/_site/LICENSE @@ -0,0 +1,121 @@ +Creative Commons Legal Code + +CC0 1.0 Universal + + CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE + LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN + ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS + INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES + REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS + PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM + THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED + HEREUNDER. + +Statement of Purpose + +The laws of most jurisdictions throughout the world automatically confer +exclusive Copyright and Related Rights (defined below) upon the creator +and subsequent owner(s) (each and all, an "owner") of an original work of +authorship and/or a database (each, a "Work"). + +Certain owners wish to permanently relinquish those rights to a Work for +the purpose of contributing to a commons of creative, cultural and +scientific works ("Commons") that the public can reliably and without fear +of later claims of infringement build upon, modify, incorporate in other +works, reuse and redistribute as freely as possible in any form whatsoever +and for any purposes, including without limitation commercial purposes. +These owners may contribute to the Commons to promote the ideal of a free +culture and the further production of creative, cultural and scientific +works, or to gain reputation or greater distribution for their Work in +part through the use and efforts of others. + +For these and/or other purposes and motivations, and without any +expectation of additional consideration or compensation, the person +associating CC0 with a Work (the "Affirmer"), to the extent that he or she +is an owner of Copyright and Related Rights in the Work, voluntarily +elects to apply CC0 to the Work and publicly distribute the Work under its +terms, with knowledge of his or her Copyright and Related Rights in the +Work and the meaning and intended legal effect of CC0 on those rights. + +1. Copyright and Related Rights. A Work made available under CC0 may be +protected by copyright and related or neighboring rights ("Copyright and +Related Rights"). Copyright and Related Rights include, but are not +limited to, the following: + + i. the right to reproduce, adapt, distribute, perform, display, + communicate, and translate a Work; + ii. moral rights retained by the original author(s) and/or performer(s); +iii. publicity and privacy rights pertaining to a person's image or + likeness depicted in a Work; + iv. rights protecting against unfair competition in regards to a Work, + subject to the limitations in paragraph 4(a), below; + v. rights protecting the extraction, dissemination, use and reuse of data + in a Work; + vi. database rights (such as those arising under Directive 96/9/EC of the + European Parliament and of the Council of 11 March 1996 on the legal + protection of databases, and under any national implementation + thereof, including any amended or successor version of such + directive); and +vii. other similar, equivalent or corresponding rights throughout the + world based on applicable law or treaty, and any national + implementations thereof. + +2. Waiver. To the greatest extent permitted by, but not in contravention +of, applicable law, Affirmer hereby overtly, fully, permanently, +irrevocably and unconditionally waives, abandons, and surrenders all of +Affirmer's Copyright and Related Rights and associated claims and causes +of action, whether now known or unknown (including existing as well as +future claims and causes of action), in the Work (i) in all territories +worldwide, (ii) for the maximum duration provided by applicable law or +treaty (including future time extensions), (iii) in any current or future +medium and for any number of copies, and (iv) for any purpose whatsoever, +including without limitation commercial, advertising or promotional +purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each +member of the public at large and to the detriment of Affirmer's heirs and +successors, fully intending that such Waiver shall not be subject to +revocation, rescission, cancellation, termination, or any other legal or +equitable action to disrupt the quiet enjoyment of the Work by the public +as contemplated by Affirmer's express Statement of Purpose. + +3. Public License Fallback. Should any part of the Waiver for any reason +be judged legally invalid or ineffective under applicable law, then the +Waiver shall be preserved to the maximum extent permitted taking into +account Affirmer's express Statement of Purpose. In addition, to the +extent the Waiver is so judged Affirmer hereby grants to each affected +person a royalty-free, non transferable, non sublicensable, non exclusive, +irrevocable and unconditional license to exercise Affirmer's Copyright and +Related Rights in the Work (i) in all territories worldwide, (ii) for the +maximum duration provided by applicable law or treaty (including future +time extensions), (iii) in any current or future medium and for any number +of copies, and (iv) for any purpose whatsoever, including without +limitation commercial, advertising or promotional purposes (the +"License"). The License shall be deemed effective as of the date CC0 was +applied by Affirmer to the Work. Should any part of the License for any +reason be judged legally invalid or ineffective under applicable law, such +partial invalidity or ineffectiveness shall not invalidate the remainder +of the License, and in such case Affirmer hereby affirms that he or she +will not (i) exercise any of his or her remaining Copyright and Related +Rights in the Work or (ii) assert any associated claims and causes of +action with respect to the Work, in either case contrary to Affirmer's +express Statement of Purpose. + +4. Limitations and Disclaimers. + + a. No trademark or patent rights held by Affirmer are waived, abandoned, + surrendered, licensed or otherwise affected by this document. + b. Affirmer offers the Work as-is and makes no representations or + warranties of any kind concerning the Work, express, implied, + statutory or otherwise, including without limitation warranties of + title, merchantability, fitness for a particular purpose, non + infringement, or the absence of latent or other defects, accuracy, or + the present or absence of errors, whether or not discoverable, all to + the greatest extent permissible under applicable law. + c. Affirmer disclaims responsibility for clearing rights of other persons + that may apply to the Work or any use thereof, including without + limitation any person's Copyright and Related Rights in the Work. + Further, Affirmer disclaims responsibility for obtaining any necessary + consents, permissions or other rights required for any use of the + Work. + d. Affirmer understands and acknowledges that Creative Commons is not a + party to this document and has no duty or obligation with respect to + this CC0 or use of the Work. diff --git a/_site/README.html b/_site/README.html new file mode 100644 index 00000000..5bcf83a4 --- /dev/null +++ b/_site/README.html @@ -0,0 +1,356 @@ + + + + + + + + + 公共程式標準, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 將《公共程式標準》套用到您的程式基底
    2. +
  2. 徵求貢獻
    3. +
  3. 幫忙改善這份標準
    4. +
  4. 預覽、建置、部署 +
      +
    1. 測試
      2. +
    2. 生成《公共程式標準》的 PDF 檔案
      3. +
    +
    5. +
  5. 授權
    6. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

公共程式標準

+ + + + +

《公共程式標準》提供公家機關一套準備開放原始碼解決方案的模型，讓他們能與其他地方相似的公家機關協作。該標準包含給政策制定者、市行政官、開發人員與供應商的指引。

+ +

version 0.7.1 License: +CC0-1.0 +標準承 +諾

+ +

pages-build-deployment +測 +試 +standard main +badge +standard develop +badge

+ +

《公共程式標準》目前為草稿階段。我們正在準備發行 1.0 版，目前仍在幾個程式基底中作測試。

+ +

將《公共程式標準》套用到您的程式基底

+ +

若您想要將《公共程式標準》套用您的程式基底，就請放心去做，因為它是人人都能自由採用的開放標準。如果您希望宣傳程式基底社群達成《公共程式標準》準則要求時的熱誠，請使 +用 standard-for-public-code-commitment 徽章連結到這份承諾文件。若要瞭解您程式基底所達成的程度，可以做自我資格評估；它能幫助您大略瞭解，如果想要滿足所有 +準則，還需要下多少功夫。

+ +

本標準 應該 足以自我解釋要如何套用到您的程式基底中。若標準中有任何不明確的地方，我們鼓勵您在此開立議題，來讓我們能協助您以及其他與您抱持同樣看法的人。如果需要 +一點靈感啟發，請參閱社群製作的《實踐指引》，其中包 +括範例與其他提示。

+ +

若新版的《公共程式標準》有任何導致過去作法不再適用的改動，則 Foundation for Public Code 的程式基底執事人員，會協助標準的實踐者理解該如何 +銜接之間的落差。

+ +

若您致力讓您的程式基底完全遵循此標準，並想在未來能取得認證，請寫信與我們聯繫： +info@publiccode.net，以展開正式評 +估。

+ +

徵求貢獻

+ +

我們相信公共政策與公共軟體，應該具備涵容、好用、開放、易懂、課責、近用、永續等特質。這代表我們需要一種新的方式，來設計、開發，以及付出心力育成原始碼和政策文件。

+ +

本標準為程式基底設立品質檢核水準，使其能滿足公家機關、社會機構、行政單位，以及其他重大基礎設施服務的需求。

+ +

本標準放在線上：standard.publiccode.net。請參閱 +index.md 查看整體內容概覽。

+ +

《公共程式標準》的影片縮圖：兩隻手中間放著本標準的印刷 +本

+ +

《公共程式標準》的影片介紹，出自 Creative Commons +Global Summit 2020 (4:12)，放在 YouTube 上。

+ +

幫忙改善這份標準

+ +

Foundation for Public Code 致力於維護與開發《公共程式標準》，且使其同時符合該標準自身的品質水準。

+ +

我們正在尋找像您這樣的人，能對此專案做出貢獻，像是建議改善方向，以及協助開發等。😊若要開始，請先參閱我們的貢獻者指 +引。由於這是相當核心的文件，我們僅接受能帶來重大價值的貢獻。治理方式聲明中有說明管理該標準的 +方式。

+ +

請注意，本專案配合行為守則一同發行。如果要參加本專案，代表您同意遵守守則。請善待社群的所有其他成員。

+ +

預覽、建置、部署

+ +

儲存庫會建置一個靜態網站，並部署至 standard.publiccode.net。網站採 +用 GitHub 頁面 與 Jekyll 技術。

+ +

網站內容透過 Jekyll 技術建置。這代表您需要有安裝 ruby 與 ruby-bundler，例如：

+ +
sudo apt-get install -y ruby ruby-bundler
+
+ +

一旦安裝好 ruby 與 bundle 後，就可以執行 bundle install，接著再利用 script/serve.sh 命令稿轉譯呈現出網 +站成果。

+ +

測試

+ +

本專案內含許多測試命令稿。其中 script/test-all.sh 命令稿則統包執行所有本機測試。

+ +

請前往 script 資料夾查看命令 +稿。

+ +

生成《公共程式標準》的 PDF 檔案

+ +

除了先前提到的 Jekyll 以外，想生成 PDF 檔，還需要依賴 Weasyprint 和 +QPDF。Pandoc 則可將 PDF 檔轉換成 +.epub 檔。

+ +

若要生成這類檔案，則應該要安裝依賴的軟體項目，例如：

+ +
sudo apt-get install -y pandoc qpdf weasyprint
+
+ +

使用以下命令稿，可以將 standard-print.html 檔案轉換成美觀的 PDF 檔，同時包括其他發行用的檔案：

+ +
script/pdf.sh
+
+ +

授權

+ +

© 作者與貢獻者

+ +

本標準採用 CC0 公眾領域貢獻宣告給予授權，該授權範圍涵蓋所有插圖與文件。CC0 代表任何人都能任意使用這些內容。如果您是貢獻者，代表您也將 +這些權利賦予他人。若要進一步瞭解如何協助本專案，請參閱〈貢獻指引〉。

+ +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/README.md b/_site/README.md new file mode 100644 index 00000000..46f2ac2c --- /dev/null +++ b/_site/README.md @@ -0,0 +1,110 @@ +# 公共程式標準 + + + + +《公共程式標準》提供公家機關一套準備開放原始碼解決方案的模型，讓他們能與其他地方相似的公家機關協作。該標準包含給政策制定者、市行政官、開發人員與供應商的指引。 + +![version 0.7.1](assets/version-badge.svg) [![License: +CC0-1.0](https://img.shields.io/badge/License-CC0_1.0-lightgrey.svg)](http://creativecommons.org/publicdomain/zero/1.0/) +[![標準承 +諾](assets/standard-for-public-code-commitment.svg)](#help-improve-this-standard) + +[![pages-build-deployment](https://github.com/publiccodenet/standard/actions/workflows/pages/pages-build-deployment/badge.svg)](https://github.com/publiccodenet/standard/actions/workflows/pages/pages-build-deployment) +[![測 +試](https://github.com/publiccodenet/standard/actions/workflows/test.yml/badge.svg)](https://github.com/publiccodenet/standard/actions/workflows/test.yml) +[![standard main +badge](https://publiccodenet.github.io/publiccodenet-url-check/badges/standard.publiccode.net.svg)](https://publiccodenet.github.io/publiccodenet-url-check/standard.publiccode.net-url-check-look.json) +[![standard develop +badge](https://publiccodenet.github.io/publiccodenet-url-check/badges/standard.publiccode.net-develop.svg)](https://publiccodenet.github.io/publiccodenet-url-check/standard.publiccode.net-develop-url-check-look.json) + +《公共程式標準》目前為草稿階段。我們正在準備發行 1.0 版，目前仍在幾個程式基底中作測試。 + +## 將《公共程式標準》套用到您的程式基底 + +若您想要將《公共程式標準》套用您的程式基底，就請放心去做，因為它是人人都能自由採用的開放標準。如果您希望宣傳程式基底社群達成《公共程式標準》準則要求時的熱誠，請使 +用 [standard-for-public-code-commitment 徽章](assets/standard-for-public-code-commitment.svg)連結到這份承諾文件。若要瞭解您程式基底所達成的程度，可以做[自我資格評估](https://publiccodenet.github.io/assessment-eligibility)；它能幫助您大略瞭解，如果想要滿足所有 +準則，還需要下多少功夫。 + +本標準 *應該* 足以自我解釋要如何套用到您的程式基底中。若標準中有任何不明確的地方，我們鼓勵您在此開立議題，來讓我們能協助您以及其他與您抱持同樣看法的人。如果需要 +一點靈感啟發，請參閱[社群製作的《實踐指引》](https://publiccodenet.github.io/community-implementation-guide-standard/)，其中包 +括範例與其他提示。 + +若新版的《公共程式標準》有任何導致過去作法不再適用的改動，則 Foundation for Public Code 的程式基底執事人員，會協助標準的實踐者理解該如何 +銜接之間的落差。 + +若您致力讓您的程式基底完全遵循此標準，並想在未來能取得認證，請寫信與我們聯繫： +[info@publiccode.net](mailto:info@publiccode.net)，以展開正式[評 +估](https://about.publiccode.net/activities/codebase-stewardship/lifecycle-diagram.html#assessment)。 + +## 徵求貢獻 + +我們相信公共政策與公共軟體，應該具備涵容、好用、開放、易懂、課責、近用、永續等特質。這代表我們需要一種新的方式，來設計、開發，以及付出心力育成原始碼和政策文件。 + +本標準為程式基底設立品質檢核水準，使其能滿足公家機關、社會機構、行政單位，以及其他重大基礎設施服務的需求。 + +本標準放在線上：[standard.publiccode.net](https://standard.publiccode.net/)。請參閱 +[`index.md`](index.md) 查看整體內容概覽。 + +[![《公共程式標準》的影片縮圖：兩隻手中間放著本標準的印刷 +本](https://img.youtube.com/vi/QWt6vB-cipE/mqdefault.jpg)](https://www.youtube.com/watch? +v=QWt6vB-cipE) + +[《公共程式標準》的影片介紹](https://www.youtube.com/watch?v=QWt6vB-cipE)，出自 Creative Commons +Global Summit 2020 (4:12)，放在 YouTube 上。 + +## 幫忙改善這份標準 + +Foundation for Public Code 致力於維護與開發《公共程式標準》，且使其同時符合該標準自身的品質水準。 + +我們正在尋找像您這樣的人，能對此專案做出[貢獻](CONTRIBUTING.md)，像是建議改善方向，以及協助開發等。😊若要開始，請先參閱我們的[貢獻者指 +引](CONTRIBUTING.md)。由於這是相當核心的文件，我們僅接受能帶來重大價值的貢獻。[治理方式聲明](GOVERNANCE.md)中有說明管理該標準的 +方式。 + +請注意，本專案配合[行為守則](CODE_OF_CONDUCT.md)一同發行。如果要參加本專案，代表您同意遵守守則。請善待社群的所有其他成員。 + +## 預覽、建置、部署 + +儲存庫會建置一個靜態網站，並部署至 [standard.publiccode.net](https://standard.publiccode.net/)。網站採 +用 [GitHub 頁面](https://pages.github.com) 與 [Jekyll](https://jekyllrb.com/) 技術。 + +網站內容透過 [Jekyll](http://jekyllrb.com/) 技術建置。這代表您需要有安裝 ruby 與 ruby-bundler，例如： + +```bash +sudo apt-get install -y ruby ruby-bundler +``` + +一旦安裝好 `ruby` 與 `bundle` 後，就可以執行 `bundle install`，接著再利用 `script/serve.sh` 命令稿轉譯呈現出網 +站成果。 + +### 測試 + +本專案內含許多測試命令稿。其中 `script/test-all.sh` 命令稿則統包執行所有本機測試。 + +請前往 [script](https://github.com/publiccodenet/standard/tree/main/script) 資料夾查看命令 +稿。 + +### 生成《公共程式標準》的 PDF 檔案 + +除了先前提到的 Jekyll 以外，想生成 PDF 檔，還需要依賴 [Weasyprint](https://weasyprint.org/) 和 +[QPDF](https://github.com/qpdf/qpdf)。[Pandoc](https://pandoc.org/) 則可將 PDF 檔轉換成 +`.epub` 檔。 + +若要生成這類檔案，則應該要安裝依賴的軟體項目，例如： + +```bash +sudo apt-get install -y pandoc qpdf weasyprint +``` + +使用以下命令稿，可以將 `standard-print.html` 檔案轉換成美觀的 PDF 檔，同時包括其他發行用的檔案： + +```bash +script/pdf.sh +``` + +## 授權 + +© [作者與貢獻者](AUTHORS.md) + +本標準採用 CC0 公眾領域貢獻宣告[給予授權](LICENSE)，該授權範圍涵蓋所有插圖與文件。CC0 代表任何人都能任意使用這些內容。如果您是貢獻者，代表您也將 +這些權利賦予他人。若要進一步瞭解如何協助本專案，請參閱〈[貢獻指引](CONTRIBUTING.md)〉。 diff --git a/_site/assets/cc-zero-badge.svg b/_site/assets/cc-zero-badge.svg new file mode 100644 index 00000000..9a925204 --- /dev/null +++ b/_site/assets/cc-zero-badge.svg @@ -0,0 +1,12 @@ + + + + + + + + + + + + diff --git a/_site/assets/codebase.svg b/_site/assets/codebase.svg new file mode 100644 index 00000000..bdd5de50 --- /dev/null +++ b/_site/assets/codebase.svg @@ -0,0 +1,134 @@ + + + + + + image/svg+xml + + Public code codebase + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_site/assets/collaboration.svg b/_site/assets/collaboration.svg new file mode 100644 index 00000000..deec655b --- /dev/null +++ b/_site/assets/collaboration.svg @@ -0,0 +1,37 @@ + + + + + + image/svg+xml + + Collaboration on public code + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_site/assets/collaborative-developement.svg b/_site/assets/collaborative-developement.svg new file mode 100644 index 00000000..61961e20 --- /dev/null +++ b/_site/assets/collaborative-developement.svg @@ -0,0 +1,50 @@ + + + + + + image/svg+xml + + collaborative public code development + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_site/assets/collaborative-development.svg b/_site/assets/collaborative-development.svg new file mode 100644 index 00000000..61961e20 --- /dev/null +++ b/_site/assets/collaborative-development.svg @@ -0,0 +1,50 @@ + + + + + + image/svg+xml + + collaborative public code development + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_site/assets/dpg-badge.svg b/_site/assets/dpg-badge.svg new file mode 100644 index 00000000..96e97b1d --- /dev/null +++ b/_site/assets/dpg-badge.svg @@ -0,0 +1,53 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_site/assets/eco-system.svg b/_site/assets/eco-system.svg new file mode 100644 index 00000000..02706113 --- /dev/null +++ b/_site/assets/eco-system.svg @@ -0,0 +1,57 @@ + + + + + + image/svg+xml + + ecosystem around public code development + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_site/assets/github-markdown.css b/_site/assets/github-markdown.css new file mode 100644 index 00000000..bc9c3901 --- /dev/null +++ b/_site/assets/github-markdown.css @@ -0,0 +1,695 @@ +@font-face { + font-family: octicons-link; + src: url(data:font/woff;charset=utf-8;base64,d09GRgABAAAAAAZwABAAAAAACFQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEU0lHAAAGaAAAAAgAAAAIAAAAAUdTVUIAAAZcAAAACgAAAAoAAQAAT1MvMgAAAyQAAABJAAAAYFYEU3RjbWFwAAADcAAAAEUAAACAAJThvmN2dCAAAATkAAAABAAAAAQAAAAAZnBnbQAAA7gAAACyAAABCUM+8IhnYXNwAAAGTAAAABAAAAAQABoAI2dseWYAAAFsAAABPAAAAZwcEq9taGVhZAAAAsgAAAA0AAAANgh4a91oaGVhAAADCAAAABoAAAAkCA8DRGhtdHgAAAL8AAAADAAAAAwGAACfbG9jYQAAAsAAAAAIAAAACABiATBtYXhwAAACqAAAABgAAAAgAA8ASm5hbWUAAAToAAABQgAAAlXu73sOcG9zdAAABiwAAAAeAAAAME3QpOBwcmVwAAAEbAAAAHYAAAB/aFGpk3jaTY6xa8JAGMW/O62BDi0tJLYQincXEypYIiGJjSgHniQ6umTsUEyLm5BV6NDBP8Tpts6F0v+k/0an2i+itHDw3v2+9+DBKTzsJNnWJNTgHEy4BgG3EMI9DCEDOGEXzDADU5hBKMIgNPZqoD3SilVaXZCER3/I7AtxEJLtzzuZfI+VVkprxTlXShWKb3TBecG11rwoNlmmn1P2WYcJczl32etSpKnziC7lQyWe1smVPy/Lt7Kc+0vWY/gAgIIEqAN9we0pwKXreiMasxvabDQMM4riO+qxM2ogwDGOZTXxwxDiycQIcoYFBLj5K3EIaSctAq2kTYiw+ymhce7vwM9jSqO8JyVd5RH9gyTt2+J/yUmYlIR0s04n6+7Vm1ozezUeLEaUjhaDSuXHwVRgvLJn1tQ7xiuVv/ocTRF42mNgZGBgYGbwZOBiAAFGJBIMAAizAFoAAABiAGIAznjaY2BkYGAA4in8zwXi+W2+MjCzMIDApSwvXzC97Z4Ig8N/BxYGZgcgl52BCSQKAA3jCV8CAABfAAAAAAQAAEB42mNgZGBg4f3vACQZQABIMjKgAmYAKEgBXgAAeNpjYGY6wTiBgZWBg2kmUxoDA4MPhGZMYzBi1AHygVLYQUCaawqDA4PChxhmh/8ODDEsvAwHgMKMIDnGL0x7gJQCAwMAJd4MFwAAAHjaY2BgYGaA4DAGRgYQkAHyGMF8NgYrIM3JIAGVYYDT+AEjAwuDFpBmA9KMDEwMCh9i/v8H8sH0/4dQc1iAmAkALaUKLgAAAHjaTY9LDsIgEIbtgqHUPpDi3gPoBVyRTmTddOmqTXThEXqrob2gQ1FjwpDvfwCBdmdXC5AVKFu3e5MfNFJ29KTQT48Ob9/lqYwOGZxeUelN2U2R6+cArgtCJpauW7UQBqnFkUsjAY/kOU1cP+DAgvxwn1chZDwUbd6CFimGXwzwF6tPbFIcjEl+vvmM/byA48e6tWrKArm4ZJlCbdsrxksL1AwWn/yBSJKpYbq8AXaaTb8AAHja28jAwOC00ZrBeQNDQOWO//sdBBgYGRiYWYAEELEwMTE4uzo5Zzo5b2BxdnFOcALxNjA6b2ByTswC8jYwg0VlNuoCTWAMqNzMzsoK1rEhNqByEyerg5PMJlYuVueETKcd/89uBpnpvIEVomeHLoMsAAe1Id4AAAAAAAB42oWQT07CQBTGv0JBhagk7HQzKxca2sJCE1hDt4QF+9JOS0nbaaYDCQfwCJ7Au3AHj+LO13FMmm6cl7785vven0kBjHCBhfpYuNa5Ph1c0e2Xu3jEvWG7UdPDLZ4N92nOm+EBXuAbHmIMSRMs+4aUEd4Nd3CHD8NdvOLTsA2GL8M9PODbcL+hD7C1xoaHeLJSEao0FEW14ckxC+TU8TxvsY6X0eLPmRhry2WVioLpkrbp84LLQPGI7c6sOiUzpWIWS5GzlSgUzzLBSikOPFTOXqly7rqx0Z1Q5BAIoZBSFihQYQOOBEdkCOgXTOHA07HAGjGWiIjaPZNW13/+lm6S9FT7rLHFJ6fQbkATOG1j2OFMucKJJsxIVfQORl+9Jyda6Sl1dUYhSCm1dyClfoeDve4qMYdLEbfqHf3O/AdDumsjAAB42mNgYoAAZQYjBmyAGYQZmdhL8zLdDEydARfoAqIAAAABAAMABwAKABMAB///AA8AAQAAAAAAAAAAAAAAAAABAAAAAA==) format('woff'); +} + +.markdown-body { + -ms-text-size-adjust: 100%; + -webkit-text-size-adjust: 100%; + line-height: 1.5; + color: #24292e; + font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol"; + font-size: 16px; + line-height: 1.5; + word-wrap: break-word; +} + +.markdown-body .pl-c { + color: #6a737d; +} + +.markdown-body .pl-c1, +.markdown-body .pl-s .pl-v { + color: #005cc5; +} + +.markdown-body .pl-e, +.markdown-body .pl-en { + color: #6f42c1; +} + +.markdown-body .pl-smi, +.markdown-body .pl-s .pl-s1 { + color: #24292e; +} + +.markdown-body .pl-ent { + color: #22863a; +} + +.markdown-body .pl-k { + color: #d73a49; +} + +.markdown-body .pl-s, +.markdown-body .pl-pds, +.markdown-body .pl-s .pl-pse .pl-s1, +.markdown-body .pl-sr, +.markdown-body .pl-sr .pl-cce, +.markdown-body .pl-sr .pl-sre, +.markdown-body .pl-sr .pl-sra { + color: #032f62; +} + +.markdown-body .pl-v, +.markdown-body .pl-smw { + color: #e36209; +} + +.markdown-body .pl-bu { + color: #b31d28; +} + +.markdown-body .pl-ii { + color: #fafbfc; + background-color: #b31d28; +} + +.markdown-body .pl-c2 { + color: #fafbfc; + background-color: #d73a49; +} + +.markdown-body .pl-c2::before { + content: "^M"; +} + +.markdown-body .pl-sr .pl-cce { + font-weight: bold; + color: #22863a; +} + +.markdown-body .pl-ml { + color: #735c0f; +} + +.markdown-body .pl-mh, +.markdown-body .pl-mh .pl-en, +.markdown-body .pl-ms { + font-weight: bold; + color: #005cc5; +} + +.markdown-body .pl-mi { + font-style: italic; + color: #24292e; +} + +.markdown-body .pl-mb { + font-weight: bold; + color: #24292e; +} + +.markdown-body .pl-md { + color: #b31d28; + background-color: #ffeef0; +} + +.markdown-body .pl-mi1 { + color: #22863a; + background-color: #f0fff4; +} + +.markdown-body .pl-mc { + color: #e36209; + background-color: #ffebda; +} + +.markdown-body .pl-mi2 { + color: #f6f8fa; + background-color: #005cc5; +} + +.markdown-body .pl-mdr { + font-weight: bold; + color: #6f42c1; +} + +.markdown-body .pl-ba { + color: #586069; +} + +.markdown-body .pl-sg { + color: #959da5; +} + +.markdown-body .pl-corl { + text-decoration: underline; + color: #032f62; +} + +.markdown-body .octicon { + display: inline-block; + vertical-align: text-top; + fill: currentColor; +} + +.markdown-body a { + background-color: transparent; +} + +.markdown-body a:active, +.markdown-body a:hover { + outline-width: 0; +} + +.markdown-body strong { + font-weight: inherit; +} + +.markdown-body strong { + font-weight: bolder; +} + +.markdown-body h1 { + font-size: 2em; + margin: 0.67em 0; +} + +.markdown-body img { + border-style: none; +} + +.markdown-body code, +.markdown-body kbd, +.markdown-body pre { + font-family: monospace, monospace; + font-size: 1em; +} + +.markdown-body hr { + box-sizing: content-box; + height: 0; + overflow: visible; +} + +.markdown-body input { + font: inherit; + margin: 0; +} + +.markdown-body input { + overflow: visible; +} + +.markdown-body [type="checkbox"] { + box-sizing: border-box; + padding: 0; +} + +.markdown-body * { + box-sizing: border-box; +} + +.markdown-body input { + font-family: inherit; + font-size: inherit; + line-height: inherit; +} + +.markdown-body a { + color: #0366d6; + text-decoration: none; +} + +.markdown-body a:hover { + text-decoration: underline; +} + +.markdown-body strong { + font-weight: 600; +} + +.markdown-body hr { + height: 0; + margin: 15px 0; + overflow: hidden; + background: transparent; + border: 0; + border-bottom: 1px solid #dfe2e5; +} + +.markdown-body hr::before { + display: table; + content: ""; +} + +.markdown-body hr::after { + display: table; + clear: both; + content: ""; +} + +.markdown-body table { + border-spacing: 0; + border-collapse: collapse; +} + +.markdown-body td, +.markdown-body th { + padding: 0; +} + +.markdown-body h1, +.markdown-body h2, +.markdown-body h3, +.markdown-body h4, +.markdown-body h5, +.markdown-body h6 { + margin-top: 0; + margin-bottom: 0; +} + +.markdown-body h1 { + font-size: 32px; + font-weight: 600; +} + +.markdown-body h2 { + font-size: 24px; + font-weight: 600; +} + +.markdown-body h3 { + font-size: 20px; + font-weight: 600; +} + +.markdown-body h4 { + font-size: 16px; + font-weight: 600; +} + +.markdown-body h5 { + font-size: 14px; + font-weight: 600; +} + +.markdown-body h6 { + font-size: 12px; + font-weight: 600; +} + +.markdown-body p { + margin-top: 0; + margin-bottom: 10px; +} + +.markdown-body blockquote { + margin: 0; +} + +.markdown-body ul, +.markdown-body ol { + padding-left: 0; + margin-top: 0; + margin-bottom: 0; +} + +.markdown-body ol ol, +.markdown-body ul ol { + list-style-type: lower-roman; +} + +.markdown-body ul ul ol, +.markdown-body ul ol ol, +.markdown-body ol ul ol, +.markdown-body ol ol ol { + list-style-type: lower-alpha; +} + +.markdown-body dd { + margin-left: 0; +} + +.markdown-body code { + font-family: "SFMono-Regular", Consolas, "Liberation Mono", Menlo, Courier, monospace; + font-size: 12px; +} + +.markdown-body pre { + margin-top: 0; + margin-bottom: 0; + font-family: "SFMono-Regular", Consolas, "Liberation Mono", Menlo, Courier, monospace; + font-size: 12px; +} + +.markdown-body .octicon { + vertical-align: text-bottom; +} + +.markdown-body .pl-0 { + padding-left: 0 !important; +} + +.markdown-body .pl-1 { + padding-left: 4px !important; +} + +.markdown-body .pl-2 { + padding-left: 8px !important; +} + +.markdown-body .pl-3 { + padding-left: 16px !important; +} + +.markdown-body .pl-4 { + padding-left: 24px !important; +} + +.markdown-body .pl-5 { + padding-left: 32px !important; +} + +.markdown-body .pl-6 { + padding-left: 40px !important; +} + +.markdown-body::before { + display: table; + content: ""; +} + +.markdown-body::after { + display: table; + clear: both; + content: ""; +} + +.markdown-body>*:first-child { + margin-top: 0 !important; +} + +.markdown-body>*:last-child { + margin-bottom: 0 !important; +} + +.markdown-body a:not([href]) { + color: inherit; + text-decoration: none; +} + +.markdown-body .anchor { + float: left; + padding-right: 4px; + margin-left: -20px; + line-height: 1; +} + +.markdown-body .anchor:focus { + outline: none; +} + +.markdown-body p, +.markdown-body blockquote, +.markdown-body ul, +.markdown-body ol, +.markdown-body dl, +.markdown-body table, +.markdown-body pre { + margin-top: 0; + margin-bottom: 16px; +} + +.markdown-body hr { + height: 0.25em; + padding: 0; + margin: 24px 0; + background-color: #e1e4e8; + border: 0; +} + +.markdown-body blockquote { + padding: 0 1em; + color: #6a737d; + border-left: 0.25em solid #dfe2e5; +} + +.markdown-body blockquote>:first-child { + margin-top: 0; +} + +.markdown-body blockquote>:last-child { + margin-bottom: 0; +} + +.markdown-body kbd { + display: inline-block; + padding: 3px 5px; + font-size: 11px; + line-height: 10px; + color: #444d56; + vertical-align: middle; + background-color: #fafbfc; + border: solid 1px #c6cbd1; + border-bottom-color: #959da5; + border-radius: 3px; + box-shadow: inset 0 -1px 0 #959da5; +} + +.markdown-body h1, +.markdown-body h2, +.markdown-body h3, +.markdown-body h4, +.markdown-body h5, +.markdown-body h6 { + margin-top: 24px; + margin-bottom: 16px; + font-weight: 600; + line-height: 1.25; +} + +.markdown-body h1 .octicon-link, +.markdown-body h2 .octicon-link, +.markdown-body h3 .octicon-link, +.markdown-body h4 .octicon-link, +.markdown-body h5 .octicon-link, +.markdown-body h6 .octicon-link { + color: #1b1f23; + vertical-align: middle; + visibility: hidden; +} + +.markdown-body h1:hover .anchor, +.markdown-body h2:hover .anchor, +.markdown-body h3:hover .anchor, +.markdown-body h4:hover .anchor, +.markdown-body h5:hover .anchor, +.markdown-body h6:hover .anchor { + text-decoration: none; +} + +.markdown-body h1:hover .anchor .octicon-link, +.markdown-body h2:hover .anchor .octicon-link, +.markdown-body h3:hover .anchor .octicon-link, +.markdown-body h4:hover .anchor .octicon-link, +.markdown-body h5:hover .anchor .octicon-link, +.markdown-body h6:hover .anchor .octicon-link { + visibility: visible; +} + +.markdown-body h1 { + padding-bottom: 0.3em; + font-size: 2em; + border-bottom: 1px solid #eaecef; +} + +.markdown-body h2 { + padding-bottom: 0.3em; + font-size: 1.5em; + border-bottom: 1px solid #eaecef; +} + +.markdown-body h3 { + font-size: 1.25em; +} + +.markdown-body h4 { + font-size: 1em; +} + +.markdown-body h5 { + font-size: 0.875em; +} + +.markdown-body h6 { + font-size: 0.85em; + color: #6a737d; +} + +.markdown-body ul, +.markdown-body ol { + padding-left: 2em; +} + +.markdown-body ul ul, +.markdown-body ul ol, +.markdown-body ol ol, +.markdown-body ol ul { + margin-top: 0; + margin-bottom: 0; +} + +.markdown-body li { + word-wrap: break-all; +} + +.markdown-body li>p { + margin-top: 16px; +} + +.markdown-body li+li { + margin-top: 0.25em; +} + +.markdown-body dl { + padding: 0; +} + +.markdown-body dl dt { + padding: 0; + margin-top: 16px; + font-size: 1em; + font-style: italic; + font-weight: 600; +} + +.markdown-body dl dd { + padding: 0 16px; + margin-bottom: 16px; +} + +.markdown-body table { + display: block; + width: 100%; + overflow: auto; +} + +.markdown-body table th { + font-weight: 600; +} + +.markdown-body table th, +.markdown-body table td { + padding: 6px 13px; + border: 1px solid #dfe2e5; +} + +.markdown-body table tr { + background-color: #fff; + border-top: 1px solid #c6cbd1; +} + +.markdown-body table tr:nth-child(2n) { + background-color: #f6f8fa; +} + +.markdown-body img { + max-width: 100%; + box-sizing: content-box; + /* background-color: #fff; */ +} + +.markdown-body img[align=right] { + padding-left: 20px; +} + +.markdown-body img[align=left] { + padding-right: 20px; +} + +.markdown-body code { + padding: 0.2em 0.4em; + margin: 0; + font-size: 85%; + background-color: rgba(27,31,35,0.05); + border-radius: 3px; +} + +.markdown-body pre { + word-wrap: normal; +} + +.markdown-body pre>code { + padding: 0; + margin: 0; + font-size: 100%; + word-break: normal; + white-space: pre; + background: transparent; + border: 0; +} + +.markdown-body .highlight { + margin-bottom: 16px; +} + +.markdown-body .highlight pre { + margin-bottom: 0; + word-break: normal; +} + +.markdown-body .highlight pre, +.markdown-body pre { + padding: 16px; + overflow: auto; + font-size: 85%; + line-height: 1.45; + background-color: #f6f8fa; + border-radius: 3px; +} + +.markdown-body pre code { + display: inline; + max-width: auto; + padding: 0; + margin: 0; + overflow: visible; + line-height: inherit; + word-wrap: normal; + background-color: transparent; + border: 0; +} + +.markdown-body .full-commit .btn-outline:not(:disabled):hover { + color: #005cc5; + border-color: #005cc5; +} + +.markdown-body kbd { + display: inline-block; + padding: 3px 5px; + font: 11px "SFMono-Regular", Consolas, "Liberation Mono", Menlo, Courier, monospace; + line-height: 10px; + color: #444d56; + vertical-align: middle; + background-color: #fafbfc; + border: solid 1px #d1d5da; + border-bottom-color: #c6cbd1; + border-radius: 3px; + box-shadow: inset 0 -1px 0 #c6cbd1; +} + +.markdown-body :checked+.radio-label { + position: relative; + z-index: 1; + border-color: #0366d6; +} + +.markdown-body .task-list-item { + list-style-type: none; +} + +.markdown-body .task-list-item+.task-list-item { + margin-top: 3px; +} + +.markdown-body .task-list-item input { + margin: 0 0.2em 0.25em -1.6em; + vertical-align: middle; +} + +.markdown-body hr { + border-bottom-color: #eee; +} diff --git a/_site/assets/hand-point.svg b/_site/assets/hand-point.svg new file mode 100644 index 00000000..beaa6645 --- /dev/null +++ b/_site/assets/hand-point.svg @@ -0,0 +1,6 @@ + + + + + + diff --git a/_site/assets/hands-shake.svg b/_site/assets/hands-shake.svg new file mode 100644 index 00000000..b855bb40 --- /dev/null +++ b/_site/assets/hands-shake.svg @@ -0,0 +1,15 @@ + + + + + + + + + + + + + + + diff --git a/_site/assets/print.css b/_site/assets/print.css new file mode 100644 index 00000000..7d0eead1 --- /dev/null +++ b/_site/assets/print.css @@ -0,0 +1,274 @@ +/* SPDX-License-Identifier: CC0-1.0 */ +/* SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS */ +html, .markdown-body { + font-family: Mulish; + font-size: 11pt; +} + +.markdown-body h1, .markdown-body h2, .markdown-body h3 { + font-weight: normal; + position: relative; +} +.markdown-body h1 { + margin-top: 0; + font-size: 1.5cm; + border-bottom: none; +} +.markdown-body h2 { + font-size: 1.5em; +} +.markdown-body h3 { + font-size: 1em; + font-weight: bold; +} +.markdown-body h4 { + font-size: 1em; + font-style: italic; +} +.markdown-body h4 { + font-weight: bold; + font-weight: normal; +} + +article>p, article>ul, article>ol { + position: relative; + max-width: 27rem; +} + +article { + clear: both; +} + +a:link { + color: inherit; + text-decoration: none; +} + +a:link:before { + color: grey; + page-break-inside: avoid; + margin-left: .25em; + break-inside: avoid; + display: block; + right: 0; + width: 6cm; + margin-right: -7cm; + padding: 0.25rem; + line-height: 1.25; + text-align: left; + float: right; + clear: both; + word-break: normal; + text-decoration: none; +} +a[href^="http"]:link { + color: black; + text-decoration: none; + word-wrap: normal; +} +a[href^="http"]:before { + content: "" attr(href) ""; + font-size: .75em; +} +a[href^="#"] { + color: black; + text-decoration: none; +} +a[href^="#"]:after { + content: "" target-counter(attr(href), page); + color: black; + background-color: whitesmoke; + display: inline; + width: 0.8cm; + padding: 0.2cm; + text-align: right; +} + +img { + max-width: 155% !important; +} + +ol, ul { + margin-bottom: 2em; +} + +li, p { + clear: both; +} + +/* Headings */ + +.markdown-body [id$="public-policy-makers-what-you-need-to-do"]:before, +.markdown-body [id$="managers-what-you-need-to-do"]:before, +.markdown-body [id$="developers-and-designers-what-you-need-to-do"]:before { + display: block; + position: absolute; + content: 'A'; + text-align: center; + width: 1cm; + height: 1cm; + background-color: black; + border: 1px solid black; + color: white; + display: inline-block; + margin-left: -1.2cm; + box-sizing: border-box; + padding: 0.12cm; + font-size: 0.5cm; + font-weight: 900; +} +.markdown-body [id$="public-policy-makers-what-you-need-to-do"]:before { + background-color: #00EFB5; + border-color: #00EFB5; + content: 'P'; +} +.markdown-body [id$="managers-what-you-need-to-do"]:before { + background-color: #FF6D1C; + border-color: #FF6D1C; + content: 'M'; +} +.markdown-body [id$="developers-and-designers-what-you-need-to-do"]:before { + background-color: #8626FF; + border-color: #8626FF; + content: 'D'; +} + +/* First page */ + +h1.title { + font-size: 5em; + font-weight: 700; + margin-bottom: 1cm; +} + +ul.first-page-audiences { + max-width: none; + list-style: none; + font-size: 1.25em; + padding-left: 0; +} +.first-page-audiences li, .first-page-audiences lh { + display: block; + margin-bottom: .5cm; +} +.first-page-audiences lh { + margin-bottom: 1cm; +} +.first-page-audiences li { + padding-left: 1.2cm; +} +.first-page-audiences li::before { + margin-top: -.15cm; +} +#section-first-page>img { + width: 100%; +} + +/* Print specific */ + +@media print { + /* html { page-break-before: left } */ + @page { + /* A4 with a 3mm bleed on every side */ + size: 21.6cm 30.3cm; + margin: 2cm 0; + orphans:4; + widows:4; + } + @page :left { + margin-right: 1cm; + @top-left { + background: whitesmoke; + font-size: 75%; + height: 1cm; + width: 1.23cm; + text-align: center; + padding-left: 0.5cm; + } + } + @page :right { + margin-left: 1cm; + @top-right { + background: whitesmoke; + font-size: 75%; + height: 1cm; + width: 1.23cm; + text-align: center; + padding-right: 0.5cm; + } + } + figure { + page: image; + } + figure>img { + width: 100%; + height: 100%; + } + @page image { + margin-top: 0 !important; + margin-left: -1.5cm !important; + margin-right: -1.5cm !important; + margin-bottom: 0 !important; + padding: 0 0 0 0 !important; + } + + article { + margin: 0 2cm; + break-before: left; + } + article:first-of-type { + break-before: avoid; + } + h1, h2, h3, h4 { + page-break-after: avoid; + } + img { + page-break-inside: avoid; + } + #table-of-contents { + line-height: 0.9; + } + a.table-of-contents[href^="http"]:after { + content: "" attr(href) ""; + font-size: .75em; +} + a.table-of-contents:link:after { + color: grey; + page-break-inside: avoid; + margin-left: .25em; + break-inside: avoid; + display: block; + right: 0; + width: 0.8cm; + margin-right: -7cm; + padding: 0.25rem; + line-height: 1.25; + text-align: right; + float: right; + clear: both; + word-break: normal; + text-decoration: none; +} + + #section-first-page>img { + width: 21.6cm; + margin: 1cm 0 1cm -3.21cm; /* This value for the left margin was done by eye */ + } +} + +@media screen { + body { + background-color: whitesmoke; + margin: 0; padding: 0; + } + article { + display: block; + background-color: white; + padding: 1cm; + min-height: 29.7cm; + max-width: 50em; + max-width: 21cm; + box-sizing: border-box; + margin: 2cm 0; + } +} diff --git a/_site/assets/rouge-highlight.css b/_site/assets/rouge-highlight.css new file mode 100644 index 00000000..f1877f20 --- /dev/null +++ b/_site/assets/rouge-highlight.css @@ -0,0 +1,210 @@ + +.highlight table td { padding: 5px; } +.highlight table pre { margin: 0; } +.highlight .cm { + color: #777772; + font-style: italic; +} +.highlight .cp { + color: #797676; + font-weight: bold; +} +.highlight .c1 { + color: #777772; + font-style: italic; +} +.highlight .cs { + color: #797676; + font-weight: bold; + font-style: italic; +} +.highlight .c, .highlight .cd { + color: #777772; + font-style: italic; +} +.highlight .err { + color: #a61717; + background-color: #e3d2d2; +} +.highlight .gd { + color: #000000; + background-color: #ffdddd; +} +.highlight .ge { + color: #000000; + font-style: italic; +} +.highlight .gr { + color: #aa0000; +} +.highlight .gh { + color: #797676; +} +.highlight .gi { + color: #000000; + background-color: #ddffdd; +} +.highlight .go { + color: #888888; +} +.highlight .gp { + color: #555555; +} +.highlight .gs { + font-weight: bold; +} +.highlight .gu { + color: #aaaaaa; +} +.highlight .gt { + color: #aa0000; +} +.highlight .kc { + color: #000000; + font-weight: bold; +} +.highlight .kd { + color: #000000; + font-weight: bold; +} +.highlight .kn { + color: #000000; + font-weight: bold; +} +.highlight .kp { + color: #000000; + font-weight: bold; +} +.highlight .kr { + color: #000000; + font-weight: bold; +} +.highlight .kt { + color: #445588; + font-weight: bold; +} +.highlight .k, .highlight .kv { + color: #000000; + font-weight: bold; +} +.highlight .mf { + color: #009999; +} +.highlight .mh { + color: #009999; +} +.highlight .il { + color: #009999; +} +.highlight .mi { + color: #009999; +} +.highlight .mo { + color: #009999; +} +.highlight .m, .highlight .mb, .highlight .mx { + color: #009999; +} +.highlight .sb { + color: #d14; +} +.highlight .sc { + color: #d14; +} +.highlight .sd { + color: #d14; +} +.highlight .s2 { + color: #d14; +} +.highlight .se { + color: #d14; +} +.highlight .sh { + color: #d14; +} +.highlight .si { + color: #d14; +} +.highlight .sx { + color: #d14; +} +.highlight .sr { + color: #009926; +} +.highlight .s1 { + color: #d14; +} +.highlight .ss { + color: #990073; +} +.highlight .s { + color: #d14; +} +.highlight .na { + color: #008080; +} +.highlight .bp { + color: #797676; +} +.highlight .nb { + color: #0086B3; +} +.highlight .nc { + color: #445588; + font-weight: bold; +} +.highlight .no { + color: #008080; +} +.highlight .nd { + color: #3c5d5d; + font-weight: bold; +} +.highlight .ni { + color: #800080; +} +.highlight .ne { + color: #990000; + font-weight: bold; +} +.highlight .nf { + color: #990000; + font-weight: bold; +} +.highlight .nl { + color: #990000; + font-weight: bold; +} +.highlight .nn { + color: #555555; +} +.highlight .nt { + color: #000080; +} +.highlight .vc { + color: #008080; +} +.highlight .vg { + color: #008080; +} +.highlight .vi { + color: #008080; +} +.highlight .nv { + color: #008080; +} +.highlight .ow { + color: #000000; + font-weight: bold; +} +.highlight .o { + color: #000000; + font-weight: bold; +} +.highlight .w { + color: #bbbbbb; +} +.highlight { + background-color: #f8f8f8; +} diff --git a/_site/assets/standard-for-public-code-commitment.svg b/_site/assets/standard-for-public-code-commitment.svg new file mode 100644 index 00000000..34b1faa2 --- /dev/null +++ b/_site/assets/standard-for-public-code-commitment.svg @@ -0,0 +1,25 @@ + + + + + + Standard for Public Code: commitment + + + + + + + + + + + + + + + Standard for Public Code + + commitment + + diff --git a/_site/assets/style.css b/_site/assets/style.css new file mode 100644 index 00000000..9470766b --- /dev/null +++ b/_site/assets/style.css @@ -0,0 +1,873 @@ +@import url("github-markdown.css"); +@import url("rouge-highlight.css"); +@import url('https://fonts.googleapis.com/css?family=Muli:400,400i,700'); + + +/* + * HTML and Body elements +*/ + +body, html { + font-family: 'Muli', sans-serif; + margin: 0; +} + +@media screen { + body { + background: whitesmoke; + } +} + +@media print { + html { + font-size: 12pt; + } + + @page { + /* A4 with, for printing presses add a (3mm to each side) bleed here */ + size: 21cm 29.7cm; + margin: 2cm 1cm; + orphans:4; + widows:4; + @bottom-center { + background: whitesmoke; + font-size: 75%; + content: counter(page); + margin-top: 0.25cm; + height: 1cm; + width: 1cm; + text-align: center; + } + } +} + +/* + * General elements and ground rules +*/ + +hr { + border: none; + border-bottom: 1px solid lightgrey; +} + +@media screen { + p, h1, h2, h3, h4, h5, ul, pre, blockquote, .highlight { + max-width: 35em; + max-width: calc(30rem + 5em); + } +} +@media print { + p, ul { + max-width: 12cm; + max-width: 60vw; + box-sizing: border-box; + } +} + +h1, h2, h3, h4, h5 { + page-break-after: avoid; +} +img, code { + break-inside: avoid; + page-break-inside: avoid; + overflow: wrap; +} + +@media print { + ul, ol { + page-break-inside: avoid; + } + ul li, ol li { + margin: .5em 0; + } +} + +/* + * Links +*/ + +a:link, a:visited { + text-decoration: underline; + color: black; +} +a:link { + text-decoration-color: blue; +} +a:visited { + text-decoration-color: purple; +} +a:link[href^='#'], a:visited[href^='#'] { + text-decoration-color: darkgrey; +} +a:hover { + background: whitesmoke; +} + +@media print { + a:link, a:visited { + text-decoration: none !important; + } + a:link:after, a:visited:after { + color: grey; + border-left: 2px solid whitesmoke; + page-break-inside: avoid; + break-inside: avoid; + display: block; + right: 0; + width: 6cm; + width: 30vw; + margin-right: -7cm; + margin-right: -30vw; + padding: 0 0 0.25em .25em; + margin-bottom: .25em; + line-height: 1.25; + text-align: left; + float: right; + clear: both; + text-decoration: none; + font-weight: normal; + } + /* Add `[href^="http"]` for limiting to external sites */ + a[href^="http"]:link { + color: black; + text-decoration: underline; + } + a[href^="http"]:after { + content: "" attr(href) ""; + font-size: .75rem; + } + a[href^="/"]:after { + /* content: "" attr(href) ""; + font-size: .75rem; */ + display: none; + } + a[href^="#"]:after { + content: "" target-counter(attr(href), page); + color: black; + background-color: whitesmoke; + width: 1cm; + padding: 0.2cm; + text-align: right; + } +} + +/* +Buttons +*/ + +button, input { + font-family: inherit; + font-size: inherit; + margin-bottom: 0.5em; + padding: 0.5em; + display: inline-block; + background: none; + border: 1px solid lightgrey; + border-radius: 2px; + white-space: nowrap; +} +input:focus, button:focus { + border: 1px solid black; + background: whitesmoke; +} +button:hover { + background: whitesmoke; +} +button svg { + vertical-align: -2px; +} + +/* + * general layout +*/ + +body>hr { + margin: 0; +} + +@media screen { + body>nav.theme-nav, body>header, body>footer { + padding: 1em; + } + body>header, body>footer#site-footer { + background-color: white; + } + body>*:not(hr) { + box-sizing: border-box; + max-width: 80em; + margin: auto; + } + body.with-site-nav>*:not(hr) { + max-width: 100em; + } +} + +@media screen and (min-width:68em) { + body>nav.theme-nav, body>header, body>footer { + padding: 2em 4em; + } +} + +/* + * Foundation Navigation +*/ + +@media screen { + nav.theme-nav { + display: flex; + flex-direction: row; + align-items: center; + flex-wrap: wrap; + padding-bottom: 1rem; + background: none; + } +} +@media screen and (min-width:400px) { + nav.theme-nav { + padding: 1rem; + } +} +@media screen and (min-width:64em) { + nav.theme-nav { + padding: 1rem 4em; + } +} +@media print { + nav.theme-nav { + display: block; + } + nav.theme-nav ul { + display: none; + } +} + +nav.theme-nav ul { + list-style: none; + margin: 0 0 12px; + padding-inline-start: 0px; + max-width: none; +} +nav.theme-nav ul li { + padding: 5px 0; + display: inline-block; +} + +nav.theme-nav a:link, header a:visited { + font-weight: normal; + border-bottom: none; +} +@media screen { + nav.theme-nav a:link, header a:visited { + padding: 1rem; + } +} +@media print { + nav.theme-nav a:link:after, header a:visited:after { + display: none; + } +} + +nav.theme-nav a.logo-mark { + display: flex; + flex-direction: row; + align-items: center; + flex: 1; + text-decoration: none; + margin-right: 40px; +} + +@media screen and (max-width:640px) { + nav.theme-nav { + align-items: flex-start; + } + nav.theme-nav a.logo-mark { + margin-right: 0px; + } + nav.theme-nav ul { + margin: 16px 15px 16px 0; + } + nav.theme-nav ul li { + display:block; + } +} + +@media screen and (min-width:520px) { + nav.theme-nav a.logo-mark { + font-size: 2em; + } +} +@media screen and (min-width:400px) and (max-width:520px) { + nav.theme-nav a.logo-mark { + font-size: 1.5em; + } +} + +@media screen and (max-width:440px) { + nav.theme-nav { + flex-direction: column; + } + nav.theme-nav { + align-items: flex-start; + } +} + + +nav.theme-nav a.logo-mark>img { + height: 2em; + margin-right: 0.5em; +} +nav.theme-nav a.logo-mark>p { + font-weight: bold; + margin: 0; +} + +@media print { + nav.theme-nav+hr { + display: none; + } + nav.theme-nav a.logo-mark { + font-size: 1.5em; + } + nav.theme-nav a.logo-mark>img { + margin-right: 0.9rem; + } +} + +/* + * Site header +*/ + +@media screen { + header .site-title { + padding: 1em 1rem; + font-size: 1.5em; + } +} +@media screen and (min-width:400px) { + header .site-title { + font-size: 2em; + padding: 1.5em 2rem; + } +} +@media screen and (min-width:700px) { + header .site-title.home { + font-size: 4em; + } +} + +header .site-title a { + text-decoration: none; +} +header .site-title a:hover { + text-decoration: underline; +} + +@media print { + header .site-title a:after { + display: none; + } + header .site-title { + font-size: 1.5em; + margin-left: 3.5rem; + } + header+hr { + margin: 2em 0; + } +} + +/* + * Site navigation +*/ + +input#show-site-nav { + display: none; +} +input#show-site-nav ~ label:before { + content: 'Open ' +} +input#show-site-nav:checked ~ label:before { + content: 'Close ' +} + +nav#site-nav { + padding: 1rem; +} +nav#site-nav>ul { + display: none; +} +label[for=show-site-nav] { + display: block; +} +nav#site-nav a.active { + font-weight: bold; +} + +input#show-site-nav ~ label { + margin: 1em; + padding: 1rem; + text-decoration: none; + border: 1px solid grey; + border-radius: 2px; + display: block; +} +input#show-site-nav ~ label:hover, input#show-site-nav:checked ~ label { + background: lightgrey; +} +input#show-site-nav:checked ~ ul { + display: block; +} + +@media print { + nav#site-nav, input#show-site-nav { + display: none !important; + /* Hide navigation from all print */ + } +} + +/* + * Main content +*/ + +@media screen { + main { + display: flex; + flex-direction: row; + flex-wrap: wrap; + background: white; + } + main>* { + padding: 2rem; + box-sizing: border-box; + max-width: 100%; + order: 2; + } + main>*>* { + max-width: 100%; + } + main #theme-breadcrumbs { + flex-basis: 100%; + order: 0; + } + main .theme-prev-next { + flex-basis: 100%; + order: 0; + } + main .theme-prev-next-prev { + float:left; + margin-right: 5px; + } + main .theme-prev-next-next { + float:right; + margin-left: 5px; + } + main>h1 { + flex-basis: 100%; + margin: 0; + order: 1; + } + main .content { + flex: 2 2 60%; + } + main .page-information { + flex: 1 1 33%; + order: 3; + } +} + +@media screen and (min-width:68em) { + main { + padding: 4em; + } + main>h1 { + font-size: 3em; + margin-bottom: .25em; + } +} + +@media print { + main { + display: block !important; + page-break-after: always; + } + main+hr { + display: none; + } + main>h1 { + padding: 1em 3.5rem; + font-size: 3em; + } + main .page-information { + page-break-after: always; + } +} + +/* + * Content + */ + +#bpmn-canvas { + height: 50vh; + border: 1px solid lightgrey; + border-radius: 2px; + max-width: 50em; + max-height: 50vw; + margin-bottom: 1em; + page-break-inside: avoid; +} +#bpmn-canvas .bjs-powered-by { + display: none; +} + +main .content>article>:first-child:not(h1):not(h2):not(ol):not(ul) { + font-size: 1.15em; +} + +/* + * Markdown content + */ + +@media print { + .markdown-body { + font-family: "Muli" + } + + .markdown-body h1, .markdown-body h2, .markdown-body h3 { + font-weight: normal; + position: relative; + } + .markdown-body h1 { + font-size: 1.5cm; + border-bottom: none; + } + .markdown-body h2 { + font-size: 1.5em; + } + .markdown-body h3 { + font-size: 1em; + font-weight: bold; + } + .markdown-body h4 { + font-size: 1em; + font-weight: normal; + } + .markdown-body h4 { + font-weight: bold; + } +} + +/* + * Page information section + */ + + @media screen { + main section.page-information { + flex: 1 2 300px; + box-sizing: border-box; + display: flex; + flex-direction: column; + } +} + +/* + * Table of contents +*/ + +/* + * Navigation lists +*/ + +@media screen { + nav#site-nav>ul:before { + color: lightgrey; + text-align: center; + font-size: 1em; + line-height: 2; + display: block; + border-bottom: 1px solid; + } + ol.table-of-contents, nav#site-nav>ul { + list-style: none; + flex: 1 1 auto; + overflow: hidden; + margin: 0 0; + padding: 0; + box-sizing: border-box; + } + + ol.table-of-contents li, nav#site-nav>ul li { + margin: .5em 0; + } + ol.table-of-contents>li, nav#site-nav>ul>li { + font-size: 1.15rem; + padding-bottom: 0.5em; + } + ol.table-of-contents>li ol, nav#site-nav>ul>li ul { + padding-left: 1em; + list-style: none; + } + ol.table-of-contents>li>ol>li, nav#site-nav>ul>li>ul>li { + font-size: 1rem; + } +} + +@media print { + nav#site-nav>ul:before { + font-size: 1.5em; + font-weight: bold; + padding-left: 0; + } +} + +/* + * Breadcrumbs + */ + +#theme-breadcrumbs { + padding-top: 0; + padding-bottom: 0; + background-color: white; +} + +#theme-breadcrumbs ul { + padding: 0; + margin: 0; + list-style: none; + line-height: 2em; +} +#theme-breadcrumbs li { + display: inline-block; + margin: -1.15em 0; + max-width: 100%; + text-overflow: ellipsis; + white-space: nowrap; + overflow: hidden; +} + +#theme-breadcrumbs li::after { + content: '›'; + display: inline-block; + opacity: 0.3; + font-size: 1em; + padding: .5em; + line-height: 0; +} + +@media print { + #theme-breadcrumbs { + display: none; + } +} + +/* + * Edit links +*/ + +main .edit-links { + padding-left: 0; +} +main .edit-links li { + list-style-type: none; +} +main .edit-links li a { + margin-bottom: 0.5em; + padding: 0.5em; + text-decoration: none; + border-radius: 2px; + display: inline-block; + border: 1px solid lightgrey; +} +main .edit-links li a:link { + border-bottom: 1px solid blue; +} +main .edit-links li a:visited { + border-bottom: 1px solid purple; +} +main .edit-links a svg { + vertical-align: -2px; +} +@media print { + h3#page-edit-links, main .edit-links { + display: none; + } +} + +/* + * Metadata display + */ + +.metadata tbody { + width: 100%; +} +.metadata tr { + margin: .25em 0 0 0; +} +.metadata .expired { + color: red; +} +.metadata td, .metadata th { + padding: 0, 0.5em, 0.5em, 0; + text-align: left; + vertical-align: top; +} + +/* + * Footer + */ + +@media screen { + .footer-trio { + width: 100%; + display: flex; + flex-direction: row; + justify-content: space-between; + } + .footer-trio section { + background: white; + width: calc(33.33% - 15px); + max-width: none; + padding: 30px; + box-sizing: border-box; + display: flex; + flex-direction: column; + justify-content: space-between; + } + .footer-trio h2 { + margin: 0px; + } + .footer-links { + text-align: right; + } + .footer-trio section a { + font-weight: 700; + text-decoration: none; + display: inline-block; + clear: both; + float: right; + margin-top: 15px; + } + .footer-trio section a:after { + content: '>'; + padding-left: 8px; + } + + .footer-duo { + width: 100%; + margin: 50px 0px; + display: flex; + flex-direction: row; + justify-content: space-between; + } + .footer-contact { + width: calc(33.33% - 15px); + max-width: none; + padding-left: 30px; + box-sizing: border-box; + } + .footer-contact dl { + width: 100%; + display: flex; + flex-flow: row; + flex-wrap: wrap; + overflow: visible; + } + .footer-contact dt { + font-weight: 700; + flex: 0 0 100px; + } + .footer-contact dd { + margin-left: auto; + text-align: left; + flex: 0 0 calc(100% - 100px); + display: block; + padding-bottom: 1em; + } + .footer-contact dd a { + } + .footer-contact dd address { + font-style: normal; + } + + .footer-notes { + width: calc(66.67% - 7.5px); + max-width: none; + padding-left: 30px; + box-sizing: border-box; + } + .footer-note-cluster { + margin-top: 30px; + } + .footer-last-updated::before { + content:''; + background-image: url("data:image/svg+xml;charset=UTF-8,%3csvg version='1.1' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' x='0px' y='0px' width='16px' height='16px' viewBox='0 0 16 16' style='overflow:visible;enable-background:new 0 0 16 16;' xml:space='preserve' aria-hidden='true'%3e%3cpath fill-rule='evenodd' fill='black' d='M1.5 8a6.5 6.5 0 1113 0 6.5 6.5 0 01-13 0zM8 0a8 8 0 100 16A8 8 0 008 0zm.5 4.75a.75.75 0 00-1.5 0v3.5a.75.75 0 00.471.696l2.5 1a.75.75 0 00.557-1.392L8.5 7.742V4.75z'%3e%3c/path%3e%3c/svg%3e"); + background-repeat: no-repeat; + width: 16px; + height: 16px; + position: relative; + margin-right: 8px; + display: inline-block; + transform: translateY(3px); + } + .footer-copyright::before { + content:''; + background-image: url("data:image/svg+xml;charset=UTF-8,%3csvg version='1.1' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' x='0px' y='0px' width='16px' height='16px' viewBox='0 0 16 16' style='overflow:visible;enable-background:new 0 0 16 16;' xml:space='preserve' aria-hidden='true'%3e%3cpath fill='black' d='M1.5,8c0-1.7,0.7-3.4,1.9-4.6C4.6,2.2,6.3,1.5,8,1.5s3.4,0.7,4.6,1.9c1.2,1.2,1.9,2.9,1.9,4.6s-0.7,3.4-1.9,4.6 S9.7,14.5,8,14.5s-3.4-0.7-4.6-1.9C2.2,11.4,1.5,9.7,1.5,8z M8,0C5.9,0,3.8,0.8,2.3,2.3C0.8,3.8,0,5.9,0,8c0,2.1,0.8,4.2,2.3,5.7 C3.8,15.2,5.9,16,8,16c2.1,0,4.2-0.8,5.7-2.3C15.2,12.2,16,10.1,16,8c0-2.1-0.8-4.2-2.3-5.7C12.2,0.8,10.1,0,8,0z'/%3e%3cpath fill='black' class='st0' d='M8,5.8c-1.2,0-2.2,1-2.2,2.2s1,2.2,2.2,2.2c0.6,0,1.1-0.2,1.5-0.6c0.3-0.3,0.8-0.3,1.1,0c0.3,0.3,0.3,0.8,0,1.1 c-0.7,0.6-1.6,1-2.6,1c-2.1,0-3.7-1.7-3.7-3.8c0-2.1,1.6-3.8,3.7-3.8c1,0,1.9,0.4,2.6,1c0.3,0.3,0.3,0.8,0,1.1 c-0.3,0.3-0.8,0.3-1.1,0C9.1,6,8.5,5.8,8,5.8z'/%3e%3c/svg%3e"); + background-repeat: no-repeat; + width: 16px; + height: 16px; + position: relative; + margin-right: 8px; + display: inline-block; + transform: translateY(3px); + } + .footer-license::before { + content:''; + background-image: url("data:image/svg+xml;charset=UTF-8,%3csvg version='1.1' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' x='0px' y='0px' width='16px' height='16px' viewBox='0 0 16 16' style='overflow:visible;enable-background:new 0 0 16 16;' xml:space='preserve' aria-hidden='true'%3e%3cpath fill-rule='evenodd' fill='black' d='M8.75.75a.75.75 0 00-1.5 0V2h-.984c-.305 0-.604.08-.869.23l-1.288.737A.25.25 0 013.984 3H1.75a.75.75 0 000 1.5h.428L.066 9.192a.75.75 0 00.154.838l.53-.53-.53.53v.001l.002.002.002.002.006.006.016.015.045.04a3.514 3.514 0 00.686.45A4.492 4.492 0 003 11c.88 0 1.556-.22 2.023-.454a3.515 3.515 0 00.686-.45l.045-.04.016-.015.006-.006.002-.002.001-.002L5.25 9.5l.53.53a.75.75 0 00.154-.838L3.822 4.5h.162c.305 0 .604-.08.869-.23l1.289-.737a.25.25 0 01.124-.033h.984V13h-2.5a.75.75 0 000 1.5h6.5a.75.75 0 000-1.5h-2.5V3.5h.984a.25.25 0 01.124.033l1.29.736c.264.152.563.231.868.231h.162l-2.112 4.692a.75.75 0 00.154.838l.53-.53-.53.53v.001l.002.002.002.002.006.006.016.015.045.04a3.517 3.517 0 00.686.45A4.492 4.492 0 0013 11c.88 0 1.556-.22 2.023-.454a3.512 3.512 0 00.686-.45l.045-.04.01-.01.006-.005.006-.006.002-.002.001-.002-.529-.531.53.53a.75.75 0 00.154-.838L13.823 4.5h.427a.75.75 0 000-1.5h-2.234a.25.25 0 01-.124-.033l-1.29-.736A1.75 1.75 0 009.735 2H8.75V.75zM1.695 9.227c.285.135.718.273 1.305.273s1.02-.138 1.305-.273L3 6.327l-1.305 2.9zm10 0c.285.135.718.273 1.305.273s1.02-.138 1.305-.273L13 6.327l-1.305 2.9z'%3e%3c/path%3e%3c/svg%3e"); + background-repeat: no-repeat; + width: 16px; + height: 16px; + position: relative; + margin-right: 8px; + display: inline-block; + transform: translateY(3px); + } + + #search-repository>button { + border-bottom-color: blue; + } + + @media screen and (max-width: 1000px) { + .footer-contact dl { + flex-flow: column; + } + .footer-contact dt { + flex: 0 0 auto; + } + .footer-contact dd { + margin-left: 0; + flex: 0 0 auto; + } + } + + @media screen and (max-width: 800px) { + .footer-trio { + flex-direction: column; + } + .footer-trio section { + width: 100%; + margin-bottom: 20px; + } + .footer-duo { + flex-direction: column; + } + .footer-duo section { + width: 100%; + } + } +} +@media print { + footer { + page-break-after: always; + } + #search-repository { + display: none; + } +} diff --git a/_site/assets/unlock.svg b/_site/assets/unlock.svg new file mode 100644 index 00000000..6510b4d6 --- /dev/null +++ b/_site/assets/unlock.svg @@ -0,0 +1,36 @@ + + + + + + image/svg+xml + + Unlock public code + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_site/assets/version-badge.svg b/_site/assets/version-badge.svg new file mode 100644 index 00000000..26d99837 --- /dev/null +++ b/_site/assets/version-badge.svg @@ -0,0 +1,25 @@ + + + + + + version: 0.7.1 + + + + + + + + + + + + + + + version + + 0.7.1 + + diff --git a/_site/criteria/advertise-maturity.html b/_site/criteria/advertise-maturity.html new file mode 100644 index 00000000..f159d99e --- /dev/null +++ b/_site/criteria/advertise-maturity.html @@ -0,0 +1,11 @@ + + + + Redirecting… + + + + +

Redirecting…

+ Click here if you are not redirected. + diff --git a/_site/criteria/bundle-policy-and-code.html b/_site/criteria/bundle-policy-and-code.html new file mode 100644 index 00000000..1ce82743 --- /dev/null +++ b/_site/criteria/bundle-policy-and-code.html @@ -0,0 +1,11 @@ + + + + Redirecting… + + + + +

Redirecting…

+ Click here if you are not redirected. + diff --git a/_site/criteria/bundle-policy-and-source-code.html b/_site/criteria/bundle-policy-and-source-code.html new file mode 100644 index 00000000..59d1c23c --- /dev/null +++ b/_site/criteria/bundle-policy-and-source-code.html @@ -0,0 +1,501 @@ + + + + + + + + + 政策與原始碼要合捆, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +← 原始碼要開放 + + + + + + + + +程式基底要可重複使用且可移植 → + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 需求規定
    2. +
  2. 測試方式
    3. +
  3. 公共政策制定者：需要的工作
    4. +
  4. 管理人員：需要的工作
    5. +
  5. 開發人員與設計師：需要的工作
    6. +
  6. 延伸閱讀
    7. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

政策與原始碼要合捆

+ +

對於想根據所在情境實作程式基底的人，或是想更進一步貢獻程式基底開發的人來說，能同時取用原始 +碼與政策文件兩者，可作為建置成品時的基礎組件。

+ +

瞭解作用範疇與該範疇的政策是基本原則，才能瞭解程式基底試圖想解決的問題是什麼，以及該如何解決這些問題的作法。

+ +

為了評估是否需要在新的情境中實作程式基底，組織單位需要瞭解必須做出改變的程序有哪些，或是如何對現有解決方案付出額外調整設定，以適應新的情境背景。

+ +

需求規定

+ +
    +
  • 程式基底「必須」包含原始碼所根據的政策。
    • +
  • 如果政策根據原始碼而來，則該原始碼「必須」包含在程式基底中，用於偵測詐騙的原始碼則可除外。
    • +
  • 政策「應該」採用機器可讀且明確的格式。
    • +
  • 持續整合測試「應該」驗證原始碼與政策是否有一致執行。
    • +
+ +

測試方式

+ +
    +
  • 與公務人員確認原始碼所根據的所有政策內容都有收錄在內。
    • +
  • 與公務人員確認政策所根據的所有原始碼都有收錄在內。
    • +
  • 確認政策內容是否能在機器上解讀。
    • +
  • 確認原始碼與政策間的執行一致性能通過持續整合測試。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 與開發人員及設計師合作，確保政策法規與原始碼之間沒有不相符之處。
    • +
  • 提供相關政策內文，以便收錄於儲存庫中；如果政策內文沒有英文版，請提供英文版摘要。務必也同時包含貴組織單 +位所選擇遵守的各項標準，以及影響貴組織單位程式基底開發或部署情境的任何組織單位流程。
    • +
  • 請提供政策相關參考資料與連結。
    • +
  • 政策內容請使用明確且機器可讀的格式，像是物件管理群體所發表的格式。
    • +
  • 追蹤政策時，請使用與追蹤原始碼相同的版本控制與文件。
    • +
  • 定期檢查，瞭解程式基底中的原始碼如何變動，以及是否仍然符合政策意圖。
    • +
  • 納入會影響社會群體、程式基底與開發目標的相關政策，包含 GDPR 一般資料保護規 +則或是歐盟網頁無障礙命 +令等此類法律義務，或者是人權政 +策，例如公家機關對機會平等的承諾等。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 讓政策制定者、開發人員與設計師持續參與，並且在整個開發過程中保持聯繫溝通。
    • +
  • 確保政策制定者、開發人員與設計師朝相同目標努力。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 熟悉並且學會貴組織單位政策制定者所使用的流程模型標記法。
    • +
  • 與政策制定者一同合作，確保政策法規與原始碼之間沒有不相符之處。
    • +
  • 針對如何讓政策文字更清楚提供意見。
    • +
+ +

延伸閱讀

+ + + +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/criteria/code-in-the-open.html b/_site/criteria/code-in-the-open.html new file mode 100644 index 00000000..2ed413eb --- /dev/null +++ b/_site/criteria/code-in-the-open.html @@ -0,0 +1,492 @@ + + + + + + + + + 原始碼要開放, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +← 準則 + + + + + + + + +政策與原始碼要合捆 → + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 需求規定
    2. +
  2. 測試方式
    3. +
  3. 公共政策制定者：需要的工作
    4. +
  4. 管理人員：需要的工作
    5. +
  5. 開發人員與設計師：需要的工作
    6. +
  6. 延伸閱讀
    7. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

原始碼要開放

+ +

以開放精神編寫原始碼，能改善資訊透明、提高原始碼品質、讓原始碼更容易稽核，也能促進互相協作。

+ +

這些合在一起，讓公民更有機會瞭解軟體與政策如何影響他們與公家機關的互動。

+ +

需求規定

+ +
    +
  • 任何使用中政策的所有原始碼都「必須」要公開（用於偵測詐欺的原始碼除外），且能供民眾取用。
    • +
  • 任何使用中軟體的所有原始碼都「必須」要公開（用於偵測詐欺的原始碼除外），且能供民眾取用。
    • +
  • 程式基底「禁止」包含與使用者及其組織單位，或與第三方相關的敏感性資訊。
    • +
  • 目前非使用中的任何原始碼（像是新版本、提案版本，或較舊版本）都「應該」公開。
    • +
  • 「可選擇」是否要以文件記錄一般大眾與組織單位之間可能發生的任何特定互動，其背後所採用的原始碼或 +支持的政策。
    • +
+ +

測試方式

+ +
    +
  • 確認目前使用中的每個版本都有公布原始碼在網際網路上，而且民眾不需要經過任何形式的身分核對或授權，就能在原始貢獻組織以外，查看這些原始碼。
    • +
  • 確認程式基底檔案與送交版次歷史紀錄，不包含敏感性資訊。
    • +
  • 檢查目前非使用中的原始碼是否有公開。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 制定合乎開放精神的政策。
    • +
  • 以公開透明的政策為優先。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 孕育擁抱開放、重視學習、歡迎意見回饋的文化。
    • +
  • 與外部供應商和自由工作者以開放精神的方式協作。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 審查人員在檢核每次的送交版次紀錄時，要確實核對內容沒有包含組態設定、使用者名稱或密碼、公開金鑰，或其他產品系統中使用的實名憑證等敏感性資訊。
    • +
  • 為符合上述敏感性資訊的相關規定，請明確分開資料與原始碼。
    • +
+ +

延伸閱讀

+ + + +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/criteria/continuous-integration.html b/_site/criteria/continuous-integration.html new file mode 100644 index 00000000..1136b0be --- /dev/null +++ b/_site/criteria/continuous-integration.html @@ -0,0 +1,11 @@ + + + + Redirecting… + + + + +

Redirecting…

+ Click here if you are not redirected. + diff --git a/_site/criteria/create-reusable-and-portable-code.html b/_site/criteria/create-reusable-and-portable-code.html new file mode 100644 index 00000000..3220819c --- /dev/null +++ b/_site/criteria/create-reusable-and-portable-code.html @@ -0,0 +1,11 @@ + + + + Redirecting… + + + + +

Redirecting…

+ Click here if you are not redirected. + diff --git a/_site/criteria/document-codebase-maturity.html b/_site/criteria/document-codebase-maturity.html new file mode 100644 index 00000000..f98de071 --- /dev/null +++ b/_site/criteria/document-codebase-maturity.html @@ -0,0 +1,483 @@ + + + + + + + + + 記錄程式基底成熟度, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +← 風格要前後一致 + + + + + + + + + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 需求規定
    2. +
  2. 測試方式
    3. +
  3. 公共政策制定者：需要的工作
    4. +
  4. 管理人員：需要的工作
    5. +
  5. 開發人員與設計師：需要的工作
    6. +
  6. 延伸閱讀
    7. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

記錄程式基底成熟度

+ +

清楚標示程式基底的成熟度，有助於他人決定是否要使用，或為該程式基底做出貢獻。程式基底版本的成熟度，包含其依賴項 +目的成熟度。瞭解程式基底演進到什麼程度，是理解該程式基底並知道如何做出貢獻的關鍵。

+ +

需求規定

+ +
    +
  • 程式基底「必須」註明版本編號。
    • +
  • 程式基底「必須」明確以文件記錄，是否有已經準備好可供使用的版本。
    • +
  • 準備好可供使用的程式基底版本，「必須」只能依賴其他也已經準備好可供使用的程式基底版本。
    • +
  • 程式基底「應該」包含每次版本的變動紀錄，像是以「CHANGELOG」日誌格式檔記錄。
    • +
  • 「應該」要以文件記錄分配版本識別碼的方法。
    • +
  • 「可選擇」是否採用語意化版本控制編號。
    • +
+ +

測試方式

+ +
    +
  • 確認程式基底有版本編號策略，且有文件記載該策略。
    • +
  • 確認政策制定者、管理人員、開發人員與設計師等，都能清楚知道程式基底是否有準備好可供使用的版本。
    • +
  • 確認準備好可供使用的程式基底版本，並不依賴任何尚未準備好可供使用的其他程式基底的版本。
    • +
  • 確認有文件記錄程式基底的版本編號方法，並且確實遵守。
    • +
  • 確認是否有版本的變動紀錄。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 制定政策時，請記住任何開發出來的原始碼都必須先經過 +測試與改善，才能夠投入服務。
    • +
  • 考慮將政策的變動註明版本編號，尤其是因而觸發新版本原始碼開發的情況。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 要確認服務依賴的程式基底版本成熟度，等同或高於該服務本身。舉例來說，正式上線的服務不要使用 beta 公測版程式基底。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 確認所有發行版，都有遵守程式基底的版本控制編號作法。
    • +
+ +

延伸閱讀

+ + + +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/criteria/document-codebase-objectives.html b/_site/criteria/document-codebase-objectives.html new file mode 100644 index 00000000..7e0c09eb --- /dev/null +++ b/_site/criteria/document-codebase-objectives.html @@ -0,0 +1,478 @@ + + + + + + + + + 程式基底要有目標文件, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +← 要求審查貢獻內容 + + + + + + + + +程式碼要有文件 → + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 需求規定
    2. +
  2. 測試方式
    3. +
  3. 公共政策制定者：需要的工作
    4. +
  4. 管理人員：需要的工作
    5. +
  5. 開發人員與設計師：需要的工作
    6. +
  6. 延伸閱讀
    7. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

程式基底要有目標文件

+ +

以文件清楚記錄程式基底目標，來傳達程式基底的用途目標。這能幫助利害關係人與貢獻者劃定程式基底的開發範圍。這些目 +標也能方便人們判斷，是否在當下或未來，會對此程式基底或其模組感興趣。

+ +

需求規定

+ +
    +
  • 程式基底「必須」包含描寫目標的文件，像是主旨、使命或目標陳述。開發人員與設計師需要能夠瞭解這些，他們才知道可以怎樣使用程式基底或協助貢獻。
    • +
  • 程式基底文件「應該」清楚描述政策目標與程式基底目標之間的關聯。
    • +
  • 「可選擇」是否以文件記錄給一般大眾看的程式基底目標。
    • +
+ +

測試方式

+ +
    +
  • 確認程式基底文件有包含程式基底目標，或主旨、使命等。
    • +
  • 查看政策目標與程式基底目標之間關聯的描述。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 將政策目標加入程式基底文件中，例如「README」文件當中。
    • +
  • 確保所有程式基底目標，有連結或引用為了符合〈政策與原始碼要合捆〉準則而加入的支持政策文 +件。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 將單位目標、組織目標或業務目標加入程式基底文件中，例如「README」文件當中。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 將技術與設計目標加入程式基底文件中，例如「README」文件當中。
    • +
+ +

延伸閱讀

+ + + +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/criteria/document-maturity.html b/_site/criteria/document-maturity.html new file mode 100644 index 00000000..f159d99e --- /dev/null +++ b/_site/criteria/document-maturity.html @@ -0,0 +1,11 @@ + + + + Redirecting… + + + + +

Redirecting…

+ Click here if you are not redirected. + diff --git a/_site/criteria/document-objectives.html b/_site/criteria/document-objectives.html new file mode 100644 index 00000000..f8c50e56 --- /dev/null +++ b/_site/criteria/document-objectives.html @@ -0,0 +1,11 @@ + + + + Redirecting… + + + + +

Redirecting…

+ Click here if you are not redirected. + diff --git a/_site/criteria/document-the-code.html b/_site/criteria/document-the-code.html new file mode 100644 index 00000000..2ea9a10e --- /dev/null +++ b/_site/criteria/document-the-code.html @@ -0,0 +1,490 @@ + + + + + + + + + 程式碼要有文件, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +← 程式基底要有目標文件 + + + + + + + + +使用白話的英語 → + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 需求規定
    2. +
  2. 測試方式
    3. +
  3. 公共政策制定者：需要的工作
    4. +
  4. 管理人員：需要的工作
    5. +
  5. 開發人員與設計師：需要的工作
    6. +
  6. 延伸閱讀
    7. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

程式碼要有文件

+ +

文件記錄周全的原始碼能幫助人們瞭解該原始碼的作用與使用方式。文件紀錄是幫助人們快速上手如何使用程式基 +底，並做出貢獻的關鍵。

+ +

需求規定

+ +
    +
  • 程式基底的所有功能、政策及原始碼，都「必須」以可清楚瞭解的用語描述，讓懂程式基底目的用途的人也能夠理解。
    • +
  • 程式基底文件「必須」說明如何安裝與執行軟體。
    • +
  • 程式基底文件「必須」為關鍵功能舉出範例。
    • +
  • 程式基底文件「應該」包含精要的說明，讓一般大眾和記者等廣泛的利害關係人都能清楚明白。
    • +
  • 程式基底文件「應該」有一部分用來說明，如何安裝與執行原始碼的單機版；如果有必要，也應該包含測試資料集。
    • +
  • 程式基底文件「應該」包含所有功能的範例。
    • +
  • 程式碼文件「應該」描述程式基底的主要組件或模組，以及其彼此之間的關係，例如以高層架構圖表示。
    • +
  • 「應該」要有針對文件品質的持續整合測試。
    • +
  • 「可選擇」是否在程式基底文件中，包含讓使用者想要立即使用程式基底的範例。
    • +
+ +

測試方式

+ +
    +
  • 確認文件內容能讓其他利害關係人、其他公家機關的專業人士，以及一般大眾，都可以清楚明白。
    • +
  • 確認文件有說明如何安裝與執行原始碼。
    • +
  • 確認文件有包含主要功能的範例。
    • +
  • 向一般大眾的成員以及記者確認，他們是否能明白文件當中的精要說明。
    • +
  • 檢查單機版原始碼的安裝與執行的步驟說明，確認能順利執行系統。
    • +
  • 檢查文件中列舉的所有功能都包含範例。
    • +
  • 檢查文件中是否包含高層架構圖，或類似的組件關係圖表。
    • +
  • 確認整合測試有包含到程式碼文件品質，例如確認生成的文件是否正確，並檢查連結與圖片等。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 定期查看程式基底中非政策程式碼的變動情況。
    • +
  • 針對如何讓非政策文件更清楚易懂提供意見回饋。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 嘗試使用程式基底，並提供您的意見回饋來讓政策與原始碼文件改善得更加清楚。舉例來說，可以自問目前的文件是否足以說服另一個公家機關的管理人員使用這套程式基底？
    • +
  • 確保您同時瞭解政策、原始碼以及文件內容。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 定期查看程式基底中非原始碼部分的變動情況。
    • +
  • 針對如何讓非原始碼文件更清楚易懂提供意見回饋。
    • +
+ +

延伸閱讀

+ + + +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/criteria/documenting.html b/_site/criteria/documenting.html new file mode 100644 index 00000000..e513d32e --- /dev/null +++ b/_site/criteria/documenting.html @@ -0,0 +1,11 @@ + + + + Redirecting… + + + + +

Redirecting…

+ Click here if you are not redirected. + diff --git a/_site/criteria/findability.html b/_site/criteria/findability.html new file mode 100644 index 00000000..2390e655 --- /dev/null +++ b/_site/criteria/findability.html @@ -0,0 +1,11 @@ + + + + Redirecting… + + + + +

Redirecting…

+ Click here if you are not redirected. + diff --git a/_site/criteria/index.html b/_site/criteria/index.html new file mode 100644 index 00000000..4126b85c --- /dev/null +++ b/_site/criteria/index.html @@ -0,0 +1,473 @@ + + + + + + + + + 準則, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +原始碼要開放 → + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + +

目次

+ + + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ + +
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/criteria/index.md b/_site/criteria/index.md new file mode 100644 index 00000000..7891057e --- /dev/null +++ b/_site/criteria/index.md @@ -0,0 +1,11 @@ +# 準則 + + + + +{% assign sorted = site.pages | sort:"order" %} + +{% for page in sorted %}{% if page.dir == "/criteria/" %}{% if page.name != +"index.md" %}{% if page.title %} + +1. [{{page.title}}]({{page.url}}){% endif%} {% endif%} {% endif%}{% endfor %} diff --git a/_site/criteria/maintain-version-control.html b/_site/criteria/maintain-version-control.html new file mode 100644 index 00000000..06a52b03 --- /dev/null +++ b/_site/criteria/maintain-version-control.html @@ -0,0 +1,504 @@ + + + + + + + + + 維護版本控制, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +← 貢獻要容易 + + + + + + + + +要求審查貢獻內容 → + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 需求規定
    2. +
  2. 測試方式
    3. +
  3. 公共政策制定者：需要的工作
    4. +
  4. 管理人員：需要的工作
    5. +
  5. 開發人員與設計師：需要的工作
    6. +
  6. 延伸閱讀
    7. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

維護版本控制

+ +

版本控制主要在追蹤原始碼以及其他程 +式基底檔案歷來的變動。這能讓您為程式基底維護有條理的變動歷史文件。這是大規模協作得以運作的要素，使開發人員可以 +針對修改變動平行作業，並幫助未來的開發人員瞭解做出修改的原因。

+ +

需求規定

+ +
    +
  • 程式基底中的所有檔案皆「必須」有版本控制。
    • +
  • 所有決定皆「必須」記錄成送交版次訊息。
    • +
  • 每份送交版次訊息皆「必須」盡可能附上討論與議題連結。
    • +
  • 程式基底「應該」以分散式版本控制系統作維護。
    • +
  • 貢獻守則「應該」要求貢獻者，將相關的修改變動以群組分類方式送交。
    • +
  • 維護人員「應該」使用像是修訂版次標記，或文字標籤，來標示程式基底正式發行的版本。
    • +
  • 貢獻守則「應該」鼓勵採用能在版本控制系統中，輕鬆檢視與瞭解檔案中何處有做出更動的檔案格式。
    • +
  • 貢獻者「可選擇」是否對送交內容作簽章，並附上電子郵件信箱，以便當未來貢獻者對其內容有疑問時，可以與之前的貢獻者聯絡。
    • +
+ +

測試方式

+ +
    +
  • 確認程式基底維持在版本控制狀態中，像是使用 Git 之類的軟體。
    • +
  • 審查送交版次歷史紀錄，確認所有的送交版次訊息，皆有解釋程式碼修改變動的原因。
    • +
  • 審查送交版次歷史紀錄，確認所有送交版次訊息之中，盡可能在所有討論過修改變更的地方，包含變動內容以及連結位置（提供網址）。
    • +
  • 檢查版本控制系統是否為分散式。
    • +
  • 審查送交版次歷史紀錄，檢查是否有根據貢獻指引將相關的程式碼變動以群組分類。
    • +
  • 檢查是否可能透過像是修訂版次標記，或文字標籤，來取用程式基底中的特定版本。
    • +
  • 檢查程式基底在盡可能的情況下，檔案都是採用文字格式。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 如果因為政策改變而在程式基底中有新的版本，則請確認有在文件中清楚說明： +
      +
    • 政策改變的地方，
      • +
    • 程式基底如何因應而改變。
      • +
    +
    • +
+ +

舉例來說，為程式基底作權限管理時，如果要新增申請方類別來賦予取用權，應視為一種政策變動。

+ +

管理人員：需要的工作

+ +
    +
  • 支持政策制定者、開發人員與設計師，使其能清楚表達他們對程式基底做出的改善。確保改善程式基底不會有公關風險。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 確認版本控制系統中，有瞭解程式碼、建置與部署所需要用到的所有檔案。
    • +
  • 送交版次訊息要寫清楚，讓人一看就能瞭解送交修改的原因。
    • +
  • 使用像是修訂版次標記，或文字標籤來標示不同版本，以方便取用特定版本。
    • +
  • 送交版次訊息要寫清楚，方便之後比較各版本。
    • +
  • 在政策改變以後，與政策制定者合作說明原始碼更新的部分。
    • +
+ +

延伸閱讀

+ + + +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/criteria/make-contributing-easy.html b/_site/criteria/make-contributing-easy.html new file mode 100644 index 00000000..2663c498 --- /dev/null +++ b/_site/criteria/make-contributing-easy.html @@ -0,0 +1,489 @@ + + + + + + + + + 貢獻要容易, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +← 歡迎貢獻者 + + + + + + + + +維護版本控制 → + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 需求規定
    2. +
  2. 測試方式
    3. +
  3. 公共政策制定者：需要的工作
    4. +
  4. 管理人員：需要的工作
    5. +
  5. 開發人員與設計師：需要的工作
    6. +
  6. 延伸閱讀
    7. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

貢獻要容易

+ +

若要開發更好、更可靠且功能更豐富的軟體，使用者需要能夠為共享的程式基底修正問題、新增功能，以及提出安全性議題 +等。

+ +

共享的數位基礎建設讓協作貢獻更容易。使用者讓程式基底接受貢獻時所需付出的心力越少，則使用者越可能成為貢獻者。

+ +

需求規定

+ +
    +
  • 程式基底「必須」有個可以公開接受任何人建議的議題追蹤器。
    • +
  • 文件中「必須」同時有公開的議題追蹤器連結，以及已提交的程式基底變動的連結，例如記錄在「README」檔案中。
    • +
  • 程式基底「必須」要有能與使用者以及開發人員溝通的管道，像是設立電子郵件列表（郵遞論壇）。
    • +
  • 「必須」有透過封閉管道通報安全性問題的方法，來達成負責任的揭露。
    • +
  • 文件「必須」說明，該如何通報潛在的安全性與敏感性問題。
    • +
+ +

測試方式

+ +
    +
  • 確認有公開的議題追蹤器。
    • +
  • 確認程式基底有公開的議題追蹤器連結，以及已提交的程式基底變動的連結。
    • +
  • 確認可以使用程式基底中提到的管道，與其他使用者以及開發人員一同討論該軟體。
    • +
  • 確認有封閉的管道可通報安全性問題。
    • +
  • 確認有說明如何私下通報安全性問題。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 追蹤程式基底中的政策問題，讓相關的外部政策專家如果自願也能夠協助。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 追蹤程式基底中的管理問題，讓有相關經驗的外部管理人員如果自願也能夠協助。
    • +
  • 支持您經驗豐富的政策制定者、開發人員與設計師，使其盡可能為程式基底持續做出長久貢獻。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 與審查流程相同，務必迅速回應請求。
    • +
  • 告知管理人員，您在支援其他貢獻者時所需的時間與資源。
    • +
  • 確保人們可輕鬆找到合適的溝通管道，來詢問維護人員與利害關係人問題，例如寫在「README」文件當中。
    • +
  • 確保中介資料包含合適的聯絡資訊，例如寫在 publiccode.yml 檔案中。
    • +
+ +

延伸閱讀

+ + + +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/criteria/make-the-codebase-findable.html b/_site/criteria/make-the-codebase-findable.html new file mode 100644 index 00000000..0222502c --- /dev/null +++ b/_site/criteria/make-the-codebase-findable.html @@ -0,0 +1,511 @@ + + + + + + + + + 程式基底可查詢得到, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +← 發行採用開放授權 + + + + + + + + +風格要前後一致 → + + + + + + + + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 需求規定
    2. +
  2. 測試方式
    3. +
  3. 公共政策制定者：需要的工作
    4. +
  4. 管理人員：需要的工作
    5. +
  5. 開發人員與設計師：需要的工作
    6. +
  6. 延伸閱讀
    7. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

程式基底可查詢得到

+ +

一旦程式基底越容易被發現，更多的潛在協作者也就找得到它。不能只是發表個程式基底，然後就盼望他人找得到這套程式基 +底，更需要主動積極。

+ +

有中介資料說明檔的話，會讓程式基底更容易被發現。良好且包含永久唯一識別碼的中介資料，例如寫成 Wikidata 維基數據條目，或是放到 FSF 自由軟體基金會的軟體 +目錄列表之中（使程式基底成為語意網路中的一部份），他人就能更容易透過第三方工具參考、引用、辨別、發現程式基底。

+ +

需求規定

+ +
    +
  • 程式基底名稱「應該」要能描述說明其用途，且不包含任何首字母縮寫字、縮寫、雙關語，或組織單位品牌名稱或抬頭等。
    • +
  • 程式基底說明「應該」要簡短，幫助他人瞭解程式基底的目的與作用。
    • +
  • 維護人員「應該」將程式基底提交至相關的軟體目錄上。
    • +
  • 程式基底「應該」要架設網站，內容中以程式基底各類潛在使用者（技術人員、政策專家、管理人員等）偏好的業內用語，描述程式基底所能解決的問題。
    • +
  • 在搜尋引擎查找程式基底名稱時，「應該」能搜尋得到程式基底。
    • +
  • 在使用搜尋引擎時，如果以自然語言描述程式基底所能解決的問題，「應該」能搜尋得到程式基底。
    • +
  • 程式基底「應該」具備永久唯一識別碼，而且該項條目要提及主要貢獻者、儲存庫、位置、網站等。
    • +
  • 程式基底「應該」包含機器可讀的中介資料說明，例如採用 +publiccode.yml格式的檔案。
    • +
  • 「可選擇」是否為程式基底設置專用的網域名稱。
    • +
  • 「可選擇」是否在社群舉辦的會議中定期進行簡報。
    • +
+ +

測試方式

+ +
    +
  • 檢查程式基底名稱是否描述說明其用途，且不包含雙關語。
    • +
  • 檢查程式基底名稱是否不包含任何首字母縮寫字或縮寫，或是其首字母縮寫字或縮寫比完整名稱更熟為人知。
    • +
  • 檢查程式基底是否不包含組織單位品牌名稱或抬頭等，除非該組織單位也是程式基底社群成員。
    • +
  • 檢查程式基底儲存庫是否包含程式基底的簡短描述。
    • +
  • 檢查程式基底有刊登在相關軟體型錄上。
    • +
  • 檢查程式基底的網站有描述程式基底能夠解決的問題。
    • +
  • 檢查以程式基底名稱來作搜尋時，有超過一個的常用主流搜尋引擎，都有將程式基底列在搜尋結果中。
    • +
  • 檢查以自然語言來作搜尋，例如使用程式基底的簡短描述時，有超過一個的常用主流搜尋引擎，都將程式基底放在搜尋結果中。
    • +
  • 檢查永久唯一識別碼條目有提及主要貢獻者。
    • +
  • 檢查永久唯一識別碼條目中有包含儲存庫位置。
    • +
  • 檢查永久唯一識別碼條目有列出程式基底網站。
    • +
  • 檢查中介資料說明檔是機器可讀的格式。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 貢獻一段說明此程式基底作用的政策領域，或所處理問題的描述。
    • +
  • 請那些對程式基底不熟悉且不同領域背景的同事，來測試您的問題描述。
    • +
  • 在相關會議上作簡報，介紹程式基底如何執行政策。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 在決定專案名稱之前，先搜尋過商標資料庫，以避免名稱造成混淆或侵權的問題。
    • +
  • 在引用到程式基底的地方，都使用簡短描述，例如放到社交媒體帳號中的說明。
    • +
  • 為團隊編列內容設計與實作 SEO 搜尋引擎最佳化技能的預算。
    • +
  • 確保專案參與人員出席相關會議，或作簡報介紹。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 實作搜尋引擎最佳化，例如加入網站地圖。
    • +
  • 在引用到程式基底的地方，都使用簡短描述，例如放到儲存庫中的說明。
    • +
  • 請那些對程式基底不熟悉且不同領域背景的同事，來測試您的問題描述。
    • +
  • 推薦適合出席或作簡報介紹的會議，並且在這些會議中出席或作簡報。
    • +
+ +

+ +

延伸閱讀

+ +
    +
  • Wikidata 維基數據社群《維基數據簡 +介》。
    • +
  • FSF 自由軟體基金會《FSF 軟體目錄列表》。
    • +
  • GO FAIR 國際支援與合作辦公室所撰寫的《FAIR 科學資料管理與監督指導原 +則》，提供一份滿好的特性清單，解說哪些特性會讓資料（或中介資料）更容易讓 +機器採取行動（也因此更容易被找到）。其中的部分特性可直接套用到程式基底上，而其他無法直接套用的，我們還需要再研究程式基底與其對應的特性要怎麼處理。
    • +
+ +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/criteria/make-the-codebase-reusable-and-portable.html b/_site/criteria/make-the-codebase-reusable-and-portable.html new file mode 100644 index 00000000..fc6c3c4d --- /dev/null +++ b/_site/criteria/make-the-codebase-reusable-and-portable.html @@ -0,0 +1,522 @@ + + + + + + + + + 程式基底要可重複使用且可移植, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +← 政策與原始碼要合捆 + + + + + + + + +歡迎貢獻者 → + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 需求規定
    2. +
  2. 測試方式
    3. +
  3. 公共政策制定者：需要的工作
    4. +
  4. 管理人員：需要的工作
    5. +
  5. 開發人員與設計師：需要的工作
    6. +
  6. 延伸閱讀
    7. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

程式基底要可重複使用且可移植

+ +

編寫可重複使用且可移植的程式碼，讓政策制定者、開發人員與設計師等，能重複使用、測試與改善目前已開發的內容，並將改善貢獻 +回程式基底中，如此可提高品質、降低維護成本、增強可靠性。

+ +

以重複利用為前提籌劃設計程式基底，更容易與多方共享程式基底的目標使命、願景與範圍等。多方開發與使用的程式基底， +更可以從能自我運作的社群中獲益。

+ +

以文件記錄周全的模組構成程式基底，能夠改善重複使用與維護的能力。以文件清楚記錄用途的模組，更容易在另一種情境中重複利用。

+ +

原始碼不依賴任何貢獻者、供應商或部署底下的特定情況專用基礎架構，則其他任何貢獻者都能測試該原始碼。

+ +

需求規定

+ +
    +
  • 程式基底「必須」開發成能在不同情境中重複使用。
    • +
  • 程式基底「必須」獨立於任何採用保密、無法揭露、專有或非開放式授權的軟體或服務，以供執行與瞭解。
    • +
  • 程式基底「應該」有多方單位使用。
    • +
  • 發展路線圖「應該」有多方單位的需求影響。
    • +
  • 程式基底開發「應該」由多方單位協作。
    • +
  • 「應該」使用組態設定方式以將原始碼調整成能適應各情境的特定需求。
    • +
  • 程式基底「應該」能夠在地化。
    • +
  • 原始碼與其文件「不應該」包含特定情況專用的資訊。
    • +
  • 程式基底模組「應該」以使其能夠在其他情境中重複利用的模式撰寫文件。
    • +
  • 軟體「不應該」要求僅有單一供應商能提供的服務或平台。
    • +
+ +

測試方式

+ +
    +
  • 與另一組織單位角色與您相似的人確認，看他們是否能利用程式基底，以及需要怎麼進行。
    • +
  • 確認程式基底不需要用到任何專有或非開放式授權的軟體或服務，就能夠執行。
    • +
  • 若程式基底處於早期開發階段，尚未準備好正式上線，則檢查是否有想要尋求協作者的意圖跡象。 +
      +
    • 或是如果程式基底非常成熟與穩定，鮮少需要修正、改善或貢獻： +
        +
      • 檢查是否有多方單位，或是有在多種情境下正使用程式基底。
        • +
      • 檢查是否有以文件記錄協作所做出的成果，以及有編列相關預算。
        • +
      +
      • +
    • 若是沒有，則： +
        +
      • 檢查是否有多方單位，或是有在多種情境下正使用程式基底。
        • +
      • 檢查程式基底貢獻者是否來自多方單位。
        • +
      +
      • +
    +
    • +
  • 檢查程式基底檔案與送交版次歷史紀錄中，不包含特定情況專用的資料。
    • +
  • 檢查軟體是否可以在不使用單一供應商服務或平台的情況下，正常部署與執行。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 為您的政策撰寫清楚且足夠詳細的文件，讓他人即使不是處於同個原始背景情境也能夠理解。
    • +
  • 確保程式基底有將貴組織單位列為已知使用者。
    • +
  • 找出貴團隊想要協作的其他組織單位。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 確認利害關係人與業主能夠瞭解，程式基底是以重複利用為明確目標，因而得以減少程式碼技術債，並讓程式基底可以永續發展。
    • +
  • 確認您的團隊與其他團隊能相互協作。
    • +
+ +

開發人員與設計師：需要的工作

+ +

原始碼應該設計成：

+ +
    +
  • 能讓其他使用者與組織單位可以重複利用，而不受地方環境影響，
    • +
  • 能解決通用性質問題，而非特定問題，
    • +
  • 以邏輯上具有意義且獨立的模組構成，
    • +
  • 如此讓類似組織單位中要面對近似問題的人，都可以採用這套解決方案（或其中一部份）。
    • +
+ +

確保程式基底文件中，有說明程式的組建日期與執行時期的依賴項目。如果您的情境需要部署至專有平臺上，或者要用到專有組件，則請確保協作者可以在不用到這兩者的情況下，就能進 +行開發、使用、測試、部署等。

+ +

在每份送交版次中，審查人員要確認其中不含特定情況專用的資料，像是主機名稱、個人與組織單位資料、代符與密碼等。

+ +

延伸閱讀

+ + + +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/criteria/open-licenses.html b/_site/criteria/open-licenses.html new file mode 100644 index 00000000..08dd1f7c --- /dev/null +++ b/_site/criteria/open-licenses.html @@ -0,0 +1,11 @@ + + + + Redirecting… + + + + +

Redirecting…

+ Click here if you are not redirected. + diff --git a/_site/criteria/open-standards.html b/_site/criteria/open-standards.html new file mode 100644 index 00000000..bede9515 --- /dev/null +++ b/_site/criteria/open-standards.html @@ -0,0 +1,11 @@ + + + + Redirecting… + + + + +

Redirecting…

+ Click here if you are not redirected. + diff --git a/_site/criteria/open-to-contributions.html b/_site/criteria/open-to-contributions.html new file mode 100644 index 00000000..b349ab45 --- /dev/null +++ b/_site/criteria/open-to-contributions.html @@ -0,0 +1,11 @@ + + + + Redirecting… + + + + +

Redirecting…

+ Click here if you are not redirected. + diff --git a/_site/criteria/publish-with-an-open-license.html b/_site/criteria/publish-with-an-open-license.html new file mode 100644 index 00000000..96e37471 --- /dev/null +++ b/_site/criteria/publish-with-an-open-license.html @@ -0,0 +1,499 @@ + + + + + + + + + 發行採用開放授權, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +← 使用持續整合 + + + + + + + + +程式基底可查詢得到 → + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 需求規定
    2. +
  2. 測試方式
    3. +
  3. 公共政策制定者：需要的工作
    4. +
  4. 管理人員：需要的工作
    5. +
  5. 開發人員與設計師：需要的工作
    6. +
  6. 延伸閱讀
    7. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

發行採用開放授權

+ +

採用開放且為人熟知的授權，讓任何人都可以查看原始碼，使其能瞭解運作方式、自由使用，並且能為程式基 +底做出貢獻。這也能促進供應商建立出以程式基底為中心的生態系。

+ +

明確指出程式基底中每一個檔案的授權，讓使用者能正確重複利用程式基底的部分內容，並表彰作者名稱。

+ +

需求規定

+ +
    +
  • 所有原始碼與文件，皆「必須」採用使其得以自由重複使用、自由修改、自由再次散布的授權條款。
    • +
  • 軟體原始碼「必須」採用經 OSI 開放原始碼促進會所批准，或由 FSF 自由軟體基金會所發表的自由授權條 +款。
    • +
  • 所有原始碼皆「必須」搭配授權條款檔案一併發行。
    • +
  • 「禁止」要求貢獻者將其貢獻的程式碼著作權轉讓給程式基底。
    • +
  • 程式基底中所有原始碼檔案，皆「應該」包含機器可讀的著作權聲明與授權條款標頭內容。
    • +
  • 「可選擇」是否為不同類型的原始碼與文件採用多重授權條款。
    • +
+ +

測試方式

+ + + +

公共政策制定者：需要的工作

+ +
    +
  • 制定要求原始碼必須採用開放原始碼授權的政策。
    • +
  • 制定抑制採購非開放原始碼授權程式碼，與非開放科技的政策。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 只與能採用開放原始碼授權交付、與發行其原始碼的開放原始碼軟體供應商合作。
    • +
  • 請注意，雖然創用CC授權適合用於文件作品，但其中指明「非商業性」或「禁止改作」 +的授權條款，代表「無法」自由重複使用、自由修改、自由再次散布等，因此未能符合規定。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 每當建立新的程式基底時，都要加入新的「license」授權條款檔案。
    • +
  • 每當建立新的原始碼檔案時，都要加入著作權聲明與授權條款標頭內容。
    • +
  • 每當程式基底重複利用原始碼時，都要確認原始碼的授權與程式基底的授權相容。
    • +
+ +

+ +

延伸閱讀

+ +
    +
  • 開放原始碼促進會所發表的《開放原始碼定義》，所有開放原始碼授權條款皆符合這套定義。
    • +
  • 紐西蘭CC Aotearoa《創用CC介紹動畫影 +片》。
    • +
  • 歐洲自由軟體基金會所發表的《REUSE 倡議規範》，提供規範明確、人類可讀以及機器可讀的著作權與 +授權資訊。
    • +
  • Linux 基金會所發表的 SPDX 授權條款清單，提供經標準化、且機器可讀的大多數授權條款縮寫表示 +法。
    • +
+ +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/criteria/require-review-of-contributions.html b/_site/criteria/require-review-of-contributions.html new file mode 100644 index 00000000..d95b2ffd --- /dev/null +++ b/_site/criteria/require-review-of-contributions.html @@ -0,0 +1,506 @@ + + + + + + + + + 要求審查貢獻內容, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +← 維護版本控制 + + + + + + + + +程式基底要有目標文件 → + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 需求規定
    2. +
  2. 測試方式
    3. +
  3. 公共政策制定者：需要的工作
    4. +
  4. 管理人員：需要的工作
    5. +
  5. 開發人員與設計師：需要的工作
    6. +
  6. 延伸閱讀
    7. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

要求審查貢獻內容

+ +

同儕審查貢獻是原始碼提升品質的關鍵，也能降低安全性風險與營運風險。

+ +

要求仔細審查貢獻，能孕育出確保貢獻都是優質、完整且能帶來價值的文化。審查原始碼能提高在原始碼加入程式基底之前， +就發現與修正潛在臭蟲與出錯的機率。得知所有原始碼都會被審查，就不會孕育出習慣怪罪他人的文化，反倒是鼓勵每個人都專注在解決方案上。

+ +

快速審查政策在於向貢獻者保證，必定在一段時間內提供意見回饋或是協作式改善，進而提高貢獻者交付貢獻內容的頻率，以及參 +與的熱度。

+ +

需求規定

+ +
    +
  • 所有被接受或是送交給程式基底正式發行版本中的貢獻內容，都「必須」經過另一位貢獻者審查。
    • +
  • 審查「必須」包含原始碼、政策、測試、文件等。
    • +
  • 如果不接受貢獻內容，審查人員「必須」提供意見回饋。
    • +
  • 審查流程「應該」確認貢獻內容遵循程式基底的標準、架構、決策安排等，以通過審查。
    • +
  • 審查內容「應該」包含執行軟體與執行程式基底測試。
    • +
  • 貢獻內容「應該」由與貢獻者不同背景情境的人來審查。
    • +
  • 版本控制系統「不應該」在程式基底的正式發行版本中，接受未經審查的貢獻內容。
    • +
  • 審查「應該」在兩個工作天內進行。
    • +
  • 「可選擇」是否由多位審查人員進行審查。
    • +
+ +

測試方式

+ +
    +
  • 確認歷史紀錄中，每個送交版次都有經過不同的貢獻者審查。
    • +
  • 確認審查內容包含原始碼、政策、測試、文件等。
    • +
  • 針對未被採用的貢獻內容，確認有適當解釋原因。
    • +
  • 檢查審查人員指引中，有包含是否遵循標準、架構、程式基底指引等指示。
    • +
  • 檢查審查人員在審查時是否有執行軟體與測試。
    • +
  • 與審查人員確認，送交版次是否有經過不同情境背景的不同貢獻者審查。
    • +
  • 檢查版本控制系統中是否有採用分支保護。
    • +
  • 檢查貢獻提交與審查之間的時間間隔。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 制定進行任何審查時，含原始碼與其他一切事物，都要恪遵「四眼原則」的政策。
    • +
  • 採用具有審查與意見回饋功能的版本控制系統，或作業流程。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 將交付妥善軟體作為共同目標。
    • +
  • 確保如原始碼、政策、文件、測試等的貢獻內容撰寫與審查，皆受到同等重視。
    • +
  • 創造歡迎所有形式的貢獻，而且每個人都能夠審查貢獻內容的文化。
    • +
  • 確保貢獻者在貢獻內容給程式基底時，不是獨自一人埋頭苦幹。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 請程式基底的其他貢獻者，審查您在貴組織單位內外的工作成果。
    • +
  • 當他人請求您審查時，請盡快回覆，並先給出需要修正之處背後的概念。
    • +
+ +

延伸閱讀

+ + + +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/criteria/require-review.html b/_site/criteria/require-review.html new file mode 100644 index 00000000..76cde276 --- /dev/null +++ b/_site/criteria/require-review.html @@ -0,0 +1,11 @@ + + + + Redirecting… + + + + +

Redirecting…

+ Click here if you are not redirected. + diff --git a/_site/criteria/reusable-and-portable-codebases.html b/_site/criteria/reusable-and-portable-codebases.html new file mode 100644 index 00000000..3220819c --- /dev/null +++ b/_site/criteria/reusable-and-portable-codebases.html @@ -0,0 +1,11 @@ + + + + Redirecting… + + + + +

Redirecting…

+ Click here if you are not redirected. + diff --git a/_site/criteria/style.html b/_site/criteria/style.html new file mode 100644 index 00000000..c2e6dc13 --- /dev/null +++ b/_site/criteria/style.html @@ -0,0 +1,11 @@ + + + + Redirecting… + + + + +

Redirecting…

+ Click here if you are not redirected. + diff --git a/_site/criteria/understandable-english-first.html b/_site/criteria/understandable-english-first.html new file mode 100644 index 00000000..b3d31cef --- /dev/null +++ b/_site/criteria/understandable-english-first.html @@ -0,0 +1,11 @@ + + + + Redirecting… + + + + +

Redirecting…

+ Click here if you are not redirected. + diff --git a/_site/criteria/use-a-coherent-style.html b/_site/criteria/use-a-coherent-style.html new file mode 100644 index 00000000..371e6a56 --- /dev/null +++ b/_site/criteria/use-a-coherent-style.html @@ -0,0 +1,485 @@ + + + + + + + + + 風格要前後一致, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +← 程式基底可查詢得到 + + + + + + + + +記錄程式基底成熟度 → + + + + + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 需求規定
    2. +
  2. 測試方式
    3. +
  3. 公共政策制定者：需要的工作
    4. +
  4. 管理人員：需要的工作
    5. +
  5. 開發人員與設計師：需要的工作
    6. +
  6. 延伸閱讀
    7. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

風格要前後一致

+ +

採用前後一致的風格，讓不同環境的貢獻者能夠一同合作。用詞統一能減少貢獻者之間在溝通上的摩擦。

+ +

需求規定

+ +
    +
  • 程式基底「必須」遵守程式碼撰寫風格指引、或文件寫作風格指引，可以是程式基底社群自身的風格指引，或是程式基底 +有採用的既有風格。
    • +
  • 貢獻內容「應該」通過自動化的風格測試。
    • +
  • 風格指引「應該」描述對於較複雜的程式碼區段，如何作列內註解與為其寫下說明文件的期待。
    • +
  • 「可選擇」是否將可理解的白話英語期望加入風格指引之中。
    • +
+ +

測試方式

+ +
    +
  • 確認貢獻內容有遵循文件中指定的風格指引。
    • +
  • 檢查是否有自動化的風格測試。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 為政策與文件建立風格指引，遵守並且持續改善，同時記錄到程式基底文件中，像是「CONTRIBUTING」或 +「README」檔案。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 將書面語言、原始碼、測試、政策標準等，包含在貴組織單位對品質的定義當中。
    • +
+ +

開發人員與設計師：需要的工作

+ +

如果程式基底還沒有工程指引，或其他貢獻者指引，則請先在儲存庫中加入相關文件，像是 +「CONTRIBUTING」或「README」檔案，並描述目前在設立指引方面的進展。上述檔案的重要目的之一，在於宣達設計偏好、命名規則，以及機器不容易檢查 +的其他層面。指引應該包含貢獻的原始碼預期該符合哪些要求，才會被維護人員合併至程式基底中，包括原始碼、測 +試、文件等項目。請持續改善與擴充這份文件內容，目標讓文件朝向工程指引演進。

+ +

此外：

+ +
    +
  • 使用 linter 程式碼品質梳理工具。
    • +
  • 在程式基底中加入 linter 梳理工具的組態設定。
    • +
+ +

延伸閱讀

+ + + +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/criteria/use-continuous-integration.html b/_site/criteria/use-continuous-integration.html new file mode 100644 index 00000000..1a59591e --- /dev/null +++ b/_site/criteria/use-continuous-integration.html @@ -0,0 +1,508 @@ + + + + + + + + + 使用持續整合, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +← 採用開放標準 + + + + + + + + +發行採用開放授權 → + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 需求規定
    2. +
  2. 測試方式
    3. +
  3. 公共政策制定者：需要的工作
    4. +
  4. 管理人員：需要的工作
    5. +
  5. 開發人員與設計師：需要的工作
    6. +
  6. 延伸閱讀
    7. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

使用持續整合

+ +

透過自動化測試驗證，開發人員能更頻繁地將其工作成果合併至共享的分支，達成非同步協作。合併的頻率越頻繁、貢獻的規模越小，在合併時所發生的衝突就越容易解決。

+ +

自動化測試所有功能，使人更加信賴貢獻內容發揮其功用且沒有引發任何錯誤，同時讓審查人員專注在貢獻的結構與作法。測試越聚焦，就越容易辨識並瞭解所出現的問題。

+ +

以文件記錄程式基底的持續整合工作流程，能協助貢獻者瞭解對貢獻內容的期待。持續整合讓 +監管程式基底狀態變得更為簡單。

+ +

需求規定

+ +
    +
  • 原始碼中的所有功能，都「必須」有自動化測試。
    • +
  • 所有貢獻內容都「必須」先通過自動化測試，才能上傳至程式基底。
    • +
  • 程式基底「必須」有解說如何撰寫貢獻內容結構的相關指引。
    • +
  • 程式基底「必須」有能夠審查貢獻內容的活躍貢獻者。
    • +
  • 「應該」公開貢獻內容的自動化測試結果。
    • +
  • 程式基底指引「應該」指出，每次的貢獻內容都只應聚焦在單一議題上。
    • +
  • 「應該」監管原始碼測試與文件的涵蓋範圍。
    • +
  • 「可選擇」是否測試政策和文件，與原始碼之間有無一致性，或是反之亦然。
    • +
  • 「可選擇」是否測試政策和文件所採用的樣式，以及連結有無失效。
    • +
  • 「可選擇」是否使用文件中的範例來測試軟體。
    • +
+ +

測試方式

+ +
    +
  • 確認有測試可用。
    • +
  • 確認原始碼覆蓋率工具能檢查到 100% 的原始碼。
    • +
  • 確認貢獻內容只有在通過所有測試後，才會認可上傳至程式基底。
    • +
  • 確認有貢獻指引解說如何撰寫貢獻內容的結構。
    • +
  • 確認最近三個月內有貢獻內容上傳。
    • +
  • 檢查是否可以查看測試結果。
    • +
  • 檢查是否有公布原始碼覆蓋率數據。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 儘早讓管理人員、開發人員與設計師一同加入，並且讓他們持續參與您政策的制定程序。
    • +
  • 確保政策文件也有設好自動化測試。
    • +
  • 如果政策文件未能通過測試，請快速修正。
    • +
  • 確保原始碼能反映出政策的任何變動（請參閱〈維護版本控制〉）。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 確保能儘快且經常給真正的終端使用者進行測試。
    • +
  • 以頻繁整合少量部分內容的方式做專案規劃，而非久久一次繳交大量部分內容。
    • +
  • 聘請有能力處理漸進式交付，並跟得上規劃進度的顧問服務。
    • +
  • 發生重大失誤後，鼓勵公開事故報告，以及公開討論事後學到的教訓。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 協助管理人員擬定工作規劃，例如規劃成可以拆分成小部分逐次整合。
    • +
  • 協助貢獻者聚焦其貢獻內容與功能請求，讓涵蓋範圍盡可能合理地縮小。
    • +
  • 協助管理人員與政策制定者測試其貢獻內容，例如測試其貢獻內容中的失效連結或樣式。
    • +
  • 編排原始碼結構時，要將難以在測試環境下創造出來的情況，得以在測試過程中模擬出來。例如硬碟空間不足、記憶體分配失敗等資源耗盡情況，都是難以創造的典型案例。
    • +
  • 調整程式碼覆蓋率測試工具，避免在 inline 過程或其他最佳化處理時得到假警報。
    • +
  • 經常部署。
    • +
  • 至少每天整合工作內容一次。
    • +
+ +

延伸閱讀

+ + + +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/criteria/use-open-standards.html b/_site/criteria/use-open-standards.html new file mode 100644 index 00000000..306397cb --- /dev/null +++ b/_site/criteria/use-open-standards.html @@ -0,0 +1,485 @@ + + + + + + + + + 採用開放標準, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +← 使用白話的英語 + + + + + + + + +使用持續整合 → + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 需求規定
    2. +
  2. 測試方式
    3. +
  3. 公共政策制定者：需要的工作
    4. +
  4. 管理人員：需要的工作
    5. +
  5. 開發人員與設計師：需要的工作
    6. +
  6. 延伸閱讀
    7. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

採用開放標準

+ +

開放標準保證可以取得使用與貢獻程式基底所需的知 +識。不僅能為不同的系統之間建立互通性，更能降低廠商套牢的可能性。開放標準如果明確，不同方就可以各自獨立開發作資料交換。

+ +

需求規定

+ +
    +
  • 程式基底如要促進資料交換的特性，就「必須」採用符合 OSI 開放原始碼促進會其《開放標準需求規範》的 +開放標準。
    • +
  • 如果有使用到任何非開放標準，則「必須」在文件中清楚記錄。
    • +
  • 程式基底選擇採用的任何標準，皆「必須」在文件中列出，並且只要有的話，就附上該標準的連結。
    • +
  • 程式基底選擇採用的任何非開放標準，皆「禁止」妨礙程式基底的協作與重複使用。
    • +
  • 如果還沒有已存在的開放標準可採用，則「應該」投入開發新標準。
    • +
  • 採用開放標準時，「應該」優先選擇可經機器測試的開放標準。
    • +
  • 採用非開放標準時，「應該」優先選擇可經機器測試的非開放標準。
    • +
+ +

測試方式

+ +
    +
  • 確認資料交換遵守 OSI 開放原始碼促進會批准的開放標準。
    • +
  • 確認若有採用任何的非開放標準，皆有清楚記錄在文件中。
    • +
  • 確認文件有清單列出程式基底所採用的標準，其中各標準有對應的有效連結；或沒有採用任何標準時，則留下聲明。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 以政策要求盡可能在任何情況下採用開放標準。
    • +
  • 禁止採購不採用開放標準的技術科技。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 考慮在原始碼審查中納入開放標準依循評估。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 將是否依循標準加入持續整合測試中。
    • +
  • 審查送交版次與儲存庫其他資源是否有參考開放標準，並交叉檢查其中有列出標準的部分。
    • +
+ +

延伸閱讀

+ + + +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/criteria/use-plain-english.html b/_site/criteria/use-plain-english.html new file mode 100644 index 00000000..974187db --- /dev/null +++ b/_site/criteria/use-plain-english.html @@ -0,0 +1,498 @@ + + + + + + + + + 使用白話的英語, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +← 程式碼要有文件 + + + + + + + + +採用開放標準 → + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 需求規定
    2. +
  2. 測試方式
    3. +
  3. 公共政策制定者：需要的工作
    4. +
  4. 管理人員：需要的工作
    5. +
  5. 開發人員與設計師：需要的工作
    6. +
  6. 延伸閱讀
    7. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

使用白話的英語

+ +

英語是軟體開發領域中的實際 協作語言。

+ +

公家機關資訊需要讓所有選民都能取用。簡單且白話的語言，能讓更多人能瞭解程式碼與其功用。

+ +

翻譯可以讓更多人有機會認識程式基底。用語越是簡單明暸，製作與維護翻譯的成本就越低。

+ +

需求規定

+ +
    +
  • 程式基底的所有文件都「必須」使用英語。
    • +
  • 所有原始碼都「必須」使用英語編寫，其中政策是由機器 +解讀當作程式碼的部分則除外。
    • +
  • 任何合捆的政策如果沒有英語版本，則「必須」隨附英語版摘要。
    • +
  • 任何翻譯版本皆「必須」跟隨英語版本更新，以維持在最新狀態，反之亦然。
    • +
  • 程式基底中「不應該」使用首字母縮字、縮寫、雙關語，或法律/非英語/行業特定詞彙；如果有的話，則需要在這些用語出現之前先行解釋，或是附上解釋該用語的網頁連結。
    • +
  • 根據《網頁內容近用性無障礙指引 2》的建議，文件內容「應該」以國中識讀程度為主。
    • +
  • 「可選擇」是否提供任何程式碼、文件、測試等的翻譯版。
    • +
+ +

測試方式

+ +
    +
  • 確認程式基底文件有英語版本。
    • +
  • 確認原始碼為英語，確認任何非英語內容都是政策，或確認術語在其前方有先行說明等。
    • +
  • 確認任何非英語政策都有隨附英語版摘要。
    • +
  • 確認翻譯版與英語版內容相同。
    • +
  • 確認文件當中，沒有任何未說明的首字母縮寫字、縮寫、雙關語，或法律/非英語/行業特定詞彙等。
    • +
  • 檢查文件的拼字、文法與易讀性等。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 在過程中經常與其他管理人員、開發人員與設計師測試，確認他們是否瞭解您們正要交付的程式碼與其文件的內容。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 在團隊內部與利害關係人之間的內部溝通中，試著限制首字母縮寫字、縮寫、雙關語，或法律/非英語/行業特定詞彙的使用。如果有使用到的話，則將這些用語加入詞彙表，並且在 +使用這些詞彙的地方加上詞彙表連結。
    • +
  • 以批判性觀點看待提案與修改當中的文件與描述。如果有您看不懂的內容，很有可能其他人也同樣迷惘。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 經常與政策制定者和管理人員測試，確認他們是否瞭解您們正要交付的程式碼與其文件的內容。
    • +
  • 詢問身處不同背景情境的人（像是另一個程式基底的開發人員）是否能瞭解內容。
    • +
+ +

+ +

延伸閱讀

+ + + +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/criteria/version-control-and-history.html b/_site/criteria/version-control-and-history.html new file mode 100644 index 00000000..ae7034c1 --- /dev/null +++ b/_site/criteria/version-control-and-history.html @@ -0,0 +1,11 @@ + + + + Redirecting… + + + + +

Redirecting…

+ Click here if you are not redirected. + diff --git a/_site/criteria/welcome-contributors.html b/_site/criteria/welcome-contributors.html new file mode 100644 index 00000000..770b71f9 --- /dev/null +++ b/_site/criteria/welcome-contributors.html @@ -0,0 +1,500 @@ + + + + + + + + + 歡迎貢獻者, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +← 程式基底要可重複使用且可移植 + + + + + + + + +貢獻要容易 → + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 需求規定
    2. +
  2. 測試方式
    3. +
  3. 公共政策制定者：需要的工作
    4. +
  4. 管理人員：需要的工作
    5. +
  5. 開發人員與設計師：需要的工作
    6. +
  6. 延伸閱讀
    7. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

歡迎貢獻者

+ +

程式基底社群的氛圍，會影響使用者選擇所要使用的程式基底。歡迎任何人成為貢獻者的社群，才能夠不斷茁壯並且持續自我 +運作。若貢獻者有明確的方法可以影響程式基底、社群目標與進展，則該社群分裂成分歧的社群的機率也較低。新參與者需要瞭解並信任程式基底社群的治理方式。

+ +

需求規定

+ +
    +
  • 程式基底必須「允許」任何人對程式基底提出修改建議。
    • +
  • 程式基底「必須」包含貢獻指引，說明歡迎貢獻的內容類型，以及貢獻者可如何參與開發，例如以「CONTRIBUTING」檔案說明。
    • +
  • 程式基底「必須」以文件記錄程式基底、貢獻內容與社群互動等的治理方式，例如以「GOVERNANCE」檔案來說明。
    • +
  • 貢獻指引「應該」以文件記錄預期由何者負擔審查貢獻內容所需的開銷費用。
    • +
  • 程式基底「應該」宣布投入其開發與維護工作的參與組織單位。
    • +
  • 程式基底「應該」要有可公開取得的發展路線圖。
    • +
  • 程式基底「應該」公布程式基底的活動統計數據。
    • +
  • 「可選擇」是否為程式基底加入貢獻者的行為守則。
    • +
+ +

測試方式

+ +
    +
  • 確認可以提交修改建議給程式基底。
    • +
  • 確認程式基底有貢獻指引。
    • +
  • 確認程式基底有清楚解釋治理架構，並包含如何影響程式基底治理的方法。
    • +
  • 確認貢獻指引是否有涵蓋預期由何者負擔審查貢獻內容的開銷費用。
    • +
  • 檢查是否有參與的組織單位名單。
    • +
  • 檢查是否有發展路線圖。
    • +
  • 檢查是否有公布活動統計數據。
    • +
  • 檢查是否有行為守則。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 為程式基底加入其他資源的清單，而這些資源可幫助政策專家、非政府組織、學者等，更能瞭解或可重複利用您的政策。
    • +
  • 考慮放入聯絡資訊，讓其他考慮合作的政策制定者能徵詢您的意見。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 確保治理架構文件內容中，有包含目前如何改變治理狀態的流程。
    • +
  • 如果社群對於治理架構應該如何改變有共識，則應該將這些構想宣告為願景寫入文件中。
    • +
  • 若有需要，確認您有編列貢獻內容審查流程的預算，且經過程式基底社群同意。
    • +
  • 確認文件有解釋每個參與組織單位所投入的內容，例如提供程式基底哪些資源，以及參與的時間長度等。
    • +
  • 支持您經驗豐富的政策制定者、開發人員與設計師，使其盡可能長久參與社群。
    • +
+ +

+ +

開發人員與設計師：需要的工作

+ +
    +
  • 快速回應請求。
    • +
  • 告知管理人員，您在支援其他貢獻者時所需的時間與資源。
    • +
  • 清楚告知貢獻者他們該如何做，才能讓貢獻內容整合到程式基底中。
    • +
+ +

延伸閱讀

+ + + +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/criteria_source/bundle-policy-and-code.html b/_site/criteria_source/bundle-policy-and-code.html new file mode 100644 index 00000000..d66773ff --- /dev/null +++ b/_site/criteria_source/bundle-policy-and-code.html @@ -0,0 +1,364 @@ + + + + + + + + + Bundle policy and source code, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

Contents

+
    +
  1. Requirements
    2. +
  2. Why this is important
    3. +
  3. What this does not do
    4. +
  4. How to test
    5. +
  5. Policy makers: what you need to do
    6. +
  6. Management: what you need to do
    7. +
  7. Developers and designers: what you need to do
    8. +
  8. Further reading
    9. +
+ + + + + + + +

Contribute on GitHub

+ + + +
+ + +
+ +
+

Bundle policy and source code

+ + + + +

Requirements

+ +
    +
  • The codebase MUST include the policy that the source code is based on.
    • +
  • The codebase MUST include all source code that the policy is based on, unless used for fraud detection.
    • +
  • Policy SHOULD be provided in machine readable and unambiguous formats.
    • +
  • Continuous integration tests SHOULD validate that the source code and the policy are executed coherently.
    • +
+ +

Why this is important

+ +

Access to both the source code and the policy documents is necessary for understanding and reuse of, as well as collaboration in, a codebase. +Understanding the context and the policies in that context is fundamental to understanding what problems a codebase is trying to solve and how it sets out to solve them. +To be able to evaluate whether to adopt a codebase in a new context, an organization will need to understand what process changes it must choose to make or how to contribute additional configurability to the existing solution in order to adapt it to the new context.

+ +

What this does not do

+ +
    +
  • Guarantee that a codebase will reflect the bundled policy.
    • +
  • Make sure packages comply with the local technical infrastructure or legal framework of a given public organization.
    • +
+ +

How to test

+ +
    +
  • Confirm with a civil servant that all policy that the source code is based on is included.
    • +
  • Confirm with a civil servant that all source code that the policy is based on is included.
    • +
  • Check if policy can be interpreted by a machine.
    • +
  • Check the continuous integration tests for coherent execution of source code and policy pass.
    • +
+ +

Policy makers: what you need to do

+ +
    +
  • Collaborate with developers and designers to ensure there is no mismatch between policy code and source code.
    • +
  • Provide the relevant policy texts for inclusion in the repository; if the text is not available in English, also provide an English summary. Be sure to include standards that your organization has chosen to adhere to and any organizational processes which impact the development or the deployment context of the codebase for your organization.
    • +
  • Provide references and links to texts which support the policies.
    • +
  • Document policy in formats that are unambiguous and machine-readable such as Business Process Model and Notation, Decision Model and Notation and Case Management Model Notation.
    • +
  • Track policy with the same version control and documentation used to track source code.
    • +
  • Check in regularly to understand how the non-policy code in the codebase has changed and whether it still matches the intentions of the policy.
    • +
+ +

Management: what you need to do

+ +
    +
  • Keep policy makers, developers and designers involved and connected throughout the whole development process.
    • +
  • Make sure policy makers, developers and designers are working to the same objectives.
    • +
+ +

Developers and designers: what you need to do

+ +
    +
  • Become familiar with and be able to use the process modelling notation that the policy makers in your organization use.
    • +
  • Work together with policy makers to ensure there is no mismatch between policy code and source code.
    • +
  • Give feedback on how to make policy documentation more clear.
    • +
+ +

Further reading

+ + + +
+
+ + +
+ + +
+ + + + + + + + + + + + + + + diff --git a/_site/criteria_source/code-in-the-open.html b/_site/criteria_source/code-in-the-open.html new file mode 100644 index 00000000..281564f6 --- /dev/null +++ b/_site/criteria_source/code-in-the-open.html @@ -0,0 +1,368 @@ + + + + + + + + + Code in the open, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

Contents

+
    +
  1. Requirements
    2. +
  2. Why this is important
    3. +
  3. What this does not do
    4. +
  4. How to test
    5. +
  5. Policy makers: what you need to do
    6. +
  6. Management: what you need to do
    7. +
  7. Developers and designers: what you need to do
    8. +
  8. Further reading
    9. +
+ + + + + + + +

Contribute on GitHub

+ + + +
+ + +
+ +
+

Code in the open

+ + + + +

Requirements

+ +
    +
  • All source code for any policy in use (unless used for fraud detection) MUST be published and publicly accessible.
    • +
  • All source code for any software in use (unless used for fraud detection) MUST be published and publicly accessible.
    • +
  • Contributors MUST NOT upload sensitive information regarding users, their organization or third parties to the repository.
    • +
  • Any source code not currently in use (such as new versions, proposals or older versions) SHOULD be published.
    • +
  • Documenting which source code or policy underpins any specific interaction the general public may have with an organization is OPTIONAL.
    • +
+ +

Why this is important

+ +

Coding in the open:

+ +
    +
  • improves transparency
    • +
  • increases code quality
    • +
  • facilitates the auditing processes
    • +
+ +

These aspects together create more opportunities for citizens to understand how software and policy impact their interactions with a public organization.

+ +

What this does not do

+ +
    +
  • Make source code or policy reusable.
    • +
  • Make the codebase and the code within it understandable to as many people as possible.
    • +
+ +

How to test

+ +
    +
  • Confirm that the source for each version currently in use is published on the internet where it can be seen from outside the original contributing organization and without the need for any form of authentication or authorization.
    • +
  • Confirm that the codebase files and commit history do not include sensitive information.
    • +
  • Check for the publication of source code not currently in use.
    • +
+ +

Policy makers: what you need to do

+ +
    +
  • Develop policies in the open.
    • +
  • Prioritize open and transparent policies.
    • +
+ +

Management: what you need to do

+ +
    +
  • Develop a culture that embraces openness, learning and feedback.
    • +
  • Collaborate with external vendors and freelancers by working in the open.
    • +
+ +

Developers and designers: what you need to do

+ +
    +
  • As a reviewer, for each commit, verify that content does not include sensitive information such as configurations, usernames or passwords, public keys or other real credentials used in production systems.
    • +
  • Clearly split data and code, in order to meet the requirement about sensitive information above.
    • +
+ +

Further reading

+ + + +
+
+ + +
+ + +
+ + + + + + + + + + + + + + + diff --git a/_site/criteria_source/continuous-integration.html b/_site/criteria_source/continuous-integration.html new file mode 100644 index 00000000..4c069e3d --- /dev/null +++ b/_site/criteria_source/continuous-integration.html @@ -0,0 +1,388 @@ + + + + + + + + + Use continuous integration, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

Contents

+
    +
  1. Requirements
    2. +
  2. Why this is important
    3. +
  3. What this does not do
    4. +
  4. How to test
    5. +
  5. Policy makers: what you need to do
    6. +
  6. Management: what you need to do
    7. +
  7. Developers and designers: what you need to do
    8. +
  8. Further reading
    9. +
+ + + + + + + +

Contribute on GitHub

+ + + +
+ + +
+ +
+

Use continuous integration

+ + + + +

Requirements

+ +
    +
  • All functionality in the source code MUST have automated tests.
    • +
  • Contributions MUST pass all automated tests before they are admitted into the codebase.
    • +
  • The codebase MUST have guidelines explaining how to structure contributions.
    • +
  • The codebase MUST have active contributors.
    • +
  • The codebase guidelines SHOULD state that each contribution should focus on a single issue.
    • +
  • Source code test and documentation coverage SHOULD be monitored.
    • +
  • Testing policy and documentation for consistency with the source and vice versa is OPTIONAL.
    • +
  • Testing policy and documentation for style and broken links is OPTIONAL.
    • +
+ +

Why this is important

+ +
    +
  • Using continuous integration: +
      +
    • allows you to quickly identify problems with the codebase,
      • +
    • enables risk taking and focusing on problem solving while minimizing stress for the contributors,
      • +
    • lowers barriers for new contributors by reducing the amount of understanding necessary to suggest changes,
      • +
    • leads to more maintainable code,
      • +
    • speeds up the development cycle.
      • +
    +
    • +
  • Smaller, more regular contributions are typically easier to evaluate and lower risk compared to large infrequent changes.
    • +
  • Codebases in active development more reliably provide opportunities for collaboration and feedback.
    • +
+ +

What this does not do

+ +
    +
  • Create a fault tolerant infrastructure that will work and scale perfectly.
    • +
  • Create meaningful tests.
    • +
  • Test for real life situations.
    • +
  • Guarantee the code will deliver exactly the same policy result.
    • +
+ +

How to test

+ +
    +
  • Confirm that there are tests present.
    • +
  • Confirm that code coverage tools check that coverage is at 100% of the code.
    • +
  • Confirm that contributions are only admitted into the codebase after all of the tests are passed.
    • +
  • Confirm that contribution guidelines explain how to structure contributions.
    • +
  • Confirm that there are contributions from within the last three months.
    • +
  • Check if code coverage data is published.
    • +
+ +

Policy makers: what you need to do

+ +
    +
  • Involve management as well as developers and designers as early in the process as possible and keep them engaged throughout development of your policy.
    • +
  • Make sure there are also automated tests set up for policy documentation.
    • +
  • Fix policy documentation promptly if it fails a test.
    • +
  • Make sure the code reflects any changes to the policy (see Maintain version control).
    • +
+ +

Management: what you need to do

+ +
    +
  • Make sure to test with real end users as quickly and often as possible.
    • +
  • Plan the work to deliver small parts very often instead of large parts less frequently.
    • +
  • Procure consultancy services that deliver incrementally aligned with the plan.
    • +
  • After a large failure, encourage publication of incident reports and public discussion of what was learned.
    • +
+ +

Developers and designers: what you need to do

+ +
    +
  • Help management structure the work plan such that it can be delivered as small increments.
    • +
  • Help contributors limit the scope of their contributions and feature requests to be as small as reasonable.
    • +
  • Help management and policy makers test their contributions, for example by testing their contributions for broken links or style.
    • +
  • Structure code written to handle conditions which are difficult to create in a test environment in such a way that the conditions can be simulated during testing. Forms of resource exhaustion such as running out of storage space and memory allocation failure are typical examples of difficult to create conditions.
    • +
  • Tune the test code coverage tools to avoid false alarms resulting from inlining or other optimizations.
    • +
  • Deploy often.
    • +
  • Integrate your work at least once a day.
    • +
+ +

Further reading

+ + + +
+
+ + +
+ + +
+ + + + + + + + + + + + + + + diff --git a/_site/criteria_source/document-maturity.html b/_site/criteria_source/document-maturity.html new file mode 100644 index 00000000..04c412b7 --- /dev/null +++ b/_site/criteria_source/document-maturity.html @@ -0,0 +1,367 @@ + + + + + + + + + Document codebase maturity, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

Contents

+
    +
  1. Requirements
    2. +
  2. Why this is important
    3. +
  3. What this does not do
    4. +
  4. How to test
    5. +
  5. Policy makers: what you need to do
    6. +
  6. Management: what you need to do
    7. +
  7. Developers and designers: what you need to do
    8. +
  8. Further reading
    9. +
+ + + + + + + +

Contribute on GitHub

+ + + +
+ + +
+ +
+

Document codebase maturity

+ + + + +

Requirements

+ +
    +
  • The codebase MUST be versioned.
    • +
  • The codebase that is ready to use MUST only depend on other codebases that are also ready to use.
    • +
  • The codebase that is not yet ready to use MUST have one of the labels: prototype, alpha, beta or pre-release version.
    • +
  • The codebase SHOULD contain a log of changes from version to version, for example in the CHANGELOG.
    • +
+ +

Why this is important

+ +

Clearly signalling a codebase’s maturity helps others decide whether to reuse, invest in or contribute to it.

+ +

What this does not do

+ +
    +
  • Guarantee that others will use the code.
    • +
+ +

How to test

+ +
    +
  • Confirm that the codebase has a strategy for versioning which is documented.
    • +
  • Confirm that it is clear where to get the newest version.
    • +
  • Confirm that the codebase doesn’t depend on any codebases marked with a less mature status.
    • +
  • Confirm that the codebase is ready to use or labeled as prototype, alpha, beta or pre-release version.
    • +
  • Check that there is a log of changes.
    • +
+ +

Policy makers: what you need to do

+ +
    +
  • When developing policy, understand that any code developed needs to be tested and improved before it can be put into service.
    • +
  • Consider versioning policy changes, especially when they trigger new versions of the source code.
    • +
+ +

Management: what you need to do

+ +
    +
  • Make sure that services only rely on codebases of equal or greater maturity than the service. For example, don’t use a beta codebase in a production service or a prototype codebase in a beta service.
    • +
  • If the codebase is not ready for general use, work with the developers to ensure the codebase is properly labeled: +
      +
    • prototype: to test the look and feel, and to internally prove the concept of the technical possibilities,
      • +
    • alpha: to do guided tests with a limited set of users,
      • +
    • beta: to open up testing to a larger section of the general public, for example to test if the codebase works at scale,
      • +
    • pre-release version: code that is ready to be released but hasn’t received formal approval yet.
      • +
    +
    • +
+ +

Developers and designers: what you need to do

+ +
    +
  • Add a prominent header to every interface that indicates the maturity level of the code.
    • +
  • Version all releases.
    • +
  • Especially in ‘rolling release’ scenarios, the version may be automatically derived from the version control system metadata (for example by using git describe).
    • +
+ +

Further reading

+ + + +
+
+ + +
+ + +
+ + + + + + + + + + + + + + + diff --git a/_site/criteria_source/document-objectives.html b/_site/criteria_source/document-objectives.html new file mode 100644 index 00000000..02db715b --- /dev/null +++ b/_site/criteria_source/document-objectives.html @@ -0,0 +1,358 @@ + + + + + + + + + Document codebase objectives, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

Contents

+
    +
  1. Requirements
    2. +
  2. Why this is important
    3. +
  3. What this does not do
    4. +
  4. How to test
    5. +
  5. Policy makers: what you need to do
    6. +
  6. Management: what you need to do
    7. +
  7. Developers and designers: what you need to do
    8. +
  8. Further reading
    9. +
+ + + + + + + +

Contribute on GitHub

+ + + +
+ + +
+ +
+

Document codebase objectives

+ + + + +

Requirements

+ +
    +
  • The codebase MUST contain documentation of its objectives, like a mission and goal statement, that is understandable by developers and designers so that they can use or contribute to the codebase.
    • +
  • Codebase documentation SHOULD clearly describe the connections between policy objectives and codebase objectives.
    • +
  • Documenting the objectives of the codebase for the general public is OPTIONAL.
    • +
+ +

Why this is important

+ +

Documenting codebase objectives:

+ +
    +
  • provides an easy way for people to decide whether this codebase, or one of its modules, is interesting for them now or in the future.
    • +
  • helps scope your own development.
    • +
  • clearly communicates to other stakeholders and contributors the purpose of the codebase and the modules of which it is composed.
    • +
+ +

What this does not do

+ +
    +
  • Guarantee that the codebase achieves the stated objective(s).
    • +
  • Guarantee contributions to the codebase.
    • +
  • Prevent other codebases from attempting to achieve the same objectives.
    • +
+ +

How to test

+ +
    +
  • Confirm that the codebase documentation includes the codebase objectives, mission or goal.
    • +
  • Check for descriptions of connections between policy objectives and codebase objectives.
    • +
+ +

Policy makers: what you need to do

+ +
    +
  • Add the policy objectives to the codebase documentation, for example in the README.
    • +
  • Include relevant policies which impact the community, codebase, and development like value and ethics based policies, for example accessibility or equal opportunity.
    • +
+ +

Management: what you need to do

+ +
    +
  • Add the organizational and business objectives to the codebase documentation, for example in the README.
    • +
+ +

Developers and designers: what you need to do

+ +
    +
  • Add the technology and design objectives to the codebase documentation, for example in the README.
    • +
+ +

Further reading

+ + + +
+
+ + +
+ + +
+ + + + + + + + + + + + + + + diff --git a/_site/criteria_source/documenting.html b/_site/criteria_source/documenting.html new file mode 100644 index 00000000..3baea1c1 --- /dev/null +++ b/_site/criteria_source/documenting.html @@ -0,0 +1,369 @@ + + + + + + + + + Document the code, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

Contents

+
    +
  1. Requirements
    2. +
  2. Why this is important
    3. +
  3. What this does not do
    4. +
  4. How to test
    5. +
  5. Policy makers: what you need to do
    6. +
  6. Management: what you need to do
    7. +
  7. Developers and designers: what you need to do
    8. +
  8. Further reading
    9. +
+ + + + + + + +

Contribute on GitHub

+ + + +
+ + +
+ +
+

Document the code

+ + + + +

Requirements

+ +
    +
  • All of the functionality of the codebase, policy as well as source, MUST be described in language clearly understandable for those that understand the purpose of the code.
    • +
  • The documentation of the codebase MUST contain a description of how to install and run the source code.
    • +
  • The documentation of the codebase MUST contain examples demonstrating the key functionality.
    • +
  • The documentation of the codebase SHOULD contain a high level description that is clearly understandable for a wide audience of stakeholders, like the general public and journalists.
    • +
  • The documentation of the codebase SHOULD contain a section describing how to install and run a standalone version of the source code, including, if necessary, a test dataset.
    • +
  • The documentation of the codebase SHOULD contain examples for all functionality.
    • +
  • The documentation SHOULD describe the key components or modules of the codebase and their relationships, for example as a high level architectural diagram.
    • +
  • There SHOULD be continuous integration tests for the quality of the documentation.
    • +
  • Including examples that make users want to immediately start using the codebase in the documentation of the codebase is OPTIONAL.
    • +
  • Testing the code by using examples in the documentation is OPTIONAL.
    • +
+ +

Why this is important

+ +
    +
  • Users can start using and contributing more quickly.
    • +
  • You help people discover the codebase, especially people asking ‘is there already code that does something like this’.
    • +
  • This provides transparency into your organization and processes.
    • +
+ +

What this does not do

+ + + +

How to test

+ +
    +
  • Confirm that other stakeholders, professionals from other public organizations and the general public find the documentation clear and understandable.
    • +
  • Confirm that the documentation describes how to install and run the source code.
    • +
  • Confirm that the documentation includes examples of the key functionality.
    • +
  • Check with members of the general public and journalists if they can understand the high level description.
    • +
  • Check that the instructions for how to install and run a standalone version of the source code result in a running system.
    • +
  • Check that all functionality documented contains an example.
    • +
  • Check that the documentation includes a high level architectural diagram or similar.
    • +
  • Check that the documentation quality is part of integration testing, for example documentation is generated from code, and links and images are tested.
    • +
+ +

Policy makers: what you need to do

+ +
    +
  • Check in regularly to understand how the non-policy code in the codebase has changed.
    • +
  • Give feedback on how to make non-policy documentation more clear.
    • +
+ +

Management: what you need to do

+ +
    +
  • Try to use the codebase.
    • +
  • Make sure you understand both the policy and source code as well as the documentation.
    • +
+ +

Developers and designers: what you need to do

+ +
    +
  • Check in regularly to understand how the non-source code in the codebase has changed.
    • +
  • Give feedback on how to make non-source documentation more clear.
    • +
+ +

Further reading

+ + + +
+
+ + +
+ + +
+ + + + + + + + + + + + + + + diff --git a/_site/criteria_source/findability.html b/_site/criteria_source/findability.html new file mode 100644 index 00000000..81c126de --- /dev/null +++ b/_site/criteria_source/findability.html @@ -0,0 +1,374 @@ + + + + + + + + + Make the codebase findable, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

Contents

+
    +
  1. Requirements
    2. +
  2. Why this is important
    3. +
  3. What this does not do
    4. +
  4. How to test
    5. +
  5. Policy makers: what you need to do
    6. +
  6. Management: what you need to do
    7. +
  7. Developers and designers: what you need to do
    8. +
  8. Further reading
    9. +
+ + + + + + + +

Contribute on GitHub

+ + + +
+ + +
+ +
+

Make the codebase findable

+ + + + +

Requirements

+ +
    +
  • The codebase MUST be findable using a search engine by describing the problem it solves in natural language.
    • +
  • The codebase MUST be findable using a search engine by codebase name.
    • +
  • Maintainers SHOULD submit the codebase to relevant software catalogs.
    • +
  • The codebase SHOULD have a website which describes the problem the codebase solves using the preferred jargon of different potential users of the codebase (including technologists, policy experts and managers).
    • +
  • The codebase SHOULD have a unique and persistent identifier where the entry mentions the major contributors, repository location and website.
    • +
  • The codebase SHOULD include a machine-readable metadata description, for example in a publiccode.yml file.
    • +
  • A dedicated domain name for the codebase is OPTIONAL.
    • +
  • Regular presentations at conferences by the community are OPTIONAL.
    • +
+ +

Why this is important

+ +
    +
  • Proactiveness is needed; just publishing a codebase and hoping it’s found doesn’t work.
    • +
  • A metadata description file increases discoverability.
    • +
  • The more findable a codebase is, the more potential new collaborators will find it.
    • +
  • By having well-written metadata containing a unique and persistent identifer, such as a Wikidata item or FSF software directory listing, and thus being part of the semantic web, it will be easier for other people to refer, cite, disambiguate and discover the codebase through third party tools.
    • +
+ +

What this does not do

+ +
    +
  • Ensure new collaborators or replicators.
    • +
+ +

How to test

+ +
    +
  • Confirm that the codebase appears in the first set of results on more than one major search engine when searching by a plain English problem description.
    • +
  • Confirm that the codebase appears in the first set of results on more than one major search engine when searching by a technical problem description.
    • +
  • Confirm that the codebase appears in the first set of results on more than one major search engine when searching by the codebase name.
    • +
  • Check for the codebase listing in relevant software catalogs.
    • +
  • Check for a codebase website which describes the problem the codebase solves.
    • +
  • Check unique and persistent identifier entries for mention of the major contributors.
    • +
  • Check unique and persistent identifier entries for the repository location.
    • +
  • Check unique and persistent identifier entries for the codebase website.
    • +
  • Check for a machine-readable metadata description file.
    • +
+ +

Policy makers: what you need to do

+ +
    +
  • Contribute a description of the policy area or problem this codebase acts on or operates.
    • +
  • Test your problem description with peers outside of your context who aren’t familiar with the codebase.
    • +
  • Present on how the codebase implements the policy at relevent conferences.
    • +
+ +

Management: what you need to do

+ +
    +
  • Budget for content design and Search Engine Optimization skills in the team.
    • +
  • Ensure people involved in the project present at relevant conferences.
    • +
  • Search trademark databases to avoid confusion or infringement before deciding the name.
    • +
+ +

Developers and designers: what you need to do

+ +
    +
  • Search engine optimization.
    • +
  • Test your problem description with peers outside of your context who aren’t familiar with the codebase.
    • +
  • Suggest conferences to present at and present at them.
    • +
+ +

Further reading

+ + + +
+
+ + +
+ + +
+ + + + + + + + + + + + + + + diff --git a/_site/criteria_source/index.html b/_site/criteria_source/index.html new file mode 100644 index 00000000..0943eb16 --- /dev/null +++ b/_site/criteria_source/index.html @@ -0,0 +1,342 @@ + + + + + + + + + Criteria, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

Contents

+ + + + + + + + +

Contribute on GitHub

+ + + +
+ + +
+ + +
+ + +
+ + +
+ + + + + + + + + + + + + + + diff --git a/_site/criteria_source/index.md b/_site/criteria_source/index.md new file mode 100644 index 00000000..a76e29e4 --- /dev/null +++ b/_site/criteria_source/index.md @@ -0,0 +1,10 @@ +# Criteria + + + + +{% assign sorted = site.pages | sort:"order" %} + +{% for page in sorted %}{% if page.dir == "/criteria/" %}{% if page.name != "index.md" %}{% if page.title %} + +1. [{{page.title}}]({{page.url}}){% endif%} {% endif%} {% endif%}{% endfor %} diff --git a/_site/criteria_source/make-contributing-easy.html b/_site/criteria_source/make-contributing-easy.html new file mode 100644 index 00000000..dbf18b6b --- /dev/null +++ b/_site/criteria_source/make-contributing-easy.html @@ -0,0 +1,360 @@ + + + + + + + + + Make contributing easy, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

Contents

+
    +
  1. Requirements
    2. +
  2. Why this is important
    3. +
  3. What this does not do
    4. +
  4. How to test
    5. +
  5. Policy makers: what you need to do
    6. +
  6. Management: what you need to do
    7. +
  7. Developers and designers: what you need to do
    8. +
  8. Further reading
    9. +
+ + + + + + + +

Contribute on GitHub

+ + + +
+ + +
+ +
+

Make contributing easy

+ + + + +

Requirements

+ +
    +
  • The codebase MUST have a public issue tracker that accepts suggestions from anyone.
    • +
  • The codebase MUST include instructions for how to privately report security issues for responsible disclosure.
    • +
  • The documentation MUST link to both the public issue tracker and submitted codebase changes, for example in a README file.
    • +
  • The codebase MUST have communication channels for users and developers, for example email lists.
    • +
  • The documentation SHOULD include instructions for how to report potentially security sensitive issues on a closed channel.
    • +
+ +

Why this is important

+ +
    +
  • Enables users to fix problems and add features to the shared codebase leading to better, more reliable and feature rich software.
    • +
  • Allows collaborative uptake of shared digital infrastructure.
    • +
  • Helps users decide to use one codebase over another.
    • +
+ +

What this does not do

+ +
    +
  • Guarantee others will reuse the codebase.
    • +
+ +

How to test

+ +
    +
  • Confirm that there is a public issue tracker.
    • +
  • Confirm that there are instructions for privately reporting security issues.
    • +
  • Confirm that the codebase contains links to the public issue tracker and submitted codebase changes.
    • +
  • Confirm that it is possible to participate in a discussion with other users and developers about the software using channels described in the codebase.
    • +
+ +

Policy makers: what you need to do

+ +
    +
  • Track policy issues in the codebase, so that a relevant external policy expert can volunteer help.
    • +
+ +

Management: what you need to do

+ +
    +
  • Track management issues in the codebase, so that external managers with relevant experience can volunteer help.
    • +
  • Support your experienced policy makers, developers and designers to keep contributing to the codebase for as long as possible.
    • +
+ +

Developers and designers: what you need to do

+ +
    +
  • Respond promptly to requests.
    • +
  • Keep your management informed of the time and resources you require to support other contributors.
    • +
+ +

Further reading

+ + + +
+
+ + +
+ + +
+ + + + + + + + + + + + + + + diff --git a/_site/criteria_source/open-licenses.html b/_site/criteria_source/open-licenses.html new file mode 100644 index 00000000..fa2b267f --- /dev/null +++ b/_site/criteria_source/open-licenses.html @@ -0,0 +1,363 @@ + + + + + + + + + Publish with an open license, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

Contents

+
    +
  1. Requirements
    2. +
  2. Why this is important
    3. +
  3. What this does not do
    4. +
  4. How to test
    5. +
  5. Policy makers: what you need to do
    6. +
  6. Management: what you need to do
    7. +
  7. Developers and designers: what you need to do
    8. +
  8. Further reading
    9. +
+ + + + + + + +

Contribute on GitHub

+ + + +
+ + +
+ +
+

Publish with an open license

+ + + + +

Requirements

+ +
    +
  • All code and documentation MUST be licensed such that it may be freely reusable, changeable and redistributable.
    • +
  • Software source code MUST be licensed under an OSI-approved or FSF Free/Libre license.
    • +
  • All code MUST be published with a license file.
    • +
  • Contributors MUST NOT be required to transfer copyright of their contributions to the codebase.
    • +
  • All source code files in the codebase SHOULD include a copyright notice and a license header that are machine-readable.
    • +
  • Having multiple licenses for different types of code and documentation is OPTIONAL.
    • +
+ +

Why this is important

+ +
    +
  • Makes it possible for anyone to see the code and know that they can and how they can reuse it.
    • +
+ +

What this does not do

+ +
    +
  • Prevent use of the code by any specific actors.
    • +
+ +

How to test

+ + + +

Policy makers: what you need to do

+ +
    +
  • Develop policy that requires code to be open source.
    • +
  • Develop policy that disincentivizes non-open source code and technology in procurement.
    • +
+ +

Management: what you need to do

+ +
    +
  • Only work with open source vendors that deliver their code by publishing it under an open source license.
    • +
  • Beware that even though Creative Commons licenses are great for documentation, licenses that stipulate Non-Commercial or No Derivatives are NOT freely reusable, changeable and redistributable and don’t fulfill these requirements.
    • +
+ +

Developers and designers: what you need to do

+ +
    +
  • Add a new license file to every new codebase created.
    • +
  • Add a copyright notice and a license header to every new source code file created.
    • +
+ +

Further reading

+ + + +
+
+ + +
+ + +
+ + + + + + + + + + + + + + + diff --git a/_site/criteria_source/open-standards.html b/_site/criteria_source/open-standards.html new file mode 100644 index 00000000..d4b648fa --- /dev/null +++ b/_site/criteria_source/open-standards.html @@ -0,0 +1,359 @@ + + + + + + + + + Use open standards, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

Contents

+
    +
  1. Requirements
    2. +
  2. Why this is important
    3. +
  3. What this does not do
    4. +
  4. How to test
    5. +
  5. Policy makers: what you need to do
    6. +
  6. Management: what you need to do
    7. +
  7. Developers and designers: what you need to do
    8. +
  8. Further reading
    9. +
+ + + + + + + +

Contribute on GitHub

+ + + +
+ + +
+ +
+

Use open standards

+ + + + +

Requirements

+ +
    +
  • For features of the codebase that facilitate the exchange of data the codebase MUST use an open standard that meets the Open Source Initiative Open Standard Requirements.
    • +
  • Any non-open standards used MUST be recorded clearly as such in the documentation.
    • +
  • Any standard chosen for use within the codebase MUST be listed in the documentation with a link to where it is available.
    • +
  • Any non-open standards chosen for use within the codebase MUST NOT hinder collaboration and reuse.
    • +
  • If no existing open standard is available, effort SHOULD be put into developing one.
    • +
  • Standards that are machine testable SHOULD be preferred over those that are not.
    • +
+ +

Why this is important

+ +
    +
  • Creates interoperability between systems.
    • +
  • Reduces possible vendor lock-in.
    • +
  • Guarantees access to the knowledge required to reuse and contribute to the codebase.
    • +
+ +

What this does not do

+ +
    +
  • Make it understandable how to use the software.
    • +
+ +

How to test

+ +
    +
  • Confirm that data exchange follows an OSI approved open standard.
    • +
  • Confirm that any non-open standards used are clearly documented as such.
    • +
  • Confirm that documentation includes a list of the standards followed within the codebase, each with a working link, or a statement that no standards were chosen.
    • +
+ +

Policy makers: what you need to do

+ +
    +
  • Mandate use of open standards everywhere possible.
    • +
  • Prohibit procurement of technology that does not use open standards.
    • +
+ +

Management: what you need to do

+ +
    +
  • Consider including open standard compliance assessment in code reviews.
    • +
+ +

Developers and designers: what you need to do

+ +
    +
  • Add continuous integration tests for compliance with the standards.
    • +
  • Review the commits and other repository resources for references to standards and cross-check those with the standards listed.
    • +
+ +

Further reading

+ + + +
+
+ + +
+ + +
+ + + + + + + + + + + + + + + diff --git a/_site/criteria_source/open-to-contributions.html b/_site/criteria_source/open-to-contributions.html new file mode 100644 index 00000000..b1390e5c --- /dev/null +++ b/_site/criteria_source/open-to-contributions.html @@ -0,0 +1,371 @@ + + + + + + + + + Welcome contributors, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

Contents

+
    +
  1. Requirements
    2. +
  2. Why this is important
    3. +
  3. What this does not do
    4. +
  4. How to test
    5. +
  5. Policy makers: what you need to do
    6. +
  6. Management: what you need to do
    7. +
  7. Developers and designers: what you need to do
    8. +
  8. Further reading
    9. +
+ + + + + + + +

Contribute on GitHub

+ + + +
+ + +
+ +
+

Welcome contributors

+ + + + +

Requirements

+ +
    +
  • The codebase MUST allow anyone to submit suggestions for changes to the codebase.
    • +
  • The codebase MUST include contribution guidelines explaining what kinds of contributions are welcome and how contributors can get involved, for example in a CONTRIBUTING file.
    • +
  • The codebase MUST document the governance of the codebase, contributions and its community, for example in a GOVERNANCE file.
    • +
  • The codebase SHOULD advertise the committed engagement of involved organizations in the development and maintenance.
    • +
  • The codebase SHOULD have a publicly available roadmap.
    • +
  • The codebase SHOULD publish codebase activity statistics.
    • +
  • Including a code of conduct for contributors in the codebase is OPTIONAL.
    • +
+ +

Why this is important

+ +
    +
  • Helps newcomers understand and trust the codebase community’s leadership.
    • +
  • Prevents the community that works on a codebase splitting because there is no way to influence its goals and progress, resulting in diverging communities.
    • +
  • Helps users decide to use one codebase over another.
    • +
+ +

What this does not do

+ +
    +
  • Guarantee others will join the community.
    • +
  • Guarantee others will reuse the codebase.
    • +
+ +

How to test

+ +
    +
  • Confirm that it is possible to submit suggestions for changes to the codebase.
    • +
  • Confirm there are contribution guidelines.
    • +
  • Confirm that the codebase governance is clearly explained, including how to influence codebase governance.
    • +
  • Check for a list of involved organizations.
    • +
  • Check for a roadmap.
    • +
  • Check for published activity statistics.
    • +
  • Check for a code of conduct.
    • +
+ +

Policy makers: what you need to do

+ +
    +
  • Add a list to the codebase of any other resources that policy experts, non-governmental organizations and academics would find useful for understanding or reusing your policy.
    • +
  • Consider adding contact details so that other policy makers considering collaboration can ask you for advice.
    • +
+ +

Management: what you need to do

+ +
    +
  • Make sure that the documentation of the governance includes the current process for how to make changes to the governance.
    • +
  • If the community has some consensus about how the governance should change, then include those ideas stated as ambitions in the documentation.
    • +
  • Make sure the documentation explains how each organization is involved in the codebase, what resources it has available for it and for how long.
    • +
  • Support your experienced policy makers, developers and designers to stay part of the community for as long as possible.
    • +
+ +

Developers and designers: what you need to do

+ +
    +
  • Respond promptly to requests.
    • +
  • Keep your management informed of the time and resources you require to support other contributors.
    • +
+ +

Further reading

+ + + +
+
+ + +
+ + +
+ + + + + + + + + + + + + + + diff --git a/_site/criteria_source/require-review.html b/_site/criteria_source/require-review.html new file mode 100644 index 00000000..4ee8ff7f --- /dev/null +++ b/_site/criteria_source/require-review.html @@ -0,0 +1,380 @@ + + + + + + + + + Require review of contributions, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

Contents

+
    +
  1. Requirements
    2. +
  2. Why this is important
    3. +
  3. What this does not do
    4. +
  4. How to test
    5. +
  5. Policy makers: what you need to do
    6. +
  6. Management: what you need to do
    7. +
  7. Developers and designers: what you need to do
    8. +
  8. Further reading
    9. +
+ + + + + + + +

Contribute on GitHub

+ + + +
+ + +
+ +
+

Require review of contributions

+ + + + +

Requirements

+ +
    +
  • All contributions that are accepted or committed to release versions of the codebase MUST be reviewed by another contributor.
    • +
  • Reviews MUST include source, policy, tests and documentation.
    • +
  • Reviewers MUST provide feedback on all decisions to not accept a contribution.
    • +
  • Contributions SHOULD conform to the standards, architecture and decisions set out in the codebase in order to pass review.
    • +
  • Reviews SHOULD include running both the code and the tests of the codebase.
    • +
  • Contributions SHOULD be reviewed by someone in a different context than the contributor.
    • +
  • Version control systems SHOULD NOT accept non-reviewed contributions in release versions.
    • +
  • Reviews SHOULD happen within two business days.
    • +
  • Performing reviews by multiple reviewers is OPTIONAL.
    • +
+ +

Why this is important

+ +
    +
  • Increases codebase quality.
    • +
  • Reduces security risks as well as operational risks.
    • +
  • Creates a culture of making every contribution great.
    • +
  • Catches the most obvious mistakes that could happen.
    • +
  • Gives contributors the security that their contributions are only accepted if they really add value.
    • +
  • Assures contributors of a guaranteed time for feedback or collaborative improvement.
    • +
  • Prompt reviews increase both rate of delivery and contributor engagement.
    • +
+ +

What this does not do

+ +
    +
  • Guarantee the right solution to a problem.
    • +
  • Mean that reviewers are liable.
    • +
  • Absolve a contributor from writing documentation and tests.
    • +
  • Provide you with the right reviewers.
    • +
+ +

How to test

+ +
    +
  • Confirm that every commit in the history has been reviewed by a different contributor.
    • +
  • Confirm that reviews include source, policy, tests and documentation.
    • +
  • Confirm that rejected contributions were appropriately explained.
    • +
  • Check if reviews cover conformance to standards, architecture and codebase guidelines.
    • +
  • Check with reviewers if they run the code and tests during review.
    • +
  • Check with reviewers if commits have been reviewed by a different contributor in a different context.
    • +
  • Check for use of branch protection in the version control system.
    • +
  • Check the times between contribution submission and review.
    • +
+ +

Policy makers: what you need to do

+ +
    +
  • Institute a ‘four eyes’ policy where everything, not just code, is reviewed.
    • +
  • Use a version control system or methodology that enables review and feedback.
    • +
+ +

Management: what you need to do

+ +
    +
  • Make delivering great code a shared objective.
    • +
  • Make sure writing and reviewing contributions to source, policy, documentation and tests are considered equally valuable.
    • +
  • Create a culture where all contributions are welcome and everyone is empowered to review them.
    • +
  • Make sure no contributor is ever alone in contributing to a codebase.
    • +
+ +

Developers and designers: what you need to do

+ +
    +
  • Ask other contributors on the codebase to review your work, in your organization or outside of it.
    • +
  • Try to respond to others’ requests for code review promptly, initially providing feedback about the concept of the change.
    • +
+ +

Further reading

+ + + +
+
+ + +
+ + +
+ + + + + + + + + + + + + + + diff --git a/_site/criteria_source/reusable-and-portable-codebases.html b/_site/criteria_source/reusable-and-portable-codebases.html new file mode 100644 index 00000000..ca82bae3 --- /dev/null +++ b/_site/criteria_source/reusable-and-portable-codebases.html @@ -0,0 +1,382 @@ + + + + + + + + + Create reusable and portable code, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

Contents

+
    +
  1. Requirements
    2. +
  2. Why this is important
    3. +
  3. What this does not do
    4. +
  4. How to test
    5. +
  5. Policy makers: what you need to do
    6. +
  6. Management: what you need to do
    7. +
  7. Developers and designers: what you need to do
    8. +
  8. Further reading
    9. +
+ + + + + + + +

Contribute on GitHub

+ + + +
+ + +
+ +
+

Create reusable and portable code

+ + + + +

Requirements

+ +
    +
  • The codebase MUST be developed to be reusable in different contexts.
    • +
  • The codebase MUST be independent from any secret, undisclosed, proprietary or non-open licensed code or services for execution and understanding.
    • +
  • The codebase SHOULD be in use by multiple parties.
    • +
  • The roadmap SHOULD be influenced by the needs of multiple parties.
    • +
  • Configuration SHOULD be used to make code adapt to context specific needs.
    • +
  • The codebase SHOULD be localizable.
    • +
  • Code and its documentation SHOULD NOT contain situation-specific information.
    • +
  • Codebase modules SHOULD be documented in such a way as to enable reuse in codebases in other contexts.
    • +
+ +

Why this is important

+ +
    +
  • Enables other policy makers, developers and designers to reuse what you’ve developed, to test it, to improve it and contribute those improvements back leading to better quality, cheaper maintenance and higher reliability.
    • +
  • Makes the code easier for new people to understand (as it’s more general).
    • +
  • Makes it easier to control the mission, vision and scope of the codebase because the codebase is thoughtfully and purposefully designed for reusability.
    • +
  • Codebases used by multiple parties are more likely to benefit from a self-sustaining community.
    • +
  • Any contributor is able to test and contribute without relying on the situation-specific infrastructure of any other contributor or deployment.
    • +
  • Composing a codebase from well documented modules improves reusability and maintainability.
    • +
  • A module is easier to reuse in another context if its purpose is clearly documented.
    • +
+ +

What this does not do

+ +
    +
  • Get others to reuse the codebase.
    • +
  • Build a community.
    • +
  • Shift responsibility for documentation, support, bug-fixing, etc. to another party.
    • +
  • Guarantee that modules are generic enough to be reused in any context.
    • +
+ +

How to test

+ +
    +
  • Confirm with someone in a similar role at another organization if they can reuse the codebase and what that would entail.
    • +
  • Confirm that the codebase can run without using any proprietary or non open-licensed code or services.
    • +
  • Check that the codebase is in use by multiple parties or in multiple contexts.
    • +
  • Check that the codebase files and commit history do not include situation-specific data.
    • +
+ +

Policy makers: what you need to do

+ +
    +
  • Document your policy with enough clarity and detail that it can be understood outside of its original context.
    • +
  • Make sure your organization is listed as a known user by the codebase.
    • +
+ +

Management: what you need to do

+ +
    +
  • Make sure that stakeholders and business owners understand that reusability is an explicit codebase goal as this reduces technical debt and provides sustainability for the codebase.
    • +
+ +

Developers and designers: what you need to do

+ +

Source should be designed:

+ +
    +
  • for reuse by other users and organizations regardless of locale,
    • +
  • to solve a general problem instead of a specific one,
    • +
  • in logically meaningful and isolated modules,
    • +
  • so that someone in a similar organization facing a similar problem would be able to use (parts of) the solution.
    • +
+ +

Ensure that the codebase documentation describes the build-time and runtime dependencies. +If your context requires deploying to proprietary platforms or using proprietary components, ensure that collaborators can develop, use, test, and deploy without them.

+ +

For each commit, reviewers verify that content does not include situation-specific data such as hostnames, personal and organizational data, or tokens and passwords.

+ +

Further reading

+ + + +
+
+ + +
+ + +
+ + + + + + + + + + + + + + + diff --git a/_site/criteria_source/style.html b/_site/criteria_source/style.html new file mode 100644 index 00000000..6275c4ff --- /dev/null +++ b/_site/criteria_source/style.html @@ -0,0 +1,362 @@ + + + + + + + + + Use a coherent style, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

Contents

+
    +
  1. Requirements
    2. +
  2. Why this is important
    3. +
  3. What this does not do
    4. +
  4. How to test
    5. +
  5. Policy makers: what you need to do
    6. +
  6. Management: what you need to do
    7. +
  7. Developers and designers: what you need to do
    8. +
  8. Further reading
    9. +
+ + + + + + + +

Contribute on GitHub

+ + + +
+ + +
+ +
+

Use a coherent style

+ + + + +

Requirements

+ +
    +
  • Contributions MUST adhere to either a coding or writing style guide, either the codebase community’s own or an existing one that is advertised in or part of the codebase.
    • +
  • Contributions SHOULD pass automated tests on style.
    • +
  • The codebase SHOULD include inline comments and documentation for non-trivial sections.
    • +
  • Including sections on understandable English in the style guide is OPTIONAL.
    • +
+ +

Why this is important

+ +
    +
  • Enables contributors in different environments to work together on a unified product.
    • +
  • Unifying vocabularies reduces friction in communication between contributors.
    • +
+ +

What this does not do

+ +
    +
  • Help contributors write well or effectively explain what they do.
    • +
+ +

How to test

+ +
    +
  • Confirm that contributions are in line with the style guides specified in the documentation.
    • +
  • Check for the presence of automated tests on style.
    • +
+ +

Policy makers: what you need to do

+ +
    +
  • Create, follow and continually improve on a style guide for policy and documentation as well as document this in the codebase, for example in the CONTRIBUTING or README.
    • +
+ +

Management: what you need to do

+ +
    +
  • Include written language, source, test and policy standards in your organizational definition of quality.
    • +
+ +

Developers and designers: what you need to do

+ +

If the codebase does not already have engineering guidelines or other contributor guidance, start by adding documentation to the repository describing whatever is being done now, for example in the CONTRIBUTING or README. +An important purpose of the file is to communicate design preferences, naming conventions, and other aspects machines can’t easily check. +Guidance should include what would be expected from code contributions in order for them to be merged by the maintainers, including source, tests and documentation. +Continually improve upon and expand this documentation with the aim of evolving this documentation into engineering guidelines.

+ +

Additionally:

+ +
    +
  • Use a linter.
    • +
  • Add linter configurations to the codebase.
    • +
+ +

Further reading

+ + + +
+
+ + +
+ + +
+ + + + + + + + + + + + + + + diff --git a/_site/criteria_source/understandable-english-first.html b/_site/criteria_source/understandable-english-first.html new file mode 100644 index 00000000..f09974cd --- /dev/null +++ b/_site/criteria_source/understandable-english-first.html @@ -0,0 +1,367 @@ + + + + + + + + + Use plain English, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

Contents

+
    +
  1. Requirements
    2. +
  2. Why this is important
    3. +
  3. What this does not do
    4. +
  4. How to test
    5. +
  5. Policy makers: what you need to do
    6. +
  6. Management: what you need to do
    7. +
  7. Developers and designers: what you need to do
    8. +
  8. Further reading
    9. +
+ + + + + + + +

Contribute on GitHub

+ + + +
+ + +
+ +
+

Use plain English

+ + + + +

Requirements

+ +
    +
  • All codebase documentation MUST be in English.
    • +
  • All code MUST be in English, except where policy is machine interpreted as code.
    • +
  • All bundled policy not available in English MUST have an accompanying summary in English.
    • +
  • Any translation MUST be up to date with the English version and vice versa.
    • +
  • There SHOULD be no acronyms, abbreviations, puns or legal/non-English/domain specific terms in the codebase without an explanation preceding it or a link to an explanation.
    • +
  • The name of the codebase SHOULD be descriptive and free from acronyms, abbreviations, puns or organizational branding.
    • +
  • Documentation SHOULD aim for a lower secondary education reading level, as recommended by the Web Content Accessibility Guidelines 2.
    • +
  • Providing a translation of any code, documentation or tests is OPTIONAL.
    • +
+ +

Why this is important

+ +
    +
  • Makes the codebase and what it does understandable for a wider variety of stakeholders in multiple contexts.
    • +
  • Helps with the discoverability of the codebase.
    • +
  • Can help you meet the European Union accessibility directive, which requires most public sector information to be accessible.
    • +
+ +

What this does not do

+ +
    +
  • Make explanations of the codebase’s functionality understandable.
    • +
  • Make your organization’s jargon understandable without an explanation.
    • +
+ +

How to test

+ +
    +
  • Confirm that codebase documentation is available in English.
    • +
  • Confirm that source code is in English, or confirm any non-English is policy or terms with preceding explanations.
    • +
  • Confirm any non-English policy has an accompanying summary in English.
    • +
  • Confirm that translations and the English version have the same content.
    • +
  • Check that no unexplained acronyms, abbreviations, puns or legal/non-English/domain specific terms are in the documentation.
    • +
  • Check the spelling, grammar and readability of the documentation.
    • +
+ +

Policy makers: what you need to do

+ +
    +
  • Frequently test with other management, developers and designers in the process if they understand what you are delivering and how you document it.
    • +
+ +

Management: what you need to do

+ +
    +
  • Try to limit the use of acronyms, abbreviations, puns or legal/non-English/domain specific terms in internal communications in and between teams and stakeholders. Add any such terms to a glossary and link to it from the places they are being used.
    • +
  • Be critical of documentation and descriptions in proposals and changes. If you don’t understand something, others will probably also struggle with it.
    • +
+ +

Developers and designers: what you need to do

+ +
    +
  • Frequently test with policy makers and management if they understand what you are delivering and how you document it.
    • +
  • Ask someone outside of your context if they understand the content (for example, a developer working on a different codebase).
    • +
+ +

Further reading

+ + + +
+
+ + +
+ + +
+ + + + + + + + + + + + + + + diff --git a/_site/criteria_source/version-control-and-history.html b/_site/criteria_source/version-control-and-history.html new file mode 100644 index 00000000..b993bb01 --- /dev/null +++ b/_site/criteria_source/version-control-and-history.html @@ -0,0 +1,386 @@ + + + + + + + + + Maintain version control, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

Contents

+
    +
  1. Requirements
    2. +
  2. Why this is important
    3. +
  3. What this does not do
    4. +
  4. How to test
    5. +
  5. Policy makers: what you need to do
    6. +
  6. Management: what you need to do
    7. +
  7. Developers and designers: what you need to do
    8. +
  8. Further reading
    9. +
+ + + + + + + +

Contribute on GitHub

+ + + +
+ + +
+ +
+

Maintain version control

+ + + + +

Requirements

+ +
    +
  • The community MUST have a way to maintain version control for the code.
    • +
  • All files in the codebase MUST be version controlled.
    • +
  • All decisions MUST be documented in commit messages.
    • +
  • Every commit message MUST link to discussions and issues wherever possible.
    • +
  • The codebase SHOULD be maintained in a distributed version control system.
    • +
  • Contributors SHOULD group relevant changes in commits.
    • +
  • Maintainers SHOULD mark released versions of the codebase, for example using revision tags or textual labels.
    • +
  • Contributors SHOULD prefer file formats where the changes within the files can be easily viewed and understood in the version control system.
    • +
  • It is OPTIONAL for contributors to sign their commits and provide an email address, so that future contributors are able to contact past contributors with questions about their work.
    • +
+ +

Why this is important

+ +

Version control means keeping track of changes to the code over time. This allows you to create structured documentation of the history of the codebase. This is essential for collaboration at scale.

+ +

Distributed version control enables you to:

+ +
    +
  • have a full copy of the code and its history
    • +
  • revert to an earlier version of the codebase whenever you want to
    • +
  • record your changes and the reasons why you made them, to help future developers understand the process
    • +
  • compare two different versions
    • +
  • work on changes in parallel as a team before merging them together
    • +
  • continue to work when the network is unavailable, merging changes back with everyone else’s at a later date
    • +
+ +

What this does not do

+ +
    +
  • Substitute for advertising maturity.
    • +
  • Guarantee the code executes correctly.
    • +
  • Guarantee collaborators.
    • +
+ +

How to test

+ +
    +
  • Confirm that the codebase is kept in version control using software such as Git.
    • +
  • Review the commit history, confirming that all commit messages explain why the change was made.
    • +
  • Review the commit history, confirming that where possible all commit messages include the discussion about the change was or where to find it (with a URL).
    • +
  • Check if the version control system is distributed.
    • +
  • Review the commit history, check if grouping of relevant changes in accordance with the contributing guidelines.
    • +
  • Check that it is possible to access a specific version of the codebase, for example through a revision tag or a textual label.
    • +
  • Check that the file formats used in the codebase are text formats where possible.
    • +
+ +

Policy makers: what you need to do

+ +
    +
  • If a new version of the codebase is created because of a policy change, make sure it’s clear in the documentation: +
      +
    • what the policy change is,
      • +
    • how it’s changed the codebase.
      • +
    +
    • +
+ +

For example, adding a new category of applicant to a codebase that manages granting permits would be considered a policy change.

+ +

Management: what you need to do

+ +
    +
  • Support policy makers, developers and designers to be clear about what improvements they’re making to the codebase. Making improvements isn’t a public relations risk.
    • +
+ +

Developers and designers: what you need to do

+ +
    +
  • Write clear commit messages so that it is easy to understand why the commit was made.
    • +
  • Mark different versions so that it is easy to access a specific version, for example using revision tags or textual labels.
    • +
  • Write clear commit messages so that versions can be usefully compared.
    • +
  • Work with policy makers to describe how the source code was updated after a policy change.
    • +
+ +

Further reading

+ + + +
+
+ + +
+ + +
+ + + + + + + + + + + + + + + diff --git a/_site/docker.sh b/_site/docker.sh new file mode 100644 index 00000000..b5f3ab98 --- /dev/null +++ b/_site/docker.sh @@ -0,0 +1,9 @@ +#!/bin/bash + +path=`pwd` +docker run -d \ + -v ${path}:/var/www/html \ + -v ${path}/docker/apache-data:/etc/apache2/sites-available \ + -p 8090:80 \ + --name=standard \ + steps/standard diff --git a/_site/docker/apache-data/000-default.conf b/_site/docker/apache-data/000-default.conf new file mode 100644 index 00000000..72b4196e --- /dev/null +++ b/_site/docker/apache-data/000-default.conf @@ -0,0 +1,34 @@ + + # The ServerName directive sets the request scheme, hostname and port that + # the server uses to identify itself. This is used when creating + # redirection URLs. In the context of virtual hosts, the ServerName + # specifies what hostname must appear in the request's Host: header to + # match this virtual host. For the default virtual host (this file) this + # value is not decisive as it is used as a last resort host regardless. + # However, you must set it for any further virtual host explicitly. + #ServerName www.example.com + + ServerAdmin webmaster@localhost + DocumentRoot /var/www/html/_site + + AllowOverride All + + + # Available loglevels: trace8, ..., trace1, debug, info, notice, warn, + # error, crit, alert, emerg. + # It is also possible to configure the loglevel for particular + # modules, e.g. + #LogLevel info ssl:warn + + ErrorLog ${APACHE_LOG_DIR}/error.log + CustomLog ${APACHE_LOG_DIR}/access.log combined + + # For most configuration files from conf-available/, which are + # enabled or disabled at a global level, it is possible to + # include a line for only one particular virtual host. For example the + # following line enables the CGI configuration for this host only + # after it has been globally disabled with "a2disconf". + #Include conf-available/serve-cgi-bin.conf + + +# vim: syntax=apache ts=4 sw=4 sts=4 sr noet diff --git a/_site/docs/checklist.html b/_site/docs/checklist.html new file mode 100644 index 00000000..5bc1b865 --- /dev/null +++ b/_site/docs/checklist.html @@ -0,0 +1,230 @@ + + + + + + +Standard for Public Code Checklist + + + +

Standard for Public Code version 0.7.1 checklist

+ +

☐ Code in the open

+ +
    +
  • All source code for any policy in use (unless used for fraud detection) MUST be published and publicly accessible.
    • +
  • All source code for any software in use (unless used for fraud detection) MUST be published and publicly accessible.
    • +
  • The codebase MUST NOT contain sensitive information regarding users, their organization or third parties.
    • +
  • Any source code not currently in use (such as new versions, proposals or older versions) SHOULD be published.
    • +
  • Documenting which source code or policy underpins any specific interaction the general public may have with an organization is OPTIONAL.
    • +
+ +

☐ Bundle policy and source code

+ +
    +
  • The codebase MUST include the policy that the source code is based on.
    • +
  • If a policy is based on source code, that source code MUST be included in the codebase, unless used for fraud detection.
    • +
  • Policy SHOULD be provided in machine readable and unambiguous formats.
    • +
  • Continuous integration tests SHOULD validate that the source code and the policy are executed coherently.
    • +
+ +

☐ Make the codebase reusable and portable

+ +
    +
  • The codebase MUST be developed to be reusable in different contexts.
    • +
  • The codebase MUST be independent from any secret, undisclosed, proprietary or non-open licensed software or services for execution and understanding.
    • +
  • The codebase SHOULD be in use by multiple parties.
    • +
  • The roadmap SHOULD be influenced by the needs of multiple parties.
    • +
  • The development of the codebase SHOULD be a collaboration between multiple parties.
    • +
  • Configuration SHOULD be used to make source code adapt to context specific needs.
    • +
  • The codebase SHOULD be localizable.
    • +
  • Source code and its documentation SHOULD NOT contain situation-specific information.
    • +
  • Codebase modules SHOULD be documented in such a way as to enable reuse in codebases in other contexts.
    • +
  • The software SHOULD NOT require services or platforms available from only a single vendor.
    • +
+ +

☐ Welcome contributors

+ +
    +
  • The codebase MUST allow anyone to submit suggestions for changes to the codebase.
    • +
  • The codebase MUST include contribution guidelines explaining what kinds of contributions are welcome and how contributors can get involved, for example in a `CONTRIBUTING` file.
    • +
  • The codebase MUST document the governance of the codebase, contributions and its community, for example in a `GOVERNANCE` file.
    • +
  • The contribution guidelines SHOULD document who is expected to cover the costs of reviewing contributions.
    • +
  • The codebase SHOULD advertise the committed engagement of involved organizations in the development and maintenance.
    • +
  • The codebase SHOULD have a publicly available roadmap.
    • +
  • The codebase SHOULD publish codebase activity statistics.
    • +
  • Including a code of conduct for contributors in the codebase is OPTIONAL.
    • +
+ +

☐ Make contributing easy

+ +
    +
  • The codebase MUST have a public issue tracker that accepts suggestions from anyone.
    • +
  • The documentation MUST link to both the public issue tracker and submitted codebase changes, for example in a `README` file.
    • +
  • The codebase MUST have communication channels for users and developers, for example email lists.
    • +
  • There MUST be a way to report security issues for responsible disclosure over a closed channel.
    • +
  • The documentation MUST include instructions for how to report potentially security sensitive issues.
    • +
+ +

☐ Maintain version control

+ +
    +
  • All files in the codebase MUST be version controlled.
    • +
  • All decisions MUST be documented in commit messages.
    • +
  • Every commit message MUST link to discussions and issues wherever possible.
    • +
  • The codebase SHOULD be maintained in a distributed version control system.
    • +
  • Contribution guidelines SHOULD require contributors to group relevant changes in commits.
    • +
  • Maintainers SHOULD mark released versions of the codebase, for example using revision tags or textual labels.
    • +
  • Contribution guidelines SHOULD encourage file formats where the changes within the files can be easily viewed and understood in the version control system.
    • +
  • It is OPTIONAL for contributors to sign their commits and provide an email address, so that future contributors are able to contact past contributors with questions about their work.
    • +
+ +

☐ Require review of contributions

+ +
    +
  • All contributions that are accepted or committed to release versions of the codebase MUST be reviewed by another contributor.
    • +
  • Reviews MUST include source, policy, tests and documentation.
    • +
  • Reviewers MUST provide feedback on all decisions to not accept a contribution.
    • +
  • The review process SHOULD confirm that a contribution conforms to the standards, architecture and decisions set out in the codebase in order to pass review.
    • +
  • Reviews SHOULD include running both the software and the tests of the codebase.
    • +
  • Contributions SHOULD be reviewed by someone in a different context than the contributor.
    • +
  • Version control systems SHOULD NOT accept non-reviewed contributions in release versions.
    • +
  • Reviews SHOULD happen within two business days.
    • +
  • Performing reviews by multiple reviewers is OPTIONAL.
    • +
+ +

☐ Document codebase objectives

+ +
    +
  • The codebase MUST contain documentation of its objectives, like a mission and goal statement, that is understandable by developers and designers so that they can use or contribute to the codebase.
    • +
  • Codebase documentation SHOULD clearly describe the connections between policy objectives and codebase objectives.
    • +
  • Documenting the objectives of the codebase for the general public is OPTIONAL.
    • +
+ +

☐ Document the code

+ +
    +
  • All of the functionality of the codebase, policy as well as source code, MUST be described in language clearly understandable for those that understand the purpose of the codebase.
    • +
  • The documentation of the codebase MUST contain a description of how to install and run the software.
    • +
  • The documentation of the codebase MUST contain examples demonstrating the key functionality.
    • +
  • The documentation of the codebase SHOULD contain a high level description that is clearly understandable for a wide audience of stakeholders, like the general public and journalists.
    • +
  • The documentation of the codebase SHOULD contain a section describing how to install and run a standalone version of the source code, including, if necessary, a test dataset.
    • +
  • The documentation of the codebase SHOULD contain examples for all functionality.
    • +
  • The documentation SHOULD describe the key components or modules of the codebase and their relationships, for example as a high level architectural diagram.
    • +
  • There SHOULD be continuous integration tests for the quality of the documentation.
    • +
  • Including examples that make users want to immediately start using the codebase in the documentation of the codebase is OPTIONAL.
    • +
+ +

☐ Use plain English

+ +
    +
  • All codebase documentation MUST be in English.
    • +
  • All source code MUST be in English, except where policy is machine interpreted as code.
    • +
  • All bundled policy not available in English MUST have an accompanying summary in English.
    • +
  • Any translation MUST be up to date with the English version and vice versa.
    • +
  • There SHOULD be no acronyms, abbreviations, puns or legal/non-English/domain specific terms in the codebase without an explanation preceding it or a link to an explanation.
    • +
  • Documentation SHOULD aim for a lower secondary education reading level, as recommended by the Web Content Accessibility Guidelines 2.
    • +
  • Providing a translation of any code, documentation or tests is OPTIONAL.
    • +
+ +

☐ Use open standards

+ +
    +
  • For features of the codebase that facilitate the exchange of data the codebase MUST use an open standard that meets the Open Source Initiative Open Standard Requirements.
    • +
  • Any non-open standards used MUST be recorded clearly as such in the documentation.
    • +
  • Any standard chosen for use within the codebase MUST be listed in the documentation with a link to where it is available.
    • +
  • Any non-open standards chosen for use within the codebase MUST NOT hinder collaboration and reuse.
    • +
  • If no existing open standard is available, effort SHOULD be put into developing one.
    • +
  • Open standards that are machine testable SHOULD be preferred over open standards that are not.
    • +
  • Non-open standards that are machine testable SHOULD be preferred over non-open standards that are not.
    • +
+ +

☐ Use continuous integration

+ +
    +
  • All functionality in the source code MUST have automated tests.
    • +
  • Contributions MUST pass all automated tests before they are admitted into the codebase.
    • +
  • The codebase MUST have guidelines explaining how to structure contributions.
    • +
  • The codebase MUST have active contributors who can review contributions.
    • +
  • Automated test results for contributions SHOULD be public.
    • +
  • The codebase guidelines SHOULD state that each contribution should focus on a single issue.
    • +
  • Source code test and documentation coverage SHOULD be monitored.
    • +
  • Testing policy and documentation for consistency with the source and vice versa is OPTIONAL.
    • +
  • Testing policy and documentation for style and broken links is OPTIONAL.
    • +
  • Testing the software by using examples in the documentation is OPTIONAL.
    • +
+ +

☐ Publish with an open license

+ +
    +
  • All source code and documentation MUST be licensed such that it may be freely reusable, changeable and redistributable.
    • +
  • Software source code MUST be licensed under an OSI-approved or FSF Free/Libre license.
    • +
  • All source code MUST be published with a license file.
    • +
  • Contributors MUST NOT be required to transfer copyright of their contributions to the codebase.
    • +
  • All source code files in the codebase SHOULD include a copyright notice and a license header that are machine-readable.
    • +
  • Having multiple licenses for different types of source code and documentation is OPTIONAL.
    • +
+ +

☐ Make the codebase findable

+ +
    +
  • The name of the codebase SHOULD be descriptive and free from acronyms, abbreviations, puns or organizational branding.
    • +
  • The codebase SHOULD have a short description that helps someone understand what the codebase is for or what it does.
    • +
  • Maintainers SHOULD submit the codebase to relevant software catalogs.
    • +
  • The codebase SHOULD have a website which describes the problem the codebase solves using the preferred jargon of different potential users of the codebase (including technologists, policy experts and managers).
    • +
  • The codebase SHOULD be findable using a search engine by codebase name.
    • +
  • The codebase SHOULD be findable using a search engine by describing the problem it solves in natural language.
    • +
  • The codebase SHOULD have a unique and persistent identifier where the entry mentions the major contributors, repository location and website.
    • +
  • The codebase SHOULD include a machine-readable metadata description, for example in a publiccode.yml file.
    • +
  • A dedicated domain name for the codebase is OPTIONAL.
    • +
  • Regular presentations at conferences by the community are OPTIONAL.
    • +
+ +

☐ Use a coherent style

+ +
    +
  • The codebase MUST use a coding or writing style guide, either the codebase community's own or an existing one referred to in the codebase.
    • +
  • Contributions SHOULD pass automated tests on style.
    • +
  • The style guide SHOULD include expectations for inline comments and documentation for non-trivial sections.
    • +
  • Including expectations for understandable English in the style guide is OPTIONAL.
    • +
+ +

☐ Document codebase maturity

+ +
    +
  • The codebase MUST be versioned.
    • +
  • The codebase MUST prominently document whether or not there are versions of the codebase that are ready to use.
    • +
  • Codebase versions that are ready to use MUST only depend on versions of other codebases that are also ready to use.
    • +
  • The codebase SHOULD contain a log of changes from version to version, for example in the `CHANGELOG`.
    • +
  • The method for assigning version identifiers SHOULD be documented.
    • +
  • It is OPTIONAL to use semantic versioning.
    • +
+ + diff --git a/_site/docs/printing.html b/_site/docs/printing.html new file mode 100644 index 00000000..9333f311 --- /dev/null +++ b/_site/docs/printing.html @@ -0,0 +1,261 @@ + + + + + + + + + 印刷, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

目次

+ + + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

印刷

+ + + + +

《公共程式標準》是由 Reclameland 負責印刷。本指引試著提供印刷相關資訊，方便您到 Reclameland 或其他地方印刷。

+ +

印刷詳細資訊（多數依照 Reclameland 網頁上的順序，依需要附上荷蘭語）：

+ +
    +
  • 樣式：平裝書 (Reclameland 產品頁面)
    • +
  • 紙張尺寸：A4
    • +
  • 直向或橫向：直向 (Staand)
    • +
  • 內頁印刷：正四反四 4/4，雙面全色印刷
    • +
  • 內頁材質：Biotop 90克
    • +
  • 封面：350 克封面
    • +
  • 封面印刷：正四反空 4/0，單面滿版印刷
    • +
  • 封面處理：單面霧面層剝處理 (Enke)
    • +
  • 頁數：書內頁數 + 4 + x，x 是 0-3頁，讓總頁數是 4 的倍數
    • +
  • 個別封裝：無
    • +
+ +

一旦選定這些印刷的詳細資訊，封面與內頁就會上傳，並且下單與付費。付費後才會開始印刷。

+ +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/docs/printing.md b/_site/docs/printing.md new file mode 100644 index 00000000..abb13962 --- /dev/null +++ b/_site/docs/printing.md @@ -0,0 +1,21 @@ +# 印刷 + + + + +《公共程式標準》是由 Reclameland 負責印刷。本指引試著提供印刷相關資訊，方便您到 Reclameland 或其他地方印刷。 + +印刷詳細資訊（多數依照 Reclameland 網頁上的順序，依需要附上荷蘭語）： + +* 樣式：平裝書 ([Reclameland 產品頁面](https://www.reclameland.nl/drukken/softcover-boeken)) +* 紙張尺寸：A4 +* 直向或橫向：直向 (Staand) +* 內頁印刷：正四反四 4/4，雙面全色印刷 +* 內頁材質：Biotop 90克 +* 封面：350 克封面 +* 封面印刷：正四反空 4/0，單面滿版印刷 +* 封面處理：單面霧面層剝處理 (Enke) +* 頁數：書內頁數 + 4 + x，x 是 0-3頁，讓總頁數是 4 的倍數 +* 個別封裝：無 + +一旦選定這些印刷的詳細資訊，封面與內頁就會上傳，並且下單與付費。付費後才會開始印刷。 diff --git a/_site/docs/releasing.html b/_site/docs/releasing.html new file mode 100644 index 00000000..1c4a1227 --- /dev/null +++ b/_site/docs/releasing.html @@ -0,0 +1,310 @@ + + + + + + + + + 發行新版本的《公共程式標準》, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

目次

+ + + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

發行新版本的《公共程式標準》

+ + + + +
    +
  1. 審查「develop」分支的狀態 +
      +
    • 確認預計收入該次發行版的所有變更都已完成合併
      • +
    • 邀請校對該分支目前的狀態 +
        +
      • 如果有引入新的破折號，檢查是否能簡化文字並且移除破折號，例如改用較簡易的句子。如果需要用到複雜的句子，檢查是否能用其他標點符號來取代破折號。如果破折號最適合用來 +表達該句子的涵義，則請遵守《芝加哥格式手 +冊》的規範。
        • +
      +
      • +
    +
    2. +
  2. 建立發行用分支 +
      +
    • 從「develop」分支下命令，git switch -c "release-$MAJOR.$MINOR.$PATCH"
      • +
    • 推送分支，git push -u origin release-$MAJOR.$MINOR.$PATCH
      • +
    +
    3. +
  3. 更新本次新發行 +
      +
    • 在 AUTHORS.md 中加入新貢獻者的資料
      • +
    • 更新 CHANGELOG.md
      • +
    • 更新 roadmap.md
      • +
    • 透過 diff 進行額外傳輸到「main」分支 +
        +
      • 執行 script/generate-review-template.sh 並送交更新後的 docs/review-template.html 版次記 +錄
        • +
      • 使用審查範本中的新文字來更新 docs/standard-for-public-code.html，會將任何狀態變更作為結果更新
        • +
      • 重新檢查用字有變更的任何小節或段落，確保變更的字詞適合該整體內容，並且沒有文法或拼字錯誤
        • +
      • 確認有安裝字型，請參見：script/ensure-font.sh
        • +
      • 使用 script/pdf.sh rc1 檢查轉譯出的 .pdf 檔 +
          +
        • 確認沒有連結相衝的問題
          • +
        • 檢查文字分頁之處，可能需要移除或新增 CSS 分頁語法，像是：<p style="page-break-after: always;"></p>
          • +
        +
        • +
      • 如果有需要，送交修正版次，並重複進行額外傳輸
        • +
      +
      • +
    • 推送分支，與「main」分支比較，範例： +https://github.com/publiccodenet/standard/compare/main...release-$MAJOR.$MINOR.$PATCH +
        +
      • 請多位審查人員（特別是校對人員）進行審查
        • +
      • 審查人員若發現不會阻礙發行的缺失，則會建立議題
        • +
      • 如果是發行所需處理的缺失，審查人員可以提交拉取請求來解決問題
        • +
      • 若有額外的拉取請求合併至發行分支，則再次請求審查
        • +
      +
      • +
    • 執行 to-archive-org.sh 命令稿
      • +
    +
    4. +
  4. 在 GItHub 上發行，附上發行備註與版本編號 +
      +
    • git tag trigger-$MAJOR.$MINOR.$PATCH
      • +
    • git push --tags（請參見：../.github/workflows/release-on-tag.yml）
      • +
    • 移除本地端的 tag 標記：git tag -d trigger-$MAJOR.$MINOR.$PATCH
      • +
    +
    5. +
  5. 將檔案傳送給印刷廠商印刷 +
      +
    • 封面檔案
      • +
    • 內頁 PDF
      • +
    +
    6. +
  6. 通知翻譯貢獻者
    7. +
+ +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/docs/releasing.md b/_site/docs/releasing.md new file mode 100644 index 00000000..0ab61c4e --- /dev/null +++ b/_site/docs/releasing.md @@ -0,0 +1,48 @@ +# 發行新版本的《公共程式標準》 + + + + +1. 審查「develop」分支的狀態 + - 確認預計收入該次發行版的所有變更都已完成合併 + - 邀請校對該分支目前的狀態 + - 如果有引入新的破折號，檢查是否能簡化文字並且移除破折號，例如改用較簡易的句子。如果需要用到複雜的句子，檢查是否能用其他標點符號來取代破折號。如果破折號最適合用來 +表達該句子的涵義，則請遵守《[芝加哥格式手 +冊](https://en.wikipedia.org/wiki/Dash#En_dash_versus_em_dash)》的規範。 + +1. 建立發行用分支 + - 從「develop」分支下命令，`git switch -c "release-$MAJOR.$MINOR.$PATCH"` + - 推送分支，`git push -u origin release-$MAJOR.$MINOR.$PATCH` + +1. 更新本次新發行 + - [ ] 在 [`AUTHORS.md`](../AUTHORS.md) 中加入新貢獻者的資料 + - [ ] 更新 [`CHANGELOG.md`](../CHANGELOG.md) + - [ ] 更新 [`roadmap.md`](roadmap.md) + - [ ] 透過 diff 進行額外傳輸到「main」分支 + - 執行 `script/generate-review-template.sh` 並送交更新後的 `docs/review-template.html` 版次記 +錄 + - 使用審查範本中的新文字來更新 `docs/standard-for-public-code.html`，會將任何狀態變更作為結果更新 + - 重新檢查用字有變更的任何小節或段落，確保變更的字詞適合該整體內容，並且沒有文法或拼字錯誤 + - 確認有安裝[字型](https://brand.publiccode.net/typography/)，請參見：`script/ensure-font.sh` + - 使用 `script/pdf.sh rc1` 檢查轉譯出的 `.pdf` 檔 + - 確認沒有連結相衝的問題 + - 檢查文字分頁之處，可能需要移除或新增 CSS 分頁語法，像是：`

` + - 如果有需要，送交修正版次，並重複進行額外傳輸 + - [ ] 推送分支，與「main」分支比較，範例： +`https://github.com/publiccodenet/standard/compare/main...release-$MAJOR.$MINOR.$PATCH` + - 請多位審查人員（特別是校對人員）進行審查 + - 審查人員若發現不會阻礙發行的缺失，則會建立議題 + - 如果是發行所需處理的缺失，審查人員可以提交拉取請求來解決問題 + - 若有額外的拉取請求合併至發行分支，則再次請求審查 + - [ ] 執行 to-archive-org.sh 命令稿 + +1. 在 GItHub 上發行，附上發行備註與版本編號 + - [ ] `git tag trigger-$MAJOR.$MINOR.$PATCH` + - [ ] `git push --tags`（請參見：`../.github/workflows/release-on-tag.yml`） + - [ ] 移除本地端的 tag 標記：`git tag -d trigger-$MAJOR.$MINOR.$PATCH` + +1. [將檔案傳送給印刷廠商印刷](printing.md) + - [ ] 封面檔案 + - [ ] 內頁 PDF + +1. 通知[翻譯](https://github.com/publiccodenet/community-translations-standard)貢獻者 diff --git a/_site/docs/review-template.html b/_site/docs/review-template.html new file mode 100644 index 00000000..7818ee68 --- /dev/null +++ b/_site/docs/review-template.html @@ -0,0 +1,1512 @@ + + + + + + +________ and the Standard for Public Code + + + +

________ and the Standard for Public Code version 0.7.1

+ +Link to commitment to meet the Standard for Public Code: + +

Code in the open

+ +☐ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+ + +All source code for any policy in use (unless used for fraud detection) MUST be published and publicly accessible. + + +
+ + +All source code for any software in use (unless used for fraud detection) MUST be published and publicly accessible. + + +
+ + +The codebase MUST NOT contain sensitive information regarding users, their organization or third parties. + + +
+ + +Any source code not currently in use (such as new versions, proposals or older versions) SHOULD be published. + + +
+ + +Documenting which source code or policy underpins any specific interaction the general public may have with an organization is OPTIONAL. + + +
+ +

Bundle policy and source code

+ +☐ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+ + +The codebase MUST include the policy that the source code is based on. + + +
+ + +If a policy is based on source code, that source code MUST be included in the codebase, unless used for fraud detection. + + +
+ + +Policy SHOULD be provided in machine readable and unambiguous formats. + + +
+ + +Continuous integration tests SHOULD validate that the source code and the policy are executed coherently. + + +
+ +

Make the codebase reusable and portable

+ +☐ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+ + +The codebase MUST be developed to be reusable in different contexts. + + +
+ + +The codebase MUST be independent from any secret, undisclosed, proprietary or non-open licensed software or services for execution and understanding. + + +
+ + +The codebase SHOULD be in use by multiple parties. + + +
+ + +The roadmap SHOULD be influenced by the needs of multiple parties. + + +
+ + +The development of the codebase SHOULD be a collaboration between multiple parties. + + +
+ + +Configuration SHOULD be used to make source code adapt to context specific needs. + + +
+ + +The codebase SHOULD be localizable. + + +
+ + +Source code and its documentation SHOULD NOT contain situation-specific information. + + +
+ + +Codebase modules SHOULD be documented in such a way as to enable reuse in codebases in other contexts. + + +
+ + +The software SHOULD NOT require services or platforms available from only a single vendor. + + +
+ +

Welcome contributors

+ +☐ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+ + +The codebase MUST allow anyone to submit suggestions for changes to the codebase. + + +
+ + +The codebase MUST include contribution guidelines explaining what kinds of contributions are welcome and how contributors can get involved, for example in a `CONTRIBUTING` file. + + +
+ + +The codebase MUST document the governance of the codebase, contributions and its community, for example in a `GOVERNANCE` file. + + +
+ + +The contribution guidelines SHOULD document who is expected to cover the costs of reviewing contributions. + + +
+ + +The codebase SHOULD advertise the committed engagement of involved organizations in the development and maintenance. + + +
+ + +The codebase SHOULD have a publicly available roadmap. + + +
+ + +The codebase SHOULD publish codebase activity statistics. + + +
+ + +Including a code of conduct for contributors in the codebase is OPTIONAL. + + +
+ +

Make contributing easy

+ +☐ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+ + +The codebase MUST have a public issue tracker that accepts suggestions from anyone. + + +
+ + +The documentation MUST link to both the public issue tracker and submitted codebase changes, for example in a `README` file. + + +
+ + +The codebase MUST have communication channels for users and developers, for example email lists. + + +
+ + +There MUST be a way to report security issues for responsible disclosure over a closed channel. + + +
+ + +The documentation MUST include instructions for how to report potentially security sensitive issues. + + +
+ +

Maintain version control

+ +☐ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+ + +All files in the codebase MUST be version controlled. + + +
+ + +All decisions MUST be documented in commit messages. + + +
+ + +Every commit message MUST link to discussions and issues wherever possible. + + +
+ + +The codebase SHOULD be maintained in a distributed version control system. + + +
+ + +Contribution guidelines SHOULD require contributors to group relevant changes in commits. + + +
+ + +Maintainers SHOULD mark released versions of the codebase, for example using revision tags or textual labels. + + +
+ + +Contribution guidelines SHOULD encourage file formats where the changes within the files can be easily viewed and understood in the version control system. + + +
+ + +It is OPTIONAL for contributors to sign their commits and provide an email address, so that future contributors are able to contact past contributors with questions about their work. + + +
+ +

Require review of contributions

+ +☐ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+ + +All contributions that are accepted or committed to release versions of the codebase MUST be reviewed by another contributor. + + +
+ + +Reviews MUST include source, policy, tests and documentation. + + +
+ + +Reviewers MUST provide feedback on all decisions to not accept a contribution. + + +
+ + +The review process SHOULD confirm that a contribution conforms to the standards, architecture and decisions set out in the codebase in order to pass review. + + +
+ + +Reviews SHOULD include running both the software and the tests of the codebase. + + +
+ + +Contributions SHOULD be reviewed by someone in a different context than the contributor. + + +
+ + +Version control systems SHOULD NOT accept non-reviewed contributions in release versions. + + +
+ + +Reviews SHOULD happen within two business days. + + +
+ + +Performing reviews by multiple reviewers is OPTIONAL. + + +
+ +

Document codebase objectives

+ +☐ criterion met. + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+ + +The codebase MUST contain documentation of its objectives, like a mission and goal statement, that is understandable by developers and designers so that they can use or contribute to the codebase. + + +
+ + +Codebase documentation SHOULD clearly describe the connections between policy objectives and codebase objectives. + + +
+ + +Documenting the objectives of the codebase for the general public is OPTIONAL. + + +
+ +

Document the code

+ +☐ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+ + +All of the functionality of the codebase, policy as well as source code, MUST be described in language clearly understandable for those that understand the purpose of the codebase. + + +
+ + +The documentation of the codebase MUST contain a description of how to install and run the software. + + +
+ + +The documentation of the codebase MUST contain examples demonstrating the key functionality. + + +
+ + +The documentation of the codebase SHOULD contain a high level description that is clearly understandable for a wide audience of stakeholders, like the general public and journalists. + + +
+ + +The documentation of the codebase SHOULD contain a section describing how to install and run a standalone version of the source code, including, if necessary, a test dataset. + + +
+ + +The documentation of the codebase SHOULD contain examples for all functionality. + + +
+ + +The documentation SHOULD describe the key components or modules of the codebase and their relationships, for example as a high level architectural diagram. + + +
+ + +There SHOULD be continuous integration tests for the quality of the documentation. + + +
+ + +Including examples that make users want to immediately start using the codebase in the documentation of the codebase is OPTIONAL. + + +
+ +

Use plain English

+ +☐ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+ + +All codebase documentation MUST be in English. + + +
+ + +All source code MUST be in English, except where policy is machine interpreted as code. + + +
+ + +All bundled policy not available in English MUST have an accompanying summary in English. + + +
+ + +Any translation MUST be up to date with the English version and vice versa. + + +
+ + +There SHOULD be no acronyms, abbreviations, puns or legal/non-English/domain specific terms in the codebase without an explanation preceding it or a link to an explanation. + + +
+ + +Documentation SHOULD aim for a lower secondary education reading level, as recommended by the Web Content Accessibility Guidelines 2. + + +
+ + +Providing a translation of any code, documentation or tests is OPTIONAL. + + +
+ +

Use open standards

+ +☐ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+ + +For features of the codebase that facilitate the exchange of data the codebase MUST use an open standard that meets the Open Source Initiative Open Standard Requirements. + + +
+ + +Any non-open standards used MUST be recorded clearly as such in the documentation. + + +
+ + +Any standard chosen for use within the codebase MUST be listed in the documentation with a link to where it is available. + + +
+ + +Any non-open standards chosen for use within the codebase MUST NOT hinder collaboration and reuse. + + +
+ + +If no existing open standard is available, effort SHOULD be put into developing one. + + +
+ + +Open standards that are machine testable SHOULD be preferred over open standards that are not. + + +
+ + +Non-open standards that are machine testable SHOULD be preferred over non-open standards that are not. + + +
+ +

Use continuous integration

+ +☐ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+ + +All functionality in the source code MUST have automated tests. + + +
+ + +Contributions MUST pass all automated tests before they are admitted into the codebase. + + +
+ + +The codebase MUST have guidelines explaining how to structure contributions. + + +
+ + +The codebase MUST have active contributors who can review contributions. + + +
+ + +Automated test results for contributions SHOULD be public. + + +
+ + +The codebase guidelines SHOULD state that each contribution should focus on a single issue. + + +
+ + +Source code test and documentation coverage SHOULD be monitored. + + +
+ + +Testing policy and documentation for consistency with the source and vice versa is OPTIONAL. + + +
+ + +Testing policy and documentation for style and broken links is OPTIONAL. + + +
+ + +Testing the software by using examples in the documentation is OPTIONAL. + + +
+ +

Publish with an open license

+ +☐ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+ + +All source code and documentation MUST be licensed such that it may be freely reusable, changeable and redistributable. + + +
+ + +Software source code MUST be licensed under an OSI-approved or FSF Free/Libre license. + + +
+ + +All source code MUST be published with a license file. + + +
+ + +Contributors MUST NOT be required to transfer copyright of their contributions to the codebase. + + +
+ + +All source code files in the codebase SHOULD include a copyright notice and a license header that are machine-readable. + + +
+ + +Having multiple licenses for different types of source code and documentation is OPTIONAL. + + +
+ +

Make the codebase findable

+ +☐ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+ + +The name of the codebase SHOULD be descriptive and free from acronyms, abbreviations, puns or organizational branding. + + +
+ + +The codebase SHOULD have a short description that helps someone understand what the codebase is for or what it does. + + +
+ + +Maintainers SHOULD submit the codebase to relevant software catalogs. + + +
+ + +The codebase SHOULD have a website which describes the problem the codebase solves using the preferred jargon of different potential users of the codebase (including technologists, policy experts and managers). + + +
+ + +The codebase SHOULD be findable using a search engine by codebase name. + + +
+ + +The codebase SHOULD be findable using a search engine by describing the problem it solves in natural language. + + +
+ + +The codebase SHOULD have a unique and persistent identifier where the entry mentions the major contributors, repository location and website. + + +
+ + +The codebase SHOULD include a machine-readable metadata description, for example in a publiccode.yml file. + + +
+ + +A dedicated domain name for the codebase is OPTIONAL. + + +
+ + +Regular presentations at conferences by the community are OPTIONAL. + + +
+ +

Use a coherent style

+ +☐ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+ + +The codebase MUST use a coding or writing style guide, either the codebase community's own or an existing one referred to in the codebase. + + +
+ + +Contributions SHOULD pass automated tests on style. + + +
+ + +The style guide SHOULD include expectations for inline comments and documentation for non-trivial sections. + + +
+ + +Including expectations for understandable English in the style guide is OPTIONAL. + + +
+ +

Document codebase maturity

+ +☐ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+ + +The codebase MUST be versioned. + + +
+ + +The codebase MUST prominently document whether or not there are versions of the codebase that are ready to use. + + +
+ + +Codebase versions that are ready to use MUST only depend on versions of other codebases that are also ready to use. + + +
+ + +The codebase SHOULD contain a log of changes from version to version, for example in the `CHANGELOG`. + + +
+ + +The method for assigning version identifiers SHOULD be documented. + + +
+ + +It is OPTIONAL to use semantic versioning. + + +
+ + diff --git a/_site/docs/review-template.md b/_site/docs/review-template.md new file mode 100644 index 00000000..179c7a70 --- /dev/null +++ b/_site/docs/review-template.md @@ -0,0 +1,222 @@ +# ________ and the Standard for Public Code version 0.4.0 + + + + +Link to commitment to meet the Standard for Public Code: + +## [Code in the open](https://standard.publiccode.net/criteria/code-in-the-open.html) + +☐ criterion met. + +Requirement | meets |  links and notes  +-----|-----|----- +All source code for any policy in use (unless used for fraud detection) MUST be published and publicly accessible. | | +All source code for any software in use (unless used for fraud detection) MUST be published and publicly accessible. | | +Contributors MUST NOT upload sensitive information regarding users, their organization or third parties to the repository. | | +Any source code not currently in use (such as new versions, proposals or older versions) SHOULD be published. | | +Documenting which source code or policy underpins any specific interaction the general public may have with an organization is OPTIONAL. | | + +## [Bundle policy and source code](https://standard.publiccode.net/criteria/bundle-policy-and-code.html) + +☐ criterion met. + +Requirement | meets |  links and notes  +-----|-----|----- +The codebase MUST include the policy that the source code is based on. | | +The codebase MUST include all source code that the policy is based on, unless used for fraud detection. | | +Policy SHOULD be provided in machine readable and unambiguous formats. | | +Continuous integration tests SHOULD validate that the source code and the policy are executed coherently. | | + +## [Create reusable and portable code](https://standard.publiccode.net/criteria/reusable-and-portable-codebases.html) + +☐ criterion met. + +Requirement | meets |  links and notes  +-----|-----|----- +The codebase MUST be developed to be reusable in different contexts. | | +The codebase MUST be independent from any secret, undisclosed, proprietary or non-open licensed code or services for execution and understanding. | | +The codebase SHOULD be in use by multiple parties. | | +The roadmap SHOULD be influenced by the needs of multiple parties. | | +Configuration SHOULD be used to make code adapt to context specific needs. | | +The codebase SHOULD be localizable. | | +Code and its documentation SHOULD NOT contain situation-specific information. | | +Codebase modules SHOULD be documented in such a way as to enable reuse in codebases in other contexts. | | + +## [Welcome contributors](https://standard.publiccode.net/criteria/open-to-contributions.html) + +☐ criterion met. + +Requirement | meets |  links and notes  +-----|-----|----- +The codebase MUST allow anyone to submit suggestions for changes to the codebase. | | +The codebase MUST include contribution guidelines explaining what kinds of contributions are welcome and how contributors can get involved, for example in a `CONTRIBUTING` file. | | +The codebase MUST document the governance of the codebase, contributions and its community, for example in a `GOVERNANCE` file. | | +The codebase SHOULD advertise the committed engagement of involved organizations in the development and maintenance. | | +The codebase SHOULD have a publicly available roadmap. | | +The codebase SHOULD publish codebase activity statistics. | | +Including a code of conduct for contributors in the codebase is OPTIONAL. | | + +## [Make contributing easy](https://standard.publiccode.net/criteria/make-contributing-easy.html) + +☐ criterion met. + +Requirement | meets |  links and notes  +-----|-----|----- +The codebase MUST have a public issue tracker that accepts suggestions from anyone. | | +The codebase MUST include instructions for how to privately report security issues for responsible disclosure. | | +The documentation MUST link to both the public issue tracker and submitted codebase changes, for example in a `README` file. | | +The codebase MUST have communication channels for users and developers, for example email lists. | | +The documentation SHOULD include instructions for how to report potentially security sensitive issues on a closed channel. | | + +## [Maintain version control](https://standard.publiccode.net/criteria/version-control-and-history.html) + +☐ criterion met. + +Requirement | meets |  links and notes  +-----|-----|----- +The community MUST have a way to maintain version control for the code. | | +All files in the codebase MUST be version controlled. | | +All decisions MUST be documented in commit messages. | | +Every commit message MUST link to discussions and issues wherever possible. | | +The codebase SHOULD be maintained in a distributed version control system. | | +Contributors SHOULD group relevant changes in commits. | | +Maintainers SHOULD mark released versions of the codebase, for example using revision tags or textual labels. | | +Contributors SHOULD prefer file formats where the changes within the files can be easily viewed and understood in the version control system. | | +It is OPTIONAL for contributors to sign their commits and provide an email address, so that future contributors are able to contact past contributors with questions about their work. | | + +## [Require review of contributions](https://standard.publiccode.net/criteria/require-review.html) + +☐ criterion met. + +Requirement | meets |  links and notes  +-----|-----|----- +All contributions that are accepted or committed to release versions of the codebase MUST be reviewed by another contributor. | | +Reviews MUST include source, policy, tests and documentation. | | +Reviewers MUST provide feedback on all decisions to not accept a contribution. | | +Contributions SHOULD conform to the standards, architecture and decisions set out in the codebase in order to pass review. | | +Reviews SHOULD include running both the code and the tests of the codebase. | | +Contributions SHOULD be reviewed by someone in a different context than the contributor. | | +Version control systems SHOULD NOT accept non-reviewed contributions in release versions. | | +Reviews SHOULD happen within two business days. | | +Performing reviews by multiple reviewers is OPTIONAL. | | + +## [Document codebase objectives](https://standard.publiccode.net/criteria/document-objectives.html) + +☐ criterion met. + +Requirement | meets |  links and notes  +-----|-----|----- +The codebase MUST contain documentation of its objectives, like a mission and goal statement, that is understandable by developers and designers so that they can use or contribute to the codebase. | | +Codebase documentation SHOULD clearly describe the connections between policy objectives and codebase objectives. | | +Documenting the objectives of the codebase for the general public is OPTIONAL. | | + +## [Document the code](https://standard.publiccode.net/criteria/documenting.html) + +☐ criterion met. + +Requirement | meets |  links and notes  +-----|-----|----- +All of the functionality of the codebase, policy as well as source, MUST be described in language clearly understandable for those that understand the purpose of the code. | | +The documentation of the codebase MUST contain a description of how to install and run the source code. | | +The documentation of the codebase MUST contain examples demonstrating the key functionality. | | +The documentation of the codebase SHOULD contain a high level description that is clearly understandable for a wide audience of stakeholders, like the general public and journalists. | | +The documentation of the codebase SHOULD contain a section describing how to install and run a standalone version of the source code, including, if necessary, a test dataset. | | +The documentation of the codebase SHOULD contain examples for all functionality. | | +The documentation SHOULD describe the key components or modules of the codebase and their relationships, for example as a high level architectural diagram. | | +There SHOULD be continuous integration tests for the quality of the documentation. | | +Including examples that make users want to immediately start using the codebase in the documentation of the codebase is OPTIONAL. | | +Testing the code by using examples in the documentation is OPTIONAL. | | + +## [Use plain English](https://standard.publiccode.net/criteria/understandable-english-first.html) + +☐ criterion met. + +Requirement | meets |  links and notes  +-----|-----|----- +All codebase documentation MUST be in English. | | +All code MUST be in English, except where policy is machine interpreted as code. | | +All bundled policy not available in English MUST have an accompanying summary in English. | | +Any translation MUST be up to date with the English version and vice versa. | | +There SHOULD be no acronyms, abbreviations, puns or legal/non-English/domain specific terms in the codebase without an explanation preceding it or a link to an explanation. | | +The name of the codebase SHOULD be descriptive and free from acronyms, abbreviations, puns or organizational branding. | | +Documentation SHOULD aim for a lower secondary education reading level, as recommended by the [Web Content Accessibility Guidelines 2](https://www.w3.org/WAI/WCAG21/quickref/?showtechniques=315#readable). | | +Providing a translation of any code, documentation or tests is OPTIONAL. | | + +## [Use open standards](https://standard.publiccode.net/criteria/open-standards.html) + +☐ criterion met. + +Requirement | meets |  links and notes  +-----|-----|----- +For features of the codebase that facilitate the exchange of data the codebase MUST use an open standard that meets the [Open Source Initiative Open Standard Requirements](https://opensource.org/osr). | | +Any non-open standards used MUST be recorded clearly as such in the documentation. | | +Any standard chosen for use within the codebase MUST be listed in the documentation with a link to where it is available. | | +Any non-open standards chosen for use within the codebase MUST NOT hinder collaboration and reuse. | | +If no existing open standard is available, effort SHOULD be put into developing one. | | +Standards that are machine testable SHOULD be preferred over those that are not. | | + +## [Use continuous integration](https://standard.publiccode.net/criteria/continuous-integration.html) + +☐ criterion met. + +Requirement | meets |  links and notes  +-----|-----|----- +All functionality in the source code MUST have automated tests. | | +Contributions MUST pass all automated tests before they are admitted into the codebase. | | +The codebase MUST have guidelines explaining how to structure contributions. | | +The codebase MUST have active contributors. | | +The codebase guidelines SHOULD state that each contribution should focus on a single issue. | | +Source code test and documentation coverage SHOULD be monitored. | | +Testing policy and documentation for consistency with the source and vice versa is OPTIONAL. | | +Testing policy and documentation for style and broken links is OPTIONAL. | | + +## [Publish with an open license](https://standard.publiccode.net/criteria/open-licenses.html) + +☐ criterion met. + +Requirement | meets |  links and notes  +-----|-----|----- +All code and documentation MUST be licensed such that it may be freely reusable, changeable and redistributable. | | +Software source code MUST be licensed under an [OSI-approved or FSF Free/Libre license](https://spdx.org/licenses/). | | +All code MUST be published with a license file. | | +Contributors MUST NOT be required to transfer copyright of their contributions to the codebase. | | +All source code files in the codebase SHOULD include a copyright notice and a license header that are machine-readable. | | +Having multiple licenses for different types of code and documentation is OPTIONAL. | | + +## [Make the codebase findable](https://standard.publiccode.net/criteria/findability.html) + +☐ criterion met. + +Requirement | meets |  links and notes  +-----|-----|----- +The codebase MUST be findable using a search engine by describing the problem it solves in natural language. | | +The codebase MUST be findable using a search engine by codebase name. | | +Maintainers SHOULD submit the codebase to relevant software catalogs. | | +The codebase SHOULD have a website which describes the problem the codebase solves using the preferred jargon of different potential users of the codebase (including technologists, policy experts and managers). | | +The codebase SHOULD have a unique and persistent identifier where the entry mentions the major contributors, repository location and website. | | +The codebase SHOULD include a machine-readable metadata description, for example in a [publiccode.yml](https://github.com/publiccodeyml/publiccode.yml) file. | | +A dedicated domain name for the codebase is OPTIONAL. | | +Regular presentations at conferences by the community are OPTIONAL. | | + +## [Use a coherent style](https://standard.publiccode.net/criteria/style.html) + +☐ criterion met. + +Requirement | meets |  links and notes  +-----|-----|----- +Contributions MUST adhere to either a coding or writing style guide, either the codebase community's own or an existing one that is advertised in or part of the codebase. | | +Contributions SHOULD pass automated tests on style. | | +The codebase SHOULD include inline comments and documentation for non-trivial sections. | | +Including sections on [understandable English](https://standard.publiccode.net/criteria/understandable-english-first.html) in the style guide is OPTIONAL. | | + +## [Document codebase maturity](https://standard.publiccode.net/criteria/document-maturity.html) + +☐ criterion met. + +Requirement | meets |  links and notes  +-----|-----|----- +The codebase MUST be versioned. | | +The codebase that is ready to use MUST only depend on other codebases that are also ready to use. | | +The codebase that is not yet ready to use MUST have one of the labels: prototype, alpha, beta or pre-release version. | | +The codebase SHOULD contain a log of changes from version to version, for example in the `CHANGELOG`. | | diff --git a/_site/docs/roadmap.html b/_site/docs/roadmap.html new file mode 100644 index 00000000..34d6f4cb --- /dev/null +++ b/_site/docs/roadmap.html @@ -0,0 +1,281 @@ + + + + + + + + + 發展路線圖, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 目前任務
    2. +
  2. 近期
    3. +
  3. 長期
    4. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

發展路線圖

+ + + + +

上次更新時間：2023-03-08

+ +

本文件旨在闡明團隊目前的開發計畫。隨著團隊吸收新資訊，這些計畫也會持續變動。

+ +

程式基底執事人員每月會定期審查發展路線圖，這是我們積累事項修整作業 +環節的一部份。

+ +

目前任務

+ +
    +
  • 盡可能讓標準遵循自我標準
    • +
  • 認證標章
    • +
+ +

近期

+ +
    +
  • 分離執行摘要 (issue #302)
    • +
  • 實體紙張檢查清單
    • +
  • 可能性：為每個準則新增解說插圖
    • +
+ +

長期

+ +
    +
  • 為「README」與「index.md」加入採用與使用（之後會繼續統計）條目（議題#438號）
    • +
  • 通過多個程式基底驗證
    • +
  • 在幾個程式基底遵循標準後，發行 1.0.0 版
    • +
  • 可連結的需求規範
    • +
  • 新封面設計
    • +
  • 註冊申請 ISBN 書號
    • +
  • 隨選書籍列印服務名單
    • +
  • 印刷版外部連結的 QR 二維圖碼
    • +
+ +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/docs/roadmap.md b/_site/docs/roadmap.md new file mode 100644 index 00000000..55f132de --- /dev/null +++ b/_site/docs/roadmap.md @@ -0,0 +1,33 @@ +# 發展路線圖 + + + + +上次更新時間：2023-03-08 + +本文件旨在闡明團隊目前的開發計畫。隨著團隊吸收新資訊，這些計畫也會持續變動。 + +程式基底執事人員每月會定期審查發展路線圖，這是我們[積累事項修整作業](https://about.publiccode.net/activities/standard-maintenance/backlog-pruning.html) +環節的一部份。 + +## 目前任務 + +* 盡可能讓標準遵循自我標準 +* 認證標章 + +## 近期 + +* 分離執行摘要 (issue #302) +* 實體紙張檢查清單 +* 可能性：為每個準則新增解說插圖 + +## 長期 + +* 為「README」與「index.md」加入採用與使用（之後會繼續統計）條目（議題#438號） +* 通過多個程式基底驗證 +* 在幾個程式基底遵循標準後，發行 1.0.0 版 +* 可連結的需求規範 +* 新封面設計 +* 註冊申請 ISBN 書號 +* 隨選書籍列印服務名單 +* 印刷版外部連結的 QR 二維圖碼 diff --git a/_site/docs/standard-for-public-code.html b/_site/docs/standard-for-public-code.html new file mode 100644 index 00000000..5e68f7b0 --- /dev/null +++ b/_site/docs/standard-for-public-code.html @@ -0,0 +1,1514 @@ + + + + + + +The Standard for Public Code's compliance to the criteria and requirements of the Standard for Public Code version 0.7.1 + + + +

The Standard for Public Code's compliance to the criteria and requirements of the Standard for Public Code version 0.7.1

+ +The Standard for Public Code is not a codebase created in the context of a policy mandate, thus some criteria do not apply directly. + +Link to commitment to meet the Standard for Public Code: [CONTRIBUTING.md](../CONTRIBUTING.md#1-make-your-changes) + +

Code in the open

+ +☑ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+N/A + +All source code for any policy in use (unless used for fraud detection) MUST be published and publicly accessible. + +GitHub repository, no official policy at this time +
+N/A + +All source code for any software in use (unless used for fraud detection) MUST be published and publicly accessible. + +GitHub repository, not software +
+Ok + +The codebase MUST NOT contain sensitive information regarding users, their organization or third parties. + + +
+Ok + +Any source code not currently in use (such as new versions, proposals or older versions) SHOULD be published. + +GitHub releases +
+N/A + +Documenting which source code or policy underpins any specific interaction the general public may have with an organization is OPTIONAL. + + +
+ +

Bundle policy and source code

+ +☑ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+N/A + +The codebase MUST include the policy that the source code is based on. + + +
+N/A + +If a policy is based on source code, that source code MUST be included in the codebase, unless used for fraud detection. + + +
+N/A + +Policy SHOULD be provided in machine readable and unambiguous formats. + + +
+N/A + +Continuous integration tests SHOULD validate that the source code and the policy are executed coherently. + + +
+ +

Create reusable and portable code

+ +☐ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+Ok + +The codebase MUST be developed to be reusable in different contexts. + + +
+Ok + +The codebase MUST be independent from any secret, undisclosed, proprietary or non-open licensed software or services for execution and understanding. + + +
+Ok + +The codebase SHOULD be in use by multiple parties. + +Signalen, OpenZaak, Algoritmeregister, Standard for Public Code +
+Ok + +The roadmap SHOULD be influenced by the needs of multiple parties. + +Community calls influenced initial roadmap +
+ + +The development of the codebase SHOULD be a collaboration between multiple parties. + + +
+N/A + +Configuration SHOULD be used to make source code adapt to context specific needs. + + +
+Ok + +The codebase SHOULD be localizable. + + +
+Ok + +Source code and its documentation SHOULD NOT contain situation-specific information. + + +
+N/A + +Codebase modules SHOULD be documented in such a way as to enable reuse in codebases in other contexts. + + +
+Ok + +The software SHOULD NOT require services or platforms available from only a single vendor. + + +
+ +

Welcome contributors

+ +☑ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+Ok + +The codebase MUST allow anyone to submit suggestions for changes to the codebase. + + +
+Ok + +The codebase MUST include contribution guidelines explaining what kinds of contributions are welcome and how contributors can get involved, for example in a `CONTRIBUTING` file. + +CONTRIBUTING +
+Ok + +The codebase MUST document the governance of the codebase, contributions and its community, for example in a `GOVERNANCE` file. + +GOVERNANCE +
+Ok + +The contribution guidelines SHOULD document who is expected to cover the costs of reviewing contributions. + +In CONTRIBUTING +
+Ok + +The codebase SHOULD advertise the committed engagement of involved organizations in the development and maintenance. + + +
+Ok + +The codebase SHOULD have a publicly available roadmap. + +Roadmap +
+Ok + +The codebase SHOULD publish codebase activity statistics. + +GitHub Pulse +
+Ok + +Including a code of conduct for contributors in the codebase is OPTIONAL. + +CODE OF CONDUCT +
+ +

Make contributing easy

+ +☑ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+Ok + +The codebase MUST have a public issue tracker that accepts suggestions from anyone. + +GitHub Issues +
+Ok + +The documentation MUST link to both the public issue tracker and submitted codebase changes, for example in a `README` file. + +Via GitHub +
+Ok + +The codebase MUST have communication channels for users and developers, for example email lists. + +Mailing list +
+N/A + +There MUST be a way to report security issues for responsible disclosure over a closed channel. + + +
+N/A + +The documentation MUST include instructions for how to report potentially security sensitive issues. + + +
+ +

Maintain version control

+ +☑ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+Ok + +All files in the codebase MUST be version controlled. + + +
+Ok + +All decisions MUST be documented in commit messages. + + +
+Ok + +Every commit message MUST link to discussions and issues wherever possible. + + +
+Ok + +The codebase SHOULD be maintained in a distributed version control system. + +git +
+Ok + +Contribution guidelines SHOULD require contributors to group relevant changes in commits. + + +
+Ok + +Maintainers SHOULD mark released versions of the codebase, for example using revision tags or textual labels. + +GitHub releases +
+Ok + +Contribution guidelines SHOULD encourage file formats where the changes within the files can be easily viewed and understood in the version control system. + + +
+Ok + +It is OPTIONAL for contributors to sign their commits and provide an email address, so that future contributors are able to contact past contributors with questions about their work. + + +
+ +

Require review of contributions

+ +☑ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+Ok + +All contributions that are accepted or committed to release versions of the codebase MUST be reviewed by another contributor. + + +
+Ok + +Reviews MUST include source, policy, tests and documentation. + +policy does not apply +
+Ok + +Reviewers MUST provide feedback on all decisions to not accept a contribution. + + +
+Ok + +The review process SHOULD confirm that a contribution conforms to the standards, architecture and decisions set out in the codebase in order to pass review. + + +
+Ok + +Reviews SHOULD include running both the software and the tests of the codebase. + +GitHub Actions +
+Ok + +Contributions SHOULD be reviewed by someone in a different context than the contributor. + +Usually in the same context, rarely get reviews from other contexts, currently no other contexts regularly available +
+Ok + +Version control systems SHOULD NOT accept non-reviewed contributions in release versions. + +the `main` branch is "protected" +
+Ok + +Reviews SHOULD happen within two business days. + +very few exceptions +
+Ok + +Performing reviews by multiple reviewers is OPTIONAL. + +for larger contributions +
+ +

Document codebase objectives

+ +☑ criterion met. + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+Ok + +The codebase MUST contain documentation of its objectives, like a mission and goal statement, that is understandable by developers and designers so that they can use or contribute to the codebase. + + +
+N/A + +Codebase documentation SHOULD clearly describe the connections between policy objectives and codebase objectives. + + +
+Ok + +Documenting the objectives of the codebase for the general public is OPTIONAL. + + +
+ +

Document the code

+ +☑ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+Ok + +All of the functionality of the codebase, policy as well as source code, MUST be described in language clearly understandable for those that understand the purpose of the codebase. + + +
+N/A + +The documentation of the codebase MUST contain a description of how to install and run the software. + + +
+N/A + +The documentation of the codebase MUST contain examples demonstrating the key functionality. + + +
+Ok + +The documentation of the codebase SHOULD contain a high level description that is clearly understandable for a wide audience of stakeholders, like the general public and journalists. + + +
+N/A + +The documentation of the codebase SHOULD contain a section describing how to install and run a standalone version of the source code, including, if necessary, a test dataset. + + +
+N/A + +The documentation of the codebase SHOULD contain examples for all functionality. + + +
+N/A + +The documentation SHOULD describe the key components or modules of the codebase and their relationships, for example as a high level architectural diagram. + + +
+Ok + +There SHOULD be continuous integration tests for the quality of the documentation. + +GitHub Actions +
+ + +Including examples that make users want to immediately start using the codebase in the documentation of the codebase is OPTIONAL. + +We're not linking to examples +
+ +

Use plain English

+ +☑ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+Ok + +All codebase documentation MUST be in English. + + +
+Ok + +All source code MUST be in English, except where policy is machine interpreted as code. + + +
+N/A + +All bundled policy not available in English MUST have an accompanying summary in English. + + +
+N/A + +Any translation MUST be up to date with the English version and vice versa. + + +
+Ok + +There SHOULD be no acronyms, abbreviations, puns or legal/non-English/domain specific terms in the codebase without an explanation preceding it or a link to an explanation. + + +
+Ok + +Documentation SHOULD aim for a lower secondary education reading level, as recommended by the Web Content Accessibility Guidelines 2. + + +
+ + +Providing a translation of any code, documentation or tests is OPTIONAL. + +We have Community translations +
+ +

Use open standards

+ +☑ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+N/A + +For features of the codebase that facilitate the exchange of data the codebase MUST use an open standard that meets the Open Source Initiative Open Standard Requirements. + + +
+N/A + +Any non-open standards used MUST be recorded clearly as such in the documentation. + + +
+Ok + +Any standard chosen for use within the codebase MUST be listed in the documentation with a link to where it is available. + +CONTRIBUTING +
+N/A + +Any non-open standards chosen for use within the codebase MUST NOT hinder collaboration and reuse. + + +
+N/A + +If no existing open standard is available, effort SHOULD be put into developing one. + + +
+N/A + +Open standards that are machine testable SHOULD be preferred over open standards that are not. + + +
+N/A + +Non-open standards that are machine testable SHOULD be preferred over non-open standards that are not. + + +
+ +

Use continuous integration

+ +☑ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+Ok + +All functionality in the source code MUST have automated tests. + + +
+Ok + +Contributions MUST pass all automated tests before they are admitted into the codebase. + + +
+Ok + +The codebase MUST have guidelines explaining how to structure contributions. + + +
+Ok + +The codebase MUST have active contributors who can review contributions. + + +
+Ok + +Automated test results for contributions SHOULD be public. + + +
+Ok + +The codebase guidelines SHOULD state that each contribution should focus on a single issue. + + +
+N/A + +Source code test and documentation coverage SHOULD be monitored. + + +
+N/A + +Testing policy and documentation for consistency with the source and vice versa is OPTIONAL. + + +
+Ok + +Testing policy and documentation for style and broken links is OPTIONAL. + + +
+N/A + +Testing the software by using examples in the documentation is OPTIONAL. + + +
+ +

Publish with an open license

+ +☑ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+Ok + +All source code and documentation MUST be licensed such that it may be freely reusable, changeable and redistributable. + +CC 0 +
+Ok + +Software source code MUST be licensed under an OSI-approved or FSF Free/Libre license. + +CC 0 +
+Ok + +All source code MUST be published with a license file. + + +
+Ok + +Contributors MUST NOT be required to transfer copyright of their contributions to the codebase. + + +
+Ok + +All source code files in the codebase SHOULD include a copyright notice and a license header that are machine-readable. + + +
+Ok + +Having multiple licenses for different types of source code and documentation is OPTIONAL. + +CC 0 +
+ +

Make the codebase findable

+ +☑ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+Ok + +The name of the codebase SHOULD be descriptive and free from acronyms, abbreviations, puns or organizational branding. + + +
+Ok + +The codebase SHOULD have a short description that helps someone understand what the codebase is for or what it does. + + +
+Ok + +Maintainers SHOULD submit the codebase to relevant software catalogs. + +In the DPG registry +
+Ok + +The codebase SHOULD have a website which describes the problem the codebase solves using the preferred jargon of different potential users of the codebase (including technologists, policy experts and managers). + + +
+Ok + +The codebase SHOULD be findable using a search engine by codebase name. + + +
+Ok + +The codebase SHOULD be findable using a search engine by describing the problem it solves in natural language. + + +
+Ok + +The codebase SHOULD have a unique and persistent identifier where the entry mentions the major contributors, repository location and website. + +Q68006929 on Wikidata +
+Ok + +The codebase SHOULD include a machine-readable metadata description, for example in a publiccode.yml file. + +publiccode.yml +
+Ok + +A dedicated domain name for the codebase is OPTIONAL. + + +
+Ok + +Regular presentations at conferences by the community are OPTIONAL. + + +
+ +

Use a coherent style

+ +☑ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+Ok + +The codebase MUST use a coding or writing style guide, either the codebase community's own or an existing one referred to in the codebase. + + +
+Ok + +Contributions SHOULD pass automated tests on style. + + +
+N/A + +The style guide SHOULD include expectations for inline comments and documentation for non-trivial sections. + +maybe some of the Jekyll could apply +
+Ok + +Including expectations for understandable English in the style guide is OPTIONAL. + + +
+ +

Document codebase maturity

+ +☑ criterion met. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MeetsRequirementNotes and links
+Ok + +The codebase MUST be versioned. + + +
+Ok + +The codebase MUST prominently document whether or not there are versions of the codebase that are ready to use. + + +
+Ok + +Codebase versions that are ready to use MUST only depend on versions of other codebases that are also ready to use. + + +
+Ok + +The codebase SHOULD contain a log of changes from version to version, for example in the `CHANGELOG`. + +CHANGELOG +
+Ok + +The method for assigning version identifiers SHOULD be documented. + + +
+Ok + +It is OPTIONAL to use semantic versioning. + + +
+ + diff --git a/_site/docs/standard-for-public-code.md b/_site/docs/standard-for-public-code.md new file mode 100644 index 00000000..efff89dc --- /dev/null +++ b/_site/docs/standard-for-public-code.md @@ -0,0 +1,224 @@ +# The Standard for Public Code's compliance to the criteria and requirements of the Standard for Public Code version 0.4.0 + + + + +The Standard for Public Code is not a codebase created in the context of a policy mandate, thus some criteria do not apply directly. + +Link to commitment to meet the Standard for Public Code: [CONTRIBUTING.md](../CONTRIBUTING.md#1-make-your-changes) + +## [Code in the open](https://standard.publiccode.net/criteria/code-in-the-open.html) + +- [x] criterion met. + +Requirement | meets | links and notes +-----|-----|----- +All source code for any policy in use (unless used for fraud detection) MUST be published and publicly accessible. | N/A | [GitHub repository](https://github.com/publiccodenet/standard/), no official policy at this time +All source code for any software in use (unless used for fraud detection) MUST be published and publicly accessible. | N/A | [GitHub repository](https://github.com/publiccodenet/standard/), not software +Contributors MUST NOT upload sensitive information regarding users, their organization or third parties to the repository. | Ok | +Any source code not currently in use (such as new versions, proposals or older versions) SHOULD be published. | Ok | [GitHub releases](https://github.com/publiccodenet/standard/releases) +Documenting which source code or policy underpins any specific interaction the general public may have with an organization is OPTIONAL. | N/A | + +## [Bundle policy and source code](https://standard.publiccode.net/criteria/bundle-policy-and-code.html) + +- [ ] criterion met. + +Requirement | meets | links and notes +-----|-----|----- +A codebase MUST include the policy that the source code is based on. | N/A | +A codebase MUST include all source code that the policy is based on, unless used for fraud detection. | N/A | +Policy SHOULD be provided in machine readable and unambiguous formats. | N/A | +Continuous integration tests SHOULD validate that the source code and the policy are executed coherently. | N/A | + +## [Create reusable and portable code](https://standard.publiccode.net/criteria/reusable-and-portable-codebases.html) + +- [x] criterion met. + +Requirement | meets | links and notes +-----|-----|----- +The codebase MUST be developed to be reusable in different contexts. | Ok | +The codebase MUST be independent from any secret, undisclosed, proprietary or non-open licensed code or services for execution and understanding. | Ok | +The codebase SHOULD be in use by multiple parties. | Ok | [Signalen](https://github.com/Amsterdam/signals/blob/master/docs/CONTRIBUTING.md#under-foundation-for-public-code-incubating-codebase-stewardship), [OpenZaak](https://github.com/open-zaak/open-zaak/blob/main/CONTRIBUTING.md#under-foundation-for-public-code-incubating-codebase-stewardship), [Algoritmeregister](https://github.com/Algoritmeregister/standard#standard-for-public-code-compliance), [Standard for Public Code](https://github.com/publiccodenet/standard/blob/develop/CONTRIBUTING.md#1-make-your-changes) +The roadmap SHOULD be influenced by the needs of multiple parties. | Ok | Community calls influenced initial roadmap +Configuration SHOULD be used to make code adapt to context specific needs. | N/A | +The codebase SHOULD be localizable. | Ok | +Code and its documentation SHOULD NOT contain situation-specific information. | Ok | +Codebase modules SHOULD be documented in such a way as to enable reuse in codebases in other contexts. | N/A | + +## [Welcome contributors](https://standard.publiccode.net/criteria/open-to-contributions.html) + +- [x] criterion met. + +Requirement | meets | links and notes +-----|-----|----- +The codebase MUST allow anyone to submit suggestions for changes to the codebase. | Ok | +The codebase MUST include contribution guidelines explaining what kinds of contributions are welcome and how contributors can get involved, for example in a `CONTRIBUTING` file. | Ok | [CONTRIBUTING](https://github.com/publiccodenet/standard/blob/develop/CONTRIBUTING.md) +The codebase MUST document the governance of the codebase, contributions and its community, for example in a `GOVERNANCE` file. | Ok | [GOVERNANCE](https://github.com/publiccodenet/standard/blob/develop/GOVERNANCE.md) +The codebase SHOULD advertise the committed engagement of involved organizations in the development and maintenance. | Ok | +The codebase SHOULD have a publicly available roadmap. | Ok | [Roadmap](https://github.com/publiccodenet/standard/blob/develop/docs/roadmap.md) +The codebase SHOULD publish codebase activity statistics. | Ok | [GitHub Pulse](https://github.com/publiccodenet/standard/pulse) +Including a code of conduct for contributors in the codebase is OPTIONAL. | Ok | [CODE OF CONDUCT](https://github.com/publiccodenet/standard/blob/develop/CODE_OF_CONDUCT.md) + +## [Make contributing easy](https://standard.publiccode.net/criteria/make-contributing-easy.html) + +- [x] criterion met. + +Requirement | meets | links and notes +-----|-----|----- +The codebase MUST have a public issue tracker that accepts suggestions from anyone. | Ok | [GitHub Issues](https://github.com/publiccodenet/standard/issues) +The codebase MUST include instructions for how to privately report security issues for responsible disclosure. | N/A | +The documentation MUST link to both the public issue tracker and submitted codebase changes, for example in a `README` file. | Ok | Via GitHub +The codebase MUST have communication channels for users and developers, for example email lists. | Ok | [Mailing list](https://lists.publiccode.net/mailman/postorius/lists/standard.lists.publiccode.net/) +The documentation SHOULD include instructions for how to report potentially security sensitive issues on a closed channel. | N/A | + +## [Maintain version control](https://standard.publiccode.net/criteria/version-control-and-history.html) + +- [x] criterion met. + +Requirement | meets | links and notes +-----|-----|----- +The community MUST have a way to maintain version control for the code. | Ok | git +All files in a codebase MUST be version controlled. | Ok | +All decisions MUST be documented in commit messages. | Ok | +Every commit message MUST link to discussions and issues wherever possible. | Ok | +The codebase SHOULD be maintained in a distributed version control system. | Ok | git +Contributors SHOULD group relevant changes in commits. | Ok | +Maintainers SHOULD mark released versions of the codebase, for example using revision tags or textual labels. | Ok | GitHub releases +Contributors SHOULD prefer file formats where the changes within the files can be easily viewed and understood in the version control system. | Ok | (bpmn is an exception) +It is OPTIONAL for contributors to sign their commits and provide an email address, so that future contributors are able to contact past contributors with questions about their work. | Ok | + +## [Require review of contributions](https://standard.publiccode.net/criteria/require-review.html) + +- [x] criterion met. + +Requirement | meets | links and notes +-----|-----|----- +All contributions that are accepted or committed to release versions of the codebase MUST be reviewed by another contributor. | Ok | +Reviews MUST include source, policy, tests and documentation. | Ok | policy does not apply +Reviewers MUST provide feedback on all decisions to not accept a contribution. | Ok | +Contributions SHOULD conform to the standards, architecture and decisions set out in the codebase in order to pass review. | Ok | +Reviews SHOULD include running both the code and the tests of the codebase. | Ok | [GitHub Actions](https://github.com/publiccodenet/standard/actions) +Contributions SHOULD be reviewed by someone in a different context than the contributor. | Ok | Usually in the same context, rarely get reviews from other contexts, currently no other contexts regularly available +Version control systems SHOULD NOT accept non-reviewed contributions in release versions. | Ok | the `main` branch is "protected" +Reviews SHOULD happen within two business days. | Ok | very few exceptions +Performing reviews by multiple reviewers is OPTIONAL. | Ok | for larger contributions + +## [Document codebase objectives](https://standard.publiccode.net/criteria/document-objectives.html) + +- [x] criterion met. + +Requirement | meets | links and notes +-----|-----|----- +The codebase MUST contain documentation of its objectives, like a mission and goal statement, that is understandable by developers and designers so that they can use or contribute to the codebase. | Ok | +Codebase documentation SHOULD clearly describe the connections between policy objectives and codebase objectives. | N/A | +Documenting the objectives of the codebase for the general public is OPTIONAL. | Ok | + +## [Document the code](https://standard.publiccode.net/criteria/documenting.html) + +- [x] criterion met. + +Requirement | meets | links and notes +-----|-----|----- +All of the functionality of the codebase, policy as well as source, MUST be described in language clearly understandable for those that understand the purpose of the code. | Ok | +The documentation of the codebase MUST contain a description of how to install and run the source code. | N/A | +The documentation of the codebase MUST contain examples demonstrating the key functionality. | N/A | +The documentation of the codebase SHOULD contain a high level description that is clearly understandable for a wide audience of stakeholders, like the general public and journalists. | Ok | +The documentation of the codebase SHOULD contain a section describing how to install and run a standalone version of the source code, including, if necessary, a test dataset. | N/A | +The documentation of the codebase SHOULD contain examples for all functionality. | N/A | +The documentation SHOULD describe the key components or modules of the codebase and their relationships, for example as a high level architectural diagram. | N/A | +There SHOULD be continuous integration tests for the quality of the documentation. | Ok | [GitHub Actions](https://github.com/publiccodenet/standard/actions) +Including examples that make users want to immediately start using the codebase in the documentation of the codebase is OPTIONAL. | | We're not linking to examples +Testing the code by using examples in the documentation is OPTIONAL. | N/A | + +## [Use plain English](https://standard.publiccode.net/criteria/understandable-english-first.html) + +- [x] criterion met. + +Requirement | meets | links and notes +-----|-----|----- +All codebase documentation MUST be in English. | Ok | +All code MUST be in English, except where policy is machine interpreted as code. | Ok | +All bundled policy not available in English MUST have an accompanying summary in English. | N/A | +Any translation MUST be up to date with the English version and vice versa. | N/A | Community translations lag +There SHOULD be no acronyms, abbreviations, puns or legal/non-English/domain specific terms in the codebase without an explanation preceding it or a link to an explanation. | Ok | +The name of the codebase SHOULD be descriptive and free from acronyms, abbreviations, puns or organizational branding. | Ok | +Documentation SHOULD aim for a lower secondary education reading level, as recommended by the [Web Content Accessibility Guidelines 2](https://www.w3.org/WAI/WCAG21/quickref/?showtechniques=315#readable). | Ok | [CONTRIBUTING](https://github.com/publiccodenet/standard/blob/develop/CONTRIBUTING.md#style) +Providing a translation of any code, documentation or tests is OPTIONAL. | We have [Community translations](https://publiccodenet.github.io/community-translations-standard/) + +## [Use open standards](https://standard.publiccode.net/criteria/open-standards.html) + +- [x] criterion met. + +Requirement | meets | links and notes +-----|-----|----- +For features of a codebase that facilitate the exchange of data the codebase MUST use an open standard that meets the [Open Source Initiative Open Standard Requirements](https://opensource.org/osr). | N/A | +Any non-open standards used MUST be recorded clearly as such in the documentation. | N/A | +Any standard chosen for use within the codebase MUST be listed in the documentation with a link to where it is available. | Ok | [CONTRIBUTING](../CONTRIBUTING.md#standards-to-follow) +Any non-open standards chosen for use within the codebase MUST NOT hinder collaboration and reuse. | N/A | +If no existing open standard is available, effort SHOULD be put into developing one. | N/A | +Standards that are machine testable SHOULD be preferred over those that are not. | N/A | + +## [Use continuous integration](https://standard.publiccode.net/criteria/continuous-integration.html) + +- [x] criterion met. + +Requirement | meets | links and notes +-----|-----|----- +All functionality in the source code MUST have automated tests. | Ok | +Contributions MUST pass all automated tests before they are admitted into the codebase. | Ok | +The codebase MUST have guidelines explaining how to structure contributions. | Ok | +The codebase MUST have active contributors. | Ok | +The codebase guidelines SHOULD state that each contribution should focus on a single issue. | Ok | +Source code test and documentation coverage SHOULD be monitored. | N/A | +Testing policy and documentation for consistency with the source and vice versa is OPTIONAL. | N/A | +Testing policy and documentation for style and broken links is OPTIONAL. | Ok | + +## [Publish with an open license](https://standard.publiccode.net/criteria/open-licenses.html) + +- [x] criterion met. + +Requirement | meets | links and notes +-----|-----|----- +All code and documentation MUST be licensed such that it may be freely reusable, changeable and redistributable. | Ok | [CC 0](https://github.com/publiccodenet/standard/blob/develop/LICENSE) +Software source code MUST be licensed under an [OSI-approved or FSF Free/Libre license](https://spdx.org/licenses/). | Ok | CC 0 +All code MUST be published with a license file. | Ok | CC 0 +Contributors MUST NOT be required to transfer copyright of their contributions to the codebase. | Ok | +All source code files in the codebase SHOULD include a copyright notice and a license header that are machine-readable. | Ok | +Having multiple licenses for different types of code and documentation is OPTIONAL. | Ok | CC0 + +## [Make the codebase findable](https://standard.publiccode.net/criteria/findability.html) + +- [ ] criterion met. + +Requirement | meets | links and notes +-----|-----|----- +The codebase MUST be findable using a search engine by describing the problem it solves in natural language. | | +The codebase MUST be findable using a search engine by codebase name. | Ok | +Maintainers SHOULD submit the codebase to relevant software catalogs. | Ok | In the [DPG registry](https://digitalpublicgoods.net/registry/standard-for-public-code.html) +The codebase SHOULD have a website which describes the problem the codebase solves using the preferred jargon of different potential users of the codebase (including technologists, policy experts and managers). | Ok | +The codebase SHOULD have a unique and persistent identifier where the entry mentions the major contributors, repository location and website. | Ok | [Q68006929](https://www.wikidata.org/wiki/Q68006929) on Wikidata +The codebase SHOULD include a machine-readable metadata description, for example in a [publiccode.yml](https://github.com/publiccodeyml/publiccode.yml) file. | | +A dedicated domain name for the codebase is OPTIONAL. | Ok | +Regular presentations at conferences by the community are OPTIONAL. | Ok | + +## [Use a coherent style](https://standard.publiccode.net/criteria/style.html) + +- [ ] criterion met. + +Requirement | meets | links and notes +-----|-----|----- +Contributions MUST adhere to either a coding or writing style guide, either the codebase community's own or an existing one that is advertised in or part of the codebase. | | Some guidance, could be made clearer in the CONTRIBUTING +Contributions SHOULD pass automated tests on style. | Ok | +The codebase SHOULD include inline comments and documentation for non-trivial sections. | N/A | maybe some of the Jekyll could apply +Including sections on [understandable English](https://standard.publiccode.net/criteria/understandable-english-first.html) in the style guide is OPTIONAL. | Ok | + +## [Document codebase maturity](https://standard.publiccode.net/criteria/document-maturity.html) + +- [ ] criterion met. + +Requirement | meets | links and notes +-----|-----|----- +A codebase MUST be versioned. | Ok | +A codebase that is ready to use MUST only depend on other codebases that are also ready to use. | Ok | +A codebase that is not yet ready to use MUST have one of the labels: prototype, alpha, beta or pre-release version. | | labled as "draft", consider adding "beta" label? +A codebase SHOULD contain a log of changes from version to version, for example in the `CHANGELOG`. | Ok | [CHANGELOG](https://github.com/publiccodenet/standard/blob/develop/CHANGELOG.md) diff --git a/_site/foreword-print.html b/_site/foreword-print.html new file mode 100644 index 00000000..2f2c00c9 --- /dev/null +++ b/_site/foreword-print.html @@ -0,0 +1,215 @@ + + + + + + + + + + + Standard for Public Code + + + + +
+ +

序文

+ +

《公共程式標準》提供一套準則規範，支持公家機關一同開發與維護軟體及政策。

+ +

任何想開發具有公眾用途的軟體或政策的人，可以利用本標準來提升公共服務品質，使其更具成本效益、風險更低，還能對系統更有掌控權。

+ +

本序文在介紹何謂「公共程式」以及解說其重要性。

+ +

公共程式定義

+ +

公共程式，英文為 Public Code，是指人類或機器在公共情境下，所執行的電腦原始碼（像是軟體與演算法）與公共政策。公共程式的範疇，涵蓋搭配公共基礎建設一同作業 +的軟體、作為公共基礎建設運作而建置的軟體，以及產生公共程式的過程安排等。公共程式與一般軟體有明顯區別，因為其作業的環境與期待全然不同。

+ +

採用公共程式的原因

+ +

公共程式現在如此重要，背後有幾個原因。

+ +

軟體程式碼 == 法律條文

+ +

軟體是公共基礎建設。

+ +

在 21 世紀，軟體可被視為重要的公共基礎建設。軟體越來越常被用於實現既有政策，甚至成為新政策的制定來源。舉例來說，演算法可以決定哪些地區需要額外的社會服務或警力 +等。

+ +

在公共政策的執行上，軟體運作機制、演算法與資料蒐集等，已成為關鍵要素。今日的電腦程式碼，正執行著透過民主程序制定的法規政策。程式碼與政策這兩種形式的程式，都根據民主 +程序而確立的公共價值，設立出社會的運作環境；前者由機器執行，後者則是由人類執行。換句話說，軟體程式碼，已經越來越實質趨近於法律條文的地位。

+ +

因此軟體也應該接受民主治理原則的約束。

+ +

傳統的公共軟體採購

+ +

目前公共軟體的生產模式，在交付公共服務上的效率並不高。

+ +

過去近十年來，購置完整軟體解決方案的公家機關，有時甚至會很訝異地發現：

+ +
    +
  • 他們無法修改軟體來反映政策的變動，或是改變軟體來利用新科技
    • +
  • 他們的資料都套牢在專有系統中，無法取用
    • +
  • 他們所需繳交的授權費變得越來越貴
    • +
+ +

技術自主權與民主課責

+ +

公家機關、公務員與居民都值得更好的。

+ +

我們相信支持社會運作的軟體，再也不能是黑箱，任由外部公司依隱藏在專有程式基底之下的秘密邏輯作控制。反過來說，政府，以及政府所要服務的人民，需要掌控技術自主權。技術自 +主讓他們能主導設定與控制公共軟體的運作，正如同他們能依法制定與調整政策一樣。人民與公民社會的參與者，都需要這類軟體能夠透明，且可以課責。

+ +

作為必要公民基礎建設的軟體，其設計應該尊重公民的數位權利。

+ +

設計真正的公共軟體

+ +

公共程式是現代公家機構的核心，型塑了公務員的工作樣態，並且影響了幾乎所有居民的生活。

+ +

因此公共軟體必須：

+ +
    +
  • 透明
    • +
  • 可課責
    • +
  • 讓選民能夠理解
    • +
+ +

必須能反映其所服務的社會價值觀，像是涵容與不歧視。

+ +

目前公家機關使用的大多數專有軟體系統，都不符合這些要求；而公共程式能夠做到。

+ +

公共程式的價值

+ +

我們認為公共程式應具有下列核心價值：

+ +
    +
  • 涵容
    • +
  • 好用
    • +
  • 開放
    • +
  • 易懂
    • +
  • 課責
    • +
  • 近用
    • +
  • 永續
    • +
+ +

公共程式運作方式

+ +

公共程式是旨在協助公家機關，履行其必要職責時所採用的開放原始碼軟體。透過使用，其他行政單位也能為軟體做出貢獻，因此公共程式的開發與維護，可說是真正互相協作的成果。

+ +

開放的精神能開創許多可能性。

+ +

公家機關在執行與維護其自身的公共程式時，就是在確保能為地方負責，並履行民主課責。開放且貢獻者眾多的軟體，得利於有許多人在看，更容易發現潛在缺陷，因此安全性會更高。許 +多貢獻者會分攤維護工作，讓公共程式能持續運作與更新，減少未來技術債的可能。因為能有多人分攤維護工作，使得現在與未來都會更加永續。而公共程式的開放性，代表其程式碼與 +資料，在未來也更容易改寫與調整。程式碼也更容易重新利用、重新調整目標，或甚至淘汰。這一切特性都讓公共基礎建設可能遭遇的風險降到更低。

+ +

這種將資源集中的作法，能讓公共行政單位可以有額外心力關注如何客製化軟體，來使軟體最適合當地情境的需求，為終端使用者（居民或市民）創造更佳的使用體驗。

+ +

公共程式的經濟效應

+ +

公共程式為公家機關以及商業公司，提供更好的經濟模型。公共程式作為替代傳統軟體採購的方案，更能提升當地的掌控權並促進經濟機會。

+ +

公共程式從設計之初，就是要開放、適應力強、資料可攜，能夠由內部員工或信任的供應商來開發。由於原始碼開放，公共行政單位在有需要時可以更換供應商。開放原始碼讓社會大眾更 +有機會瞭解與監督公共程式，使公共行政單位得以採購小規模的合約，而地方性的中小企業就更容易參與這些小型採購案的競標。如此一來，公共行政單位就可以透過他們所需的軟體採 +購案，刺激當地經濟的創新與競爭。

+ +

這可視為對未來經濟成長的投資。隨著科技需求成長，也將需要更多供應商。

+ +

購置公共程式

+ +

公共程式可由常駐的內部研發團隊、承包商或外包供應商開發。公家機關的供應商，在投標時可以在標案中納入公共程式。

+ +

若要使用既有的公共程式，您將需要在預算以及專案設計中，明確指出新的解決方案將會使用該程式基底。為了鼓勵創新，將公共程式依據您的情境背景作調整，您可在合約中描述說明服 +務內容或預期成果。

+ +

《公共程式標準》目標

+ +

本標準在於支持開發人員、設計師、管理人員、公共政策制定者：

+ +
    +
  • 開發出高品質的軟體與政策，來改善公共服務的交付
    • +
  • 開發出能在各種情境下重複使用，且以協作方式維護的程式基底
    • +
  • 減少技術債與專案失敗率
    • +
  • 更能精細控制其 IT 系統粒度，並做出系統相關決策
    • +
  • 以更好的經濟模型改善供應商關係
    • +
+ +

如果有潛在使用者想採用經由《公共程式標準》測試過的程式基底，便可以預期這些程式基底具有方便重複利用、容易維護、高品質的特性。

+ +

《公共程式標準》能有此效果是基於：

+ +
    +
  • 為公共程式開發訂立通用術語
    • +
  • 制定措施協助高品質公共程式的開發
    • +
  • 提出該如何符合準則並實作遵循的指引
    • +
+ +

《公共程式標準》設計精神就是要跨越時間與科技，不受其限制。

+ +

適用對象

+ +

《公共程式標準》適用於開發與重複使用公共程式的人：

+ +
    +
  • 公共政策制定者
    • +
  • 業務與專案經理
    • +
  • 開發人員與設計師
    • +
+ +

在以下單位服務的人：

+ +
    +
  • 社會機構、公家機關的組織與行政單位
    • +
  • 公家機關在資訊科技與政策服務上的顧問與供應商
    • +
+ +

適用對象不含公家機關的終端使用者（居民或市民）、記者或學者等。

+ +

延伸閱讀

+ + + +

探討公共程式的影片

+ + + +

參與我們

+ +

本標準是持續成長的文件。請讀我們的〈貢獻者指引〉，瞭解您可以怎麼做來讓本標準變得更好。

+ +

聯絡方式

+ +

若有疑問，或想進一步瞭解 Foundation for Public Code，請造訪我們的網站，或是寄電子郵 +件到 info@publiccode.net，或撥打我們的電話 +31 20 2 444 500。

+ + +
+ + + diff --git a/_site/foreword.html b/_site/foreword.html new file mode 100644 index 00000000..21facae7 --- /dev/null +++ b/_site/foreword.html @@ -0,0 +1,443 @@ + + + + + + + + + 序文, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 公共程式定義
    2. +
  2. 採用公共程式的原因 +
      +
    1. 軟體程式碼 == 法律條文
      2. +
    2. 傳統的公共軟體採購
      3. +
    3. 技術自主權與民主課責
      4. +
    4. 設計真正的公共軟體
      5. +
    5. 公共程式的價值
      6. +
    +
    3. +
  3. 公共程式運作方式 +
      +
    1. 公共程式的經濟效應
      2. +
    2. 購置公共程式
      3. +
    +
    4. +
  4. 《公共程式標準》目標 +
      +
    1. 適用對象
      2. +
    +
    5. +
  5. 延伸閱讀 +
      +
    1. 探討公共程式的影片
      2. +
    +
    6. +
  6. 參與我們
    7. +
  7. 聯絡方式
    8. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

序文

+ +

《公共程式標準》提供一套準則規範，支持公家機關一同開發與維護軟體及政策。

+ +

任何想開發具有公眾用途的軟體或政策的人，可以利用本標準來提升公共服務品質，使其更具成本效益、風險更低，還能對系統更有掌控權。

+ +

本序文在介紹何謂「公共程式」以及解說其重要性。

+ +

公共程式定義

+ +

公共程式，英文為 Public Code，是指人類或機器在公共情境下，所執行的電腦原始碼（像是軟體與演算法）與公共政策。公共程式的範疇，涵蓋搭配公共基礎建設一同作業 +的軟體、作為公共基礎建設運作而建置的軟體，以及產生公共程式的過程安排等。公共程式與一般軟體有明顯區別，因為其作業的環境與期待全然不同。

+ +

採用公共程式的原因

+ +

公共程式現在如此重要，背後有幾個原因。

+ +

軟體程式碼 == 法律條文

+ +

軟體是公共基礎建設。

+ +

在 21 世紀，軟體可被視為重要的公共基礎建設。軟體越來越常被用於實現既有政策，甚至成為新政策的制定來源。舉例來說，演算法可以決定哪些地區需要額外的社會服務或警力 +等。

+ +

在公共政策的執行上，軟體運作機制、演算法與資料蒐集等，已成為關鍵要素。今日的電腦程式碼，正執行著透過民主程序制定的法規政策。程式碼與政策這兩種形式的程式，都根據民主 +程序而確立的公共價值，設立出社會的運作環境；前者由機器執行，後者則是由人類執行。換句話說，軟體程式碼，已經越來越實質趨近於法律條文的地位。

+ +

因此軟體也應該接受民主治理原則的約束。

+ +

傳統的公共軟體採購

+ +

目前公共軟體的生產模式，在交付公共服務上的效率並不高。

+ +

過去近十年來，購置完整軟體解決方案的公家機關，有時甚至會很訝異地發現：

+ +
    +
  • 他們無法修改軟體來反映政策的變動，或是改變軟體來利用新科技
    • +
  • 他們的資料都套牢在專有系統中，無法取用
    • +
  • 他們所需繳交的授權費變得越來越貴
    • +
+ +

技術自主權與民主課責

+ +

公家機關、公務員與居民都值得更好的。

+ +

我們相信支持社會運作的軟體，再也不能是黑箱，任由外部公司依隱藏在專有程式基底之下的秘密邏輯作控制。反過來說，政府，以及政府所要服務的人民，需要掌控技術自主權。技術自 +主讓他們能主導設定與控制公共軟體的運作，正如同他們能依法制定與調整政策一樣。人民與公民社會的參與者，都需要這類軟體能夠透明，且可以課責。

+ +

作為必要公民基礎建設的軟體，其設計應該尊重公民的數位權利。

+ +

設計真正的公共軟體

+ +

公共程式是現代公家機構的核心，型塑了公務員的工作樣態，並且影響了幾乎所有居民的生活。

+ +

因此公共軟體必須：

+ +
    +
  • 透明
    • +
  • 可課責
    • +
  • 讓選民能夠理解
    • +
+ +

必須能反映其所服務的社會價值觀，像是涵容與不歧視。

+ +

目前公家機關使用的大多數專有軟體系統，都不符合這些要求；而公共程式能夠做到。

+ +

公共程式的價值

+ +

我們認為公共程式應具有下列核心價值：

+ +
    +
  • 涵容
    • +
  • 好用
    • +
  • 開放
    • +
  • 易懂
    • +
  • 課責
    • +
  • 近用
    • +
  • 永續
    • +
+ +

公共程式運作方式

+ +

公共程式是旨在協助公家機關，履行其必要職責時所採用的開放原始碼軟體。透過使用，其他行政單位也能為軟體做出貢獻，因此公共程式的開發與維護，可說是真正互相協作的成果。

+ +

開放的精神能開創許多可能性。

+ +

公家機關在執行與維護其自身的公共程式時，就是在確保能為地方負責，並履行民主課責。開放且貢獻者眾多的軟體，得利於有許多人在看，更容易發現潛在缺陷，因此安全性會更高。許 +多貢獻者會分攤維護工作，讓公共程式能持續運作與更新，減少未來技術債的可能。因為能有多人分攤維護工作，使得現在與未來都會更加永續。而公共程式的開放性，代表其程式碼與 +資料，在未來也更容易改寫與調整。程式碼也更容易重新利用、重新調整目標，或甚至淘汰。這一切特性都讓公共基礎建設可能遭遇的風險降到更低。

+ +

這種將資源集中的作法，能讓公共行政單位可以有額外心力關注如何客製化軟體，來使軟體最適合當地情境的需求，為終端使用者（居民或市民）創造更佳的使用體驗。

+ +

公共程式的經濟效應

+ +

公共程式為公家機關以及商業公司，提供更好的經濟模型。公共程式作為替代傳統軟體採購的方案，更能提升當地的掌控權並促進經濟機會。

+ +

公共程式從設計之初，就是要開放、適應力強、資料可攜，能夠由內部員工或信任的供應商來開發。由於原始碼開放，公共行政單位在有需要時可以更換供應商。開放原始碼讓社會大眾更 +有機會瞭解與監督公共程式，使公共行政單位得以採購小規模的合約，而地方性的中小企業就更容易參與這些小型採購案的競標。如此一來，公共行政單位就可以透過他們所需的軟體採 +購案，刺激當地經濟的創新與競爭。

+ +

這可視為對未來經濟成長的投資。隨著科技需求成長，也將需要更多供應商。

+ +

購置公共程式

+ +

公共程式可由常駐的內部研發團隊、承包商或外包供應商開發。公家機關的供應商，在投標時可以在標案中納入公共程式。

+ +

若要使用既有的公共程式，您將需要在預算以及專案設計中，明確指出新的解決方案將會使用該程式基底。為了鼓勵創新，將公共程式依據您的情境背景作調整，您可在合約中描述說明服 +務內容或預期成果。

+ +

《公共程式標準》目標

+ +

本標準在於支持開發人員、設計師、管理人員、公共政策制定者：

+ +
    +
  • 開發出高品質的軟體與政策，來改善公共服務的交付
    • +
  • 開發出能在各種情境下重複使用，且以協作方式維護的程式基底
    • +
  • 減少技術債與專案失敗率
    • +
  • 更能精細控制其 IT 系統粒度，並做出系統相關決策
    • +
  • 以更好的經濟模型改善供應商關係
    • +
+ +

如果有潛在使用者想採用經由《公共程式標準》測試過的程式基底，便可以預期這些程式基底具有方便重複利用、容易維護、高品質的特性。

+ +

《公共程式標準》能有此效果是基於：

+ +
    +
  • 為公共程式開發訂立通用術語
    • +
  • 制定措施協助高品質公共程式的開發
    • +
  • 提出該如何符合準則並實作遵循的指引
    • +
+ +

《公共程式標準》設計精神就是要跨越時間與科技，不受其限制。

+ +

適用對象

+ +

《公共程式標準》適用於開發與重複使用公共程式的人：

+ +
    +
  • 公共政策制定者
    • +
  • 業務與專案經理
    • +
  • 開發人員與設計師
    • +
+ +

在以下單位服務的人：

+ +
    +
  • 社會機構、公家機關的組織與行政單位
    • +
  • 公家機關在資訊科技與政策服務上的顧問與供應商
    • +
+ +

適用對象不含公家機關的終端使用者（居民或市民）、記者或學者等。

+ +

延伸閱讀

+ + + +

探討公共程式的影片

+ + + +

參與我們

+ +

本標準是持續成長的文件。請讀我們的〈貢獻者指引〉，瞭解您可以怎麼做來讓本標準變得更好。

+ +

聯絡方式

+ +

若有疑問，或想進一步瞭解 Foundation for Public Code，請造訪我們的網站，或是寄電子郵 +件到 info@publiccode.net，或撥打我們的電話 +31 20 2 444 500。

+ +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/glossary.html b/_site/glossary.html new file mode 100644 index 00000000..1dd179a1 --- /dev/null +++ b/_site/glossary.html @@ -0,0 +1,327 @@ + + + + + + + + + 詞彙表, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 程式或程式碼 (Code)
    2. +
  2. 程式基底 (Codebase)
    3. +
  3. 持續整合
    4. +
  4. 不同情境
    5. +
  5. 一般大眾
    6. +
  6. 開源或開放原始碼 (Open Source)
    7. +
  7. 開放標準
    8. +
  8. 政策
    9. +
  9. 公共程式 (Public Code)
    10. +
  10. 儲存庫
    11. +
  11. 原始碼 (Source Code)
    12. +
  12. 版本控制
    13. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

詞彙表

+ +

程式或程式碼 (Code)

+ +

任何明確的規則系統，包括法律、政策與規則條例（法規、法式，也可稱為程式），以及用來開發軟體的原始碼（程式碼）。兩者都是規則，有些是由人類來執行，其餘則是由機器執 +行。

+ +

程式基底 (Codebase)

+ +

任何獨立分離的統合包，內含執行部分政策或軟體所需的程式（包含原始碼與政策）、測試與文件等的整套內容。

+ +

舉例而言，這個具體形式可以是文件，或是版本控制的儲存庫。

+ +

持續整合

+ +

在軟體工程中，持續整合 (CI) 是盡可能頻繁地將所有開發人員工作中的副本，合併回程式基底開發中分支的實務作法。

+ +

不同情境

+ +

只要是不同的公家機關或不同的部門，無法透過同一個決策單位讓協作自然發生，那就算是兩個不同的情境。

+ +

一般大眾

+ +

整體民眾：程式碼與其所建立的服務的終端使用者。

+ +

舉例而言，城市的居民即視為該城市的服務、以及驅動這些服務運作的程式碼的終端使用者。

+ +

開源或開放原始碼 (Open Source)

+ +

所謂「開源」或「開放原始碼」，是根據 OSI 開放原始碼促進會發表的《開放原始碼定義》而來。

+ +

開放標準

+ +

任何符合 OSI 開放原始碼促進會《開放標準需求規範》的標準，就是開放標準。

+ +

政策

+ +

政策是一套謹慎設計的原則體系，用來引導決策並達成合理的成果。政策是一種意圖的聲明，並以程序或協定來執行。政策通常是由組織單位內的理事機構採用執行。政策能協助做出主觀 +與客觀的決策。

+ +

公共政策是政府將其政治願景，轉化成計畫與行動來取得成果的程序。

+ +

在國家層級，政策與立法（法律）通常是分開的；而在地方政府中，這兩者之間的區別通常比較模糊。

+ +

在本標準當中，「政策」一詞指的是公家機關，例如政府與自治市等，所制定與採用的政策。

+ +

公共程式 (Public Code)

+ +

公共程式，是由公家機關所開發的開放原始碼軟體，同時包含協作與重複利用所需的政策與指引。

+ +

公共程式是在公共情境下，由人類或機器所執行的電腦原始碼（例如軟體與演算法）以及公共政策兩者。

+ +

服務公眾利益的公共程式，具有開放、易懂、課責、近用、永續等特性。

+ +

透過獨立於當地情境，但仍可在當地情境下實作的方式，還有公開以文件記錄開發程序等作法，來開發公共程式。如此，公共程式能作為基礎組件提供給他人，使其得以：

+ +
    +
  • 根據其當地情境重新實作
    • +
  • 作為起點並繼續開發
    • +
  • 當作學習時的基礎
    • +
+ +

為了促進重複利用，公共程式通常放到公眾領域發行，或者採取允許他人能自由檢視、重複利用其成果，甚至產出衍生作品的開放授權。

+ +

儲存庫

+ +

儲存庫是版本控制工具，用於存放程式基底的檔案與中介資料的儲存位置。儲存庫讓多位貢獻者，得以同時對同一組檔案作業。儲存庫可以儲存一組檔案的多個版本。

+ +

原始碼 (Source Code)

+ +

人類可讀，並且能夠翻譯成機器指令的電腦程式文字。

+ +

版本控制

+ +

版本控制，是對原始碼及其相關檔案的變動行為作管理的流程。變動行為，通常是以稱為「修訂編號」（或版次等類似名稱）的代號作識別。每次修訂都會標示其改動時間以及作者， +方便追溯程式碼的演進。修訂控制系統可用來比較不同版本之間的差異，以及查看內容隨著時間經歷的變動。

+ +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/glossary.md b/_site/glossary.md new file mode 100644 index 00000000..6205b910 --- /dev/null +++ b/_site/glossary.md @@ -0,0 +1,78 @@ +# Glossary + + + + +## Code + +Any explicitly described system of rules. This includes laws, policy and ordinances, as well as source code that is used to build software. Both of these are rules, some executed by humans and others by machines. + +## Codebase + +Any discrete package of code (both source and policy), the tests and the documentation required to implement a piece of policy or software. + +This can be, for example, a document or a version-control repository. + +## Continuous integration + +In software engineering, continuous integration (CI) is the practice of merging all developers' working copies to a development branch of a codebase as frequently as reasonable. + +## Different contexts + +Two contexts are different if they are different public organizations or different departments for which there is not one decision maker that could make collaboration happen naturally. + +## General public + +The public at large: end users of the code and the services based upon it. + +For example, a city's residents are considered end users of a city's services and of all code that powers these services. + +## Open source + +Open source is defined by the Open Source Initiative in their [Open Source Definition](https://opensource.org/osd-annotated). + +## Open standard + +An open standard is any standard that meets the Open Source Initiative's [Open Standard Requirements](https://opensource.org/osr). + +## Policy + +A policy is a deliberate system of principles to guide decisions and achieve rational outcomes. +A policy is a statement of intent, and is implemented as a procedure or protocol. +Policies are generally adopted by a governance body within an organization. +Policies can assist in both subjective and objective decision making. + +Public policy is the process by which governments translate their political vision into programs and actions to deliver outcomes. + +At the national level, policy and legislation (the law) are usually separate. The distinction is often more blurred in local government. + +In the Standard the word 'policy' refers to policy created and adopted by public organizations such as governments and municipalities. + +## Public code + +Public code is open source software developed by public organizations, together with the policy and guidance needed for collaboration and reuse. + +Public code is both computer source code (such as software and algorithms) and public policy executed in a public context, by humans or machines. + +Public code serves the public interest, is open, legible, accountable, accessible and sustainable. + +By developing public code independently from but still implementable in the local context for which it was developed, as well as documenting the development process openly, public code can provide a building block for others to: + +* re-implement in their local context +* take as a starting point to continue development +* use as a basis for learning + +To facilitate reuse, public code is either released into the public domain or licensed with an open license that permits others to view and reuse the work freely and to produce derivative works. + +## Repository + +A repository is a storage location used by version control tools for files and metadata of a codebase. +Repositories allow multiple developers to work on the same set of files. +Repositories are able to store multiple versions of sets of files. + +## Version control + +Version control is the management of changes to source code and the files associated with it. +Changes are usually identified by a code, termed the *revision number* (or similar). +Each revision is associated with the time it was made and the person making the change, thus making it easier to retrace the evolution of the code. +Revision control systems can be used to compare different versions with each other and to see how content has changed over time. diff --git a/_site/images/audit-flow.dot b/_site/images/audit-flow.dot new file mode 100644 index 00000000..553b2747 --- /dev/null +++ b/_site/images/audit-flow.dot @@ -0,0 +1,198 @@ +/* audit-flow-dot */ +/* SPDX-License-Identifier: CC0-1.0 */ +/* 2022 The Foundation for Public Code */ + +/* To generate the audit-flow.svg, run the following command: */ +/* dot audit-flow.dot -Tsvg -o audit-flow.svg */ + +digraph { + fontname = "Arial"; + + contrib_context [ + fontname = "Arial" + label = "Merge request to a\n'protected branch' or\nFoundation for\nPublic Code\nmanaged codebase" + ]; + contrib_submit [ + fontname = "Arial" + label = "Contributor submits\na merge request" + ]; + contrib_fix [ + fontname = "Arial" + label = "Make new commits to the code to\nresolve review and audit issues" + ]; + contrib_update [ + fontname = "Arial" + label = "Request\nupdated" + ]; + + audit_assign [ + fontname = "Arial" + label = "Auditor team member\nassigns merge request\nto themselves within\n2 business days" + ]; + audit_check [ + fontname = "Arial" + label = "Check changes for\ncodebase governance and\nStandard for Public Code\ncompliance" + ]; + audit_check_fail [ + fontname = "Arial" + label = "Post what needs to be\ndone so the contributor\ncan make the changes" + ]; + maint_check_fail [ + fontname = "Arial" + label = "Post what needs to be\ndone so the contributor\ncan make the changes" + ]; + audit_changes_requested [ + fontname = "Arial" + label = "Set request status to\n'Changes requested'" + ]; + maint_changes_requested [ + fontname = "Arial" + label = "Set request status to\n'Changes requested'" + ]; + audit_check_pass [ + fontname = "Arial" + label = "Set request status\nto 'approved' and\npost positively" + ]; + maint_check_pass [ + fontname = "Arial" + label = "Set request status\nto 'approved' and\npost positively" + ]; + maint_check [ + fontname = "Arial" + label = "Maintainer checks changes\nfor usefulness,\nvalue added and\n'mergeability'" + ]; + maint_merge [ + fontname = "Arial" + label = "Merge" + ]; + maint_check_reject [ + fontname = "Arial" + label = "Post why the request\ncannot be merged\nand close it" + ]; + maint_request_rejected [ + fontname = "Arial" + label = "Merge\nrequest\nrejected" + ]; + maint_request_merged [ + fontname = "Arial" + label = "Merge\nrequest\nmerged" + ]; + + + subgraph cluster_contrib { + fontname = "Arial"; + label = "Contributor"; + + contrib_context [ shape = "rectangle" ]; + contrib_submit; + subgraph cluster_contrib_update { + label = ""; + style = "invis"; + contrib_fix; + contrib_update; + contrib_submit_join; + } + } + + subgraph cluster_audit { + fontname = "Arial"; + label = "Auditor\n(staff)"; + + audit_assign; + audit_check; + audit_check_branch; + audit_check_pass; + audit_check_fail; + audit_changes_requested; + audit_changes_req_join; + } + + subgraph cluster_maint { + fontname = "Arial"; + label = "Maintainers\n(community or staff)"; + + maint_check; + maint_check_branch; + maint_check_pass; + maint_pass_join; + maint_merge; + maint_request_merged [ shape = "circle" style = "bold" ]; + maint_check_fail; + maint_changes_requested; + maint_check_reject; + maint_request_rejected [ shape = "circle" style = "bold" ]; + } + + contrib_submit_join [ + shape = "diamond" + fontname = "Arial" + label = "+" + ]; + audit_check_branch [ + shape = "diamond" + fontname = "Arial" + label = "X" + ]; + audit_changes_req_join [ + shape = "diamond" + fontname = "Arial" + label = "O" + ]; + maint_pass_join [ + shape = "diamond" + fontname = "Arial" + label = "+" + ]; + maint_check_branch [ + shape = "diamond" + fontname = "Arial" + label = "X" + ]; + + /* graph connections (edges) */ + contrib_context -> contrib_submit [ + style = "dashed" + arrowhead = "none" + ]; + contrib_submit -> contrib_submit_join; + contrib_submit_join -> audit_assign; + contrib_submit_join -> maint_check; + contrib_fix -> contrib_update; + contrib_update -> contrib_submit_join; + + audit_assign -> audit_check; + audit_check -> audit_check_branch; + audit_check_branch -> audit_check_pass [ + fontname = "Arial" + label = "Compliant" + ]; + audit_check_branch -> audit_check_fail [ + fontname = "Arial" + label = "Not compliant" + ]; + audit_check_pass -> maint_pass_join; + audit_check_fail -> audit_changes_requested; + audit_changes_requested -> audit_changes_req_join; + audit_changes_req_join -> contrib_fix; + + maint_check -> maint_check_branch; + maint_check_branch -> maint_check_pass [ + fontname = "Arial" + label = "Can\nbe merged" + ]; + maint_check_branch -> maint_check_fail [ + fontname = "Arial" + label = "Needs\nchanges" + ]; + maint_check_branch -> maint_check_reject [ + fontname = "Arial" + label = "Cannot\nbe merged" + ]; + maint_check_pass -> maint_pass_join; + maint_pass_join -> maint_merge; + maint_merge -> maint_request_merged; + maint_check_fail -> maint_changes_requested; + maint_changes_requested -> audit_changes_req_join; + maint_check_reject -> maint_request_rejected; + +} diff --git a/_site/images/audit-flow.svg b/_site/images/audit-flow.svg new file mode 100644 index 00000000..5c3f89b2 --- /dev/null +++ b/_site/images/audit-flow.svg @@ -0,0 +1,348 @@ + + + + + + +%3 + + +cluster_contrib + +Contributor + + +cluster_contrib_update + + +cluster_audit + +Auditor +(staff) + + +cluster_maint + +Maintainers +(community or staff) + + + +contrib_context + +Merge request to a +'protected branch' or +Foundation for +Public Code +managed codebase + + + +contrib_submit + +Contributor submits +a merge request + + + +contrib_context->contrib_submit + + + + +contrib_submit_join + ++ + + + +contrib_submit->contrib_submit_join + + + + + +contrib_fix + +Make new commits to the code to +resolve review and audit issues + + + +contrib_update + +Request +updated + + + +contrib_fix->contrib_update + + + + + +contrib_update->contrib_submit_join + + + + + +audit_assign + +Auditor team member +assigns merge request +to themselves within +2 business days + + + +audit_check + +Check changes for +codebase governance and +Standard for Public Code +compliance + + + +audit_assign->audit_check + + + + + +audit_check_branch + +X + + + +audit_check->audit_check_branch + + + + + +audit_check_fail + +Post what needs to be +done so the contributor +can make the changes + + + +audit_changes_requested + +Set request status to +'Changes requested' + + + +audit_check_fail->audit_changes_requested + + + + + +maint_check_fail + +Post what needs to be +done so the contributor +can make the changes + + + +maint_changes_requested + +Set request status to +'Changes requested' + + + +maint_check_fail->maint_changes_requested + + + + + +audit_changes_req_join + +O + + + +audit_changes_requested->audit_changes_req_join + + + + + +maint_changes_requested->audit_changes_req_join + + + + + +audit_check_pass + +Set request status +to 'approved' and +post positively + + + +maint_pass_join + ++ + + + +audit_check_pass->maint_pass_join + + + + + +maint_check_pass + +Set request status +to 'approved' and +post positively + + + +maint_check_pass->maint_pass_join + + + + + +maint_check + +Maintainer checks changes +for usefulness, +value added and +'mergeability' + + + +maint_check_branch + +X + + + +maint_check->maint_check_branch + + + + + +maint_merge + +Merge + + + +maint_request_merged + +Merge +request +merged + + + +maint_merge->maint_request_merged + + + + + +maint_check_reject + +Post why the request +cannot be merged +and close it + + + +maint_request_rejected + +Merge +request +rejected + + + +maint_check_reject->maint_request_rejected + + + + + +contrib_submit_join->audit_assign + + + + + +contrib_submit_join->maint_check + + + + + +audit_check_branch->audit_check_fail + + +Not compliant + + + +audit_check_branch->audit_check_pass + + +Compliant + + + +audit_changes_req_join->contrib_fix + + + + + +maint_check_branch->maint_check_fail + + +Needs +changes + + + +maint_check_branch->maint_check_pass + + +Can +be merged + + + +maint_check_branch->maint_check_reject + + +Cannot +be merged + + + +maint_pass_join->maint_merge + + + + + diff --git a/_site/index.html b/_site/index.html new file mode 100644 index 00000000..d1423ff9 --- /dev/null +++ b/_site/index.html @@ -0,0 +1,288 @@ + + + + + + + + + 政府開放原始碼協作指引, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

政府開放原始碼協作指引

+ +

《公共程式標準》是一套支持公家機關一同協作開發軟體與政策，以及維護的準則。

+ +

《公共程式標準》為那些在建構自身開放原始碼解決方案的公家機關提供指引，以便他們未來能成功與其他地方的類似公部門單位互相協作，並且重複使用各自的成果。這份標準涵蓋寫給政策制定者、政府管理人員、開發人員與供應商的建議。《公共程式標準》支持公家機關透過協作方式，創造出好用、開放、易懂、課責、近用、永續的程式基底。這份標準從設計之初，就是要用於各種不同政府層級的程式基底，小從市政府，大到超國家組織都行。

+ +

《公共程式標準》將「公共程式」定義為：由公家機關所開發的開放原始碼軟體，同時包含協作與重複使用所需的政策與指引。

+ +

《公共程式標準》當中的準則，符合開放原始碼軟體開發的指引與最佳實務。

+ +

其他情境與背景資訊請參閱序文。

+ +

目次

+ + + +

社群會議

+ +

我們通常在每月第一個週四的 15:00 (CET/CEST) 舉辦社群會議。議程在會議前 +約一週的時間更新。您可以註冊 +報名，會再寄送會議通話邀請函給您。

+ +

其他資源

+ + + +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/index.md b/_site/index.md new file mode 100644 index 00000000..79c865af --- /dev/null +++ b/_site/index.md @@ -0,0 +1,39 @@ +# Contents + + + + +Welcome to the Standard for Public Code. + +We define ‘public code’ as open source software developed by public organizations, together with the policy and guidance needed for collaboration and reuse. + +The Standard for Public Code gives public organizations a model for building their own open source solutions to enable successful future reuse by similar public organizations in other places. It includes guidance for policy makers, city administrators, developers and vendors. + +There are also unofficial [community translations of the Standard](https://publiccodenet.github.io/community-translations-standard/) in other languages. + +* [Introduction and background](introduction.md) +* [Readers guide: how to interpret this standard](readers-guide.md) +* [Glossary](glossary.md) +* [Criteria](criteria/) + * [Code in the open](criteria/code-in-the-open.md) + * [Bundle policy and source code](criteria/bundle-policy-and-code.md) + * [Create reusable and portable code](criteria/reusable-and-portable-codebases.md) + * [Welcome contributors](criteria/open-to-contributions.md) + * [Make contributing easy](criteria/make-contributing-easy.md) + * [Maintain version control](criteria/version-control-and-history.md) + * [Require review of contributions](criteria/require-review.md) + * [Document codebase objectives](criteria/document-objectives.md) + * [Document the code](criteria/documenting.md) + * [Use plain English](criteria/understandable-english-first.md) + * [Use open standards](criteria/open-standards.md) + * [Use continuous integration](criteria/continuous-integration.md) + * [Publish with an open license](criteria/open-licenses.md) + * [Make the codebase findable](criteria/findability.md) + * [Use a coherent style](criteria/style.md) + * [Document codebase maturity](criteria/document-maturity.md) +* [Authors](AUTHORS.md) +* [Contributing guide](CONTRIBUTING.md) +* [Code of conduct](CODE_OF_CONDUCT.md) +* [Governance](GOVERNANCE.md) +* [Version history](CHANGELOG.md) +* [License](license.html) diff --git a/_site/introduction.html b/_site/introduction.html new file mode 100644 index 00000000..4ac2bfdb --- /dev/null +++ b/_site/introduction.html @@ -0,0 +1,11 @@ + + + + Redirecting… + + + + +

Redirecting…

+ Click here if you are not redirected. + diff --git a/_site/introduction.md b/_site/introduction.md new file mode 100644 index 00000000..12407f02 --- /dev/null +++ b/_site/introduction.md @@ -0,0 +1,172 @@ +# Introduction + + + + +The Standard for Public Code is a set of criteria that supports public organizations in developing and maintaining software and policy together. + +Anyone developing software or policy for a public purpose can use this standard to work towards higher quality public services that are more cost effective, with less risk and more control. + +This introduction introduces the term public code, explains why this is important, and introduces the process through which software and policy code can become certified public code. + +## Definition of public code + +Public code is both computer source code (such as software and algorithms) and public policy executed in a public context, by humans or machines. +It encompasses the software built to operate with and as public infrastructure, along with the arrangements for its production. +Public code is explicitly distinct from regular software because it operates under fundamentally different circumstances and expectations. + +## Reasons for public code + +There are many reasons for why public code is relevant now. + +### Software code == legal code + +Software is public infrastructure. + +In the 21st century, software can be considered vital public infrastructure. It is increasingly not just the expression of existing policy but the originator of new policy, for example where algorithms decide which districts need extra social services or policing. + +Software mechanics, algorithms and data collection have become key elements in the execution of public policies. Computer code now executes policies that have been codified in legal code through democratic procedures. Both forms of code set conditions for society to function according to democratically set public values, the latter executed by humans, the former by machines. In other words, software code has increasingly started to equal legal code. + +Software should therefore be subject to the principles of democratic governance. + +### Traditional public software procurement + +Current public software production methods have not served public service delivery very well. + +In the last decade, public organizations that purchased complete software solutions have sometimes been surprised to discover that they: + +* can’t change their software to reflect changing policy or take advantage of new technology +* don’t have access to their data as it's locked into proprietary systems +* are asked to pay ever increasing license fees + +### Technological sovereignty and democratic accountability + +Public institutions, civil servants and residents deserve better. + +We believe the software that runs our society can no longer be a black box, controlled by outside companies that keep the underlying logic on which their software operates hidden in proprietary codebases. Instead, governments and the people they serve need technological sovereignty. This allows them to set and control the functioning of public software, just like they are able to set and control policy that is legally formulated in laws. Citizens and civil society actors need this software to be transparent and accountable. + +The design of software as essential civic infrastructure should honor digital citizens’ rights. + +### Designing truly public software + +Public code is at the core of modern public institutions, shapes the work of civil servants and affects the lives of almost all residents. + +Public software must therefore be: + +* transparent +* accountable +* understandable for its constituents + +It must reflect the values of the society it serves, for example by being inclusive and non-discriminatory. + +Most proprietary software systems currently used by public organizations do not meet these requirements. Public code does. + +### Values of public code + +We consider public code to have these core values: + +* Inclusive +* Usable +* Open +* Legible +* Accountable +* Accessible +* Sustainable + +## How public code works + +Public code is open source software meant for fulfilling the essential role of public organizations. Through use, other administrations contribute back to the software, so that its development and maintenance become truly collaborative. + +Being open unlocks many other things. + +Local responsibility and democratic accountability are ensured when a public organization implements and maintains their own public code. By being open and with a broader contributor base, the software is more secure as it benefits from many eyes spotting potential flaws. Many contributors share the maintenance work to keep it functional and modern, which reduces future technical debt. The shared workload is more sustainable now and in the future. Its openness makes the code and its data more easily adaptable in the future. The code will be easier to retool, repurpose or retire. This all results in lower risk public infrastructure. + +This pooling of resources lets public administrations give extra attention to how to customize the software so it works best in each local context, creating better user experiences for their end users (residents or citizens). + +### Economics of public code + +Public code offers a better economic model for public organizations as well as for commercial companies. It's an alternative to traditional software procurement which increases local control and economic opportunity. + +Designed from the start to be open, adaptable and with data portability, it can be developed by in-house staff or trusted vendors. Because the code is open, the public administration can change vendors if they need to. Open code increases opportunities for public learning and scrutiny, allowing the public administration to procure smaller contracts. Smaller procurements are easier for local small and medium enterprises to bid upon. Public administrations can use their own software purchasing to stimulate innovation and competition in their local economy. + +This can be seen as investment leading to future economic growth. More vendors will be necessary due to growing technology demand. + +### Procuring public code + +Public code can be used and developed by permanent in-house development teams, contractors or outsourced suppliers. Vendors to public organizations can include public code in their bids for contracts. + +To use existing public code, you need to specify in your budget and project design that your new solution will use that codebase. To encourage an innovative approach to adapting the public code to your context, you could describe the service or outcome in your contract. + +## Standard compliance or certification process + +The Foundation for Public Code ensures that codebases under its stewardship (and not in incubation or the attic) are compliant with the Standard for Public Code. This makes clear to potential users and contributors that the codebase is of high quality, and updates will be too. + +The audit performed by the Foundation for Public Code is meant to complement machine testing, as machines are great at testing things like syntax and whether outcomes align with expectations. Things meant for humans, such as testing whether documentation is actually understandable and accessible in context, the commit messages make sense, and whether community guidelines are being followed are impossible for machines to test. + +The audit tests the entire codebase, including source code, policy, documentation and conversation for compliance with both the standards set out by the Foundation for Public Code and the standards set out in the codebase itself. + +### How the process works + +Every time a contribution is suggested to a codebase, through for instance a merge request, the [codebase stewards](https://about.publiccode.net/roles/) of the Foundation for Public Code will audit the contribution for compliance with the Standard for Public Code. New contributions can only be adopted into the codebase after they have been approved as compliant with the Standard for Public Code, and have been reviewed by another contributor. + +The audit is presented as a review of the contribution. The codebase steward gives line by line feedback and compliance, helping the contributor to improve their contribution. The merge request cannot be fulfilled until the codebase stewards have approved the contribution. + +![Pull Request Acceptance process](images/audit-flow.svg) + +### Certifying an entire codebase versus a contribution + +For the codebase to be completely certified every meaningful line of code, and the commits behind the code, need to meet the Standard. + +If codebases have been completely audited from the first merge request they can be immediately certified as compliant with the Standard for Public Code. + +If the audit process is added to an existing codebase, the new merge requests can be certified, but the existing code cannot be certified. By auditing every new merge request the codebase can move incrementally towards being completely certified. + +## The goals for the Standard for Public Code + +This Standard supports developers, designers, business management and policy makers to: + +* develop high quality software and policy for better public service delivery +* develop codebases that can be reused across contexts and collaboratively maintained +* reduce technical debt and project failure rate +* have more granular control over, and ability to make decisions about, their IT systems +* improve vendor relationships with a better economic model + +[The Foundation for Public Code](https://publiccode.net/) helps public organizations share and adopt open source software, build sustainable developer communities and create a thriving ecosystem for public code. It does this through codebase stewardship. For this process the codebase stewards use the Standard for Public Code to make sure the code it stewards is high quality as well as collaboratively maintainable. + +Potential users of codebases tested against the Standard for Public Code can expect them to be highly reusable, easily maintainable and of high quality. + +The Standard for Public Code does this by: + +* setting out a common terminology for public code development +* establishing measures to help develop high quality public code +* providing guidance on how to fulfill its criteria and operationalize compliance + +The Standard for Public Code is meant to be time and technology independent. + +### Who this is for + +The Standard for Public Code is for the people who create and reuse public code: + +* policy makers +* business and project management +* developers and designers + +These people work at: + +* institutions, organizations and administrations in the public sector +* consultancies and vendors of information technology and policy services to public organizations + +It is not aimed at public organizations' end users (residents or citizens), journalists or academics. + +## Further reading + +* ["Modernising Public Infrastructure with Free Software" whitepaper](https://download.fsfe.org/campaigns/pmpc/PMPC-Modernising-with-Free-Software.pdf) by the Free Software Foundation Europe. + +### Videos on public code + +* [Collaborative Code is the Future of Cities @ DecidimFest 2019](https://www.youtube.com/watch?v=cnJtnZ9Cx1o). Talk by Ben Cerveny on the background behind the Foundation for Public Code. +* [Public Money? Public Code! - Panel @ Nextcloud Conference 2019](https://youtube.com/watch?v=QHFkD4xfd6c). Touches on topics like procurement, law and more. + +## Get involved + +This standard is a living document. [Read our contributor guide](/CONTRIBUTING.md) to learn how you can make it better. diff --git a/_site/jargon.txt b/_site/jargon.txt new file mode 100644 index 00000000..ad01f5e7 --- /dev/null +++ b/_site/jargon.txt @@ -0,0 +1,190 @@ +personal_ws-1.1 en 30 utf-8 +st +nd +rd +th +Ainali +Algoritmeregister +Aotearoa +Arial +Arnout +AUAS +authorsFile +availableLanguages +Barberi +biotop +bmpn +BPMN +bundler +Camunda +Cerveny +CEST +CET +CHANGELOG +changelog +cibuild +CMMN +codebase +codebase's +codebases +configurability +cron +dataset +de +DecidimFest +Deerenberg +deps +der +developmentStatus +digitalminister +dir +discoverability +discoverable +disincentivizes +DMN +DPG +Edo +endfor +endif +Engelen +english +Enke +epub +Erkelens +Faassen +facto +FileCopyrightText +findability +findable +Findley +Floris +Fogel +foliated +fontconfig +fontname +GDS +Gemeente +Gemfile +genericName +gh +GitFlow +GitLab +Groenen +Hajduczenia +Heikendorf +Hendriks +Hintjens +hostnames +Hoytema +html +HTTPS +Huy +IETF +implementers +inlining +io +jekyll +Johan +Kivimäki +Klaas +landingURL +Lectorate +libre +linkable +linter +linters +localisationReady +localisedName +localizable +longDescription +mainCopyrightOwner +Marek +MarkDown +markdownify +Markdownlint +Martijn +Matti +Mauko +Maurits +McQuaid +md +Mirjam +modularity +Mullie +Nextcloud +Ngô +Ngọc +NIIS +nl +ok +OpenApi +OpenSSF +OpenZaak +operationalize +OSI +OSS +pandoc +pdf +PDFs +Petteri +Pieter +Plantinga +proactiveness +procurements +provincie +publiccode +publiccodenet +publiccodeYmlVersion +QPDF +Quiroga +README +Reclameland +redistributable +Regt +releaseDate +repoOwner +repurpose +reusability +roadmap +Roza +ruleset +runtime +Sanderson +Schee +Schuijff +shortDescription +Signalen +Slinger +softwareType +softwareVersion +Spaan +spdx +Staand +sudo +svg +synergize +Tamas +Theo +Tiel +Timo +toc +Trisotech +Tsvg +tw +txt +ubuntu +ức +Upgoer +url +URL +URLs +usedBy +venv +Vries +Waal +weasyprint +whitepaper +Wikidata +yaml +yml +Zuid diff --git a/_site/license.html b/_site/license.html new file mode 100644 index 00000000..1a40f449 --- /dev/null +++ b/_site/license.html @@ -0,0 +1,11 @@ + + + + Redirecting… + + + + +

Redirecting…

+ Click here if you are not redirected. + diff --git a/_site/locales/en/LC_MESSAGES/messages.po b/_site/locales/en/LC_MESSAGES/messages.po new file mode 100644 index 00000000..9fad8d18 --- /dev/null +++ b/_site/locales/en/LC_MESSAGES/messages.po @@ -0,0 +1,5602 @@ +# +msgid "" +msgstr "" + +#: ./404.md:block 1 (header) +msgid "SPDX-License-Identifier: CC0-1.0" +msgstr "" + +#: ./404.md:block 2 (header) +msgid "" +"SPDX-FileCopyrightText: 2022-2023 The Foundation for Public Code " +"[info@publiccode.net](mailto:info@publiccode.net), " +"https://standard.publiccode.net/AUTHORS" +msgstr "" + +#: ./404.md:block 3 (header) +msgid "" +"layout: default\n" +"title: Page not found\n" +"toc: false" +msgstr "" + +#: ./404.md:block 4 (header) +msgid "404 Not Found" +msgstr "" + +#: ./404.md:block 5 (paragraph) +msgid "If you typed the web address, check it is correct." +msgstr "" + +#: ./404.md:block 6 (paragraph) +msgid "If you pasted the web address, check you copied the entire address." +msgstr "" + +#: ./404.md:block 7 (paragraph) +msgid "" +"If the web address is correct or you followed a link or button, email the " +"[Foundation for Public Code staff](mailto:info@publiccode.net) so we'll be " +"able to help you out, as well as correct our mistake." +msgstr "" + +#: ./AUTHORS.md:block 2 (header) +msgid "" +"SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code " +"[info@publiccode.net](mailto:info@publiccode.net), " +"https://standard.publiccode.net/AUTHORS" +msgstr "" + +#: ./AUTHORS.md:block 3 (header) +msgid "Authors" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Alba Roza, [The Foundation for Public Code](https://publiccode.net/)" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Arnout Engelen" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Arnout Schuijff, The Foundation for Public Code" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Audrey Tang, [digitalminister.tw](https://digitalminister.tw/)" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Ben Cerveny, The Foundation for Public Code" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Bert Spaan" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Boris van Hoytema, The Foundation for Public Code" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Charlotte Heikendorf" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Claus Mullie, The Foundation for Public Code" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "David Barberi" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Edo Plantinga, [Code For NL](https://codefor.nl/)" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Elena Findley-de Regt, The Foundation for Public Code" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Eric Herman, The Foundation for Public Code" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Felix Faassen, The Foundation for Public Code" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Floris Deerenberg" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Jan Ainali, The Foundation for Public Code" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Johan Groenen, Code For NL" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Marcus Klaas de Vries" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Mark van der Net, [Gemeente Amsterdam](https://www.amsterdam.nl/en/)" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "" +"Martijn de Waal, [Amsterdam University of Applied Sciences " +"(AUAS)](https://www.amsterdamuas.com/), Faculty of Digital Media and " +"Creative Industries, Lectorate of Play & Civic Media" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Matti Schneider" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Mauko Quiroga" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Maurice Hendriks, Gemeente Amsterdam" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Maurits van der Schee, Gemeente Amsterdam" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Mirjam van Tiel, The Foundation for Public Code" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Ngô Ngọc Đức Huy" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Paul Keller" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "" +"Petteri Kivimäki, [Nordic Institute for Interoperability Solutions " +"(NIIS)](https://niis.org)" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Sky Bristol" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Tamas Erkelens, Gemeente Amsterdam" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Timo Slinger" +msgstr "" + +#: ./CC0-1.0.md:block 3 (header) +msgid "toc: false redirect_from: - license.html - LICENSE.html" +msgstr "" + +#: ./CC0-1.0.md:block 4 (header) +msgid "Creative Commons Zero v1.0 Universal" +msgstr "" + +#: ./CC0-1.0.md:block 6 (paragraph) +msgid "" +"This license is the legal contract that allows anyone to do anything they " +"like with the content in this entire document." +msgstr "" + +#: ./CHANGELOG.md:block 3 (header) +msgid "" +"script/release-body.sh expects VERSION in the first second-level header" +msgstr "" + +#: ./CHANGELOG.md:block 4 (header) +msgid "script/update-changelog-date.sh expects DATE-OF-RELEASE and a colon" +msgstr "" + +#: ./CHANGELOG.md:block 5 (header) +msgid "Version history" +msgstr "" + +#: ./CHANGELOG.md:block 6 (header) +msgid "Version 0.7.1" +msgstr "" + +#: ./CHANGELOG.md:block 7 (paragraph) +msgid "" +"July 31st 2023: 💄 The sixteenth draft change the name of a criterion and " +"clarifies references to code." +msgstr "" + +#: ./CHANGELOG.md:block 8 (unordered list) +msgid "" +"The criterion \"Make the codebase reusable and portable\" was renamed from " +"\"Create reusable and portable code\"." +msgstr "" + +#: ./CHANGELOG.md:block 8 (unordered list) +msgid "Added a glossary entry for \"Source Code\"." +msgstr "" + +#: ./CHANGELOG.md:block 8 (unordered list) +msgid "" +"References to \"code\" which only applied to \"source code\" now reference " +"\"source code\" explicitly." +msgstr "" + +#: ./CHANGELOG.md:block 8 (unordered list) +msgid "Clarification of \"running code\" as \"software\"." +msgstr "" + +#: ./CHANGELOG.md:block 8 (unordered list) +msgid "Minor changes to clarify \"code\" vs \"codebase\"." +msgstr "" + +#: ./CHANGELOG.md:block 8 (unordered list) +msgid "Simplify guidance to policy makers in Bundle policy and source code." +msgstr "" + +#: ./CHANGELOG.md:block 8 (unordered list) +msgid "" +"Clarify How to test sections of Make the codebase findable and Make the " +"codebase reusable and portable." +msgstr "" + +#: ./CHANGELOG.md:block 8 (unordered list) +msgid "Add a criteria and requirements checklist to the release artifacts." +msgstr "" + +#: ./CHANGELOG.md:block 8 (unordered list) +msgid "Increase automation of the release process." +msgstr "" + +#: ./CHANGELOG.md:block 9 (header) +msgid "Version 0.7.0" +msgstr "" + +#: ./CHANGELOG.md:block 10 (paragraph) +msgid "" +"May 31st 2023: 📑 the fifteenth draft adds new requirements for documenting " +"review funding and clarifies review process requirement." +msgstr "" + +#: ./CHANGELOG.md:block 11 (unordered list) +msgid "" +"Add requirement to document who is expected to cover the cost of reviewing " +"contributions." +msgstr "" + +#: ./CHANGELOG.md:block 11 (unordered list) +msgid "Add requirement to have a short description of the codebase." +msgstr "" + +#: ./CHANGELOG.md:block 11 (unordered list) +msgid "" +"Change the focus of contributions adhering to standards to focus on the " +"review of contributions." +msgstr "" + +#: ./CHANGELOG.md:block 11 (unordered list) +msgid "Relaxed MUST requirements to SHOULD in Make the codebase findable." +msgstr "" + +#: ./CHANGELOG.md:block 11 (unordered list) +msgid "Review template now in HTML format." +msgstr "" + +#: ./CHANGELOG.md:block 11 (unordered list) +msgid "Introduction converted to foreword." +msgstr "" + +#: ./CHANGELOG.md:block 11 (unordered list) +msgid "Improved contributing guidelines." +msgstr "" + +#: ./CHANGELOG.md:block 11 (unordered list) +msgid "Improved documentation of scripts." +msgstr "" + +#: ./CHANGELOG.md:block 12 (header) +msgid "Version 0.6.0" +msgstr "" + +#: ./CHANGELOG.md:block 13 (paragraph) +msgid "" +"April 20th 2023: 🔀 the fourteenth draft adds new requirements for " +"portability and tests and an introduction to each criterion." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"New requirement in Create reusable and portable code about the development " +"being a collaboration between multiple parties." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"New requirement in Create reusable and portable code about being dependent " +"on a single vendor." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"New requirement in Use continuous integration about publishing results for " +"automated tests." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Differentiating the two requirements about security to clearly be about " +"providing a method and having documentation about it." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Rephrased requirements to focus on the codebase rather than contributor " +"behavior." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Removed the sections Why this is important and What this does not do and " +"replaced with an introduction in each criterion." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Added general What this does not do section in the introduction of the " +"Standard." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Added guidance for public policy makers about related policies and license " +"compatibility." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Added guidance for developers and designers about version controlling files." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Clarified guidance for developers and designers about prompt responses and " +"search engine optimization." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "Added Further reading about accessibility." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "Aligned criteria URLs with criteria names." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "Improved navigation in the web version." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Moved tools in Further reading sections to the community implementation " +"guide." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Moved compliance or certification process to " +"[publiccode.net](https://publiccode.net)." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Change format of the review template to make it easier to update after a new" +" release." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Improved the text on the landing page and added links to related resources." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "Added spell checker automated test." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "Made minor changes to text for clarity and consistency." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "Moved SPDX headers to yaml header." +msgstr "" + +#: ./CHANGELOG.md:block 15 (header) +msgid "Version 0.5.0" +msgstr "" + +#: ./CHANGELOG.md:block 16 (paragraph) +msgid "" +"January 25th 2023: 🎨 the thirteenth draft focuses on documenting style " +"guidelines." +msgstr "" + +#: ./CHANGELOG.md:block 17 (unordered list) +msgid "" +"Adjust the coding style requirement to focus on the codebase using a style " +"guide rather than contributor behavior." +msgstr "" + +#: ./CHANGELOG.md:block 17 (unordered list) +msgid "" +"Moved requirement for codebase names to Make the codebase findable from Use " +"plain English." +msgstr "" + +#: ./CHANGELOG.md:block 17 (unordered list) +msgid "" +"Moved requirement about testing the code by using examples to Use continuous" +" integration from Document the code." +msgstr "" + +#: ./CHANGELOG.md:block 17 (unordered list) +msgid "" +"Split requirement about machine testable standards to clarify that open is " +"more important than testable." +msgstr "" + +#: ./CHANGELOG.md:block 17 (unordered list) +msgid "" +"Adjust how to test findability requirements to be less reliant on search " +"engine algorithms." +msgstr "" + +#: ./CHANGELOG.md:block 18 (header) +msgid "Version 0.4.1" +msgstr "" + +#: ./CHANGELOG.md:block 19 (paragraph) +msgid "December 5th 2022: 📝 the twelfth draft clarifies document maturity." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "" +"Document maturity focuses on whether or not versions of the codebase are " +"ready to use." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "" +"Document maturity no longer requires specific labels for codebases that are " +"not ready to use." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Audit flow image now generated from an easier to translate format." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Improved guidance on How to test." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Add publiccode.yml file." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Add review template." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Consistently link glossary terms." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Add practices and standards to follow in CONTRIBUTING." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Add Matti Schneider to Authors." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Add remaining SPDX headers to files." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Made additional minor changes to text for clarity." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Some hyperlinks updated." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "" +"Moved examples to the [Community implementation " +"guide](https://publiccodenet.github.io/community-implementation-guide-" +"standard/)." +msgstr "" + +#: ./CHANGELOG.md:block 21 (header) +msgid "Version 0.4.0" +msgstr "" + +#: ./CHANGELOG.md:block 22 (paragraph) +msgid "" +"September 7th 2022: 🔭 the eleventh draft adds a new findability criterion." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Introduce new criterion: Make the codebase findable." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Improve How to test section for most criteria." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "" +"New requirement in Welcome contributors about publishing activity " +"statistics." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Removed redundant requirement about portable and reusable code." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "" +"Expand open license definition to include both OSI and FSF approved " +"licenses." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Rephrase MAY requirements to use the keyword OPTIONAL for clarity." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "" +"Expressed intent that the Standard for Public Code should meet its own " +"requirements where applicable and added assessment." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Add SPDX license identifiers to files." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Introduced new Code of Conduct." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Clarify distinction between source code and policy text." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Restructuring of requirements with bullet point lists." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Acknowledge the importance of codebase modularity for reuse." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Move requirements related to Findability to the new criterion." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Clarify the role of non-open standards when used in a codebase." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Additional guidance about build-time and runtime dependencies." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Added roadmap for the development of the Standard for Public Code." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Update structure of Authors file." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Add Audrey Tang to Authors." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Added a list of criteria to the print edition." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "" +"Clarify what the standard means with policymakers, managers, developers and " +"designers." +msgstr "" + +#: ./CHANGELOG.md:block 24 (header) +msgid "Version 0.3.0" +msgstr "" + +#: ./CHANGELOG.md:block 25 (paragraph) +msgid "" +"May 23rd 2022: 🗎 the tenth draft strengthens documentation and localization." +msgstr "" + +#: ./CHANGELOG.md:block 26 (unordered list) +msgid "" +"Requirement for localization made explicit in Create reusable and portable " +"code." +msgstr "" + +#: ./CHANGELOG.md:block 26 (unordered list) +msgid "Documentation of governance changed from a SHOULD to a MUST." +msgstr "" + +#: ./CHANGELOG.md:block 26 (unordered list) +msgid "" +"Replace the very subjective (and hard to test) \"contributions MUST be " +"small\" with requirement to document expectation in contributing guidelines " +"and focus on a single issue." +msgstr "" + +#: ./CHANGELOG.md:block 26 (unordered list) +msgid "Community translations now linked in the footer." +msgstr "" + +#: ./CHANGELOG.md:block 26 (unordered list) +msgid "Revert \"Replace BPMN svg with Mermaid flowchart\"." +msgstr "" + +#: ./CHANGELOG.md:block 26 (unordered list) +msgid "Many minor clarifications to language and sentences made more simple." +msgstr "" + +#: ./CHANGELOG.md:block 27 (header) +msgid "Version 0.2.3" +msgstr "" + +#: ./CHANGELOG.md:block 28 (paragraph) +msgid "" +"March 15th 2022: 📜 the ninth draft allows English summaries for policy " +"lacking an official translation." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "" +"Relax the criterion Use plain English by adding a new requirement allows " +"bundled policy not available in English to have an accompanying summary in " +"English instead of translating the full text." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "" +"Similarly, allow for English summaries for policies not available in English" +" in Bundle policy and code." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "" +"Clarify that term 'policy' includes processes which impact development and " +"deployment in Bundle policy and code." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "" +"Emphasize reusability also on parts of the solutions in Create reusable and " +"portable code." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "" +"Expand guidance to Developers and designers in Create reusable and portable " +"code about deploying to proprietary platforms." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "" +"Add nuance to use of non-English terms in what management need to do in Use " +"plain English." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "" +"Change the pull request process diagram to use Mermaid instead of BPMN to " +"make [community translations](https://github.com/publiccodenet/community-" +"translations-standard) easier." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "Added Maurice Hendriks to AUTHORS." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "Added OpenApi Specification to further reading." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "Made the attributions in further reading sections clearer." +msgstr "" + +#: ./CHANGELOG.md:block 30 (header) +msgid "Version 0.2.2" +msgstr "" + +#: ./CHANGELOG.md:block 31 (paragraph) +msgid "" +"November 29th 2021: 🏛 the eighth draft recognizes that policy which executes" +" as code may not be in English." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "" +"Document exception to \"All code MUST be in English\" where policy is " +"interpreted as code." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "" +"Add MAY requirement regarding committer email addresses in Maintain version " +"control." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Expand guidance to Policy Makers in Bundle policy and code." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Expand guidance to Developers and designers in Use a coherent style." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Add \"Different contexts\" to glossary." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Add Mauko Quiroga and Charlotte Heikendorf to AUTHORS." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Add Digital Public Goods approval badge." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Added \"next\" and \"previous\" links to criteria pages of web version." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Add Open Standards principles to further reading." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Add Definition of plain language to further reading." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Move the Semantic Versioning Specification further reading reference." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "" +"Clarify that publiccode.yml is one example of a machine-readable metadata " +"description." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Changed \"your codebase\" and \"your organization\" to be less possessive." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Add instructions for creating a print version." +msgstr "" + +#: ./CHANGELOG.md:block 33 (header) +msgid "Version 0.2.1" +msgstr "" + +#: ./CHANGELOG.md:block 34 (paragraph) +msgid "" +"March 1st 2021: 🧽 the seventh draft has minor cleaning up after version " +"0.2.0." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "" +"New SHOULD requirement on using a distributed version control system and why" +" distributed is important." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "" +"Feedback requirements for rejected contributions are more strict than " +"accepted ones." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "" +"Specify that copyright and license notices should also be machine-readable." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "Advice on how to test that notices be machine-readable." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "Clarify guidance for rolling releases." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "Clear up definition of version control in glossary." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "" +"Add further reading encouraging contribution, SPDX, Git and reviewing " +"contributions." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "Add links to videos about the concept of public code." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "Update BPMN link." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "Reduce link duplication." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "Add Alba Roza and Ngô Ngọc Đức Huy to authors." +msgstr "" + +#: ./CHANGELOG.md:block 36 (header) +msgid "Version 0.2.0" +msgstr "" + +#: ./CHANGELOG.md:block 37 (paragraph) +msgid "" +"October 26th 2020: 🎊 the sixth draft splits a requirement and adds clarity." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "" +"Split \"Welcome contributions\" criterion into \"Make contributing easy\" " +"and \"Welcome contributors\"." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "" +"Rename criterion \"Pay attention to codebase maturity\" to \"Document " +"codebase maturity\"." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "" +"Changed MUST to SHOULD for requirement of codebase in use by multiple " +"parties." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "Add MUST NOT requirement regarding copyright assignment." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "Clarify role of configuration in reusable code requirement." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "" +"Glossary additions: continuous integration, policy, repository, and version " +"control." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "Replace references to 'cities' with 'public organizations'." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "" +"Clarify aspects of sensitive code by separating contributor and reviewer " +"requirements into separate items." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "" +"Expand further reading, and guidance to policy makers, developers and " +"designers." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "Add Felix Faassen and Arnout Engelen to authors." +msgstr "" + +#: ./CHANGELOG.md:block 39 (header) +msgid "Version 0.1.4" +msgstr "" + +#: ./CHANGELOG.md:block 40 (paragraph) +msgid "" +"November 27th 2019: 🧹 the fifth draft consists mostly of additional minor " +"fixes." +msgstr "" + +#: ./CHANGELOG.md:block 41 (unordered list) +msgid "Linked License.md file." +msgstr "" + +#: ./CHANGELOG.md:block 41 (unordered list) +msgid "Add Sky Bristol, Marcus Klaas de Vries, and Jan Ainali to authors." +msgstr "" + +#: ./CHANGELOG.md:block 41 (unordered list) +msgid "Made punctuation more consistent, especially for bullet lists." +msgstr "" + +#: ./CHANGELOG.md:block 41 (unordered list) +msgid "Made some minor changes to text for clarity." +msgstr "" + +#: ./CHANGELOG.md:block 42 (header) +msgid "Version 0.1.3" +msgstr "" + +#: ./CHANGELOG.md:block 43 (paragraph) +msgid "" +"October 8th 2019: 🍂 the fourth draft only patches and fixes minor things for" +" the autumn cleaning" +msgstr "" + +#: ./CHANGELOG.md:block 44 (unordered list) +msgid "Renamed continuous delivery to continuous integration." +msgstr "" + +#: ./CHANGELOG.md:block 44 (unordered list) +msgid "Referencing accessibility guidelines in the language standard." +msgstr "" + +#: ./CHANGELOG.md:block 44 (unordered list) +msgid "A bunch of style and consistency fixes." +msgstr "" + +#: ./CHANGELOG.md:block 45 (header) +msgid "Version 0.1.2" +msgstr "" + +#: ./CHANGELOG.md:block 46 (paragraph) +msgid "" +"August 22th 2019: 🌠 the third draft focuses on better text and takes " +"community input" +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "With some great new contributors comes a fresh author list." +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "All links are now HTTPS." +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "General proofreading, wording clarifications, and smashed typos." +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "Updated criteria:" +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "Requirement for reuse in different contexts" +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "Recommendation for explicit versioning" +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "Recommendation for multi party development" +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "Recommendation for license headers in files" +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "Recommendation for vulnerability reporting" +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "Recommendation for explicit documentation of governance" +msgstr "" + +#: ./CHANGELOG.md:block 48 (header) +msgid "Version 0.1.1" +msgstr "" + +#: ./CHANGELOG.md:block 49 (paragraph) +msgid "" +"May 9th 2019: 🤔 the second draft fixes a few basic oversights and fixes a " +"lot of typos" +msgstr "" + +#: ./CHANGELOG.md:block 50 (unordered list) +msgid "" +"Removed references to the Foundation for Public Code, we're going to have to" +" change the name in becoming an association." +msgstr "" + +#: ./CHANGELOG.md:block 50 (unordered list) +msgid "Updated the introduction." +msgstr "" + +#: ./CHANGELOG.md:block 50 (unordered list) +msgid "Updated the glossary." +msgstr "" + +#: ./CHANGELOG.md:block 50 (unordered list) +msgid "Added the code of conduct." +msgstr "" + +#: ./CHANGELOG.md:block 50 (unordered list) +msgid "We've recommended using the publiccode.yml standard for easier reuse." +msgstr "" + +#: ./CHANGELOG.md:block 51 (header) +msgid "Version 0.1.0" +msgstr "" + +#: ./CHANGELOG.md:block 52 (paragraph) +msgid "" +"April 16th 2019: 🎉 the first draft is ready, it is all brand new and has " +"snazzy new ideas in it" +msgstr "" + +#: ./CHANGELOG.md:block 53 (unordered list) +msgid "14 criteria with their requirements and how to operationalize them." +msgstr "" + +#: ./CHANGELOG.md:block 53 (unordered list) +msgid "" +"An introduction with a high level background, what this standard is, and how" +" the Foundation for Public Code will use it." +msgstr "" + +#: ./CHANGELOG.md:block 54 (paragraph) +msgid "" +"This first version was produced together with the Amsterdam University of " +"Applied Sciences and the City of Amsterdam as a part of the [Smart Cities? " +"Public Code! project](https://smartcities.publiccode.net/)." +msgstr "" + +#: ./CODE_OF_CONDUCT.md:block 1 (header) +msgid "Code of Conduct" +msgstr "" + +#: ./CODE_OF_CONDUCT.md:block 3 (paragraph) +msgid "" +"Many community members are from civic or professional environments with " +"behavioral codes yet some individuals are not. This document expresses " +"expectations of all community members and all interactions regardless of " +"communication channel." +msgstr "" + +#: ./CODE_OF_CONDUCT.md:block 4 (paragraph) +msgid "Be here to collaborate." +msgstr "" + +#: ./CODE_OF_CONDUCT.md:block 5 (paragraph) +msgid "Be considerate, respectful, and patient." +msgstr "" + +#: ./CODE_OF_CONDUCT.md:block 6 (paragraph) +msgid "Strive to be as constructive as possible." +msgstr "" + +#: ./CODE_OF_CONDUCT.md:block 7 (paragraph) +msgid "To raise a concern, please email directors@publiccode.net." +msgstr "" + +#: ./CONTRIBUTING.md:block 1 (header) +msgid "Contributing to this standard" +msgstr "" + +#: ./CONTRIBUTING.md:block 3 (paragraph) +msgid "🙇‍♀️ Thank you for contributing!" +msgstr "" + +#: ./CONTRIBUTING.md:block 4 (paragraph) +msgid "" +"We understand that a standard like this can only be set in collaboration " +"with as many public technologists, policy makers and interested folk as " +"possible. Thus we appreciate your input, enjoy feedback and welcome " +"improvements to this project and are very open to collaboration." +msgstr "" + +#: ./CONTRIBUTING.md:block 5 (paragraph) +msgid "" +"We love issues and pull requests from everyone. If you're not comfortable " +"with GitHub, you can email use your feedback at " +"[info@publiccode.net](mailto:info@publiccode.net)." +msgstr "" + +#: ./CONTRIBUTING.md:block 6 (header) +msgid "Problems, suggestions and questions in issues" +msgstr "" + +#: ./CONTRIBUTING.md:block 7 (paragraph) +msgid "" +"A high-level overview of the development that we already have sketched out " +"can be seen in the [roadmap](/docs/roadmap.md). Please help development by " +"reporting problems, suggesting changes and asking questions. To do this, you" +" can [create a GitHub issue](https://docs.github.com/en/issues/tracking-" +"your-work-with-issues/creating-an-issue) for this project in the [GitHub " +"Issues for the Standard for Public " +"Code](https://github.com/publiccodenet/standard/issues)." +msgstr "" + +#: ./CONTRIBUTING.md:block 8 (paragraph) +msgid "" +"Or, sign up to the [mailing " +"list](https://lists.publiccode.net/mailman/postorius/lists/standard.lists.publiccode.net/)" +" and send an email to " +"[standard@lists.publiccode.net](mailto:standard@lists.publiccode.net)." +msgstr "" + +#: ./CONTRIBUTING.md:block 9 (paragraph) +msgid "" +"You don't need to change any of our code or documentation to be a " +"contributor!" +msgstr "" + +#: ./CONTRIBUTING.md:block 10 (header) +msgid "Documentation and code in pull requests" +msgstr "" + +#: ./CONTRIBUTING.md:block 11 (paragraph) +msgid "" +"If you want to add to the documentation or code of one of our projects you " +"should make a pull request." +msgstr "" + +#: ./CONTRIBUTING.md:block 12 (paragraph) +msgid "" +"If you never used GitHub, get up to speed with [Understanding the GitHub " +"flow](https://docs.github.com/en/get-started/quickstart/github-flow) or " +"follow one of the great free interactive courses in [GitHub " +"Skills](https://skills.github.com/) on working with GitHub and working with " +"MarkDown, the syntax this project's documentation is in." +msgstr "" + +#: ./CONTRIBUTING.md:block 13 (paragraph) +msgid "" +"This project is licensed Creative Commons Zero v1.0 Universal, which " +"essentially means that the project, along with your contributions is in the " +"public domain in whatever jurisdiction possible, and everyone can do " +"whatever they want with it." +msgstr "" + +#: ./CONTRIBUTING.md:block 14 (header) +msgid "1. Make your changes" +msgstr "" + +#: ./CONTRIBUTING.md:block 15 (paragraph) +msgid "" +"Contributions should [follow](docs/standard-for-public-code.html) the " +"requirements set out in the criteria of the Standard for Public code itself." +" Reviewers will also be ensuring that contributions are aligned with the " +"[values of public code](foreword.md#values-of-public-code). Furthermore, " +"they will review that the contribution conforms to the " +"[standards](#standards-to-follow) and remains coherent with the overall " +"work." +msgstr "" + +#: ./CONTRIBUTING.md:block 16 (paragraph) +msgid "" +"This project uses the [GitFlow branching model and " +"workflow](https://nvie.com/posts/a-successful-git-branching-model/). When " +"you've forked this repository, please make sure to create a feature branch " +"following the GitFlow model." +msgstr "" + +#: ./CONTRIBUTING.md:block 17 (paragraph) +msgid "" +"Add your changes in commits [with a message that explains " +"them](https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-" +"message). If more than one type of change is needed, group logically related" +" changes into separate commits. For example, white-space fixes could be a " +"separate commit from text content changes. When adding new files, select " +"file formats that are easily viewed in a `diff`, for instance, `.svg` is " +"preferable to a binary image. Document choices or decisions you make in the " +"commit message, this will enable everyone to be informed of your choices in " +"the future." +msgstr "" + +#: ./CONTRIBUTING.md:block 18 (paragraph) +msgid "" +"If you are adding code, make sure you've added and updated the relevant " +"documentation and tests before you submit your pull request. Make sure to " +"write tests that show the behavior of the newly added or changed code." +msgstr "" + +#: ./CONTRIBUTING.md:block 19 (header) +msgid "Applicable policy" +msgstr "" + +#: ./CONTRIBUTING.md:block 20 (paragraph) +msgid "" +"Currently, the Standard for Public Code is not implementing any specific " +"public policy." +msgstr "" + +#: ./CONTRIBUTING.md:block 21 (header) +msgid "Style" +msgstr "" + +#: ./CONTRIBUTING.md:block 22 (paragraph) +msgid "" +"The Standard for Public Code aims to [use plain English](criteria/use-plain-" +"english.md) and we have chosen American English for spelling. Text content " +"should typically follow one line per sentence, with no line-wrap, in order " +"to make `diff` output easier to view. However, we want to emphasize that it " +"is more important that you make your contribution than worry about spelling " +"and typography. We will help you get it right in our review process and we " +"also have a separate quality check before [making a new " +"release](docs/releasing.md)." +msgstr "" + +#: ./CONTRIBUTING.md:block 23 (header) +msgid "Standards to follow" +msgstr "" + +#: ./CONTRIBUTING.md:block 24 (paragraph) +msgid "" +"These are the standards that the Standard for Public Code uses. Please make " +"sure that your contributions are aligned with them so that they can be " +"merged more easily." +msgstr "" + +#: ./CONTRIBUTING.md:block 25 (unordered list) +msgid "" +"[IETF RFC 2119](https://tools.ietf.org/html/rfc2119) - for requirement level" +" keywords" +msgstr "" + +#: ./CONTRIBUTING.md:block 25 (unordered list) +msgid "" +"[Web Content Accessibility Guidelines " +"2.1](https://www.w3.org/TR/WCAG21/#readable) - for readability" +msgstr "" + +#: ./CONTRIBUTING.md:block 26 (header) +msgid "2. Pull request" +msgstr "" + +#: ./CONTRIBUTING.md:block 27 (paragraph) +msgid "" +"When submitting the pull request, please accompany it with a description of " +"the problem you are trying to solve and the issue number that this pull " +"request fixes. It is preferred for each pull request to address a single " +"issue where possible. In some cases a single set of changes may address " +"multiple issues, in which case be sure to list all issue numbers fixed." +msgstr "" + +#: ./CONTRIBUTING.md:block 28 (header) +msgid "3. Improve" +msgstr "" + +#: ./CONTRIBUTING.md:block 29 (paragraph) +msgid "" +"All contributions have to be reviewed by someone. The Foundation for Public " +"Code has committed to make sure that maintainers are available to review " +"contributions with an aim to provide feedback within two business days." +msgstr "" + +#: ./CONTRIBUTING.md:block 30 (paragraph) +msgid "" +"It could be that your contribution can be merged immediately by a " +"maintainer. However, usually, a new pull request needs some improvements " +"before it can be merged. Other contributors (or helper robots) might have " +"feedback. If this is the case the reviewing maintainer will help you improve" +" your documentation and code." +msgstr "" + +#: ./CONTRIBUTING.md:block 31 (paragraph) +msgid "If your documentation and code have passed human review, it is merged." +msgstr "" + +#: ./CONTRIBUTING.md:block 32 (header) +msgid "4. Celebrate" +msgstr "" + +#: ./CONTRIBUTING.md:block 33 (paragraph) +msgid "" +"Your ideas, documentation and code have become an integral part of this " +"project. You are the open source hero we need!" +msgstr "" + +#: ./CONTRIBUTING.md:block 34 (paragraph) +msgid "" +"In fact, feel free to open a pull request to add your name to the " +"[`AUTHORS`](AUTHORS.md) file and get eternal attribution." +msgstr "" + +#: ./CONTRIBUTING.md:block 35 (header) +msgid "Translations in other languages" +msgstr "" + +#: ./CONTRIBUTING.md:block 36 (paragraph) +msgid "" +"While the Standard does not have any official translations, you can help " +"maintain existing and add new [community translations of the " +"Standard](https://github.com/publiccodenet/community-translations-standard)." +msgstr "" + +#: ./CONTRIBUTING.md:block 37 (header) +msgid "Releases" +msgstr "" + +#: ./CONTRIBUTING.md:block 38 (paragraph) +msgid "" +"We have dedicated documentation for creating [new " +"releases](/docs/releasing.md) and [ordering printed " +"standards](/docs/printing.md)." +msgstr "" + +#: ./CONTRIBUTING.md:block 39 (paragraph) +msgid "" +"For more information on how to use and contribute to this project, please " +"read the [`README`](README.md)." +msgstr "" + +#: ./GOVERNANCE.md:block 2 (header) +msgid "" +"SPDX-FileCopyrightText: 2019-2022 The Foundation for Public Code " +"[info@publiccode.net](mailto:info@publiccode.net), " +"https://standard.publiccode.net/AUTHORS" +msgstr "" + +#: ./GOVERNANCE.md:block 3 (header) +msgid "Governance" +msgstr "" + +#: ./GOVERNANCE.md:block 4 (paragraph) +msgid "" +"This standard lies at the core of the codebase stewardship provided by the " +"[Foundation for Public Code](https://publiccode.net/). We decide if a " +"codebase is ready for community co-development based on this document." +msgstr "" + +#: ./GOVERNANCE.md:block 5 (paragraph) +msgid "The standard is maintained by Foundation for Public Code staff." +msgstr "" + +#: ./GOVERNANCE.md:block 6 (paragraph) +msgid "" +"[We welcome contributions, such as suggestions for changes or general " +"feedback, from anyone.](/CONTRIBUTING.md)" +msgstr "" + +#: ./GOVERNANCE.md:block 7 (paragraph) +msgid "" +"Because of the important role that the Standard for Public Code has in our " +"core process we require the highest standards from the Standard." +msgstr "" + +#: ./GOVERNANCE.md:block 8 (paragraph) +msgid "" +"We will try to respond promptly to all pull requests. The pull request is an" +" opportunity to work together to improve our methods and the Standard. We " +"may not accept all changes, but we will explain our logic." +msgstr "" + +#: ./README.md:block 1 (header) +msgid "Standard for Public Code" +msgstr "" + +#: ./README.md:block 3 (paragraph) +msgid "" +"The Standard for Public Code gives public organizations a model for " +"preparing open source solutions to enable collaborations with similar public" +" organizations in other places. It includes guidance for policy makers, city" +" administrators, developers and vendors." +msgstr "" + +#: ./README.md:block 4 (paragraph) +msgid "" +"![version 0.7.1](assets/version-badge.svg) [![License: " +"CC0-1.0](https://img.shields.io/badge/License-" +"CC0_1.0-lightgrey.svg)](http://creativecommons.org/publicdomain/zero/1.0/) " +"[![Standard commitment](assets/standard-for-public-code-" +"commitment.svg)](#help-improve-this-standard)" +msgstr "" + +#: ./README.md:block 5 (paragraph) +msgid "" +"[![pages-build-" +"deployment](https://github.com/publiccodenet/standard/actions/workflows/pages/pages-" +"build-" +"deployment/badge.svg)](https://github.com/publiccodenet/standard/actions/workflows/pages/pages-" +"build-deployment) " +"[![Test](https://github.com/publiccodenet/standard/actions/workflows/test.yml/badge.svg)](https://github.com/publiccodenet/standard/actions/workflows/test.yml)" +" [![standard main badge](https://publiccodenet.github.io/publiccodenet-url-" +"check/badges/standard.publiccode.net.svg)](https://publiccodenet.github.io/publiccodenet-" +"url-check/standard.publiccode.net-url-check-look.json) [![standard develop " +"badge](https://publiccodenet.github.io/publiccodenet-url-" +"check/badges/standard.publiccode.net-" +"develop.svg)](https://publiccodenet.github.io/publiccodenet-url-" +"check/standard.publiccode.net-develop-url-check-look.json)" +msgstr "" + +#: ./README.md:block 6 (paragraph) +msgid "" +"The Standard for Public Code is in a draft format. We are preparing it for a" +" version 1.0 release. Currently, we are testing it on a small number of " +"codebases." +msgstr "" + +#: ./README.md:block 7 (header) +msgid "Applying the Standard for Public Code to your codebase" +msgstr "" + +#: ./README.md:block 8 (paragraph) +msgid "" +"If you want to apply the Standard for Public Code to your codebase, just go " +"ahead, it's an open standard and free for anyone to use. If you wish to " +"advertise the codebase community's aspiration to meet the criteria of the " +"Standard for Public Code, link the documentation of this commitment from the" +" [standard-for-public-code-commitment badge](assets/standard-for-public-" +"code-commitment.svg). To see how ready your codebase is, you can do a quick " +"[eligibility self assessment](https://publiccodenet.github.io/assessment-" +"eligibility) that will give you a rough idea of how much work you may need " +"to do to meet all criteria." +msgstr "" + +#: ./README.md:block 9 (paragraph) +msgid "" +"The standard *should* be mostly self-explanatory in how to apply it to your " +"codebase. If anything in the standard is unclear, we encourage you to open " +"an issue here so that we can help you and anyone else who feels the same as " +"you. For inspiration, look at the [community built implementation " +"guide](https://publiccodenet.github.io/community-implementation-guide-" +"standard/) which contains examples and other tips." +msgstr "" + +#: ./README.md:block 10 (paragraph) +msgid "" +"If there are any breaking changes in a new version of the Standard for " +"Public Code, the codebase stewards at the Foundation for Public Code will " +"help any implementers of the standard understand how the gaps can be closed." +msgstr "" + +#: ./README.md:block 11 (paragraph) +msgid "" +"If you want to commit your codebase to become fully compliant to the " +"standard for future certification, please contact us at " +"[info@publiccode.net](mailto:info@publiccode.net) to initiate a formal " +"[assessment](https://about.publiccode.net/activities/codebase-" +"stewardship/lifecycle-diagram.html#assessment)." +msgstr "" + +#: ./README.md:block 12 (header) +msgid "Request for contributions" +msgstr "" + +#: ./README.md:block 13 (paragraph) +msgid "" +"We believe public policy and software should be inclusive, usable, open, " +"legible, accountable, accessible and sustainable. This means we need a new " +"way of designing, developing and procuring both the source code and policy " +"documentation." +msgstr "" + +#: ./README.md:block 14 (paragraph) +msgid "" +"This standard sets a quality level for codebases that meets the needs of " +"public organizations, institutions and administrations as well as other " +"critical infrastructural services." +msgstr "" + +#: ./README.md:block 15 (paragraph) +msgid "" +"The standard lives at " +"[standard.publiccode.net](https://standard.publiccode.net/). See " +"[`index.md`](index.md) for an overview of all content." +msgstr "" + +#: ./README.md:block 16 (paragraph) +msgid "" +"[![Thumbnail for the video on the Standard for Public Code: a printed " +"version lying on a table between two " +"hands](https://img.youtube.com/vi/QWt6vB-" +"cipE/mqdefault.jpg)](https://www.youtube.com/watch?v=QWt6vB-cipE)" +msgstr "" + +#: ./README.md:block 17 (paragraph) +msgid "" +"[A video introduction to Standard for Public " +"Code](https://www.youtube.com/watch?v=QWt6vB-cipE) from Creative Commons " +"Global Summit 2020 (4:12) on YouTube." +msgstr "" + +#: ./README.md:block 18 (header) +msgid "Help improve this standard" +msgstr "" + +#: ./README.md:block 19 (paragraph) +msgid "" +"The Foundation for Public Code is committed to maintaining and developing " +"the Standard for Public Code at a level of quality that meets the standard " +"itself." +msgstr "" + +#: ./README.md:block 20 (paragraph) +msgid "" +"We are looking for people like you to [contribute](CONTRIBUTING.md) to this " +"project by suggesting improvements and helping develop it. 😊 Get started by " +"reading our [contributors guide](CONTRIBUTING.md). Since it is such a core " +"document we will accept contributions when they add significant value. We've" +" described how we govern the standard in the [governance " +"statement](GOVERNANCE.md)." +msgstr "" + +#: ./README.md:block 21 (paragraph) +msgid "" +"Please note that this project is released with a [code of " +"conduct](CODE_OF_CONDUCT.md). By participating in this project you agree to " +"abide by its terms. Please be lovely to all other community members." +msgstr "" + +#: ./README.md:block 22 (header) +msgid "Preview, build and deploy" +msgstr "" + +#: ./README.md:block 23 (paragraph) +msgid "" +"The repository builds to a static site deployed at " +"[standard.publiccode.net](https://standard.publiccode.net/). It is built " +"with [GitHub pages](https://pages.github.com) and " +"[Jekyll](https://jekyllrb.com/)." +msgstr "" + +#: ./README.md:block 24 (paragraph) +msgid "" +"The content is made to be built with [Jekyll](http://jekyllrb.com/), which " +"means you will need ruby and ruby-bundler installed, for example:" +msgstr "" + +#: ./README.md:block 26 (paragraph) +msgid "" +"If `ruby` and `bundle` are installed, one can run `bundle install` after " +"which the site can be rendered with the `script/serve.sh` script." +msgstr "" + +#: ./README.md:block 27 (header) +msgid "Testing" +msgstr "" + +#: ./README.md:block 28 (paragraph) +msgid "" +"A variety of test scripts are included. The script `script/test-all.sh` " +"wraps running of all local tests." +msgstr "" + +#: ./README.md:block 29 (paragraph) +msgid "" +"See the scripts in the " +"[script](https://github.com/publiccodenet/standard/tree/main/script) folder." +msgstr "" + +#: ./README.md:block 30 (header) +msgid "Generating a PDF of the Standard for Public Code" +msgstr "" + +#: ./README.md:block 31 (paragraph) +msgid "" +"In addition to Jekyll, generating PDFs relies upon " +"[Weasyprint](https://weasyprint.org/) and " +"[QPDF](https://github.com/qpdf/qpdf). [Pandoc](https://pandoc.org/) can be " +"used to transform PDFs into `.epub`." +msgstr "" + +#: ./README.md:block 32 (paragraph) +msgid "" +"To generate these kinds of files, the dependencies should be installed, for " +"example:" +msgstr "" + +#: ./README.md:block 34 (paragraph) +msgid "" +"The file `standard-print.html` can be converted to a nice looking PDF, along" +" with the other release files, using:" +msgstr "" + +#: ./README.md:block 36 (header) +msgid "License" +msgstr "" + +#: ./README.md:block 37 (paragraph) +msgid "© [The authors and contributors](AUTHORS.md)" +msgstr "" + +#: ./README.md:block 38 (paragraph) +msgid "" +"The standard is [licensed](LICENSE) under CC 0, which also applies to all " +"illustrations and the documentation. This means anyone can do anything with " +"it. If you contribute you also grant these rights to others. You can read " +"more about how to help in the [contributing guide](CONTRIBUTING.md)." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 3 (paragraph) +msgid "order: 2 redirect_from:" +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 4 (unordered list) +msgid "criteria/bundle-policy-and-code" +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 5 (header) +msgid "Bundle policy and source code" +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 6 (paragraph) +msgid "" +"Access to both [source code](../glossary.md#source-code) and " +"[policy](../glossary.md#policy) documentation provides building blocks for " +"anyone to implement the codebase in their local context or contribute to the" +" further development of the [codebase](../glossary.md#codebase)." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 7 (paragraph) +msgid "" +"Understanding the domain and policies within that domain is fundamental to " +"understanding what problems a codebase is trying to solve and how it sets " +"out to solve them." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 8 (paragraph) +msgid "" +"To be able to evaluate whether to implement a codebase in a new context, an " +"organization needs to understand what process changes it must choose to make" +" or how to contribute additional configurability to the existing solution in" +" order to adapt it to the new context." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 9 (header) +msgid "Requirements" +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 10 (unordered list) +msgid "The codebase MUST include the policy that the source code is based on." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 10 (unordered list) +msgid "" +"If a policy is based on source code, that source code MUST be included in " +"the codebase, unless used for fraud detection." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 10 (unordered list) +msgid "Policy SHOULD be provided in machine readable and unambiguous formats." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 10 (unordered list) +msgid "" +"[Continuous integration](../glossary.md#continuous-integration) tests SHOULD" +" validate that the source code and the policy are executed coherently." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 11 (header) +msgid "How to test" +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 12 (unordered list) +msgid "" +"Confirm with a civil servant that all policy that the source code is based " +"on is included." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 12 (unordered list) +msgid "" +"Confirm with a civil servant that all source code that the policy is based " +"on is included." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 12 (unordered list) +msgid "Check if policy can be interpreted by a machine." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 12 (unordered list) +msgid "" +"Check the continuous integration tests for coherent execution of source code" +" and policy pass." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 13 (header) +msgid "Public policy makers: what you need to do" +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Collaborate with developers and designers to make sure there is no mismatch " +"between policy code and source code." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Provide the relevant policy texts for inclusion in the " +"[repository](../glossary.md#repository); if the text is not available in " +"English, also provide an English summary. Be sure to include standards that " +"your organization has chosen to adhere to and any organizational processes " +"which impact the development or the deployment context of the codebase for " +"your organization." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "Provide references and links to texts which support the policies." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Document policy in formats that are unambiguous and machine-readable, such " +"as those published by the [Object Management " +"Group](https://www.omg.org/spec/)." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Track policy with [the same version control](maintain-version-control.md) " +"and documentation used to track source code." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Check in regularly to understand how the source code in the codebase has " +"changed and whether it still matches the [intentions of the " +"policy](document-codebase-objectives.md)." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Include relevant policies which impact the community, codebase, and " +"development, including legal obligations like the [General Data Protection " +"Regulation](https://eur-lex.europa.eu/eli/reg/2016/679/oj) or the [EU Web " +"Accessibility Directive](https://ec.europa.eu/digital-single-market/en/web-" +"accessibility), or human rights policies, like a public organization's " +"commitment to equal opportunity." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 15 (header) +msgid "Managers: what you need to do" +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 16 (unordered list) +msgid "" +"Keep policy makers, developers and designers involved and connected " +"throughout the whole development process." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 16 (unordered list) +msgid "" +"Make sure policy makers, developers and designers are working to the same " +"objectives." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 17 (header) +msgid "Developers and designers: what you need to do" +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 18 (unordered list) +msgid "" +"Become familiar with and be able to use the process modelling notation that " +"the policy makers in your organization use." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 18 (unordered list) +msgid "" +"Work together with policy makers to make sure there is no mismatch between " +"policy code and source code." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 18 (unordered list) +msgid "Give feedback on how to make policy documentation more clear." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 19 (header) +msgid "Further reading" +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 20 (unordered list) +msgid "" +"[Business Process Model and " +"Notation](https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation)" +" on Wikipedia." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 20 (unordered list) +msgid "" +"[BPMN Quick Guide](https://www.bpmnquickguide.com/view-bpmn-quick-guide/) by" +" Trisotech." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 20 (unordered list) +msgid "" +"[Decision Model and " +"Notation](https://en.wikipedia.org/wiki/Decision_Model_and_Notation) on " +"Wikipedia." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 20 (unordered list) +msgid "" +"[Case Management Model Notation](https://en.wikipedia.org/wiki/CMMN) on " +"Wikipedia." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 3 (header) +msgid "order: 1" +msgstr "" + +#: ./criteria/code-in-the-open.md:block 4 (header) +msgid "Code in the open" +msgstr "" + +#: ./criteria/code-in-the-open.md:block 5 (paragraph) +msgid "" +"Coding in the open improves transparency, increases [source " +"code](../glossary.md#source-code) quality, makes the source code easier to " +"audit, and enables collaboration." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 6 (paragraph) +msgid "" +"Together, this creates more opportunities for citizens to understand how " +"software and [policy](../glossary.md#policy) impact their interactions with " +"a public organization." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"All source code for any policy in use (unless used for fraud detection) MUST" +" be published and publicly accessible." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"All source code for any software in use (unless used for fraud detection) " +"MUST be published and publicly accessible." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"The codebase MUST NOT contain sensitive information regarding users, their " +"organization or third parties." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"Any source code not currently in use (such as new versions, proposals or " +"older versions) SHOULD be published." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"Documenting which source code or policy underpins any specific interaction " +"the [general public](../glossary.md#general-public) may have with an " +"organization is OPTIONAL." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 10 (unordered list) +msgid "" +"Confirm that the source for each version currently in use is published on " +"the internet where it can be seen from outside the original contributing " +"organization and without the need for any form of authentication or " +"authorization." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 10 (unordered list) +msgid "" +"Confirm that the [codebase](../glossary.md#codebase) files and commit " +"history do not include sensitive information." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 10 (unordered list) +msgid "Check for the publication of source code not currently in use." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 12 (unordered list) +msgid "Develop policies in the open." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 12 (unordered list) +msgid "Prioritize open and transparent policies." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 14 (unordered list) +msgid "Develop a culture that embraces openness, learning and feedback." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 14 (unordered list) +msgid "" +"Collaborate with external vendors and freelancers by working in the open." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 16 (unordered list) +msgid "" +"As a reviewer, for each commit, verify that content does not include " +"sensitive information such as configurations, usernames or passwords, public" +" keys or other real credentials used in production systems." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 16 (unordered list) +msgid "" +"Clearly split data and source code, in order to meet the requirement about " +"sensitive information above." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[Coding in the open](https://gds.blog.gov.uk/2012/10/12/coding-in-the-open/)" +" by the UK Government Digital Service." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[When code should be open or " +"closed](https://www.gov.uk/government/publications/open-source-" +"guidance/when-code-should-be-open-or-closed) by the UK Government Digital " +"Service." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[Security considerations when coding in the " +"open](https://www.gov.uk/government/publications/open-source-" +"guidance/security-considerations-when-coding-in-the-open) by the UK " +"Government Digital Service." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[Deploying software regularly](https://www.gov.uk/service-" +"manual/technology/deploying-software-regularly) by the UK Government Digital" +" Service." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[How GDS uses GitHub](https://gdstechnology.blog.gov.uk/2014/01/27/how-we-" +"use-github/) by the UK Government Digital Service." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 3 (header) +msgid "" +"order: 16 redirect_from: - criteria/advertise-maturity - criteria/document-" +"maturity" +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 4 (header) +msgid "Document codebase maturity" +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 5 (paragraph) +msgid "" +"Clearly signalling a [codebase](../glossary.md#codebase)'s maturity helps " +"others decide whether to use and contribute to it. A codebase version's " +"maturity includes the maturity of its dependencies. Understanding how a " +"codebase has evolved is key to understanding the codebase and how to " +"contribute to it." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "The codebase MUST be versioned." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "" +"The codebase MUST prominently document whether or not there are versions of " +"the codebase that are ready to use." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "" +"Codebase versions that are ready to use MUST only depend on versions of " +"other codebases that are also ready to use." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "" +"The codebase SHOULD contain a log of changes from version to version, for " +"example in the `CHANGELOG`." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "The method for assigning version identifiers SHOULD be documented." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "It is OPTIONAL to use semantic versioning." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "" +"Confirm that the codebase has a strategy for versioning which is documented." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "" +"Confirm that it is obvious to policy makers, managers, developers and " +"designers whether the codebase has versions that are ready to use." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "" +"Confirm that ready to use versions of the codebase do not depend on any " +"versions of other codebases that are not ready to use." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "" +"Check that the versioning scheme of the codebase is documented and followed." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "Check that there is a log of changes." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 11 (unordered list) +msgid "" +"When developing [policy](../glossary.md#policy), understand that any [source" +" code](../glossary.md#source-code) developed needs to be tested and improved" +" before it can be put into service." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 11 (unordered list) +msgid "" +"Consider versioning policy changes, especially when they trigger new " +"versions of the source code." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 13 (unordered list) +msgid "" +"Make sure that services only rely on versions of codebases of equal or " +"greater maturity than the service. For example, don't use a beta version of " +"a codebase in a production service." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 15 (unordered list) +msgid "" +"Make sure that the codebase versioning approach is followed for all " +"releases." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 17 (unordered list) +msgid "" +"[Semantic Versioning Specification](https://semver.org/) used by many " +"codebases to label versions." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 17 (unordered list) +msgid "" +"[Software release life " +"cycle](https://en.wikipedia.org/wiki/Software_release_life_cycle)" +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 17 (unordered list) +msgid "" +"[Service Design and Delivery Process](https://www.dta.gov.au/help-and-" +"advice/build-and-improve-services/service-design-and-delivery-process) by " +"the Australian Digital Transformation Agency." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 17 (unordered list) +msgid "" +"[Service Manual on Agile Delivery](https://www.gov.uk/service-manual/agile-" +"delivery) by the UK Government Digital Service." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 3 (paragraph) +msgid "order: 8 redirect_from:" +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 4 (unordered list) +msgid "criteria/document-objectives" +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 5 (header) +msgid "Document codebase objectives" +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 6 (paragraph) +msgid "" +"Clearly documenting [codebase](../glossary.md#codebase) objectives " +"communicates the purpose of the codebase. It helps stakeholders and " +"contributors scope the development of the codebase. The objectives also " +"provide an easy way for people to decide whether this codebase, or one of " +"its modules, is interesting for them now or in the future." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 8 (unordered list) +msgid "" +"The codebase MUST contain documentation of its objectives, like a mission " +"and goal statement, that is understandable by developers and designers so " +"that they can use or contribute to the codebase." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 8 (unordered list) +msgid "" +"Codebase documentation SHOULD clearly describe the connections between " +"[policy](../glossary.md#policy) objectives and codebase objectives." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 8 (unordered list) +msgid "" +"Documenting the objectives of the codebase for the [general " +"public](../glossary.md#general-public) is OPTIONAL." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 10 (unordered list) +msgid "" +"Confirm that the codebase documentation includes the codebase objectives, " +"mission or goal." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 10 (unordered list) +msgid "" +"Check for descriptions of connections between policy objectives and codebase" +" objectives." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 12 (unordered list) +msgid "" +"Add the policy objectives to the codebase documentation, for example in the " +"`README`." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 12 (unordered list) +msgid "" +"Make sure that all your codebase objectives have links or references to " +"supporting policy documents added to meet the [Bundle policy and source " +"code](bundle-policy-and-source-code.md) criterion." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 14 (unordered list) +msgid "" +"Add the organizational and business objectives to the codebase " +"documentation, for example in the `README`." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 16 (unordered list) +msgid "" +"Add the technology and design objectives to the codebase documentation, for " +"example in the `README`." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 18 (unordered list) +msgid "" +"[How to write project " +"objectives](http://grouper.ieee.org/groups/802/3/RTPGE/public/may12/hajduczenia_01_0512.pdf)" +" by Marek Hajduczenia." +msgstr "" + +#: ./criteria/document-the-code.md:block 3 (paragraph) +msgid "order: 9 redirect_from:" +msgstr "" + +#: ./criteria/document-the-code.md:block 4 (unordered list) +msgid "criteria/documenting" +msgstr "" + +#: ./criteria/document-the-code.md:block 5 (header) +msgid "Document the code" +msgstr "" + +#: ./criteria/document-the-code.md:block 6 (paragraph) +msgid "" +"Well documented [source code](../glossary.md#source-code) helps people to " +"understand what the source code does and how to use it. Documentation is " +"essential for people to start using the [codebase](../glossary.md#codebase) " +"and contributing to it more quickly." +msgstr "" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"All of the functionality of the codebase, [policy](../glossary.md#policy) as" +" well as source code, MUST be described in language clearly understandable " +"for those that understand the purpose of the codebase." +msgstr "" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase MUST contain a description of how to " +"install and run the software." +msgstr "" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase MUST contain examples demonstrating the " +"key functionality." +msgstr "" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase SHOULD contain a high level description " +"that is clearly understandable for a wide audience of stakeholders, like the" +" [general public](../glossary.md#general-public) and journalists." +msgstr "" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase SHOULD contain a section describing how to" +" install and run a standalone version of the source code, including, if " +"necessary, a test dataset." +msgstr "" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase SHOULD contain examples for all " +"functionality." +msgstr "" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation SHOULD describe the key components or modules of the " +"codebase and their relationships, for example as a high level architectural " +"diagram." +msgstr "" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"There SHOULD be [continuous integration](../glossary.md#continuous-" +"integration) tests for the quality of the documentation." +msgstr "" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"Including examples that make users want to immediately start using the " +"codebase in the documentation of the codebase is OPTIONAL." +msgstr "" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Confirm that other stakeholders, professionals from other public " +"organizations and the general public find the documentation clear and " +"understandable." +msgstr "" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Confirm that the documentation describes how to install and run the source " +"code." +msgstr "" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Confirm that the documentation includes examples of the key functionality." +msgstr "" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Check with members of the general public and journalists if they can " +"understand the high level description." +msgstr "" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Check that the instructions for how to install and run a standalone version " +"of the source code result in a running system." +msgstr "" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "Check that all functionality documented contains an example." +msgstr "" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Check that the documentation includes a high level architectural diagram or " +"similar." +msgstr "" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Check that the documentation quality is part of integration testing, for " +"example documentation is generated correctly, and links and images are " +"tested." +msgstr "" + +#: ./criteria/document-the-code.md:block 12 (unordered list) +msgid "" +"Check in regularly to understand how the non-policy code in the codebase has" +" changed." +msgstr "" + +#: ./criteria/document-the-code.md:block 12 (unordered list) +msgid "Give feedback on how to make non-policy documentation more clear." +msgstr "" + +#: ./criteria/document-the-code.md:block 14 (unordered list) +msgid "" +"Try to use the codebase, so your feedback can improve how clearly the policy" +" and source code are documented. For example, is the current documentation " +"sufficient to persuade a manager at another public organization to use this " +"codebase?" +msgstr "" + +#: ./criteria/document-the-code.md:block 14 (unordered list) +msgid "" +"Make sure you understand both the policy and source code as well as the " +"documentation." +msgstr "" + +#: ./criteria/document-the-code.md:block 16 (unordered list) +msgid "" +"Check in regularly to understand how the non-source code in the codebase has" +" changed." +msgstr "" + +#: ./criteria/document-the-code.md:block 16 (unordered list) +msgid "Give feedback on how to make non-source documentation more clear." +msgstr "" + +#: ./criteria/document-the-code.md:block 18 (unordered list) +msgid "" +"[Documentation guide](https://www.writethedocs.org/guide/) by Write the " +"Docs." +msgstr "" + +#: ./criteria/index.md:block 3 (header) +msgid "order: 0" +msgstr "" + +#: ./criteria/index.md:block 4 (header) +msgid "Criteria" +msgstr "" + +#: ./criteria/index.md:block 5 (paragraph) +msgid "{% assign sorted = site.pages | sort:\"order\" %}" +msgstr "" + +#: ./criteria/index.md:block 6 (paragraph) +msgid "" +"{% for page in sorted %}{% if page.dir == \"/criteria/\" %}{% if page.name " +"!= \"index.md\" %}{% if page.title %}" +msgstr "" + +#: ./criteria/index.md:block 7 (ordered list) +msgid "" +"[{{page.title}}]({{page.url}}){% endif%} {% endif%} {% endif%}{% endfor %}" +msgstr "" + +#: ./criteria/maintain-version-control.md:block 3 (paragraph) +msgid "order: 6 redirect_from:" +msgstr "" + +#: ./criteria/maintain-version-control.md:block 4 (unordered list) +msgid "criteria/version-control-and-history" +msgstr "" + +#: ./criteria/maintain-version-control.md:block 5 (header) +msgid "Maintain version control" +msgstr "" + +#: ./criteria/maintain-version-control.md:block 6 (paragraph) +msgid "" +"[Version control](../glossary.md#version-control) means keeping track of " +"changes to the [source code](../glossary.md#source-code) and other files of " +"the [codebase](../glossary.md#codebase) over time. This allows you to " +"maintain structured documentation of the history of the codebase. This is " +"essential for collaboration at scale, as it enables developers to work on " +"changes in parallel and helps future developers to understand the reasons " +"for changes." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "All files in the codebase MUST be version controlled." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "All decisions MUST be documented in commit messages." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"Every commit message MUST link to discussions and issues wherever possible." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"The codebase SHOULD be maintained in a distributed version control system." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"Contribution guidelines SHOULD require contributors to group relevant " +"changes in commits." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"Maintainers SHOULD mark released versions of the codebase, for example using" +" revision tags or textual labels." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"Contribution guidelines SHOULD encourage file formats where the changes " +"within the files can be easily viewed and understood in the version control " +"system." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"It is OPTIONAL for contributors to sign their commits and provide an email " +"address, so that future contributors are able to contact past contributors " +"with questions about their work." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Confirm that the codebase is kept in version control using software such as " +"Git." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Review the commit history, confirming that all commit messages explain why " +"the change was made." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Review the commit history, confirming that where possible all commit " +"messages include the discussion about the change was or where to find it " +"(with a URL)." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "Check if the version control system is distributed." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Review the commit history, check if grouping of relevant changes in " +"accordance with the contributing guidelines." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Check that it is possible to access a specific version of the codebase, for " +"example through a revision tag or a textual label." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Check that the file formats used in the codebase are text formats where " +"possible." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 12 (unordered list) +msgid "" +"If a new version of the codebase is created because of a " +"[policy](../glossary.md#policy) change, make sure it's clear in the " +"documentation:" +msgstr "" + +#: ./criteria/maintain-version-control.md:block 12 (unordered list) +msgid "what the policy change is," +msgstr "" + +#: ./criteria/maintain-version-control.md:block 12 (unordered list) +msgid "how it's changed the codebase." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 13 (paragraph) +msgid "" +"For example, adding a new category of applicant to a codebase that manages " +"granting permits would be considered a policy change." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 15 (unordered list) +msgid "" +"Support policy makers, developers and designers to be clear about what " +"improvements they're making to the codebase. Making improvements isn't a " +"public relations risk." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "" +"Make sure that all files required to understand the code, build and deploy " +"are in the version control system." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "" +"Write clear commit messages so that it is easy to understand why the commit " +"was made." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "" +"Mark different versions so that it is easy to access a specific version, for" +" example using revision tags or textual labels." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "Write clear commit messages so that versions can be usefully compared." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "" +"Work with policy makers to describe how the source code was updated after a " +"policy change." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 19 (unordered list) +msgid "" +"[Producing OSS: Version Control " +"Vocabulary](https://producingoss.com/en/vc.html#vc-vocabulary) by Karl " +"Fogel." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 19 (unordered list) +msgid "" +"[Maintaining version control in coding](https://www.gov.uk/service-" +"manual/technology/maintaining-version-control-in-coding) by the UK " +"Government Digital Service." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 19 (unordered list) +msgid "" +"[GitHub Skills](https://skills.github.com/) by GitHub for learning how to " +"use GitHub or refresh your skills." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 19 (unordered list) +msgid "" +"[Git Cheat Sheet](https://education.github.com/git-cheat-sheet-" +"education.pdf) by GitHub, a list with the most common used git commands." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 3 (header) +msgid "order: 5" +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 4 (header) +msgid "Make contributing easy" +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 5 (paragraph) +msgid "" +"To develop better, more reliable and feature rich software, users need to be" +" able to fix problems, add features, and address security issues of the " +"shared [codebase](../glossary.md#codebase)." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 6 (paragraph) +msgid "" +"A shared digital infrastructure makes it easier to make collaborative " +"contributions. The less effort it takes to make contributions that are " +"accepted by the codebase, the more likely users are to become contributors." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"The codebase MUST have a public issue tracker that accepts suggestions from " +"anyone." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"The documentation MUST link to both the public issue tracker and submitted " +"codebase changes, for example in a `README` file." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"The codebase MUST have communication channels for users and developers, for " +"example email lists." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"There MUST be a way to report security issues for responsible disclosure " +"over a closed channel." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"The documentation MUST include instructions for how to report potentially " +"security sensitive issues." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "Confirm that there is a public issue tracker." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "" +"Confirm that the codebase contains links to the public issue tracker and " +"submitted codebase changes." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "" +"Confirm that it is possible to participate in a discussion with other users " +"and developers about the software using channels described in the codebase." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "Confirm that there is a closed channel for reporting security issues." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "" +"Confirm that there are instructions for privately reporting security issues." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 12 (unordered list) +msgid "" +"Track [policy](../glossary.md#policy) issues in the codebase, so that a " +"relevant external policy expert can volunteer help." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 14 (unordered list) +msgid "" +"Track management issues in the codebase, so that external managers with " +"relevant experience can volunteer help." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 14 (unordered list) +msgid "" +"Support your experienced policy makers, developers and designers to keep " +"contributing to the codebase for as long as possible." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 16 (unordered list) +msgid "" +"Just like for [reviews](require-review-of-contributions.md), make sure to " +"respond to requests promptly." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 16 (unordered list) +msgid "" +"Keep your managers informed of the time and resources you require to support" +" other contributors." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 16 (unordered list) +msgid "" +"Make sure that appropriate communication channels for asking maintainers and" +" stakeholders questions are easy to locate, for instance in the README." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 16 (unordered list) +msgid "" +"Make sure that appropriate contact details are included in the metadata, for" +" instance in the publiccode.yml file." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 18 (unordered list) +msgid "" +"[How to inspire exceptional contributions to your open-source " +"project](https://dev.to/joelhans/how-to-inspire-exceptional-contributions-" +"to-your-open-source-project-1ebf) by Joel Hans." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 18 (unordered list) +msgid "" +"[The benefits of coding in the open](https://gds.blog.gov.uk/2017/09/04/the-" +"benefits-of-coding-in-the-open/) by the UK Government Digital Service." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 3 (paragraph) +msgid "order: 14 redirect_from:" +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 4 (unordered list) +msgid "criteria/findability" +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 5 (header) +msgid "Make the codebase findable" +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 6 (paragraph) +msgid "" +"The more findable a [codebase](../glossary.md#codebase) is, the more " +"potential new collaborators will find it. Just publishing a codebase and " +"hoping it is found does not work, instead proactiveness is needed." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 7 (paragraph) +msgid "" +"A metadata description file increases discoverability. Well-written metadata" +" containing a unique and persistent identifier, such as a Wikidata item or " +"FSF software directory listing (thus being part of the semantic web), makes " +"the codebase easier for people to refer, cite, disambiguate and discover " +"through third party tools." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The name of the codebase SHOULD be descriptive and free from acronyms, " +"abbreviations, puns or organizational branding." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD have a short description that helps someone understand " +"what the codebase is for or what it does." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "Maintainers SHOULD submit the codebase to relevant software catalogs." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD have a website which describes the problem the codebase " +"solves using the preferred jargon of different potential users of the " +"codebase (including technologists, policy experts and managers)." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD be findable using a search engine by codebase name." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD be findable using a search engine by describing the " +"problem it solves in natural language." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD have a unique and persistent identifier where the entry " +"mentions the major contributors, [repository](../glossary.md#repository) " +"location and website." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD include a machine-readable metadata description, for " +"example in a " +"[publiccode.yml](https://github.com/publiccodeyml/publiccode.yml) file." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "A dedicated domain name for the codebase is OPTIONAL." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "Regular presentations at conferences by the community are OPTIONAL." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "Check that the codebase name is descriptive and free of puns." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase name is free of acronyms and abbreviations or that " +"the acronyms or abbreviations in the name are more universally known than " +"the longer forms." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase name is free of organizational branding, unless that" +" organization is of the codebase community itself." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase repository has a short description of the codebase." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "Check for the codebase listing in relevant software catalogs." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check for a codebase website which describes the problem the codebase " +"solves." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase appears in the results on more than one major search" +" engine when searching by the codebase name." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase appears in the results on more than one major search" +" engine when searching by using natural language, for instance, using the " +"short description." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check unique and persistent identifier entries for mention of the major " +"contributors." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check unique and persistent identifier entries for the repository location." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check unique and persistent identifier entries for the codebase website." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "Check for a machine-readable metadata description file." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 13 (unordered list) +msgid "" +"Contribute a description of the policy area or problem this codebase acts on" +" or operates." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 13 (unordered list) +msgid "" +"Test your problem description with peers outside of your context who aren't " +"familiar with the codebase." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 13 (unordered list) +msgid "" +"Present on how the codebase implements the [policy](../glossary.md#policy) " +"at relevant conferences." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 15 (unordered list) +msgid "" +"Search trademark databases to avoid confusion or infringement before " +"deciding the name." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 15 (unordered list) +msgid "" +"Use the short description wherever the codebase is referenced, for instance," +" as social media account descriptions." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 15 (unordered list) +msgid "" +"Budget for content design and Search Engine Optimization skills in the team." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 15 (unordered list) +msgid "" +"Make sure people involved in the project present at relevant conferences." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 17 (unordered list) +msgid "" +"Search engine optimization, for instance adding a " +"[sitemap](https://www.sitemaps.org/protocol.html)." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 17 (unordered list) +msgid "" +"Use the short description wherever the codebase is referenced, for instance," +" as the repository description." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 17 (unordered list) +msgid "Suggest conferences to present at and present at them." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 19 (unordered list) +msgid "" +"[Introduction to " +"Wikidata](https://www.wikidata.org/wiki/Wikidata:Introduction) by the " +"Wikidata community." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 19 (unordered list) +msgid "" +"[FSF software directory listing](https://directory.fsf.org/wiki/Main_Page) " +"by the Free Software Foundation." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 19 (unordered list) +msgid "" +"The [FAIR Guiding Principles for scientific data management and " +"stewardship](https://www.go-fair.org/fair-principles/) by the GO FAIR " +"International Support and Coordination Office provide a nice list of " +"attributes that make (meta)data more machine actionable (and hence more " +"findable). Some of these apply directly to codebases, while others may " +"provoke exploration into what the codebase equivalent would be." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 3 (paragraph) +msgid "order: 3 redirect_from:" +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 4 (unordered +#: list) +msgid "criteria/reusable-and-portable-codebases" +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 4 (unordered +#: list) +msgid "criteria/create-reusable-and-portable-code" +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 5 (header) +msgid "Make the codebase reusable and portable" +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 6 (paragraph) +msgid "" +"Creating reusable and portable [code](../glossary.md#code) enables policy " +"makers, developers and designers to reuse what has been developed, test it, " +"improve it and contribute those improvements back, leading to better " +"quality, cheaper maintenance and higher reliability." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 7 (paragraph) +msgid "" +"Thoughtfully and purposefully designing a " +"[codebase](../glossary.md#codebase) for reusability allows for the mission, " +"vision and scope of the codebase to be shared by multiple parties. Codebases" +" developed and used by multiple parties are more likely to benefit from a " +"self-sustaining community." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 8 (paragraph) +msgid "" +"Organizing a codebase such that it is composed of well documented modules " +"improves reusability and maintainability. A module is easier to reuse in " +"[another context](../glossary.md#different-contexts) if its purpose is " +"clearly documented." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 9 (paragraph) +msgid "" +"Source code which does not rely on the situation-specific infrastructure of " +"any contributor, vendor or deployment can be tested by any other " +"contributor." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "The codebase MUST be developed to be reusable in different contexts." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"The codebase MUST be independent from any secret, undisclosed, proprietary " +"or non-open licensed software or services for execution and understanding." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "The codebase SHOULD be in use by multiple parties." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "The roadmap SHOULD be influenced by the needs of multiple parties." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"The development of the codebase SHOULD be a collaboration between multiple " +"parties." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"Configuration SHOULD be used to make [source code](../glossary.md#source-" +"code) adapt to context specific needs." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "The codebase SHOULD be localizable." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"Source code and its documentation SHOULD NOT contain situation-specific " +"information." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"Codebase modules SHOULD be documented in such a way as to enable reuse in " +"codebases in other contexts." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"The software SHOULD NOT require services or platforms available from only a " +"single vendor." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Confirm with someone in a similar role at another organization if they can " +"use the codebase and what that would entail." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Confirm that the codebase can run without using any proprietary or non open-" +"licensed software or services." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"If the codebase is in early development before a production-ready release, " +"then check for evidence of ambition to obtain collaborators." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Or if the codebase is very mature and stable with very infrequent fixes, " +"patches, or contributions:" +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Check that the codebase is in use by multiple parties or in multiple " +"contexts." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "Check for documented and budgeted commitments of collaboration." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "Otherwise:" +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "Check that the codebase contributors are from multiple parties." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Check that the codebase files and commit history do not include situation-" +"specific data." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Check that the software can be deployed and run without services or " +"platforms available from a single vendor." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 15 (unordered +#: list) +msgid "" +"Document your [policy](../glossary.md#policy) with enough clarity and detail" +" that it can be understood outside of its original context." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 15 (unordered +#: list) +msgid "Make sure your organization is listed as a known user by the codebase." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 15 (unordered +#: list) +msgid "Identify other organizations for your teams to collaborate with." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 17 (unordered +#: list) +msgid "" +"Make sure that stakeholders and business owners understand that reusability " +"is an explicit codebase goal as this reduces technical debt and provides " +"sustainability for the codebase." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 17 (unordered +#: list) +msgid "Make sure that your teams are collaborating with other teams." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 19 (paragraph) +msgid "Source should be designed:" +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 20 (unordered +#: list) +msgid "for reuse by other users and organizations regardless of locale," +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 20 (unordered +#: list) +msgid "to solve a general problem instead of a specific one," +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 20 (unordered +#: list) +msgid "in logically meaningful and isolated modules," +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 20 (unordered +#: list) +msgid "" +"so that someone in a similar organization facing a similar problem would be " +"able to use (parts of) the solution." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 21 (paragraph) +msgid "" +"Make sure that the codebase documentation describes the build-time and " +"runtime dependencies. If your context requires deploying to proprietary " +"platforms or using proprietary components, make sure that collaborators can " +"develop, use, test, and deploy without them." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 22 (paragraph) +msgid "" +"For each commit, reviewers verify that content does not include situation-" +"specific data such as hostnames, personal and organizational data, or tokens" +" and passwords." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 24 (unordered +#: list) +msgid "" +"[Making source code open and reusable](https://www.gov.uk/service-" +"manual/technology/making-source-code-open-and-reusable) by the UK Government" +" Digital Service." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 24 (unordered +#: list) +msgid "" +"[Localization vs. " +"Internationalization](https://www.w3.org/International/questions/qa-i18n) by" +" the World Wide Web Consortium." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 3 (paragraph) +msgid "order: 13 redirect_from:" +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 4 (unordered list) +msgid "criteria/open-licenses" +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 5 (header) +msgid "Publish with an open license" +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 6 (paragraph) +msgid "" +"An open and well known license makes it possible for anyone to see the " +"[source code](../glossary.md#source-code) in order to understand how it " +"works, to use it freely and to contribute to the " +"[codebase](../glossary.md#codebase). This enables a vendor ecosystem to " +"emerge around the codebase." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 7 (paragraph) +msgid "" +"Clearly indicating the license for each file within a codebase facilitates " +"correct reuse and attribution of parts of a codebase." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"All source code and documentation MUST be licensed such that it may be " +"freely reusable, changeable and redistributable." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"Software source code MUST be licensed under an [OSI-approved or FSF " +"Free/Libre license](https://spdx.org/licenses/)." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "All source code MUST be published with a license file." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"Contributors MUST NOT be required to transfer copyright of their " +"contributions to the codebase." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"All source code files in the codebase SHOULD include a copyright notice and " +"a license header that are machine-readable." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"Having multiple licenses for different types of source code and " +"documentation is OPTIONAL." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "Confirm that the codebase is clearly licensed." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "" +"Confirm that the license for the source code is on the [OSI-approved or FSF " +"Free/Libre license list](https://spdx.org/licenses/) and the license for " +"documentation [conforms to the Open " +"Definition](https://opendefinition.org/licenses/)." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "Confirm that the licenses used in the codebase are included as files." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "" +"Confirm that contribution guidelines and " +"[repository](../glossary.md#repository) configuration do not require " +"transfer of copyright." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "" +"Check for machine-readable license checking in the codebase [continuous " +"integration](../glossary.md#continuous-integration) tests." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 13 (unordered list) +msgid "" +"Develop [policy](../glossary.md#policy) that requires source code to be " +"[open source](../glossary.md#open-source)." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 13 (unordered list) +msgid "" +"Develop policy that disincentivizes non-open source code and technology in " +"procurement." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 15 (unordered list) +msgid "" +"Only work with open source vendors that deliver their source code by " +"publishing it under an open source license." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 15 (unordered list) +msgid "" +"Beware that even though [Creative Commons " +"licenses](https://creativecommons.org/licenses/) are great for " +"documentation, licenses that stipulate Non-Commercial or No Derivatives are " +"NOT freely reusable, changeable and redistributable and don't fulfill these " +"requirements." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 17 (unordered list) +msgid "Add a new `license` file to every new codebase created." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 17 (unordered list) +msgid "" +"Add a copyright notice and a license header to every new source code file " +"created." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 17 (unordered list) +msgid "" +"When source code is being reused by the codebase, make sure that it has a " +"license that is compatible with the license or licenses of the codebase." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 19 (unordered list) +msgid "" +"[Open source definition](https://opensource.org/osd) by the Open Source " +"Initiative, all open source licenses meet this definition." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 19 (unordered list) +msgid "" +"[Animated video introduction to Creative " +"Commons](https://creativecommons.org/about/videos/creative-commons-kiwi) by " +"Creative Commons Aotearoa New Zealand." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 19 (unordered list) +msgid "" +"[REUSE Initiative specification](https://reuse.software/spec/) by Free " +"Software Foundation Europe for unambiguous, human-readable and machine-" +"readable copyright and licensing information." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 19 (unordered list) +msgid "" +"[SPDX License List](https://spdx.org/licenses/) by the Linux Foundation with" +" standardized, machine-readable abbreviations for most licenses." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 3 (paragraph) +msgid "order: 7 redirect_from:" +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 4 (unordered list) +msgid "criteria/require-review" +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 5 (header) +msgid "Require review of contributions" +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 6 (paragraph) +msgid "" +"Peer-review of contributions is essential for [source " +"code](../glossary.md#source-code) quality, reducing security risks and " +"operational risks." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 7 (paragraph) +msgid "" +"Requiring thorough review of contributions encourages a culture of making " +"sure every contribution is of high quality, completeness and value. Source " +"code review increases the chance of discovering and fixing potential bugs or" +" mistakes before they are added to the [codebase](../glossary.md#codebase). " +"Knowing that all source code was reviewed discourages a culture of blaming " +"individuals, and encourages a culture of focusing on solutions." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 8 (paragraph) +msgid "" +"A [policy](../glossary.md#policy) of prompt reviews assures contributors of " +"a guaranteed time for feedback or collaborative improvement, which increases" +" both rate of delivery and contributor engagement." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"All contributions that are accepted or committed to release versions of the " +"codebase MUST be reviewed by another contributor." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "Reviews MUST include source, policy, tests and documentation." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"Reviewers MUST provide feedback on all decisions to not accept a " +"contribution." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"The review process SHOULD confirm that a contribution conforms to the " +"standards, architecture and decisions set out in the codebase in order to " +"pass review." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"Reviews SHOULD include running both the software and the tests of the " +"codebase." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"Contributions SHOULD be reviewed by someone in a different context than the " +"contributor." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"Version control systems SHOULD NOT accept non-reviewed contributions in " +"release versions." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "Reviews SHOULD happen within two business days." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "Performing reviews by multiple reviewers is OPTIONAL." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "" +"Confirm that every commit in the history has been reviewed by a different " +"contributor." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "Confirm that reviews include source, policy, tests and documentation." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "Confirm that rejected contributions were appropriately explained." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "" +"Check if guidelines for reviewers include instructions to review for " +"conformance to standards, architecture and codebase guidelines." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "Check with reviewers if they run the software and tests during review." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "" +"Check with reviewers if commits have been reviewed by a different " +"contributor in a different context." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "" +"Check for use of branch protection in the [version " +"control](../glossary.md#version-control) system." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "Check the times between contribution submission and review." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 14 (unordered list) +msgid "" +"Institute a 'four eyes' policy where everything, not just source code, is " +"reviewed." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 14 (unordered list) +msgid "" +"Use a version control system or methodology that enables review and " +"feedback." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 16 (unordered list) +msgid "Make delivering great software a shared objective." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 16 (unordered list) +msgid "" +"Make sure writing and reviewing contributions to source, policy, " +"documentation and tests are considered equally valuable." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 16 (unordered list) +msgid "" +"Create a culture where all contributions are welcome and everyone is " +"empowered to review them." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 16 (unordered list) +msgid "Make sure no contributor is ever alone in contributing to a codebase." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 18 (unordered list) +msgid "" +"Ask other contributors on the codebase to review your work, in your " +"organization or outside of it." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 18 (unordered list) +msgid "" +"Try to respond to others' requests for review promptly, initially providing " +"feedback about the concept of the change." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 20 (unordered list) +msgid "" +"[How to review code the GDS way](https://gds-" +"way.cloudapps.digital/manuals/code-review-guidelines.html#content) by the UK" +" Government Digital Service." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 20 (unordered list) +msgid "" +"Branch protection on " +"[GitHub](https://docs.github.com/en/repositories/configuring-branches-and-" +"merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-" +"protected-branches) and " +"[GitLab](https://about.gitlab.com/blog/2014/11/26/keeping-your-code-" +"protected/)." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 20 (unordered list) +msgid "" +"[The Gentle Art of Patch Review](https://sage.thesharps.us/2014/09/01/the-" +"gentle-art-of-patch-review/) by Sage Sharp." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 20 (unordered list) +msgid "" +"[Measuring " +"Engagement](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-" +"mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) by Mozilla." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 3 (paragraph) +msgid "order: 15 redirect_from:" +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 4 (unordered list) +msgid "criteria/style" +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 5 (header) +msgid "Use a coherent style" +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 6 (paragraph) +msgid "" +"Following a consistent and coherent style enables contributors in different " +"environments to work together. Unifying vocabularies reduces friction in " +"communication between contributors." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 8 (unordered list) +msgid "" +"The [codebase](../glossary.md#codebase) MUST use a coding or writing style " +"guide, either the codebase community's own or an existing one referred to in" +" the codebase." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 8 (unordered list) +msgid "Contributions SHOULD pass automated tests on style." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 8 (unordered list) +msgid "" +"The style guide SHOULD include expectations for inline comments and " +"documentation for non-trivial sections." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 8 (unordered list) +msgid "" +"Including expectations for [understandable English](use-plain-english.md) in" +" the style guide is OPTIONAL." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 10 (unordered list) +msgid "" +"Confirm that contributions are in line with the style guides specified in " +"the documentation." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 10 (unordered list) +msgid "Check for the presence of automated tests on style." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 12 (unordered list) +msgid "" +"Create, follow and continually improve on a style guide for " +"[policy](../glossary.md#policy) and documentation as well as document this " +"in the codebase, for example in the `CONTRIBUTING` or `README`." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 14 (unordered list) +msgid "" +"Include written language, source, test and policy standards in your " +"organizational definition of quality." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 16 (paragraph) +msgid "" +"If the codebase does not already have engineering guidelines or other " +"contributor guidance, start by adding documentation to the " +"[repository](../glossary.md#repository) describing whatever is being done " +"now, for example in the `CONTRIBUTING` or `README`. An important purpose of " +"the file is to communicate design preferences, naming conventions, and other" +" aspects machines can't easily check. Guidance should include what would be " +"expected from [source code](../glossary.md#source-code) contributions in " +"order for them to be merged by the maintainers, including source, tests and " +"documentation. Continually improve upon and expand this documentation with " +"the aim of evolving this documentation into engineering guidelines." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 17 (paragraph) +msgid "Additionally:" +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 18 (unordered list) +msgid "Use a linter." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 18 (unordered list) +msgid "Add linter configurations to the codebase." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 20 (unordered list) +msgid "" +"[Programming style](https://en.wikipedia.org/wiki/Programming_style) on " +"Wikipedia." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 3 (paragraph) +msgid "order: 12 redirect_from:" +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 4 (unordered list) +msgid "criteria/continuous-integration" +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 5 (header) +msgid "Use continuous integration" +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 6 (paragraph) +msgid "" +"Asynchronous collaboration is enabled by developers merging their work to a " +"shared branch frequently, verified by automated tests. The more frequent the" +" merging and the smaller the contribution, the easier it is to resolve merge" +" conflicts." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 7 (paragraph) +msgid "" +"Automated testing of all functionality provides confidence that " +"contributions are working as intended and have not introduced errors, and " +"allows reviewers to focus on the structure and approach of the contribution." +" The more focused the test, the easier it is to clearly identify and " +"understand errors as they arise." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 8 (paragraph) +msgid "" +"Documenting a codebase's [continuous integration](../glossary.md#continuous-" +"integration) workflow helps contributors understand the expectations of " +"contributions. Continuous integration allows for an easier monitoring of the" +" state of the [codebase](../glossary.md#codebase)." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"All functionality in the [source code](../glossary.md#source-code) MUST have" +" automated tests." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"Contributions MUST pass all automated tests before they are admitted into " +"the codebase." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"The codebase MUST have guidelines explaining how to structure contributions." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"The codebase MUST have active contributors who can review contributions." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "Automated test results for contributions SHOULD be public." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"The codebase guidelines SHOULD state that each contribution should focus on " +"a single issue." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "Source code test and documentation coverage SHOULD be monitored." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"Testing [policy](../glossary.md#policy) and documentation for consistency " +"with the source and vice versa is OPTIONAL." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"Testing policy and documentation for style and broken links is OPTIONAL." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"Testing the software by using examples in the documentation is OPTIONAL." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "Confirm that there are tests present." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "" +"Confirm that source code coverage tools check that coverage is at 100% of " +"the source code." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "" +"Confirm that contributions are only admitted into the codebase after all of " +"the tests are passed." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "" +"Confirm that contribution guidelines explain how to structure contributions." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "" +"Confirm that there are contributions from within the last three months." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "Check that test results are viewable." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "Check if source code coverage data is published." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 14 (unordered list) +msgid "" +"Involve managers as well as developers and designers as early in the process" +" as possible and keep them engaged throughout development of your policy." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 14 (unordered list) +msgid "" +"Make sure there are also automated tests set up for policy documentation." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 14 (unordered list) +msgid "Fix policy documentation promptly if it fails a test." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 14 (unordered list) +msgid "" +"Make sure the source code reflects any changes to the policy (see [Maintain " +"version control](maintain-version-control.md))." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 16 (unordered list) +msgid "" +"Make sure to test with real end users as quickly and often as possible." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 16 (unordered list) +msgid "" +"Plan the work to integrate small parts very often instead of large parts " +"less frequently." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 16 (unordered list) +msgid "" +"Procure consultancy services that deliver incrementally aligned with the " +"plan." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 16 (unordered list) +msgid "" +"After a large failure, encourage publication of incident reports and public " +"discussion of what was learned." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Help managers structure the work plan such that it can be integrated as " +"small increments." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Help contributors limit the scope of their contributions and feature " +"requests to be as small as reasonable." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Help managers and policy makers test their contributions, for example by " +"testing their contributions for broken links or style." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Structure source code written to handle conditions which are difficult to " +"create in a test environment in such a way that the conditions can be " +"simulated during testing. Forms of resource exhaustion such as running out " +"of storage space and memory allocation failure are typical examples of " +"difficult to create conditions." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Tune the test code coverage tools to avoid false alarms resulting from " +"inlining or other optimizations." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "Deploy often." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "Integrate your work at least once a day." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 20 (unordered list) +msgid "" +"[What is continuous " +"integration](https://www.martinfowler.com/articles/continuousIntegration.html)" +" by Martin Fowler." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 20 (unordered list) +msgid "" +"[Use continuous delivery](https://gds-" +"way.cloudapps.digital/standards/continuous-delivery.html) by the UK " +"Government Digital Service." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 20 (unordered list) +msgid "" +"[Quality assurance: testing your service " +"regularly](https://www.gov.uk/service-manual/technology/quality-assurance-" +"testing-your-service-regularly) by the UK Government Digital Service." +msgstr "" + +#: ./criteria/use-open-standards.md:block 3 (paragraph) +msgid "order: 11 redirect_from:" +msgstr "" + +#: ./criteria/use-open-standards.md:block 4 (unordered list) +msgid "criteria/open-standards" +msgstr "" + +#: ./criteria/use-open-standards.md:block 5 (header) +msgid "Use open standards" +msgstr "" + +#: ./criteria/use-open-standards.md:block 6 (paragraph) +msgid "" +"[Open standards](../glossary.md#open-standard) guarantee access to the " +"knowledge required to use and contribute to the " +"[codebase](../glossary.md#codebase). They enable interoperability between " +"systems and reduce the risk of vendor lock-in. Open standards which are " +"unambiguous allow for independent development of either side of data " +"exchange." +msgstr "" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"For features of the codebase that facilitate the exchange of data the " +"codebase MUST use an open standard that meets the [Open Source Initiative " +"Open Standard Requirements](https://opensource.org/osr)." +msgstr "" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Any non-open standards used MUST be recorded clearly as such in the " +"documentation." +msgstr "" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Any standard chosen for use within the codebase MUST be listed in the " +"documentation with a link to where it is available." +msgstr "" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Any non-open standards chosen for use within the codebase MUST NOT hinder " +"collaboration and reuse." +msgstr "" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"If no existing open standard is available, effort SHOULD be put into " +"developing one." +msgstr "" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Open standards that are machine testable SHOULD be preferred over open " +"standards that are not." +msgstr "" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Non-open standards that are machine testable SHOULD be preferred over non-" +"open standards that are not." +msgstr "" + +#: ./criteria/use-open-standards.md:block 10 (unordered list) +msgid "Confirm that data exchange follows an OSI approved open standard." +msgstr "" + +#: ./criteria/use-open-standards.md:block 10 (unordered list) +msgid "" +"Confirm that any non-open standards used are clearly documented as such." +msgstr "" + +#: ./criteria/use-open-standards.md:block 10 (unordered list) +msgid "" +"Confirm that documentation includes a list of the standards followed within " +"the codebase, each with a working link, or a statement that no standards " +"were chosen." +msgstr "" + +#: ./criteria/use-open-standards.md:block 12 (unordered list) +msgid "Mandate use of open standards everywhere possible." +msgstr "" + +#: ./criteria/use-open-standards.md:block 12 (unordered list) +msgid "Prohibit procurement of technology that does not use open standards." +msgstr "" + +#: ./criteria/use-open-standards.md:block 14 (unordered list) +msgid "" +"Consider including open standard compliance assessment in [source " +"code](../glossary.md#source-code) reviews." +msgstr "" + +#: ./criteria/use-open-standards.md:block 16 (unordered list) +msgid "" +"Add [continuous integration](../glossary.md#continuous-integration) tests " +"for compliance with the standards." +msgstr "" + +#: ./criteria/use-open-standards.md:block 16 (unordered list) +msgid "" +"Review the commits and other [repository](../glossary.md#repository) " +"resources for references to standards and cross-check those with the " +"standards listed." +msgstr "" + +#: ./criteria/use-open-standards.md:block 18 (unordered list) +msgid "" +"[Open Standards principles](https://www.gov.uk/government/publications/open-" +"standards-principles/open-standards-principles), " +"[policy](../glossary.md#policy) paper of the UK Cabinet Office." +msgstr "" + +#: ./criteria/use-plain-english.md:block 3 (paragraph) +msgid "order: 10 redirect_from:" +msgstr "" + +#: ./criteria/use-plain-english.md:block 4 (unordered list) +msgid "criteria/understandable-english-first" +msgstr "" + +#: ./criteria/use-plain-english.md:block 5 (header) +msgid "Use plain English" +msgstr "" + +#: ./criteria/use-plain-english.md:block 6 (paragraph) +msgid "" +"English is the de facto language of collaboration in software " +"development." +msgstr "" + +#: ./criteria/use-plain-english.md:block 7 (paragraph) +msgid "" +"Public sector information needs to be accessible to all its constituents. " +"Plain and simple language makes the [code](../glossary.md#code) and what it " +"does easier to understand for a wider variety of people." +msgstr "" + +#: ./criteria/use-plain-english.md:block 8 (paragraph) +msgid "" +"Translations further increase the possible reach of a " +"[codebase](../glossary.md#codebase). Language that is easy to understand " +"lowers the cost of creating and maintaining translations." +msgstr "" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "All codebase documentation MUST be in English." +msgstr "" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"All [source code](../glossary.md#source-code) MUST be in English, except " +"where [policy](../glossary.md#policy) is machine interpreted as code." +msgstr "" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"All bundled policy not available in English MUST have an accompanying " +"summary in English." +msgstr "" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"Any translation MUST be up to date with the English version and vice versa." +msgstr "" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"There SHOULD be no acronyms, abbreviations, puns or legal/non-English/domain" +" specific terms in the codebase without an explanation preceding it or a " +"link to an explanation." +msgstr "" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"Documentation SHOULD aim for a lower secondary education reading level, as " +"recommended by the [Web Content Accessibility Guidelines " +"2](https://www.w3.org/WAI/WCAG21/quickref/?showtechniques=315#readable)." +msgstr "" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"Providing a translation of any code, documentation or tests is OPTIONAL." +msgstr "" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "Confirm that codebase documentation is available in English." +msgstr "" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "" +"Confirm that source code is in English, or confirm any non-English is policy" +" or terms with preceding explanations." +msgstr "" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "Confirm any non-English policy has an accompanying summary in English." +msgstr "" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "" +"Confirm that translations and the English version have the same content." +msgstr "" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "" +"Check that no unexplained acronyms, abbreviations, puns or legal/non-" +"English/domain specific terms are in the documentation." +msgstr "" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "Check the spelling, grammar and readability of the documentation." +msgstr "" + +#: ./criteria/use-plain-english.md:block 14 (unordered list) +msgid "" +"Frequently test with other managers, developers and designers in the process" +" if they understand what you are delivering and how you document it." +msgstr "" + +#: ./criteria/use-plain-english.md:block 16 (unordered list) +msgid "" +"Try to limit the use of acronyms, abbreviations, puns or legal/non-" +"English/domain specific terms in internal communications in and between " +"teams and stakeholders. Add any such terms to a glossary and link to it from" +" the places they are being used." +msgstr "" + +#: ./criteria/use-plain-english.md:block 16 (unordered list) +msgid "" +"Be critical of documentation and descriptions in proposals and changes. If " +"you don't understand something, others will probably also struggle with it." +msgstr "" + +#: ./criteria/use-plain-english.md:block 18 (unordered list) +msgid "" +"Frequently test with policy makers and managers if they understand what you " +"are delivering and how you document it." +msgstr "" + +#: ./criteria/use-plain-english.md:block 18 (unordered list) +msgid "" +"Ask someone outside of your context if they understand the content (for " +"example, a developer working on a different codebase)." +msgstr "" + +#: ./criteria/use-plain-english.md:block 20 (unordered list) +msgid "" +"Meeting the [Web Content Accessibility Guidelines 2.1, Guideline 3.1 " +"Readable](https://www.w3.org/TR/WCAG21/#readable) by W3C makes text content " +"readable and understandable." +msgstr "" + +#: ./criteria/use-plain-english.md:block 20 (unordered list) +msgid "" +"The[European Union accessibility directive](https://ec.europa.eu/digital-" +"single-market/en/web-accessibility) by the European Commission, is an " +"example of regulation requiring high accessibility." +msgstr "" + +#: ./criteria/use-plain-english.md:block 20 (unordered list) +msgid "" +"[Definition of plain " +"language](https://www.plainlanguage.gov/about/definitions/) by United States" +" General Services Administration." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 3 (paragraph) +msgid "order: 4 redirect_from:" +msgstr "" + +#: ./criteria/welcome-contributors.md:block 4 (unordered list) +msgid "criteria/open-to-contributions" +msgstr "" + +#: ./criteria/welcome-contributors.md:block 5 (header) +msgid "Welcome contributors" +msgstr "" + +#: ./criteria/welcome-contributors.md:block 6 (paragraph) +msgid "" +"The atmosphere in a [codebase](../glossary.md#codebase) community helps " +"users decide to use one codebase over another. Welcoming anyone as a " +"contributor enables the community to grow and sustain itself over time. A " +"community where contributors have clear ways to influence codebase and " +"community goals and progress is less likely to split and end up in diverging" +" communities. Newcomers need to understand and trust the codebase " +"community’s governance." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The codebase MUST allow anyone to submit suggestions for changes to the " +"codebase." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The codebase MUST include contribution guidelines explaining what kinds of " +"contributions are welcome and how contributors can get involved, for example" +" in a `CONTRIBUTING` file." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The codebase MUST document the governance of the codebase, contributions and" +" its community, for example in a `GOVERNANCE` file." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The contribution guidelines SHOULD document who is expected to cover the " +"costs of reviewing contributions." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The codebase SHOULD advertise the committed engagement of involved " +"organizations in the development and maintenance." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "The codebase SHOULD have a publicly available roadmap." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "The codebase SHOULD publish codebase activity statistics." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"Including a code of conduct for contributors in the codebase is OPTIONAL." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "" +"Confirm that it is possible to submit suggestions for changes to the " +"codebase." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Confirm there are contribution guidelines." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "" +"Confirm that the codebase governance is clearly explained, including how to " +"influence codebase governance." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "" +"Check that contributing guidelines cover who is expected to cover the costs " +"of reviewing contributions." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Check for a list of involved organizations." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Check for a roadmap." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Check for published activity statistics." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Check for a code of conduct." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 12 (unordered list) +msgid "" +"Add a list to the codebase of any other resources that " +"[policy](../glossary.md#policy) experts, non-governmental organizations and " +"academics would find useful for understanding or reusing your policy." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 12 (unordered list) +msgid "" +"Consider adding contact details so that other policy makers considering " +"collaboration can ask you for advice." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"Make sure that the documentation of the governance includes the current " +"process for how to make changes to the governance." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"If the community has some consensus about how the governance should change, " +"then include those ideas stated as ambitions in the documentation." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"If needed, make sure you have allocated budget for the contributions review " +"process as agreed by the codebase community." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"Make sure the documentation explains how each organization is involved in " +"the codebase, what resources it has available for it and for how long." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"Support your experienced policy makers, developers and designers to stay " +"part of the community for as long as possible." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 16 (unordered list) +msgid "Respond promptly to requests." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 16 (unordered list) +msgid "" +"Communicate clearly to contributors what they need to do make sure their " +"contribution can be integrated." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 18 (unordered list) +msgid "" +"[Building welcoming communities](https://opensource.guide/building-" +"community/) by Open Source Guides." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 18 (unordered list) +msgid "" +"[The Open Source Contributor Funnel](https://mikemcquaid.com/2018/08/14/the-" +"open-source-contributor-funnel-why-people-dont-contribute-to-your-open-" +"source-project/) by Mike McQuaid." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 18 (unordered list) +msgid "" +"[Leadership and governance](https://opensource.guide/leadership-and-" +"governance/) for growing [open source](../glossary.md#open-source) community" +" projects, by Open Source Guides." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 18 (unordered list) +msgid "" +"[Building online communities](http://hintjens.com/blog:117) by Pieter " +"Hintjens (long read!)." +msgstr "" + +#: ./docs/printing.md:block 1 (header) +msgid "Printing" +msgstr "" + +#: ./docs/printing.md:block 3 (paragraph) +msgid "" +"The printed Standard for Public Code is printed by Reclameland. This guide " +"tries to provide the relevant information to print it there or somewhere " +"else." +msgstr "" + +#: ./docs/printing.md:block 4 (paragraph) +msgid "" +"Details, mostly in order they are on the Reclameland page with the Dutch if " +"necessary:" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "" +"Form: Softcover book ([Reclameland product " +"page](https://www.reclameland.nl/drukken/softcover-boeken))" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Format: A4" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Portrait or landscape: Portrait (Staand)" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Printing inside: 4/4 dual sided full color" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Inside material: 90 grams biotop" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Cover: 350 grams cover" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Printing cover: 4/0 one sided full cover" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Cover treatment: one sided matt foliated (Enke)" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "" +"Pages: pages of the inside + 4 + x, where x is 0-3 so that the sum becomes a" +" multiple of 4" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Individually sealed: no" +msgstr "" + +#: ./docs/printing.md:block 6 (paragraph) +msgid "" +"When these details are chosen, the cover and insides are uploaded and the " +"order is placed payment can happen (payment ahead) after which printing " +"starts." +msgstr "" + +#: ./docs/releasing.md:block 1 (header) +msgid "Releasing a new version of the Standard for public code" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Review state of the 'develop' branch" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Ensure all changes intended for release are merged" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Invite a proofread of the current state of the branch" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"If new dashes are introduced, check if the language can be simplified to " +"remove them in favor of more simple sentences. If a complex sentence is " +"needed, see if the dash can be replaced with other punctuation. If a dash is" +" truly the best expression of ideas, then follow the [Chicago Manual of " +"Style](https://en.wikipedia.org/wiki/Dash#En_dash_versus_em_dash)." +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Create a release branch" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "From 'develop', `git switch -c \"release-$MAJOR.$MINOR.$PATCH\"`" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Push the branch, `git push -u origin release-$MAJOR.$MINOR.$PATCH`" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update the new release" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update [`AUTHORS.md`](../AUTHORS.md) with new contributors" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update [`CHANGELOG.md`](../CHANGELOG.md)" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update [`roadmap.md`](roadmap.md)" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Perform extra pass on diff to the 'main' branch" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"run `script/generate-review-template.sh` and commit updated `docs/review-" +"template.html`" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"update `docs/standard-for-public-code.html` with the new text from the " +"review template, updating any status changes as a result" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Reread any section or paragraph to ensure wording changes still fit the " +"whole and do not contain grammar or spelling errors" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Ensure [fonts](https://brand.publiccode.net/typography/) are installed, see:" +" `script/ensure-font.sh`" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Check the rendered `.pdf` using `script/pdf.sh rc1`" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Ensure no link collisions exist" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Check the page breaks, possibly removing or adding page-break CSS, for " +"example: `

`" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "If needed, commit fixes and repeat extra pass" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Push branch, compare with 'main' branch, i.e.: " +"`https://github.com/publiccodenet/standard/compare/main...release-$MAJOR.$MINOR.$PATCH`" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Request review from multiple reviewers, especially a proofreader" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Reviewers will create issues for shortcomings found which would not prevent " +"release" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"If needed for release, reviewers may create pull requests to resolve issues" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Re-request reviews if additional pull requests are merged into release " +"branch" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Run the to-archive-org.sh script" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Create GitHub release with the release notes and version number" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "`git tag trigger-$MAJOR.$MINOR.$PATCH`" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "`git push --tags` (see: `../.github/workflows/release-on-tag.yml`)" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "delete local tag: `git tag -d trigger-$MAJOR.$MINOR.$PATCH`" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "[Send the files for print to the printer](printing.md)" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Cover file" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Inside pages PDF" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Ping [translation](https://github.com/publiccodenet/community-translations-" +"standard) contributors" +msgstr "" + +#: ./docs/roadmap.md:block 1 (header) +msgid "Roadmap" +msgstr "" + +#: ./docs/roadmap.md:block 3 (paragraph) +msgid "Last updated: 2023-03-08" +msgstr "" + +#: ./docs/roadmap.md:block 4 (paragraph) +msgid "" +"This document intends to shed light on the current development plans of the " +"team. Plans change constantly as new information is absorbed by the team." +msgstr "" + +#: ./docs/roadmap.md:block 5 (paragraph) +msgid "" +"Codebase stewards review the roadmap monthly as part of our [backlog pruning" +" session](https://about.publiccode.net/activities/standard-" +"maintenance/backlog-pruning.html)." +msgstr "" + +#: ./docs/roadmap.md:block 6 (header) +msgid "Current work" +msgstr "" + +#: ./docs/roadmap.md:block 7 (unordered list) +msgid "As far as possible, make the standard Standard-compliant" +msgstr "" + +#: ./docs/roadmap.md:block 7 (unordered list) +msgid "Certification badges" +msgstr "" + +#: ./docs/roadmap.md:block 8 (header) +msgid "Near term" +msgstr "" + +#: ./docs/roadmap.md:block 9 (unordered list) +msgid "Separate executive summary (issue #302)" +msgstr "" + +#: ./docs/roadmap.md:block 9 (unordered list) +msgid "Physical paper checklist" +msgstr "" + +#: ./docs/roadmap.md:block 9 (unordered list) +msgid "Possibly: add in the illustrations for each criterion" +msgstr "" + +#: ./docs/roadmap.md:block 10 (header) +msgid "Longer term" +msgstr "" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "" +"Add to README and index.md information (and eventually statistics) on " +"adoption and use (issue #438)" +msgstr "" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Becoming validated by multiple codebases" +msgstr "" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Release version 1.0.0 after a few codebases are compliant" +msgstr "" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Linkable requirements" +msgstr "" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "New cover art" +msgstr "" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Register for ISBN" +msgstr "" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "List with an on-demand book printing service" +msgstr "" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "QR codes for external links in print version" +msgstr "" + +#: ./foreword.md:block 3 (paragraph) +msgid "redirect_from:" +msgstr "" + +#: ./foreword.md:block 4 (unordered list) +msgid "introduction" +msgstr "" + +#: ./foreword.md:block 5 (header) +msgid "Foreword" +msgstr "" + +#: ./foreword.md:block 6 (paragraph) +msgid "" +"The Standard for Public Code is a set of criteria that support public " +"organizations in developing and maintaining software and policy together." +msgstr "" + +#: ./foreword.md:block 7 (paragraph) +msgid "" +"Anyone developing public-purpose software or policy can use this standard to" +" work towards higher quality public services that are more cost effective, " +"with less risk and more control." +msgstr "" + +#: ./foreword.md:block 8 (paragraph) +msgid "" +"This foreword introduces the term public code and explains why this is " +"important." +msgstr "" + +#: ./foreword.md:block 9 (header) +msgid "Definition of public code" +msgstr "" + +#: ./foreword.md:block 10 (paragraph) +msgid "" +"Public code is both computer source code (such as software and algorithms) " +"and public policy executed in a public context, by humans or machines. It " +"encompasses the software built to operate with and as public infrastructure," +" along with the arrangements for its production. Public code is explicitly " +"distinct from regular software because it operates under fundamentally " +"different circumstances and expectations." +msgstr "" + +#: ./foreword.md:block 11 (header) +msgid "Reasons for public code" +msgstr "" + +#: ./foreword.md:block 12 (paragraph) +msgid "There are many reasons for why public code is relevant now." +msgstr "" + +#: ./foreword.md:block 13 (header) +msgid "Software code == legal code" +msgstr "" + +#: ./foreword.md:block 14 (paragraph) +msgid "Software is public infrastructure." +msgstr "" + +#: ./foreword.md:block 15 (paragraph) +msgid "" +"In the 21st century, software can be considered vital public infrastructure." +" It is increasingly not just the expression of existing policy but the " +"originator of new policy, for example where algorithms decide which " +"districts need extra social services or policing." +msgstr "" + +#: ./foreword.md:block 16 (paragraph) +msgid "" +"Software mechanics, algorithms and data collection have become key elements " +"in the execution of public policies. Computer code now executes policies " +"that have been codified in legal code through democratic procedures. Both " +"forms of code set conditions for society to function according to " +"democratically set public values, the latter executed by humans, the former " +"by machines. In other words, software code has increasingly started to equal" +" legal code." +msgstr "" + +#: ./foreword.md:block 17 (paragraph) +msgid "" +"Software should therefore be subject to the principles of democratic " +"governance." +msgstr "" + +#: ./foreword.md:block 18 (header) +msgid "Traditional public software procurement" +msgstr "" + +#: ./foreword.md:block 19 (paragraph) +msgid "" +"Current public software production methods have not served public service " +"delivery very well." +msgstr "" + +#: ./foreword.md:block 20 (paragraph) +msgid "" +"In the last decade, public organizations that purchased complete software " +"solutions have sometimes been surprised to discover that they:" +msgstr "" + +#: ./foreword.md:block 21 (unordered list) +msgid "" +"can’t change their software to reflect changing policy or take advantage of " +"new technology" +msgstr "" + +#: ./foreword.md:block 21 (unordered list) +msgid "" +"don’t have access to their data as it's locked into proprietary systems" +msgstr "" + +#: ./foreword.md:block 21 (unordered list) +msgid "are asked to pay ever increasing license fees" +msgstr "" + +#: ./foreword.md:block 22 (header) +msgid "Technological sovereignty and democratic accountability" +msgstr "" + +#: ./foreword.md:block 23 (paragraph) +msgid "Public institutions, civil servants and residents deserve better." +msgstr "" + +#: ./foreword.md:block 24 (paragraph) +msgid "" +"We believe the software that runs our society can no longer be a black box, " +"controlled by outside companies that keep the underlying logic on which " +"their software operates hidden in proprietary codebases. Instead, " +"governments and the people they serve need technological sovereignty. This " +"allows them to set and control the functioning of public software, just like" +" they are able to set and control policy that is legally formulated in laws." +" Citizens and civil society actors need this software to be transparent and " +"accountable." +msgstr "" + +#: ./foreword.md:block 25 (paragraph) +msgid "" +"The design of software as essential civic infrastructure should honor " +"digital citizens’ rights." +msgstr "" + +#: ./foreword.md:block 26 (header) +msgid "Designing truly public software" +msgstr "" + +#: ./foreword.md:block 27 (paragraph) +msgid "" +"Public code is at the core of modern public institutions, shapes the work of" +" civil servants and affects the lives of almost all residents." +msgstr "" + +#: ./foreword.md:block 28 (paragraph) +msgid "Public software must therefore be:" +msgstr "" + +#: ./foreword.md:block 29 (unordered list) +msgid "transparent" +msgstr "" + +#: ./foreword.md:block 29 (unordered list) +msgid "accountable" +msgstr "" + +#: ./foreword.md:block 29 (unordered list) +msgid "understandable for its constituents" +msgstr "" + +#: ./foreword.md:block 30 (paragraph) +msgid "" +"It must reflect the values of the society it serves, for example by being " +"inclusive and non-discriminatory." +msgstr "" + +#: ./foreword.md:block 31 (paragraph) +msgid "" +"Most proprietary software systems currently used by public organizations do " +"not meet these requirements. Public code does." +msgstr "" + +#: ./foreword.md:block 32 (header) +msgid "Values of public code" +msgstr "" + +#: ./foreword.md:block 33 (paragraph) +msgid "We consider public code to have these core values:" +msgstr "" + +#: ./foreword.md:block 34 (unordered list) +msgid "Inclusive" +msgstr "" + +#: ./foreword.md:block 34 (unordered list) +msgid "Usable" +msgstr "" + +#: ./foreword.md:block 34 (unordered list) +msgid "Open" +msgstr "" + +#: ./foreword.md:block 34 (unordered list) +msgid "Legible" +msgstr "" + +#: ./foreword.md:block 34 (unordered list) +msgid "Accountable" +msgstr "" + +#: ./foreword.md:block 34 (unordered list) +msgid "Accessible" +msgstr "" + +#: ./foreword.md:block 34 (unordered list) +msgid "Sustainable" +msgstr "" + +#: ./foreword.md:block 35 (header) +msgid "How public code works" +msgstr "" + +#: ./foreword.md:block 36 (paragraph) +msgid "" +"Public code is open source software meant for fulfilling the essential role " +"of public organizations. Through use, other administrations contribute back " +"to the software, so that its development and maintenance become truly " +"collaborative." +msgstr "" + +#: ./foreword.md:block 37 (paragraph) +msgid "Being open unlocks many other things." +msgstr "" + +#: ./foreword.md:block 38 (paragraph) +msgid "" +"Local responsibility and democratic accountability are ensured when a public" +" organization implements and maintains their own public code. By being open " +"and with a broader contributor base, the software is more secure as it " +"benefits from many eyes spotting potential flaws. Many contributors share " +"the maintenance work to keep it functional and modern, which reduces future " +"technical debt. The shared workload is more sustainable now and in the " +"future. Its openness makes both the code and its data more easily adaptable " +"in the future. The code will be easier to retool, repurpose or retire. This " +"all results in lower risk public infrastructure." +msgstr "" + +#: ./foreword.md:block 39 (paragraph) +msgid "" +"This pooling of resources lets public administrations give extra attention " +"to how to customize the software so it works best in each local context, " +"creating better user experiences for their end users (residents or " +"citizens)." +msgstr "" + +#: ./foreword.md:block 40 (header) +msgid "Economics of public code" +msgstr "" + +#: ./foreword.md:block 41 (paragraph) +msgid "" +"Public code offers a better economic model for public organizations as well " +"as for commercial companies. It's an alternative to traditional software " +"procurement which increases local control and economic opportunity." +msgstr "" + +#: ./foreword.md:block 42 (paragraph) +msgid "" +"Designed from the start to be open, adaptable and with data portability, it " +"can be developed by in-house staff or trusted vendors. Because the code is " +"open, the public administration can change vendors if they need to. Open " +"code increases opportunities for public learning and scrutiny, allowing the " +"public administration to procure smaller contracts. Smaller procurements are" +" easier for local small and medium enterprises to bid upon. Public " +"administrations can use their own software purchasing to stimulate " +"innovation and competition in their local economy." +msgstr "" + +#: ./foreword.md:block 43 (paragraph) +msgid "" +"This can be seen as investment leading to future economic growth. More " +"vendors will be necessary due to growing technology demand." +msgstr "" + +#: ./foreword.md:block 44 (header) +msgid "Procuring public code" +msgstr "" + +#: ./foreword.md:block 45 (paragraph) +msgid "" +"Public code can be used and developed by permanent in-house development " +"teams, contractors or outsourced suppliers. Vendors to public organizations " +"can include public code in their bids for contracts." +msgstr "" + +#: ./foreword.md:block 46 (paragraph) +msgid "" +"To use existing public code, you need to specify in your budget and project " +"design that your new solution will use that codebase. To encourage an " +"innovative approach to adapting the public code to your context, you could " +"describe the service or outcome in your contract." +msgstr "" + +#: ./foreword.md:block 47 (header) +msgid "The goals for the Standard for Public Code" +msgstr "" + +#: ./foreword.md:block 48 (paragraph) +msgid "" +"This Standard supports developers, designers, managers and public policy " +"makers to:" +msgstr "" + +#: ./foreword.md:block 49 (unordered list) +msgid "" +"develop high quality software and policy for better public service delivery" +msgstr "" + +#: ./foreword.md:block 49 (unordered list) +msgid "" +"develop codebases that can be reused across contexts and collaboratively " +"maintained" +msgstr "" + +#: ./foreword.md:block 49 (unordered list) +msgid "reduce technical debt and project failure rate" +msgstr "" + +#: ./foreword.md:block 49 (unordered list) +msgid "" +"have more granular control over, and ability to make decisions about, their " +"IT systems" +msgstr "" + +#: ./foreword.md:block 49 (unordered list) +msgid "improve vendor relationships with a better economic model" +msgstr "" + +#: ./foreword.md:block 50 (paragraph) +msgid "" +"Potential users of codebases tested against the Standard for Public Code can" +" expect them to be highly reusable, easily maintainable and of high quality." +msgstr "" + +#: ./foreword.md:block 51 (paragraph) +msgid "The Standard for Public Code does this by:" +msgstr "" + +#: ./foreword.md:block 52 (unordered list) +msgid "setting out a common terminology for public code development" +msgstr "" + +#: ./foreword.md:block 52 (unordered list) +msgid "establishing measures to help develop high quality public code" +msgstr "" + +#: ./foreword.md:block 52 (unordered list) +msgid "" +"providing guidance on how to fulfill its criteria and operationalize " +"compliance" +msgstr "" + +#: ./foreword.md:block 53 (paragraph) +msgid "" +"The Standard for Public Code is meant to be time and technology independent." +msgstr "" + +#: ./foreword.md:block 54 (header) +msgid "Who this is for" +msgstr "" + +#: ./foreword.md:block 55 (paragraph) +msgid "" +"The Standard for Public Code is for the people who create and reuse public " +"code:" +msgstr "" + +#: ./foreword.md:block 56 (unordered list) +msgid "public policy makers" +msgstr "" + +#: ./foreword.md:block 56 (unordered list) +msgid "business and project managers" +msgstr "" + +#: ./foreword.md:block 56 (unordered list) +msgid "developers and designers" +msgstr "" + +#: ./foreword.md:block 57 (paragraph) +msgid "These people work at:" +msgstr "" + +#: ./foreword.md:block 58 (unordered list) +msgid "institutions, organizations and administrations in the public sector" +msgstr "" + +#: ./foreword.md:block 58 (unordered list) +msgid "" +"consultancies and vendors of information technology and policy services to " +"public organizations" +msgstr "" + +#: ./foreword.md:block 59 (paragraph) +msgid "" +"It is not aimed at public organizations' end users (residents or citizens), " +"journalists or academics." +msgstr "" + +#: ./foreword.md:block 61 (unordered list) +msgid "" +"[\"Modernising Public Infrastructure with Free Software\" white " +"paper](https://download.fsfe.org/campaigns/pmpc/PMPC-Modernising-with-Free-" +"Software.pdf) by the Free Software Foundation Europe." +msgstr "" + +#: ./foreword.md:block 62 (header) +msgid "Videos on public code" +msgstr "" + +#: ./foreword.md:block 63 (unordered list) +msgid "" +"[Collaborative Code is the Future of Cities @ DecidimFest " +"2019](https://www.youtube.com/watch?v=cnJtnZ9Cx1o). Talk by Ben Cerveny on " +"the background behind the Foundation for Public Code." +msgstr "" + +#: ./foreword.md:block 63 (unordered list) +msgid "" +"[Public Money? Public Code! - Panel @ Nextcloud Conference " +"2019](https://youtube.com/watch?v=QHFkD4xfd6c). Touches on topics like " +"procurement, law and more." +msgstr "" + +#: ./foreword.md:block 64 (header) +msgid "Get involved" +msgstr "" + +#: ./foreword.md:block 65 (paragraph) +msgid "" +"This standard is a living document. [Read our contributor " +"guide](/CONTRIBUTING.md) to learn how you can make it better." +msgstr "" + +#: ./foreword.md:block 66 (header) +msgid "Contact" +msgstr "" + +#: ./foreword.md:block 67 (paragraph) +msgid "" +"For questions and more information about the Foundation for Public Code you " +"can find us at [our website](https://publiccode.net/), email us at " +"info@publiccode.net, or call us at +31 20 2 444 500." +msgstr "" + +#: ./glossary.md:block 3 (header) +msgid "Glossary" +msgstr "" + +#: ./glossary.md:block 4 (header) +msgid "Code" +msgstr "" + +#: ./glossary.md:block 5 (paragraph) +msgid "" +"Any explicitly described system of rules. This includes laws, policy and " +"ordinances, as well as source code that is used to build software. Both of " +"these are rules, some executed by humans and others by machines." +msgstr "" + +#: ./glossary.md:block 6 (header) +msgid "Codebase" +msgstr "" + +#: ./glossary.md:block 7 (paragraph) +msgid "" +"Any discrete package of code (both source and policy), the tests and the " +"documentation required to implement a piece of policy or software." +msgstr "" + +#: ./glossary.md:block 8 (paragraph) +msgid "This can be, for example, a document or a version-control repository." +msgstr "" + +#: ./glossary.md:block 9 (header) +msgid "Continuous integration" +msgstr "" + +#: ./glossary.md:block 10 (paragraph) +msgid "" +"In software engineering, continuous integration (CI) is the practice of " +"merging all developers' working copies to a development branch of a codebase" +" as frequently as reasonable." +msgstr "" + +#: ./glossary.md:block 11 (header) +msgid "Different contexts" +msgstr "" + +#: ./glossary.md:block 12 (paragraph) +msgid "" +"Two contexts are different if they are different public organizations or " +"different departments for which there is not one decision maker that could " +"make collaboration happen naturally." +msgstr "" + +#: ./glossary.md:block 13 (header) +msgid "General public" +msgstr "" + +#: ./glossary.md:block 14 (paragraph) +msgid "" +"The public at large: end users of the code and the services based upon it." +msgstr "" + +#: ./glossary.md:block 15 (paragraph) +msgid "" +"For example, a city's residents are considered end users of a city's " +"services and of all code that powers these services." +msgstr "" + +#: ./glossary.md:block 16 (header) +msgid "Open source" +msgstr "" + +#: ./glossary.md:block 17 (paragraph) +msgid "" +"Open source is defined by the Open Source Initiative in their [Open Source " +"Definition](https://opensource.org/osd-annotated)." +msgstr "" + +#: ./glossary.md:block 18 (header) +msgid "Open standard" +msgstr "" + +#: ./glossary.md:block 19 (paragraph) +msgid "" +"An open standard is any standard that meets the Open Source Initiative's " +"[Open Standard Requirements](https://opensource.org/osr)." +msgstr "" + +#: ./glossary.md:block 20 (header) +msgid "Policy" +msgstr "" + +#: ./glossary.md:block 21 (paragraph) +msgid "" +"A policy is a deliberate system of principles to guide decisions and achieve" +" rational outcomes. A policy is a statement of intent, and is implemented as" +" a procedure or protocol. Policies are generally adopted by a governance " +"body within an organization. Policies can assist in both subjective and " +"objective decision making." +msgstr "" + +#: ./glossary.md:block 22 (paragraph) +msgid "" +"Public policy is the process by which governments translate their political " +"vision into programs and actions to deliver outcomes." +msgstr "" + +#: ./glossary.md:block 23 (paragraph) +msgid "" +"At the national level, policy and legislation (the law) are usually " +"separate. The distinction is often more blurred in local government." +msgstr "" + +#: ./glossary.md:block 24 (paragraph) +msgid "" +"In the Standard the word 'policy' refers to policy created and adopted by " +"public organizations such as governments and municipalities." +msgstr "" + +#: ./glossary.md:block 25 (header) +msgid "Public code" +msgstr "" + +#: ./glossary.md:block 26 (paragraph) +msgid "" +"Public code is open source software developed by public organizations, " +"together with the policy and guidance needed for collaboration and reuse." +msgstr "" + +#: ./glossary.md:block 27 (paragraph) +msgid "" +"Public code is both computer source code (such as software and algorithms) " +"and public policy executed in a public context, by humans or machines." +msgstr "" + +#: ./glossary.md:block 28 (paragraph) +msgid "" +"Public code serves the public interest, is open, legible, accountable, " +"accessible and sustainable." +msgstr "" + +#: ./glossary.md:block 29 (paragraph) +msgid "" +"By developing public code independently from but still implementable in the " +"local context for which it was developed, as well as documenting the " +"development process openly, public code can provide a building block for " +"others to:" +msgstr "" + +#: ./glossary.md:block 30 (unordered list) +msgid "re-implement in their local context" +msgstr "" + +#: ./glossary.md:block 30 (unordered list) +msgid "take as a starting point to continue development" +msgstr "" + +#: ./glossary.md:block 30 (unordered list) +msgid "use as a basis for learning" +msgstr "" + +#: ./glossary.md:block 31 (paragraph) +msgid "" +"To facilitate reuse, public code is either released into the public domain " +"or licensed with an open license that permits others to view and reuse the " +"work freely and to produce derivative works." +msgstr "" + +#: ./glossary.md:block 32 (header) +msgid "Repository" +msgstr "" + +#: ./glossary.md:block 33 (paragraph) +msgid "" +"A repository is a storage location used by version control tools for files " +"and metadata of a codebase. Repositories allow multiple contributors to work" +" on the same set of files. Repositories are able to store multiple versions " +"of sets of files." +msgstr "" + +#: ./glossary.md:block 34 (header) +msgid "Source Code" +msgstr "" + +#: ./glossary.md:block 35 (paragraph) +msgid "" +"Human readable text of a computer program which can be translated into " +"machine instructions." +msgstr "" + +#: ./glossary.md:block 36 (header) +msgid "Version control" +msgstr "" + +#: ./glossary.md:block 37 (paragraph) +msgid "" +"Version control is the management of changes to source code and the files " +"associated with it. Changes are usually identified by a code, termed the " +"*revision number* (or similar). Each revision is associated with the time it" +" was made and the person making the change, thus making it easier to retrace" +" the evolution of the code. Revision control systems can be used to compare " +"different versions with each other and to see how content has changed over " +"time." +msgstr "" + +#: ./index.md:block 3 (header) +msgid "toc: false" +msgstr "" + +#: ./index.md:block 4 (header) +msgid "Guidance for government open source collaboration" +msgstr "" + +#: ./index.md:block 5 (paragraph) +msgid "" +"The Standard for Public Code is a set of criteria that supports public " +"organizations in developing and maintaining software and policy together." +msgstr "" + +#: ./index.md:block 6 (paragraph) +msgid "" +"The Standard for Public Code provides guidance to public organizations " +"building their own open source solutions to enable successful future " +"collaboration and reuse by similar organizations in the public sector in " +"other places. It includes advice for policy makers, government managers, " +"developers and vendors. The Standard for Public Code supports the " +"collaborative creation of codebases that are usable, open, legible, " +"accountable, accessible and sustainable. It is meant to be applicable to " +"codebases for all levels of government, from supranational to municipal." +msgstr "" + +#: ./index.md:block 7 (paragraph) +msgid "" +"The Standard for Public Code defines ‘[public code](glossary.md#public-" +"code)’ as open source software developed by public organizations, together " +"with the policy and guidance needed for collaboration and reuse." +msgstr "" + +#: ./index.md:block 8 (paragraph) +msgid "" +"The criteria of the Standard for Public Code are aligned with guidelines and" +" best practices of open source software development." +msgstr "" + +#: ./index.md:block 9 (paragraph) +msgid "" +"{% for page in site.pages %}{% if page.name == \"foreword.md\" %} Additional" +" context and background can be found in the [foreword](foreword.md). {% " +"endif%}{% endfor %}" +msgstr "" + +#: ./index.md:block 10 (header) +msgid "Contents" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "[Readers guide: how to interpret this standard](readers-guide.md)" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "[Glossary](glossary.md)" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "" +"[Criteria](criteria/){% assign sorted = site.pages | sort:\"order\" %}{% for" +" page in sorted %}{% if page.dir == \"/criteria/\" %}{% if page.name != " +"\"index.md\" %}{% if page.title %}" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "" +"[{{page.title}}]({{page.url}}){% endif%}{% endif%}{% endif%}{% endfor %}" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "[Authors](AUTHORS.md)" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "[Contributing guide](CONTRIBUTING.md)" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "[Code of conduct](CODE_OF_CONDUCT.md)" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "[Governance](GOVERNANCE.md)" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "[Version history](CHANGELOG.md)" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "[License](license.html)" +msgstr "" + +#: ./index.md:block 12 (header) +msgid "Community calls" +msgstr "" + +#: ./index.md:block 13 (paragraph) +msgid "" +"We usually have a community call on the first Thursday of the month at 15:00" +" (CET/CEST). [The agenda](https://write.publiccode.net/pads/Community-Call-" +"Standard-for-Public-Code) is updated roughly a week before the call. It is " +"possible to [sign " +"up](https://odoo.publiccode.net/survey/start/594b9243-c7e5-4bc1-8714-35137c971842)" +" to get a call invitation emailed to you." +msgstr "" + +#: ./index.md:block 14 (header) +msgid "Other resources" +msgstr "" + +#: ./index.md:block 15 (unordered list) +msgid "" +"Unofficial [community translations of the " +"Standard](https://publiccodenet.github.io/community-translations-standard/) " +"in other languages" +msgstr "" + +#: ./index.md:block 15 (unordered list) +msgid "" +"[Standard compliance self " +"assessment](https://publiccodenet.github.io/assessment-eligibility/) for " +"public sector open source codebases" +msgstr "" + +#: ./index.md:block 15 (unordered list) +msgid "" +"[Standard criteria checklist](/docs/review-template.html) used by Foundation" +" for Public Code stewards for codebase review" +msgstr "" + +#: ./readers-guide.md:block 3 (header) +msgid "Readers guide" +msgstr "" + +#: ./readers-guide.md:block 4 (paragraph) +msgid "" +"The Standard describes a number of criteria. All criteria have consistent " +"sections that make it clear how to create great public code." +msgstr "" + +#: ./readers-guide.md:block 5 (paragraph) +msgid "" +"References to \"policy makers\", \"managers\", and \"developers and " +"designers\" apply to anyone performing duties associated with these roles, " +"regardless of their job title. It is common for individuals to have duties " +"which span multiple roles." +msgstr "" + +#: ./readers-guide.md:block 6 (paragraph) +msgid "" +"Below is a brief explanation of each of these sections and how they are used" +" within the criteria of the Standard." +msgstr "" + +#: ./readers-guide.md:block 7 (header) +msgid "Introduction" +msgstr "" + +#: ./readers-guide.md:block 8 (paragraph) +msgid "" +"This section explains what the criterion aims to achieve and why it is " +"important for a codebase's users and contributors." +msgstr "" + +#: ./readers-guide.md:block 10 (paragraph) +msgid "" +"This section lists what needs to be done in order to comply with the " +"standard." +msgstr "" + +#: ./readers-guide.md:block 11 (paragraph) +msgid "" +"The following keywords in this document are to be interpreted as described " +"in [IETF RFC 2119](https://tools.ietf.org/html/rfc2119):" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "MUST" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "MUST NOT" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "REQUIRED" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "SHALL" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "SHALL NOT" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "SHOULD" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "SHOULD NOT" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "RECOMMENDED" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "MAY" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "OPTIONAL" +msgstr "" + +#: ./readers-guide.md:block 14 (paragraph) +msgid "" +"This section offers actions you can take to see if a contribution is " +"compliant with the Standard. This is key if you want to operationalize the " +"Standard." +msgstr "" + +#: ./readers-guide.md:block 15 (paragraph) +msgid "" +"We've tried to word it so that someone who is not intimately acquainted with" +" the subject matter can still do a basic check for compliance." +msgstr "" + +#: ./readers-guide.md:block 17 (paragraph) +msgid "" +"This section tries to specifically speak to policy makers by offering them " +"concrete actions they can perform in their role." +msgstr "" + +#: ./readers-guide.md:block 18 (paragraph) +msgid "" +"Public policy makers set the priorities and goals of projects and may be " +"less technologically experienced." +msgstr "" + +#: ./readers-guide.md:block 20 (paragraph) +msgid "" +"This section tries to specifically speak to managers by offering concrete " +"actions they can perform in their role." +msgstr "" + +#: ./readers-guide.md:block 21 (paragraph) +msgid "" +"Managers are responsible for on-time project delivery, stakeholder " +"management and continued delivery of the service. For this they are wholly " +"reliant on both policy makers as well as developers and designers. They need" +" to create the right culture, line up the right resources and provide the " +"right structures to deliver great services." +msgstr "" + +#: ./readers-guide.md:block 23 (paragraph) +msgid "" +"This section tries to specifically speak to developers and designers by " +"offering them concrete actions they can perform in their role." +msgstr "" + +#: ./readers-guide.md:block 24 (paragraph) +msgid "" +"Developers are usually more technically aligned and have more impact on the " +"delivery of services than the previous groups." +msgstr "" + +#: ./readers-guide.md:block 25 (header) +msgid "Limitation of scope" +msgstr "" + +#: ./readers-guide.md:block 26 (paragraph) +msgid "" +"The Standard for Public Code is not meant to cover individual " +"implementations of a codebase. This means the standard does not tell " +"implementers how to comply with their organization's local technical " +"infrastructure or legal framework." +msgstr "" + +#: ./readers-guide.md:block 27 (paragraph) +msgid "" +"Also, while the Standard for Public Code refers to several standards and has" +" considerable overlap with others, its purpose is to enable collaboration. " +"Therefore, it does not aim to replace quality standards, like the ISO 25000 " +"series, or those focusing on security, like the [OpenSSF Best Practices " +"Badge](https://github.com/coreinfrastructure/best-practices-badge), but to " +"synergize well with them." +msgstr "" + +#: ./readers-guide.md:block 28 (paragraph) +msgid "" +"And while the purpose includes enabling collaboration, it will not guarantee" +" that a community will spring into existence. That still requires " +"proactiveness and ambition beyond making the codebase collaboration ready." +msgstr "" diff --git a/_site/locales/zh_Hant/LC_MESSAGES/messages.po b/_site/locales/zh_Hant/LC_MESSAGES/messages.po new file mode 100644 index 00000000..ae369f9a --- /dev/null +++ b/_site/locales/zh_Hant/LC_MESSAGES/messages.po @@ -0,0 +1,6304 @@ +msgid "" +msgstr "" +"Project-Id-Version: PACKAGE VERSION\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2023-07-30 22:44+0800\n" +"PO-Revision-Date: 2023-11-03 06:41+0000\n" +"Last-Translator: Winnie \n" +"Language-Team: Chinese (Traditional) \n" +"Language: zh_Hant\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=1; plural=0;\n" +"X-Generator: Weblate 4.18.2\n" + +# +#: ./404.md:block 1 (header) +msgid "SPDX-License-Identifier: CC0-1.0" +msgstr "SPDX-License-Identifier: CC0-1.0" + +#: ./404.md:block 2 (header) +msgid "" +"SPDX-FileCopyrightText: 2022-2023 The Foundation for Public Code " +"[info@publiccode.net](mailto:info@publiccode.net), " +"https://standard.publiccode.net/AUTHORS" +msgstr "" +"SPDX-FileCopyrightText: 2022-2023 Foundation for Public Code [info@publiccode" +".net](mailto:info@publiccode.net), https://standard.publiccode.net/AUTHORS" + +#: ./404.md:block 3 (header) +msgid "" +"layout: default\n" +"title: Page not found\n" +"toc: false" +msgstr "" +"layout: default\n" +"title: Page not found\n" +"toc: false" + +#: ./404.md:block 4 (header) +msgid "404 Not Found" +msgstr "404 找不到網頁" + +#: ./404.md:block 5 (paragraph) +msgid "If you typed the web address, check it is correct." +msgstr "如果您是手動輸入網址，請確認網址是否正確。" + +#: ./404.md:block 6 (paragraph) +msgid "If you pasted the web address, check you copied the entire address." +msgstr "如果您是複製貼上此網址，請確認是否有複製到完整的網址。" + +#: ./404.md:block 7 (paragraph) +msgid "" +"If the web address is correct or you followed a link or button, email the " +"[Foundation for Public Code staff](mailto:info@publiccode.net) so we'll be " +"able to help you out, as well as correct our mistake." +msgstr "" +"若網址正確，或您是按下連結或按鈕來的，請寫信給 [Foundation for Public Code " +"員工](mailto:info@publiccode.net)，讓我們協助您，並同時修正我們的錯誤。" + +#: ./AUTHORS.md:block 2 (header) +msgid "" +"SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code " +"[info@publiccode.net](mailto:info@publiccode.net), " +"https://standard.publiccode.net/AUTHORS" +msgstr "" +"SPDX-FileCopyrightText: 2019-2023 Foundation for Public Code [info@publiccode" +".net](mailto:info@publiccode.net), https://standard.publiccode.net/AUTHORS" + +#: ./AUTHORS.md:block 3 (header) +msgid "Authors" +msgstr "作者群" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Alba Roza, [The Foundation for Public Code](https://publiccode.net/)" +msgstr "Alba Roza，[Foundation for Public Code](https://publiccode.net/)" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Arnout Engelen" +msgstr "Arnout Engelen" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Arnout Schuijff, The Foundation for Public Code" +msgstr "Arnout Schuijff，Foundation for Public Code" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Audrey Tang, [digitalminister.tw](https://digitalminister.tw/)" +msgstr "唐鳳，[數位發展部](https://digitalminister.tw/)" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Ben Cerveny, The Foundation for Public Code" +msgstr "Ben Cerveny，Foundation for Public Code" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Bert Spaan" +msgstr "Bert Spaan" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Boris van Hoytema, The Foundation for Public Code" +msgstr "Boris van Hoytema，Foundation for Public Code" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Charlotte Heikendorf" +msgstr "Charlotte Heikendorf" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Claus Mullie, The Foundation for Public Code" +msgstr "Claus Mullie，Foundation for Public Code" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "David Barberi" +msgstr "David Barberi" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Edo Plantinga, [Code For NL](https://codefor.nl/)" +msgstr "Edo Plantinga，[Code For NL](https://codefor.nl/)" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Elena Findley-de Regt, The Foundation for Public Code" +msgstr "Elena Findley-de Regt，Foundation for Public Code" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Eric Herman, The Foundation for Public Code" +msgstr "Eric Herman，Foundation for Public Code" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Felix Faassen, The Foundation for Public Code" +msgstr "Felix Faassen，Foundation for Public Code" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Floris Deerenberg" +msgstr "Floris Deerenberg" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Jan Ainali, The Foundation for Public Code" +msgstr "Jan Ainali，Foundation for Public Code" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Johan Groenen, Code For NL" +msgstr "Johan Groenen，Code For NL" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Marcus Klaas de Vries" +msgstr "Marcus Klaas de Vries" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Mark van der Net, [Gemeente Amsterdam](https://www.amsterdam.nl/en/)" +msgstr "Mark van der Net，[阿姆斯特丹市政府](https://www.amsterdam.nl/en/)" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "" +"Martijn de Waal, [Amsterdam University of Applied Sciences " +"(AUAS)](https://www.amsterdamuas.com/), Faculty of Digital Media and " +"Creative Industries, Lectorate of Play & Civic Media" +msgstr "" +"Martijn de Waal，[阿姆斯特丹應用科技大學 (AUAS)](https://www.amsterdamuas." +"com/)，數位媒體與創意產業學院，戲劇與公民媒體系講師" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Matti Schneider" +msgstr "Matti Schneider" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Mauko Quiroga" +msgstr "Mauko Quiroga" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Maurice Hendriks, Gemeente Amsterdam" +msgstr "Maurice Hendriks， 阿姆斯特丹市政府" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Maurits van der Schee, Gemeente Amsterdam" +msgstr "Maurits van der Schee，阿姆斯特丹市政府" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Mirjam van Tiel, The Foundation for Public Code" +msgstr "Mirjam van Tiel，Foundation for Public Code" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Ngô Ngọc Đức Huy" +msgstr "Ngô Ngọc Đức Huy" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Paul Keller" +msgstr "Paul Keller" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "" +"Petteri Kivimäki, [Nordic Institute for Interoperability Solutions " +"(NIIS)](https://niis.org)" +msgstr "Petteri Kivimäki， [北歐互通性解決方案機構 (NIIS)](https://niis.org)" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Sky Bristol" +msgstr "Sky Bristol" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Tamas Erkelens, Gemeente Amsterdam" +msgstr "Tamas Erkelens，阿姆斯特丹市政府" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Timo Slinger" +msgstr "Timo Slinger" + +#: ./CC0-1.0.md:block 3 (header) +msgid "toc: false redirect_from: - license.html - LICENSE.html" +msgstr "toc: false redirect_from: - license.html - LICENSE.html" + +#: ./CC0-1.0.md:block 4 (header) +msgid "Creative Commons Zero v1.0 Universal" +msgstr "創用 CC0 1.0 通用授權" + +#: ./CC0-1.0.md:block 6 (paragraph) +msgid "" +"This license is the legal contract that allows anyone to do anything they " +"like with the content in this entire document." +msgstr "此授權的法律契約，允許任何人任意使用本文件中的任何內容。" + +#: ./CHANGELOG.md:block 3 (header) +msgid "Version history" +msgstr "版本歷史" + +#: ./CHANGELOG.md:block 5 (header) +msgid "Version 0.7.0" +msgstr "0.7.0 版" + +#: ./CHANGELOG.md:block 6 (paragraph) +msgid "" +"May 31st 2023: 📑 the fifteenth draft adds new requirements for documenting " +"review funding and clarifies review process requirement." +msgstr "2023年5月31日：📑第十五版新增紀錄募資審查的新規定，並釐清審查流程規定。" + +#: ./CHANGELOG.md:block 7 (unordered list) +msgid "" +"Add requirement to document who is expected to cover the cost of reviewing " +"contributions." +msgstr "新增規定，記錄預期由何者負擔審核貢獻內容所需的開銷費用。" + +#: ./CHANGELOG.md:block 7 (unordered list) +msgid "Add requirement to have a short description of the codebase." +msgstr "新增規定，程式基底必須要有簡短說明。" + +#: ./CHANGELOG.md:block 7 (unordered list) +msgid "" +"Change the focus of contributions adhering to standards to focus on the " +"review of contributions." +msgstr "原先專注在貢獻內容是否遵循標準，現在則改為注重貢獻內容的審查。" + +#: ./CHANGELOG.md:block 7 (unordered list) +msgid "Relaxed MUST requirements to SHOULD in Make the codebase findable." +msgstr "將〈程式基底可查詢得到〉中許多「必須」等級的規定，調降為「應該」等級。" + +#: ./CHANGELOG.md:block 7 (unordered list) +msgid "Review template now in HTML format." +msgstr "審查範本現在有 HTML 格式。" + +#: ./CHANGELOG.md:block 7 (unordered list) +msgid "Introduction converted to foreword." +msgstr "「前言」轉換為「序文」。" + +#: ./CHANGELOG.md:block 7 (unordered list) +msgid "Improved contributing guidelines." +msgstr "改善貢獻指引。" + +#: ./CHANGELOG.md:block 7 (unordered list) +msgid "Improved documentation of scripts." +msgstr "改善命令稿文件紀錄。" + +#: ./CHANGELOG.md:block 8 (header) +msgid "Version 0.6.0" +msgstr "0.6.0 版" + +#: ./CHANGELOG.md:block 9 (paragraph) +msgid "" +"April 20th 2023: 🔀 the fourteenth draft adds new requirements for " +"portability and tests and an introduction to each criterion." +msgstr "2023年4月20日：🔀第十四版草稿新增可移植性與測試的規定，並且每個準則都有一段前" +"言。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"New requirement in Create reusable and portable code about the development " +"being a collaboration between multiple parties." +msgstr "新增規定，在〈程式碼要可重複使用且可攜〉加入多方協作開發的內容。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"New requirement in Create reusable and portable code about being dependent " +"on a single vendor." +msgstr "新增規定，在〈程式碼要可重複使用且可攜〉中加入依賴單一供應商的內容。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"New requirement in Use continuous integration about publishing results for " +"automated tests." +msgstr "新增規定，在〈使用持續整合〉中加入要發布自動化測試結果的內容。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Differentiating the two requirements about security to clearly be about " +"providing a method and having documentation about it." +msgstr "對安全性區分出兩項規定，一是要有提供方法，另一個是要有文件紀錄。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Rephrased requirements to focus on the codebase rather than contributor " +"behavior." +msgstr "重新撰寫規定，將焦點放在程式基底，而非貢獻者行為。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Removed the sections Why this is important and What this does not do and " +"replaced with an introduction in each criterion." +msgstr "移除「此措施辦不到的事」以及「此措施為何重要」兩個小節，改換成在每項準則中加" +"入前言。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Added general What this does not do section in the introduction of the " +"Standard." +msgstr "在本標準前言中，加入通用的「此措施辦不到的事」小節。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Added guidance for public policy makers about related policies and license " +"compatibility." +msgstr "為政策制定者加入相關政策與授權相容性的指引。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Added guidance for developers and designers about version controlling files." +msgstr "為開發人員與設計師新增檔案要有版本控制的相關指引。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Clarified guidance for developers and designers about prompt responses and " +"search engine optimization." +msgstr "為開發人員與設計師釐清有關快速回應，以及搜尋引擎最佳化的內容。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "Added Further reading about accessibility." +msgstr "新增可近用性無障礙環境的「延伸閱讀」內容。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "Aligned criteria URLs with criteria names." +msgstr "將各準則的連結與其名稱連動。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "Improved navigation in the web version." +msgstr "改善網頁版的導覽功能。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Moved tools in Further reading sections to the community implementation " +"guide." +msgstr "已將「延伸閱讀」小節的工具移到社群實踐指引。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Moved compliance or certification process to " +"[publiccode.net](https://publiccode.net)." +msgstr "將標準依循或認證相關流程移到 [publiccode.net](https://publiccode.net)。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Change format of the review template to make it easier to update after a new" +" release." +msgstr "變更審查範本格式，讓範本在發行新版後更容易更新。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Improved the text on the landing page and added links to related resources." +msgstr "改善著陸引導頁文字，加入相關資源的連結。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "Added spell checker automated test." +msgstr "新增拼字檢查自動化測試。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "Made minor changes to text for clarity and consistency." +msgstr "微調文字，讓內容更明確與一致。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "Moved SPDX headers to yaml header." +msgstr "將 SPDX 標頭換成 yaml 標頭。" + +#: ./CHANGELOG.md:block 11 (header) +msgid "Version 0.5.0" +msgstr "0.5.0 版" + +#: ./CHANGELOG.md:block 12 (paragraph) +msgid "" +"January 25th 2023: 🎨 the thirteenth draft focuses on documenting style " +"guidelines." +msgstr "2023年1月25日：🎨第十三版草稿焦點著重在文件紀錄風格指引。" + +#: ./CHANGELOG.md:block 13 (unordered list) +msgid "" +"Adjust the coding style requirement to focus on the codebase using a style " +"guide rather than contributor behavior." +msgstr "調整程式碼撰寫風格要求，專注於程式基底上，而非貢獻者行為。" + +#: ./CHANGELOG.md:block 13 (unordered list) +msgid "" +"Moved requirement for codebase names to Make the codebase findable from Use " +"plain English." +msgstr "將程式基底名稱規定，從〈使用白話的英文〉移到〈程式基底可查詢得到〉。" + +#: ./CHANGELOG.md:block 13 (unordered list) +msgid "" +"Moved requirement about testing the code by using examples to Use continuous" +" integration from Document the code." +msgstr "將測試程式碼的規定，從〈程式碼要有文件〉移到〈使用持續整合〉。" + +#: ./CHANGELOG.md:block 13 (unordered list) +msgid "" +"Split requirement about machine testable standards to clarify that open is " +"more important than testable." +msgstr "劃分機器可讀的測試標準規定，指明程式碼的開放性比可測試性更重要。" + +#: ./CHANGELOG.md:block 13 (unordered list) +msgid "" +"Adjust how to test findability requirements to be less reliant on search " +"engine algorithms." +msgstr "調整可查找性的測試規定，降低對搜尋引擎演算法的依賴。" + +#: ./CHANGELOG.md:block 14 (header) +msgid "Version 0.4.1" +msgstr "0.4.1 版" + +#: ./CHANGELOG.md:block 15 (paragraph) +msgid "December 5th 2022: 📝 the twelfth draft clarifies document maturity." +msgstr "2022年12月5日：📝第十二版草稿指出要以文件記錄成熟度。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "" +"Document maturity focuses on whether or not versions of the codebase are " +"ready to use." +msgstr "寫下成熟度著重於程式基底是否已經可供使用，更甚於版本編號。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "" +"Document maturity no longer requires specific labels for codebases that are " +"not ready to use." +msgstr "寫下成熟度不再需要為尚未準備好可供使用的程式基底加上特定標籤。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Audit flow image now generated from an easier to translate format." +msgstr "稽核流程圖現在以更容易轉譯的格式生成。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Improved guidance on How to test." +msgstr "改善「測試方式」指引。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Add publiccode.yml file." +msgstr "新增 publiccode.yml 檔案。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Add review template." +msgstr "新增審查範本。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Consistently link glossary terms." +msgstr "一致性連結詞彙表。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Add practices and standards to follow in CONTRIBUTING." +msgstr "在「CONTRIBUTING」中加入要遵循的實務與標準。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Add Matti Schneider to Authors." +msgstr "將 Matti Schneider 加入作者群。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Add remaining SPDX headers to files." +msgstr "將剩餘 SPDX 標頭加入檔案中。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Made additional minor changes to text for clarity." +msgstr "再稍微修改些文字，讓文字更明確。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Some hyperlinks updated." +msgstr "更新部分超連結。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "" +"Moved examples to the [Community implementation " +"guide](https://publiccodenet.github.io/community-implementation-guide-" +"standard/)." +msgstr "" +"將範例移動到《[社群實踐指引](https://publiccodenet.github.io/" +"community-implementation-guide-standard/)》。" + +#: ./CHANGELOG.md:block 17 (header) +msgid "Version 0.4.0" +msgstr "0.4.0 版" + +#: ./CHANGELOG.md:block 18 (paragraph) +msgid "" +"September 7th 2022: 🔭 the eleventh draft adds a new findability criterion." +msgstr "2022年9月7日：🔭第十一版草稿新增可查找性準則。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Introduce new criterion: Make the codebase findable." +msgstr "導入新準則：程式基底可查詢得到。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Improve How to test section for most criteria." +msgstr "改善多數準則的「測試方式」小節。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "" +"New requirement in Welcome contributors about publishing activity " +"statistics." +msgstr "在〈歡迎貢獻者〉中加入發布活動統計的新規定。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Removed redundant requirement about portable and reusable code." +msgstr "移除可重複使用與移植的程式碼中多餘的規定。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "" +"Expand open license definition to include both OSI and FSF approved " +"licenses." +msgstr "在開放授權的定義中，加入 OSI 與 FSF 所批准的授權。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Rephrase MAY requirements to use the keyword OPTIONAL for clarity." +msgstr "重新編寫「得以」等級的相關規定，加入使用「可選擇」這個關鍵字，讓規定更明確。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "" +"Expressed intent that the Standard for Public Code should meet its own " +"requirements where applicable and added assessment." +msgstr "表達《公共程式標準》應該盡可能符合其自身規定的立場，並加入評估措施。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Add SPDX license identifiers to files." +msgstr "將 SPDX 授權識別碼加入檔案中。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Introduced new Code of Conduct." +msgstr "導入新的行為守則。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Clarify distinction between source code and policy text." +msgstr "解釋原始碼與政策內文的差異。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Restructuring of requirements with bullet point lists." +msgstr "將規定重新調整為項目要點清單格式。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Acknowledge the importance of codebase modularity for reuse." +msgstr "告知程式基底成熟度對於重複使用時的重要性。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Move requirements related to Findability to the new criterion." +msgstr "將可查找性相關規定移動到新準則中。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Clarify the role of non-open standards when used in a codebase." +msgstr "釐清非開放標準在程式基底中的角色。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Additional guidance about build-time and runtime dependencies." +msgstr "加入組建日期與執行時期依賴項目的額外指引。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Added roadmap for the development of the Standard for Public Code." +msgstr "新增《公共程式標準》的發展路線圖。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Update structure of Authors file." +msgstr "更新 Authors 檔案的結構。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Add Audrey Tang to Authors." +msgstr "將唐鳳加入作者群。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Added a list of criteria to the print edition." +msgstr "將準則列表加到印刷版本中。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "" +"Clarify what the standard means with policymakers, managers, developers and " +"designers." +msgstr "釐清標準對於政策制定者、管理人員、開發人員與設計師等不同身分間的意義。" + +#: ./CHANGELOG.md:block 20 (header) +msgid "Version 0.3.0" +msgstr "0.3.0 版" + +#: ./CHANGELOG.md:block 21 (paragraph) +msgid "" +"May 23rd 2022: 🗎 the tenth draft strengthens documentation and localization." +msgstr "2022年5月23日：🗎第十版草稿加強文件紀錄與在地化內容。" + +#: ./CHANGELOG.md:block 22 (unordered list) +msgid "" +"Requirement for localization made explicit in Create reusable and portable " +"code." +msgstr "在〈程式碼要可重複使用且可攜〉中定下明確的在地化規定。" + +#: ./CHANGELOG.md:block 22 (unordered list) +msgid "Documentation of governance changed from a SHOULD to a MUST." +msgstr "以文件記錄治理方式的規定，從「應該」等級調升為「必須」。" + +#: ./CHANGELOG.md:block 22 (unordered list) +msgid "" +"Replace the very subjective (and hard to test) \"contributions MUST be " +"small\" with requirement to document expectation in contributing guidelines " +"and focus on a single issue." +msgstr "在貢獻指引中，將非常主觀（且難以驗證）的「貢獻內容『必須』小」的規定，改為必" +"須紀錄貢獻所要完成的期待，並一次專注在單一議題上。" + +#: ./CHANGELOG.md:block 22 (unordered list) +msgid "Community translations now linked in the footer." +msgstr "社群翻譯連結現在已放到頁尾中。" + +#: ./CHANGELOG.md:block 22 (unordered list) +msgid "Revert \"Replace BPMN svg with Mermaid flowchart\"." +msgstr "還原「用 Mermaid 流程圖取代業務流程 BPMN svg」。" + +#: ./CHANGELOG.md:block 22 (unordered list) +msgid "Many minor clarifications to language and sentences made more simple." +msgstr "細微調整用詞，讓句子更簡單。" + +#: ./CHANGELOG.md:block 23 (header) +msgid "Version 0.2.3" +msgstr "0.2.3 版" + +#: ./CHANGELOG.md:block 24 (paragraph) +msgid "" +"March 15th 2022: 📜 the ninth draft allows English summaries for policy " +"lacking an official translation." +msgstr "2022年3月15日：📜第九版草稿允許缺少官方翻譯的政策，改為提供政策的英文版摘要。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "" +"Relax the criterion Use plain English by adding a new requirement allows " +"bundled policy not available in English to have an accompanying summary in " +"English instead of translating the full text." +msgstr "放寬〈使用白話的英文〉準則，加入新規定，允許合捆的政策內文如果沒有英文版，只" +"需要加入英文版摘要，而不用翻譯全文。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "" +"Similarly, allow for English summaries for policies not available in English" +" in Bundle policy and code." +msgstr "同樣地，在〈政策與原始碼要合捆〉中，沒有英文版的政策內文可允許提供英文版摘要" +"。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "" +"Clarify that term 'policy' includes processes which impact development and " +"deployment in Bundle policy and code." +msgstr "釐清〈政策與原始碼要合捆〉中，「政策」包含能影響開發與部署的流程。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "" +"Emphasize reusability also on parts of the solutions in Create reusable and " +"portable code." +msgstr "在〈程式碼要可重複使用且可攜〉中強調解決方案部分內容的可重複使用性。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "" +"Expand guidance to Developers and designers in Create reusable and portable " +"code about deploying to proprietary platforms." +msgstr "將〈程式碼要可重複使用且可攜〉當中的開發人員與設計師指引，加入部署到專有平台" +"上的內容。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "" +"Add nuance to use of non-English terms in what management need to do in Use " +"plain English." +msgstr "在〈使用白話的英文〉中，加入管理層在面對非英語詞彙時需要做的事的提點。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "" +"Change the pull request process diagram to use Mermaid instead of BPMN to " +"make [community translations](https://github.com/publiccodenet/community-" +"translations-standard) easier." +msgstr "" +"變更拉取請求流程圖，從業務流程 BPMN 改用 " +"Mermaid，來讓[社群翻譯](https://github.com/publiccodenet/community-" +"translations-standard)更容易。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "Added Maurice Hendriks to AUTHORS." +msgstr "將 Maurice Hendriks 加入作者群。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "Added OpenApi Specification to further reading." +msgstr "將「OpenApi 規格」加入延伸閱讀。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "Made the attributions in further reading sections clearer." +msgstr "將延伸閱讀小節的特性變得更明確。" + +#: ./CHANGELOG.md:block 26 (header) +msgid "Version 0.2.2" +msgstr "0.2.2 版" + +#: ./CHANGELOG.md:block 27 (paragraph) +msgid "" +"November 29th 2021: 🏛 the eighth draft recognizes that policy which executes" +" as code may not be in English." +msgstr "2021年11月29日：🏛第八版草稿認知程式碼所執行的政策，不一定是英文。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "" +"Document exception to \"All code MUST be in English\" where policy is " +"interpreted as code." +msgstr "在「所有程式碼都必須使用英語編寫」規定中，雖然政策也算是一種程式 " +"(code)，但可以保有例外。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "" +"Add MAY requirement regarding committer email addresses in Maintain version " +"control." +msgstr "在〈維護版本控制〉中，新增與送交者電子郵件相關的「得以」規定。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Expand guidance to Policy Makers in Bundle policy and code." +msgstr "將政策制定者加入〈政策與原始碼要合捆〉指引中。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Expand guidance to Developers and designers in Use a coherent style." +msgstr "將開發人員與設計師加入「風格要前後一致」指引中。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Add \"Different contexts\" to glossary." +msgstr "新增「不同情境」到詞彙表中。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Add Mauko Quiroga and Charlotte Heikendorf to AUTHORS." +msgstr "將 Mauko Quiroga 與 Charlotte Heikendorf 加入 AUTHORS。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Add Digital Public Goods approval badge." +msgstr "新增「數位公共財」認可標章。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Added \"next\" and \"previous\" links to criteria pages of web version." +msgstr "為「準則」頁面網頁版加入「上一頁」與「下一頁」連結。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Add Open Standards principles to further reading." +msgstr "將「開放標準」原則加入延伸閱讀。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Add Definition of plain language to further reading." +msgstr "將「白話語言定義」加入延伸閱讀。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Move the Semantic Versioning Specification further reading reference." +msgstr "將「語意化版本編號規範」移動為延伸閱讀參考內容。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "" +"Clarify that publiccode.yml is one example of a machine-readable metadata " +"description." +msgstr "指出 publiccode.yml 是機器可讀中介資料說明的範例之一。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Changed \"your codebase\" and \"your organization\" to be less possessive." +msgstr "將「您的程式基底」與「您的組織單位」改為較不具有所有格的寫法。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Add instructions for creating a print version." +msgstr "新增印刷版的製作指示。" + +#: ./CHANGELOG.md:block 29 (header) +msgid "Version 0.2.1" +msgstr "0.2.1 版" + +#: ./CHANGELOG.md:block 30 (paragraph) +msgid "" +"March 1st 2021: 🧽 the seventh draft has minor cleaning up after version " +"0.2.0." +msgstr "2021年3月1日：🧽第七版草稿是 0.2.0 版後的些微清理改善。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "" +"New SHOULD requirement on using a distributed version control system and why" +" distributed is important." +msgstr "新增使用分散式版本控制系統的相關「應該」規定，並解釋分散式的重要性。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "" +"Feedback requirements for rejected contributions are more strict than " +"accepted ones." +msgstr "針對未被採用的貢獻需要給予回饋，規定要比被接受的貢獻更加嚴格。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "" +"Specify that copyright and license notices should also be machine-readable." +msgstr "明確指出著作權與授權聲明也應該要機器可讀。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "Advice on how to test that notices be machine-readable." +msgstr "聲明是否為機器可讀的測試方式建議。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "Clarify guidance for rolling releases." +msgstr "釐清滾動發行的指引。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "Clear up definition of version control in glossary." +msgstr "釐清詞彙表中「版本控制」的定義。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "" +"Add further reading encouraging contribution, SPDX, Git and reviewing " +"contributions." +msgstr "新增鼓勵貢獻、SPDX、Git 以及審查貢獻等的延伸閱讀項目。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "Add links to videos about the concept of public code." +msgstr "新增有關公共程式概念的影片連結。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "Update BPMN link." +msgstr "更新業務流程 BPMN 連結。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "Reduce link duplication." +msgstr "減少重複連結。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "Add Alba Roza and Ngô Ngọc Đức Huy to authors." +msgstr "將 Alba Roza 與 Ngô Ngọc Đức Huy 加入作者群。" + +#: ./CHANGELOG.md:block 32 (header) +msgid "Version 0.2.0" +msgstr "0.2.0 版" + +#: ./CHANGELOG.md:block 33 (paragraph) +msgid "" +"October 26th 2020: 🎊 the sixth draft splits a requirement and adds clarity." +msgstr "2020年10月26日：🎊第六版草稿拆分出一項新規定並且釐清內容。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "" +"Split \"Welcome contributions\" criterion into \"Make contributing easy\" " +"and \"Welcome contributors\"." +msgstr "將〈歡迎貢獻〉準則拆分為〈貢獻要容易〉以及〈歡迎貢獻者〉。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "" +"Rename criterion \"Pay attention to codebase maturity\" to \"Document " +"codebase maturity\"." +msgstr "將〈注意程式基底成熟度〉準則改名為〈記錄程式基底成熟度〉。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "" +"Changed MUST to SHOULD for requirement of codebase in use by multiple " +"parties." +msgstr "針對多方使用的程式基底，將「必須」等級規定調降為「應該」。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "Add MUST NOT requirement regarding copyright assignment." +msgstr "針對著作權轉讓，新增「禁止」規定。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "Clarify role of configuration in reusable code requirement." +msgstr "在可重複使用程式碼的規定中，釐清組態設定的角色。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "" +"Glossary additions: continuous integration, policy, repository, and version " +"control." +msgstr "新增詞彙：持續整合、政策、儲存庫、版本控制等。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "Replace references to 'cities' with 'public organizations'." +msgstr "將「城市」替換成「公家機關」。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "" +"Clarify aspects of sensitive code by separating contributor and reviewer " +"requirements into separate items." +msgstr "將貢獻者與審查人員規定分開為不同項目，以釐清程式碼中較敏感性的層面。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "" +"Expand further reading, and guidance to policy makers, developers and " +"designers." +msgstr "將政策制定者、開發人員與設計師加入延伸閱讀與指引中。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "Add Felix Faassen and Arnout Engelen to authors." +msgstr "將 Felix Faassen 與 Arnout Engelen 加入作者群。" + +#: ./CHANGELOG.md:block 35 (header) +msgid "Version 0.1.4" +msgstr "0.1.4 版" + +#: ./CHANGELOG.md:block 36 (paragraph) +msgid "" +"November 27th 2019: 🧹 the fifth draft consists mostly of additional minor " +"fixes." +msgstr "2019年11月27日：🧹第五版草稿主要是一些細部修正。" + +#: ./CHANGELOG.md:block 37 (unordered list) +msgid "Linked License.md file." +msgstr "連結 License.md 檔案。" + +#: ./CHANGELOG.md:block 37 (unordered list) +msgid "Add Sky Bristol, Marcus Klaas de Vries, and Jan Ainali to authors." +msgstr "將 Sky Bristol、Marcus Klaas de Vries 與 Jan Ainali 加入作者群。" + +#: ./CHANGELOG.md:block 37 (unordered list) +msgid "Made punctuation more consistent, especially for bullet lists." +msgstr "讓標點符號使用更一致，特別是項目符號列表。" + +#: ./CHANGELOG.md:block 37 (unordered list) +msgid "Made some minor changes to text for clarity." +msgstr "細部調整文字，讓內容更明確。" + +#: ./CHANGELOG.md:block 38 (header) +msgid "Version 0.1.3" +msgstr "0.1.3 版" + +#: ./CHANGELOG.md:block 39 (paragraph) +msgid "" +"October 8th 2019: 🍂 the fourth draft only patches and fixes minor things for" +" the autumn cleaning" +msgstr "2019年10月8日：🍂第四版草稿僅針對秋季所作的清理修正一些小地方" + +#: ./CHANGELOG.md:block 40 (unordered list) +msgid "Renamed continuous delivery to continuous integration." +msgstr "將「持續交付」改名為「持續整合」。" + +#: ./CHANGELOG.md:block 40 (unordered list) +msgid "Referencing accessibility guidelines in the language standard." +msgstr "在語言標準中引用無障礙指導原則。" + +#: ./CHANGELOG.md:block 40 (unordered list) +msgid "A bunch of style and consistency fixes." +msgstr "改善一些樣式，與一致性修正。" + +#: ./CHANGELOG.md:block 41 (header) +msgid "Version 0.1.2" +msgstr "0.1.2 版" + +#: ./CHANGELOG.md:block 42 (paragraph) +msgid "" +"August 22th 2019: 🌠 the third draft focuses on better text and takes " +"community input" +msgstr "2019年8月22日：🌠第三版草稿專注在提升文字品質，並且納入社群意見" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "With some great new contributors comes a fresh author list." +msgstr "有好幾位很棒的新貢獻者加入我們的作者群名單，讓氣象一新。" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "All links are now HTTPS." +msgstr "所有連結都是 HTTPS。" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "General proofreading, wording clarifications, and smashed typos." +msgstr "一般校對、釐清用字淺詞、修正拼字錯誤等。" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "Updated criteria:" +msgstr "更新準則：" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "Requirement for reuse in different contexts" +msgstr "在不同情境背景下重複使用的規定" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "Recommendation for explicit versioning" +msgstr "明確的版本控制建議" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "Recommendation for multi party development" +msgstr "多方部署的建議" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "Recommendation for license headers in files" +msgstr "檔案授權標頭的建議" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "Recommendation for vulnerability reporting" +msgstr "漏洞回報的建議" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "Recommendation for explicit documentation of governance" +msgstr "明確以文件記錄治理方式的建議" + +#: ./CHANGELOG.md:block 44 (header) +msgid "Version 0.1.1" +msgstr "0.1.1 版" + +#: ./CHANGELOG.md:block 45 (paragraph) +msgid "" +"May 9th 2019: 🤔 the second draft fixes a few basic oversights and fixes a " +"lot of typos" +msgstr "2019年5月9日：🤔第二版草稿修正一些基本的疏漏，以及許多拼字錯誤" + +#: ./CHANGELOG.md:block 46 (unordered list) +msgid "" +"Removed references to the Foundation for Public Code, we're going to have to" +" change the name in becoming an association." +msgstr "移除出現「Foundation for Public " +"Code」的地方，我們之後可能必須改名才能成為協會。" + +#: ./CHANGELOG.md:block 46 (unordered list) +msgid "Updated the introduction." +msgstr "更新簡介。" + +#: ./CHANGELOG.md:block 46 (unordered list) +msgid "Updated the glossary." +msgstr "更新詞彙表。" + +#: ./CHANGELOG.md:block 46 (unordered list) +msgid "Added the code of conduct." +msgstr "新增行為守則。" + +#: ./CHANGELOG.md:block 46 (unordered list) +msgid "We've recommended using the publiccode.yml standard for easier reuse." +msgstr "我們建議使用 publiccode.yml 標準，方便重複使用。" + +#: ./CHANGELOG.md:block 47 (header) +msgid "Version 0.1.0" +msgstr "0.1.0 版" + +#: ./CHANGELOG.md:block 48 (paragraph) +msgid "" +"April 16th 2019: 🎉 the first draft is ready, it is all brand new and has " +"snazzy new ideas in it" +msgstr "2019年4月16日：🎉初版草稿已準備就緒，全新內容，而且有許多有趣的新穎理念" + +#: ./CHANGELOG.md:block 49 (unordered list) +msgid "14 criteria with their requirements and how to operationalize them." +msgstr "14 項準則，有各自的規定，以及相關的實施方式。" + +#: ./CHANGELOG.md:block 49 (unordered list) +msgid "" +"An introduction with a high level background, what this standard is, and how" +" the Foundation for Public Code will use it." +msgstr "精要的背景介紹，例如本標準是什麼，以及 Foundation for Public Code " +"如何使用此標準。" + +#: ./CHANGELOG.md:block 50 (paragraph) +msgid "" +"This first version was produced together with the Amsterdam University of " +"Applied Sciences and the City of Amsterdam as a part of the [Smart Cities? " +"Public Code! project](https://smartcities.publiccode.net/)." +msgstr "" +"最初的版本是由阿姆斯特丹應用科學大學、阿姆斯特丹市政府，以及本基金會合作撰寫" +"，取自 [Smart Cities? Public Code! 專案](https://smartcities.publiccode.net/)" +" 的部分內容。" + +#: ./CODE_OF_CONDUCT.md:block 1 (header) +msgid "Code of Conduct" +msgstr "行為守則" + +#: ./CODE_OF_CONDUCT.md:block 3 (paragraph) +msgid "" +"Many community members are from civic or professional environments with " +"behavioral codes yet some individuals are not. This document expresses " +"expectations of all community members and all interactions regardless of " +"communication channel." +msgstr "" +"社群很多成員來自有行為守則的公民社會或專業背景，但有些人並非如此。本文件表達" +"基金會對於所有社群成員，以及所有互動間的期望，無論互動是透過何種溝通管道。" + +#: ./CODE_OF_CONDUCT.md:block 4 (paragraph) +msgid "Be here to collaborate." +msgstr "來到這裡來是為了協作。" + +#: ./CODE_OF_CONDUCT.md:block 5 (paragraph) +msgid "Be considerate, respectful, and patient." +msgstr "請對彼此體貼、尊重，以及有耐心。" + +#: ./CODE_OF_CONDUCT.md:block 6 (paragraph) +msgid "Strive to be as constructive as possible." +msgstr "努力做出有建設性的行為。" + +#: ./CODE_OF_CONDUCT.md:block 7 (paragraph) +msgid "To raise a concern, please email directors@publiccode.net." +msgstr "若有問題需要提出，請寄送電子郵件到 directors@publiccode.net。" + +#: ./CONTRIBUTING.md:block 1 (header) +msgid "Contributing to this standard" +msgstr "貢獻此標準" + +#: ./CONTRIBUTING.md:block 3 (paragraph) +msgid "🙇‍♀️ Thank you for contributing!" +msgstr "🙇‍♀️ 感謝您的貢獻！" + +#: ./CONTRIBUTING.md:block 4 (paragraph) +msgid "" +"We understand that a standard like this can only be set in collaboration " +"with as many public technologists, policy makers and interested folk as " +"possible. Thus we appreciate your input, enjoy feedback and welcome " +"improvements to this project and are very open to collaboration." +msgstr "" +"我們理解這樣的標準，只有在盡可能與公共技術人員、政策制定者，以及有興趣的人士" +"協作下才能完成。因此，我們很感謝您的意見，樂意得到回饋，以及歡迎提供改善此專" +"案的建議。我們非常開放任何合作的機會。" + +#: ./CONTRIBUTING.md:block 5 (paragraph) +msgid "" +"We love issues and pull requests from everyone. If you're not comfortable " +"with GitHub, you can email use your feedback at " +"[info@publiccode.net](mailto:info@publiccode.net)." +msgstr "" +"我們歡迎每個人提出的議題，以及拉取請求。如果您不大習慣 GitHub ，" +"也歡迎將意見回饋用電子郵件寄送到 [info@publiccode.net](mailto:info@publiccode" +".net)。" + +#: ./CONTRIBUTING.md:block 6 (header) +msgid "Problems, suggestions and questions in issues" +msgstr "問題、建議與議題等" + +#: ./CONTRIBUTING.md:block 7 (paragraph) +msgid "" +"A high-level overview of the development that we already have sketched out " +"can be seen in the [roadmap](/docs/roadmap.md). Please help development by " +"reporting problems, suggesting changes and asking questions. To do this, you" +" can [create a GitHub issue](https://docs.github.com/en/issues/tracking-" +"your-work-with-issues/creating-an-issue) for this project in the [GitHub " +"Issues for the Standard for Public " +"Code](https://github.com/publiccodenet/standard/issues)." +msgstr "" +"在[發展路線圖](/docs/roadmap.md)中可查看我們勾勒的精要概覽。歡迎回報問題、建" +"議修改，以及發問等，來協助發展。您可以到 [Standard for Public Code 的 GitHub " +"Issue](https://github.com/publiccodenet/standard/issues) 頁面中，為本專案[" +"提出 GitHub 議題](https://docs.github.com/en/issues/" +"tracking-your-work-with-issues/creating-an-issue)。" + +#: ./CONTRIBUTING.md:block 8 (paragraph) +msgid "" +"Or, sign up to the [mailing " +"list](https://lists.publiccode.net/mailman/postorius/lists/standard.lists.publiccode.net/)" +" and send an email to " +"[standard@lists.publiccode.net](mailto:standard@lists.publiccode.net)." +msgstr "" +"或者，註冊加入[郵遞論壇列表](https://lists.publiccode.net/mailman/postorius/" +"lists/standard.lists.publiccode.net/)，並寄送電子郵件到[standard@lists." +"publiccode.net](mailto:standard@lists.publiccode.net)。" + +#: ./CONTRIBUTING.md:block 9 (paragraph) +msgid "" +"You don't need to change any of our code or documentation to be a " +"contributor!" +msgstr "您不一定要修改我們的程式碼或文件，也能成為貢獻者！" + +#: ./CONTRIBUTING.md:block 10 (header) +msgid "Documentation and code in pull requests" +msgstr "為文件與程式碼提出拉取請求" + +#: ./CONTRIBUTING.md:block 11 (paragraph) +msgid "" +"If you want to add to the documentation or code of one of our projects you " +"should make a pull request." +msgstr "如果您想要在我們的專案中，為文件或程式碼加入新內容，您應該提出拉取請求 (Pull " +"Request，亦可簡稱 PR)。" + +#: ./CONTRIBUTING.md:block 12 (paragraph) +msgid "" +"If you never used GitHub, get up to speed with [Understanding the GitHub " +"flow](https://docs.github.com/en/get-started/quickstart/github-flow) or " +"follow one of the great free interactive courses in [GitHub " +"Skills](https://skills.github.com/) on working with GitHub and working with " +"MarkDown, the syntax this project's documentation is in." +msgstr "" +"若您從未使用過 GitHub，歡迎先[認識 GitHub 作業流程](https://docs.github.com/" +"en/get-started/quickstart/github-flow)，或是參加 [GitHub " +"Skills](https://skills.github.com/) 免費且優質的互動式課程，" +"當中會介紹該如何使用 GitHub 以及 MarkDown 語法。MarkDown " +"是本專案文件所採用的撰寫語法。" + +#: ./CONTRIBUTING.md:block 13 (paragraph) +msgid "" +"This project is licensed Creative Commons Zero v1.0 Universal, which " +"essentially means that the project, along with your contributions is in the " +"public domain in whatever jurisdiction possible, and everyone can do " +"whatever they want with it." +msgstr "" +"本專案採用創用CC 0 1.0 通用式公眾領域貢獻宣告給予授權；這本質上代表本專案，以" +"及您所做出的貢獻，在無論何種司法管轄情況下，都屬於公眾領域，也就是任何人都可" +"以任意使用。" + +#: ./CONTRIBUTING.md:block 14 (header) +msgid "1. Make your changes" +msgstr "1. 作出您的修改" + +#: ./CONTRIBUTING.md:block 15 (paragraph) +msgid "" +"Contributions should [follow](docs/standard-for-public-code.html) the " +"requirements set out in the criteria of the Standard for Public code itself." +" Reviewers will also be ensuring that contributions are aligned with the " +"[values of public code](foreword.md#values-of-public-code). Furthermore, " +"they will review that the contribution conforms to the " +"[standards](#standards-to-follow) and remains coherent with the overall " +"work." +msgstr "" +"貢獻內容應該[遵守](docs/standard-for-public-code.html)《公共程式標準》自身所" +"列出的準則規定。審查人員同時也會確保貢獻內容，符合[公共程式的價值](foreword." +"md#values-of-public-code)。此外，他們也會審查貢獻是否遵循[標準](#standards-" +"to-follow)，且與整體作品有所連貫。" + +#: ./CONTRIBUTING.md:block 16 (paragraph) +msgid "" +"This project uses the [GitFlow branching model and " +"workflow](https://nvie.com/posts/a-successful-git-branching-model/). When " +"you've forked this repository, please make sure to create a feature branch " +"following the GitFlow model." +msgstr "" +"本專案使用 [GitFlow 分支與工作流程](https://nvie.com/posts/" +"a-successful-git-branching-model/)。當您對此儲存庫作分支以後，請務必依照 " +"GitFlow 模型建立新功能分支。" + +#: ./CONTRIBUTING.md:block 17 (paragraph) +msgid "" +"Add your changes in commits [with a message that explains " +"them](https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-" +"message). If more than one type of change is needed, group logically related" +" changes into separate commits. For example, white-space fixes could be a " +"separate commit from text content changes. When adding new files, select " +"file formats that are easily viewed in a `diff`, for instance, `.svg` is " +"preferable to a binary image. Document choices or decisions you make in the " +"commit message, this will enable everyone to be informed of your choices in " +"the future." +msgstr "" +"將您所作的變更內容加入送交版次，[並附上內容說明](https://robots.thoughtbot." +"com/5-useful-tips-for-a-better-commit-message)。如果需要作出多種類型的變更，" +"請將相關變更依據邏輯分類，不同類型各自放在不同的送交版次中。例如：修正空白、" +"以及文字內容更動，兩者應該放在不同的送交版次中。當新增檔案時，請選用容易以「`" +"diff` 」檢視的檔案格式，如「`.svg` 」格式就勝過二進位影像。在送交版次訊息中，" +"請記錄您所作的選擇與決策，如此未來其他人都能知道您當時的抉擇。" + +#: ./CONTRIBUTING.md:block 18 (paragraph) +msgid "" +"If you are adding code, make sure you've added and updated the relevant " +"documentation and tests before you submit your pull request. Make sure to " +"write tests that show the behavior of the newly added or changed code." +msgstr "如果您是要新增程式碼，請確保您有新增與更新相關文件與測試項目，之後再提交您的" +"拉取請求。請務必撰寫可以展示新增或修改後程式碼行為的測試項目。" + +#: ./CONTRIBUTING.md:block 19 (header) +msgid "Applicable policy" +msgstr "適用政策" + +#: ./CONTRIBUTING.md:block 20 (paragraph) +msgid "" +"Currently, the Standard for Public Code is not implementing any specific " +"public policy." +msgstr "就目前而言，《公共程式標準》並非在執行任何特定的公共政策。" + +#: ./CONTRIBUTING.md:block 21 (header) +msgid "Style" +msgstr "風格" + +#: ./CONTRIBUTING.md:block 22 (paragraph) +msgid "" +"The Standard for Public Code aims to [use plain English](criteria/use-plain-" +"english.md) and we have chosen American English for spelling. Text content " +"should typically follow one line per sentence, with no line-wrap, in order " +"to make `diff` output easier to view. However, we want to emphasize that it " +"is more important that you make your contribution than worry about spelling " +"and typography. We will help you get it right in our review process and we " +"also have a separate quality check before [making a new " +"release](docs/releasing.md)." +msgstr "" +"《公共程式標準》目標[使用白話的英語](criteria/use-plain-english.md)，而拼字採" +"用美式英文。文字內容基本上以每句一行為原則，沒有文繞圖換行，來讓「`diff`」輸" +"出更容易檢視。然而，我們想要強調更重要的是，您應該專注在貢獻內容上，而不是擔" +"心拼字與排版。我們的審查流程會協助修正這一部分，也會另外再次檢查品質才[推出新" +"發行版本](docs/releasing.md)。" + +#: ./CONTRIBUTING.md:block 23 (header) +msgid "Standards to follow" +msgstr "遵守的標準" + +#: ./CONTRIBUTING.md:block 24 (paragraph) +msgid "" +"These are the standards that the Standard for Public Code uses. Please make " +"sure that your contributions are aligned with them so that they can be " +"merged more easily." +msgstr "這些是《公共程式標準》所採用的標準。請確保您的貢獻內容也遵守這些標準，才會更" +"容易合併。" + +#: ./CONTRIBUTING.md:block 25 (unordered list) +msgid "" +"[IETF RFC 2119](https://tools.ietf.org/html/rfc2119) - for requirement level" +" keywords" +msgstr "[IETF RFC 2119](https://tools.ietf.org/html/rfc2119) - 要求等級關鍵字" + +#: ./CONTRIBUTING.md:block 25 (unordered list) +msgid "" +"[Web Content Accessibility Guidelines " +"2.1](https://www.w3.org/TR/WCAG21/#readable) - for readability" +msgstr "[網頁內容可近用無障礙指引 2.1](https://www.w3.org/TR/WCAG21/#readable) - " +"易讀性" + +#: ./CONTRIBUTING.md:block 26 (header) +msgid "2. Pull request" +msgstr "2. 拉取請求" + +#: ./CONTRIBUTING.md:block 27 (paragraph) +msgid "" +"When submitting the pull request, please accompany it with a description of " +"the problem you are trying to solve and the issue number that this pull " +"request fixes. It is preferred for each pull request to address a single " +"issue where possible. In some cases a single set of changes may address " +"multiple issues, in which case be sure to list all issue numbers fixed." +msgstr "" +"當您提出拉取請求時，請隨附描述您想要解決的問題，以及該拉取請求所能修正的議題" +"編號。以一個拉取請求處理單一項議題為佳。若一組變動能同時解決多項議題，則請列" +"出所有能一併修正的議題編號。" + +#: ./CONTRIBUTING.md:block 28 (header) +msgid "3. Improve" +msgstr "3. 改善" + +#: ./CONTRIBUTING.md:block 29 (paragraph) +msgid "" +"All contributions have to be reviewed by someone. The Foundation for Public " +"Code has committed to make sure that maintainers are available to review " +"contributions with an aim to provide feedback within two business days." +msgstr "" +"所有貢獻都必須接受審查。Foundation for Public Code " +"致力於確保有維護人員能審查貢獻內容，目標是在兩個工作日內提供意見回饋。" + +#: ./CONTRIBUTING.md:block 30 (paragraph) +msgid "" +"It could be that your contribution can be merged immediately by a " +"maintainer. However, usually, a new pull request needs some improvements " +"before it can be merged. Other contributors (or helper robots) might have " +"feedback. If this is the case the reviewing maintainer will help you improve" +" your documentation and code." +msgstr "" +"維護人員有時候可以立即合併您的貢獻內容。不過一般來說，新的拉取請求通常需要再" +"經過改善後，才能夠合併。其他貢獻者（或是輔助用機器人）可能會提供意見回饋。若" +"是如此，負責審查您貢獻內容的維護人員，將協助您改善文件與程式碼。" + +#: ./CONTRIBUTING.md:block 31 (paragraph) +msgid "If your documentation and code have passed human review, it is merged." +msgstr "一旦您的文件與程式碼通過人工審查，就會合併。" + +#: ./CONTRIBUTING.md:block 32 (header) +msgid "4. Celebrate" +msgstr "4. 慶祝" + +#: ./CONTRIBUTING.md:block 33 (paragraph) +msgid "" +"Your ideas, documentation and code have become an integral part of this " +"project. You are the open source hero we need!" +msgstr "您的構想、文件與程式碼，已成為本專案的一部份。您就是我們需要的開放原始碼英雄" +"！" + +#: ./CONTRIBUTING.md:block 34 (paragraph) +msgid "" +"In fact, feel free to open a pull request to add your name to the " +"[`AUTHORS`](AUTHORS.md) file and get eternal attribution." +msgstr "誠摯歡迎您提出拉取請求，將您的名字加到 [`AUTHORS`](AUTHORS.md) " +"檔案中，讓您所做的貢獻能銘記在本專案中。" + +#: ./CONTRIBUTING.md:block 35 (header) +msgid "Translations in other languages" +msgstr "翻譯成其他語言" + +#: ./CONTRIBUTING.md:block 36 (paragraph) +msgid "" +"While the Standard does not have any official translations, you can help " +"maintain existing and add new [community translations of the " +"Standard](https://github.com/publiccodenet/community-translations-standard)." +msgstr "" +"《公共程式標準》沒有官方版本的翻譯，您仍可以協助本標準維護已有的[社群翻譯](ht" +"tps://github.com/publiccodenet/community-translations-" +"standard)，或是新增翻譯。" + +#: ./CONTRIBUTING.md:block 37 (header) +msgid "Releases" +msgstr "發行版本" + +#: ./CONTRIBUTING.md:block 38 (paragraph) +msgid "" +"We have dedicated documentation for creating [new " +"releases](/docs/releasing.md) and [ordering printed " +"standards](/docs/printing.md)." +msgstr "我們有提供[發行新版本](/docs/releasing.md)，與[訂購印刷版標準](/docs/printing" +".md)的專用詳細文件。" + +#: ./CONTRIBUTING.md:block 39 (paragraph) +msgid "" +"For more information on how to use and contribute to this project, please " +"read the [`README`](README.md)." +msgstr "若要進一步瞭解如何使用，以及協助貢獻本專案，請參閱 [`README `](README.md)。" + +#: ./GOVERNANCE.md:block 2 (header) +msgid "" +"SPDX-FileCopyrightText: 2019-2022 The Foundation for Public Code " +"[info@publiccode.net](mailto:info@publiccode.net), " +"https://standard.publiccode.net/AUTHORS" +msgstr "" +"SPDX-FileCopyrightText: 2019-2022 Foundation for Public Code[info@publiccode." +"net](mailto:info@publiccode.net), https://standard.publiccode.net/AUTHORS" + +#: ./GOVERNANCE.md:block 3 (header) +msgid "Governance" +msgstr "治理方式" + +#: ./GOVERNANCE.md:block 4 (paragraph) +msgid "" +"This standard lies at the core of the codebase stewardship provided by the " +"[Foundation for Public Code](https://publiccode.net/). We decide if a " +"codebase is ready for community co-development based on this document." +msgstr "" +"本標準是 [Foundation for Public Code](https://publiccode.net/) 在為程式基底提" +"供督導時的核心。我們依照這份文件來判斷，某個程式基底是否已經準備好讓社群共同" +"參與開發。" + +#: ./GOVERNANCE.md:block 5 (paragraph) +msgid "The standard is maintained by Foundation for Public Code staff." +msgstr "這份標準由 Foundation for Public Code 職員負責維護。" + +#: ./GOVERNANCE.md:block 6 (paragraph) +msgid "" +"[We welcome contributions, such as suggestions for changes or general " +"feedback, from anyone.](/CONTRIBUTING.md)" +msgstr "[我們歡迎任何人貢獻，例如提供修改建議，或是給予一般意見回饋等。](/CONTRIBUTIN" +"G.md)" + +#: ./GOVERNANCE.md:block 7 (paragraph) +msgid "" +"Because of the important role that the Standard for Public Code has in our " +"core process we require the highest standards from the Standard." +msgstr "由於《公共程式標準》在我們的核心流程中，扮演至關重要的角色，所以我們會以《公" +"共程式標準》的最高標準作要求。" + +#: ./GOVERNANCE.md:block 8 (paragraph) +msgid "" +"We will try to respond promptly to all pull requests. The pull request is an" +" opportunity to work together to improve our methods and the Standard. We " +"may not accept all changes, but we will explain our logic." +msgstr "" +"我們會努力儘速回覆所有拉取請求。拉取請求使我們有機會一起合作，來改善我們的方" +"法與這份標準。我們有可能不會接受貢獻者提出的所有修改，而我們會解釋背後的邏輯" +"。" + +#: ./README.md:block 1 (header) +msgid "Standard for Public Code" +msgstr "公共程式標準" + +#: ./README.md:block 3 (paragraph) +msgid "" +"The Standard for Public Code gives public organizations a model for " +"preparing open source solutions to enable collaborations with similar public" +" organizations in other places. It includes guidance for policy makers, city" +" administrators, developers and vendors." +msgstr "" +"《公共程式標準》提供公家機關一套準備開放原始碼解決方案的模型，讓他們能與其他" +"地方相似的公家機關協作。該標準包含給政策制定者、市行政官、開發人員與供應商的" +"指引。" + +#: ./README.md:block 4 (paragraph) +msgid "" +"![version 0.7.0](assets/version-badge.svg) [![License: " +"CC0-1.0](https://img.shields.io/badge/License-" +"CC0_1.0-lightgrey.svg)](http://creativecommons.org/publicdomain/zero/1.0/)" +msgstr "" +"![0.7.0版](assets/version-badge.svg) " +"[![授權：CC0-1.0](https://img.shields.io/badge/License-" +"CC0_1.0-lightgrey.svg)](http://creativecommons.org/publicdomain/zero/1.0/)" + +#: ./README.md:block 5 (paragraph) +msgid "" +"[![pages-build-" +"deployment](https://github.com/publiccodenet/standard/actions/workflows/pages/pages-" +"build-" +"deployment/badge.svg)](https://github.com/publiccodenet/standard/actions/workflows/pages/pages-" +"build-deployment) " +"[![Test](https://github.com/publiccodenet/standard/actions/workflows/test.yml/badge.svg)](https://github.com/publiccodenet/standard/actions/workflows/test.yml)" +" [![standard main badge](https://publiccodenet.github.io/publiccodenet-url-" +"check/badges/standard.publiccode.net.svg)](https://publiccodenet.github.io/publiccodenet-" +"url-check/standard.publiccode.net-url-check-look.json) [![standard develop " +"badge](https://publiccodenet.github.io/publiccodenet-url-" +"check/badges/standard.publiccode.net-" +"develop.svg)](https://publiccodenet.github.io/publiccodenet-url-" +"check/standard.publiccode.net-develop-url-check-look.json)" +msgstr "" +"[![pages-build-deployment](https://github.com/publiccodenet/standard/actions/" +"workflows/pages/pages-build-deployment/badge.svg)](https://github.com/" +"publiccodenet/standard/actions/workflows/pages/pages-build-deployment) " +"[![測試](https://github.com/publiccodenet/standard/actions/workflows/test." +"yml/badge.svg)](https://github.com/publiccodenet/standard/actions/workflows/" +"test.yml) [![standard main badge](https://publiccodenet.github.io/" +"publiccodenet-url-check/badges/standard.publiccode.net." +"svg)](https://publiccodenet.github.io/publiccodenet-url-check/standard." +"publiccode.net-url-check-look.json) [![standard develop " +"badge](https://publiccodenet.github.io/publiccodenet-url-check/badges/" +"standard.publiccode.net-develop.svg)](https://publiccodenet.github.io/" +"publiccodenet-url-check/standard.publiccode.net-develop-url-check-look.json)" + +#: ./README.md:block 6 (paragraph) +msgid "" +"The Standard for Public Code is in a draft format. We are preparing it for a" +" version 1.0 release. Currently, we are testing it on a small number of " +"codebases." +msgstr "《公共程式標準》目前為草稿階段。我們正在準備發行 1.0 " +"版，目前仍在幾個程式基底中作測試。" + +#: ./README.md:block 7 (header) +msgid "Applying the Standard for Public Code to your codebase" +msgstr "將《公共程式標準》套用到您的程式基底" + +#: ./README.md:block 8 (paragraph) +msgid "" +"If you want to apply the Standard for Public Code to your codebase, just go " +"ahead, it's an open standard and free for anyone to use. To see how ready " +"your codebase is, you can do a quick [eligibility self " +"assessment](https://publiccodenet.github.io/assessment-eligibility) that " +"will give you a rough idea of how much work you may need to do to meet all " +"criteria." +msgstr "" +"若您想要將《公共程式標準》套用到您的程式基底，就請放心去做，因為它是人人都能" +"自由採用的開放標準。若要瞭解您程式基底所達成的程度，可以做[自我資格評估](http" +"s://publiccodenet.github.io/assessment-" +"eligibility)；它能幫助您大略瞭解，如果想要滿足所有準則，還需要下多少功夫。" + +#: ./README.md:block 9 (paragraph) +msgid "" +"The standard *should* be mostly self-explanatory in how to apply it to your " +"codebase. If anything in the standard is unclear, we encourage you to open " +"an issue here so that we can help you and anyone else who feels the same as " +"you. For inspiration, look at the [community built implementation " +"guide](https://publiccodenet.github.io/community-implementation-guide-" +"standard/) which contains examples and other tips." +msgstr "" +"本標準 *應該* 足以自我解釋要如何套用到您的程式基底中。若標準中有任何不明確的" +"地方，我們鼓勵您在此開立議題，來讓我們能協助您以及其他與您抱持同樣看法的人。" +"如果需要一點靈感啟發，請參閱[社群製作的《實踐指引》](https://publiccodenet." +"github.io/community-implementation-guide-standard/)，其中包括範例與其他提示。" + +#: ./README.md:block 10 (paragraph) +msgid "" +"If there are any breaking changes in a new version of the Standard for " +"Public Code, the codebase stewards at the Foundation for Public Code will " +"help any implementers of the standard understand how the gaps can be closed." +msgstr "" +"若新版的《公共程式標準》有任何導致過去作法不再適用的改動，則 Foundation for " +"Public Code 的程式基底執事人員，會協助標準的實踐者理解該如何銜接之間的落差。" + +#: ./README.md:block 11 (paragraph) +msgid "" +"If you want to commit your codebase to become fully compliant to the " +"standard for future certification, please contact us at " +"[info@publiccode.net](mailto:info@publiccode.net) to initiate a formal " +"[assessment](https://about.publiccode.net/activities/codebase-" +"stewardship/lifecycle-diagram.html#assessment)." +msgstr "" +"若您致力讓您的程式基底完全遵循此標準，並想在未來能取得認證，請寫信與我們聯繫" +"：[info@publiccode.net](mailto:info@publiccode." +"net)，以展開正式[評估](https://about.publiccode.net/activities/" +"codebase-stewardship/lifecycle-diagram.html#assessment)。" + +#: ./README.md:block 12 (header) +msgid "Request for contributions" +msgstr "徵求貢獻" + +#: ./README.md:block 13 (paragraph) +msgid "" +"We believe public policy and software should be inclusive, usable, open, " +"legible, accountable, accessible and sustainable. This means we need a new " +"way of designing, developing and procuring both the source code and policy " +"documentation." +msgstr "" +"我們相信公共政策與公共軟體，應該具備涵容、好用、開放、易懂、課責、近用、永續" +"等特質。這代表我們需要一種新的方式，來設計、開發，以及付出心力育成原始碼和政" +"策文件。" + +#: ./README.md:block 14 (paragraph) +msgid "" +"This standard sets a quality level for codebases that meets the needs of " +"public organizations, institutions and administrations as well as other " +"critical infrastructural services." +msgstr "本標準為程式基底設立品質檢核水準，使其能滿足公家機關、社會機構、行政單位，以" +"及其他重大基礎設施服務的需求。" + +#: ./README.md:block 15 (paragraph) +msgid "" +"The standard lives at " +"[standard.publiccode.net](https://standard.publiccode.net/). See " +"[`index.md`](index.md) for an overview of all content." +msgstr "" +"本標準放在線上：[standard.publiccode.net](https://standard.publiccode.net/)。" +"請參閱 [`index.md`](index.md) 查看整體內容概覽。" + +#: ./README.md:block 16 (paragraph) +msgid "" +"[![Thumbnail for the video on the Standard for Public Code: a printed " +"version lying on a table between two " +"hands](https://img.youtube.com/vi/QWt6vB-" +"cipE/mqdefault.jpg)](https://www.youtube.com/watch?v=QWt6vB-cipE)" +msgstr "" +"[![《公共程式標準》的影片縮圖：兩隻手中間放著本標準的印刷本](https://img." +"youtube.com/vi/QWt6vB-cipE/mqdefault.jpg)](https://www.youtube.com/watch?v" +"=QWt6vB-cipE)" + +#: ./README.md:block 17 (paragraph) +msgid "" +"[A video introduction to Standard for Public " +"Code](https://www.youtube.com/watch?v=QWt6vB-cipE) from Creative Commons " +"Global Summit 2020 (4:12) on YouTube." +msgstr "" +"[《公共程式標準》的影片介紹](https://www.youtube.com/watch?v=QWt6vB-cipE)，" +"出自 Creative Commons Global Summit 2020 (4:12)，放在 YouTube 上。" + +#: ./README.md:block 18 (header) +msgid "Help improve this standard" +msgstr "幫忙改善這份標準" + +#: ./README.md:block 19 (paragraph) +msgid "" +"The Foundation for Public Code is committed to maintaining and developing " +"the Standard for Public Code at a level of quality that meets the standard " +"itself." +msgstr "Foundation for Public Code " +"致力於維護與開發《公共程式標準》，且使其同時符合該標準自身的品質水準。" + +#: ./README.md:block 20 (paragraph) +msgid "" +"We are looking for people like you to [contribute](CONTRIBUTING.md) to this " +"project by suggesting improvements and helping develop it. 😊 Get started by " +"reading our [contributors guide](CONTRIBUTING.md). Since it is such a core " +"document we will accept contributions when they add significant value. We've" +" described how we govern the standard in the [governance " +"statement](GOVERNANCE.md)." +msgstr "" +"我們正在尋找像您這樣的人，能對此專案做出[貢獻](CONTRIBUTING.md)，像是建議改善" +"方向，以及協助開發等。😊若要開始，請先參閱我們的[貢獻者指引](CONTRIBUTING.md)" +"。由於這是相當核心的文件，我們僅接受能帶來重大價值的貢獻。[治理方式聲明](GOVE" +"RNANCE.md)中有說明管理該標準的方式。" + +#: ./README.md:block 21 (paragraph) +msgid "" +"Please note that this project is released with a [code of " +"conduct](CODE_OF_CONDUCT.md). By participating in this project you agree to " +"abide by its terms. Please be lovely to all other community members." +msgstr "" +"請注意，本專案配合[行為守則](CODE_OF_CONDUCT." +"md)一同發行。如果要參加本專案，代表您同意遵守守則。請善待社群的所有其他成員。" + +#: ./README.md:block 22 (header) +msgid "Preview, build and deploy" +msgstr "預覽、建置、部署" + +#: ./README.md:block 23 (paragraph) +msgid "" +"The repository builds to a static site deployed at " +"[standard.publiccode.net](https://standard.publiccode.net/). It is built " +"with [GitHub pages](https://pages.github.com) and " +"[Jekyll](https://jekyllrb.com/)." +msgstr "" +"儲存庫會建置一個靜態網站，並部署至 [standard.publiccode.net](https://standard" +".publiccode.net/)。網站採用 [GitHub 頁面](https://pages.github.com) 與 " +"[Jekyll](https://jekyllrb.com/) 技術。" + +#: ./README.md:block 24 (paragraph) +msgid "" +"The content is made to be built with [Jekyll](http://jekyllrb.com/), which " +"means you will need ruby and ruby-bundler installed, for example:" +msgstr "" +"網站內容透過 [Jekyll](http://jekyllrb.com/) 技術建置。這代表您需要有安裝 " +"ruby 與 ruby-bundler，例如：" + +#: ./README.md:block 26 (paragraph) +msgid "" +"If `ruby` and `bundle` are installed, one can run `bundle install` after " +"which the site can be rendered with the `script/serve.sh` script." +msgstr "" +"一旦安裝好 `ruby` 與 `bundle` 後，就可以執行 `bundle install`，接著再利用 `" +"script/serve.sh` 命令稿轉譯呈現出網站成果。" + +#: ./README.md:block 27 (header) +msgid "Testing" +msgstr "測試" + +#: ./README.md:block 28 (paragraph) +msgid "" +"A variety of test scripts are included. The script `script/test-all.sh` " +"wraps running of all local tests." +msgstr "本專案內含許多測試命令稿。其中 `script/test-all.sh` " +"命令稿則統包執行所有本機測試。" + +#: ./README.md:block 29 (paragraph) +msgid "" +"See the scripts in the " +"[script](https://github.com/publiccodenet/standard/tree/main/script) folder." +msgstr "" +"請前往 [script](https://github.com/publiccodenet/standard/tree/main/script) " +"資料夾查看命令稿。" + +#: ./README.md:block 30 (header) +msgid "Generating a PDF of the Standard for Public Code" +msgstr "生成《公共程式標準》的 PDF 檔案" + +#: ./README.md:block 31 (paragraph) +msgid "" +"In addition to Jekyll, generating PDFs relies upon " +"[Weasyprint](https://weasyprint.org/) and " +"[QPDF](https://github.com/qpdf/qpdf). [Pandoc](https://pandoc.org/) can be " +"used to transform PDFs into `.epub`." +msgstr "" +"除了先前提到的 Jekyll 以外，想生成 PDF 檔，還需要依賴 " +"[Weasyprint](https://weasyprint.org/) 和 [QPDF](https://github.com/qpdf/" +"qpdf)。[Pandoc](https://pandoc.org/) 則可將 PDF 檔轉換成 `.epub` 檔。" + +#: ./README.md:block 32 (paragraph) +msgid "" +"To generate these kinds of files, the dependencies should be installed, for " +"example:" +msgstr "若要生成這類檔案，則應該要安裝依賴的軟體項目，例如：" + +#: ./README.md:block 34 (paragraph) +msgid "" +"The file `standard-print.html` can be converted to a nice looking PDF, along" +" with the other release files, using:" +msgstr "使用以下命令稿，可以將 `standard-print.html` 檔案轉換成美觀的 PDF " +"檔，同時包括其他發行用的檔案：" + +#: ./README.md:block 36 (header) +msgid "License" +msgstr "授權" + +#: ./README.md:block 37 (paragraph) +msgid "© [The authors and contributors](AUTHORS.md)" +msgstr "© [作者與貢獻者](AUTHORS.md)" + +#: ./README.md:block 38 (paragraph) +msgid "" +"The standard is [licensed](LICENSE) under CC 0, which also applies to all " +"illustrations and the documentation. This means anyone can do anything with " +"it. If you contribute you also grant these rights to others. You can read " +"more about how to help in the [contributing guide](CONTRIBUTING.md)." +msgstr "" +"本標準採用 CC0 " +"公眾領域貢獻宣告[給予授權](LICENSE)，該授權範圍涵蓋所有插圖與文件。CC0 代表任" +"何人都能任意使用這些內容。如果您是貢獻者，代表您也將這些權利賦予他人。若要進" +"一步瞭解如何協助本專案，請參閱〈[貢獻指引](CONTRIBUTING.md)〉。" + +#: ./criteria/bundle-policy-and-source-code.md:block 3 (paragraph) +msgid "order: 2 redirect_from:" +msgstr "order: 2 redirect_from:" + +#: ./criteria/bundle-policy-and-source-code.md:block 4 (unordered list) +msgid "criteria/bundle-policy-and-code" +msgstr "criteria/bundle-policy-and-code" + +#: ./criteria/bundle-policy-and-source-code.md:block 5 (header) +msgid "Bundle policy and source code" +msgstr "政策與原始碼要合捆" + +#: ./criteria/bundle-policy-and-source-code.md:block 6 (paragraph) +msgid "" +"Access to both [source code](../glossary.md#source-code) and " +"[policy](../glossary.md#policy) documentation provides building blocks for " +"anyone to implement the codebase in their local context or contribute to the" +" further development of the [codebase](../glossary.md#codebase)." +msgstr "" +"對於想根據所在情境實作程式基底的人，或是想更進一步貢獻[程式基底](../glossary." +"md#codebase)開發的人來說，能同時取用[原始碼](../glossary.md#source-" +"code)與[政策](../glossary.md#policy)文件兩者，可作為建置成品時的基礎組件。" + +#: ./criteria/bundle-policy-and-source-code.md:block 7 (paragraph) +msgid "" +"Understanding the domain and policies within that domain is fundamental to " +"understanding what problems a codebase is trying to solve and how it sets " +"out to solve them." +msgstr "瞭解作用範疇與該範疇的政策是基本原則，才能瞭解程式基底試圖想解決的問題是什麼" +"，以及該如何解決這些問題的作法。" + +#: ./criteria/bundle-policy-and-source-code.md:block 8 (paragraph) +msgid "" +"To be able to evaluate whether to implement a codebase in a new context, an " +"organization needs to understand what process changes it must choose to make" +" or how to contribute additional configurability to the existing solution in" +" order to adapt it to the new context." +msgstr "" +"為了評估是否需要在新的情境中實作程式基底，組織單位需要瞭解必須做出改變的程序" +"有哪些，或是如何對現有解決方案付出額外調整設定，以適應新的情境背景。" + +#: ./criteria/bundle-policy-and-source-code.md:block 9 (header) +msgid "Requirements" +msgstr "需求規定" + +#: ./criteria/bundle-policy-and-source-code.md:block 10 (unordered list) +msgid "The codebase MUST include the policy that the source code is based on." +msgstr "程式基底「必須」包含原始碼所根據的政策。" + +#: ./criteria/bundle-policy-and-source-code.md:block 10 (unordered list) +msgid "" +"If a policy is based on source code, that source code MUST be included in " +"the codebase, unless used for fraud detection." +msgstr "如果政策根據原始碼而來，則該原始碼「必須」包含在程式基底中，用於偵測詐騙的原" +"始碼則可除外。" + +#: ./criteria/bundle-policy-and-source-code.md:block 10 (unordered list) +msgid "Policy SHOULD be provided in machine readable and unambiguous formats." +msgstr "政策「應該」採用機器可讀且明確的格式。" + +#: ./criteria/bundle-policy-and-source-code.md:block 10 (unordered list) +msgid "" +"[Continuous integration](../glossary.md#continuous-integration) tests SHOULD" +" validate that the source code and the policy are executed coherently." +msgstr "[持續整合](../glossary.md#continuous-" +"integration)測試「應該」驗證原始碼與政策是否有一致執行。" + +#: ./criteria/bundle-policy-and-source-code.md:block 11 (header) +msgid "How to test" +msgstr "測試方式" + +#: ./criteria/bundle-policy-and-source-code.md:block 12 (unordered list) +msgid "" +"Confirm with a civil servant that all policy that the source code is based " +"on is included." +msgstr "與公務人員確認原始碼所根據的所有政策內容都有收錄在內。" + +#: ./criteria/bundle-policy-and-source-code.md:block 12 (unordered list) +msgid "" +"Confirm with a civil servant that all source code that the policy is based " +"on is included." +msgstr "與公務人員確認政策所根據的所有原始碼都有收錄在內。" + +#: ./criteria/bundle-policy-and-source-code.md:block 12 (unordered list) +msgid "Check if policy can be interpreted by a machine." +msgstr "確認政策內容是否能在機器上解讀。" + +#: ./criteria/bundle-policy-and-source-code.md:block 12 (unordered list) +msgid "" +"Check the continuous integration tests for coherent execution of source code" +" and policy pass." +msgstr "確認原始碼與政策間的執行一致性能通過持續整合測試。" + +#: ./criteria/bundle-policy-and-source-code.md:block 13 (header) +msgid "Public policy makers: what you need to do" +msgstr "公共政策制定者：需要的工作" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Collaborate with developers and designers to make sure there is no mismatch " +"between policy code and source code." +msgstr "與開發人員及設計師合作，確保政策法規與原始碼之間沒有不相符之處。" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Provide the relevant policy texts for inclusion in the " +"[repository](../glossary.md#repository); if the text is not available in " +"English, also provide an English summary. Be sure to include standards that " +"your organization has chosen to adhere to and any organizational processes " +"which impact the development or the deployment context of the codebase for " +"your organization." +msgstr "" +"提供相關政策內文，以便收錄於[儲存庫](../glossary.md#repository)中；如果政策內" +"文沒有英文版，請提供英文版摘要。務必也同時包含貴組織單位所選擇遵守的各項標準" +"，以及影響貴組織單位程式基底開發或部署情境的任何組織單位流程。" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "Provide references and links to texts which support the policies." +msgstr "請提供政策相關參考資料與連結。" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Document policy in formats that are unambiguous and machine-readable, such " +"as those published by the [Object Management " +"Group](https://www.omg.org/spec/)." +msgstr "政策內容請使用明確且機器可讀的格式，像是[物件管理群體](https://www.omg.org/" +"spec/)所發表的格式。" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Track policy with [the same version control](maintain-version-control.md) " +"and documentation used to track source code." +msgstr "追蹤政策時，請使用與追蹤原始碼[相同的版本控制](maintain-version-control." +"md)與文件。" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Check in regularly to understand how the source code in the codebase has " +"changed and whether it still matches the [intentions of the " +"policy](document-codebase-objectives.md)." +msgstr "定期檢查，瞭解程式基底中的原始碼如何變動，以及是否仍然符合[政策意圖" +"](document-codebase-objectives.md)。" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Include relevant policies which impact the community, codebase, and " +"development, including legal obligations like the [General Data Protection " +"Regulation](https://eur-lex.europa.eu/eli/reg/2016/679/oj) or the [EU Web " +"Accessibility Directive](https://ec.europa.eu/digital-single-market/en/web-" +"accessibility), or human rights policies, like a public organization's " +"commitment to equal opportunity." +msgstr "" +"納入會影響社會群體、程式基底與開發目標的相關政策，包含 [GDPR " +"一般資料保護規則](https://eur-lex.europa.eu/eli/reg/2016/679/" +"oj)或是[歐盟網頁無障礙命令](https://ec.europa.eu/digital-single-market/en/" +"web-accessibility)等此類法律義務，或者是人權政策，例如公家機關對機會平等的承" +"諾等。" + +#: ./criteria/bundle-policy-and-source-code.md:block 15 (header) +msgid "Managers: what you need to do" +msgstr "管理人員：需要的工作" + +#: ./criteria/bundle-policy-and-source-code.md:block 16 (unordered list) +msgid "" +"Keep policy makers, developers and designers involved and connected " +"throughout the whole development process." +msgstr "讓政策制定者、開發人員與設計師持續參與，並且在整個開發過程中保持聯繫溝通。" + +#: ./criteria/bundle-policy-and-source-code.md:block 16 (unordered list) +msgid "" +"Make sure policy makers, developers and designers are working to the same " +"objectives." +msgstr "確保政策制定者、開發人員與設計師朝相同目標努力。" + +#: ./criteria/bundle-policy-and-source-code.md:block 17 (header) +msgid "Developers and designers: what you need to do" +msgstr "開發人員與設計師：需要的工作" + +#: ./criteria/bundle-policy-and-source-code.md:block 18 (unordered list) +msgid "" +"Become familiar with and be able to use the process modelling notation that " +"the policy makers in your organization use." +msgstr "熟悉並且學會貴組織單位政策制定者所使用的流程模型標記法。" + +#: ./criteria/bundle-policy-and-source-code.md:block 18 (unordered list) +msgid "" +"Work together with policy makers to make sure there is no mismatch between " +"policy code and source code." +msgstr "與政策制定者一同合作，確保政策法規與原始碼之間沒有不相符之處。" + +#: ./criteria/bundle-policy-and-source-code.md:block 18 (unordered list) +msgid "Give feedback on how to make policy documentation more clear." +msgstr "針對如何讓政策文字更清楚提供意見。" + +#: ./criteria/bundle-policy-and-source-code.md:block 19 (header) +msgid "Further reading" +msgstr "延伸閱讀" + +#: ./criteria/bundle-policy-and-source-code.md:block 20 (unordered list) +msgid "" +"[Business Process Model and " +"Notation](https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation)" +" on Wikipedia." +msgstr "" +"維基百科上的 [BPMN 業務流程模型與標記法](https://en.wikipedia.org/wiki/" +"Business_Process_Model_and_Notation)。" + +#: ./criteria/bundle-policy-and-source-code.md:block 20 (unordered list) +msgid "" +"[BPMN Quick Guide](https://www.bpmnquickguide.com/view-bpmn-quick-guide/) by" +" Trisotech." +msgstr "" +"Trisotech 提供的 [BPMN 快速指南](https://www.bpmnquickguide.com/" +"view-bpmn-quick-guide/)。" + +#: ./criteria/bundle-policy-and-source-code.md:block 20 (unordered list) +msgid "" +"[Decision Model and " +"Notation](https://en.wikipedia.org/wiki/Decision_Model_and_Notation) on " +"Wikipedia." +msgstr "" +"維基百科上的 [DMN 決策模型與標記法](https://en.wikipedia.org/wiki/" +"Decision_Model_and_Notation)。" + +#: ./criteria/bundle-policy-and-source-code.md:block 20 (unordered list) +msgid "" +"[Case Management Model Notation](https://en.wikipedia.org/wiki/CMMN) on " +"Wikipedia." +msgstr "維基百科上的[ CMMN 案例管理模型標記法](https://en.wikipedia.org/wiki/CMMN)。" + +#: ./criteria/code-in-the-open.md:block 3 (header) +msgid "order: 1" +msgstr "order: 1" + +#: ./criteria/code-in-the-open.md:block 4 (header) +msgid "Code in the open" +msgstr "原始碼要開放" + +#: ./criteria/code-in-the-open.md:block 5 (paragraph) +msgid "" +"Coding in the open improves transparency, increases [source " +"code](../glossary.md#source-code) quality, makes the source code easier to " +"audit, and enables collaboration." +msgstr "" +"以開放精神編寫原始碼，能改善資訊透明、提高[原始碼](../glossary.md#source-" +"code)品質、讓原始碼更容易稽核，也能促進互相協作。" + +#: ./criteria/code-in-the-open.md:block 6 (paragraph) +msgid "" +"Together, this creates more opportunities for citizens to understand how " +"software and [policy](../glossary.md#policy) impact their interactions with " +"a public organization." +msgstr "這些合在一起，讓公民更有機會瞭解軟體與[政策](../glossary." +"md#policy)如何影響他們與公家機關的互動。" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"All source code for any policy in use (unless used for fraud detection) MUST" +" be published and publicly accessible." +msgstr "任何使用中政策的所有原始碼都「必須」要公開（用於偵測詐欺的原始碼除外），且能" +"供民眾取用。" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"All source code for any software in use (unless used for fraud detection) " +"MUST be published and publicly accessible." +msgstr "任何使用中軟體的所有原始碼都「必須」要公開（用於偵測詐欺的原始碼除外），且能" +"供民眾取用。" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"The codebase MUST NOT contain sensitive information regarding users, their " +"organization or third parties." +msgstr "程式基底「禁止」包含與使用者及其組織單位，或與第三方相關的敏感性資訊。" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"Any source code not currently in use (such as new versions, proposals or " +"older versions) SHOULD be published." +msgstr "目前非使用中的任何原始碼（像是新版本、提案版本，或較舊版本）都「應該」公開。" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"Documenting which source code or policy underpins any specific interaction " +"the [general public](../glossary.md#general-public) may have with an " +"organization is OPTIONAL." +msgstr "" +"「可選擇」是否要以文件記錄[一般大眾](../glossary.md#general-public)與組織單位" +"之間可能發生的任何特定互動，其背後所採用的原始碼或支持的政策。" + +#: ./criteria/code-in-the-open.md:block 10 (unordered list) +msgid "" +"Confirm that the source for each version currently in use is published on " +"the internet where it can be seen from outside the original contributing " +"organization and without the need for any form of authentication or " +"authorization." +msgstr "確認目前使用中的每個版本都有公布原始碼在網際網路上，而且民眾不需要經過任何形" +"式的身分核對或授權，就能在原始貢獻組織以外，查看這些原始碼。" + +#: ./criteria/code-in-the-open.md:block 10 (unordered list) +msgid "" +"Confirm that the [codebase](../glossary.md#codebase) files and commit " +"history do not include sensitive information." +msgstr "確認[程式基底](../glossary." +"md#codebase)檔案與送交版次歷史紀錄，不包含敏感性資訊。" + +#: ./criteria/code-in-the-open.md:block 10 (unordered list) +msgid "Check for the publication of source code not currently in use." +msgstr "檢查目前非使用中的原始碼是否有公開。" + +#: ./criteria/code-in-the-open.md:block 12 (unordered list) +msgid "Develop policies in the open." +msgstr "制定合乎開放精神的政策。" + +#: ./criteria/code-in-the-open.md:block 12 (unordered list) +msgid "Prioritize open and transparent policies." +msgstr "以公開透明的政策為優先。" + +#: ./criteria/code-in-the-open.md:block 14 (unordered list) +msgid "Develop a culture that embraces openness, learning and feedback." +msgstr "孕育擁抱開放、重視學習、歡迎意見回饋的文化。" + +#: ./criteria/code-in-the-open.md:block 14 (unordered list) +msgid "" +"Collaborate with external vendors and freelancers by working in the open." +msgstr "與外部供應商和自由工作者以開放精神的方式協作。" + +#: ./criteria/code-in-the-open.md:block 16 (unordered list) +msgid "" +"As a reviewer, for each commit, verify that content does not include " +"sensitive information such as configurations, usernames or passwords, public" +" keys or other real credentials used in production systems." +msgstr "審查人員在檢核每次的送交版次紀錄時，要確實核對內容沒有包含組態設定、使用者名" +"稱或密碼、公開金鑰，或其他產品系統中使用的實名憑證等敏感性資訊。" + +#: ./criteria/code-in-the-open.md:block 16 (unordered list) +msgid "" +"Clearly split data and source code, in order to meet the requirement about " +"sensitive information above." +msgstr "為符合上述敏感性資訊的相關規定，請明確分開資料與原始碼。" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[Coding in the open](https://gds.blog.gov.uk/2012/10/12/coding-in-the-open/)" +" by the UK Government Digital Service." +msgstr "" +"英國政府數位服務團《[以開放精神編寫原始碼](https://gds.blog.gov.uk/2012/10/12/coding-in-the-" +"open/)》。" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[When code should be open or " +"closed](https://www.gov.uk/government/publications/open-source-" +"guidance/when-code-should-be-open-or-closed) by the UK Government Digital " +"Service." +msgstr "" +"英國政府數位服務團《[程式碼應該開放或封閉的時機](https://www.gov.uk/government/publications/open-" +"source-guidance/when-code-should-be-open-or-closed)》。" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[Security considerations when coding in the " +"open](https://www.gov.uk/government/publications/open-source-" +"guidance/security-considerations-when-coding-in-the-open) by the UK " +"Government Digital Service." +msgstr "" +"英國政府數位服務團《[以開放精神編寫原始碼的資安考量](https://www.gov.uk/government/publications/open-" +"source-guidance/security-considerations-when-coding-in-the-open)》。" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[Deploying software regularly](https://www.gov.uk/service-" +"manual/technology/deploying-software-regularly) by the UK Government Digital" +" Service." +msgstr "" +"英國政府數位服務團《[定期部署軟體](https://www.gov.uk/service-manual/technology/deploying-" +"software-regularly)》。" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[How GDS uses GitHub](https://gdstechnology.blog.gov.uk/2014/01/27/how-we-" +"use-github/) by the UK Government Digital Service." +msgstr "" +"英國政府數位服務團《[政府數位服務團如何使用 " +"GitHub](https://gdstechnology.blog.gov.uk/2014/01/27/how-we-use-github/)》。" + +#: ./criteria/document-codebase-maturity.md:block 3 (header) +msgid "" +"order: 16 redirect_from: - criteria/advertise-maturity - criteria/document-" +"maturity" +msgstr "" +"order: 16 redirect_from: - criteria/advertise-maturity - criteria/document-" +"maturity" + +#: ./criteria/document-codebase-maturity.md:block 4 (header) +msgid "Document codebase maturity" +msgstr "記錄程式基底成熟度" + +#: ./criteria/document-codebase-maturity.md:block 5 (paragraph) +msgid "" +"Clearly signalling a [codebase](../glossary.md#codebase)'s maturity helps " +"others decide whether to use and contribute to it. A codebase version's " +"maturity includes the maturity of its dependencies. Understanding how a " +"codebase has evolved is key to understanding the codebase and how to " +"contribute to it." +msgstr "" +"清楚標示[程式基底](../glossary.md#codebase)的成熟度，有助於他人決定是否要使用" +"，或為該程式基底做出貢獻。程式基底版本的成熟度，包含其依賴項目的成熟度。瞭解" +"程式基底演進到什麼程度，是理解該程式基底並知道如何做出貢獻的關鍵。" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "The codebase MUST be versioned." +msgstr "程式基底「必須」註明版本編號。" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "" +"The codebase MUST prominently document whether or not there are versions of " +"the codebase that are ready to use." +msgstr "程式基底「必須」明確以文件記錄，是否有已經準備好可供使用的版本。" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "" +"Codebase versions that are ready to use MUST only depend on versions of " +"other codebases that are also ready to use." +msgstr "準備好可供使用的程式基底版本，「必須」只能依賴其他也已經準備好可供使用的程式" +"基底版本。" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "" +"The codebase SHOULD contain a log of changes from version to version, for " +"example in the `CHANGELOG`." +msgstr "程式基底「應該」包含每次版本的變動紀錄，像是以「`CHANGELOG`」日誌格式檔記錄。" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "The method for assigning version identifiers SHOULD be documented." +msgstr "「應該」要以文件記錄分配版本識別碼的方法。" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "It is OPTIONAL to use semantic versioning." +msgstr "「可選擇」是否採用語意化版本控制編號。" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "" +"Confirm that the codebase has a strategy for versioning which is documented." +msgstr "確認程式基底有版本編號策略，且有文件記載該策略。" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "" +"Confirm that it is obvious to policy makers, managers, developers and " +"designers whether the codebase has versions that are ready to use." +msgstr "確認政策制定者、管理人員、開發人員與設計師等，都能清楚知道程式基底是否有準備" +"好可供使用的版本。" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "" +"Confirm that ready to use versions of the codebase do not depend on any " +"versions of other codebases that are not ready to use." +msgstr "確認準備好可供使用的程式基底版本，並不依賴任何尚未準備好可供使用的其他程式基" +"底的版本。" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "" +"Check that the versioning scheme of the codebase is documented and followed." +msgstr "確認有文件記錄程式基底的版本編號方法，並且確實遵守。" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "Check that there is a log of changes." +msgstr "確認是否有版本的變動紀錄。" + +#: ./criteria/document-codebase-maturity.md:block 11 (unordered list) +msgid "" +"When developing [policy](../glossary.md#policy), understand that any [source" +" code](../glossary.md#source-code) developed needs to be tested and improved" +" before it can be put into service." +msgstr "" +"制定[政策](../glossary.md#policy)時，請記住任何開發出來的[原始碼](../glossary" +".md#source-code)都必須先經過測試與改善，才能夠投入服務。" + +#: ./criteria/document-codebase-maturity.md:block 11 (unordered list) +msgid "" +"Consider versioning policy changes, especially when they trigger new " +"versions of the source code." +msgstr "考慮將政策的變動註明版本編號，尤其是因而觸發新版本原始碼開發的情況。" + +#: ./criteria/document-codebase-maturity.md:block 13 (unordered list) +msgid "" +"Make sure that services only rely on versions of codebases of equal or " +"greater maturity than the service. For example, don't use a beta version of " +"a codebase in a production service." +msgstr "要確認服務依賴的程式基底版本成熟度，等同或高於該服務本身。舉例來說，" +"正式上線的服務不要使用 beta 公測版程式基底。" + +#: ./criteria/document-codebase-maturity.md:block 15 (unordered list) +msgid "" +"Make sure that the codebase versioning approach is followed for all " +"releases." +msgstr "確認所有發行版，都有遵守程式基底的版本控制編號作法。" + +#: ./criteria/document-codebase-maturity.md:block 17 (unordered list) +msgid "" +"[Semantic Versioning Specification](https://semver.org/) used by many " +"codebases to label versions." +msgstr "許多程式基底使用「[語意化版本編號規範](https://semver.org/)」來標示版本。" + +#: ./criteria/document-codebase-maturity.md:block 17 (unordered list) +msgid "" +"[Software release life " +"cycle](https://en.wikipedia.org/wiki/Software_release_life_cycle)" +msgstr "[軟體發行生命週期](https://en.wikipedia.org/wiki/Software_release_life_cycle)" + +#: ./criteria/document-codebase-maturity.md:block 17 (unordered list) +msgid "" +"[Service Design and Delivery Process](https://www.dta.gov.au/help-and-" +"advice/build-and-improve-services/service-design-and-delivery-process) by " +"the Australian Digital Transformation Agency." +msgstr "" +"澳洲數位轉型局《[服務設計與交付流程](https://www.dta.gov.au/help-and-advice/build-and-" +"improve-services/service-design-and-delivery-process)》。" + +#: ./criteria/document-codebase-maturity.md:block 17 (unordered list) +msgid "" +"[Service Manual on Agile Delivery](https://www.gov.uk/service-manual/agile-" +"delivery) by the UK Government Digital Service." +msgstr "" +"英國政府數位服務團《[敏捷交付服務手冊](https://www.gov.uk/service-manual/agile-delivery)》。" + +#: ./criteria/document-codebase-objectives.md:block 3 (paragraph) +msgid "order: 8 redirect_from:" +msgstr "order: 8 redirect_from:" + +#: ./criteria/document-codebase-objectives.md:block 4 (unordered list) +msgid "criteria/document-objectives" +msgstr "criteria/document-objectives" + +#: ./criteria/document-codebase-objectives.md:block 5 (header) +msgid "Document codebase objectives" +msgstr "程式基底要有目標文件" + +#: ./criteria/document-codebase-objectives.md:block 6 (paragraph) +msgid "" +"Clearly documenting [codebase](../glossary.md#codebase) objectives " +"communicates the purpose of the codebase. It helps stakeholders and " +"contributors scope the development of the codebase. The objectives also " +"provide an easy way for people to decide whether this codebase, or one of " +"its modules, is interesting for them now or in the future." +msgstr "" +"以文件清楚記錄[程式基底](../glossary.md#codebase)目標，來傳達程式基底的用途目" +"標。這能幫助利害關係人與貢獻者劃定程式基底的開發範圍。這些目標也能方便人們判" +"斷，是否在當下或未來，會對此程式基底或其模組感興趣。" + +#: ./criteria/document-codebase-objectives.md:block 8 (unordered list) +msgid "" +"The codebase MUST contain documentation of its objectives, like a mission " +"and goal statement, that is understandable by developers and designers so " +"that they can use or contribute to the codebase." +msgstr "程式基底「必須」包含描寫目標的文件，像是主旨、使命或目標陳述。開發人員與設計" +"師需要能夠瞭解這些，他們才知道可以怎樣使用程式基底或協助貢獻。" + +#: ./criteria/document-codebase-objectives.md:block 8 (unordered list) +msgid "" +"Codebase documentation SHOULD clearly describe the connections between " +"[policy](../glossary.md#policy) objectives and codebase objectives." +msgstr "程式基底文件「應該」清楚描述[政策](../glossary." +"md#policy)目標與程式基底目標之間的關聯。" + +#: ./criteria/document-codebase-objectives.md:block 8 (unordered list) +msgid "" +"Documenting the objectives of the codebase for the [general " +"public](../glossary.md#general-public) is OPTIONAL." +msgstr "「可選擇」是否以文件記錄給[一般大眾](../glossary.md#general-" +"public)看的程式基底目標。" + +#: ./criteria/document-codebase-objectives.md:block 10 (unordered list) +msgid "" +"Confirm that the codebase documentation includes the codebase objectives, " +"mission or goal." +msgstr "確認程式基底文件有包含程式基底目標，或主旨、使命等。" + +#: ./criteria/document-codebase-objectives.md:block 10 (unordered list) +msgid "" +"Check for descriptions of connections between policy objectives and codebase" +" objectives." +msgstr "查看政策目標與程式基底目標之間關聯的描述。" + +#: ./criteria/document-codebase-objectives.md:block 12 (unordered list) +msgid "" +"Add the policy objectives to the codebase documentation, for example in the " +"`README`." +msgstr "將政策目標加入程式基底文件中，例如「`README`」文件當中。" + +#: ./criteria/document-codebase-objectives.md:block 12 (unordered list) +msgid "" +"Make sure that all your codebase objectives have links or references to " +"supporting policy documents added to meet the [Bundle policy and source " +"code](bundle-policy-and-source-code.md) criterion." +msgstr "" +"確保所有程式基底目標，有連結或引用為了符合〈[政策與原始碼要合捆](bundle-" +"policy-and-source-code.md)〉準則而加入的支持政策文件。" + +#: ./criteria/document-codebase-objectives.md:block 14 (unordered list) +msgid "" +"Add the organizational and business objectives to the codebase " +"documentation, for example in the `README`." +msgstr "將單位目標、組織目標或業務目標加入程式基底文件中，例如「`README`」文件當中。" + +#: ./criteria/document-codebase-objectives.md:block 16 (unordered list) +msgid "" +"Add the technology and design objectives to the codebase documentation, for " +"example in the `README`." +msgstr "將技術與設計目標加入程式基底文件中，例如「`README`」文件當中。" + +#: ./criteria/document-codebase-objectives.md:block 18 (unordered list) +msgid "" +"[How to write project " +"objectives](http://grouper.ieee.org/groups/802/3/RTPGE/public/may12/hajduczenia_01_0512.pdf)" +" by Marek Hajduczenia." +msgstr "" +"Marek " +"Hajduczenia《[如何撰寫專案目標](http://grouper.ieee.org/groups/802/3/RTPGE/public/may12/hajduczenia_01_0512.pdf)》。" + +#: ./criteria/document-the-code.md:block 3 (paragraph) +msgid "order: 9 redirect_from:" +msgstr "order: 9 redirect_from:" + +#: ./criteria/document-the-code.md:block 4 (unordered list) +msgid "criteria/documenting" +msgstr "criteria/documenting" + +#: ./criteria/document-the-code.md:block 5 (header) +msgid "Document the code" +msgstr "程式碼要有文件" + +#: ./criteria/document-the-code.md:block 6 (paragraph) +msgid "" +"Well documented [source code](../glossary.md#source-code) helps people to " +"understand what the source code does and how to use it. Documentation is " +"essential for people to start using the [codebase](../glossary.md#codebase) " +"and contributing to it more quickly." +msgstr "" +"文件記錄周全的[原始碼](../glossary.md#source-code)能幫助人們瞭解該原始碼的作" +"用與使用方式。文件紀錄是幫助人們快速上手如何使用[程式基底](../glossary." +"md#codebase)，並做出貢獻的關鍵。" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"All of the functionality of the codebase, [policy](../glossary.md#policy) as" +" well as source code, MUST be described in language clearly understandable " +"for those that understand the purpose of the codebase." +msgstr "" +"程式基底的所有功能、[政策](../glossary.md#policy)及原始碼，都「必須」以可清楚" +"瞭解的用語描述，讓懂程式基底目的用途的人也能夠理解。" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase MUST contain a description of how to " +"install and run the software." +msgstr "程式基底文件「必須」說明如何安裝與執行軟體。" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase MUST contain examples demonstrating the " +"key functionality." +msgstr "程式基底文件「必須」為關鍵功能舉出範例。" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase SHOULD contain a high level description " +"that is clearly understandable for a wide audience of stakeholders, like the" +" [general public](../glossary.md#general-public) and journalists." +msgstr "" +"程式基底文件「應該」包含精要的說明，讓[一般大眾](../glossary.md#general-" +"public)和記者等廣泛的利害關係人都能清楚明白。" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase SHOULD contain a section describing how to" +" install and run a standalone version of the source code, including, if " +"necessary, a test dataset." +msgstr "程式基底文件「應該」有一部分用來說明，如何安裝與執行原始碼的單機版；如果有必" +"要，也應該包含測試資料集。" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase SHOULD contain examples for all " +"functionality." +msgstr "程式基底文件「應該」包含所有功能的範例。" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation SHOULD describe the key components or modules of the " +"codebase and their relationships, for example as a high level architectural " +"diagram." +msgstr "程式碼文件「應該」描述程式基底的主要組件或模組，以及其彼此之間的關係，例如以" +"高層架構圖表示。" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"There SHOULD be [continuous integration](../glossary.md#continuous-" +"integration) tests for the quality of the documentation." +msgstr "「應該」要有針對文件品質的[持續整合](../glossary.md#continuous-" +"integration)測試。" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"Including examples that make users want to immediately start using the " +"codebase in the documentation of the codebase is OPTIONAL." +msgstr "「可選擇」是否在程式基底文件中，包含讓使用者想要立即使用程式基底的範例。" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Confirm that other stakeholders, professionals from other public " +"organizations and the general public find the documentation clear and " +"understandable." +msgstr "確認文件內容能讓其他利害關係人、其他公家機關的專業人士，以及一般大眾，都可以" +"清楚明白。" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Confirm that the documentation describes how to install and run the source " +"code." +msgstr "確認文件有說明如何安裝與執行原始碼。" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Confirm that the documentation includes examples of the key functionality." +msgstr "確認文件有包含主要功能的範例。" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Check with members of the general public and journalists if they can " +"understand the high level description." +msgstr "向一般大眾的成員以及記者確認，他們是否能明白文件當中的精要說明。" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Check that the instructions for how to install and run a standalone version " +"of the source code result in a running system." +msgstr "檢查單機版原始碼的安裝與執行的步驟說明，確認能順利執行系統。" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "Check that all functionality documented contains an example." +msgstr "檢查文件中列舉的所有功能都包含範例。" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Check that the documentation includes a high level architectural diagram or " +"similar." +msgstr "檢查文件中是否包含高層架構圖，或類似的組件關係圖表。" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Check that the documentation quality is part of integration testing, for " +"example documentation is generated correctly, and links and images are " +"tested." +msgstr "確認整合測試有包含到程式碼文件品質，例如確認生成的文件是否正確，並檢查連結與" +"圖片等。" + +#: ./criteria/document-the-code.md:block 12 (unordered list) +msgid "" +"Check in regularly to understand how the non-policy code in the codebase has" +" changed." +msgstr "定期查看程式基底中非政策程式碼的變動情況。" + +#: ./criteria/document-the-code.md:block 12 (unordered list) +msgid "Give feedback on how to make non-policy documentation more clear." +msgstr "針對如何讓非政策文件更清楚易懂提供意見回饋。" + +#: ./criteria/document-the-code.md:block 14 (unordered list) +msgid "" +"Try to use the codebase, so your feedback can improve how clearly the policy" +" and source code are documented. For example, is the current documentation " +"sufficient to persuade a manager at another public organization to use this " +"codebase?" +msgstr "" +"嘗試使用程式基底，並提供您的意見回饋來讓政策與原始碼文件改善得更加清楚。舉例" +"來說，可以自問目前的文件是否足以說服另一個公家機關的管理人員使用這套程式基底" +"？" + +#: ./criteria/document-the-code.md:block 14 (unordered list) +msgid "" +"Make sure you understand both the policy and source code as well as the " +"documentation." +msgstr "確保您同時瞭解政策、原始碼以及文件內容。" + +#: ./criteria/document-the-code.md:block 16 (unordered list) +msgid "" +"Check in regularly to understand how the non-source code in the codebase has" +" changed." +msgstr "定期查看程式基底中非原始碼部分的變動情況。" + +#: ./criteria/document-the-code.md:block 16 (unordered list) +msgid "Give feedback on how to make non-source documentation more clear." +msgstr "針對如何讓非原始碼文件更清楚易懂提供意見回饋。" + +#: ./criteria/document-the-code.md:block 18 (unordered list) +msgid "" +"[Documentation guide](https://www.writethedocs.org/guide/) by Write the " +"Docs." +msgstr "Write the Docs《[文件指南](https://www.writethedocs.org/guide/)》。" + +#: ./criteria/index.md:block 3 (header) +msgid "order: 0" +msgstr "order: 0" + +#: ./criteria/index.md:block 4 (header) +msgid "Criteria" +msgstr "準則" + +#: ./criteria/index.md:block 5 (paragraph) +msgid "{% assign sorted = site.pages | sort:\"order\" %}" +msgstr "{% assign sorted = site.pages | sort:\"order\" %}" + +#: ./criteria/index.md:block 6 (paragraph) +msgid "" +"{% for page in sorted %}{% if page.dir == \"/criteria/\" %}{% if page.name " +"!= \"index.md\" %}{% if page.title %}" +msgstr "" +"{% for page in sorted %}{% if page.dir == \"/criteria/\" %}{% if page.name " +"!= \"index.md\" %}{% if page.title %}" + +#: ./criteria/index.md:block 7 (ordered list) +msgid "" +"[{{page.title}}]({{page.url}}){% endif%} {% endif%} {% endif%}{% endfor %}" +msgstr "" +"[{{page.title}}]({{page.url}}){% endif%} {% endif%} {% endif%}{% endfor %}" + +#: ./criteria/maintain-version-control.md:block 3 (paragraph) +msgid "order: 6 redirect_from:" +msgstr "order: 6 redirect_from:" + +#: ./criteria/maintain-version-control.md:block 4 (unordered list) +msgid "criteria/version-control-and-history" +msgstr "criteria/version-control-and-history" + +#: ./criteria/maintain-version-control.md:block 5 (header) +msgid "Maintain version control" +msgstr "維護版本控制" + +#: ./criteria/maintain-version-control.md:block 6 (paragraph) +msgid "" +"[Version control](../glossary.md#version-control) means keeping track of " +"changes to the [source code](../glossary.md#source-code) and other files of " +"the [codebase](../glossary.md#codebase) over time. This allows you to " +"maintain structured documentation of the history of the codebase. This is " +"essential for collaboration at scale, as it enables developers to work on " +"changes in parallel and helps future developers to understand the reasons " +"for changes." +msgstr "" +"[版本控制](../glossary.md#version-control)主要在追蹤[原始碼](../glossary.md" +"#source-code)以及其他[程式基底](../glossary.md#codebase)檔案歷來的變動。這能" +"讓您為程式基底維護有條理的變動歷史文件。這是大規模協作得以運作的要素，使開發" +"人員可以針對修改變動平行作業，並幫助未來的開發人員瞭解做出修改的原因。" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "All files in the codebase MUST be version controlled." +msgstr "程式基底中的所有檔案皆「必須」有版本控制。" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "All decisions MUST be documented in commit messages." +msgstr "所有決定皆「必須」記錄成送交版次訊息。" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"Every commit message MUST link to discussions and issues wherever possible." +msgstr "每份送交版次訊息皆「必須」盡可能附上討論與議題連結。" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"The codebase SHOULD be maintained in a distributed version control system." +msgstr "程式基底「應該」以分散式版本控制系統作維護。" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"Contribution guidelines SHOULD require contributors to group relevant " +"changes in commits." +msgstr "貢獻守則「應該」要求貢獻者，將相關的修改變動以群組分類方式送交。" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"Maintainers SHOULD mark released versions of the codebase, for example using" +" revision tags or textual labels." +msgstr "維護人員「應該」使用像是修訂版次標記，或文字標籤，來標示程式基底正式發行的版" +"本。" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"Contribution guidelines SHOULD encourage file formats where the changes " +"within the files can be easily viewed and understood in the version control " +"system." +msgstr "貢獻守則「應該」鼓勵採用能在版本控制系統中，輕鬆檢視與瞭解檔案中何處有做出更" +"動的檔案格式。" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"It is OPTIONAL for contributors to sign their commits and provide an email " +"address, so that future contributors are able to contact past contributors " +"with questions about their work." +msgstr "貢獻者「可選擇」是否對送交內容作簽章，並附上電子郵件信箱，以便當未來貢獻者對" +"其內容有疑問時，可以與之前的貢獻者聯絡。" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Confirm that the codebase is kept in version control using software such as " +"Git." +msgstr "確認程式基底維持在版本控制狀態中，像是使用 Git 之類的軟體。" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Review the commit history, confirming that all commit messages explain why " +"the change was made." +msgstr "審查送交版次歷史紀錄，確認所有的送交版次訊息，皆有解釋程式碼修改變動的原因。" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Review the commit history, confirming that where possible all commit " +"messages include the discussion about the change was or where to find it " +"(with a URL)." +msgstr "審查送交版次歷史紀錄，確認所有送交版次訊息之中，盡可能在所有討論過修改變更的" +"地方，包含變動內容以及連結位置（提供網址）。" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "Check if the version control system is distributed." +msgstr "檢查版本控制系統是否為分散式。" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Review the commit history, check if grouping of relevant changes in " +"accordance with the contributing guidelines." +msgstr "審查送交版次歷史紀錄，檢查是否有根據貢獻指引將相關的程式碼變動以群組分類。" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Check that it is possible to access a specific version of the codebase, for " +"example through a revision tag or a textual label." +msgstr "檢查是否可能透過像是修訂版次標記，或文字標籤，來取用程式基底中的特定版本。" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Check that the file formats used in the codebase are text formats where " +"possible." +msgstr "檢查程式基底在盡可能的情況下，檔案都是採用文字格式。" + +#: ./criteria/maintain-version-control.md:block 12 (unordered list) +msgid "" +"If a new version of the codebase is created because of a " +"[policy](../glossary.md#policy) change, make sure it's clear in the " +"documentation:" +msgstr "如果因為[政策](../glossary." +"md#policy)改變而在程式基底中有新的版本，則請確認有在文件中清楚說明：" + +#: ./criteria/maintain-version-control.md:block 12 (unordered list) +msgid "what the policy change is," +msgstr "政策改變的地方，" + +#: ./criteria/maintain-version-control.md:block 12 (unordered list) +msgid "how it's changed the codebase." +msgstr "程式基底如何因應而改變。" + +#: ./criteria/maintain-version-control.md:block 13 (paragraph) +msgid "" +"For example, adding a new category of applicant to a codebase that manages " +"granting permits would be considered a policy change." +msgstr "舉例來說，為程式基底作權限管理時，如果要新增申請方類別來賦予取用權，應視為一" +"種政策變動。" + +#: ./criteria/maintain-version-control.md:block 15 (unordered list) +msgid "" +"Support policy makers, developers and designers to be clear about what " +"improvements they're making to the codebase. Making improvements isn't a " +"public relations risk." +msgstr "支持政策制定者、開發人員與設計師，使其能清楚表達他們對程式基底做出的改善。確" +"保改善程式基底不會有公關風險。" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "" +"Make sure that all files required to understand the code, build and deploy " +"are in the version control system." +msgstr "確認版本控制系統中，有瞭解程式碼、建置與部署所需要用到的所有檔案。" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "" +"Write clear commit messages so that it is easy to understand why the commit " +"was made." +msgstr "送交版次訊息要寫清楚，讓人一看就能瞭解送交修改的原因。" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "" +"Mark different versions so that it is easy to access a specific version, for" +" example using revision tags or textual labels." +msgstr "使用像是修訂版次標記，或文字標籤來標示不同版本，以方便取用特定版本。" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "Write clear commit messages so that versions can be usefully compared." +msgstr "送交版次訊息要寫清楚，方便之後比較各版本。" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "" +"Work with policy makers to describe how the source code was updated after a " +"policy change." +msgstr "在政策改變以後，與政策制定者合作說明原始碼更新的部分。" + +#: ./criteria/maintain-version-control.md:block 19 (unordered list) +msgid "" +"[Producing OSS: Version Control " +"Vocabulary](https://producingoss.com/en/vc.html#vc-vocabulary) by Karl " +"Fogel." +msgstr "" +"Karl Fogel《[製作開放原始碼軟體：版本控制字彙](https://producingoss.com/en/vc.html#vc-" +"vocabulary)》。" + +#: ./criteria/maintain-version-control.md:block 19 (unordered list) +msgid "" +"[Maintaining version control in coding](https://www.gov.uk/service-" +"manual/technology/maintaining-version-control-in-coding) by the UK " +"Government Digital Service." +msgstr "" +"英國政府數位服務團《[維護程式碼的版本控制](https://www.gov.uk/service-" +"manual/technology/maintaining-version-control-in-coding)》。" + +#: ./criteria/maintain-version-control.md:block 19 (unordered list) +msgid "" +"[GitHub Skills](https://skills.github.com/) by GitHub for learning how to " +"use GitHub or refresh your skills." +msgstr "" +"GitHub 提供的「[GitHub 技能](https://skills.github.com/)」，可學習如何使用 " +"GitHub，或是重溫您的技巧。" + +#: ./criteria/maintain-version-control.md:block 19 (unordered list) +msgid "" +"[Git Cheat Sheet](https://education.github.com/git-cheat-sheet-" +"education.pdf) by GitHub, a list with the most common used git commands." +msgstr "" +"GitHub 提供的「[Git 密技表](https://education.github.com/git-cheat-sheet-" +"education.pdf)」，列出了最常用的 git 命令。" + +#: ./criteria/make-contributing-easy.md:block 3 (header) +msgid "order: 5" +msgstr "order: 5" + +#: ./criteria/make-contributing-easy.md:block 4 (header) +msgid "Make contributing easy" +msgstr "貢獻要容易" + +#: ./criteria/make-contributing-easy.md:block 5 (paragraph) +msgid "" +"To develop better, more reliable and feature rich software, users need to be" +" able to fix problems, add features, and address security issues of the " +"shared [codebase](../glossary.md#codebase)." +msgstr "" +"若要開發更好、更可靠且功能更豐富的軟體，使用者需要能夠為共享的[程式基底](../g" +"lossary.md#codebase)修正問題、新增功能，以及提出安全性議題等。" + +#: ./criteria/make-contributing-easy.md:block 6 (paragraph) +msgid "" +"A shared digital infrastructure makes it easier to make collaborative " +"contributions. The less effort it takes to make contributions that are " +"accepted by the codebase, the more likely users are to become contributors." +msgstr "共享的數位基礎建設讓協作貢獻更容易。使用者讓程式基底接受貢獻時所需付出的心力" +"越少，則使用者越可能成為貢獻者。" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"The codebase MUST have a public issue tracker that accepts suggestions from " +"anyone." +msgstr "程式基底「必須」有個可以公開接受任何人建議的議題追蹤器。" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"The documentation MUST link to both the public issue tracker and submitted " +"codebase changes, for example in a `README` file." +msgstr "文件中「必須」同時有公開的議題追蹤器連結，以及已提交的程式基底變動的連結，例" +"如記錄在「`README`」檔案中。" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"The codebase MUST have communication channels for users and developers, for " +"example email lists." +msgstr "程式基底「必須」要有能與使用者以及開發人員溝通的管道，像是設立電子郵件列表（" +"郵遞論壇）。" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"There MUST be a way to report security issues for responsible disclosure " +"over a closed channel." +msgstr "「必須」有透過封閉管道通報安全性問題的方法，來達成負責任的揭露。" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"The documentation MUST include instructions for how to report potentially " +"security sensitive issues." +msgstr "文件「必須」說明，該如何通報潛在的安全性與敏感性問題。" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "Confirm that there is a public issue tracker." +msgstr "確認有公開的議題追蹤器。" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "" +"Confirm that the codebase contains links to the public issue tracker and " +"submitted codebase changes." +msgstr "確認程式基底有公開的議題追蹤器連結，以及已提交的程式基底變動的連結。" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "" +"Confirm that it is possible to participate in a discussion with other users " +"and developers about the software using channels described in the codebase." +msgstr "確認可以使用程式基底中提到的管道，與其他使用者以及開發人員一同討論該軟體。" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "Confirm that there is a closed channel for reporting security issues." +msgstr "確認有封閉的管道可通報安全性問題。" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "" +"Confirm that there are instructions for privately reporting security issues." +msgstr "確認有說明如何私下通報安全性問題。" + +#: ./criteria/make-contributing-easy.md:block 12 (unordered list) +msgid "" +"Track [policy](../glossary.md#policy) issues in the codebase, so that a " +"relevant external policy expert can volunteer help." +msgstr "追蹤程式基底中的[政策](../glossary." +"md#policy)問題，讓相關的外部政策專家如果自願也能夠協助。" + +#: ./criteria/make-contributing-easy.md:block 14 (unordered list) +msgid "" +"Track management issues in the codebase, so that external managers with " +"relevant experience can volunteer help." +msgstr "追蹤程式基底中的管理問題，讓有相關經驗的外部管理人員如果自願也能夠協助。" + +#: ./criteria/make-contributing-easy.md:block 14 (unordered list) +msgid "" +"Support your experienced policy makers, developers and designers to keep " +"contributing to the codebase for as long as possible." +msgstr "支持您經驗豐富的政策制定者、開發人員與設計師，使其盡可能為程式基底持續做出長" +"久貢獻。" + +#: ./criteria/make-contributing-easy.md:block 16 (unordered list) +msgid "" +"Just like for [reviews](require-review-of-contributions.md), make sure to " +"respond to requests promptly." +msgstr "與[審查](require-review-of-contributions.md)流程相同，務必迅速回應請求。" + +#: ./criteria/make-contributing-easy.md:block 16 (unordered list) +msgid "" +"Keep your managers informed of the time and resources you require to support" +" other contributors." +msgstr "告知管理人員，您在支援其他貢獻者時所需的時間與資源。" + +#: ./criteria/make-contributing-easy.md:block 16 (unordered list) +msgid "" +"Make sure that appropriate communication channels for asking maintainers and" +" stakeholders questions are easy to locate, for instance in the README." +msgstr "確保人們可輕鬆找到合適的溝通管道，來詢問維護人員與利害關係人問題，例如寫在「`" +"README`」文件當中。" + +#: ./criteria/make-contributing-easy.md:block 16 (unordered list) +msgid "" +"Make sure that appropriate contact details are included in the metadata, for" +" instance in the publiccode.yml file." +msgstr "確保中介資料包含合適的聯絡資訊，例如寫在 publiccode.yml 檔案中。" + +#: ./criteria/make-contributing-easy.md:block 18 (unordered list) +msgid "" +"[How to inspire exceptional contributions to your open-source " +"project](https://dev.to/joelhans/how-to-inspire-exceptional-contributions-" +"to-your-open-source-project-1ebf) by Joel Hans." +msgstr "" +"Joel Hans《[如何引發他人為您的開放原始碼專案做出優秀貢獻](https://dev.to/joelhans/how-to-inspire-" +"exceptional-contributions-to-your-open-source-project-1ebf)》。" + +#: ./criteria/make-contributing-easy.md:block 18 (unordered list) +msgid "" +"[The benefits of coding in the open](https://gds.blog.gov.uk/2017/09/04/the-" +"benefits-of-coding-in-the-open/) by the UK Government Digital Service." +msgstr "" +"英國政府數位服務團《[以開放精神編寫原始碼的好處](https://gds.blog.gov.uk/2017/09/04/the-benefits-" +"of-coding-in-the-open/)》。" + +#: ./criteria/make-the-codebase-findable.md:block 3 (paragraph) +msgid "order: 14 redirect_from:" +msgstr "order: 14 redirect_from:" + +#: ./criteria/make-the-codebase-findable.md:block 4 (unordered list) +msgid "criteria/findability" +msgstr "criteria/findability" + +#: ./criteria/make-the-codebase-findable.md:block 5 (header) +msgid "Make the codebase findable" +msgstr "程式基底可查詢得到" + +#: ./criteria/make-the-codebase-findable.md:block 6 (paragraph) +msgid "" +"The more findable a [codebase](../glossary.md#codebase) is, the more " +"potential new collaborators will find it. Just publishing a codebase and " +"hoping it is found does not work, instead proactiveness is needed." +msgstr "" +"一旦[程式基底](../glossary.md#codebase)越容易被發現，更多的潛在協作者也就找得" +"到它。不能只是發表個程式基底，然後就盼望他人找得到這套程式基底，更需要主動積" +"極。" + +#: ./criteria/make-the-codebase-findable.md:block 7 (paragraph) +msgid "" +"A metadata description file increases discoverability. Well-written metadata" +" containing a unique and persistent identifier, such as a Wikidata item or " +"FSF software directory listing (thus being part of the semantic web), makes " +"the codebase easier for people to refer, cite, disambiguate and discover " +"through third party tools." +msgstr "" +"有中介資料說明檔的話，會讓程式基底更容易被發現。良好且包含永久唯一識別碼的中" +"介資料，例如寫成 Wikidata 維基數據條目，或是放到 FSF 自由軟體基金會的軟體目錄" +"列表之中（使程式基底成為語意網路中的一部份），他人就能更容易透過第三方工具參" +"考、引用、辨別、發現程式基底。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The name of the codebase SHOULD be descriptive and free from acronyms, " +"abbreviations, puns or organizational branding." +msgstr "程式基底名稱「應該」要能描述說明其用途，且不包含任何首字母縮寫字、縮寫、雙關" +"語，或組織單位品牌名稱或抬頭等。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD have a short description that helps someone understand " +"what the codebase is for or what it does." +msgstr "程式基底說明「應該」要簡短，幫助他人瞭解程式基底的目的與作用。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "Maintainers SHOULD submit the codebase to relevant software catalogs." +msgstr "維護人員「應該」將程式基底提交至相關的軟體目錄上。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD have a website which describes the problem the codebase " +"solves using the preferred jargon of different potential users of the " +"codebase (including technologists, policy experts and managers)." +msgstr "程式基底「應該」要架設網站，內容中以程式基底各類潛在使用者（技術人員、政策專" +"家、管理人員等）偏好的業內用語，描述程式基底所能解決的問題。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD be findable using a search engine by codebase name." +msgstr "在搜尋引擎查找程式基底名稱時，「應該」能搜尋得到程式基底。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD be findable using a search engine by describing the " +"problem it solves in natural language." +msgstr "在使用搜尋引擎時，如果以自然語言描述程式基底所能解決的問題，「應該」能搜尋得" +"到程式基底。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD have a unique and persistent identifier where the entry " +"mentions the major contributors, [repository](../glossary.md#repository) " +"location and website." +msgstr "" +"程式基底「應該」具備永久唯一識別碼，而且該項條目要提及主要貢獻者、[儲存庫](.." +"/glossary.md#repository)、位置、網站等。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD include a machine-readable metadata description, for " +"example in a " +"[publiccode.yml](https://github.com/publiccodeyml/publiccode.yml) file." +msgstr "" +"程式基底「應該」包含機器可讀的中介資料說明，例如採用[publiccode." +"yml](https://github.com/publiccodeyml/publiccode.yml)格式的檔案。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "A dedicated domain name for the codebase is OPTIONAL." +msgstr "「可選擇」是否為程式基底設置專用的網域名稱。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "Regular presentations at conferences by the community are OPTIONAL." +msgstr "「可選擇」是否在社群舉辦的會議中定期進行簡報。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "Check that the codebase name is descriptive and free of puns." +msgstr "檢查程式基底名稱是否描述說明其用途，且不包含雙關語。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase name is free of acronyms and abbreviations or that " +"the acronyms or abbreviations in the name are more universally known than " +"the longer forms." +msgstr "檢查程式基底名稱是否不包含任何首字母縮寫字或縮寫，或是其首字母縮寫字或縮寫比" +"完整名稱更熟為人知。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase name is free of organizational branding, unless that" +" organization is of the codebase community itself." +msgstr "檢查程式基底是否不包含組織單位品牌名稱或抬頭等，除非該組織單位也是程式基底社" +"群成員。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase repository has a short description of the codebase." +msgstr "檢查程式基底儲存庫是否包含程式基底的簡短描述。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "Check for the codebase listing in relevant software catalogs." +msgstr "檢查程式基底有刊登在相關軟體型錄上。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check for a codebase website which describes the problem the codebase " +"solves." +msgstr "檢查程式基底的網站有描述程式基底能夠解決的問題。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase appears in the results on more than one major search" +" engine when searching by the codebase name." +msgstr "檢查以程式基底名稱來作搜尋時，有超過一個的常用主流搜尋引擎，都有將程式基底列" +"在搜尋結果中。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase appears in the results on more than one major search" +" engine when searching by using natural language, for instance, using the " +"short description." +msgstr "檢查以自然語言來作搜尋，例如使用程式基底的簡短描述時，有超過一個的常用主流搜" +"尋引擎，都將程式基底放在搜尋結果中。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check unique and persistent identifier entries for mention of the major " +"contributors." +msgstr "檢查永久唯一識別碼條目有提及主要貢獻者。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check unique and persistent identifier entries for the repository location." +msgstr "檢查永久唯一識別碼條目中有包含儲存庫位置。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check unique and persistent identifier entries for the codebase website." +msgstr "檢查永久唯一識別碼條目有列出程式基底網站。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "Check for a machine-readable metadata description file." +msgstr "檢查中介資料說明檔是機器可讀的格式。" + +#: ./criteria/make-the-codebase-findable.md:block 13 (unordered list) +msgid "" +"Contribute a description of the policy area or problem this codebase acts on" +" or operates." +msgstr "貢獻一段說明此程式基底作用的政策領域，或所處理問題的描述。" + +#: ./criteria/make-the-codebase-findable.md:block 13 (unordered list) +msgid "" +"Test your problem description with peers outside of your context who aren't " +"familiar with the codebase." +msgstr "請那些對程式基底不熟悉且不同領域背景的同事，來測試您的問題描述。" + +#: ./criteria/make-the-codebase-findable.md:block 13 (unordered list) +msgid "" +"Present on how the codebase implements the [policy](../glossary.md#policy) " +"at relevant conferences." +msgstr "在相關會議上作簡報，介紹程式基底如何執行[政策](../glossary.md#policy)。" + +#: ./criteria/make-the-codebase-findable.md:block 15 (unordered list) +msgid "" +"Search trademark databases to avoid confusion or infringement before " +"deciding the name." +msgstr "在決定專案名稱之前，先搜尋過商標資料庫，以避免名稱造成混淆或侵權的問題。" + +#: ./criteria/make-the-codebase-findable.md:block 15 (unordered list) +msgid "" +"Use the short description wherever the codebase is referenced, for instance," +" as social media account descriptions." +msgstr "在引用到程式基底的地方，都使用簡短描述，例如放到社交媒體帳號中的說明。" + +#: ./criteria/make-the-codebase-findable.md:block 15 (unordered list) +msgid "" +"Budget for content design and Search Engine Optimization skills in the team." +msgstr "為團隊編列內容設計與實作 SEO 搜尋引擎最佳化技能的預算。" + +#: ./criteria/make-the-codebase-findable.md:block 15 (unordered list) +msgid "" +"Make sure people involved in the project present at relevant conferences." +msgstr "確保專案參與人員出席相關會議，或作簡報介紹。" + +#: ./criteria/make-the-codebase-findable.md:block 17 (unordered list) +msgid "" +"Search engine optimization, for instance adding a " +"[sitemap](https://www.sitemaps.org/protocol.html)." +msgstr "實作搜尋引擎最佳化，例如加入[網站地圖](https://www.sitemaps.org/protocol." +"html)。" + +#: ./criteria/make-the-codebase-findable.md:block 17 (unordered list) +msgid "" +"Use the short description wherever the codebase is referenced, for instance," +" as the repository description." +msgstr "在引用到程式基底的地方，都使用簡短描述，例如放到儲存庫中的說明。" + +#: ./criteria/make-the-codebase-findable.md:block 17 (unordered list) +msgid "Suggest conferences to present at and present at them." +msgstr "推薦適合出席或作簡報介紹的會議，並且在這些會議中出席或作簡報。" + +#: ./criteria/make-the-codebase-findable.md:block 19 (unordered list) +msgid "" +"[Introduction to " +"Wikidata](https://www.wikidata.org/wiki/Wikidata:Introduction) by the " +"Wikidata community." +msgstr "" +"Wikidata " +"維基數據社群《[維基數據簡介](https://www.wikidata.org/wiki/Wikidata:Introduction)》。" + +#: ./criteria/make-the-codebase-findable.md:block 19 (unordered list) +msgid "" +"[FSF software directory listing](https://directory.fsf.org/wiki/Main_Page) " +"by the Free Software Foundation." +msgstr "FSF 自由軟體基金會《[FSF 軟體目錄列表](https://directory.fsf.org/wiki/Main_Page)》。" + +#: ./criteria/make-the-codebase-findable.md:block 19 (unordered list) +msgid "" +"The [FAIR Guiding Principles for scientific data management and " +"stewardship](https://www.go-fair.org/fair-principles/) by the GO FAIR " +"International Support and Coordination Office provide a nice list of " +"attributes that make (meta)data more machine actionable (and hence more " +"findable). Some of these apply directly to codebases, while others may " +"provoke exploration into what the codebase equivalent would be." +msgstr "" +"GO FAIR 國際支援與合作辦公室所撰寫的《[FAIR " +"科學資料管理與監督指導原則](https://www.go-fair.org/fair-principles/)》，提供" +"一份滿好的特性清單，解說哪些特性會讓資料（或中介資料）更容易讓機器採取行動（" +"也因此更容易被找到）。其中的部分特性可直接套用到程式基底上，而其他無法直接套" +"用的，我們還需要再研究程式基底與其對應的特性要怎麼處理。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 3 (paragraph) +msgid "order: 3 redirect_from:" +msgstr "order: 3 redirect_from:" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 4 (unordered +#: list) +msgid "criteria/reusable-and-portable-codebases" +msgstr "criteria/reusable-and-portable-codebases" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 4 (unordered +#: list) +msgid "criteria/create-reusable-and-portable-code" +msgstr "criteria/create-reusable-and-portable-code" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 5 (header) +msgid "Make the codebase reusable and portable" +msgstr "程式基底要可重複使用且可移植" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 6 (paragraph) +msgid "" +"Creating reusable and portable [code](../glossary.md#code) enables policy " +"makers, developers and designers to reuse what has been developed, test it, " +"improve it and contribute those improvements back, leading to better " +"quality, cheaper maintenance and higher reliability." +msgstr "" +"編寫可重複使用且可移植的[程式碼](../glossary.md#code)，讓政策制定者、開發人員" +"與設計師等，能重複使用、測試與改善目前已開發的內容，並將改善貢獻回程式基底中" +"，如此可提高品質、降低維護成本、增強可靠性。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 7 (paragraph) +msgid "" +"Thoughtfully and purposefully designing a " +"[codebase](../glossary.md#codebase) for reusability allows for the mission, " +"vision and scope of the codebase to be shared by multiple parties. Codebases" +" developed and used by multiple parties are more likely to benefit from a " +"self-sustaining community." +msgstr "" +"以重複利用為前提籌劃設計[程式基底](../glossary.md#codebase)，更容易與多方共享" +"程式基底的目標使命、願景與範圍等。多方開發與使用的程式基底，更可以從能自我運" +"作的社群中獲益。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 8 (paragraph) +msgid "" +"Organizing a codebase such that it is composed of well documented modules " +"improves reusability and maintainability. A module is easier to reuse in " +"[another context](../glossary.md#different-contexts) if its purpose is " +"clearly documented." +msgstr "" +"以文件記錄周全的模組構成程式基底，能夠改善重複使用與維護的能力。以文件清楚記" +"錄用途的模組，更容易在[另一種情境](../glossary.md#different-" +"contexts)中重複利用。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 9 (paragraph) +msgid "" +"Source code which does not rely on the situation-specific infrastructure of " +"any contributor, vendor or deployment can be tested by any other " +"contributor." +msgstr "原始碼不依賴任何貢獻者、供應商或部署底下的特定情況專用基礎架構，則其他任何貢" +"獻者都能測試該原始碼。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "The codebase MUST be developed to be reusable in different contexts." +msgstr "程式基底「必須」開發成能在不同情境中重複使用。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"The codebase MUST be independent from any secret, undisclosed, proprietary " +"or non-open licensed software or services for execution and understanding." +msgstr "程式基底「必須」獨立於任何採用保密、無法揭露、專有或非開放式授權的軟體或服務" +"，以供執行與瞭解。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "The codebase SHOULD be in use by multiple parties." +msgstr "程式基底「應該」有多方單位使用。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "The roadmap SHOULD be influenced by the needs of multiple parties." +msgstr "發展路線圖「應該」有多方單位的需求影響。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"The development of the codebase SHOULD be a collaboration between multiple " +"parties." +msgstr "程式基底開發「應該」由多方單位協作。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"Configuration SHOULD be used to make [source code](../glossary.md#source-" +"code) adapt to context specific needs." +msgstr "「應該」使用組態設定方式以將[原始碼](../glossary.md#source-" +"code)調整成能適應各情境的特定需求。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "The codebase SHOULD be localizable." +msgstr "程式基底「應該」能夠在地化。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"Source code and its documentation SHOULD NOT contain situation-specific " +"information." +msgstr "原始碼與其文件「不應該」包含特定情況專用的資訊。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"Codebase modules SHOULD be documented in such a way as to enable reuse in " +"codebases in other contexts." +msgstr "程式基底模組「應該」以使其能夠在其他情境中重複利用的模式撰寫文件。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"The software SHOULD NOT require services or platforms available from only a " +"single vendor." +msgstr "軟體「不應該」要求僅有單一供應商能提供的服務或平台。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Confirm with someone in a similar role at another organization if they can " +"use the codebase and what that would entail." +msgstr "與另一組織單位角色與您相似的人確認，看他們是否能利用程式基底，以及需要怎麼進" +"行。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Confirm that the codebase can run without using any proprietary or non open-" +"licensed software or services." +msgstr "確認程式基底不需要用到任何專有或非開放式授權的軟體或服務，就能夠執行。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"If the codebase is in early development before a production-ready release, " +"then check for evidence of ambition to obtain collaborators." +msgstr "若程式基底處於早期開發階段，尚未準備好正式上線，則檢查是否有想要尋求協作者的" +"意圖跡象。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Or if the codebase is very mature and stable with very infrequent fixes, " +"patches, or contributions:" +msgstr "或是如果程式基底非常成熟與穩定，鮮少需要修正、改善或貢獻：" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Check that the codebase is in use by multiple parties or in multiple " +"contexts." +msgstr "檢查是否有多方單位，或是有在多種情境下正使用程式基底。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "Check for documented and budgeted commitments of collaboration." +msgstr "檢查是否有以文件記錄協作所做出的成果，以及有編列相關預算。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "Otherwise:" +msgstr "若是沒有，則：" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "Check that the codebase contributors are from multiple parties." +msgstr "檢查程式基底貢獻者是否來自多方單位。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Check that the codebase files and commit history do not include situation-" +"specific data." +msgstr "檢查程式基底檔案與送交版次歷史紀錄中，不包含特定情況專用的資料。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Check that the software can be deployed and run without services or " +"platforms available from a single vendor." +msgstr "檢查軟體是否可以在不使用單一供應商服務或平台的情況下，正常部署與執行。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 15 (unordered +#: list) +msgid "" +"Document your [policy](../glossary.md#policy) with enough clarity and detail" +" that it can be understood outside of its original context." +msgstr "為您的[政策](../glossary.md#policy)撰寫清楚且足夠詳細的文件，讓他人即使不是處於同個原始背景情境也能夠理解。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 15 (unordered +#: list) +msgid "Make sure your organization is listed as a known user by the codebase." +msgstr "確保程式基底有將貴組織單位列為已知使用者。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 15 (unordered +#: list) +msgid "Identify other organizations for your teams to collaborate with." +msgstr "找出貴團隊想要協作的其他組織單位。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 17 (unordered +#: list) +msgid "" +"Make sure that stakeholders and business owners understand that reusability " +"is an explicit codebase goal as this reduces technical debt and provides " +"sustainability for the codebase." +msgstr "確認利害關係人與業主能夠瞭解，程式基底是以重複利用為明確目標，因而得以減少程" +"式碼技術債，並讓程式基底可以永續發展。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 17 (unordered +#: list) +msgid "Make sure that your teams are collaborating with other teams." +msgstr "確認您的團隊與其他團隊能相互協作。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 19 (paragraph) +msgid "Source should be designed:" +msgstr "原始碼應該設計成：" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 20 (unordered +#: list) +msgid "for reuse by other users and organizations regardless of locale," +msgstr "能讓其他使用者與組織單位可以重複利用，而不受地方環境影響，" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 20 (unordered +#: list) +msgid "to solve a general problem instead of a specific one," +msgstr "能解決通用性質問題，而非特定問題，" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 20 (unordered +#: list) +msgid "in logically meaningful and isolated modules," +msgstr "以邏輯上具有意義且獨立的模組構成，" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 20 (unordered +#: list) +msgid "" +"so that someone in a similar organization facing a similar problem would be " +"able to use (parts of) the solution." +msgstr "如此讓類似組織單位中要面對近似問題的人，都可以採用這套解決方案（或其中一部份）。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 21 (paragraph) +msgid "" +"Make sure that the codebase documentation describes the build-time and " +"runtime dependencies. If your context requires deploying to proprietary " +"platforms or using proprietary components, make sure that collaborators can " +"develop, use, test, and deploy without them." +msgstr "" +"確保程式基底文件中，有說明程式的組建日期與執行時期的依賴項目。如果您的情境需" +"要部署至專有平臺上，或者要用到專有組件，則請確保協作者可以在不用到這兩者的情" +"況下，就能進行開發、使用、測試、部署等。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 22 (paragraph) +msgid "" +"For each commit, reviewers verify that content does not include situation-" +"specific data such as hostnames, personal and organizational data, or tokens" +" and passwords." +msgstr "在每份送交版次中，審查人員要確認其中不含特定情況專用的資料，像是主機名稱、個" +"人與組織單位資料、代符與密碼等。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 24 (unordered +#: list) +msgid "" +"[Making source code open and reusable](https://www.gov.uk/service-" +"manual/technology/making-source-code-open-and-reusable) by the UK Government" +" Digital Service." +msgstr "" +"英國政府數位服務團《[讓原始碼開放且可重複利用](https://www.gov.uk/service-" +"manual/technology/making-source-code-open-and-reusable)》。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 24 (unordered +#: list) +msgid "" +"[Localization vs. " +"Internationalization](https://www.w3.org/International/questions/qa-i18n) by" +" the World Wide Web Consortium." +msgstr "" +"W3C 全球資訊網協會《[在地化與國際化](https://www.w3.org/International/questions/qa-i18n)》。" + +#: ./criteria/publish-with-an-open-license.md:block 3 (paragraph) +msgid "order: 13 redirect_from:" +msgstr "order: 13 redirect_from:" + +#: ./criteria/publish-with-an-open-license.md:block 4 (unordered list) +msgid "criteria/open-licenses" +msgstr "criteria/open-licenses" + +#: ./criteria/publish-with-an-open-license.md:block 5 (header) +msgid "Publish with an open license" +msgstr "發行採用開放授權" + +#: ./criteria/publish-with-an-open-license.md:block 6 (paragraph) +msgid "" +"An open and well known license makes it possible for anyone to see the " +"[source code](../glossary.md#source-code) in order to understand how it " +"works, to use it freely and to contribute to the " +"[codebase](../glossary.md#codebase). This enables a vendor ecosystem to " +"emerge around the codebase." +msgstr "" +"採用開放且為人熟知的授權，讓任何人都可以查看[原始碼](../glossary.md#source-" +"code)，使其能瞭解運作方式、自由使用，並且能為[程式基底](../glossary." +"md#codebase)做出貢獻。這也能促進供應商建立出以程式基底為中心的生態系。" + +#: ./criteria/publish-with-an-open-license.md:block 7 (paragraph) +msgid "" +"Clearly indicating the license for each file within a codebase facilitates " +"correct reuse and attribution of parts of a codebase." +msgstr "明確指出程式基底中每一個檔案的授權，讓使用者能正確重複利用程式基底的部分內容" +"，並表彰作者名稱。" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"All source code and documentation MUST be licensed such that it may be " +"freely reusable, changeable and redistributable." +msgstr "所有原始碼與文件，皆「必須」採用使其得以自由重複使用、自由修改、自由再次散布" +"的授權條款。" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"Software source code MUST be licensed under an [OSI-approved or FSF " +"Free/Libre license](https://spdx.org/licenses/)." +msgstr "" +"軟體原始碼「必須」採用[經 OSI 開放原始碼促進會所批准，或由 FSF " +"自由軟體基金會所發表的自由授權條款](https://spdx.org/licenses/)。" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "All source code MUST be published with a license file." +msgstr "所有原始碼皆「必須」搭配授權條款檔案一併發行。" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"Contributors MUST NOT be required to transfer copyright of their " +"contributions to the codebase." +msgstr "「禁止」要求貢獻者將其貢獻的程式碼著作權轉讓給程式基底。" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"All source code files in the codebase SHOULD include a copyright notice and " +"a license header that are machine-readable." +msgstr "程式基底中所有原始碼檔案，皆「應該」包含機器可讀的著作權聲明與授權條款標頭內" +"容。" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"Having multiple licenses for different types of source code and " +"documentation is OPTIONAL." +msgstr "「可選擇」是否為不同類型的原始碼與文件採用多重授權條款。" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "Confirm that the codebase is clearly licensed." +msgstr "確認程式基底有清楚給予授權條款。" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "" +"Confirm that the license for the source code is on the [OSI-approved or FSF " +"Free/Libre license list](https://spdx.org/licenses/) and the license for " +"documentation [conforms to the Open " +"Definition](https://opendefinition.org/licenses/)." +msgstr "" +"確認原始碼的授權條款有列於[經 OSI 開放原始碼促進會所批准，或由 FSF " +"自由軟體基金會所發表的自由授權條款清單](https://spdx.org/licenses/)，以及文件的授權條款有[符合「開放定義」](https://opendefinition.org/licenses/)。" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "Confirm that the licenses used in the codebase are included as files." +msgstr "確認程式基底中有包含其採用的授權條款檔案。" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "" +"Confirm that contribution guidelines and " +"[repository](../glossary.md#repository) configuration do not require " +"transfer of copyright." +msgstr "確認貢獻指引中，以及[儲存庫](../glossary." +"md#repository)的組態設定中，沒有要求貢獻者轉讓著作權。" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "" +"Check for machine-readable license checking in the codebase [continuous " +"integration](../glossary.md#continuous-integration) tests." +msgstr "" +"在程式基底[持續整合](../glossary.md#continuous-" +"integration)測試中，確認是否有檢查授權內容為機器可讀的檢查項目。" + +#: ./criteria/publish-with-an-open-license.md:block 13 (unordered list) +msgid "" +"Develop [policy](../glossary.md#policy) that requires source code to be " +"[open source](../glossary.md#open-source)." +msgstr "" +"制定要求原始碼必須採用[開放原始碼](../glossary.md#open-" +"source)授權的[政策](../glossary.md#policy)。" + +#: ./criteria/publish-with-an-open-license.md:block 13 (unordered list) +msgid "" +"Develop policy that disincentivizes non-open source code and technology in " +"procurement." +msgstr "制定抑制採購非開放原始碼授權程式碼，與非開放科技的政策。" + +#: ./criteria/publish-with-an-open-license.md:block 15 (unordered list) +msgid "" +"Only work with open source vendors that deliver their source code by " +"publishing it under an open source license." +msgstr "只與能採用開放原始碼授權交付、與發行其原始碼的開放原始碼軟體供應商合作。" + +#: ./criteria/publish-with-an-open-license.md:block 15 (unordered list) +msgid "" +"Beware that even though [Creative Commons " +"licenses](https://creativecommons.org/licenses/) are great for " +"documentation, licenses that stipulate Non-Commercial or No Derivatives are " +"NOT freely reusable, changeable and redistributable and don't fulfill these " +"requirements." +msgstr "" +"請注意，雖然[創用CC授權](https://creativecommons.org/licenses/)適合用於文件作品，但其中指明「非商業性」或「禁止改作」的授權條款，代表「無法」自由重複使用、自由修改、自由再次散布等，因此未能符合規定。" + +#: ./criteria/publish-with-an-open-license.md:block 17 (unordered list) +msgid "Add a new `license` file to every new codebase created." +msgstr "每當建立新的程式基底時，都要加入新的「`license`」授權條款檔案。" + +#: ./criteria/publish-with-an-open-license.md:block 17 (unordered list) +msgid "" +"Add a copyright notice and a license header to every new source code file " +"created." +msgstr "每當建立新的原始碼檔案時，都要加入著作權聲明與授權條款標頭內容。" + +#: ./criteria/publish-with-an-open-license.md:block 17 (unordered list) +msgid "" +"When source code is being reused by the codebase, make sure that it has a " +"license that is compatible with the license or licenses of the codebase." +msgstr "每當程式基底重複利用原始碼時，都要確認原始碼的授權與程式基底的授權相容。" + +#: ./criteria/publish-with-an-open-license.md:block 19 (unordered list) +msgid "" +"[Open source definition](https://opensource.org/osd) by the Open Source " +"Initiative, all open source licenses meet this definition." +msgstr "" +"開放原始碼促進會所發表的《[開放原始碼定義](https://opensource.org/osd)》，所有開放原始碼授權條款皆符合這套定義。" + +#: ./criteria/publish-with-an-open-license.md:block 19 (unordered list) +msgid "" +"[Animated video introduction to Creative " +"Commons](https://creativecommons.org/about/videos/creative-commons-kiwi) by " +"Creative Commons Aotearoa New Zealand." +msgstr "" +"紐西蘭CC Aotearoa《[創用CC介紹動畫影片](https://creativecommons.org/about/" +"videos/creative-commons-kiwi)》。" + +#: ./criteria/publish-with-an-open-license.md:block 19 (unordered list) +msgid "" +"[REUSE Initiative specification](https://reuse.software/spec/) by Free " +"Software Foundation Europe for unambiguous, human-readable and machine-" +"readable copyright and licensing information." +msgstr "" +"歐洲自由軟體基金會所發表的《[REUSE 倡議規範](https://reuse.software/spec/" +")》，提供規範明確、人類可讀以及機器可讀的著作權與授權資訊。" + +#: ./criteria/publish-with-an-open-license.md:block 19 (unordered list) +msgid "" +"[SPDX License List](https://spdx.org/licenses/) by the Linux Foundation with" +" standardized, machine-readable abbreviations for most licenses." +msgstr "" +"Linux 基金會所發表的 [SPDX 授權條款清單](https://spdx.org/licenses/" +")，提供經標準化、且機器可讀的大多數授權條款縮寫表示法。" + +#: ./criteria/require-review-of-contributions.md:block 3 (paragraph) +msgid "order: 7 redirect_from:" +msgstr "order: 7 redirect_from:" + +#: ./criteria/require-review-of-contributions.md:block 4 (unordered list) +msgid "criteria/require-review" +msgstr "criteria/require-review" + +#: ./criteria/require-review-of-contributions.md:block 5 (header) +msgid "Require review of contributions" +msgstr "要求審查貢獻內容" + +#: ./criteria/require-review-of-contributions.md:block 6 (paragraph) +msgid "" +"Peer-review of contributions is essential for [source " +"code](../glossary.md#source-code) quality, reducing security risks and " +"operational risks." +msgstr "同儕審查貢獻是[原始碼](../glossary.md#source-" +"code)提升品質的關鍵，也能降低安全性風險與營運風險。" + +#: ./criteria/require-review-of-contributions.md:block 7 (paragraph) +msgid "" +"Requiring thorough review of contributions encourages a culture of making " +"sure every contribution is of high quality, completeness and value. Source " +"code review increases the chance of discovering and fixing potential bugs or" +" mistakes before they are added to the [codebase](../glossary.md#codebase). " +"Knowing that all source code was reviewed discourages a culture of blaming " +"individuals, and encourages a culture of focusing on solutions." +msgstr "" +"要求仔細審查貢獻，能孕育出確保貢獻都是優質、完整且能帶來價值的文化。審查原始" +"碼能提高在原始碼加入[程式基底](../glossary.md#codebase)之前，就發現與修正潛在" +"臭蟲與出錯的機率。得知所有原始碼都會被審查，就不會孕育出習慣怪罪他人的文化，" +"反倒是鼓勵每個人都專注在解決方案上。" + +#: ./criteria/require-review-of-contributions.md:block 8 (paragraph) +msgid "" +"A [policy](../glossary.md#policy) of prompt reviews assures contributors of " +"a guaranteed time for feedback or collaborative improvement, which increases" +" both rate of delivery and contributor engagement." +msgstr "" +"快速審查[政策](../glossary.md#policy)在於向貢獻者保證，必定在一段時間內提供意" +"見回饋或是協作式改善，進而提高貢獻者交付貢獻內容的頻率，以及參與的熱度。" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"All contributions that are accepted or committed to release versions of the " +"codebase MUST be reviewed by another contributor." +msgstr "所有被接受或是送交給程式基底正式發行版本中的貢獻內容，都「必須」經過另一位貢" +"獻者審查。" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "Reviews MUST include source, policy, tests and documentation." +msgstr "審查「必須」包含原始碼、政策、測試、文件等。" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"Reviewers MUST provide feedback on all decisions to not accept a " +"contribution." +msgstr "如果不接受貢獻內容，審查人員「必須」提供意見回饋。" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"The review process SHOULD confirm that a contribution conforms to the " +"standards, architecture and decisions set out in the codebase in order to " +"pass review." +msgstr "審查流程「應該」確認貢獻內容遵循程式基底的標準、架構、決策安排等，以通過審查" +"。" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"Reviews SHOULD include running both the software and the tests of the " +"codebase." +msgstr "審查內容「應該」包含執行軟體與執行程式基底測試。" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"Contributions SHOULD be reviewed by someone in a different context than the " +"contributor." +msgstr "貢獻內容「應該」由與貢獻者不同背景情境的人來審查。" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"Version control systems SHOULD NOT accept non-reviewed contributions in " +"release versions." +msgstr "版本控制系統「不應該」在程式基底的正式發行版本中，接受未經審查的貢獻內容。" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "Reviews SHOULD happen within two business days." +msgstr "審查「應該」在兩個工作天內進行。" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "Performing reviews by multiple reviewers is OPTIONAL." +msgstr "「可選擇」是否由多位審查人員進行審查。" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "" +"Confirm that every commit in the history has been reviewed by a different " +"contributor." +msgstr "確認歷史紀錄中，每個送交版次都有經過不同的貢獻者審查。" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "Confirm that reviews include source, policy, tests and documentation." +msgstr "確認審查內容包含原始碼、政策、測試、文件等。" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "Confirm that rejected contributions were appropriately explained." +msgstr "針對未被採用的貢獻內容，確認有適當解釋原因。" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "" +"Check if guidelines for reviewers include instructions to review for " +"conformance to standards, architecture and codebase guidelines." +msgstr "檢查審查人員指引中，有包含是否遵循標準、架構、程式基底指引等指示。" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "Check with reviewers if they run the software and tests during review." +msgstr "檢查審查人員在審查時是否有執行軟體與測試。" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "" +"Check with reviewers if commits have been reviewed by a different " +"contributor in a different context." +msgstr "與審查人員確認，送交版次是否有經過不同情境背景的不同貢獻者審查。" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "" +"Check for use of branch protection in the [version " +"control](../glossary.md#version-control) system." +msgstr "檢查[版本控制](../glossary.md#version-control)系統中是否有採用分支保護。" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "Check the times between contribution submission and review." +msgstr "檢查貢獻提交與審查之間的時間間隔。" + +#: ./criteria/require-review-of-contributions.md:block 14 (unordered list) +msgid "" +"Institute a 'four eyes' policy where everything, not just source code, is " +"reviewed." +msgstr "制定進行任何審查時，含原始碼與其他一切事物，都要恪遵「四眼原則」的政策。" + +#: ./criteria/require-review-of-contributions.md:block 14 (unordered list) +msgid "" +"Use a version control system or methodology that enables review and " +"feedback." +msgstr "採用具有審查與意見回饋功能的版本控制系統，或作業流程。" + +#: ./criteria/require-review-of-contributions.md:block 16 (unordered list) +msgid "Make delivering great software a shared objective." +msgstr "將交付妥善軟體作為共同目標。" + +#: ./criteria/require-review-of-contributions.md:block 16 (unordered list) +msgid "" +"Make sure writing and reviewing contributions to source, policy, " +"documentation and tests are considered equally valuable." +msgstr "確保如原始碼、政策、文件、測試等的貢獻內容撰寫與審查，皆受到同等重視。" + +#: ./criteria/require-review-of-contributions.md:block 16 (unordered list) +msgid "" +"Create a culture where all contributions are welcome and everyone is " +"empowered to review them." +msgstr "創造歡迎所有形式的貢獻，而且每個人都能夠審查貢獻內容的文化。" + +#: ./criteria/require-review-of-contributions.md:block 16 (unordered list) +msgid "Make sure no contributor is ever alone in contributing to a codebase." +msgstr "確保貢獻者在貢獻內容給程式基底時，不是獨自一人埋頭苦幹。" + +#: ./criteria/require-review-of-contributions.md:block 18 (unordered list) +msgid "" +"Ask other contributors on the codebase to review your work, in your " +"organization or outside of it." +msgstr "請程式基底的其他貢獻者，審查您在貴組織單位內外的工作成果。" + +#: ./criteria/require-review-of-contributions.md:block 18 (unordered list) +msgid "" +"Try to respond to others' requests for review promptly, initially providing " +"feedback about the concept of the change." +msgstr "當他人請求您審查時，請盡快回覆，並先給出需要修正之處背後的概念。" + +#: ./criteria/require-review-of-contributions.md:block 20 (unordered list) +msgid "" +"[How to review code the GDS way](https://gds-" +"way.cloudapps.digital/manuals/code-review-guidelines.html#content) by the UK" +" Government Digital Service." +msgstr "" +"英國政府數位服務團《[英國政府數位服務團程式碼審查程序](https://gds-way.cloudapps.digital/manuals/code-" +"review-guidelines.html#content)》。" + +#: ./criteria/require-review-of-contributions.md:block 20 (unordered list) +msgid "" +"Branch protection on " +"[GitHub](https://docs.github.com/en/repositories/configuring-branches-and-" +"merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-" +"protected-branches) and " +"[GitLab](https://about.gitlab.com/blog/2014/11/26/keeping-your-code-" +"protected/)." +msgstr "" +"[GitHub](https://docs.github.com/en/repositories/configuring-branches-and-" +"merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-" +"protected-branches) 與 " +"[GitLab](https://about.gitlab.com/blog/2014/11/26/keeping-your-code-" +"protected/) 平臺的分支保護說明。" + +#: ./criteria/require-review-of-contributions.md:block 20 (unordered list) +msgid "" +"[The Gentle Art of Patch Review](https://sage.thesharps.us/2014/09/01/the-" +"gentle-art-of-patch-review/) by Sage Sharp." +msgstr "" +"Sage Sharp《[程式修補審查的和善藝術](https://sage.thesharps.us/2014/09/01/the-gentle-" +"art-of-patch-review/)》。" + +#: ./criteria/require-review-of-contributions.md:block 20 (unordered list) +msgid "" +"[Measuring " +"Engagement](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-" +"mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) by Mozilla." +msgstr "" +"Mozilla《[參與度評測成果](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-" +"mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177)》。" + +#: ./criteria/use-a-coherent-style.md:block 3 (paragraph) +msgid "order: 15 redirect_from:" +msgstr "order: 15 redirect_from:" + +#: ./criteria/use-a-coherent-style.md:block 4 (unordered list) +msgid "criteria/style" +msgstr "criteria/style" + +#: ./criteria/use-a-coherent-style.md:block 5 (header) +msgid "Use a coherent style" +msgstr "風格要前後一致" + +#: ./criteria/use-a-coherent-style.md:block 6 (paragraph) +msgid "" +"Following a consistent and coherent style enables contributors in different " +"environments to work together. Unifying vocabularies reduces friction in " +"communication between contributors." +msgstr "採用前後一致的風格，讓不同環境的貢獻者能夠一同合作。用詞統一能減少貢獻者之間" +"在溝通上的摩擦。" + +#: ./criteria/use-a-coherent-style.md:block 8 (unordered list) +msgid "" +"The [codebase](../glossary.md#codebase) MUST use a coding or writing style " +"guide, either the codebase community's own or an existing one referred to in" +" the codebase." +msgstr "" +"[程式基底](../glossary.md#codebase)「必須」遵守程式碼撰寫風格指引、或文件寫作" +"風格指引，可以是程式基底社群自身的風格指引，或是程式基底有採用的既有風格。" + +#: ./criteria/use-a-coherent-style.md:block 8 (unordered list) +msgid "Contributions SHOULD pass automated tests on style." +msgstr "貢獻內容「應該」通過自動化的風格測試。" + +#: ./criteria/use-a-coherent-style.md:block 8 (unordered list) +msgid "" +"The style guide SHOULD include expectations for inline comments and " +"documentation for non-trivial sections." +msgstr "風格指引「應該」描述對於較複雜的程式碼區段，如何作列內註解與為其寫下說明文件" +"的期待。" + +#: ./criteria/use-a-coherent-style.md:block 8 (unordered list) +msgid "" +"Including expectations for [understandable English](use-plain-english.md) in" +" the style guide is OPTIONAL." +msgstr "「可選擇」是否將[可理解的白話英語](use-plain-english." +"md)期望加入風格指引之中。" + +#: ./criteria/use-a-coherent-style.md:block 10 (unordered list) +msgid "" +"Confirm that contributions are in line with the style guides specified in " +"the documentation." +msgstr "確認貢獻內容有遵循文件中指定的風格指引。" + +#: ./criteria/use-a-coherent-style.md:block 10 (unordered list) +msgid "Check for the presence of automated tests on style." +msgstr "檢查是否有自動化的風格測試。" + +#: ./criteria/use-a-coherent-style.md:block 12 (unordered list) +msgid "" +"Create, follow and continually improve on a style guide for " +"[policy](../glossary.md#policy) and documentation as well as document this " +"in the codebase, for example in the `CONTRIBUTING` or `README`." +msgstr "" +"為[政策](../glossary.md#policy)與文件建立風格指引，遵守並且持續改善，同時記錄" +"到程式基底文件中，像是「`CONTRIBUTING`」或「`README`」檔案。" + +#: ./criteria/use-a-coherent-style.md:block 14 (unordered list) +msgid "" +"Include written language, source, test and policy standards in your " +"organizational definition of quality." +msgstr "將書面語言、原始碼、測試、政策標準等，包含在貴組織單位對品質的定義當中。" + +#: ./criteria/use-a-coherent-style.md:block 16 (paragraph) +msgid "" +"If the codebase does not already have engineering guidelines or other " +"contributor guidance, start by adding documentation to the " +"[repository](../glossary.md#repository) describing whatever is being done " +"now, for example in the `CONTRIBUTING` or `README`. An important purpose of " +"the file is to communicate design preferences, naming conventions, and other" +" aspects machines can't easily check. Guidance should include what would be " +"expected from [source code](../glossary.md#source-code) contributions in " +"order for them to be merged by the maintainers, including source, tests and " +"documentation. Continually improve upon and expand this documentation with " +"the aim of evolving this documentation into engineering guidelines." +msgstr "" +"如果程式基底還沒有工程指引，或其他貢獻者指引，則請先在[儲存庫](../glossary.md" +"#repository)中加入相關文件，像是「`CONTRIBUTING`」或「`README`」檔案，並描述" +"目前在設立指引方面的進展。上述檔案的重要目的之一，在於宣達設計偏好、命名規則" +"，以及機器不容易檢查的其他層面。指引應該包含貢獻的[原始碼](../glossary.md" +"#source-code)預期該符合哪些要求，才會被維護人員合併至程式基底中，包括原始碼、" +"測試、文件等項目。請持續改善與擴充這份文件內容，目標讓文件朝向工程指引演進。" + +#: ./criteria/use-a-coherent-style.md:block 17 (paragraph) +msgid "Additionally:" +msgstr "此外：" + +#: ./criteria/use-a-coherent-style.md:block 18 (unordered list) +msgid "Use a linter." +msgstr "使用 linter 程式碼品質梳理工具。" + +#: ./criteria/use-a-coherent-style.md:block 18 (unordered list) +msgid "Add linter configurations to the codebase." +msgstr "在程式基底中加入 linter 梳理工具的組態設定。" + +#: ./criteria/use-a-coherent-style.md:block 20 (unordered list) +msgid "" +"[Programming style](https://en.wikipedia.org/wiki/Programming_style) on " +"Wikipedia." +msgstr "維基百科上的《[程式碼風格](https://en.wikipedia.org/wiki/" +"Programming_style)》條目。" + +#: ./criteria/use-continuous-integration.md:block 3 (paragraph) +msgid "order: 12 redirect_from:" +msgstr "order: 12 redirect_from:" + +#: ./criteria/use-continuous-integration.md:block 4 (unordered list) +msgid "criteria/continuous-integration" +msgstr "criteria/continuous-integration" + +#: ./criteria/use-continuous-integration.md:block 5 (header) +msgid "Use continuous integration" +msgstr "使用持續整合" + +#: ./criteria/use-continuous-integration.md:block 6 (paragraph) +msgid "" +"Asynchronous collaboration is enabled by developers merging their work to a " +"shared branch frequently, verified by automated tests. The more frequent the" +" merging and the smaller the contribution, the easier it is to resolve merge" +" conflicts." +msgstr "" +"透過自動化測試驗證，開發人員能更頻繁地將其工作成果合併至共享的分支，達成非同" +"步協作。合併的頻率越頻繁、貢獻的規模越小，在合併時所發生的衝突就越容易解決。" + +#: ./criteria/use-continuous-integration.md:block 7 (paragraph) +msgid "" +"Automated testing of all functionality provides confidence that " +"contributions are working as intended and have not introduced errors, and " +"allows reviewers to focus on the structure and approach of the contribution." +" The more focused the test, the easier it is to clearly identify and " +"understand errors as they arise." +msgstr "" +"自動化測試所有功能，使人更加信賴貢獻內容發揮其功用且沒有引發任何錯誤，同時讓" +"審查人員專注在貢獻的結構與作法。測試越聚焦，就越容易辨識並瞭解所出現的問題。" + +#: ./criteria/use-continuous-integration.md:block 8 (paragraph) +msgid "" +"Documenting a codebase's [continuous integration](../glossary.md#continuous-" +"integration) workflow helps contributors understand the expectations of " +"contributions. Continuous integration allows for an easier monitoring of the" +" state of the [codebase](../glossary.md#codebase)." +msgstr "" +"以文件記錄程式基底的[持續整合](../glossary.md#continuous-integration)工作流程" +"，能協助貢獻者瞭解對貢獻內容的期待。持續整合讓監管[程式基底](../glossary." +"md#codebase)狀態變得更為簡單。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"All functionality in the [source code](../glossary.md#source-code) MUST have" +" automated tests." +msgstr "[原始碼](../glossary.md#source-code)中的所有功能，都「必須」有自動化測試。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"Contributions MUST pass all automated tests before they are admitted into " +"the codebase." +msgstr "所有貢獻內容都「必須」先通過自動化測試，才能上傳至程式基底。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"The codebase MUST have guidelines explaining how to structure contributions." +msgstr "程式基底「必須」有解說如何撰寫貢獻內容結構的相關指引。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"The codebase MUST have active contributors who can review contributions." +msgstr "程式基底「必須」有能夠審查貢獻內容的活躍貢獻者。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "Automated test results for contributions SHOULD be public." +msgstr "「應該」公開貢獻內容的自動化測試結果。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"The codebase guidelines SHOULD state that each contribution should focus on " +"a single issue." +msgstr "程式基底指引「應該」指出，每次的貢獻內容都只應聚焦在單一議題上。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "Source code test and documentation coverage SHOULD be monitored." +msgstr "「應該」監管原始碼測試與文件的涵蓋範圍。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"Testing [policy](../glossary.md#policy) and documentation for consistency " +"with the source and vice versa is OPTIONAL." +msgstr "「可選擇」是否測試[政策](../glossary." +"md#policy)和文件，與原始碼之間有無一致性，或是反之亦然。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"Testing policy and documentation for style and broken links is OPTIONAL." +msgstr "「可選擇」是否測試政策和文件所採用的樣式，以及連結有無失效。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"Testing the software by using examples in the documentation is OPTIONAL." +msgstr "「可選擇」是否使用文件中的範例來測試軟體。" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "Confirm that there are tests present." +msgstr "確認有測試可用。" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "" +"Confirm that source code coverage tools check that coverage is at 100% of " +"the source code." +msgstr "確認原始碼覆蓋率工具能檢查到 100% 的原始碼。" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "" +"Confirm that contributions are only admitted into the codebase after all of " +"the tests are passed." +msgstr "確認貢獻內容只有在通過所有測試後，才會認可上傳至程式基底。" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "" +"Confirm that contribution guidelines explain how to structure contributions." +msgstr "確認有貢獻指引解說如何撰寫貢獻內容的結構。" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "" +"Confirm that there are contributions from within the last three months." +msgstr "確認最近三個月內有貢獻內容上傳。" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "Check that test results are viewable." +msgstr "檢查是否可以查看測試結果。" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "Check if source code coverage data is published." +msgstr "檢查是否有公布原始碼覆蓋率數據。" + +#: ./criteria/use-continuous-integration.md:block 14 (unordered list) +msgid "" +"Involve managers as well as developers and designers as early in the process" +" as possible and keep them engaged throughout development of your policy." +msgstr "儘早讓管理人員、開發人員與設計師一同加入，並且讓他們持續參與您政策的制定程序。" + +#: ./criteria/use-continuous-integration.md:block 14 (unordered list) +msgid "" +"Make sure there are also automated tests set up for policy documentation." +msgstr "確保政策文件也有設好自動化測試。" + +#: ./criteria/use-continuous-integration.md:block 14 (unordered list) +msgid "Fix policy documentation promptly if it fails a test." +msgstr "如果政策文件未能通過測試，請快速修正。" + +#: ./criteria/use-continuous-integration.md:block 14 (unordered list) +msgid "" +"Make sure the source code reflects any changes to the policy (see [Maintain " +"version control](maintain-version-control.md))." +msgstr "確保原始碼能反映出政策的任何變動（請參閱〈[維護版本控制](maintain-version-" +"control.md)〉）。" + +#: ./criteria/use-continuous-integration.md:block 16 (unordered list) +msgid "" +"Make sure to test with real end users as quickly and often as possible." +msgstr "確保能儘快且經常給真正的終端使用者進行測試。" + +#: ./criteria/use-continuous-integration.md:block 16 (unordered list) +msgid "" +"Plan the work to integrate small parts very often instead of large parts " +"less frequently." +msgstr "以頻繁整合少量部分內容的方式做專案規劃，而非久久一次繳交大量部分內容。" + +#: ./criteria/use-continuous-integration.md:block 16 (unordered list) +msgid "" +"Procure consultancy services that deliver incrementally aligned with the " +"plan." +msgstr "聘請有能力處理漸進式交付，並跟得上規劃進度的顧問服務。" + +#: ./criteria/use-continuous-integration.md:block 16 (unordered list) +msgid "" +"After a large failure, encourage publication of incident reports and public " +"discussion of what was learned." +msgstr "發生重大失誤後，鼓勵公開事故報告，以及公開討論事後學到的教訓。" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Help managers structure the work plan such that it can be integrated as " +"small increments." +msgstr "協助管理人員擬定工作規劃，例如規劃成可以拆分成小部分逐次整合。" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Help contributors limit the scope of their contributions and feature " +"requests to be as small as reasonable." +msgstr "協助貢獻者聚焦其貢獻內容與功能請求，讓涵蓋範圍盡可能合理地縮小。" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Help managers and policy makers test their contributions, for example by " +"testing their contributions for broken links or style." +msgstr "協助管理人員與政策制定者測試其貢獻內容，例如測試其貢獻內容中的失效連結或樣式。" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Structure source code written to handle conditions which are difficult to " +"create in a test environment in such a way that the conditions can be " +"simulated during testing. Forms of resource exhaustion such as running out " +"of storage space and memory allocation failure are typical examples of " +"difficult to create conditions." +msgstr "" +"編排原始碼結構時，要將難以在測試環境下創造出來的情況，得以在測試過程中模擬出" +"來。例如硬碟空間不足、記憶體分配失敗等資源耗盡情況，都是難以創造的典型案例。" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Tune the test code coverage tools to avoid false alarms resulting from " +"inlining or other optimizations." +msgstr "調整程式碼覆蓋率測試工具，避免在 inline 過程或其他最佳化處理時得到假警報。" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "Deploy often." +msgstr "經常部署。" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "Integrate your work at least once a day." +msgstr "至少每天整合工作內容一次。" + +#: ./criteria/use-continuous-integration.md:block 20 (unordered list) +msgid "" +"[What is continuous " +"integration](https://www.martinfowler.com/articles/continuousIntegration.html)" +" by Martin Fowler." +msgstr "" +"Martin " +"Fowler《[什麼是持續整合](https://www.martinfowler.com/articles/continuousIntegration.html)》。" + +#: ./criteria/use-continuous-integration.md:block 20 (unordered list) +msgid "" +"[Use continuous delivery](https://gds-" +"way.cloudapps.digital/standards/continuous-delivery.html) by the UK " +"Government Digital Service." +msgstr "" +"英國政府數位服務團《[使用持續交付](https://gds-way.cloudapps.digital/standards/continuous-" +"delivery.html)》。" + +#: ./criteria/use-continuous-integration.md:block 20 (unordered list) +msgid "" +"[Quality assurance: testing your service " +"regularly](https://www.gov.uk/service-manual/technology/quality-assurance-" +"testing-your-service-regularly) by the UK Government Digital Service." +msgstr "" +"英國政府數位服務團《[品質保證：定期測試您的服務](https://www.gov.uk/service-" +"manual/technology/quality-assurance-testing-your-service-regularly)》。" + +#: ./criteria/use-open-standards.md:block 3 (paragraph) +msgid "order: 11 redirect_from:" +msgstr "order: 11 redirect_from:" + +#: ./criteria/use-open-standards.md:block 4 (unordered list) +msgid "criteria/open-standards" +msgstr "criteria/open-standards" + +#: ./criteria/use-open-standards.md:block 5 (header) +msgid "Use open standards" +msgstr "採用開放標準" + +#: ./criteria/use-open-standards.md:block 6 (paragraph) +msgid "" +"[Open standards](../glossary.md#open-standard) guarantee access to the " +"knowledge required to use and contribute to the " +"[codebase](../glossary.md#codebase). They enable interoperability between " +"systems and reduce the risk of vendor lock-in. Open standards which are " +"unambiguous allow for independent development of either side of data " +"exchange." +msgstr "" +"[開放標準](../glossary.md#open-" +"standard)保證可以取得使用與貢獻[程式基底](../glossary.md#codebase)所需的知識" +"。不僅能為不同的系統之間建立互通性，更能降低廠商套牢的可能性。開放標準如果明" +"確，不同方就可以各自獨立開發作資料交換。" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"For features of the codebase that facilitate the exchange of data the " +"codebase MUST use an open standard that meets the [Open Source Initiative " +"Open Standard Requirements](https://opensource.org/osr)." +msgstr "" +"程式基底如要促進資料交換的特性，就「必須」採用符合 [OSI " +"開放原始碼促進會其《開放標準需求規範](https://opensource.org/" +"osr)》的開放標準。" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Any non-open standards used MUST be recorded clearly as such in the " +"documentation." +msgstr "如果有使用到任何非開放標準，則「必須」在文件中清楚記錄。" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Any standard chosen for use within the codebase MUST be listed in the " +"documentation with a link to where it is available." +msgstr "程式基底選擇採用的任何標準，皆「必須」在文件中列出，並且只要有的話，就附上該" +"標準的連結。" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Any non-open standards chosen for use within the codebase MUST NOT hinder " +"collaboration and reuse." +msgstr "程式基底選擇採用的任何非開放標準，皆「禁止」妨礙程式基底的協作與重複使用。" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"If no existing open standard is available, effort SHOULD be put into " +"developing one." +msgstr "如果還沒有已存在的開放標準可採用，則「應該」投入開發新標準。" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Open standards that are machine testable SHOULD be preferred over open " +"standards that are not." +msgstr "採用開放標準時，「應該」優先選擇可經機器測試的開放標準。" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Non-open standards that are machine testable SHOULD be preferred over non-" +"open standards that are not." +msgstr "採用非開放標準時，「應該」優先選擇可經機器測試的非開放標準。" + +#: ./criteria/use-open-standards.md:block 10 (unordered list) +msgid "Confirm that data exchange follows an OSI approved open standard." +msgstr "確認資料交換遵守 OSI 開放原始碼促進會批准的開放標準。" + +#: ./criteria/use-open-standards.md:block 10 (unordered list) +msgid "" +"Confirm that any non-open standards used are clearly documented as such." +msgstr "確認若有採用任何的非開放標準，皆有清楚記錄在文件中。" + +#: ./criteria/use-open-standards.md:block 10 (unordered list) +msgid "" +"Confirm that documentation includes a list of the standards followed within " +"the codebase, each with a working link, or a statement that no standards " +"were chosen." +msgstr "確認文件有清單列出程式基底所採用的標準，其中各標準有對應的有效連結；或沒有採" +"用任何標準時，則留下聲明。" + +#: ./criteria/use-open-standards.md:block 12 (unordered list) +msgid "Mandate use of open standards everywhere possible." +msgstr "以政策要求盡可能在任何情況下採用開放標準。" + +#: ./criteria/use-open-standards.md:block 12 (unordered list) +msgid "Prohibit procurement of technology that does not use open standards." +msgstr "禁止採購不採用開放標準的技術科技。" + +#: ./criteria/use-open-standards.md:block 14 (unordered list) +msgid "" +"Consider including open standard compliance assessment in [source " +"code](../glossary.md#source-code) reviews." +msgstr "考慮在[原始碼](../glossary.md#source-code)審查中納入開放標準依循評估。" + +#: ./criteria/use-open-standards.md:block 16 (unordered list) +msgid "" +"Add [continuous integration](../glossary.md#continuous-integration) tests " +"for compliance with the standards." +msgstr "將是否依循標準加入[持續整合](../glossary.md#continuous-integration)測試中。" + +#: ./criteria/use-open-standards.md:block 16 (unordered list) +msgid "" +"Review the commits and other [repository](../glossary.md#repository) " +"resources for references to standards and cross-check those with the " +"standards listed." +msgstr "審查送交版次與[儲存庫](../glossary." +"md#repository)其他資源是否有參考開放標準，並交叉檢查其中有列出標準的部分。" + +#: ./criteria/use-open-standards.md:block 18 (unordered list) +msgid "" +"[Open Standards principles](https://www.gov.uk/government/publications/open-" +"standards-principles/open-standards-principles), " +"[policy](../glossary.md#policy) paper of the UK Cabinet Office." +msgstr "" +"英國內閣辦公室發表的《[開放標準原則](https://www.gov.uk/government/publications/open-" +"standards-principles/open-standards-" +"principles)》[政策](../glossary.md#policy)報告。" + +#: ./criteria/use-plain-english.md:block 3 (paragraph) +msgid "order: 10 redirect_from:" +msgstr "order: 10 redirect_from:" + +#: ./criteria/use-plain-english.md:block 4 (unordered list) +msgid "criteria/understandable-english-first" +msgstr "criteria/understandable-english-first" + +#: ./criteria/use-plain-english.md:block 5 (header) +msgid "Use plain English" +msgstr "使用白話的英語" + +#: ./criteria/use-plain-english.md:block 6 (paragraph) +msgid "" +"English is the de facto language of collaboration in software " +"development." +msgstr "英語是軟體開發領域中的實際 協作語言。" + +#: ./criteria/use-plain-english.md:block 7 (paragraph) +msgid "" +"Public sector information needs to be accessible to all its constituents. " +"Plain and simple language makes the [code](../glossary.md#code) and what it " +"does easier to understand for a wider variety of people." +msgstr "公家機關資訊需要讓所有選民都能取用。簡單且白話的語言，能讓更多人能瞭解[程式碼" +"](../glossary.md#code)與其功用。" + +#: ./criteria/use-plain-english.md:block 8 (paragraph) +msgid "" +"Translations further increase the possible reach of a " +"[codebase](../glossary.md#codebase). Language that is easy to understand " +"lowers the cost of creating and maintaining translations." +msgstr "翻譯可以讓更多人有機會認識[程式基底](../glossary." +"md#codebase)。用語越是簡單明暸，製作與維護翻譯的成本就越低。" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "All codebase documentation MUST be in English." +msgstr "程式基底的所有文件都「必須」使用英語。" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"All [source code](../glossary.md#source-code) MUST be in English, except " +"where [policy](../glossary.md#policy) is machine interpreted as code." +msgstr "" +"所有[原始碼](../glossary.md#source-" +"code)都「必須」使用英語編寫，其中[政策](../glossary." +"md#policy)是由機器解讀當作程式碼的部分則除外。" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"All bundled policy not available in English MUST have an accompanying " +"summary in English." +msgstr "任何合捆的政策如果沒有英語版本，則「必須」隨附英語版摘要。" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"Any translation MUST be up to date with the English version and vice versa." +msgstr "任何翻譯版本皆「必須」跟隨英語版本更新，以維持在最新狀態，反之亦然。" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"There SHOULD be no acronyms, abbreviations, puns or legal/non-English/domain" +" specific terms in the codebase without an explanation preceding it or a " +"link to an explanation." +msgstr "" +"程式基底中「不應該」使用首字母縮字、縮寫、雙關語，或法律/非英語/行業特定詞彙" +"；如果有的話，則需要在這些用語出現之前先行解釋，或是附上解釋該用語的網頁連結" +"。" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"Documentation SHOULD aim for a lower secondary education reading level, as " +"recommended by the [Web Content Accessibility Guidelines " +"2](https://www.w3.org/WAI/WCAG21/quickref/?showtechniques=315#readable)." +msgstr "" +"根據《[網頁內容近用性無障礙指引 2](https://www.w3.org/WAI/WCAG21/quickref/" +"?showtechniques=315#readable)》的建議，文件內容「應該」以國中識讀程度為主。" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"Providing a translation of any code, documentation or tests is OPTIONAL." +msgstr "「可選擇」是否提供任何程式碼、文件、測試等的翻譯版。" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "Confirm that codebase documentation is available in English." +msgstr "確認程式基底文件有英語版本。" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "" +"Confirm that source code is in English, or confirm any non-English is policy" +" or terms with preceding explanations." +msgstr "確認原始碼為英語，確認任何非英語內容都是政策，或確認術語在其前方有先行說明等。" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "Confirm any non-English policy has an accompanying summary in English." +msgstr "確認任何非英語政策都有隨附英語版摘要。" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "" +"Confirm that translations and the English version have the same content." +msgstr "確認翻譯版與英語版內容相同。" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "" +"Check that no unexplained acronyms, abbreviations, puns or legal/non-" +"English/domain specific terms are in the documentation." +msgstr "確認文件當中，沒有任何未說明的首字母縮寫字、縮寫、雙關語，或法律/非英語/行業特定詞彙等。" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "Check the spelling, grammar and readability of the documentation." +msgstr "檢查文件的拼字、文法與易讀性等。" + +#: ./criteria/use-plain-english.md:block 14 (unordered list) +msgid "" +"Frequently test with other managers, developers and designers in the process" +" if they understand what you are delivering and how you document it." +msgstr "在過程中經常與其他管理人員、開發人員與設計師測試，確認他們是否瞭解您們正要交付的程式碼與其文件的內容。" + +#: ./criteria/use-plain-english.md:block 16 (unordered list) +msgid "" +"Try to limit the use of acronyms, abbreviations, puns or legal/non-" +"English/domain specific terms in internal communications in and between " +"teams and stakeholders. Add any such terms to a glossary and link to it from" +" the places they are being used." +msgstr "" +"在團隊內部與利害關係人之間的內部溝通中，試著限制首字母縮寫字、縮寫、雙關語，或法律/非英語/行業特定詞彙的使用。如果有使用到的話，則將這些用語加入詞彙表，並且在使用這些詞彙的地方加上詞彙表連結。" + +#: ./criteria/use-plain-english.md:block 16 (unordered list) +msgid "" +"Be critical of documentation and descriptions in proposals and changes. If " +"you don't understand something, others will probably also struggle with it." +msgstr "以批判性觀點看待提案與修改當中的文件與描述。如果有您看不懂的內容，很有可能其他人也同樣迷惘。" + +#: ./criteria/use-plain-english.md:block 18 (unordered list) +msgid "" +"Frequently test with policy makers and managers if they understand what you " +"are delivering and how you document it." +msgstr "經常與政策制定者和管理人員測試，確認他們是否瞭解您們正要交付的程式碼與其文件的內容。" + +#: ./criteria/use-plain-english.md:block 18 (unordered list) +msgid "" +"Ask someone outside of your context if they understand the content (for " +"example, a developer working on a different codebase)." +msgstr "詢問身處不同背景情境的人（像是另一個程式基底的開發人員）是否能瞭解內容。" + +#: ./criteria/use-plain-english.md:block 20 (unordered list) +msgid "" +"Meeting the [Web Content Accessibility Guidelines 2.1, Guideline 3.1 " +"Readable](https://www.w3.org/TR/WCAG21/#readable) by W3C makes text content " +"readable and understandable." +msgstr "" +"符合 W3C 全球資訊網協會《[網頁內容近用性無障礙指引 2.1、3.1 " +"之可讀性](https://www.w3.org/TR/WCAG21/" +"#readable)》要求，撰寫的文字內容要容易閱讀與理解。" + +#: ./criteria/use-plain-english.md:block 20 (unordered list) +msgid "" +"The[European Union accessibility directive](https://ec.europa.eu/digital-" +"single-market/en/web-accessibility) by the European Commission, is an " +"example of regulation requiring high accessibility." +msgstr "" +"歐盟委員會的《[歐盟無障礙環境命令](https://ec.europa.eu/" +"digital-single-market/en/web-" +"accessibility)》，是高度要求無障礙環境的法規範例。" + +#: ./criteria/use-plain-english.md:block 20 (unordered list) +msgid "" +"[Definition of plain " +"language](https://www.plainlanguage.gov/about/definitions/) by United States" +" General Services Administration." +msgstr "美國總務署《[白話語言定義](https://www.plainlanguage.gov/about/definitions/)》。" + +#: ./criteria/welcome-contributors.md:block 3 (paragraph) +msgid "order: 4 redirect_from:" +msgstr "order: 4 redirect_from:" + +#: ./criteria/welcome-contributors.md:block 4 (unordered list) +msgid "criteria/open-to-contributions" +msgstr "criteria/open-to-contributions" + +#: ./criteria/welcome-contributors.md:block 5 (header) +msgid "Welcome contributors" +msgstr "歡迎貢獻者" + +#: ./criteria/welcome-contributors.md:block 6 (paragraph) +msgid "" +"The atmosphere in a [codebase](../glossary.md#codebase) community helps " +"users decide to use one codebase over another. Welcoming anyone as a " +"contributor enables the community to grow and sustain itself over time. A " +"community where contributors have clear ways to influence codebase and " +"community goals and progress is less likely to split and end up in diverging" +" communities. Newcomers need to understand and trust the codebase " +"community’s governance." +msgstr "" +"[程式基底](../glossary.md#codebase)社群的氛圍，會影響使用者選擇所要使用的程式" +"基底。歡迎任何人成為貢獻者的社群，才能夠不斷茁壯並且持續自我運作。若貢獻者有" +"明確的方法可以影響程式基底、社群目標與進展，則該社群分裂成分歧的社群的機率也" +"較低。新參與者需要瞭解並信任程式基底社群的治理方式。" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The codebase MUST allow anyone to submit suggestions for changes to the " +"codebase." +msgstr "程式基底必須「允許」任何人對程式基底提出修改建議。" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The codebase MUST include contribution guidelines explaining what kinds of " +"contributions are welcome and how contributors can get involved, for example" +" in a `CONTRIBUTING` file." +msgstr "程式基底「必須」包含貢獻指引，說明歡迎貢獻的內容類型，以及貢獻者可如何參與開" +"發，例如以「`CONTRIBUTING`」檔案說明。" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The codebase MUST document the governance of the codebase, contributions and" +" its community, for example in a `GOVERNANCE` file." +msgstr "程式基底「必須」以文件記錄程式基底、貢獻內容與社群互動等的治理方式，例如以「`" +"GOVERNANCE`」檔案來說明。" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The contribution guidelines SHOULD document who is expected to cover the " +"costs of reviewing contributions." +msgstr "貢獻指引「應該」以文件記錄預期由何者負擔審查貢獻內容所需的開銷費用。" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The codebase SHOULD advertise the committed engagement of involved " +"organizations in the development and maintenance." +msgstr "程式基底「應該」宣布投入其開發與維護工作的參與組織單位。" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "The codebase SHOULD have a publicly available roadmap." +msgstr "程式基底「應該」要有可公開取得的發展路線圖。" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "The codebase SHOULD publish codebase activity statistics." +msgstr "程式基底「應該」公布程式基底的活動統計數據。" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"Including a code of conduct for contributors in the codebase is OPTIONAL." +msgstr "「可選擇」是否為程式基底加入貢獻者的行為守則。" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "" +"Confirm that it is possible to submit suggestions for changes to the " +"codebase." +msgstr "確認可以提交修改建議給程式基底。" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Confirm there are contribution guidelines." +msgstr "確認程式基底有貢獻指引。" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "" +"Confirm that the codebase governance is clearly explained, including how to " +"influence codebase governance." +msgstr "確認程式基底有清楚解釋治理架構，並包含如何影響程式基底治理的方法。" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "" +"Check that contributing guidelines cover who is expected to cover the costs " +"of reviewing contributions." +msgstr "確認貢獻指引是否有涵蓋預期由何者負擔審查貢獻內容的開銷費用。" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Check for a list of involved organizations." +msgstr "檢查是否有參與的組織單位名單。" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Check for a roadmap." +msgstr "檢查是否有發展路線圖。" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Check for published activity statistics." +msgstr "檢查是否有公布活動統計數據。" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Check for a code of conduct." +msgstr "檢查是否有行為守則。" + +#: ./criteria/welcome-contributors.md:block 12 (unordered list) +msgid "" +"Add a list to the codebase of any other resources that " +"[policy](../glossary.md#policy) experts, non-governmental organizations and " +"academics would find useful for understanding or reusing your policy." +msgstr "" +"為程式基底加入其他資源的清單，而這些資源可幫助[政策](../glossary." +"md#policy)專家、非政府組織、學者等，更能瞭解或可重複利用您的政策。" + +#: ./criteria/welcome-contributors.md:block 12 (unordered list) +msgid "" +"Consider adding contact details so that other policy makers considering " +"collaboration can ask you for advice." +msgstr "考慮放入聯絡資訊，讓其他考慮合作的政策制定者能徵詢您的意見。" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"Make sure that the documentation of the governance includes the current " +"process for how to make changes to the governance." +msgstr "確保治理架構文件內容中，有包含目前如何改變治理狀態的流程。" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"If the community has some consensus about how the governance should change, " +"then include those ideas stated as ambitions in the documentation." +msgstr "如果社群對於治理架構應該如何改變有共識，則應該將這些構想宣告為願景寫入文件中。" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"If needed, make sure you have allocated budget for the contributions review " +"process as agreed by the codebase community." +msgstr "若有需要，確認您有編列貢獻內容審查流程的預算，且經過程式基底社群同意。" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"Make sure the documentation explains how each organization is involved in " +"the codebase, what resources it has available for it and for how long." +msgstr "確認文件有解釋每個參與組織單位所投入的內容，例如提供程式基底哪些資源，以及參" +"與的時間長度等。" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"Support your experienced policy makers, developers and designers to stay " +"part of the community for as long as possible." +msgstr "支持您經驗豐富的政策制定者、開發人員與設計師，使其盡可能長久參與社群。" + +#: ./criteria/welcome-contributors.md:block 16 (unordered list) +msgid "Respond promptly to requests." +msgstr "快速回應請求。" + +#: ./criteria/welcome-contributors.md:block 16 (unordered list) +msgid "" +"Communicate clearly to contributors what they need to do make sure their " +"contribution can be integrated." +msgstr "清楚告知貢獻者他們該如何做，才能讓貢獻內容整合到程式基底中。" + +#: ./criteria/welcome-contributors.md:block 18 (unordered list) +msgid "" +"[Building welcoming communities](https://opensource.guide/building-" +"community/) by Open Source Guides." +msgstr "開放原始碼指引所提供的《[營造友善的社群](https://opensource.guide/" +"building-community/)》。" + +#: ./criteria/welcome-contributors.md:block 18 (unordered list) +msgid "" +"[The Open Source Contributor Funnel](https://mikemcquaid.com/2018/08/14/the-" +"open-source-contributor-funnel-why-people-dont-contribute-to-your-open-" +"source-project/) by Mike McQuaid." +msgstr "" +"Mike McQuaid《[開放原始碼貢獻者瓶頸](https://mikemcquaid.com/2018/08/14/the-open-" +"source-contributor-funnel-why-people-dont-contribute-to-your-open-source-" +"project/)》。" + +#: ./criteria/welcome-contributors.md:block 18 (unordered list) +msgid "" +"[Leadership and governance](https://opensource.guide/leadership-and-" +"governance/) for growing [open source](../glossary.md#open-source) community" +" projects, by Open Source Guides." +msgstr "" +"開放原始碼指引針對推動[開放原始碼](../glossary.md#open-" +"source)社群專案所寫的《[領導與治理](https://opensource.guide/" +"leadership-and-governance/)》。" + +#: ./criteria/welcome-contributors.md:block 18 (unordered list) +msgid "" +"[Building online communities](http://hintjens.com/blog:117) by Pieter " +"Hintjens (long read!)." +msgstr "Pieter Hintjens《[打造網路社群](http://hintjens.com/blog:117)》(長篇文章！)。" + +#: ./docs/printing.md:block 1 (header) +msgid "Printing" +msgstr "印刷" + +#: ./docs/printing.md:block 3 (paragraph) +msgid "" +"The printed Standard for Public Code is printed by Reclameland. This guide " +"tries to provide the relevant information to print it there or somewhere " +"else." +msgstr "《公共程式標準》是由 Reclameland 負責印刷。本指引試著提供印刷相關資訊，" +"方便您到 Reclameland 或其他地方印刷。" + +#: ./docs/printing.md:block 4 (paragraph) +msgid "" +"Details, mostly in order they are on the Reclameland page with the Dutch if " +"necessary:" +msgstr "印刷詳細資訊（多數依照 Reclameland 網頁上的順序，依需要附上荷蘭語）：" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "" +"Form: Softcover book ([Reclameland product " +"page](https://www.reclameland.nl/drukken/softcover-boeken))" +msgstr "" +"樣式：平裝書 ([Reclameland 產品頁面](https://www.reclameland.nl/drukken/" +"softcover-boeken))" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Format: A4" +msgstr "紙張尺寸：A4" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Portrait or landscape: Portrait (Staand)" +msgstr "直向或橫向：直向 (Staand)" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Printing inside: 4/4 dual sided full color" +msgstr "內頁印刷：正四反四 4/4，雙面全色印刷" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Inside material: 90 grams biotop" +msgstr "內頁材質：Biotop 90克" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Cover: 350 grams cover" +msgstr "封面：350 克封面" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Printing cover: 4/0 one sided full cover" +msgstr "封面印刷：正四反空 4/0，單面滿版印刷" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Cover treatment: one sided matt foliated (Enke)" +msgstr "封面處理：單面霧面層剝處理 (Enke)" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "" +"Pages: pages of the inside + 4 + x, where x is 0-3 so that the sum becomes a" +" multiple of 4" +msgstr "頁數：書內頁數 + 4 + x，x 是 0-3頁，讓總頁數是 4 的倍數" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Individually sealed: no" +msgstr "個別封裝：無" + +#: ./docs/printing.md:block 6 (paragraph) +msgid "" +"When these details are chosen, the cover and insides are uploaded and the " +"order is placed payment can happen (payment ahead) after which printing " +"starts." +msgstr "一旦選定這些印刷的詳細資訊，封面與內頁就會上傳，並且下單與付費。付費後才會開始印刷。" + +#: ./docs/releasing.md:block 1 (header) +msgid "Releasing a new version of the Standard for public code" +msgstr "發行新版本的《公共程式標準》" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Review state of the 'develop' branch" +msgstr "審查「develop」分支的狀態" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Ensure all changes intended for release are merged" +msgstr "確認預計收入該次發行版的所有變更都已完成合併" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Invite a proofread of the current state of the branch" +msgstr "邀請校對該分支目前的狀態" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"If new dashes are introduced, check if the language can be simplified to " +"remove them in favor of more simple sentences. If a complex sentence is " +"needed, see if the dash can be replaced with other punctuation. If a dash is" +" truly the best expression of ideas, then follow the [Chicago Manual of " +"Style](https://en.wikipedia.org/wiki/Dash#En_dash_versus_em_dash)." +msgstr "" +"如果有引入新的破折號，檢查是否能簡化文字並且移除破折號，例如改用較簡易的句子" +"。如果需要用到複雜的句子，檢查是否能用其他標點符號來取代破折號。如果破折號最" +"適合用來表達該句子的涵義，則請遵守《[芝加哥格式手冊](https://en.wikipedia." +"org/wiki/Dash#En_dash_versus_em_dash)》的規範。" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Create a release branch" +msgstr "建立發行用分支" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "From 'develop', `git switch -c \"release-$MAJOR.$MINOR.$PATCH\"`" +msgstr "從「develop」分支下命令，`git switch -c \"release-$MAJOR.$MINOR.$PATCH\"`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Push the branch, `git push -u origin release-$MAJOR.$MINOR.$PATCH`" +msgstr "推送分支，`git push -u origin release-$MAJOR.$MINOR.$PATCH`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update the new release" +msgstr "更新本次新發行" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Update version number in `_config.yml`, `README.md` and `publiccode.yml`" +msgstr "更新 `_config.yml`、`README.md` 與 `publiccode.yml` 中的版本編號" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update `assets/version-badge.svg` with `script/make-version-badge.sh`" +msgstr "使用 `script/make-version-badge.sh` 更新 `assets/version-badge.svg`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update releaseDate in `publiccode.yml`" +msgstr "更新 `publiccode.yml` 當中的 releaseDate 日期" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update [`AUTHORS.md`](../AUTHORS.md) with new contributors" +msgstr "在 [`AUTHORS.md`](../AUTHORS.md) 中加入新貢獻者的資料" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update [`CHANGELOG.md`](../CHANGELOG.md)" +msgstr "更新 [`CHANGELOG.md`](../CHANGELOG.md)" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Perform extra pass on diff to the 'main' branch" +msgstr "透過 diff 進行額外傳輸到「main」分支" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"run `script/generate-review-template.sh` and commit updated `docs/review-" +"template.html`" +msgstr "" +"執行 `script/generate-review-template.sh` 並送交更新後的 `docs/review-" +"template.html` 版次記錄" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"update `docs/standard-for-public-code.md` with the new text from the review " +"template, updating any status changes as a result" +msgstr "用審查範本中的新文字來更新 `docs/standard-for-public-code." +"md`，根據成果更新所有的狀態變更" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Reread any section or paragraph to ensure wording changes still fit the " +"whole and do not contain grammar or spelling errors" +msgstr "重新檢查用字有變更的任何小節或段落，確保變更的字詞適合該整體內容，並且沒有文" +"法或拼字錯誤" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Ensure [fonts](https://brand.publiccode.net/typography/) are installed, see:" +" `script/ensure-font.sh`" +msgstr "" +"確認有安裝[字型](https://brand.publiccode.net/typography/)，請參見：`script/" +"ensure-font.sh`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Check the rendered `.pdf` using `script/pdf.sh rc1`" +msgstr "使用 `script/pdf.sh rc1` 檢查轉譯出的 `.pdf` 檔" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Ensure no link collisions exist" +msgstr "確認沒有連結相衝的問題" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Check the page breaks, possibly removing or adding page-break CSS, for " +"example: `

`" +msgstr "" +"檢查文字分頁之處，可能需要移除或新增 CSS 分頁語法，像是：`

`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "If needed, commit fixes and repeat extra pass" +msgstr "如果有需要，送交修正版次，並重複進行額外傳輸" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Push branch, open a pull request to the 'main' branch" +msgstr "推送分支，對 「main」分支提出拉取請求" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Request review from multiple reviewers, especially a proofreader" +msgstr "請多位審查人員（特別是校對人員）進行審查" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Reviewers will create issues for shortcomings found which would not prevent " +"release" +msgstr "審查人員若發現不會阻礙發行的缺失，則會建立議題" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"If needed for release, reviewers may create pull requests to resolve issues" +msgstr "如果是發行所需處理的缺失，審查人員可以提交拉取請求來解決問題" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Re-request reviews if additional pull requests are merged into release " +"branch" +msgstr "若有額外的拉取請求合併至發行分支，則再次請求審查" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Run the to-archive-org.sh script" +msgstr "執行 to-archive-org.sh 命令稿" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Once reviews are complete, merge to 'main'" +msgstr "當審查完成後，合併回「main」" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Create GitHub release with the release notes and version number" +msgstr "在 GItHub 上發行，附上發行備註與版本編號" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Switch to the 'main' branch, `git pull` and `git status`" +msgstr "切換至「main」分支，`git pull` 然後 `git status`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "`git tag $MAJOR.$MINOR.$PATCH`" +msgstr "`git tag $MAJOR.$MINOR.$PATCH`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "`git push --tags` (see: `../.github/workflows/release-on-tag.yml`)" +msgstr "`git push --tags`（請參見：`../.github/workflows/release-on-tag.yml`）" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Trigger a rebuild of gh-pages" +msgstr "觸發 gh-pages 重建" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "`git switch -c rebuild-gh-pages-$MAJOR.$MINOR.$PATCH`" +msgstr "`git switch -c rebuild-gh-pages-$MAJOR.$MINOR.$PATCH`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "`git commit --allow-empty -m\"Rebuild GH Pages $MAJOR.$MINOR.$PATCH\"`" +msgstr "`git commit --allow-empty -m\"Rebuild GH Pages $MAJOR.$MINOR.$PATCH\"`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "`git push -u origin rebuild-gh-pages-$MAJOR.$MINOR.$PATCH`" +msgstr "`git push -u origin rebuild-gh-pages-$MAJOR.$MINOR.$PATCH`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Open a pull request from this branch to `main`" +msgstr "從此分支向「main」提出拉取請求" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Approve and merge PR (containing empty commit)" +msgstr "批准與合併 PR （包含空白的送交版次）" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update 'develop' with a merge from 'main'" +msgstr "將「develop」透過合併更新「main」" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "[Send the files for print to the printer](printing.md)" +msgstr "[將檔案傳送給印刷廠商印刷](printing.md)" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Cover file" +msgstr "封面檔案" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Inside pages PDF" +msgstr "內頁 PDF" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Ping [translation](https://github.com/publiccodenet/community-translations-" +"standard) contributors" +msgstr "" +"通知[翻譯](https://github.com/publiccodenet/community-translations-" +"standard)貢獻者" + +#: ./docs/roadmap.md:block 1 (header) +msgid "Roadmap" +msgstr "發展路線圖" + +#: ./docs/roadmap.md:block 3 (paragraph) +msgid "Last updated: 2023-03-08" +msgstr "上次更新時間：2023-03-08" + +#: ./docs/roadmap.md:block 4 (paragraph) +msgid "" +"This document intends to shed light on the current development plans of the " +"team. Plans change constantly as new information is absorbed by the team." +msgstr "本文件旨在闡明團隊目前的開發計畫。隨著團隊吸收新資訊，這些計畫也會持續變動。" + +#: ./docs/roadmap.md:block 5 (paragraph) +msgid "" +"Codebase stewards review the roadmap monthly as part of our [backlog pruning" +" session](https://about.publiccode.net/activities/standard-" +"maintenance/backlog-pruning.html)." +msgstr "" +"程式基底執事人員每月會定期審查發展路線圖，這是我們[積累事項修整作業](https://" +"about.publiccode.net/activities/standard-maintenance/backlog-pruning." +"html)環節的一部份。" + +#: ./docs/roadmap.md:block 6 (header) +msgid "Current work" +msgstr "目前任務" + +#: ./docs/roadmap.md:block 7 (unordered list) +msgid "As far as possible, make the standard Standard-compliant" +msgstr "盡可能讓標準遵循自我標準" + +#: ./docs/roadmap.md:block 8 (header) +msgid "Near term" +msgstr "近期" + +#: ./docs/roadmap.md:block 9 (unordered list) +msgid "Separate executive summary" +msgstr "分離執行摘要" + +#: ./docs/roadmap.md:block 9 (unordered list) +msgid "" +"Clarify \"code\" as \"source code\" or \"policy code\" when specific to one," +" issue #208" +msgstr "#208號議題：將程式碼或規則之「code」清楚區分為「原始碼」或是「政策法規」" + +#: ./docs/roadmap.md:block 9 (unordered list) +msgid "Possibly: add in the illustrations for each criterion" +msgstr "可能性：為每個準則新增解說插圖" + +#: ./docs/roadmap.md:block 10 (header) +msgid "Longer term" +msgstr "長期" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Certification badges" +msgstr "認證標章" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "" +"Add to README and index.md information (and eventually statistics) on " +"adoption and use (issue #438)" +msgstr "為「README」與「index.md」加入採用與使用（之後會繼續統計）條目（議題#438號）" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Physical paper checklist" +msgstr "實體紙張檢查清單" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Becoming validated by multiple codebases" +msgstr "通過多個程式基底驗證" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Release version 1.0.0 after a few codebases are compliant" +msgstr "在幾個程式基底遵循標準後，發行 1.0.0 版" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Linkable requirements" +msgstr "可連結的需求規範" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "New cover art" +msgstr "新封面設計" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Register for ISBN" +msgstr "註冊申請 ISBN 書號" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "List with an on-demand book printing service" +msgstr "隨選書籍列印服務名單" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "QR codes for external links in print version" +msgstr "印刷版外部連結的 QR 二維圖碼" + +#: ./foreword.md:block 3 (paragraph) +msgid "redirect_from:" +msgstr "redirect_from:" + +#: ./foreword.md:block 4 (unordered list) +msgid "introduction" +msgstr "前言" + +#: ./foreword.md:block 5 (header) +msgid "Foreword" +msgstr "序文" + +#: ./foreword.md:block 6 (paragraph) +msgid "" +"The Standard for Public Code is a set of criteria that support public " +"organizations in developing and maintaining software and policy together." +msgstr "《公共程式標準》提供一套準則規範，支持公家機關一同開發與維護軟體及政策。" + +#: ./foreword.md:block 7 (paragraph) +msgid "" +"Anyone developing public-purpose software or policy can use this standard to" +" work towards higher quality public services that are more cost effective, " +"with less risk and more control." +msgstr "任何想開發具有公眾用途的軟體或政策的人，可以利用本標準來提升公共服務品質，使" +"其更具成本效益、風險更低，還能對系統更有掌控權。" + +#: ./foreword.md:block 8 (paragraph) +msgid "" +"This foreword introduces the term public code and explains why this is " +"important." +msgstr "本序文在介紹何謂「公共程式」以及解說其重要性。" + +#: ./foreword.md:block 9 (header) +msgid "Definition of public code" +msgstr "公共程式定義" + +#: ./foreword.md:block 10 (paragraph) +msgid "" +"Public code is both computer source code (such as software and algorithms) " +"and public policy executed in a public context, by humans or machines. It " +"encompasses the software built to operate with and as public infrastructure," +" along with the arrangements for its production. Public code is explicitly " +"distinct from regular software because it operates under fundamentally " +"different circumstances and expectations." +msgstr "" +"公共程式，英文為 Public Code，是指人類或機器在公共情境下，所執行的電腦原始碼" +"（像是軟體與演算法）與公共政策。公共程式的範疇，涵蓋搭配公共基礎建設一同作業" +"的軟體、作為公共基礎建設運作而建置的軟體，以及產生公共程式的過程安排等。公共" +"程式與一般軟體有明顯區別，因為其作業的環境與期待全然不同。" + +#: ./foreword.md:block 11 (header) +msgid "Reasons for public code" +msgstr "採用公共程式的原因" + +#: ./foreword.md:block 12 (paragraph) +msgid "There are many reasons for why public code is relevant now." +msgstr "公共程式現在如此重要，背後有幾個原因。" + +#: ./foreword.md:block 13 (header) +msgid "Software code == legal code" +msgstr "軟體程式碼 == 法律條文" + +#: ./foreword.md:block 14 (paragraph) +msgid "Software is public infrastructure." +msgstr "軟體是公共基礎建設。" + +#: ./foreword.md:block 15 (paragraph) +msgid "" +"In the 21st century, software can be considered vital public infrastructure." +" It is increasingly not just the expression of existing policy but the " +"originator of new policy, for example where algorithms decide which " +"districts need extra social services or policing." +msgstr "" +"在 21 世紀，軟體可被視為重要的公共基礎建設。軟體越來越常被用於實現既有政策，" +"甚至成為新政策的制定來源。舉例來說，演算法可以決定哪些地區需要額外的社會服務" +"或警力等。" + +#: ./foreword.md:block 16 (paragraph) +msgid "" +"Software mechanics, algorithms and data collection have become key elements " +"in the execution of public policies. Computer code now executes policies " +"that have been codified in legal code through democratic procedures. Both " +"forms of code set conditions for society to function according to " +"democratically set public values, the latter executed by humans, the former " +"by machines. In other words, software code has increasingly started to equal" +" legal code." +msgstr "" +"在公共政策的執行上，軟體運作機制、演算法與資料蒐集等，已成為關鍵要素。今日的" +"電腦程式碼，正執行著透過民主程序制定的法規政策。程式碼與政策這兩種形式的程式" +"，都根據民主程序而確立的公共價值，設立出社會的運作環境；前者由機器執行，後者" +"則是由人類執行。換句話說，軟體程式碼，已經越來越實質趨近於法律條文的地位。" + +#: ./foreword.md:block 17 (paragraph) +msgid "" +"Software should therefore be subject to the principles of democratic " +"governance." +msgstr "因此軟體也應該接受民主治理原則的約束。" + +#: ./foreword.md:block 18 (header) +msgid "Traditional public software procurement" +msgstr "傳統的公共軟體採購" + +#: ./foreword.md:block 19 (paragraph) +msgid "" +"Current public software production methods have not served public service " +"delivery very well." +msgstr "目前公共軟體的生產模式，在交付公共服務上的效率並不高。" + +#: ./foreword.md:block 20 (paragraph) +msgid "" +"In the last decade, public organizations that purchased complete software " +"solutions have sometimes been surprised to discover that they:" +msgstr "過去近十年來，購置完整軟體解決方案的公家機關，有時甚至會很訝異地發現：" + +#: ./foreword.md:block 21 (unordered list) +msgid "" +"can’t change their software to reflect changing policy or take advantage of " +"new technology" +msgstr "他們無法修改軟體來反映政策的變動，或是改變軟體來利用新科技" + +#: ./foreword.md:block 21 (unordered list) +msgid "" +"don’t have access to their data as it's locked into proprietary systems" +msgstr "他們的資料都套牢在專有系統中，無法取用" + +#: ./foreword.md:block 21 (unordered list) +msgid "are asked to pay ever increasing license fees" +msgstr "他們所需繳交的授權費變得越來越貴" + +#: ./foreword.md:block 22 (header) +msgid "Technological sovereignty and democratic accountability" +msgstr "技術自主權與民主課責" + +#: ./foreword.md:block 23 (paragraph) +msgid "Public institutions, civil servants and residents deserve better." +msgstr "公家機關、公務員與居民都值得更好的。" + +#: ./foreword.md:block 24 (paragraph) +msgid "" +"We believe the software that runs our society can no longer be a black box, " +"controlled by outside companies that keep the underlying logic on which " +"their software operates hidden in proprietary codebases. Instead, " +"governments and the people they serve need technological sovereignty. This " +"allows them to set and control the functioning of public software, just like" +" they are able to set and control policy that is legally formulated in laws." +" Citizens and civil society actors need this software to be transparent and " +"accountable." +msgstr "" +"我們相信支持社會運作的軟體，再也不能是黑箱，任由外部公司依隱藏在專有程式基底" +"之下的秘密邏輯作控制。反過來說，政府，以及政府所要服務的人民，需要掌控技術自" +"主權。技術自主讓他們能主導設定與控制公共軟體的運作，正如同他們能依法制定與調" +"整政策一樣。人民與公民社會的參與者，都需要這類軟體能夠透明，且可以課責。" + +#: ./foreword.md:block 25 (paragraph) +msgid "" +"The design of software as essential civic infrastructure should honor " +"digital citizens’ rights." +msgstr "作為必要公民基礎建設的軟體，其設計應該尊重公民的數位權利。" + +#: ./foreword.md:block 26 (header) +msgid "Designing truly public software" +msgstr "設計真正的公共軟體" + +#: ./foreword.md:block 27 (paragraph) +msgid "" +"Public code is at the core of modern public institutions, shapes the work of" +" civil servants and affects the lives of almost all residents." +msgstr "公共程式是現代公家機構的核心，型塑了公務員的工作樣態，並且影響了幾乎所有居民" +"的生活。" + +#: ./foreword.md:block 28 (paragraph) +msgid "Public software must therefore be:" +msgstr "因此公共軟體必須：" + +#: ./foreword.md:block 29 (unordered list) +msgid "transparent" +msgstr "透明" + +#: ./foreword.md:block 29 (unordered list) +msgid "accountable" +msgstr "可課責" + +#: ./foreword.md:block 29 (unordered list) +msgid "understandable for its constituents" +msgstr "讓選民能夠理解" + +#: ./foreword.md:block 30 (paragraph) +msgid "" +"It must reflect the values of the society it serves, for example by being " +"inclusive and non-discriminatory." +msgstr "必須能反映其所服務的社會價值觀，像是涵容與不歧視。" + +#: ./foreword.md:block 31 (paragraph) +msgid "" +"Most proprietary software systems currently used by public organizations do " +"not meet these requirements. Public code does." +msgstr "目前公家機關使用的大多數專有軟體系統，都不符合這些要求；而公共程式能夠做到。" + +#: ./foreword.md:block 32 (header) +msgid "Values of public code" +msgstr "公共程式的價值" + +#: ./foreword.md:block 33 (paragraph) +msgid "We consider public code to have these core values:" +msgstr "我們認為公共程式應具有下列核心價值：" + +#: ./foreword.md:block 34 (unordered list) +msgid "Inclusive" +msgstr "涵容" + +#: ./foreword.md:block 34 (unordered list) +msgid "Usable" +msgstr "好用" + +#: ./foreword.md:block 34 (unordered list) +msgid "Open" +msgstr "開放" + +#: ./foreword.md:block 34 (unordered list) +msgid "Legible" +msgstr "易懂" + +#: ./foreword.md:block 34 (unordered list) +msgid "Accountable" +msgstr "課責" + +#: ./foreword.md:block 34 (unordered list) +msgid "Accessible" +msgstr "近用" + +#: ./foreword.md:block 34 (unordered list) +msgid "Sustainable" +msgstr "永續" + +#: ./foreword.md:block 35 (header) +msgid "How public code works" +msgstr "公共程式運作方式" + +#: ./foreword.md:block 36 (paragraph) +msgid "" +"Public code is open source software meant for fulfilling the essential role " +"of public organizations. Through use, other administrations contribute back " +"to the software, so that its development and maintenance become truly " +"collaborative." +msgstr "" +"公共程式是旨在協助公家機關，履行其必要職責時所採用的開放原始碼軟體。透過使用" +"，其他行政單位也能為軟體做出貢獻，因此公共程式的開發與維護，可說是真正互相協" +"作的成果。" + +#: ./foreword.md:block 37 (paragraph) +msgid "Being open unlocks many other things." +msgstr "開放的精神能開創許多可能性。" + +#: ./foreword.md:block 38 (paragraph) +msgid "" +"Local responsibility and democratic accountability are ensured when a public" +" organization implements and maintains their own public code. By being open " +"and with a broader contributor base, the software is more secure as it " +"benefits from many eyes spotting potential flaws. Many contributors share " +"the maintenance work to keep it functional and modern, which reduces future " +"technical debt. The shared workload is more sustainable now and in the " +"future. Its openness makes both the code and its data more easily adaptable " +"in the future. The code will be easier to retool, repurpose or retire. This " +"all results in lower risk public infrastructure." +msgstr "" +"公家機關在執行與維護其自身的公共程式時，就是在確保能為地方負責，並履行民主課" +"責。開放且貢獻者眾多的軟體，得利於有許多人在看，更容易發現潛在缺陷，因此安全" +"性會更高。許多貢獻者會分攤維護工作，讓公共程式能持續運作與更新，減少未來技術" +"債的可能。因為能有多人分攤維護工作，使得現在與未來都會更加永續。而公共程式的" +"開放性，代表其程式碼與資料，在未來也更容易改寫與調整。程式碼也更容易重新利用" +"、重新調整目標，或甚至淘汰。這一切特性都讓公共基礎建設可能遭遇的風險降到更低" +"。" + +#: ./foreword.md:block 39 (paragraph) +msgid "" +"This pooling of resources lets public administrations give extra attention " +"to how to customize the software so it works best in each local context, " +"creating better user experiences for their end users (residents or " +"citizens)." +msgstr "" +"這種將資源集中的作法，能讓公共行政單位可以有額外心力關注如何客製化軟體，來使" +"軟體最適合當地情境的需求，為終端使用者（居民或市民）創造更佳的使用體驗。" + +#: ./foreword.md:block 40 (header) +msgid "Economics of public code" +msgstr "公共程式的經濟效應" + +#: ./foreword.md:block 41 (paragraph) +msgid "" +"Public code offers a better economic model for public organizations as well " +"as for commercial companies. It's an alternative to traditional software " +"procurement which increases local control and economic opportunity." +msgstr "公共程式為公家機關以及商業公司，提供更好的經濟模型。公共程式作為替代傳統軟體" +"採購的方案，更能提升當地的掌控權並促進經濟機會。" + +#: ./foreword.md:block 42 (paragraph) +msgid "" +"Designed from the start to be open, adaptable and with data portability, it " +"can be developed by in-house staff or trusted vendors. Because the code is " +"open, the public administration can change vendors if they need to. Open " +"code increases opportunities for public learning and scrutiny, allowing the " +"public administration to procure smaller contracts. Smaller procurements are" +" easier for local small and medium enterprises to bid upon. Public " +"administrations can use their own software purchasing to stimulate " +"innovation and competition in their local economy." +msgstr "" +"公共程式從設計之初，就是要開放、適應力強、資料可攜，能夠由內部員工或信任的供" +"應商來開發。由於原始碼開放，公共行政單位在有需要時可以更換供應商。開放原始碼" +"讓社會大眾更有機會瞭解與監督公共程式，使公共行政單位得以採購小規模的合約，而" +"地方性的中小企業就更容易參與這些小型採購案的競標。如此一來，公共行政單位就可" +"以透過他們所需的軟體採購案，刺激當地經濟的創新與競爭。" + +#: ./foreword.md:block 43 (paragraph) +msgid "" +"This can be seen as investment leading to future economic growth. More " +"vendors will be necessary due to growing technology demand." +msgstr "這可視為對未來經濟成長的投資。隨著科技需求成長，也將需要更多供應商。" + +#: ./foreword.md:block 44 (header) +msgid "Procuring public code" +msgstr "購置公共程式" + +#: ./foreword.md:block 45 (paragraph) +msgid "" +"Public code can be used and developed by permanent in-house development " +"teams, contractors or outsourced suppliers. Vendors to public organizations " +"can include public code in their bids for contracts." +msgstr "公共程式可由常駐的內部研發團隊、承包商或外包供應商開發。公家機關的供應商，在" +"投標時可以在標案中納入公共程式。" + +#: ./foreword.md:block 46 (paragraph) +msgid "" +"To use existing public code, you need to specify in your budget and project " +"design that your new solution will use that codebase. To encourage an " +"innovative approach to adapting the public code to your context, you could " +"describe the service or outcome in your contract." +msgstr "" +"若要使用既有的公共程式，您將需要在預算以及專案設計中，明確指出新的解決方案將" +"會使用該程式基底。為了鼓勵創新，將公共程式依據您的情境背景作調整，您可在合約" +"中描述說明服務內容或預期成果。" + +#: ./foreword.md:block 47 (header) +msgid "The goals for the Standard for Public Code" +msgstr "《公共程式標準》目標" + +#: ./foreword.md:block 48 (paragraph) +msgid "" +"This Standard supports developers, designers, managers and public policy " +"makers to:" +msgstr "本標準在於支持開發人員、設計師、管理人員、公共政策制定者：" + +#: ./foreword.md:block 49 (unordered list) +msgid "" +"develop high quality software and policy for better public service delivery" +msgstr "開發出高品質的軟體與政策，來改善公共服務的交付" + +#: ./foreword.md:block 49 (unordered list) +msgid "" +"develop codebases that can be reused across contexts and collaboratively " +"maintained" +msgstr "開發出能在各種情境下重複使用，且以協作方式維護的程式基底" + +#: ./foreword.md:block 49 (unordered list) +msgid "reduce technical debt and project failure rate" +msgstr "減少技術債與專案失敗率" + +#: ./foreword.md:block 49 (unordered list) +msgid "" +"have more granular control over, and ability to make decisions about, their " +"IT systems" +msgstr "更能精細控制其 IT 系統粒度，並做出系統相關決策" + +#: ./foreword.md:block 49 (unordered list) +msgid "improve vendor relationships with a better economic model" +msgstr "以更好的經濟模型改善供應商關係" + +#: ./foreword.md:block 50 (paragraph) +msgid "" +"Potential users of codebases tested against the Standard for Public Code can" +" expect them to be highly reusable, easily maintainable and of high quality." +msgstr "如果有潛在使用者想採用經由《公共程式標準》測試過的程式基底，便可以預期這些程" +"式基底具有方便重複利用、容易維護、高品質的特性。" + +#: ./foreword.md:block 51 (paragraph) +msgid "The Standard for Public Code does this by:" +msgstr "《公共程式標準》能有此效果是基於：" + +#: ./foreword.md:block 52 (unordered list) +msgid "setting out a common terminology for public code development" +msgstr "為公共程式開發訂立通用術語" + +#: ./foreword.md:block 52 (unordered list) +msgid "establishing measures to help develop high quality public code" +msgstr "制定措施協助高品質公共程式的開發" + +#: ./foreword.md:block 52 (unordered list) +msgid "" +"providing guidance on how to fulfill its criteria and operationalize " +"compliance" +msgstr "提出該如何符合準則並實作遵循的指引" + +#: ./foreword.md:block 53 (paragraph) +msgid "" +"The Standard for Public Code is meant to be time and technology independent." +msgstr "《公共程式標準》設計精神就是要跨越時間與科技，不受其限制。" + +#: ./foreword.md:block 54 (header) +msgid "Who this is for" +msgstr "適用對象" + +#: ./foreword.md:block 55 (paragraph) +msgid "" +"The Standard for Public Code is for the people who create and reuse public " +"code:" +msgstr "《公共程式標準》適用於開發與重複使用公共程式的人：" + +#: ./foreword.md:block 56 (unordered list) +msgid "public policy makers" +msgstr "公共政策制定者" + +#: ./foreword.md:block 56 (unordered list) +msgid "business and project managers" +msgstr "業務與專案經理" + +#: ./foreword.md:block 56 (unordered list) +msgid "developers and designers" +msgstr "開發人員與設計師" + +#: ./foreword.md:block 57 (paragraph) +msgid "These people work at:" +msgstr "在以下單位服務的人：" + +#: ./foreword.md:block 58 (unordered list) +msgid "institutions, organizations and administrations in the public sector" +msgstr "社會機構、公家機關的組織與行政單位" + +#: ./foreword.md:block 58 (unordered list) +msgid "" +"consultancies and vendors of information technology and policy services to " +"public organizations" +msgstr "公家機關在資訊科技與政策服務上的顧問與供應商" + +#: ./foreword.md:block 59 (paragraph) +msgid "" +"It is not aimed at public organizations' end users (residents or citizens), " +"journalists or academics." +msgstr "適用對象不含公家機關的終端使用者（居民或市民）、記者或學者等。" + +#: ./foreword.md:block 61 (unordered list) +msgid "" +"[\"Modernising Public Infrastructure with Free Software\" white " +"paper](https://download.fsfe.org/campaigns/pmpc/PMPC-Modernising-with-Free-" +"Software.pdf) by the Free Software Foundation Europe." +msgstr "" +"歐洲自由軟體基金會所發表的[《透過自由軟體實現公共基礎設施現代化》白皮書](http" +"s://download.fsfe.org/campaigns/pmpc/PMPC-Modernising-with-Free-Software.pdf)" +" 》。" + +#: ./foreword.md:block 62 (header) +msgid "Videos on public code" +msgstr "探討公共程式的影片" + +#: ./foreword.md:block 63 (unordered list) +msgid "" +"[Collaborative Code is the Future of Cities @ DecidimFest " +"2019](https://www.youtube.com/watch?v=cnJtnZ9Cx1o). Talk by Ben Cerveny on " +"the background behind the Foundation for Public Code." +msgstr "" +"[「程式協作是城市的未來」@ DecidimFest 2019](https://www.youtube.com/" +"watch?v=cnJtnZ9Cx1o)。主講人 Ben Cerveny，講述 Foundation for Public Code " +"的背景。" + +#: ./foreword.md:block 63 (unordered list) +msgid "" +"[Public Money? Public Code! - Panel @ Nextcloud Conference " +"2019](https://youtube.com/watch?v=QHFkD4xfd6c). Touches on topics like " +"procurement, law and more." +msgstr "" +"[ 「用公共的納稅錢？做公共的程式吧！」專題討論 @ Nextcloud 大會 " +"2019](https://youtube.com/watch?v=QHFkD4xfd6c)。討論採購、法律等主題。" + +#: ./foreword.md:block 64 (header) +msgid "Get involved" +msgstr "參與我們" + +#: ./foreword.md:block 65 (paragraph) +msgid "" +"This standard is a living document. [Read our contributor " +"guide](/CONTRIBUTING.md) to learn how you can make it better." +msgstr "本標準是持續成長的文件。[請讀我們的〈貢獻者指引〉](/CONTRIBUTING." +"md)，瞭解您可以怎麼做來讓本標準變得更好。" + +#: ./foreword.md:block 66 (header) +msgid "Contact" +msgstr "聯絡方式" + +#: ./foreword.md:block 67 (paragraph) +msgid "" +"For questions and more information about the Foundation for Public Code you " +"can find us at [our website](https://publiccode.net/), email us at " +"info@publiccode.net, or call us at +31 20 2 444 500." +msgstr "" +"若有疑問，或想進一步瞭解 Foundation for Public " +"Code，請造訪[我們的網站](https://publiccode.net/)，或是寄電子郵件到 " +"info@publiccode.net，或撥打我們的電話 +31 20 2 444 500。" + +#: ./glossary.md:block 3 (header) +msgid "Glossary" +msgstr "詞彙表" + +#: ./glossary.md:block 4 (header) +msgid "Code" +msgstr "程式或程式碼 (Code)" + +#: ./glossary.md:block 5 (paragraph) +msgid "" +"Any explicitly described system of rules. This includes laws, policy and " +"ordinances, as well as source code that is used to build software. Both of " +"these are rules, some executed by humans and others by machines." +msgstr "" +"任何明確的規則系統，包括法律、政策與規則條例（法規、法式，也可稱為程式），以" +"及用來開發軟體的原始碼（程式碼）。兩者都是規則，有些是由人類來執行，其餘則是" +"由機器執行。" + +#: ./glossary.md:block 6 (header) +msgid "Codebase" +msgstr "程式基底 (Codebase)" + +#: ./glossary.md:block 7 (paragraph) +msgid "" +"Any discrete package of code (both source and policy), the tests and the " +"documentation required to implement a piece of policy or software." +msgstr "任何獨立分離的統合包，內含執行部分政策或軟體所需的程式（包含原始碼與政策）、" +"測試與文件等的整套內容。" + +#: ./glossary.md:block 8 (paragraph) +msgid "This can be, for example, a document or a version-control repository." +msgstr "舉例而言，這個具體形式可以是文件，或是版本控制的儲存庫。" + +#: ./glossary.md:block 9 (header) +msgid "Continuous integration" +msgstr "持續整合" + +#: ./glossary.md:block 10 (paragraph) +msgid "" +"In software engineering, continuous integration (CI) is the practice of " +"merging all developers' working copies to a development branch of a codebase" +" as frequently as reasonable." +msgstr "在軟體工程中，持續整合 (CI) 是盡可能頻繁地將所有開發人員工作中的副本，合併回" +"程式基底開發中分支的實務作法。" + +#: ./glossary.md:block 11 (header) +msgid "Different contexts" +msgstr "不同情境" + +#: ./glossary.md:block 12 (paragraph) +msgid "" +"Two contexts are different if they are different public organizations or " +"different departments for which there is not one decision maker that could " +"make collaboration happen naturally." +msgstr "只要是不同的公家機關或不同的部門，無法透過同一個決策單位讓協作自然發生，那就" +"算是兩個不同的情境。" + +#: ./glossary.md:block 13 (header) +msgid "General public" +msgstr "一般大眾" + +#: ./glossary.md:block 14 (paragraph) +msgid "" +"The public at large: end users of the code and the services based upon it." +msgstr "整體民眾：程式碼與其所建立的服務的終端使用者。" + +#: ./glossary.md:block 15 (paragraph) +msgid "" +"For example, a city's residents are considered end users of a city's " +"services and of all code that powers these services." +msgstr "舉例而言，城市的居民即視為該城市的服務、以及驅動這些服務運作的程式碼的終端使" +"用者。" + +#: ./glossary.md:block 16 (header) +msgid "Open source" +msgstr "開源或開放原始碼 (Open Source)" + +#: ./glossary.md:block 17 (paragraph) +msgid "" +"Open source is defined by the Open Source Initiative in their [Open Source " +"Definition](https://opensource.org/osd-annotated)." +msgstr "" +"所謂「開源」或「開放原始碼」，是根據 OSI " +"開放原始碼促進會發表的《[開放原始碼定義](https://opensource.org/osd-" +"annotated)》而來。" + +#: ./glossary.md:block 18 (header) +msgid "Open standard" +msgstr "開放標準" + +#: ./glossary.md:block 19 (paragraph) +msgid "" +"An open standard is any standard that meets the Open Source Initiative's " +"[Open Standard Requirements](https://opensource.org/osr)." +msgstr "任何符合 OSI 開放原始碼促進會《[開放標準需求規範](https://opensource.org/" +"osr)》的標準，就是開放標準。" + +#: ./glossary.md:block 20 (header) +msgid "Policy" +msgstr "政策" + +#: ./glossary.md:block 21 (paragraph) +msgid "" +"A policy is a deliberate system of principles to guide decisions and achieve" +" rational outcomes. A policy is a statement of intent, and is implemented as" +" a procedure or protocol. Policies are generally adopted by a governance " +"body within an organization. Policies can assist in both subjective and " +"objective decision making." +msgstr "" +"政策是一套謹慎設計的原則體系，用來引導決策並達成合理的成果。政策是一種意圖的" +"聲明，並以程序或協定來執行。政策通常是由組織單位內的理事機構採用執行。政策能" +"協助做出主觀與客觀的決策。" + +#: ./glossary.md:block 22 (paragraph) +msgid "" +"Public policy is the process by which governments translate their political " +"vision into programs and actions to deliver outcomes." +msgstr "公共政策是政府將其政治願景，轉化成計畫與行動來取得成果的程序。" + +#: ./glossary.md:block 23 (paragraph) +msgid "" +"At the national level, policy and legislation (the law) are usually " +"separate. The distinction is often more blurred in local government." +msgstr "在國家層級，政策與立法（法律）通常是分開的；而在地方政府中，這兩者之間的區別" +"通常比較模糊。" + +#: ./glossary.md:block 24 (paragraph) +msgid "" +"In the Standard the word 'policy' refers to policy created and adopted by " +"public organizations such as governments and municipalities." +msgstr "在本標準當中，「政策」一詞指的是公家機關，例如政府與自治市等，所制定與採用的" +"政策。" + +#: ./glossary.md:block 25 (header) +msgid "Public code" +msgstr "公共程式 (Public Code)" + +#: ./glossary.md:block 26 (paragraph) +msgid "" +"Public code is open source software developed by public organizations, " +"together with the policy and guidance needed for collaboration and reuse." +msgstr "公共程式，是由公家機關所開發的開放原始碼軟體，同時包含協作與重複利用所需的政" +"策與指引。" + +#: ./glossary.md:block 27 (paragraph) +msgid "" +"Public code is both computer source code (such as software and algorithms) " +"and public policy executed in a public context, by humans or machines." +msgstr "公共程式是在公共情境下，由人類或機器所執行的電腦原始碼（例如軟體與演算法）以" +"及公共政策兩者。" + +#: ./glossary.md:block 28 (paragraph) +msgid "" +"Public code serves the public interest, is open, legible, accountable, " +"accessible and sustainable." +msgstr "服務公眾利益的公共程式，具有開放、易懂、課責、近用、永續等特性。" + +#: ./glossary.md:block 29 (paragraph) +msgid "" +"By developing public code independently from but still implementable in the " +"local context for which it was developed, as well as documenting the " +"development process openly, public code can provide a building block for " +"others to:" +msgstr "" +"透過獨立於當地情境，但仍可在當地情境下實作的方式，還有公開以文件記錄開發程序" +"等作法，來開發公共程式。如此，公共程式能作為基礎組件提供給他人，使其得以：" + +#: ./glossary.md:block 30 (unordered list) +msgid "re-implement in their local context" +msgstr "根據其當地情境重新實作" + +#: ./glossary.md:block 30 (unordered list) +msgid "take as a starting point to continue development" +msgstr "作為起點並繼續開發" + +#: ./glossary.md:block 30 (unordered list) +msgid "use as a basis for learning" +msgstr "當作學習時的基礎" + +#: ./glossary.md:block 31 (paragraph) +msgid "" +"To facilitate reuse, public code is either released into the public domain " +"or licensed with an open license that permits others to view and reuse the " +"work freely and to produce derivative works." +msgstr "為了促進重複利用，公共程式通常放到公眾領域發行，或者採取允許他人能自由檢視、" +"重複利用其成果，甚至產出衍生作品的開放授權。" + +#: ./glossary.md:block 32 (header) +msgid "Repository" +msgstr "儲存庫" + +#: ./glossary.md:block 33 (paragraph) +msgid "" +"A repository is a storage location used by version control tools for files " +"and metadata of a codebase. Repositories allow multiple contributors to work" +" on the same set of files. Repositories are able to store multiple versions " +"of sets of files." +msgstr "" +"儲存庫是版本控制工具，用於存放程式基底的檔案與中介資料的儲存位置。儲存庫讓多" +"位貢獻者，得以同時對同一組檔案作業。儲存庫可以儲存一組檔案的多個版本。" + +#: ./glossary.md:block 34 (header) +msgid "Source Code" +msgstr "原始碼 (Source Code)" + +#: ./glossary.md:block 35 (paragraph) +msgid "" +"Human readable text of a computer program which can be translated into " +"machine instructions." +msgstr "人類可讀，並且能夠翻譯成機器指令的電腦程式文字。" + +#: ./glossary.md:block 36 (header) +msgid "Version control" +msgstr "版本控制" + +#: ./glossary.md:block 37 (paragraph) +msgid "" +"Version control is the management of changes to source code and the files " +"associated with it. Changes are usually identified by a code, termed the " +"*revision number* (or similar). Each revision is associated with the time it" +" was made and the person making the change, thus making it easier to retrace" +" the evolution of the code. Revision control systems can be used to compare " +"different versions with each other and to see how content has changed over " +"time." +msgstr "" +"版本控制，是對原始碼及其相關檔案的變動行為作管理的流程。變動行為，通常是以稱" +"為「*修訂編號*」（或版次等類似名稱）的代號作識別。每次修訂都會標示其改動時間" +"以及作者，方便追溯程式碼的演進。修訂控制系統可用來比較不同版本之間的差異，以" +"及查看內容隨著時間經歷的變動。" + +#: ./index.md:block 3 (header) +msgid "toc: false" +msgstr "toc: false" + +#: ./index.md:block 4 (header) +msgid "Guidance for government open source collaboration" +msgstr "政府開放原始碼協作指引" + +#: ./index.md:block 5 (paragraph) +msgid "" +"The Standard for Public Code is a set of criteria that supports public " +"organizations in developing and maintaining software and policy together." +msgstr "《公共程式標準》是一套支持公家機關一同協作開發軟體與政策，以及維護的準則。" + +#: ./index.md:block 6 (paragraph) +msgid "" +"The Standard for Public Code provides guidance to public organizations " +"building their own open source solutions to enable successful future " +"collaboration and reuse by similar organizations in the public sector in " +"other places. It includes advice for policy makers, government managers, " +"developers and vendors. The Standard for Public Code supports the " +"collaborative creation of codebases that are usable, open, legible, " +"accountable, accessible and sustainable. It is meant to be applicable to " +"codebases for all levels of government, from supranational to municipal." +msgstr "" +"《公共程式標準》為那些在建構自身開放原始碼解決方案的公家機關提供指引，以便他" +"們未來能成功與其他地方的類似公部門單位互相協作，並且重複使用各自的成果。這份" +"標準涵蓋寫給政策制定者、政府管理人員、開發人員與供應商的建議。《公共程式標準" +"》支持公家機關透過協作方式，創造出好用、開放、易懂、課責、近用、永續的程式基" +"底。這份標準從設計之初，就是要用於各種不同政府層級的程式基底，小從市政府，大" +"到超國家組織都行。" + +#: ./index.md:block 7 (paragraph) +msgid "" +"The Standard for Public Code defines ‘[public code](glossary.md#public-" +"code)’ as open source software developed by public organizations, together " +"with the policy and guidance needed for collaboration and reuse." +msgstr "" +"《公共程式標準》將「[公共程式](glossary.md#public-code)」定義為：由公家機關所" +"開發的開放原始碼軟體，同時包含協作與重複使用所需的政策與指引。" + +#: ./index.md:block 8 (paragraph) +msgid "" +"The criteria of the Standard for Public Code are aligned with guidelines and" +" best practices of open source software development." +msgstr "《公共程式標準》當中的準則，符合開放原始碼軟體開發的指引與最佳實務。" + +#: ./index.md:block 9 (paragraph) +msgid "" +"{% for page in site.pages %}{% if page.name == \"foreword.md\" %} Additional" +" context and background can be found in the [foreword](foreword.md). {% " +"endif%}{% endfor %}" +msgstr "" +"{% for page in site.pages %}{% if page.name == \"foreword.md\" %} " +"其他情境與背景資訊請參閱[序文](foreword.md)。 {% endif%}{% endfor %}" + +#: ./index.md:block 10 (header) +msgid "Contents" +msgstr "目次" + +#: ./index.md:block 11 (unordered list) +msgid "[Readers guide: how to interpret this standard](readers-guide.md)" +msgstr "[讀者指引：如何解讀本標準](readers-guide.md)" + +#: ./index.md:block 11 (unordered list) +msgid "[Glossary](glossary.md)" +msgstr "[詞彙表](glossary.md)" + +#: ./index.md:block 11 (unordered list) +msgid "" +"[Criteria](criteria/){% assign sorted = site.pages | sort:\"order\" %}{% for" +" page in sorted %}{% if page.dir == \"/criteria/\" %}{% if page.name != " +"\"index.md\" %}{% if page.title %}" +msgstr "" +"[準則](criteria/){% assign sorted = site.pages | sort:\"order\" %}{% for " +"page in sorted %}{% if page.dir == \"/criteria/\" %}{% if page.name != " +"\"index.md\" %}{% if page.title %}" + +#: ./index.md:block 11 (unordered list) +msgid "" +"[{{page.title}}]({{page.url}}){% endif%}{% endif%}{% endif%}{% endfor %}" +msgstr "" +"[{{page.title}}]({{page.url}}){% endif%}{% endif%}{% endif%}{% endfor %}" + +#: ./index.md:block 11 (unordered list) +msgid "[Authors](AUTHORS.md)" +msgstr "[作者群](AUTHORS.md)" + +#: ./index.md:block 11 (unordered list) +msgid "[Contributing guide](CONTRIBUTING.md)" +msgstr "[貢獻指引](CONTRIBUTING.md)" + +#: ./index.md:block 11 (unordered list) +msgid "[Code of conduct](CODE_OF_CONDUCT.md)" +msgstr "[行為守則](CODE_OF_CONDUCT.md)" + +#: ./index.md:block 11 (unordered list) +msgid "[Governance](GOVERNANCE.md)" +msgstr "[治理方式](GOVERNANCE.md)" + +#: ./index.md:block 11 (unordered list) +msgid "[Version history](CHANGELOG.md)" +msgstr "[版本歷史](CHANGELOG.md)" + +#: ./index.md:block 11 (unordered list) +msgid "[License](license.html)" +msgstr "[授權](license.html)" + +#: ./index.md:block 12 (header) +msgid "Community calls" +msgstr "社群會議" + +#: ./index.md:block 13 (paragraph) +msgid "" +"We usually have a community call on the first Thursday of the month at 15:00" +" (CET/CEST). [The agenda](https://write.publiccode.net/pads/Community-Call-" +"Standard-for-Public-Code) is updated roughly a week before the call. It is " +"possible to [sign " +"up](https://odoo.publiccode.net/survey/start/594b9243-c7e5-4bc1-8714-35137c971842)" +" to get a call invitation emailed to you." +msgstr "" +"我們通常在每月第一個週四的 15:00 (CET/CEST) " +"舉辦社群會議。[議程](https://write.publiccode.net/pads/Community-Call-" +"Standard-for-Public-Code)在會議前約一週的時間更新。您可以[註冊](https://odoo." +"publiccode.net/survey/start/" +"594b9243-c7e5-4bc1-8714-35137c971842)報名，會再寄送會議通話邀請函給您。" + +#: ./index.md:block 14 (header) +msgid "Other resources" +msgstr "其他資源" + +#: ./index.md:block 15 (unordered list) +msgid "" +"Unofficial [community translations of the " +"Standard](https://publiccodenet.github.io/community-translations-standard/) " +"in other languages" +msgstr "" +"本標準非官方的其他語言[社群翻譯](https://publiccodenet.github.io/" +"community-translations-standard/)" + +#: ./index.md:block 15 (unordered list) +msgid "" +"[Standard compliance self " +"assessment](https://publiccodenet.github.io/assessment-eligibility/) for " +"public sector open source codebases" +msgstr "" +"公部門開放原始碼程式基底的《[標準遵循自我評估](https://publiccodenet.github." +"io/assessment-eligibility/)》" + +#: ./index.md:block 15 (unordered list) +msgid "" +"[Standard criteria " +"checklist](https://github.com/publiccodenet/standard/blob/develop/docs/review-" +"template.html) used by Foundation for Public Code stewards for codebase " +"review" +msgstr "" +"Foundation for Public Code " +"執事人員審查程式基底時所使用的《[本標準準則檢查清單](https://github.com/" +"publiccodenet/standard/blob/develop/docs/review-template.html)》" + +#: ./readers-guide.md:block 3 (header) +msgid "Readers guide" +msgstr "讀者指引" + +#: ./readers-guide.md:block 4 (paragraph) +msgid "" +"The Standard describes a number of criteria. All criteria have consistent " +"sections that make it clear how to create great public code." +msgstr "本標準描述說明許多準則。所有準則各小節結構維持一致，來讓讀者清楚明白如何開發" +"良好的公共程式。" + +#: ./readers-guide.md:block 5 (paragraph) +msgid "" +"References to \"policy makers\", \"managers\", and \"developers and " +"designers\" apply to anyone performing duties associated with these roles, " +"regardless of their job title. It is common for individuals to have duties " +"which span multiple roles." +msgstr "「政策制定者」、「管理人員」以及「開發人員與設計師」的稱呼，係指任何履行這些" +"角色職責的人，不受其職稱限制。常見同時承擔多個角色職責的人。" + +#: ./readers-guide.md:block 6 (paragraph) +msgid "" +"Below is a brief explanation of each of these sections and how they are used" +" within the criteria of the Standard." +msgstr "以下是各小節的簡要介紹，以及在本標準準則中的作用。" + +#: ./readers-guide.md:block 7 (header) +msgid "Introduction" +msgstr "前言" + +#: ./readers-guide.md:block 8 (paragraph) +msgid "" +"This section explains what the criterion aims to achieve and why it is " +"important for a codebase's users and contributors." +msgstr "本小節說明這些準則想達成的目的，以及為何會對程式基底使用者與貢獻者來說這麼重" +"要的原因。" + +#: ./readers-guide.md:block 10 (paragraph) +msgid "" +"This section lists what needs to be done in order to comply with the " +"standard." +msgstr "這個小節列出如果要遵循本標準，需要完成哪些事項。" + +#: ./readers-guide.md:block 11 (paragraph) +msgid "" +"The following keywords in this document are to be interpreted as described " +"in [IETF RFC 2119](https://tools.ietf.org/html/rfc2119):" +msgstr "" +"本文件中的下列關鍵字，請以《[IETF RFC 2119](https://tools.ietf.org/html/" +"rfc2119)》的描述作解釋：" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "MUST" +msgstr "必須" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "MUST NOT" +msgstr "禁止" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "REQUIRED" +msgstr "要求" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "SHALL" +msgstr "應當" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "SHALL NOT" +msgstr "不得" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "SHOULD" +msgstr "應該" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "SHOULD NOT" +msgstr "不該" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "RECOMMENDED" +msgstr "建議" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "MAY" +msgstr "得以" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "OPTIONAL" +msgstr "可選擇" + +#: ./readers-guide.md:block 14 (paragraph) +msgid "" +"This section offers actions you can take to see if a contribution is " +"compliant with the Standard. This is key if you want to operationalize the " +"Standard." +msgstr "本小節提供您可採取的行動，來確認貢獻內容是否遵循本標準。如果您想要務實操作本" +"標準，這部分很關鍵。" + +#: ./readers-guide.md:block 15 (paragraph) +msgid "" +"We've tried to word it so that someone who is not intimately acquainted with" +" the subject matter can still do a basic check for compliance." +msgstr "我們已嘗試調整用字，讓即使是不熟悉這類主題內容的讀者，看完之後也能夠進行基本" +"的遵循檢查。" + +#: ./readers-guide.md:block 17 (paragraph) +msgid "" +"This section tries to specifically speak to policy makers by offering them " +"concrete actions they can perform in their role." +msgstr "本小節主要對象是政策制定者，列出他們的角色所能採取的具體行動。" + +#: ./readers-guide.md:block 18 (paragraph) +msgid "" +"Public policy makers set the priorities and goals of projects and may be " +"less technologically experienced." +msgstr "公共政策制定者設定專案的優先順序與目標，而在科技上的經驗可能沒那麼多。" + +#: ./readers-guide.md:block 20 (paragraph) +msgid "" +"This section tries to specifically speak to managers by offering concrete " +"actions they can perform in their role." +msgstr "本小節主要對象是管理人員，列出他們的角色所能採取的具體行動。" + +#: ./readers-guide.md:block 21 (paragraph) +msgid "" +"Managers are responsible for on-time project delivery, stakeholder " +"management and continued delivery of the service. For this they are wholly " +"reliant on both policy makers as well as developers and designers. They need" +" to create the right culture, line up the right resources and provide the " +"right structures to deliver great services." +msgstr "" +"管理人員負責監督專案的準時交付、利害關係人管理，以及服務的持續交付。因此，他" +"們得完全依賴政策制定者、開發人員與設計師。他們需要塑造正確的文化、籌備合適的" +"資源、提供適當的架構等，才能交付優良的服務。" + +#: ./readers-guide.md:block 23 (paragraph) +msgid "" +"This section tries to specifically speak to developers and designers by " +"offering them concrete actions they can perform in their role." +msgstr "本小節主要對象是開發人員與設計師，列出他們的角色能採取的具體行動。" + +#: ./readers-guide.md:block 24 (paragraph) +msgid "" +"Developers are usually more technically aligned and have more impact on the " +"delivery of services than the previous groups." +msgstr "開發人員通常對技術比較在行，與其他角色類別相比，對服務交付的影響更大。" + +#: ./readers-guide.md:block 25 (header) +msgid "Limitation of scope" +msgstr "作用範圍限制" + +#: ./readers-guide.md:block 26 (paragraph) +msgid "" +"The Standard for Public Code is not meant to cover individual " +"implementations of a codebase. This means the standard does not tell " +"implementers how to comply with their organization's local technical " +"infrastructure or legal framework." +msgstr "《公共程式標準》不是為了涵蓋程式基底的個別實作而撰寫。這代表本標準不是要告訴" +"實作人員，該如何遵循其組織單位當地的技術性基礎建設或法律框架。" + +#: ./readers-guide.md:block 27 (paragraph) +msgid "" +"Also, while the Standard for Public Code refers to several standards and has" +" considerable overlap with others, its purpose is to enable collaboration. " +"Therefore, it does not aim to replace quality standards, like the ISO 25000 " +"series, or those focusing on security, like the [OpenSSF Best Practices " +"Badge](https://github.com/coreinfrastructure/best-practices-badge), but to " +"synergize well with them." +msgstr "" +"此外，雖然《公共程式標準》有引用一些標準，並且與其他標準有滿多重疊的部分，但" +"本標準的目的是要推動協作。因此，本標準目標不在於取代品質標準，像是 ISO 25000 " +"認證系列，或是取代那些聚焦於安全性的標準，例如 [OpenSSF " +"最佳實務標章](https://github.com/coreinfrastructure/best-practices-" +"badge)等，而是希望能與它們能良好協同搭配。" + +#: ./readers-guide.md:block 28 (paragraph) +msgid "" +"And while the purpose includes enabling collaboration, it will not guarantee" +" that a community will spring into existence. That still requires " +"proactiveness and ambition beyond making the codebase collaboration ready." +msgstr "" +"《公共程式標準》的目在於促進協作，但也無法保證能夠催生出一個社群。若要建立社" +"群，除了程式基底需要準備好進行協作以外，也需要積極主動，以及做到超越協作以外" +"的企圖心。" + +msgid "" +"script/release-body.sh expects VERSION in the first second-level header" +msgstr "script/release-body.sh 預期 VERSION 放在第一個第二層的標頭中" + +msgid "script/update-changelog-date.sh expects DATE-OF-RELEASE and a colon" +msgstr "script/update-changelog-date.sh 預期 DATE-OF-RELEASE 與一個冒號「:」" + +msgid "Version 0.7.1" +msgstr "0.7.1 版" + +msgid "" +"July 31st 2023: 💄 The sixteenth draft change the name of a criterion and " +"clarifies references to code." +msgstr "2023/07/31: 💄 第十六版草稿修改準則名稱，並釐清程式 code 的稱呼。" + +msgid "" +"The criterion \"Make the codebase reusable and portable\" was renamed from " +"\"Create reusable and portable code\"." +msgstr "〈程式碼要可重複使用且可攜〉準則改名為〈程式基底要可重複使用且可移植〉。" + +msgid "Added a glossary entry for \"Source Code\"." +msgstr "新增詞彙條目「原始碼」。" + +msgid "" +"References to \"code\" which only applied to \"source code\" now reference " +"\"source code\" explicitly." +msgstr "對於只適用於「原始碼」意義的「程式 (code)」，現在明確以「原始碼」稱呼。" + +msgid "Clarification of \"running code\" as \"software\"." +msgstr "將「運作的程式碼」釐清稱為「軟體」。" + +msgid "Minor changes to clarify \"code\" vs \"codebase\"." +msgstr "細微修改以清楚區分「程式碼」與「程式基底」。" + +msgid "Simplify guidance to policy makers in Bundle policy and source code." +msgstr "簡化給政策制定者在〈政策與原始碼要合捆〉中的指引。" + +msgid "" +"Clarify How to test sections of Make the codebase findable and Make the " +"codebase reusable and portable." +msgstr "釐清〈程式基底可查詢得到〉與〈程式基底要可重複使用且可移植〉的「測試方式」小" +"節。" + +msgid "Add a criteria and requirements checklist to the release artifacts." +msgstr "在發行成品前的要求中，加入準則與需求規定檢查清單。" + +msgid "Increase automation of the release process." +msgstr "提升發行流程的自動化程度。" + +msgid "" +"![version 0.7.1](assets/version-badge.svg) [![License: " +"CC0-1.0](https://img.shields.io/badge/License-" +"CC0_1.0-lightgrey.svg)](http://creativecommons.org/publicdomain/zero/1.0/) " +"[![Standard commitment](assets/standard-for-public-code-" +"commitment.svg)](#help-improve-this-standard)" +msgstr "" +"![version 0.7.1](assets/version-badge.svg) [![License: CC0-1.0](https://img." +"shields.io/badge/License-CC0_1.0-lightgrey.svg)](http://creativecommons.org/" +"publicdomain/zero/1.0/) [![標準承諾](assets/standard-for-public-code-" +"commitment.svg)](#help-improve-this-standard)" + +msgid "" +"If you want to apply the Standard for Public Code to your codebase, just go " +"ahead, it's an open standard and free for anyone to use. If you wish to " +"advertise the codebase community's aspiration to meet the criteria of the " +"Standard for Public Code, link the documentation of this commitment from the" +" [standard-for-public-code-commitment badge](assets/standard-for-public-" +"code-commitment.svg). To see how ready your codebase is, you can do a quick " +"[eligibility self assessment](https://publiccodenet.github.io/assessment-" +"eligibility) that will give you a rough idea of how much work you may need " +"to do to meet all criteria." +msgstr "" +"若您想要將《公共程式標準》套用您的程式基底，就請放心去做，因為它是人人都能自" +"由採用的開放標準。如果您希望宣傳程式基底社群達成《公共程式標準》準則要求時的" +"熱誠，請使用 [standard-for-public-code-commitment 徽章](assets/standard-for-" +"public-code-commitment.svg)連結到這份承諾文件。若要瞭解您程式基底所達成的程度" +"，可以做[自我資格評估](https://publiccodenet.github.io/assessment-" +"eligibility)；它能幫助您大略瞭解，如果想要滿足所有準則，還需要下多少功夫。" + +msgid "Update [`roadmap.md`](roadmap.md)" +msgstr "更新 [`roadmap.md`](roadmap.md)" + +msgid "" +"update `docs/standard-for-public-code.html` with the new text from the " +"review template, updating any status changes as a result" +msgstr "使用審查範本中的新文字來更新 `docs/standard-for-public-code." +"html`，會將任何狀態變更作為結果更新" + +msgid "" +"Push branch, compare with 'main' branch, i.e.: " +"`https://github.com/publiccodenet/standard/compare/main...release-$MAJOR.$MINOR.$PATCH`" +msgstr "" +"推送分支，與「main」分支比較，範例：`https://github.com/publiccodenet/" +"standard/compare/main...release-$MAJOR.$MINOR.$PATCH`" + +msgid "`git tag trigger-$MAJOR.$MINOR.$PATCH`" +msgstr "`git tag trigger-$MAJOR.$MINOR.$PATCH`" + +msgid "delete local tag: `git tag -d trigger-$MAJOR.$MINOR.$PATCH`" +msgstr "移除本地端的 tag 標記：`git tag -d trigger-$MAJOR.$MINOR.$PATCH`" + +msgid "Separate executive summary (issue #302)" +msgstr "分離執行摘要 (issue #302)" + +msgid "" +"[Standard criteria checklist](/docs/review-template.html) used by Foundation" +" for Public Code stewards for codebase review" +msgstr "" +"Foundation for Public Code 執事人員用於程式基底審查的《[標準準則檢查清單](/" +"docs/review-template.html)》" diff --git a/_site/package.json b/_site/package.json new file mode 100644 index 00000000..fb24660f --- /dev/null +++ b/_site/package.json @@ -0,0 +1,5 @@ +{ + "dependencies": { + "badge-maker": "^3.3.1" + } +} diff --git a/_site/print-cover.html b/_site/print-cover.html new file mode 100644 index 00000000..5c3f5c2f --- /dev/null +++ b/_site/print-cover.html @@ -0,0 +1,308 @@ + + + + + + + + + + Standard for Public Code + + + + + +
+
+
+

+ The Standard for Public Code supports the collaborative creation of codebases that are usable, open, legible, accountable, accessible and sustainable. + The Standard includes guidance to policymakers, managers, designers and developers creating and managing codebases. +

+

+ The standard specifies the criteria: + +

    + + + + + + + + + + + + + + + + + +
  1. 原始碼要開放
    2. + +
  2. 政策與原始碼要合捆
    3. + +
  3. 程式基底要可重複使用且可移植
    4. + +
  4. 歡迎貢獻者
    5. + +
  5. 貢獻要容易
    6. + +
  6. 維護版本控制
    7. + +
  7. 要求審查貢獻內容
    8. + +
  8. 程式基底要有目標文件
    9. + +
  9. 程式碼要有文件
    10. + +
  10. 使用白話的英語
    11. + +
  11. 採用開放標準
    12. + +
  12. 使用持續整合
    13. + +
  13. 發行採用開放授權
    14. + +
  14. 程式基底可查詢得到
    15. + +
  15. 風格要前後一致
    16. + +
  16. 記錄程式基底成熟度
    17. + +
+

+
+ + hand pointing + + +
+ +
+
+

Request for contributions

+

Standard for Public Code

+
+ +
    + What public code is and how to implement it for: +
  • Public policy makers
    • +
  • Managers
    • +
  • Developers and designers
    • +
+ + hands shaking + +
+

Draft
Version 0.7.1

+

Licensed CC0 Digital Public Goods approval badge

+

https://standard.publiccode.net/

+
+
+
+ + + + diff --git a/_site/print-review-template.html b/_site/print-review-template.html new file mode 100644 index 00000000..7d5cbde2 --- /dev/null +++ b/_site/print-review-template.html @@ -0,0 +1,925 @@ + + + + + + + + + + Standard for Public Code + + + +
+ +

________ and the Standard for Public Code version 0.4.0

+ + + + +

Link to commitment to meet the Standard for Public Code:

+ +

Code in the open

+ +

☐ criterion met.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Requirementmeets links and notes 
All source code for any policy in use (unless used for fraud detection) MUST be published and publicly accessible.  
All source code for any software in use (unless used for fraud detection) MUST be published and publicly accessible.  
Contributors MUST NOT upload sensitive information regarding users, their organization or third parties to the repository.  
Any source code not currently in use (such as new versions, proposals or older versions) SHOULD be published.  
Documenting which source code or policy underpins any specific interaction the general public may have with an organization is OPTIONAL.  
+ +

Bundle policy and source code

+ +

☐ criterion met.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Requirementmeets links and notes 
The codebase MUST include the policy that the source code is based on.  
The codebase MUST include all source code that the policy is based on, unless used for fraud detection.  
Policy SHOULD be provided in machine readable and unambiguous formats.  
Continuous integration tests SHOULD validate that the source code and the policy are executed coherently.  
+ +

Create reusable and portable code

+ +

☐ criterion met.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Requirementmeets links and notes 
The codebase MUST be developed to be reusable in different contexts.  
The codebase MUST be independent from any secret, undisclosed, proprietary or non-open licensed code or services for execution and understanding.  
The codebase SHOULD be in use by multiple parties.  
The roadmap SHOULD be influenced by the needs of multiple parties.  
Configuration SHOULD be used to make code adapt to context specific needs.  
The codebase SHOULD be localizable.  
Code and its documentation SHOULD NOT contain situation-specific information.  
Codebase modules SHOULD be documented in such a way as to enable reuse in codebases in other contexts.  
+ +

Welcome contributors

+ +

☐ criterion met.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Requirementmeets links and notes 
The codebase MUST allow anyone to submit suggestions for changes to the codebase.  
The codebase MUST include contribution guidelines explaining what kinds of contributions are welcome and how contributors can get involved, for example in a CONTRIBUTING file.  
The codebase MUST document the governance of the codebase, contributions and its community, for example in a GOVERNANCE file.  
The codebase SHOULD advertise the committed engagement of involved organizations in the development and maintenance.  
The codebase SHOULD have a publicly available roadmap.  
The codebase SHOULD publish codebase activity statistics.  
Including a code of conduct for contributors in the codebase is OPTIONAL.  
+ +

Make contributing easy

+ +

☐ criterion met.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Requirementmeets links and notes 
The codebase MUST have a public issue tracker that accepts suggestions from anyone.  
The codebase MUST include instructions for how to privately report security issues for responsible disclosure.  
The documentation MUST link to both the public issue tracker and submitted codebase changes, for example in a README file.  
The codebase MUST have communication channels for users and developers, for example email lists.  
The documentation SHOULD include instructions for how to report potentially security sensitive issues on a closed channel.  
+ +

Maintain version control

+ +

☐ criterion met.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Requirementmeets links and notes 
The community MUST have a way to maintain version control for the code.  
All files in the codebase MUST be version controlled.  
All decisions MUST be documented in commit messages.  
Every commit message MUST link to discussions and issues wherever possible.  
The codebase SHOULD be maintained in a distributed version control system.  
Contributors SHOULD group relevant changes in commits.  
Maintainers SHOULD mark released versions of the codebase, for example using revision tags or textual labels.  
Contributors SHOULD prefer file formats where the changes within the files can be easily viewed and understood in the version control system.  
It is OPTIONAL for contributors to sign their commits and provide an email address, so that future contributors are able to contact past contributors with questions about their work.  
+ +

Require review of contributions

+ +

☐ criterion met.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Requirementmeets links and notes 
All contributions that are accepted or committed to release versions of the codebase MUST be reviewed by another contributor.  
Reviews MUST include source, policy, tests and documentation.  
Reviewers MUST provide feedback on all decisions to not accept a contribution.  
Contributions SHOULD conform to the standards, architecture and decisions set out in the codebase in order to pass review.  
Reviews SHOULD include running both the code and the tests of the codebase.  
Contributions SHOULD be reviewed by someone in a different context than the contributor.  
Version control systems SHOULD NOT accept non-reviewed contributions in release versions.  
Reviews SHOULD happen within two business days.  
Performing reviews by multiple reviewers is OPTIONAL.  
+ +

Document codebase objectives

+ +

☐ criterion met.

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Requirementmeets links and notes 
The codebase MUST contain documentation of its objectives, like a mission and goal statement, that is understandable by developers and designers so that they can use or contribute to the codebase.  
Codebase documentation SHOULD clearly describe the connections between policy objectives and codebase objectives.  
Documenting the objectives of the codebase for the general public is OPTIONAL.  
+ +

Document the code

+ +

☐ criterion met.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Requirementmeets links and notes 
All of the functionality of the codebase, policy as well as source, MUST be described in language clearly understandable for those that understand the purpose of the code.  
The documentation of the codebase MUST contain a description of how to install and run the source code.  
The documentation of the codebase MUST contain examples demonstrating the key functionality.  
The documentation of the codebase SHOULD contain a high level description that is clearly understandable for a wide audience of stakeholders, like the general public and journalists.  
The documentation of the codebase SHOULD contain a section describing how to install and run a standalone version of the source code, including, if necessary, a test dataset.  
The documentation of the codebase SHOULD contain examples for all functionality.  
The documentation SHOULD describe the key components or modules of the codebase and their relationships, for example as a high level architectural diagram.  
There SHOULD be continuous integration tests for the quality of the documentation.  
Including examples that make users want to immediately start using the codebase in the documentation of the codebase is OPTIONAL.  
Testing the code by using examples in the documentation is OPTIONAL.  
+ +

Use plain English

+ +

☐ criterion met.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Requirementmeets links and notes 
All codebase documentation MUST be in English.  
All code MUST be in English, except where policy is machine interpreted as code.  
All bundled policy not available in English MUST have an accompanying summary in English.  
Any translation MUST be up to date with the English version and vice versa.  
There SHOULD be no acronyms, abbreviations, puns or legal/non-English/domain specific terms in the codebase without an explanation preceding it or a link to an explanation.  
The name of the codebase SHOULD be descriptive and free from acronyms, abbreviations, puns or organizational branding.  
Documentation SHOULD aim for a lower secondary education reading level, as recommended by the Web Content Accessibility Guidelines 2.  
Providing a translation of any code, documentation or tests is OPTIONAL.  
+ +

Use open standards

+ +

☐ criterion met.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Requirementmeets links and notes 
For features of the codebase that facilitate the exchange of data the codebase MUST use an open standard that meets the Open Source Initiative Open Standard Requirements.  
Any non-open standards used MUST be recorded clearly as such in the documentation.  
Any standard chosen for use within the codebase MUST be listed in the documentation with a link to where it is available.  
Any non-open standards chosen for use within the codebase MUST NOT hinder collaboration and reuse.  
If no existing open standard is available, effort SHOULD be put into developing one.  
Standards that are machine testable SHOULD be preferred over those that are not.  
+ +

Use continuous integration

+ +

☐ criterion met.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Requirementmeets links and notes 
All functionality in the source code MUST have automated tests.  
Contributions MUST pass all automated tests before they are admitted into the codebase.  
The codebase MUST have guidelines explaining how to structure contributions.  
The codebase MUST have active contributors.  
The codebase guidelines SHOULD state that each contribution should focus on a single issue.  
Source code test and documentation coverage SHOULD be monitored.  
Testing policy and documentation for consistency with the source and vice versa is OPTIONAL.  
Testing policy and documentation for style and broken links is OPTIONAL.  
+ +

Publish with an open license

+ +

☐ criterion met.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Requirementmeets links and notes 
All code and documentation MUST be licensed such that it may be freely reusable, changeable and redistributable.  
Software source code MUST be licensed under an OSI-approved or FSF Free/Libre license.  
All code MUST be published with a license file.  
Contributors MUST NOT be required to transfer copyright of their contributions to the codebase.  
All source code files in the codebase SHOULD include a copyright notice and a license header that are machine-readable.  
Having multiple licenses for different types of code and documentation is OPTIONAL.  
+ +

Make the codebase findable

+ +

☐ criterion met.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Requirementmeets links and notes 
The codebase MUST be findable using a search engine by describing the problem it solves in natural language.  
The codebase MUST be findable using a search engine by codebase name.  
Maintainers SHOULD submit the codebase to relevant software catalogs.  
The codebase SHOULD have a website which describes the problem the codebase solves using the preferred jargon of different potential users of the codebase (including technologists, policy experts and managers).  
The codebase SHOULD have a unique and persistent identifier where the entry mentions the major contributors, repository location and website.  
The codebase SHOULD include a machine-readable metadata description, for example in a publiccode.yml file.  
A dedicated domain name for the codebase is OPTIONAL.  
Regular presentations at conferences by the community are OPTIONAL.  
+ +

Use a coherent style

+ +

☐ criterion met.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Requirementmeets links and notes 
Contributions MUST adhere to either a coding or writing style guide, either the codebase community’s own or an existing one that is advertised in or part of the codebase.  
Contributions SHOULD pass automated tests on style.  
The codebase SHOULD include inline comments and documentation for non-trivial sections.  
Including sections on understandable English in the style guide is OPTIONAL.  
+ +

Document codebase maturity

+ +

☐ criterion met.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Requirementmeets links and notes 
The codebase MUST be versioned.  
The codebase that is ready to use MUST only depend on other codebases that are also ready to use.  
The codebase that is not yet ready to use MUST have one of the labels: prototype, alpha, beta or pre-release version.  
The codebase SHOULD contain a log of changes from version to version, for example in the CHANGELOG.  
+ + +
+ + diff --git a/_site/print.html b/_site/print.html new file mode 100644 index 00000000..d2c6fde6 --- /dev/null +++ b/_site/print.html @@ -0,0 +1,2529 @@ + + + + + + + + + + Standard for Public Code + + + + +
+

Request for contributions

+

Standard for Public Code

+ +
    + What public code is and how to implement it for: +
  • Policy makers
    • +
  • Management
    • +
  • Developers and designers
    • +
+ + hands shaking + +

Draft
Version 0.4.0

+

Licensed CC0 Digital Public Goods approval badge

+

github.com/publiccodenet/standard

+
+ +
+ +

Authors

+ + + + +
    +
  • Alba Roza, The Foundation for Public Code
    • +
  • Arnout Engelen
    • +
  • Arnout Schuijff, The Foundation for Public Code
    • +
  • Audrey Tang, digitalminister.tw
    • +
  • Ben Cerveny, The Foundation for Public Code
    • +
  • Bert Spaan
    • +
  • Boris van Hoytema, The Foundation for Public Code
    • +
  • Charlotte Heikendorf
    • +
  • Claus Mullie, The Foundation for Public Code
    • +
  • David Barberi
    • +
  • Edo Plantinga, Code For NL
    • +
  • Elena Findley-de Regt, The Foundation for Public Code
    • +
  • Eric Herman, The Foundation for Public Code
    • +
  • Felix Faassen, The Foundation for Public Code
    • +
  • Floris Deerenberg
    • +
  • Jan Ainali, The Foundation for Public Code
    • +
  • Johan Groenen, Code For NL
    • +
  • Marcus Klaas de Vries
    • +
  • Mark van der Net, Gemeente Amsterdam
    • +
  • Martijn de Waal, Amsterdam University of Applied Sciences (AUAS), Faculty of Digital Media and Creative Industries, Lectorate of Play & Civic Media
    • +
  • Mauko Quiroga
    • +
  • Maurice Hendriks, Gemeente Amsterdam
    • +
  • Maurits van der Schee, Gemeente Amsterdam
    • +
  • Mirjam van Tiel, The Foundation for Public Code
    • +
  • Ngô Ngọc Đức Huy
    • +
  • Paul Keller
    • +
  • Petteri Kivimäki, Nordic Institute for Interoperability Solutions (NIIS)
    • +
  • Sky Bristol
    • +
  • Tamas Erkelens, Gemeente Amsterdam
    • +
  • Timo Slinger
    • +
+ + +
+ +
+ +

Table of Contents

+ +
    +
  1. Authors
    2. +
  2. Introduction
    3. +
  3. Readers guide
    4. +
  4. Glossary
    5. +
  5. Criteria + +
      + + + +
    1. 原始碼要開放
      2. + +
    2. 政策與原始碼要合捆
      3. + +
    3. 程式碼要可重複使用且可攜
      4. + +
    4. 歡迎貢獻者
      5. + +
    5. 貢獻要容易
      6. + +
    6. 維護版本控制
      7. + +
    7. 要求審查貢獻內容
      8. + +
    8. 代碼庫有目標文件
      9. + +
    9. 程式碼有文件
      10. + +
    10. 使用白話的英語
      11. + +
    11. 採用開放標準
      12. + +
    12. 使用持續整合
      13. + +
    13. 發行採用開放授權
      14. + +
    14. 代碼庫可查詢得到
      15. + +
    15. 風格要前後一致
      16. + +
    16. 紀錄代碼庫成熟度
      17. + +
    +
    6. +
  6. Contributing guide
    7. +
  7. Code of conduct
    8. +
  8. Governance
    9. +
  9. Version history
    10. +
  10. License
    11. +
  11. Contact
    12. +
+ +
+ +
+ codebase +
+ +
+ +

Introduction

+ + + + +

The Standard for Public Code is a set of criteria that supports public organizations in developing and maintaining software and policy together.

+ +

Anyone developing software or policy for a public purpose can use this standard to work towards higher quality public services that are more cost effective, with less risk and more control.

+ +

This introduction introduces the term public code, explains why this is important, and introduces the process through which software and policy code can become certified public code.

+ +

Definition of public code

+ +

Public code is both computer source code (such as software and algorithms) and public policy executed in a public context, by humans or machines. +It encompasses the software built to operate with and as public infrastructure, along with the arrangements for its production. +Public code is explicitly distinct from regular software because it operates under fundamentally different circumstances and expectations.

+ +

Reasons for public code

+ +

There are many reasons for why public code is relevant now.

+ +

Software code == legal code

+ +

Software is public infrastructure.

+ +

In the 21st century, software can be considered vital public infrastructure. It is increasingly not just the expression of existing policy but the originator of new policy, for example where algorithms decide which districts need extra social services or policing.

+ +

Software mechanics, algorithms and data collection have become key elements in the execution of public policies. Computer code now executes policies that have been codified in legal code through democratic procedures. Both forms of code set conditions for society to function according to democratically set public values, the latter executed by humans, the former by machines. In other words, software code has increasingly started to equal legal code.

+ +

Software should therefore be subject to the principles of democratic governance.

+ +

Traditional public software procurement

+ +

Current public software production methods have not served public service delivery very well.

+ +

In the last decade, public organizations that purchased complete software solutions have sometimes been surprised to discover that they:

+ +
    +
  • can’t change their software to reflect changing policy or take advantage of new technology
    • +
  • don’t have access to their data as it’s locked into proprietary systems
    • +
  • are asked to pay ever increasing license fees
    • +
+ +

Technological sovereignty and democratic accountability

+ +

Public institutions, civil servants and residents deserve better.

+ +

We believe the software that runs our society can no longer be a black box, controlled by outside companies that keep the underlying logic on which their software operates hidden in proprietary codebases. Instead, governments and the people they serve need technological sovereignty. This allows them to set and control the functioning of public software, just like they are able to set and control policy that is legally formulated in laws. Citizens and civil society actors need this software to be transparent and accountable.

+ +

The design of software as essential civic infrastructure should honor digital citizens’ rights.

+ +

Designing truly public software

+ +

Public code is at the core of modern public institutions, shapes the work of civil servants and affects the lives of almost all residents.

+ +

Public software must therefore be:

+ +
    +
  • transparent
    • +
  • accountable
    • +
  • understandable for its constituents
    • +
+ +

It must reflect the values of the society it serves, for example by being inclusive and non-discriminatory.

+ +

Most proprietary software systems currently used by public organizations do not meet these requirements. Public code does.

+ +

Values of public code

+ +

We consider public code to have these core values:

+ +
    +
  • Inclusive
    • +
  • Usable
    • +
  • Open
    • +
  • Legible
    • +
  • Accountable
    • +
  • Accessible
    • +
  • Sustainable
    • +
+ +

How public code works

+ +

Public code is open source software meant for fulfilling the essential role of public organizations. Through use, other administrations contribute back to the software, so that its development and maintenance become truly collaborative.

+ +

Being open unlocks many other things.

+ +

Local responsibility and democratic accountability are ensured when a public organization implements and maintains their own public code. By being open and with a broader contributor base, the software is more secure as it benefits from many eyes spotting potential flaws. Many contributors share the maintenance work to keep it functional and modern, which reduces future technical debt. The shared workload is more sustainable now and in the future. Its openness makes the code and its data more easily adaptable in the future. The code will be easier to retool, repurpose or retire. This all results in lower risk public infrastructure.

+ +

This pooling of resources lets public administrations give extra attention to how to customize the software so it works best in each local context, creating better user experiences for their end users (residents or citizens).

+ +

Economics of public code

+ +

Public code offers a better economic model for public organizations as well as for commercial companies. It’s an alternative to traditional software procurement which increases local control and economic opportunity.

+ +

Designed from the start to be open, adaptable and with data portability, it can be developed by in-house staff or trusted vendors. Because the code is open, the public administration can change vendors if they need to. Open code increases opportunities for public learning and scrutiny, allowing the public administration to procure smaller contracts. Smaller procurements are easier for local small and medium enterprises to bid upon. Public administrations can use their own software purchasing to stimulate innovation and competition in their local economy.

+ +

This can be seen as investment leading to future economic growth. More vendors will be necessary due to growing technology demand.

+ +

Procuring public code

+ +

Public code can be used and developed by permanent in-house development teams, contractors or outsourced suppliers. Vendors to public organizations can include public code in their bids for contracts.

+ +

To use existing public code, you need to specify in your budget and project design that your new solution will use that codebase. To encourage an innovative approach to adapting the public code to your context, you could describe the service or outcome in your contract.

+ +

Standard compliance or certification process

+ +

The Foundation for Public Code ensures that codebases under its stewardship (and not in incubation or the attic) are compliant with the Standard for Public Code. This makes clear to potential users and contributors that the codebase is of high quality, and updates will be too.

+ +

The audit performed by the Foundation for Public Code is meant to complement machine testing, as machines are great at testing things like syntax and whether outcomes align with expectations. Things meant for humans, such as testing whether documentation is actually understandable and accessible in context, the commit messages make sense, and whether community guidelines are being followed are impossible for machines to test.

+ +

The audit tests the entire codebase, including source code, policy, documentation and conversation for compliance with both the standards set out by the Foundation for Public Code and the standards set out in the codebase itself.

+ +

How the process works

+ +

Every time a contribution is suggested to a codebase, through for instance a merge request, the codebase stewards of the Foundation for Public Code will audit the contribution for compliance with the Standard for Public Code. New contributions can only be adopted into the codebase after they have been approved as compliant with the Standard for Public Code, and have been reviewed by another contributor.

+ +

The audit is presented as a review of the contribution. The codebase steward gives line by line feedback and compliance, helping the contributor to improve their contribution. The merge request cannot be fulfilled until the codebase stewards have approved the contribution.

+ +

Pull Request Acceptance process

+ +

Certifying an entire codebase versus a contribution

+ +

For the codebase to be completely certified every meaningful line of code, and the commits behind the code, need to meet the Standard.

+ +

If codebases have been completely audited from the first merge request they can be immediately certified as compliant with the Standard for Public Code.

+ +

If the audit process is added to an existing codebase, the new merge requests can be certified, but the existing code cannot be certified. By auditing every new merge request the codebase can move incrementally towards being completely certified.

+ +

The goals for the Standard for Public Code

+ +

This Standard supports developers, designers, business management and policy makers to:

+ +
    +
  • develop high quality software and policy for better public service delivery
    • +
  • develop codebases that can be reused across contexts and collaboratively maintained
    • +
  • reduce technical debt and project failure rate
    • +
  • have more granular control over, and ability to make decisions about, their IT systems
    • +
  • improve vendor relationships with a better economic model
    • +
+ +

The Foundation for Public Code helps public organizations share and adopt open source software, build sustainable developer communities and create a thriving ecosystem for public code. It does this through codebase stewardship. For this process the codebase stewards use the Standard for Public Code to make sure the code it stewards is high quality as well as collaboratively maintainable.

+ +

Potential users of codebases tested against the Standard for Public Code can expect them to be highly reusable, easily maintainable and of high quality.

+ +

The Standard for Public Code does this by:

+ +
    +
  • setting out a common terminology for public code development
    • +
  • establishing measures to help develop high quality public code
    • +
  • providing guidance on how to fulfill its criteria and operationalize compliance
    • +
+ +

The Standard for Public Code is meant to be time and technology independent.

+ +

Who this is for

+ +

The Standard for Public Code is for the people who create and reuse public code:

+ +
    +
  • policy makers
    • +
  • business and project management
    • +
  • developers and designers
    • +
+ +

These people work at:

+ +
    +
  • institutions, organizations and administrations in the public sector
    • +
  • consultancies and vendors of information technology and policy services to public organizations
    • +
+ +

It is not aimed at public organizations’ end users (residents or citizens), journalists or academics.

+ +

Further reading

+ + + +

Videos on public code

+ + + +

Get involved

+ +

This standard is a living document. Read our contributor guide to learn how you can make it better.

+ + +
+ +
+ +

Readers guide

+ + + + +

The Standard describes a number of criteria. +All criteria have consistent sections that make it clear how to create great public code.

+ +

References to “policy makers”, “management”, and “developers and designers” apply to anyone performing duties associated with these roles, regardless of their job title. +It is common for individuals to have duties which span multiple roles.

+ +

Below is a brief explanation of each of these sections and how they are used within the criteria of the Standard.

+ +

Requirements

+ +

This section lists what needs to be done in order to comply with the standard.

+ +

In order to limit ambiguity, the key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL +NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in IETF RFC 2119.

+ +

Why this is important

+ +

This section explains why it is important for the users and contributors of this codebase that these requirements are followed.

+ +

What this does not do

+ +

This section manages expectations by explaining what following the requirements will not save you from.

+ +

This helps:

+ +
    +
  • with applying the Standard correctly
    • +
  • make sure no unexpected things pop up
    • +
+ +

How to test

+ +

This section offers actions you can take to see if a contribution is compliant with the Standard. This is key if you want to operationalize the Standard.

+ +

We’ve tried to word it so that someone who is not intimately acquainted with the subject matter can still do a basic check for compliance.

+ +

Policy makers: what you need to do

+ +

This section tries to specifically speak to policy makers by offering them concrete actions they can perform in their role.

+ +

Policy makers set the priorities and goals of projects and may be less technologically experienced.

+ +

Management: what you need to do

+ +

This section tries to specifically speak to management by offering concrete actions they can perform in their role.

+ +

Management is responsible for on-time project delivery, stakeholder management and continued delivery of the service. For this they are wholly reliant on both policy makers as well as developers and designers. They need to create the right culture, line up the right resources and provide the right structures to deliver great services.

+ +

Developers and designers: what you need to do

+ +

This section tries to specifically speak to developers and designers by offering them concrete actions they can perform in their role.

+ +

Developers are usually more technically aligned and have more impact on the delivery of services than the previous groups.

+ + +
+ +
+ +

Glossary

+ + + + +

Code

+ +

Any explicitly described system of rules. This includes laws, policy and ordinances, as well as source code that is used to build software. Both of these are rules, some executed by humans and others by machines.

+ +

Codebase

+ +

Any discrete package of code (both source and policy), the tests and the documentation required to implement a piece of policy or software.

+ +

This can be, for example, a document or a version-control repository.

+ +

Continuous integration

+ +

In software engineering, continuous integration (CI) is the practice of merging all developers’ working copies to a development branch of a codebase as frequently as reasonable.

+ +

Different contexts

+ +

Two contexts are different if they are different public organizations or different departments for which there is not one decision maker that could make collaboration happen naturally.

+ +

General public

+ +

The public at large: end users of the code and the services based upon it.

+ +

For example, a city’s residents are considered end users of a city’s services and of all code that powers these services.

+ +

Open source

+ +

Open source is defined by the Open Source Initiative in their Open Source Definition.

+ +

Open standard

+ +

An open standard is any standard that meets the Open Source Initiative’s Open Standard Requirements.

+ +

Policy

+ +

A policy is a deliberate system of principles to guide decisions and achieve rational outcomes. +A policy is a statement of intent, and is implemented as a procedure or protocol. +Policies are generally adopted by a governance body within an organization. +Policies can assist in both subjective and objective decision making.

+ +

Public policy is the process by which governments translate their political vision into programs and actions to deliver outcomes.

+ +

At the national level, policy and legislation (the law) are usually separate. The distinction is often more blurred in local government.

+ +

In the Standard the word ‘policy’ refers to policy created and adopted by public organizations such as governments and municipalities.

+ +

Public code

+ +

Public code is open source software developed by public organizations, together with the policy and guidance needed for collaboration and reuse.

+ +

Public code is both computer source code (such as software and algorithms) and public policy executed in a public context, by humans or machines.

+ +

Public code serves the public interest, is open, legible, accountable, accessible and sustainable.

+ +

By developing public code independently from but still implementable in the local context for which it was developed, as well as documenting the development process openly, public code can provide a building block for others to:

+ +
    +
  • re-implement in their local context
    • +
  • take as a starting point to continue development
    • +
  • use as a basis for learning
    • +
+ +

To facilitate reuse, public code is either released into the public domain or licensed with an open license that permits others to view and reuse the work freely and to produce derivative works.

+ +

Repository

+ +

A repository is a storage location used by version control tools for files and metadata of a codebase. +Repositories allow multiple developers to work on the same set of files. +Repositories are able to store multiple versions of sets of files.

+ +

Version control

+ +

Version control is the management of changes to source code and the files associated with it. +Changes are usually identified by a code, termed the revision number (or similar). +Each revision is associated with the time it was made and the person making the change, thus making it easier to retrace the evolution of the code. +Revision control systems can be used to compare different versions with each other and to see how content has changed over time.

+ + +
+ + + +
+ unlock +
+ + + + + +
+

原始碼要開放

+ + + + +

需求規範

+ +
    +
  • 任何使用中的政策所有原始碼都必須要公開（用於偵測詐欺的原始碼除外），且能供民眾取用。
    • +
  • 任何使用中軟體的所有原始碼都必須要公開（用於偵測詐欺的原始碼除外），且能供民眾取用。
    • +
  • 貢獻者不得上傳與使用者及其組織單位，或與第三方相關的敏感性資訊到儲存庫中。
    • +
  • 目前非使用中的任何原始碼（像是新版本、提案版本，或較舊版本）都應該公開。
    • +
  • 可選擇是否要以文件記錄一般大眾與組織單位之間可能發生的任何特定互動，其背後所採用的原始碼或支持的政策。
    • +
+ +

此措施為何重要

+ +

以開放精神編寫原始碼能：

+ +
    +
  • 改善資訊透明
    • +
  • 提高程式碼品質
    • +
  • 促進稽核流程
    • +
+ +

這些面向讓公民更有機會能瞭解，軟體與政策如何影響他們與公共組織的互動。

+ +

此措施辦不到的事

+ +
    +
  • 讓原始碼或政策可以重複使用。
    • +
  • 讓盡可能越多人能讀懂代碼庫以及當中的程式碼。
    • +
+ +

測試方式

+ +
    +
  • 確認目前使用中的每個版本都有公布原始碼在網際網路上，而且民眾不需要經過任何形式的身分核對或授權，就能在原始貢獻組織之外，查看這些原始碼。
    • +
  • 確認代碼庫檔案與提交歷史紀錄不包含敏感性資訊。
    • +
  • 檢查目前非使用中的原始碼是否有公開。
    • +
+ +

政策制定者：需要的工作

+ +
    +
  • 制定合乎開放精神的政策。
    • +
  • 以公開透明的政策為優先。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 孕育擁抱開放、重視學習、歡迎意見回饋的文化。
    • +
  • 與外部供應商和自由工作者以開放精神的方式協作。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 審查人員在檢核每次的程式碼提交紀錄時，要確實核對內容沒有包含組態設定、使用者名稱或密碼、公開金鑰，或其他產品系統中使用的實名憑證等敏感性資訊。
    • +
  • 為符合上述敏感性資訊的相關規定，請明確分開資料與程式碼。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

政策與原始碼要合捆

+ + + + +

需求規範

+ +
    +
  • 代碼庫必須包含原始碼所根據的政策。
    • +
  • 代碼庫必須包含根據政策而來的所有原始碼，用於偵測詐騙的原始碼則可除外。
    • +
  • 政策應該採用機器可讀且明確的格式。
    • +
  • 持續整合測試應該驗證原始碼與政策能一致執行。
    • +
+ +

此措施為何重要

+ +

如果要瞭解、重複利用程式碼，還有在代碼庫中互相協作，就必須要能同時取用原始碼與政策文件。瞭解使用情境與該情境的政策是基本原則，才能瞭解代碼庫試圖想解決的問題，以及程式碼解決這些問題的出發點。如果想評估是否能在新的情境中採用該代碼庫，則組織單位需要瞭解必須做出改變的程序有哪些，或是如何對現有解決方案付出額外調整設定，以適應新的情境。

+ +

此措施辦不到的事

+ +
    +
  • 保證代碼庫能反映合捆的政策。
    • +
  • 確保成套合捆內容符合地方性技術基礎建設，或是特定公共組織的法律架構。
    • +
+ +

測試方式

+ +
    +
  • 與公務人員確認程式碼根據的所有政策內容都有包含在內。
    • +
  • 與公務人員確認根據政策而來的所有原始碼都有包含在內。
    • +
  • 確認政策內容是否能在機器上解讀。
    • +
  • 確認原始碼與政策間的執行一致性能通過持續整合測試。
    • +
+ +

政策制定者：需要的工作

+ +
    +
  • 與開發人員及設計師合作，確保政策法規與原始碼之間沒有不相符之處。
    • +
  • 提供相關政策內文，以便收錄於儲存庫中；如果政策內文沒有英文版，請提供英文版摘要。務必也同時包含貴組織單位所選擇遵守的各項標準，以及影響貴組織單位代碼庫開發或部署情境的任何組織流程。
    • +
  • 請提供政策相關參考資料與連結。
    • +
  • 政策內容請使用明確且機器可讀的格式，像是業務流程模型與標記法、 +決策模型與標記法，以及 +案例管理模型標記法。
    • +
  • 追蹤政策時，請使用與追蹤原始碼相同的版本控制與文件。
    • +
  • 定期檢查代碼庫中非政策程式碼的變動，以及確認是否仍符合政策意圖。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 讓政策制定者、開發人員與設計師持續參與，並且在整個開發過程中保持聯繫溝通。
    • +
  • 確保政策制定者、開發人員與設計師朝相同目標努力。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 熟悉並且學會貴組織單位政策制定者所使用的流程模型標記法。
    • +
  • 與政策制定者一同合作，確保政策法規與原始碼之間沒有不相符之處。
    • +
  • 針對如何讓政策文字更清楚提供意見。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

程式碼要可重複使用且可攜

+ + + + +

需求規範

+ +
    +
  • 代碼庫必須開發成能在不同情境中重複使用。
    • +
  • 執行與瞭解代碼庫時，不得仰賴於任何採用保密、無法揭露、專有或非開放式授權的程式碼或服務。
    • +
  • 代碼庫應該有多方單位使用。
    • +
  • 發展路線圖應該有多方單位的需求影響。
    • +
  • 應該使用組態設定方式以將程式碼調整成能適應各情境的特定需求。
    • +
  • 代碼庫應該能夠在地化。
    • +
  • 程式碼與其文件不應該包含特定情況專用的資訊。
    • +
  • 代碼庫模組應該以使其能夠在其他情境中重複利用的模式撰寫文件。
    • +
+ +

此措施為何重要

+ +
    +
  • 讓其他政策制定者、開發人員與設計師等，能夠重複利用您所開發的內容，以及測試它、改善它，並將改善貢獻回代碼庫中，如此可提高品質、降低維護成本、增強可靠性。
    • +
  • 讓新進人員能更容易瞭解程式碼（因為用途更廣泛通用）。
    • +
  • 由於代碼庫以重複利用為前提籌劃設計，因此要調控代碼庫的目標使命、願景與範圍等也更容易。
    • +
  • 多方使用的代碼庫更可以從能自我運作的社群中獲益。
    • +
  • 任何貢獻者都能測試與貢獻給代碼庫，不需要仰賴任何其他貢獻者或部署底下的特定情況專用基礎架構。
    • +
  • 以文件記錄良好的模組構成代碼庫，能夠改善重複使用與維護的能力。
    • +
  • 以文件清楚記錄用途的模組，更容易在另一種情境中重複利用。
    • +
+ +

此措施辦不到的事

+ +
    +
  • 讓他人重複利用代碼庫。
    • +
  • 建立社群。
    • +
  • 將文件、支援、修正錯誤⋯⋯等責任轉移給其他單位。
    • +
  • 保證模組在任何情境下都足以通用。
    • +
+ +

測試方式

+ +
    +
  • 與另一組織單位角色與您相似的人確認，看他們是否能重複利用代碼庫，以及需要怎麼進行。
    • +
  • 確認代碼庫不需要用到任何專有或非開放式授權的程式碼或服務，就能夠執行。
    • +
  • 檢查是否有多方單位或是有在多種情境下正使用代碼庫。
    • +
  • 檢查代碼庫檔案與提交歷史紀錄中，不包含特定情況專用的資料。
    • +
+ +

政策制定者：需要的工作

+ +
    +
  • 為您的政策撰寫清楚且足夠詳細的文件，讓他人即使不是處於同個原始背景情境也能夠理解。
    • +
  • 確保代碼庫有將貴組織單位列為已知用戶。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 確認利害關係人與業主能夠瞭解，代碼庫是以重複利用為明確目標，因而得以減少程式碼技術債，並讓代碼庫可以永續發展。
    • +
+ +

開發人員與設計師：需要的工作

+ +

原始碼應該設計成：

+ +
    +
  • 能讓其他使用者與組織單位可以重複利用，而不受地方環境影響，
    • +
  • 能解決通用性質問題，而非特定問題，
    • +
  • 以邏輯上具有意義且獨立的模組構成，
    • +
  • 如此讓類似組織單位中要面對近似問題的人，都可以採用這套解決方案（或其中一部份）。
    • +
+ +

確保代碼庫文件中，有說明程式的組建時間與執行時期的依賴項目。如果您的情境需要將程式部署至專有平臺上，或者要用到專有組件，則請確保協作者可以在不用到這兩者的情況下，就能進行開發、使用、測試、部署等。

+ +

在每份提交內容中，審查人員要確認其中不含特定情況專用的資料，像是主機名稱、個人與組織單位資料、代符與密碼等。

+ +

延伸閱讀

+ + + +
+ +
+

歡迎貢獻者

+ + + + +

需求規範

+ +
    +
  • 代碼庫必須允許任何人針對代碼庫提出修改建議。
    • +
  • 代碼庫必須包含貢獻指引，說明歡迎貢獻者貢獻的內容類型，以及貢獻者可如何參與開發，例如以「CONTRIBUTING」檔案說明。
    • +
  • 代碼庫必須以文件記錄代碼庫提交、貢獻內容與社群互動等的治理方式，例如以「GOVERNANCE」檔案來說明。
    • +
  • 代碼庫應該宣布投入其開發與維護工作的參與組織單位。
    • +
  • 代碼庫應該要有可公開取得的發展路線圖。
    • +
  • 代碼庫應該公布代碼庫的活動統計數據。
    • +
  • 可選擇是否為代碼庫加入貢獻者的行為準則。
    • +
+ +

此措施為何重要

+ +
    +
  • 幫助新參與者瞭解並且信任代碼庫社群的領導。
    • +
  • 避免參與者因為無法影響代碼庫的目標與進展，而造成代碼庫社群分裂成分歧的社群。
    • +
  • 幫助使用者在代碼庫間做出選擇。
    • +
+ +

此措施辦不到的事

+ +
    +
  • 保證他人會參與社群。
    • +
  • 保證其他人會重複使用代碼庫。
    • +
+ +

測試方式

+ +
    +
  • 確認可以提交修改建議給代碼庫。
    • +
  • 確認代碼庫有貢獻指引。
    • +
  • 確認代碼庫有清楚解釋治理架構，並包含如何對代碼庫治理施加影響。
    • +
  • 檢查是否有參與的組織單位名單。
    • +
  • 檢查是否有發展路線圖。
    • +
  • 檢查是否有公布活動統計數據。
    • +
  • 檢查是否有行為準則。
    • +
+ +

政策制定者：需要的工作

+ +
    +
  • 為代碼庫加入其他資源的清單，而這些資源可幫助政策專家、非政府組織、學者等，更能瞭解或可重複利用您的政策。
    • +
  • 考慮放入聯絡資訊，讓其他考慮合作的政策制定者能徵詢您的意見。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 確保治理架構文件內容中，有包含目前如何改變治理狀態的流程。
    • +
  • 如果社群對於治理架構應該如何改變有共識，則應該將這些構想宣告為願景寫入文件中。
    • +
  • 確認文件有解釋每個參與組織單位所投入的內容，例如提供代碼庫哪些資源，以及參與的時間長度等。
    • +
  • 支持您經驗豐富的政策制定者、開發人員與設計師，使其盡可能長久參與社群。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 快速回應請求。
    • +
  • 持續告知管理階層，您在支援其他貢獻者時所需要的時間與資源。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

貢獻要容易

+ + + + +

需求規範

+ +
    +
  • 代碼庫必須有個可以公開接受任何人建議的議題追蹤器。
    • +
  • 代碼庫必須說明，如何私下回報安全性問題來達成負責任的揭露。
    • +
  • 文件中必須同時有公開的議題追蹤器連結，以及提交的代碼庫變動的連結，例如記錄在「README」檔案中。
    • +
  • 代碼庫必須要有能與使用者以及開發人員溝通的管道，像是設立電子郵件列表（如郵遞論壇）。
    • +
  • 文件應該說明，如何私下透過封閉的管道通報潛在的安全性與敏感性問題。
    • +
+ +

此措施為何重要

+ +
    +
  • 讓使用者能夠為共享的代碼庫修復問題與新增功能，能讓軟體變得更好、更可靠、功能更豐富。
    • +
  • 讓人們能以協作方式採用共享的數位基礎建設。
    • +
  • 幫助使用者在代碼庫間做出選擇。
    • +
+ +

此措施辦不到的事

+ +
    +
  • 保證其他人會重複使用代碼庫。
    • +
+ +

測試方式

+ +
    +
  • 確認有公開的議題追蹤器。
    • +
  • 確認有說明如何私下通報安全性問題。
    • +
  • 確認代碼庫有公開的議題追蹤器連結，以及已提交的代碼庫變動的連結。
    • +
  • 確認可以使用代碼庫中提到的管道，與其他使用者以及開發人員一同討論該軟體。
    • +
+ +

政策制定者：需要的工作

+ +
    +
  • 追蹤代碼庫中的政策問題，讓相關的外部政策專家如果自願也能夠協助。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 追蹤代碼庫中的管理問題，讓有相關經驗的外部管理人員如果自願也能夠協助。
    • +
  • 支持您經驗豐富的政策制定者、開發人員與設計師，使其盡可能為代碼庫持續做出長久貢獻。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 快速回應請求。
    • +
  • 持續告知管理階層，您在支援其他貢獻者時所需要的時間與資源。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

維護版本控制

+ + + + +

需求規範

+ +
    +
  • 社群必須要有方法為程式碼維護版本控制。
    • +
  • 代碼庫中的所有檔案皆必須有版本控制。
    • +
  • 所有決定皆必須記錄成提交訊息。
    • +
  • 每份提交訊息皆必須盡可能附上討論與議題連結。
    • +
  • 代碼庫應該以分散式版本控制系統作維護。
    • +
  • 貢獻者應該將相關的修改變動提交內容作群組分類。
    • +
  • 維護人員應該使用像是修訂版次標記，或文字標籤，來標示代碼庫正式發行的版本。
    • +
  • 貢獻者應該偏好使用能在版本控制系統中，輕鬆檢視與瞭解檔案中何處有做出更動的檔案格式。
    • +
  • 貢獻者可選擇是否在提交內容中簽章，並附上電子郵件信箱，以便當未來貢獻者對其內容有疑問時，可以與之前的貢獻者聯絡。
    • +
+ +

此措施為何重要

+ +

版本控制代表追蹤程式碼歷來的變動。這能讓您為代碼庫製作有條理的變動歷史文件。這是大規模協作能運作的要素。

+ +

分散式版本控制能讓您：

+ +
    +
  • 擁有完整的程式碼副本與其版本歷史
    • +
  • 在需要時可以將代碼庫恢復至先前版本
    • +
  • 紀錄變動與變動的原因，可幫助未來開發人員瞭解整個過程
    • +
  • 比較兩個不同版本
    • +
  • 在將修改內容合併回代碼庫之前，各團隊可以針對修改變動平行作業
    • +
  • 在沒有網路時也能繼續作業，可以日後再將修改變動合併回代碼庫與其他人整合
    • +
+ +

此措施辦不到的事

+ +
    +
  • 代替成熟度宣告。
    • +
  • 保證程式碼能正確執行。
    • +
  • 保證有人加入協作。
    • +
+ +

測試方式

+ +
    +
  • 確認代碼庫維持在版本控制狀態中，像是使用 Git 之類的軟體。
    • +
  • 審查提交內容歷史紀錄，確認所有的提交訊息皆有解釋之前程式碼修改變動的原因。
    • +
  • 審查提交內容歷史紀錄，確認所有提交訊息之中，盡可能在所有討論過修改變更的地方，包含變動內容以及連結位置（提供網址）。
    • +
  • 檢查版本控制系統是否為分散式。
    • +
  • 審查提交內容歷史紀錄，檢查是否有根據貢獻指南將相關的程式碼變動以群組分類。
    • +
  • 檢查是否可能透過像是修訂版次標記，或文字標籤，來存取代碼庫中的特定版本。
    • +
  • 檢查代碼庫在可能的情況下，檔案都是採用文字格式。
    • +
+ +

政策制定者：需要的工作

+ +
    +
  • 如果因為政策改變而在代碼庫中有新的版本，則請確認有在文件中清楚說明： +
      +
    • 政策改變的地方，
      • +
    • 代碼庫如何因應而改變。
      • +
    +
    • +
+ +

舉例來說，在做權限管理賦予取用權的代碼庫中，如果要新增申請方類別，就會視為政策變動。

+ +

管理人員：需要的工作

+ +
    +
  • 支持政策制定者、開發人員與設計師，使其能清楚表達他們對代碼庫做出的改善。確保改善代碼庫不會有公關風險。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 提交內容的訊息要寫清楚，讓人一看就能瞭解提交修改的原因。
    • +
  • 使用像是修訂版次標記，或文字標籤來標示不同版本，以方便存取特定版本。
    • +
  • 提交內容的訊息要寫清楚，方便之後比較各版本。
    • +
  • 在政策改變以後與政策制定者合作，說明原始碼更新的內容。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

要求審查貢獻內容

+ + + + +

需求規範

+ +
    +
  • 所有被接受或是提交給代碼庫正式發行版本中的貢獻內容，都必須經過另一位貢獻者審查。
    • +
  • 審查必須包含原始碼、政策、測試、文件等。
    • +
  • 如果不接受貢獻內容，審查人員必須提供意見回饋。
    • +
  • 貢獻內容應該遵循代碼庫的標準、架構、決策安排等，以通過審查。
    • +
  • 審查內容應該包含執行程式碼與執行代碼庫測試。
    • +
  • 貢獻內容應該由與貢獻者不同背景情境的人來審查。
    • +
  • 版本控制系統不應該在代碼庫的正式發行版本中，接受未經審查的貢獻內容。
    • +
  • 審查應該在兩個工作天內進行。
    • +
  • 可選擇是否由多位審查人員進行審查。
    • +
+ +

此措施為何重要

+ +
    +
  • 提升代碼庫品質。
    • +
  • 降低安全性風險與營運風險。
    • +
  • 打造每份貢獻內容皆能有品質的文化。
    • +
  • 揪出可能發生的極明顯錯誤。
    • +
  • 只有真正能為代碼庫提升價值的貢獻內容才會被接受，可以給予貢獻者安全感。
    • +
  • 向貢獻者保證在一段時間內提供意見回饋或是合作改善。
    • +
  • 快速審查能提高貢獻者交付貢獻內容的頻率以及參與熱度。
    • +
+ +

此措施辦不到的事

+ +
    +
  • 保證能找到問題的合適解決方案。
    • +
  • 代表審查人員必須承擔責任。
    • +
  • 貢獻者能從編寫文件與測試中免除責任。
    • +
  • 提供您合適的審查人選。
    • +
+ +

測試方式

+ +
    +
  • 確認歷史紀錄中每個提交內容都有經過不同的貢獻者審查。
    • +
  • 確認審查內容包含原始碼、政策、測試、文件等。
    • +
  • 針對未被採用的貢獻內容，確認有適當解釋原因。
    • +
  • 檢查審查範圍有涵蓋是否遵循標準、架構、代碼庫指引等。
    • +
  • 檢查審查人員在審查時是否有執行程式碼與測試。
    • +
  • 與審查人員確認，提交的內容是否有經過不同情境背景的不同貢獻者審查。
    • +
  • 檢查版本控制系統中是否有採用分支保護。
    • +
  • 檢查貢獻提交與審查之間的時間間隔。
    • +
+ +

政策制定者：需要的工作

+ +
    +
  • 制定進行任何審查時，含程式碼與其他一切事物，都要恪遵「四眼原則」的政策。
    • +
  • 採用具有審查與意見回饋功能的版本控制系統或作業流程。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 將交付妥善程式碼作為共同目標。
    • +
  • 確保如原始碼、政策、文件、測試等的撰寫與審查貢獻，皆受到同等重視。
    • +
  • 創造歡迎所有形式的貢獻，而且每個人都能夠審查貢獻內容的文化。
    • +
  • 確保貢獻者在貢獻內容給代碼庫時，不是獨自一人埋頭苦幹。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 請代碼庫的其他貢獻者，審查您在貴組織單位內外的工作成果。
    • +
  • 當他人請求您審查程式碼時，請盡快回覆，並先給出程式碼需要修正之處背後的概念。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

代碼庫有目標文件

+ + + + +

需求規範

+ +
    +
  • 代碼庫必須包含描寫目標的文件，像是主旨、使命或目標陳述。開發人員與設計師需要能夠瞭解這些，他們才知道可以怎樣使用代碼庫或協助貢獻。
    • +
  • 代碼庫文件應該清楚描述政策目標與代碼庫目標之前的關聯。
    • +
  • 可選擇是否以文件記錄給一般民眾看的代碼庫目標。
    • +
+ +

此措施為何重要

+ +

以文件記錄代碼庫目標：

+ +
    +
  • 提供簡易方法讓人方便判斷是否在當下或未來，會對此代碼庫或其模組感興趣。
    • +
  • 幫助劃定您自己開發專案的範圍。
    • +
  • 將代碼庫以及所包含模組的目的用途，清楚告知其他利害關係人與貢獻者。
    • +
+ +

此措施辦不到的事

+ +
    +
  • 保證代碼庫能達成其陳述的目標。
    • +
  • 保證會有人為代碼庫做出貢獻。
    • +
  • 預防其他代碼庫試圖達成相同目標。
    • +
+ +

測試方式

+ +
    +
  • 確認代碼庫文件有包含代碼庫目標，或主旨、使命等。
    • +
  • 查看政策目標與代碼庫目標之間關聯的描述。
    • +
+ +

政策制定者：需要的工作

+ +
    +
  • 將政策目標加入代碼庫文件中，例如「README」文件當中。
    • +
  • 納入會影響社會群體、代碼庫與開發目標的相關政策，例如可近用無障礙環境，或機會平等等價值或倫理取向的政策。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 將單位目標、組織目標或業務目標加入代碼庫文件中，例如「README」文件當中。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 將技術與設計目標加入代碼庫文件中，例如「README」文件當中。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

程式碼有文件

+ + + + +

需求規範

+ +
    +
  • 代碼庫的所有功能、政策及原始碼，都必須以可清楚瞭解的用語描述，讓懂 +程式碼目的用途的人也能夠理解。
    • +
  • 代碼庫文件必須說明如何安裝與執行原始碼。
    • +
  • 代碼庫文件必須為關鍵功能舉出範例。
    • +
  • 代碼庫文件應該包含精要的說明，讓一般民眾和記者等廣泛的利害關係人都能清楚明白。
    • +
  • 代碼庫文件應該有一部分用來說明，如何安裝與執行單機版的原始碼；如果有必要，也應該包含測試資料集。
    • +
  • 代碼庫文件應該包含所有功能的範例。
    • +
  • 程式碼文件應該描述代碼庫的主要組件或模組，以及其彼此之間的關係，例如以高層架構圖表示。
    • +
  • 應該要有針對文件品質的持續整合測試。
    • +
  • 可選擇是否在代碼庫文件中，包含讓使用者想要立即使用代碼庫的範例。
    • +
  • 可選擇是否以文件中的範例來測試程式碼。
    • +
+ +

此措施為何重要

+ +
    +
  • 使用者可以更快速上手代碼庫的使用並做出貢獻。
    • +
  • 能幫助他人找到這個代碼庫，特別是那些在問「是不是已經有提供某某功能的程式碼」的人。
    • +
  • 讓貴組織單位與其流程資訊更透明。
    • +
+ +

此措施辦不到的事

+ + + +

測試方式

+ +
    +
  • 確認文件內容能讓其他利害關係人、其他公共組織的專業人士，以及一般民眾，都可以清楚明白。
    • +
  • 確認文件有說明如何安裝與執行原始碼。
    • +
  • 確認文件有包含主要功能的範例。
    • +
  • 向一般民眾的成員以及記者確認，他們是否能明白文件當中的精要說明。
    • +
  • 檢查單機版原始碼的安裝與執行的步驟說明，確認能順利執行系統。
    • +
  • 檢查文件中列舉的所有功能都包含範例。
    • +
  • 檢查文件中是否包含高層架構圖，或類似的組件關係圖表。
    • +
  • 確認整合測試有包含到程式碼文件品質，例如確認由程式碼生成的文件，並檢查連結與圖片等。
    • +
+ +

政策制定者：需要的工作

+ +
    +
  • 定期查看代碼庫的非政策程式碼的變動情況。
    • +
  • 針對如何讓非政策文件更清楚易懂提供意見回饋。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 嘗試使用代碼庫。
    • +
  • 確保您同時瞭解政策、原始碼以及文件內容。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 定期查看代碼庫中非原始碼部分的變動情況。
    • +
  • 針對如何讓非原始碼文件更清楚易懂提供意見回饋。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

使用白話的英語

+ + + + +

需求規範

+ +
    +
  • 代碼庫的所有文件都必須使用英語。
    • +
  • 所有程式碼都必須使用英語編寫，其中政策是由機器解讀當作程式碼的部分則除外。
    • +
  • 任何合捆的政策如果沒有英語版本，則必須隨附英語版摘要。
    • +
  • 任何翻譯版本皆必須跟隨英語版本更新，以維持在最新狀態，反之亦然。
    • +
  • 代碼庫中不應該使用首字母縮字、縮寫、雙關語，或法律/非英語/行業特定詞彙；如果有的話，則需要在這些用語出現之前先行解釋，或是附上解釋該用語的網頁連結。
    • +
  • 代碼庫名稱應該要能描述說明其用途，且不包含任何首字母縮寫字、縮寫、雙關語，或組織單位品牌名稱或抬頭等。
    • +
  • 根據《網頁內容近用性無障礙指南 2》的建議，文件內容應該以國中識讀程度為主。
    • +
  • 可選擇是否提供任何程式碼、文件、測試等的翻譯版。
    • +
+ +

此措施為何重要

+ +
    +
  • 讓不同情境的廣大利害關係人，都能瞭解代碼庫以及其用途。
    • +
  • 讓代碼庫更容易被找到。
    • +
  • 能幫助您達成《歐盟無障礙環境命令》，內容要求大多數的公家機關資訊都要能夠近用以滿足無障礙環境。
    • +
+ +

此措施辦不到的事

+ +
    +
  • 讓代碼庫功能解說更容易瞭解。
    • +
  • 幫助他人在沒有額外解釋之下，就能理解貴組織單位的業內用語。
    • +
+ +

測試方式

+ +
    +
  • 確認代碼庫文件有英語版本。
    • +
  • 確認原始碼為英語，確認任何非英語內容都是政策，或確認術語在其前方有先行說明等。
    • +
  • 確認任何非英語政策都有隨附英語版摘要。
    • +
  • 確認翻譯版與英語版內容相同。
    • +
  • 確認文件當中，沒有任何未說明的首字母縮寫字、縮寫、雙關語，或法律/非英語/行業特定詞彙等。
    • +
  • 檢查文件的拼字、文法與易讀性等。
    • +
+ +

政策制定者：需要的工作

+ +
    +
  • 在過程中經常與其他管理人員、開發人員與設計師測試，確認他們是否瞭解您們正要交付的程式碼與其文件的內容。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 在團隊內部與利害關係人之間的內部溝通中，試著限制首字母縮寫字、縮寫、雙關語，或法律/非英語/行業特定詞彙的使用。如果有使用到的話，則將這些用語加入詞彙表，並且在使用這些詞彙的地方加上詞彙表連結。
    • +
  • 以批判性觀點看待提案與修改當中的文件與描述。如果有您看不懂的內容，很有可能其他人也同樣迷惘。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 經常與政策制定者和管理人員測試，確認他們是否瞭解您們正要交付的程式碼與其文件的內容。
    • +
  • 詢問身處不同背景情境的人（像是另一個代碼庫的開發人員）是否能瞭解內容。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

採用開放標準

+ + + + +

需求規範

+ +
    +
  • 代碼庫如要達成促進資料交換的特性，就必須採用符合開放原始碼促進會其開放標準需求規範的 +開放標準。
    • +
  • 如果有使用到任何的非開放標準，則必須在文件中清楚記錄。
    • +
  • 代碼庫採用的任何標準，皆必須在文件中清楚列出，並且只要有的話，就附上該標準的連結。
    • +
  • 代碼庫採用的任何非開放標準，皆不得妨礙代碼庫的協作與重複使用。
    • +
  • 如果還沒有已存在的開放標準可採用，則應該投入開發新標準。
    • +
  • 採用標準時，應該優先選擇可經機器測試的標準。
    • +
+ +

此措施為何重要

+ +
    +
  • 為不同的系統之間建立互通性。
    • +
  • 降低廠商套牢的可能性。
    • +
  • 保證可以取得重複利用與貢獻代碼庫所需的知識。
    • +
+ +

此措施辦不到的事

+ +
    +
  • 讓軟體的操作方法變得可以瞭解。
    • +
+ +

測試方式

+ +
    +
  • 確認資料交換遵守 OSI 開放原始碼促進會批准的開放標準。
    • +
  • 確認若有採用任何的非開放標準，皆有清楚記錄在文件中。
    • +
  • 確認文件有清單列出代碼庫所採用的標準，其中各標準有對應的有效連結；或沒有採用任何標準時，則留下聲明。
    • +
+ +

政策制定者：需要的工作

+ +
    +
  • 以政策要求盡可能在任何情況下使用開放標準。
    • +
  • 禁止採購不採用開放標準的技術科技。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 考慮在程式碼審查中納入開放標準依循評估。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 將是否依循標準加入持續整合測試中。
    • +
  • 審查提交紀錄與其他儲存庫資源是否有參考開放標準，並交叉檢查其中有列出標準的部分。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

使用持續整合

+ + + + +

需求規範

+ +
    +
  • 原始碼中的所有功能都必須有自動化測試。
    • +
  • 所有貢獻內容都必須先通過自動化測試，才能上傳至代碼庫。
    • +
  • 代碼庫必須有說明貢獻內容結構的相關準則。
    • +
  • 代碼庫必須有活躍貢獻者。
    • +
  • 代碼庫準則應該規定每次做出貢獻時，都應只聚焦在單一議題上。
    • +
  • 應該監督原始碼測試與文件的涵蓋範圍。
    • +
  • 可選擇是否測試政策和文件，與原始碼間有無一致性，或是反之亦然。
    • +
  • 可選擇是否測試政策和文件所採用的樣式，以及連結有無失效。
    • +
+ +

此措施為何重要

+ +
    +
  • 使用持續整合： +
      +
    • 可以讓您快速找出代碼庫的問題所在，
      • +
    • 能在降低貢獻者面臨壓力的同時，允許承擔風險並且專注在解決問題上，
      • +
    • 可降低新貢獻者對整體內容理解的門檻，讓他們更容易提出修改，
      • +
    • 讓程式碼更容易維護，
      • +
    • 能加速開發週期。
      • +
    +
    • +
  • 修改內容較少、時常提出的貢獻，通常較為容易評估，其風險也低於內容龐大、累積很久才一次提出的變更。
    • +
  • 活躍開發中的代碼庫較能提供協作與意見回饋的機會。
    • +
+ +

此措施辦不到的事

+ +
    +
  • 建立能夠順暢作業、可擴展，且能容錯的基礎架構。
    • +
  • 建立有意義的測試。
    • +
  • 測試實際會發生的情境。
    • +
  • 保證交付的程式碼與政策期望的成果確實相同。
    • +
+ +

測試方式

+ +
    +
  • 確認有測試可用。
    • +
  • 確認程式碼覆蓋率工具能檢查到 100% 的程式碼。
    • +
  • 確認貢獻內容只有在通過所有測試後，才會認可上傳至代碼庫。
    • +
  • 確認有貢獻準則說明貢獻內容的結構。
    • +
  • 確認最近三個月內有貢獻內容上傳。
    • +
  • 檢查程式碼覆蓋率數據是否有公布。
    • +
+ +

政策制定者：需要的工作

+ +
    +
  • 儘早讓管理人員、開發人員與設計師一同加入，並且讓他們持續參與您政策的制定程序。
    • +
  • 確保政策文件也有設好自動化測試。
    • +
  • 如果政策文件未能通過測試，請立即修正。
    • +
  • 確保程式碼能反映出政策的任何變動（請參閱維護版本控制）。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 確保能儘快且經常給真正的終端使用者進行測試。
    • +
  • 以頻繁交付少量部分內容的方式做專案規劃，而非久久一次繳交大量部分內容。
    • +
  • 聘請有能力處理漸進式交付並跟上規劃進度的顧問服務。
    • +
  • 發生重大失誤後，鼓勵公開事故報告，以及公開討論事後學到的教訓。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 協助管理階層擬定工作規劃，例如規劃成可以拆分成小部分逐次交付。
    • +
  • 協助貢獻者聚焦其貢獻內容與功能請求，讓涵蓋範圍盡可能合理地縮小。
    • +
  • 協助管理人員與政策制定者測試其貢獻內容，例如測試其貢獻內容中的失效連結或樣式。
    • +
  • 編排程式碼結構時，要將難以在測試環境下創造出來的情況，得以在測試過程中模擬出來。例如硬碟空間不足、記憶體配置失敗等資源耗盡情況，都是難以創造的典型案例。
    • +
  • 調整程式碼覆蓋率測試工具，避免在 inline 過程或其他最佳化處理時得到假警報。
    • +
  • 經常部署。
    • +
  • 至少每天整合工作內容一次。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

發行採用開放授權

+ + + + +

需求規範

+ + + +

此措施為何重要

+ +
    +
  • 讓任何人都可以查看程式碼，並知道他們可以與該如何重複利用這些程式碼。
    • +
+ +

此措施辦不到的事

+ +
    +
  • 預防任何特定行為人使用程式碼。
    • +
+ +

測試方式

+ + + +

政策制定者：需要的工作

+ +
    +
  • 制定要求程式碼必須採用開放原始碼授權的政策。
    • +
  • 制定抑制採購非開放原始碼授權程式碼與非開放科技的政策。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 只與能採用開放原始碼授權交付與發行其程式碼的開放原始碼軟體供應商合作。
    • +
  • 請注意，雖然創用CC授權適合用於文件作品，但其中指明「非商業性」或「禁止改作」的授權條款，代表「無法」自由重複使用、自由修改、自由再次散布等，因此未能符合規定。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 每當建立新的代碼庫時，都要加入新的「license」授權條款檔案。
    • +
  • 每當建立新的原始碼檔案時，都要加入著作權聲明與授權條款標頭內容。
    • +
+ +

延伸閱讀

+ +
    +
  • 開放原始碼促進會所發表的《開放原始碼定義》，所有開放原始碼授權條款皆符合這套定義。
    • +
  • 紐西蘭CC Aotearoa《創用CC介紹動畫影片》。
    • +
  • 歐洲自由軟體基金會所發表的《REUSE 倡議規範》提供規範明確、人類可讀以及機器可讀的著作權與授權資訊。
    • +
  • Linux 基金會所發表的 SPDX 授權條款清單提供經標準化、且機器可讀的大多數授權條款縮寫表示法。
    • +
+ +
+ +
+

代碼庫可查詢得到

+ + + + +

需求規範

+ +
    +
  • 在使用搜尋引擎時，如果以自然語言描述代碼庫所能解決的問題，必須能搜尋得到代碼庫。
    • +
  • 在搜尋引擎查找代碼庫名稱時，必須能搜尋得到代碼庫。
    • +
  • 維護人員應該將代碼庫提交至相關的軟體目錄上。
    • +
  • 代碼庫應該要架設網站，內容中以代碼庫各類潛在使用者（技術人員、政策專家、管理人員等）偏好的業內用語，描述代碼庫所能解決的問題。
    • +
  • 代碼庫應該具備永久唯一識別碼，而且該項條目要提及主要貢獻者、儲存庫、位置、網站等。
    • +
  • 代碼庫應該包含機器可讀的中介資料說明，例如採用 publiccode.yml +格式的檔案。
    • +
  • 可選擇是否為代碼庫設定專用的網域名稱。
    • +
  • 可選擇是否在社群舉辦的會議中定期進行簡報。
    • +
+ +

此措施為何重要

+ +
    +
  • 必須主動積極；不能只是發表個代碼庫，然後就盼望他人找得到這個代碼庫。
    • +
  • 有中介資料說明檔案會讓代碼庫更容易被發現。
    • +
  • 一旦代碼庫越容易被發現，更多的潛在協作者也就找得到它。
    • +
  • 撰寫出良好且包含永久唯一識別碼的中介資料，例如寫成 Wikidata 維基數據條目，或是放到 FSF +自由軟體基金會的軟體目錄列表之中，使代碼庫成為語意網路中的一部份。如此一來，他人就能更容易透過第三方工具參考、引用、辨別、發現代碼庫。
    • +
+ +

此措施辦不到的事

+ +
    +
  • 確認新的協作人員或複製者。
    • +
+ +

測試方式

+ +
    +
  • 確認以白話英語敘述相關問題來作搜尋時，有超過一個的常用主流搜尋引擎，都將代碼庫放在搜尋結果的第一頁中。
    • +
  • 確認以技術性文字敘述相關問題來作搜尋時，有超過一個的常用主流搜尋引擎，都將代碼庫放在搜尋結果的第一頁中。
    • +
  • 確認以代碼庫名稱來作搜尋時，有超過一個的常用主流搜尋引擎，都將代碼庫放在搜尋結果的第一頁中。
    • +
  • 檢查代碼庫有刊登在相關軟體型錄上。
    • +
  • 檢查代碼庫的網站有描述代碼庫能夠解決的問題。
    • +
  • 檢查永久唯一識別碼條目有提及主要貢獻者。
    • +
  • 檢查永久唯一識別碼條目中有包含儲存庫位置。
    • +
  • 檢查永久唯一識別碼條目有列出代碼庫網站。
    • +
  • 檢查中介資料說明檔案是機器可讀的格式。
    • +
+ +

政策制定者：需要的工作

+ +
    +
  • 貢獻一段說明此代碼庫作用的政策領域或處理的問題的描述。
    • +
  • 請對代碼庫不熟悉且不同領域的同儕來測試您的問題描述。
    • +
  • 在相關會議上作簡報介紹代碼庫如何執行政策。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 為團隊編列內容設計與 SEO 搜尋引擎最佳化技能的預算。
    • +
  • 確保專案參與人員出席相關會議或作簡報介紹。
    • +
  • 在決定專案名稱之前，先搜尋過商標資料庫，以避免名稱造成混淆或侵權的問題。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 搜尋引擎最佳化。
    • +
  • 請對代碼庫不熟悉且不同領域的同儕來測試您的問題描述。
    • +
  • 推薦適合出席或作簡報介紹的會議，並且在這些會議中出席或作簡報。
    • +
+ +

延伸閱讀

+ +
    +
  • Wikidata 維基數據社群《維基數據簡介》。
    • +
  • FSF 自由軟體基金會《FSF 軟體目錄列表》。
    • +
  • GO FAIR 國際支援與合作辦公室所撰寫的《FAIR科學資料管理與盡職治理指導原則》，提供一份滿好的特性清單，解說哪些特性會讓資料（或中介資料）更容易讓機器採取行動（也因此更容易被找到）。其中的部分特性可直接套用到代碼庫上，而其他無法直接套用的，我們還需要再研究代碼庫與其對應的特性要怎麼處理。
    • +
+ +
+ +
+

風格要前後一致

+ + + + +

需求規範

+ +
    +
  • 貢獻內容必須遵守程式碼撰寫風格指南、或文件寫作風格指南，可以是代碼庫社群自身的風格指南，或是代碼庫所宣布的或其中部分有採用的既有風格。
    • +
  • 貢獻內容應該通過自動化的風格測試。
    • +
  • 代碼庫當中較複雜的程式碼區段，應該包含列內註解與說明文件。
    • +
  • 可選擇是否將可理解的白話英語小節加入風格指南之中。
    • +
+ +

此措施為何重要

+ +
    +
  • 讓不同環境的貢獻者可以在統合的產品上合作。
    • +
  • 用詞統一能減少貢獻者之間在溝通上的摩擦。
    • +
+ +

此措施辦不到的事

+ +
    +
  • 幫助貢獻者寫好程式碼，或者精確說明他們在做什麼。
    • +
+ +

測試方式

+ +
    +
  • 確認貢獻內容有遵循文件中指定的風格指南。
    • +
  • 檢查是否有自動化的風格測試。
    • +
+ +

政策制定者：需要的工作

+ +
    +
  • 為政策與文件建立風格指南，遵守並且持續改善，同時記錄到代碼庫文件中，像是「CONTRIBUTING」或「 +README」檔案。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 將書面語言、原始碼、測試、政策標準等，包含在貴組織單位對品質的定義當中。
    • +
+ +

開發人員與設計師：需要的工作

+ +

如果代碼庫還沒有工程指南，或其他貢獻者指南，則請先在儲存庫中加入相關文件，像是「 +CONTRIBUTING」或「README」檔案，並描述目前在設立指南方面的進展。上述檔案的重要目的之一，在於宣達設計偏好、命名規則，以及機器不容易檢查的其他層面。指南應該包含貢獻的 +程式碼預期該符合哪些要求，才會被維護人員加入代碼庫中，包含原始碼、測試、文件等項目。請持續改善與擴充這份文件內容，目標讓文件朝向工程指南演進。

+ +

此外：

+ +
    +
  • 使用程式碼品質分析工具 (linter)。
    • +
  • 在代碼庫中加入程式碼品質分析工具的組態設定。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

紀錄代碼庫成熟度

+ + + + +

需求規範

+ +
    +
  • 代碼庫必須註明版本編號。
    • +
  • 準備好可供使用的代碼庫，必須只能依賴其他也已經準備好可供使用的代碼庫。
    • +
  • 尚未準備好使用的代碼庫，必須有所列標籤之一：prototype、alpha、beta、pre-release 等版本進度。
    • +
  • 代碼庫應該包含每次版本的變動紀錄，像是以「CHANGELOG」日誌格式檔記錄。
    • +
+ +

此措施為何重要

+ +

清楚標示代碼庫的成熟度，有助於他人決定是否要重複使用、投資，或為該代碼庫做出貢獻。

+ +

此措施辦不到的事

+ + + +

測試方式

+ +
    +
  • 確認代碼庫有版本編號策略，且有文件記載該策略。
    • +
  • 確認有清楚表明最新版的取得位置。
    • +
  • 確認代碼庫不依賴其他成熟度標示較低的任何代碼庫。
    • +
  • 確認代碼庫是已準備好可供使用，還是仍標示為 prototype、alpha、beta、pre-release 等開發中版本。
    • +
  • 檢查是否有變更紀錄。
    • +
+ +

政策制定者：需要的工作

+ +
    +
  • 制定政策時，請記住任何開發出來的程式碼都必須先經過測試與改善，才能夠投入服務。
    • +
  • 考慮將政策的變動註明版本編號，尤其是因而觸發開發新版本原始碼的情況。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 要確認服務依賴的代碼庫成熟度等同或高於服務本身。舉例來說，正式上線的服務不要使用 beta 公測版代碼庫，公測版服務不要使用 prototype +原型代碼庫。
    • +
  • 若代碼庫尚未準備好供一般使用，請與開發人員一起確保該代碼庫是否有標示適當標籤： +
      +
    • prototype：原型概念，測試外觀與感覺體驗，並且從內部證明技術的可行性概念，
      • +
    • alpha：內部測試，在限制的一群使用者中進行引導性測試，
      • +
    • beta：公開測試，讓更多一般大眾參與測試，例如測試代碼庫在大規模操作下是否仍能運作，
      • +
    • pre-release：準發行版，已經準備好發行，但尚未獲得正式批准的程式碼。
      • +
    +
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 在每個指示程式碼成熟度的介面中加上明顯的標頭。
    • +
  • 所有正式發行的程式碼都要有版本編號。
    • +
  • 特別是在採用「滾動發行」的情況下，程式碼的版本資訊可以根據版本控制系統的中介資料自動衍生（例如使用 +git describe）。
    • +
+ +

延伸閱讀

+ + + +
+ + +
+ +

Contributing to this standard

+ + + + +

🙇‍♀️ Thank you for contributing!

+ +

We understand that a standard like this can only be set in collaboration with as many public technologists, policy makers and interested folk as possible. Thus we appreciate your input, enjoy feedback and welcome improvements to this project and are very open to collaboration.

+ +

We love issues and pull requests from everyone. If you’re not comfortable with GitHub, you can email use your feedback at info@publiccode.net.

+ +

Problems, suggestions and questions in issues

+ +

A high-level overview of the development that we already have sketched out can be seen in the roadmap. +Please help development by reporting problems, suggesting changes and asking questions. +To do this, you can create a GitHub issue for this project in the GitHub Issues for the Standard for Public Code.

+ +

Or, sign up to the mailing list and send an email to +standard@lists.publiccode.net.

+ +

You don’t need to change any of our code or documentation to be a contributor!

+ +

Documentation and code in pull requests

+ +

If you want to add to the documentation or code of one of our projects you should make a pull request.

+ +

If you never used GitHub, get up to speed with Understanding the GitHub flow or follow one of the great free interactive courses in the GitHub learning lab on working with GitHub and working with MarkDown, the syntax this project’s documentation is in.

+ +

This project is licensed Creative Commons Zero v1.0 Universal, which essentially means that the project, along with your contributions is in the public domain in whatever jurisdiction possible, and everyone can do whatever they want with it.

+ +

1. Make your changes

+ +

Contributions should follow the requirements set out in the criteria of the Standard for Public code itself. +Reviewers will also be ensuring that contributions are aligned with the values of public code.

+ +

This project uses the GitFlow branching model and workflow. When you’ve forked this repository, please make sure to create a feature branch following the GitFlow model.

+ +

Add your changes in commits with a message that explains them. +If more than one type of change is needed, group logically related changes into separate commits. +For example, white-space fixes could be a separate commit from text content changes. +Document choices or decisions you make in the commit message, this will enable everyone to be informed of your choices in the future.

+ +

If you are adding code, make sure you’ve added and updated the relevant documentation and tests before you submit your pull request. Make sure to write tests that show the behavior of the newly added or changed code.

+ +

Style

+ +

The Standard for Public Code aims to use plain English and we have chosen American English for spelling. +However, we want to emphasize that it is more important that you make your contribution than worry about spelling and typography. +We will help you get it right in our review process and we also have a separate quality check before making a new release.

+ +

Standards to follow

+ +

These are the standards that the Standard for Public Code uses. +Please make sure that your contributions are aligned with them so that they easier can be merged.

+ + + +

2. Pull request

+ +

When submitting the pull request, please accompany it with a description of the problem you are trying to solve and the issue number that this pull request fixes. +It is preferred for each pull request to address a single issue where possible. +In some cases a single set of changes may address multiple issues, in which case be sure to list all issue numbers fixed.

+ +

3. Improve

+ +

All contributions have to be reviewed by someone.

+ +

It could be that your contribution can be merged immediately by a maintainer. However, usually, a new pull request needs some improvements before it can be merged. Other contributors (or helper robots) might have feedback. If this is the case the reviewing maintainer will help you improve your documentation and code.

+ +

If your documentation and code have passed human review, it is merged.

+ +

4. Celebrate

+ +

Your ideas, documentation and code have become an integral part of this project. You are the open source hero we need!

+ +

In fact, feel free to open a pull request to add your name to the AUTHORS file and get eternal attribution.

+ +

Translations in other languages

+ +

While the Standard does not have any official translations, you can help maintain existing and add new community translations of the Standard.

+ +

Releases

+ +

We have dedicated documentation for creating new releases and ordering printed standards.

+ +

For more information on how to use and contribute to this project, please read the README.

+ + +
+ +
+ collaborative-developement +
+ +
+ +

Code of Conduct

+ + + + +

Many community members are from civic or professional environments with behavioral codes yet some individuals are not. +This document expresses expectations of all community members and all interactions regardless of communication channel.

+ +

Be here to collaborate.

+ +

Be considerate, respectful, and patient.

+ +

Strive to be as constructive as possible.

+ +

To raise a concern, please email directors@publiccode.net.

+ + +
+ +
+ collaboration +
+ +
+ +

Governance

+ + + + +

This standard lies at the core of the codebase stewardship provided by the Foundation for Public Code. We decide if a codebase is ready for community co-development based on this document.

+ +

The standard is maintained by Foundation for Public Code staff.

+ +

We welcome contributions, such as suggestions for changes or general feedback, from anyone.

+ +

Because of the important role that the Standard for Public Code has in our core process we require the highest standards from the Standard.

+ +

We will try to respond promptly to all pull requests. The pull request is an opportunity to work together to improve our methods and the Standard. We may not accept all changes, but we will explain our logic.

+ + +
+ +
+ ecosystem +
+ +
+ +

Version history

+ + + + +

Version 0.4.0

+ +

September 7th 2022: 🔭 the eleventh draft adds a new findability criterion.

+ +
    +
  • Introduce new criterion: Make the codebase findable.
    • +
  • Improve How to test section for most criteria.
    • +
  • New requirement in Welcome contributors about publishing activity statistics.
    • +
  • Removed redundant requirement about portable and reusable code.
    • +
  • Expand open license definition to include both OSI and FSF approved licenses.
    • +
  • Rephrase MAY requirements to use the keyword OPTIONAL for clarity.
    • +
  • Expressed intent that the Standard for Public Code should meet its own requirements where applicable and added assessment.
    • +
  • Add SPDX license identifiers to files.
    • +
  • Introduced new Code of Conduct.
    • +
  • Clarify distinction between source code and policy text.
    • +
  • Restructuring of requirements with bullet point lists.
    • +
  • Acknowledge the importance of codebase modularity for reuse.
    • +
  • Move requirements related to Findability to the new criterion.
    • +
  • Clarify the role of non-open standards when used in a codebase.
    • +
  • Additional guidance about build-time and runtime dependencies.
    • +
  • Added roadmap for the development of the Standard for Public Code.
    • +
  • Update structure of Authors file.
    • +
  • Add Audrey Tang to Authors.
    • +
  • Added a list of criteria to the print edition.
    • +
  • Clarify what the standard means with policymakers, managers, developers and designers.
    • +
  • Made additional minor changes to text for clarity.
    • +
  • Some hyperlinks updated.
    • +
+ +

Version 0.3.0

+ +

May 23rd 2022: 🗎 the tenth draft strengthens documentation and localization.

+ +
    +
  • Requirement for localization made explicit in Create reusable and portable code.
    • +
  • Documentation of governance changed from a SHOULD to a MUST.
    • +
  • Replace the very subjective (and hard to test) “contributions MUST be small” with requirement to document expectation in contributing guidelines and focus on a single issue.
    • +
  • Community translations now linked in the footer.
    • +
  • Revert “Replace BPMN svg with Mermaid flowchart”.
    • +
  • Many minor clarifications to language and sentences made more simple.
    • +
  • Some hyperlinks updated.
    • +
+ +

Version 0.2.3

+ +

March 15th 2022: 📜 the ninth draft allows English summaries for policy lacking an official translation.

+ +
    +
  • Relax the criterion Use plain English by adding a new requirement allows bundled policy not available in English to have an accompanying summary in English instead of translating the full text.
    • +
  • Similarly, allow for English summaries for policies not available in English in Bundle policy and code.
    • +
  • Clarify that term ‘policy’ includes processes which impact development and deployment in Bundle policy and code.
    • +
  • Emphasize reusability also on parts of the solutions in Create reusable and portable code.
    • +
  • Expand guidance to Developers and designers in Create reusable and portable code about deploying to proprietary platforms.
    • +
  • Add nuance to use of non-English terms in what management need to do in Use plain English.
    • +
  • Change the pull request process diagram to use Mermaid instead of BPMN to make community translations easier.
    • +
  • Added Maurice Hendriks to AUTHORS.
    • +
  • Added OpenApi Specification to further reading.
    • +
  • Made the attributions in further reading sections clearer.
    • +
  • Made additional minor changes to text for clarity.
    • +
+ +

Version 0.2.2

+ +

November 29th 2021: 🏛 the eighth draft recognizes that policy which executes as code may not be in English.

+ +
    +
  • Document exception to “All code MUST be in English” where policy is interpreted as code.
    • +
  • Add MAY requirement regarding committer email addresses in Maintain version control.
    • +
  • Expand guidance to Policy Makers in Bundle policy and code.
    • +
  • Expand guidance to Developers and designers in Use a coherent style.
    • +
  • Add “Different contexts” to glossary.
    • +
  • Add Mauko Quiroga and Charlotte Heikendorf to AUTHORS.
    • +
  • Add Digital Public Goods approval badge.
    • +
  • Added “next” and “previous” links to criteria pages of web version.
    • +
  • Add Open Standards principles to further reading.
    • +
  • Add Definition of plain language to further reading.
    • +
  • Move the Semantic Versioning Specification further reading reference.
    • +
  • Clarify that publiccode.yml is one example of a machine-readable metadata description.
    • +
  • Changed “your codebase” and “your organization” to be less possessive.
    • +
  • Made additional minor changes to text for clarity.
    • +
  • Add instructions for creating a print version.
    • +
+ +

Version 0.2.1

+ +

March 1st 2021: 🧽 the seventh draft has minor cleaning up after version 0.2.0.

+ +
    +
  • New SHOULD requirement on using a distributed version control system and why distributed is important.
    • +
  • Feedback requirements for rejected contributions are more strict than accepted ones.
    • +
  • Specify that copyright and license notices should also be machine-readable.
    • +
  • Advice on how to test that notices be machine-readable.
    • +
  • Clarify guidance for rolling releases.
    • +
  • Clear up definition of version control in glossary.
    • +
  • Add further reading encouraging contribution, SPDX, Git and reviewing contributions.
    • +
  • Add links to videos about the concept of public code.
    • +
  • Update BPMN link.
    • +
  • Reduce link duplication.
    • +
  • Add Alba Roza and Ngô Ngọc Đức Huy to authors.
    • +
  • Made additional minor changes to text for clarity.
    • +
+ +

Version 0.2.0

+ +

October 26th 2020: 🎊 the sixth draft splits a requirement and adds clarity.

+ +
    +
  • Split “Welcome contributions” criterion into “Make contributing easy” and “Welcome contributors”.
    • +
  • Rename criterion “Pay attention to codebase maturity” to “Document codebase maturity”.
    • +
  • Changed MUST to SHOULD for requirement of codebase in use by multiple parties.
    • +
  • Add MUST NOT requirement regarding copyright assignment.
    • +
  • Clarify role of configuration in reusable code requirement.
    • +
  • Glossary additions: continuous integration, policy, repository, and version control.
    • +
  • Replace references to ‘cities’ with ‘public organizations’.
    • +
  • Clarify aspects of sensitive code by separating contributor and reviewer requirements into separate items.
    • +
  • Expand further reading, and guidance to policy makers, developers and designers.
    • +
  • Add Felix Faassen and Arnout Engelen to authors.
    • +
  • Made additional minor changes to text for clarity.
    • +
+ +

Version 0.1.4

+ +

November 27th 2019: 🧹 the fifth draft consists mostly of additional minor fixes.

+ +
    +
  • Linked License.md file.
    • +
  • Add Sky Bristol, Marcus Klaas de Vries, and Jan Ainali to authors.
    • +
  • Made punctuation more consistent, especially for bullet lists.
    • +
  • Made some minor changes to text for clarity.
    • +
+ +

Version 0.1.3

+ +

October 8th 2019: 🍂 the fourth draft only patches and fixes minor things for the autumn cleaning

+ +
    +
  • Renamed continuous delivery to continuous integration.
    • +
  • Referencing accessibility guidelines in the language standard.
    • +
  • A bunch of style and consistency fixes.
    • +
+ +

Version 0.1.2

+ +

August 22th 2019: 🌠 the third draft focuses on better text and takes community input

+ +
    +
  • With some great new contributors comes a fresh author list.
    • +
  • All links are now HTTPS.
    • +
  • General proofreading, wording clarifications, and smashed typos.
    • +
  • Updated criteria: +
      +
    • Requirement for reuse in different contexts
      • +
    • Recommendation for explicit versioning
      • +
    • Recommendation for multi party development
      • +
    • Recommendation for license headers in files
      • +
    • Recommendation for vulnerability reporting
      • +
    • Recommendation for explicit documentation of governance
      • +
    +
    • +
+ +

Version 0.1.1

+ +

May 9th 2019: 🤔 the second draft fixes a few basic oversights and fixes a lot of typos

+ +
    +
  • Removed references to the Foundation for Public Code, we’re going to have to change the name in becoming an association.
    • +
  • Updated the introduction.
    • +
  • Updated the glossary.
    • +
  • Added the code of conduct.
    • +
  • We’ve recommended using the publiccode.yml standard for easier reuse.
    • +
+ +

Version 0.1.0

+ +

April 16th 2019: 🎉 the first draft is ready, it is all brand new and has snazzy new ideas in it

+ +
    +
  • 14 criteria with their requirements and how to operationalize them.
    • +
  • An introduction with a high level background, what this standard is, and how the Foundation for Public Code will use it.
    • +
+ +

This first version was produced together with the Amsterdam University of Applied Sciences and the City of Amsterdam as a part of the Smart Cities? Public Code! project.

+ + +
+ +
+ +

This license is the legal contract that allows anyone to do anything they like with the content in this entire document.

+

CC0 1.0 Universal

+ 
Creative Commons Legal Code
+
+CC0 1.0 Universal
+
+    CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE
+    LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN
+    ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS
+    INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES
+    REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS
+    PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM
+    THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED
+    HEREUNDER.
+
+Statement of Purpose
+
+The laws of most jurisdictions throughout the world automatically confer
+exclusive Copyright and Related Rights (defined below) upon the creator
+and subsequent owner(s) (each and all, an "owner") of an original work of
+authorship and/or a database (each, a "Work").
+
+Certain owners wish to permanently relinquish those rights to a Work for
+the purpose of contributing to a commons of creative, cultural and
+scientific works ("Commons") that the public can reliably and without fear
+of later claims of infringement build upon, modify, incorporate in other
+works, reuse and redistribute as freely as possible in any form whatsoever
+and for any purposes, including without limitation commercial purposes.
+These owners may contribute to the Commons to promote the ideal of a free
+culture and the further production of creative, cultural and scientific
+works, or to gain reputation or greater distribution for their Work in
+part through the use and efforts of others.
+
+For these and/or other purposes and motivations, and without any
+expectation of additional consideration or compensation, the person
+associating CC0 with a Work (the "Affirmer"), to the extent that he or she
+is an owner of Copyright and Related Rights in the Work, voluntarily
+elects to apply CC0 to the Work and publicly distribute the Work under its
+terms, with knowledge of his or her Copyright and Related Rights in the
+Work and the meaning and intended legal effect of CC0 on those rights.
+
+1. Copyright and Related Rights. A Work made available under CC0 may be
+protected by copyright and related or neighboring rights ("Copyright and
+Related Rights"). Copyright and Related Rights include, but are not
+limited to, the following:
+
+  i. the right to reproduce, adapt, distribute, perform, display,
+     communicate, and translate a Work;
+ ii. moral rights retained by the original author(s) and/or performer(s);
+iii. publicity and privacy rights pertaining to a person's image or
+     likeness depicted in a Work;
+ iv. rights protecting against unfair competition in regards to a Work,
+     subject to the limitations in paragraph 4(a), below;
+  v. rights protecting the extraction, dissemination, use and reuse of data
+     in a Work;
+ vi. database rights (such as those arising under Directive 96/9/EC of the
+     European Parliament and of the Council of 11 March 1996 on the legal
+     protection of databases, and under any national implementation
+     thereof, including any amended or successor version of such
+     directive); and
+vii. other similar, equivalent or corresponding rights throughout the
+     world based on applicable law or treaty, and any national
+     implementations thereof.
+
+2. Waiver. To the greatest extent permitted by, but not in contravention
+of, applicable law, Affirmer hereby overtly, fully, permanently,
+irrevocably and unconditionally waives, abandons, and surrenders all of
+Affirmer's Copyright and Related Rights and associated claims and causes
+of action, whether now known or unknown (including existing as well as
+future claims and causes of action), in the Work (i) in all territories
+worldwide, (ii) for the maximum duration provided by applicable law or
+treaty (including future time extensions), (iii) in any current or future
+medium and for any number of copies, and (iv) for any purpose whatsoever,
+including without limitation commercial, advertising or promotional
+purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each
+member of the public at large and to the detriment of Affirmer's heirs and
+successors, fully intending that such Waiver shall not be subject to
+revocation, rescission, cancellation, termination, or any other legal or
+equitable action to disrupt the quiet enjoyment of the Work by the public
+as contemplated by Affirmer's express Statement of Purpose.
+
+3. Public License Fallback. Should any part of the Waiver for any reason
+be judged legally invalid or ineffective under applicable law, then the
+Waiver shall be preserved to the maximum extent permitted taking into
+account Affirmer's express Statement of Purpose. In addition, to the
+extent the Waiver is so judged Affirmer hereby grants to each affected
+person a royalty-free, non transferable, non sublicensable, non exclusive,
+irrevocable and unconditional license to exercise Affirmer's Copyright and
+Related Rights in the Work (i) in all territories worldwide, (ii) for the
+maximum duration provided by applicable law or treaty (including future
+time extensions), (iii) in any current or future medium and for any number
+of copies, and (iv) for any purpose whatsoever, including without
+limitation commercial, advertising or promotional purposes (the
+"License"). The License shall be deemed effective as of the date CC0 was
+applied by Affirmer to the Work. Should any part of the License for any
+reason be judged legally invalid or ineffective under applicable law, such
+partial invalidity or ineffectiveness shall not invalidate the remainder
+of the License, and in such case Affirmer hereby affirms that he or she
+will not (i) exercise any of his or her remaining Copyright and Related
+Rights in the Work or (ii) assert any associated claims and causes of
+action with respect to the Work, in either case contrary to Affirmer's
+express Statement of Purpose.
+
+4. Limitations and Disclaimers.
+
+ a. No trademark or patent rights held by Affirmer are waived, abandoned,
+    surrendered, licensed or otherwise affected by this document.
+ b. Affirmer offers the Work as-is and makes no representations or
+    warranties of any kind concerning the Work, express, implied,
+    statutory or otherwise, including without limitation warranties of
+    title, merchantability, fitness for a particular purpose, non
+    infringement, or the absence of latent or other defects, accuracy, or
+    the present or absence of errors, whether or not discoverable, all to
+    the greatest extent permissible under applicable law.
+ c. Affirmer disclaims responsibility for clearing rights of other persons
+    that may apply to the Work or any use thereof, including without
+    limitation any person's Copyright and Related Rights in the Work.
+    Further, Affirmer disclaims responsibility for obtaining any necessary
+    consents, permissions or other rights required for any use of the
+    Work.
+ d. Affirmer understands and acknowledges that Creative Commons is not a
+    party to this document and has no duty or obligation with respect to
+    this CC0 or use of the Work.
+
+ +
+ +
+ +

Contact

+ +

For questions and more information about the Foundation for Public Code you can find us at our website, email us at info@publiccode.net, or call us at +31 20 2 444 500

+ +
+ + + diff --git a/_site/publiccode.yml b/_site/publiccode.yml new file mode 100644 index 00000000..7a700c99 --- /dev/null +++ b/_site/publiccode.yml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2022-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +# This repository adheres to the publiccode.yml standard by including this +# metadata file that makes public software easily discoverable. +# More info at https://github.com/italia/publiccode.yml + +publiccodeYmlVersion: '0.2' +categories: + - collaboration + - project-collaboration +description: + en: + features: + - enables collaboration + - enables successful future reuse + - |- + gives public organizations a model for building their own open source + solutions + - |- + gives guidance for policy makers, city administrators, developers and + vendors + genericName: standard + localisedName: Standard for Public Code + longDescription: | + The Standard for Public Code gives public organizations a model for + preparing open source solutions to enable collaborations with similar + public organizations in other places. It includes guidance for policy + makers, city administrators, developers and vendors. + + + The Standard defines ‘public code’ as open source software developed by + public organizations, together with the policy and guidance needed for + collaboration and reuse. + + + The Standard is recognized as a [Digital Public + Good](https://digitalpublicgoods.net/registry/standard-for-public-code.html) + by the [Digital Public Goods Alliance](https://digitalpublicgoods.net/). + shortDescription: |- + It gives public organizations a model for preparing open source solutions + to enable collaborations with similar public organizations in other + places. + videos: + - 'https://www.youtube.com/watch?v=QWt6vB-cipE' +developmentStatus: beta +landingURL: 'https://standard.publiccode.net/' +legal: + authorsFile: 'https://raw.githubusercontent.com/publiccodenet/standard/master/AUTHORS.md' + license: CC0-1.0 + mainCopyrightOwner: Foundation for Public Code + repoOwner: Foundation for Public Code +localisation: + availableLanguages: + - en + localisationReady: false +maintenance: + contacts: + - affiliation: Foundation for Public Code + email: eric@publiccode.net + name: Eric Herman + - affiliation: Foundation for Public Code + email: jan@publiccode.net + name: Jan Ainali + type: internal +name: Standard for Public Code +platforms: + - web +releaseDate: '2023-07-31' +roadmap: 'https://github.com/publiccodenet/standard/blob/develop/docs/roadmap.md' +softwareType: standalone/other +softwareVersion: 0.7.1 +url: 'https://github.com/publiccodenet/standard/' +usedBy: + - Provincie Zuid-Holland diff --git a/_site/python/po2md.py b/_site/python/po2md.py new file mode 100644 index 00000000..3cd0cd10 --- /dev/null +++ b/_site/python/po2md.py @@ -0,0 +1,102 @@ +import os +import shutil +import subprocess + +PROJECT_FOLDER = "./" +SOURCE_FOLDER = "./origin_source" + +def main(): + root_path = "./" + source_path = "./origin_source" + + # 1. get all md file + md_files = find_md_files(PROJECT_FOLDER) + + # 2. filter origin file + md_files = [file for file in md_files if not file.startswith(SOURCE_FOLDER)] + + # 3A. backup md file (只有主程式更新的時候，才需要複製一次) + # backup_md_files(md_files) + + # 3B. restore md file + restore_md_files(md_files) + + # 4. run po2md + for file in md_files: + full_target_path = os.path.join(SOURCE_FOLDER, os.path.relpath(file, PROJECT_FOLDER)) + do_po2md(source_file=full_target_path, target_file=file) + + # 4. update md file + update_md_file(SOURCE_FOLDER) + + + + +def find_md_files(folder_path) -> list: + md_files = [] + for root, dirs, files in os.walk(folder_path): + md_files += [os.path.join(root, file) for file in files if file.endswith('.md')] + return md_files + +# 複製原始檔案 +def backup_md_files(files): + if not os.path.exists(SOURCE_FOLDER): + os.makedirs(SOURCE_FOLDER) + + for file in files: + # 建立目標資料夾的完整路徑 + full_target_path = os.path.join(SOURCE_FOLDER, os.path.relpath(file, PROJECT_FOLDER)) + if not os.path.exists(os.path.dirname(full_target_path)): + os.makedirs(os.path.dirname(full_target_path)) + + # 複製檔案到目標資料夾 + shutil.copy2(file, full_target_path) + +# 還原原始檔案 +def restore_md_files(files): + for file in files: + full_target_path = os.path.join(SOURCE_FOLDER, os.path.relpath(file, PROJECT_FOLDER)) + shutil.copy2(full_target_path, file) + + +def do_po2md(source_file, target_file): + locale_file = "locales/zh_Hant/LC_MESSAGES/messages.po" + cmd = f"po2md -p {locale_file} -s {target_file} {source_file}" + result = subprocess.run(cmd, shell=True, capture_output=True, text=True) + if result.returncode != 0: + print("錯誤訊息：") + print(result.stderr) + exit() + +def update_md_file(source_path): + source_marker = "---" + target_marker = "***" + + source_files = find_md_files(source_path) + for file in source_files: + with open(file, 'r') as infile: + file_content = infile.read() + + start_index = file_content.find(source_marker) + end_index = file_content.find(source_marker, start_index + len(source_marker)) + copied_content = file_content[start_index:end_index + len(source_marker)] + + + with open(file[len(source_path) + 1:], 'r') as infile: + file_content = infile.read() + + start_index = file_content.find(target_marker) + end_index = file_content.find(target_marker, start_index + len(target_marker)) + if end_index == -1: + print(file) + continue + + new_content = copied_content + file_content[end_index + len(target_marker):] + + with open(file[len(source_path) + 1:], 'w') as outfile: + outfile.write(new_content) + + + +if __name__ == '__main__': + main() \ No newline at end of file diff --git a/_site/python/update_po.py b/_site/python/update_po.py new file mode 100644 index 00000000..b8df8924 --- /dev/null +++ b/_site/python/update_po.py @@ -0,0 +1,34 @@ +import os +import shutil +import subprocess +import polib + + +def main(): + locals_en = 'locales/en/LC_MESSAGES/messages.po' + locals_zh = 'locales/zh_Hant/LC_MESSAGES/messages.po' + en_po = polib.pofile(locals_en) + zh_po = polib.pofile(locals_zh) + + zh_msgids = set(entry.msgid for entry in zh_po) + + # 遍歷 en.po 中的每一個 entry + for entry in en_po: + # 如果 en.po 中的 msgid 不在 zh.po 中 + if entry.msgid not in zh_msgids: + # 創建一個新的 POEntry 對象 + new_entry = polib.POEntry( + msgid=entry.msgid, + msgstr='', # 初始為空字符串 + ) + # 將新的 entry 添加到 zh.po 中 + zh_po.append(new_entry) + + # 儲存更新後的 zh.po 檔案 + zh_po.save(locals_zh) + + + + +if __name__ == '__main__': + main() \ No newline at end of file diff --git a/_site/readers-guide.html b/_site/readers-guide.html new file mode 100644 index 00000000..99ba11c0 --- /dev/null +++ b/_site/readers-guide.html @@ -0,0 +1,313 @@ + + + + + + + + + 讀者指引, Standard for Public Code + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ Standard for Public Code +
+ + + +
+ + +
+ +
+ + + + + + + +
+ + + + + + + + + + + + +

目次

+
    +
  1. 前言
    2. +
  2. 需求規定
    3. +
  3. 測試方式
    4. +
  4. 公共政策制定者：需要的工作
    5. +
  5. 管理人員：需要的工作
    6. +
  6. 開發人員與設計師：需要的工作
    7. +
  7. 作用範圍限制
    8. +
+ + + + + + + +

到 GitHub 貢獻

+ + + +
+ + +
+ +
+

讀者指引

+ +

本標準描述說明許多準則。所有準則各小節結構維持一致，來讓讀者清楚明白如何開發良好的公共程式。

+ +

「政策制定者」、「管理人員」以及「開發人員與設計師」的稱呼，係指任何履行這些角色職責的人，不受其職稱限制。常見同時承擔多個角色職責的人。

+ +

以下是各小節的簡要介紹，以及在本標準準則中的作用。

+ +

前言

+ +

本小節說明這些準則想達成的目的，以及為何會對程式基底使用者與貢獻者來說這麼重要的原因。

+ +

需求規定

+ +

這個小節列出如果要遵循本標準，需要完成哪些事項。

+ +

本文件中的下列關鍵字，請以《IETF RFC 2119》的描述作解釋：

+ +
    +
  • 必須
    • +
  • 禁止
    • +
  • 要求
    • +
  • 應當
    • +
  • 不得
    • +
  • 應該
    • +
  • 不該
    • +
  • 建議
    • +
  • 得以
    • +
  • 可選擇
    • +
+ +

測試方式

+ +

本小節提供您可採取的行動，來確認貢獻內容是否遵循本標準。如果您想要務實操作本標準，這部分很關鍵。

+ +

我們已嘗試調整用字，讓即使是不熟悉這類主題內容的讀者，看完之後也能夠進行基本的遵循檢查。

+ +

公共政策制定者：需要的工作

+ +

本小節主要對象是政策制定者，列出他們的角色所能採取的具體行動。

+ +

公共政策制定者設定專案的優先順序與目標，而在科技上的經驗可能沒那麼多。

+ +

管理人員：需要的工作

+ +

本小節主要對象是管理人員，列出他們的角色所能採取的具體行動。

+ +

管理人員負責監督專案的準時交付、利害關係人管理，以及服務的持續交付。因此，他們得完全依賴政策制定者、開發人員與設計師。他們需要塑造正確的文化、籌備合適的資源、提供適 +當的架構等，才能交付優良的服務。

+ +

開發人員與設計師：需要的工作

+ +

本小節主要對象是開發人員與設計師，列出他們的角色能採取的具體行動。

+ +

開發人員通常對技術比較在行，與其他角色類別相比，對服務交付的影響更大。

+ +

作用範圍限制

+ +

《公共程式標準》不是為了涵蓋程式基底的個別實作而撰寫。這代表本標準不是要告訴實作人員，該如何遵循其組織單位當地的技術性基礎建設或法律框架。

+ +

此外，雖然《公共程式標準》有引用一些標準，並且與其他標準有滿多重疊的部分，但本標準的目的是要推動協作。因此，本標準目標不在於取代品質標準，像是 ISO 25000 +認證系列，或是取代那些聚焦於安全性的標準，例如 OpenSSF 最佳實務標 +章等，而是希望能與它們能良好協同搭 +配。

+ +

《公共程式標準》的目在於促進協作，但也無法保證能夠催生出一個社群。若要建立社群，除了程式基底需要準備好進行協作以外，也需要積極主動，以及做到超越協作以外的企圖 +心。

+ +
+
+ + +
+ + +
+ +
+ + + + + +
+

本站在 GitHub 的頁面

+

本站最近一次是在 15 November 2023 根據 publiccodenet/jekyll-theme GitHub 的儲存庫版本發表。

+ +
+ + +
+ +
+ + + + +
+

著作權與授權

+

+ © 2023 + + + 公共程式基金會 + + +

+

+ + + European Union Public License 1.2 + +

+
+ +
+ + + + + + + + + + + + + diff --git a/_site/readers-guide.md b/_site/readers-guide.md new file mode 100644 index 00000000..8a35b0c0 --- /dev/null +++ b/_site/readers-guide.md @@ -0,0 +1,56 @@ +# Readers guide + + + + +The Standard describes a number of criteria. +All criteria have consistent sections that make it clear how to create great public code. + +References to "policy makers", "management", and "developers and designers" apply to anyone performing duties associated with these roles, regardless of their job title. +It is common for individuals to have duties which span multiple roles. + +Below is a brief explanation of each of these sections and how they are used within the criteria of the Standard. + +## Requirements + +This section lists what needs to be done in order to comply with the standard. + +In order to limit ambiguity, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL +NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [IETF RFC 2119](https://tools.ietf.org/html/rfc2119). + +## Why this is important + +This section explains why it is important for the users and contributors of this codebase that these requirements are followed. + +## What this does not do + +This section manages expectations by explaining what following the requirements will not save you from. + +This helps: + +* with applying the Standard correctly +* make sure no unexpected things pop up + +## How to test + +This section offers actions you can take to see if a contribution is compliant with the Standard. This is key if you want to operationalize the Standard. + +We've tried to word it so that someone who is not intimately acquainted with the subject matter can still do a basic check for compliance. + +## Policy makers: what you need to do + +This section tries to specifically speak to policy makers by offering them concrete actions they can perform in their role. + +Policy makers set the priorities and goals of projects and may be less technologically experienced. + +## Management: what you need to do + +This section tries to specifically speak to management by offering concrete actions they can perform in their role. + +Management is responsible for on-time project delivery, stakeholder management and continued delivery of the service. For this they are wholly reliant on both policy makers as well as developers and designers. They need to create the right culture, line up the right resources and provide the right structures to deliver great services. + +## Developers and designers: what you need to do + +This section tries to specifically speak to developers and designers by offering them concrete actions they can perform in their role. + +Developers are usually more technically aligned and have more impact on the delivery of services than the previous groups. diff --git a/_site/redirects.json b/_site/redirects.json new file mode 100644 index 00000000..52eb296a --- /dev/null +++ b/_site/redirects.json @@ -0,0 +1 @@ +{"/license.html":"/CC0-1.0.html","/LICENSE.html":"/CC0-1.0.html","/criteria/bundle-policy-and-code":"/criteria/bundle-policy-and-source-code.html","/criteria/advertise-maturity":"/criteria/document-codebase-maturity.html","/criteria/document-maturity":"/criteria/document-codebase-maturity.html","/criteria/document-objectives":"/criteria/document-codebase-objectives.html","/criteria/documenting":"/criteria/document-the-code.html","/introduction":"/foreword.html","/criteria/version-control-and-history":"/criteria/maintain-version-control.html","/criteria/findability":"/criteria/make-the-codebase-findable.html","/criteria/reusable-and-portable-codebases":"/criteria/make-the-codebase-reusable-and-portable.html","/criteria/create-reusable-and-portable-code":"/criteria/make-the-codebase-reusable-and-portable.html","/criteria/open-licenses":"/criteria/publish-with-an-open-license.html","/criteria/require-review":"/criteria/require-review-of-contributions.html","/criteria/style":"/criteria/use-a-coherent-style.html","/criteria/continuous-integration":"/criteria/use-continuous-integration.html","/criteria/open-standards":"/criteria/use-open-standards.html","/criteria/understandable-english-first":"/criteria/use-plain-english.html","/criteria/open-to-contributions":"/criteria/welcome-contributors.html"} \ No newline at end of file diff --git a/_site/robots.txt b/_site/robots.txt new file mode 100644 index 00000000..e087884e --- /dev/null +++ b/_site/robots.txt @@ -0,0 +1 @@ +Sitemap: /sitemap.xml diff --git a/_site/script/check-new-links.sh b/_site/script/check-new-links.sh new file mode 100755 index 00000000..6a9b1668 --- /dev/null +++ b/_site/script/check-new-links.sh @@ -0,0 +1,61 @@ +#!/bin/bash +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2021-2022 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS + +# This script is referenced by .github/workflows/test.yml which executes on +# each pull request. + +# As part of reviewing a contribution, reviewers are responsible for checking +# that new links are valid. This script is intended to aid in that process. +# Rather than checking all links with an incoming contribution, only the links +# added by that contribution should be checked. + +NOT_OK_COUNT=0 +SKIP_PATTERNS=( + 'github\.com/.*/edit' # links may not exist yet + 'twitter\.com' # twitter is broken + 'http://127.0.0.1' # local host + 'http://localhost' # local host +) + +if [ "_${VERBOSE}_" == "__" ]; then VERBOSE=0; fi + +for URL in $(git diff develop | + grep '^+' | + grep -Eo '(http|https)://[^ )"><]+'); do + SKIP_URL=0 + for PATTERN in "${SKIP_PATTERNS[@]}"; do + if echo "$URL" | grep --quiet --extended-regexp "$PATTERN" + then + if [ $VERBOSE -gt 0 ]; then + echo "'$URL' matches '$PATTERN'" + fi + SKIP_URL=1 + fi + done + if [ $SKIP_URL -eq 1 ] + then + if [ $VERBOSE -gt 0 ]; then + echo "(ignoring '$URL')" + fi + elif curl --fail --show-error --silent --head --location $URL \ + > url_head 2>&1 + then + if [ $VERBOSE -gt 0 ] + then + echo "$URL" + head -n1 url_head + fi + else + let "NOT_OK_COUNT+=1" + echo $URL + head -n1 url_head + fi + rm -f url_head +done + +if [ $NOT_OK_COUNT -gt 0 ]; then + echo "FAIL: $NOT_OK_COUNT new URLs were not OK" + EXIT_FAILURE=1 + exit $EXIT_FAILURE +fi diff --git a/_site/script/ensure-font.sh b/_site/script/ensure-font.sh new file mode 100755 index 00000000..224beb14 --- /dev/null +++ b/_site/script/ensure-font.sh @@ -0,0 +1,29 @@ +#!/bin/bash +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2022-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS + +# halt on error +set -e + +# On Ubuntu (and Debian-like systems), fc-cache is in the fontconfig package +# sudo apt-get install -y fontconfig + +FONT_NAME=Mulish +FONT_URL="https://fonts.google.com/download?family=$FONT_NAME" +FONT_DIR="${HOME}/.local/share/fonts" +FONT_ZIP="/tmp/${FONT_NAME}.zip" + +if grep "$FONT_NAME" <<< "$(fc-match $FONT_NAME)"; then + echo "$FONT_NAME is installed" + exit 0; +fi +echo "installing $FONT_NAME from $FONT_URL" + +rm -fv "$FONT_ZIP" +curl --output "$FONT_ZIP" "$FONT_URL" +mkdir -pv "$FONT_DIR" +cd "$FONT_DIR" +unzip -o -d . "$FONT_ZIP" +rm -fv "$FONT_ZIP" +fc-cache -fv +fc-match "$FONT_NAME" diff --git a/_site/script/find-missing-spdx.sh b/_site/script/find-missing-spdx.sh new file mode 100755 index 00000000..fe443095 --- /dev/null +++ b/_site/script/find-missing-spdx.sh @@ -0,0 +1,26 @@ +#!/bin/bash +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2022 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS + +function git_list_files() { + # -r Recurse into sub-trees. + git ls-tree \ + --full-tree \ + -r \ + --name-only \ + HEAD +} + +IGNORE_PATTERN='\.svg\|\.json\|CNAME\|Gemfile\|LICENSE\|jargon.txt' + +MISSING=0 +for FILE in $(git_list_files | grep --invert-match $IGNORE_PATTERN); do + if ! grep --quiet SPDX-License-Identifier $FILE; then + MISSING=$(( 1 + $MISSING )) + echo $FILE + fi +done + +if [ $MISSING -ne 0 ]; then + exit 1 +fi diff --git a/_site/script/generate-checklist.sh b/_site/script/generate-checklist.sh new file mode 100755 index 00000000..632e4aef --- /dev/null +++ b/_site/script/generate-checklist.sh @@ -0,0 +1,94 @@ +#!/bin/bash +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS + +TEMPLATE=docs/checklist.html +THIS_YEAR=$(date +%Y) +STANDARD_VERSION="${1}" +cat << EOF > $TEMPLATE + + + + + + +Standard for Public Code Checklist + + + +

Standard for Public Code version ${STANDARD_VERSION} checklist

+EOF + +# grep criteria files for "order: ", results in entries like: +# criteria/document-the-code.md:order: 9 +# ignoring the index.md +# swap name and order (extract the order number put it ahead of the file name) +# sort numerically +# take only the file name +CRITERIA_FILES=$(grep '^order: ' criteria/*.md \ + | grep --invert-match 'index.md' \ + | sed 's@\(criteria/[a-z\-]*.md\):order:\s*\([0-9]*\).*@\2 \1@g' \ + | sort --numeric-sort \ + | cut --fields=2 --delimiter=' ') + +for FILE in $CRITERIA_FILES; do + # echo $FILE + FILE_BASE=$(basename --suffix=.md $FILE) + # Strip the '#' off of the H1 + CRITERION_TITLE=$(grep '^# [A-Z]' $FILE \ + | grep --invert-match 'SPDX' \ + | cut --fields=2- --delimiter=' ') + CRITERION_LINK=https://standard.publiccode.net/criteria/${FILE_BASE}.html + cat << EOF >> $TEMPLATE + +

☐ $CRITERION_TITLE

+ +
    +EOF + # awk will process each line of file + # set 'p' to 1 if we are in the "## Requirements" section, or skip line + # set 's' to be all the words except the leading "*" of requirement + # if not a blank line, print 's' and the column pipe delimiters + awk 'BEGIN {p=0}; /## Requirements/ {p=1 ; next}; /##/ {p=0 ; next}; \ + p { s = ""; for (i = 2; i <= NF; i++) s = s $i " "; \ + if (length(s) > 0) print \ + "
  • " s "
    • "}' \ + $FILE >> $TEMPLATE + echo "
" >> $TEMPLATE +done +echo "" >> $TEMPLATE +echo "" >> $TEMPLATE + +# remove trailing spaces at end of line +sed -i -e's/\s\+$//g' $TEMPLATE + +# remove markdown links +sed -i -e's@\[\([^]]*\)\](\([^)]*\))@\1@g' $TEMPLATE + +ls -l $TEMPLATE diff --git a/_site/script/generate-review-template.sh b/_site/script/generate-review-template.sh new file mode 100755 index 00000000..05029e89 --- /dev/null +++ b/_site/script/generate-review-template.sh @@ -0,0 +1,119 @@ +#!/bin/bash +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2022-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS + +TEMPLATE=docs/review-template.html +THIS_YEAR=$(date +%Y) +STANDARD_VERSION="${1}" +cat << EOF > $TEMPLATE + + + + + + +________ and the Standard for Public Code + + + +

________ and the Standard for Public Code version ${STANDARD_VERSION}

+ +Link to commitment to meet the Standard for Public Code: +EOF + +# grep criteria files for "order: ", results in entries like: +# criteria/document-the-code.md:order: 9 +# ignoring the index.md +# swap name and order (extract the order number put it ahead of the file name) +# sort numerically +# take only the file name +CRITERIA_FILES=$(grep '^order: ' criteria/*.md \ + | grep --invert-match 'index.md' \ + | sed 's@\(criteria/[a-z\-]*.md\):order:\s*\([0-9]*\).*@\2 \1@g' \ + | sort --numeric-sort \ + | cut --fields=2 --delimiter=' ') + +for FILE in $CRITERIA_FILES; do + # echo $FILE + FILE_BASE=$(basename --suffix=.md $FILE) + # Strip the '#' off of the H1 + CRITERION_TITLE=$(grep '^# [A-Z]' $FILE \ + | grep --invert-match 'SPDX' \ + | cut --fields=2- --delimiter=' ') + CRITERION_LINK=https://standard.publiccode.net/criteria/${FILE_BASE}.html + cat << EOF >> $TEMPLATE + +

$CRITERION_TITLE

+ +☐ criterion met. + + + +EOF + # awk will process each line of file + # set 'p' to 1 if we are in the "## Requirements" section, or skip line + # set 's' to be all the words except the leading "*" of requirement + # if not a blank line, print 's' and the column pipe delimiters + awk 'BEGIN {p=0}; /## Requirements/ {p=1 ; next}; /##/ {p=0 ; next}; \ + p { s = ""; for (i = 2; i <= NF; i++) s = s $i " "; \ + if (length(s) > 0) print \ + "\n\n\n\n\n"}' \ + $FILE >> $TEMPLATE + echo "
MeetsRequirementNotes and links
\n\n\n" \ + s \ + "\n\n\n
" >> $TEMPLATE +done +echo "" >> $TEMPLATE +echo "" >> $TEMPLATE + +# remove trailing spaces at end of line +sed -i -e's/\s\+$//g' $TEMPLATE + +# unlink glossary local links in requirement lines +sed -i -e's@\[\([^]]*\)\](../glossary.md\(#[a-z\-]*\))@\1@g' $TEMPLATE + +# fully qualify local criteria links in requirement lines +# by looking for links lacking a colon +sed -i -e's@\[\([^]]*\)\](\([^:)]*\).md)@[\1](https://standard.publiccode.net/criteria/\2.html)@g' $TEMPLATE + +# convert markdown links to html links +sed -i -e's@\[\([^]]*\)\](\([^)]*\))@\1@g' $TEMPLATE + +ls -l $TEMPLATE diff --git a/_site/script/make-version-badge.sh b/_site/script/make-version-badge.sh new file mode 100755 index 00000000..91b0cd97 --- /dev/null +++ b/_site/script/make-version-badge.sh @@ -0,0 +1,61 @@ +#!/bin/bash +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2023 The Foundation for Public Code + +# $ help set | grep "\-e" +# -e Exit immediately if a command exits with a non-zero status. +set -e + +if [ "_${VERBOSE}_" == "__" ]; then VERBOSE=0; fi +if [ $VERBOSE -gt 0 ]; then +# $ help set | grep "\-x" +# -x Print commands and their arguments as they are executed. + set -x +fi + +VERSION=${1} +if [ "_${VERSION}_" == "__" ]; then + echo "must supply a version" + exit 1 +fi + +BADGE_LABEL="version" +BADGE_TEXT="$VERSION" +BADGE_COLOR_NAME="yellow" +BADGE_COLOR_CODE=":yellow" +# BADGE_PATH=assets/${BADGE_LABEL}-${BADGE_TEXT}-${BADGE_COLOR_NAME}.svg +BADGE_PATH=assets/version-badge.svg + + +if ! [ -e ./node_modules/.bin/badge ]; then + npm install +fi +ls -l ./node_modules/.bin/badge + +rm -f $BADGE_PATH +cat > ${BADGE_PATH}.head.svg < + + + +EOF + +# create the body +./node_modules/.bin/badge \ + "${BADGE_LABEL}" \ + "${BADGE_TEXT}" \ + "${BADGE_COLOR_CODE}" \ + flat \ + > ${BADGE_PATH}.body.svg + +# combine the unformatted contents +cat ${BADGE_PATH}.head.svg \ + ${BADGE_PATH}.body.svg \ + > ${BADGE_PATH}.tmp.svg + +# format for final output +xmllint --format ${BADGE_PATH}.tmp.svg \ + --output ${BADGE_PATH} + +rm ${BADGE_PATH}.{tmp,head,body}.svg +ls -l ${BADGE_PATH} diff --git a/_site/script/missing-glossary-links.sh b/_site/script/missing-glossary-links.sh new file mode 100755 index 00000000..72740ab3 --- /dev/null +++ b/_site/script/missing-glossary-links.sh @@ -0,0 +1,101 @@ +#!/bin/bash +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2022 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS + +# This script extracts the glossary terms from glossary.md +# for each file in the criteria directory, it looks for the use of a term +# if the term is found, it checks to see if a link exists +# if no link is found, it prints the TODO list + +if [ "_${VERBOSE}_" == "__" ]; then + VERBOSE=0 +fi + +if [ $VERBOSE -gt 1 ]; then + set -x +fi + +MISSING=0; + +# grep for heading in glossary +# strip the hashes off +# strip off the leading space +# convert space to hyphen +# transform upper case to lower case +GLOSSARY_ANCHORS=$( grep '## ' glossary.md \ + | cut -f3- -d"#" \ + | sed -e 's/^ //g' \ + | sed -e 's/ /-/g' \ + | tr A-Z a-z ) + +function glossary_pass_list() { + GLOSSARY_ANCHOR=$1 + FILE=$2 + + # "version control" correctly links to the criterion + # rather than the glossary entry + if [ "$GLOSSARY_ANCHOR" == "version-control" ] && + [ "$FILE" == "criteria/bundle-policy-and-source-code.md" ]; then + return 0 + fi + if [ "$GLOSSARY_ANCHOR" == "version-control" ] && + [ "$FILE" == "criteria/use-continuous-integration.md" ]; then + return 0 + fi + + # "Open Source Initiative" would be a false positive + if [ "$GLOSSARY_ANCHOR" == "open-source" ] && + [ "$FILE" == "criteria/use-open-standards.md" ]; then + return 0 + fi + + # repository inside of a link would be a false positive + if [ "$GLOSSARY_ANCHOR" == "repository" ] && + [ "$FILE" == "criteria/require-review-of-contributions.md" ]; then + return 0 + fi + + # link to "bundle policy and source code" is a false positive + if [ "$GLOSSARY_ANCHOR" == "source-code" ] && + [ "$FILE" == "criteria/document-codebase-objectives.md" ]; then + return 0 + fi + + return 1 +} + +for GLOSSARY_ANCHOR in $GLOSSARY_ANCHORS; do + GLOSSARY_TERM=$(echo $GLOSSARY_ANCHOR | sed -e 's/-/ /g') + + if [ $VERBOSE -gt 0 ]; then + echo GLOSSARY_ANCHOR: $GLOSSARY_ANCHOR + echo GLOSSARY_TERM: $GLOSSARY_TERM + fi + if [ "_${GLOSSARY_TERM}_" == "_public code_" ]; then + GLOSSARY_TERM='Public code\|public code' + GREP="grep -lr" + else + GLOSSARY_TERM="$GLOSSARY_TERM" + #case insensitive + GREP="grep -ilr" + fi + for FILE in $( $GREP "$GLOSSARY_TERM" criteria/ | grep -v index); do + if glossary_pass_list "$GLOSSARY_ANCHOR" "$FILE"; then + continue + fi + + if grep -q "glossary.md\#$GLOSSARY_ANCHOR" $FILE; then + if [ $VERBOSE -gt 0 ]; then + echo Found link $GLOSSARY_ANCHOR $FILE + fi + else + MISSING=$(( $MISSING + 1 )) + echo to-do: $GLOSSARY_ANCHOR $FILE + fi + done +done + +if [ $MISSING -gt 0 ]; then + echo Missing $MISSING links + exit 1 +fi diff --git a/_site/script/pdf.sh b/_site/script/pdf.sh new file mode 100755 index 00000000..0d9925cf --- /dev/null +++ b/_site/script/pdf.sh @@ -0,0 +1,160 @@ +#!/bin/bash +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2021-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS + +# This script is used to generate a PDF from the html generated by Jekyll. +# This script is used during the release process (see ../docs/releasing.md) + +if [ "_${1}_" == "__" ]; then + echo "must specify a VERSION" + exit 1 +fi +VERSION="${1}" + +function weasyprint_version() { + weasyprint --version \ + | sed -e's/[^0-9]*\([0-9\.]*\).*/\1/' +} + +function temp_weasyprint_info() { + if [ $TMP_WEASYPRINT -gt 0 ]; then + WEASY_PRINT_VER=$(weasyprint_version) + echo "=================================================" + echo "temp WeasyPrint installed, version $WEASY_PRINT_VER" + echo "to use this version outside of this script," + echo "type the following command:" + echo + echo "$ source /tmp/weasyprint/venv/bin/activate" + echo "=================================================" + fi +} + +function ensure_good_weasyprint () { + WEASY_PRINT_VER=$(weasyprint_version) + echo "WEASY_PRINT_VER='$WEASY_PRINT_VER'" + + if [ "_${WEASY_PRINT_VER}_" != "__" ]; then + WP_MAJOR_VERSION=$(echo "${WEASY_PRINT_VER}" | cut -f1 -d'.') + WP_MINOR_VERSION=$(echo "${WEASY_PRINT_VER}" | cut -f2 -d'.') + else + WP_MAJOR_VERSION=0 + WP_MINOR_VERSION=0 + fi + + if [ "$WP_MAJOR_VERSION" -lt 57 ]; then + echo "WeasyPrint version: $WEASY_PRINT_VER less than 57" + echo "installing new weasyprint" + pushd /tmp + rm -rf weasyprint + git clone https://github.com/Kozea/WeasyPrint.git weasyprint + cd weasyprint + python3 -m venv venv + source venv/bin/activate + pip install weasyprint + TMP_WEASYPRINT=1 + echo + temp_weasyprint_info + echo + popd + fi + if [ "_${TMP_WEASYPRINT}_" == "__" ]; then + TMP_WEASYPRINT=0 + fi +} +ensure_good_weasyprint + +JEKYLL_PDF_PORT=9000 +JEKYLL_PDF_DIR=_build_pdf +rm -rf $JEKYLL_PDF_DIR + +PAGES_REPO_NWO=publiccodenet/standard \ + bundle exec jekyll serve \ + --port=$JEKYLL_PDF_PORT \ + --destination=$JEKYLL_PDF_DIR & +JEKYLL_PID=$! +function cleanup() { + echo "Killing JEKYLL_PID: $JEKYLL_PID" + kill $JEKYLL_PID +} +trap cleanup EXIT # stop the jekyll serve + +MAX_LOOPS=100 +LOOPS=0 +while ! curl "http://localhost:$JEKYLL_PDF_PORT" >/dev/null 2>&1 ; do + LOOPS=$(( $LOOPS + 1 )); + echo "try $LOOPS, waiting to connect ..." + sleep 1; + if [ $LOOPS -gt $MAX_LOOPS ]; then + echo "exceeds MAX_LOOPS"; + exit 1; + fi +done + +# give it one more second +sleep 1; + +echo +weasyprint --presentational-hints \ + "http://localhost:$JEKYLL_PDF_PORT/standard-print.html" \ + standard-for-public-code-$VERSION.pdf +ls -l standard-for-public-code-$VERSION.pdf + +echo +weasyprint --presentational-hints \ + "http://localhost:$JEKYLL_PDF_PORT/foreword-print.html" \ + standard-for-public-code-foreword-$VERSION.pdf +ls -l standard-for-public-code-foreword-$VERSION.pdf + +echo +weasyprint --presentational-hints \ + "http://localhost:$JEKYLL_PDF_PORT/print-cover.html" \ + standard-cover-$VERSION.pdf +ls -l standard-cover-$VERSION.pdf + +echo +weasyprint --presentational-hints \ + "http://localhost:$JEKYLL_PDF_PORT/docs/review-template.html" \ + standard-review-template-$VERSION.pdf +ls -l standard-review-template-$VERSION.pdf + +echo +weasyprint --presentational-hints \ + "http://localhost:$JEKYLL_PDF_PORT/docs/checklist.html" \ + standard-checklist-$VERSION.pdf +ls -l standard-checklist-$VERSION.pdf + +echo +if ! pandoc --version ; then + echo "'pandoc' not installed, skipping .epub version" + echo "'pandoc' should be available from the package manager, e.g.:" + echo + echo " sudo apt install -y pandoc" + echo +else + pandoc $JEKYLL_PDF_DIR/standard-print.html \ + -o standard-for-public-code-$VERSION.epub + ls -l standard-for-public-code-$VERSION.epub +fi + +echo +if ! qpdf --version ; then + echo "'qpdf' not installed, skipping combined-for-print version" + echo "'qpdf' should be available from the package manager, e.g.:" + echo + echo " sudo apt install -y qpdf" + echo +else + qpdf --empty --pages \ + standard-for-public-code-foreword-$VERSION.pdf \ + standard-for-public-code-$VERSION.pdf \ + -- \ + standard-for-public-code-print-$VERSION.pdf + ls -l standard-for-public-code-print-$VERSION.pdf +fi + +echo +temp_weasyprint_info + +ls -l *.pdf *.epub + +echo "done" diff --git a/_site/script/release-body.sh b/_site/script/release-body.sh new file mode 100755 index 00000000..596b426b --- /dev/null +++ b/_site/script/release-body.sh @@ -0,0 +1,36 @@ +#!/bin/bash +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2022-2023 The Foundation for Public Code + +# Create a 'release.body' file for the text describing a release + +if [ "_${VERBOSE}_" != "__" ] && [ "$VERBOSE" -gt 0 ]; then + set -x +fi + +CODEBASE_NAME="Standard for Public Code" +VERSION=$1 +if [ "_${VERSION}_" == "__" ]; then + echo "No version?" + exit 1 +fi +echo "# $CODEBASE_NAME version $VERSION" > release.body + +# strip the trailing version info if exists, e.g: '1.2.3-rc2' becomes '1.2.3' +BASE_VERSION=$( echo "$VERSION" | sed 's/^\([0-9]*\.[0-9]*\.[0-9]*\).*/\1/' ) + +# pull out the top of the CHANGELOG +START=$( grep "##" CHANGELOG.md | head -n1 ) + +# if the first CHANGELOG entry (START) does not match the BASE_VERSION, +# then print error and exit +if ! grep -q "$BASE_VERSION" <<< "$START"; then + echo "Start of CHANGELOG.md does not match $BASE_VERSION" + exit 1 +fi + +# add BASE_VERSION notes to release.body +NEXT=$( grep '##' CHANGELOG.md | head -n2 | tail -n1 ) +sed -n "/$START/,/$NEXT/p" CHANGELOG.md \ + | grep -v '^##' \ + >> release.body diff --git a/_site/script/serve.sh b/_site/script/serve.sh new file mode 100755 index 00000000..49fff946 --- /dev/null +++ b/_site/script/serve.sh @@ -0,0 +1,15 @@ +#!/bin/bash +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2022 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS + +# The serve.sh script can be used to preview how Jekyll will build the site. +# See also: pdf.sh + +# if PAGES_REPO_NWO is not set then default to publiccodenet/standard +# (jekyll defaults to "origin" if a remote of that name exists, +# which makes sense for a true fork, but not for most contributors) +if [ "_${PAGES_REPO_NWO}_" == "__" ]; then +export PAGES_REPO_NWO=publiccodenet/standard +fi + +bundle exec jekyll serve --livereload diff --git a/_site/script/spell-check.sh b/_site/script/spell-check.sh new file mode 100755 index 00000000..bd841a4e --- /dev/null +++ b/_site/script/spell-check.sh @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2023 The Foundation for Public Code + +# help set +# -e Exit immediately if a command exits with a non-zero status. +# -x Print commands and their arguments as they are executed. +if [ "_${VERBOSE}_" != "__" ] && [ "${VERBOSE}" -gt 0 ]; then + set -x +fi +set -e + + +function git_list_files() { + # -r Recurse into sub-trees. + git ls-tree \ + --full-tree \ + -r \ + --name-only \ + HEAD +} + +IGNORE_PATTERN='\.css$\|\.svg$\|\.json$\|CNAME$\|Gemfile$\|LICENSE$\|\.sh$\|\.gitignore$\|.github.*\|jargon.txt$' + +ERRORS=0 +for FILE in $(git_list_files | grep --invert-match $IGNORE_PATTERN); do + name=$(basename -- "$FILE") + extension="${name##*.}" + + if [ "$extension" == "html" ]; then + MODE=--mode=html + elif [ "$extension" == "md" ]; then + MODE=--mode=markdown + fi + WORDS=$( aspell $MODE --master=en \ + --home-dir=. --personal=jargon.txt \ + list < $FILE ) + if [ $(echo "$WORDS" | wc -w) -gt 0 ]; then + echo "FAIL: $FILE spell check: $WORDS" + ERRORS=$(( $ERRORS + 1 )) + fi +done +if [ $ERRORS -gt 0 ]; then + exit 1 +fi diff --git a/_site/script/test-all.sh b/_site/script/test-all.sh new file mode 100755 index 00000000..57dbedc2 --- /dev/null +++ b/_site/script/test-all.sh @@ -0,0 +1,20 @@ +#!/usr/bin/env bash +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2022 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS + +# This script is provided for local development, +# it is not used by continuous integration + +# $ help set +# -e Exit immediately if a command exits with a non-zero status. +# -x Print commands and their arguments as they are executed. +set -x +set -e + +./script/find-missing-spdx.sh +./script/test-markdown.sh +./script/spell-check.sh +./script/missing-glossary-links.sh +./script/check-new-links.sh +./script/test-without-link-check.sh +./script/test-with-link-check.sh diff --git a/_site/script/test-markdown.sh b/_site/script/test-markdown.sh new file mode 100755 index 00000000..eeaec428 --- /dev/null +++ b/_site/script/test-markdown.sh @@ -0,0 +1,13 @@ +#!/bin/sh +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2021-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS + +# This script is referenced by .github/workflows/test.yml which executes on +# each pull request. + +# As part of reviewing a contribution, reviewers are responsible for checking +# that new Markdown is valid and conforms to the repository guidelines. This +# script is intended to aid in that process. + +# Lint markdown using the rules loaded with .mdlrc, .mdl_style.rb +bundle exec mdl -i -g '.' diff --git a/_site/script/test-with-link-check.sh b/_site/script/test-with-link-check.sh new file mode 100755 index 00000000..f94b36e7 --- /dev/null +++ b/_site/script/test-with-link-check.sh @@ -0,0 +1,60 @@ +#!/usr/bin/env bash +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2021-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS + +# This script is referenced by .github/workflows/link-check.yml which +# executes daily. + +# Failures reported by this script are addressed on a case-by-case basis. + +set -e # halt script on error + +# if PAGES_REPO_NWO is not set then default to publiccodenet/standard +# (jekyll defaults to "origin" if a remote of that name exists, +# which makes sense for a true fork, but not for most contributors) +if [ "_${PAGES_REPO_NWO}_" == "__" ]; then +export PAGES_REPO_NWO=publiccodenet/standard +fi + +# Build the site +bundle exec jekyll build + +# bundle exec htmlproofer --help | grep url-ignore +# --url-ignore link1,[link2,...] A comma-separated list of +# Strings or RegExps containing URLs that are safe to ignore. +# * github.com/foo/edit/ : may reference yet-to-exist pages +# * docs.github.com/en : blocked by github DDoS protection +# * plausible.io/js/plausible.js : does not serve to scripts +# * opensource.org : gives "failed: 503 No error" when run as GitHub workflow +# * belastingdienst.nl/wps/wcm/connect/bldcontenten : regular timeouts +# * reclameland.nl : often "failed: 403 No error" when run as GitHub workflow +# * www.dta.gov.au : often "failed: 403 No error" when run as GitHub workflow +# * 127.0.0.1 : localhost does not need to be checked +# * twitter.com : failed: 302 Number of redirects hit maximum amount +# +URL_IGNORE_REGEXES="\ +/github\.com\/.*\/edit\//\ +,/docs\.github\.com\/en\//\ +,/plausible\.io\/js\/plausible\.js/\ +,/opensource\.org/\ +,/belastingdienst\.nl\/wps\/wcm\/connect\/bldcontenten/\ +,/reclameland\.nl\/drukken\/softcover-boeken/\ +,/www\.dta\.gov\.au\/help-and-advice/\ +,/127\.0\.0\.1:/\ +,/twitter\.com\//\ +,/amsterdam\.nl\/en\//\ +" + +# ignore request rate limit errors (HTTP 429) +# --http_status_ignore "429" \ + +# Check for broken links and missing alt tags: +# jekyll does not require extensions like HTML +# ignoring problem urls (see above) +# set an extra long timout for test-servers with poor connectivity +# using the files in Jekylls build folder +bundle exec htmlproofer \ + --assume-extension \ + --url-ignore $URL_IGNORE_REGEXES \ + --typhoeus-config '{"timeout":60,"ssl_verifypeer":false,"ssl_verifyhost":"0"}' \ + ./_site diff --git a/_site/script/test-without-link-check.sh b/_site/script/test-without-link-check.sh new file mode 100755 index 00000000..32d2277a --- /dev/null +++ b/_site/script/test-without-link-check.sh @@ -0,0 +1,33 @@ +#!/usr/bin/env bash +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2021-2022 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS + +# This script is referenced by .github/workflows/test.yml which executes on +# each pull request. + +# As part of reviewing a contribution, reviewers are responsible for checking +# that html is valid and conforms to the repository guidelines. This script is +# intended to aid in that process. + +set -e # halt script on error + +# if PAGES_REPO_NWO is not set then default to publiccodenet/standard +# (jekyll defaults to "origin" if a remote of that name exists, +# which makes sense for a true fork, but not for most contributors) +if [ "_${PAGES_REPO_NWO}_" == "__" ]; then +export PAGES_REPO_NWO=publiccodenet/standard +fi + +# Build the site +bundle exec jekyll build + +# Check for broken links and missing alt tags: +# jekyll does not require extentions like HTML +# run only "ScriptCheck" and "ImageCheck"; skip "LinkCheck" +# set an extra long timout for test-servers with poor connectivity +# ignore request rate limit errors (HTTP 429) +# using the files in Jekylls build folder +bundle exec htmlproofer \ + --assume-extension \ + --disable-external \ + ./_site diff --git a/_site/script/to-archive-org.sh b/_site/script/to-archive-org.sh new file mode 100755 index 00000000..55c0f6eb --- /dev/null +++ b/_site/script/to-archive-org.sh @@ -0,0 +1,84 @@ +#!/bin/bash +# SPDX-License-Identifier: LGPL-2.1-or-later +# to-archive-org.sh : send referenced URLs to the wayback machine +# Copyright (C) 2020 Eric Herman + +# TODO FIXXXME: use something better than bash + +if [ "_${ARCHIVER_LOG_FILE}_" == "__" ]; then + NOW=$(date --utc +%Y%m%dT%H%M%SZ) + ARCHIVER_LOG_FILE=/tmp/to-archive-org.sh.${NOW}.log +fi +echo "ARCHIVER_LOG_FILE=$ARCHIVER_LOG_FILE" + +if [ "_${ARCHIVER_USER_AGENT}_" == "__" ]; then + GIT_USER_NAME=$(git config --get user.name) + GIT_USER_EMAIL=$(git config --get user.email) + RUN_BY="$GIT_USER_NAME ( $GIT_USER_EMAIL )" + REMOTE=$(git remote -v | head -n1 | cut -f1 -d$'\t') + REPO_URL=$(git config --get remote.${REMOTE}.url) + ARCHIVER_USER_AGENT="'url-archiver run by $RUN_BY for $REPO_URL'" +fi +echo "ARCHIVER_USER_AGENT=$ARCHIVER_USER_AGENT" + +rm -f urls.txt + +# find . -type f -name '*.md' -print0 | +# while IFS= read -r -d '' FILE; do + +BRANCH_NAME=$(git branch | grep \* | cut -d ' ' -f2) +for FILE in $(git ls-tree -r --name-only $BRANCH_NAME); do + # URLs inside parens + grep '(http[s]\?:' "$FILE" \ + | sed -e's/.*[(]\(http[s]*:[^)]*\).*/\1/' \ + >> urls.txt + # URLs inside angle brackets + grep ']*\).*/\1/' \ + >> urls.txt + # URLs inside double-quotes + grep '"http[s]\?:' "$FILE" \ + | sed -e's/.*"\(http[s]*:[^"]*\).*/\1/' \ + >> urls.txt +done + +# create a list of unique URLs, excluding archive.org and localhost +cat urls.txt \ + | cut -f1 -d'#' \ + | grep -v '^http[s]\?://web.archive.org' \ + | grep -v '^http[s]\?://localhost' \ + | grep -v '^http[s]\?://127.0.0.1' \ + | sort -u \ + > urls-sorted.txt + +URLS_TOTAL=$(wc -l urls-sorted.txt | cut -f1 -d' ') + +# cat urls-sorted.txt + +MAX_PER_MINUTE=5 +echo "sending $URLS_TOTAL URLs to the wayback machine," +echo " throttled to $MAX_PER_MINUTE per minute..." +PAUSE_TIME=$(( 1 + (60 / $MAX_PER_MINUTE) )) +URLS_COUNT=0 +for URL in $(cat urls-sorted.txt); do + echo sleeping for $PAUSE_TIME .... + sleep $PAUSE_TIME + # $ sudo apt-get install gridsite-clients + ENCODED=`urlencode $URL` + echo "" + URLS_COUNT=$(( $URLS_COUNT + 1 )) + echo "$URLS_COUNT of $URLS_TOTAL" + echo URL: $URL + echo encoded: $ENCODED + + echo "" >> $ARCHIVER_LOG_FILE + echo "----------" >> $ARCHIVER_LOG_FILE + echo $URL >> $ARCHIVER_LOG_FILE + ARC_ORG_URL=https://web.archive.org/save/$ENCODED + echo $ARC_ORG_URL >> $ARCHIVER_LOG_FILE + curl --user-agent "$ARCHIVER_USER_AGENT" \ + $ARC_ORG_URL >> $ARCHIVER_LOG_FILE + echo "" >> $ARCHIVER_LOG_FILE + echo "----------" >> $ARCHIVER_LOG_FILE +done +echo "done" diff --git a/_site/script/update-changelog-date.sh b/_site/script/update-changelog-date.sh new file mode 100755 index 00000000..828214f0 --- /dev/null +++ b/_site/script/update-changelog-date.sh @@ -0,0 +1,46 @@ +#!/bin/bash +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2023 The Foundation for Public Code + +# help set | grep '\-e\|\-o' +# -e Exit immediately if a command exits with a non-zero status +# -o option-name +# help set | grep -A2 pipefail +# pipefail the return value of a pipeline is the status of +# the last command to exit with a non-zero status, +# or zero if no command exited with a non-zero status +set -e +set -o pipefail + +function num_suffix() { + case "$1" in + # teens or numbers ending something other than 1,2,3 + *1[0-9]|*[04-9]) + echo "$1"th + ;; + # non-teen numbers ending in 1 + *1) + echo "$1"st + ;; + # non-teen numbers ending in 2 + *2) + echo "$1"nd + ;; + # non-teen numbers ending in 3 + *3) + echo "$1"rd + ;; + esac +} + +# The date(1) command uses the locale, +# so we set it to C which is always installed +# and is the same as US English in this particular case. +# The formats %e %B %Y are documented in the man page: +# https://www.man7.org/linux/man-pages/man1/date.1.html + +TODAYS_DOM=$(LC_ALL=C date +'%e') +TODAYS_DOM_WITH_SUFFIX=$(num_suffix $TODAYS_DOM) +TODAYS_DATE=$(LC_ALL=C date +"%B $TODAYS_DOM_WITH_SUFFIX %Y") + +sed -i -e"s/DATE-OF-RELEASE:/${TODAYS_DATE}:/" CHANGELOG.md diff --git a/_site/sitemap.xml b/_site/sitemap.xml new file mode 100644 index 00000000..db8a39d5 --- /dev/null +++ b/_site/sitemap.xml @@ -0,0 +1,117 @@ + + + +/AUTHORS.html + + +/CC0-1.0.html + + +/CHANGELOG.html + + +/GOVERNANCE.html + + +/criteria/bundle-policy-and-source-code.html + + +/criteria/code-in-the-open.html + + +/criteria/document-codebase-maturity.html + + +/criteria/document-codebase-objectives.html + + +/criteria/document-the-code.html + + +/foreword-print.html + + +/foreword.html + + +/glossary.html + + +/criteria/ + + +/ + + +/criteria/maintain-version-control.html + + +/criteria/make-contributing-easy.html + + +/criteria/make-the-codebase-findable.html + + +/criteria/make-the-codebase-reusable-and-portable.html + + +/print-cover.html + + +/criteria/publish-with-an-open-license.html + + +/readers-guide.html + + +/criteria/require-review-of-contributions.html + + +/standard-print.html + + +/criteria/use-a-coherent-style.html + + +/criteria/use-continuous-integration.html + + +/criteria/use-open-standards.html + + +/criteria/use-plain-english.html + + +/criteria/welcome-contributors.html + + +/CODE_OF_CONDUCT.html + + +/CONTRIBUTING.html + + +/README.html + + +/docs/printing.html + + +/docs/releasing.html + + +/docs/roadmap.html + + +/docs/checklist.html +2023-08-30T05:59:51+00:00 + + +/docs/review-template.html +2023-08-30T05:59:51+00:00 + + +/docs/standard-for-public-code.html +2023-08-30T05:59:51+00:00 + + diff --git a/_site/standard-print.html b/_site/standard-print.html new file mode 100644 index 00000000..0bdd24ce --- /dev/null +++ b/_site/standard-print.html @@ -0,0 +1,2078 @@ + + + + + + + + + + + Standard for Public Code + + + + +
+

Request for contributions

+

Standard for Public Code

+ +
    + What public code is and how to implement it for: +
  • Public policy makers
    • +
  • Managers
    • +
  • Developers and designers
    • +
+ + hands shaking + +

Draft
Version 0.7.1

+

Licensed CC0 Digital Public Goods approval badge

+

github.com/publiccodenet/standard

+
+ +
+ +

作者群

+ +
    +
  • Alba Roza，Foundation for Public Code
    • +
  • Arnout Engelen
    • +
  • Arnout Schuijff，Foundation for Public Code
    • +
  • 唐鳳，數位發展部
    • +
  • Ben Cerveny，Foundation for Public Code
    • +
  • Bert Spaan
    • +
  • Boris van Hoytema，Foundation for Public Code
    • +
  • Charlotte Heikendorf
    • +
  • Claus Mullie，Foundation for Public Code
    • +
  • David Barberi
    • +
  • Edo Plantinga，Code For NL
    • +
  • Elena Findley-de Regt，Foundation for Public Code
    • +
  • Eric Herman，Foundation for Public Code
    • +
  • Felix Faassen，Foundation for Public Code
    • +
  • Floris Deerenberg
    • +
  • Jan Ainali，Foundation for Public Code
    • +
  • Johan Groenen，Code For NL
    • +
  • Marcus Klaas de Vries
    • +
  • Mark van der Net，阿姆斯特丹市政府
    • +
  • Martijn de Waal，阿姆斯特丹應用科技大學 (AUAS)，數位媒體與創意產業學院， +戲劇與公民媒體系講師
    • +
  • Matti Schneider
    • +
  • Mauko Quiroga
    • +
  • Maurice Hendriks， 阿姆斯特丹市政府
    • +
  • Maurits van der Schee，阿姆斯特丹市政府
    • +
  • Mirjam van Tiel，Foundation for Public Code
    • +
  • Ngô Ngọc Đức Huy
    • +
  • Paul Keller
    • +
  • Petteri Kivimäki， 北歐互通性解決方案機構 (NIIS)
    • +
  • Sky Bristol
    • +
  • Tamas Erkelens，阿姆斯特丹市政府
    • +
  • Timo Slinger
    • +
+ + +
+ +
+ +

Table of Contents

+ +
    +
  1. Authors
    2. +
  2. Readers guide
    3. +
  3. Glossary
    4. +
  4. Criteria + +
      + + + + + + + + + + + + + + + + + +
    1. 原始碼要開放
      2. + +
    2. 政策與原始碼要合捆
      3. + +
    3. 程式基底要可重複使用且可移植
      4. + +
    4. 歡迎貢獻者
      5. + +
    5. 貢獻要容易
      6. + +
    6. 維護版本控制
      7. + +
    7. 要求審查貢獻內容
      8. + +
    8. 程式基底要有目標文件
      9. + +
    9. 程式碼要有文件
      10. + +
    10. 使用白話的英語
      11. + +
    11. 採用開放標準
      12. + +
    12. 使用持續整合
      13. + +
    13. 發行採用開放授權
      14. + +
    14. 程式基底可查詢得到
      15. + +
    15. 風格要前後一致
      16. + +
    16. 記錄程式基底成熟度
      17. + +
    +
    5. +
  5. Contributing guide
    6. +
  6. Code of conduct
    7. +
  7. Governance
    8. +
  8. Version history
    9. +
  9. License
    10. +
+ +
+ +
+ codebase +
+ +
+ +

讀者指引

+ +

本標準描述說明許多準則。所有準則各小節結構維持一致，來讓讀者清楚明白如何開發良好的公共程式。

+ +

「政策制定者」、「管理人員」以及「開發人員與設計師」的稱呼，係指任何履行這些角色職責的人，不受其職稱限制。常見同時承擔多個角色職責的人。

+ +

以下是各小節的簡要介紹，以及在本標準準則中的作用。

+ +

前言

+ +

本小節說明這些準則想達成的目的，以及為何會對程式基底使用者與貢獻者來說這麼重要的原因。

+ +

需求規定

+ +

這個小節列出如果要遵循本標準，需要完成哪些事項。

+ +

本文件中的下列關鍵字，請以《IETF RFC 2119》的描述作解釋：

+ +
    +
  • 必須
    • +
  • 禁止
    • +
  • 要求
    • +
  • 應當
    • +
  • 不得
    • +
  • 應該
    • +
  • 不該
    • +
  • 建議
    • +
  • 得以
    • +
  • 可選擇
    • +
+ +

測試方式

+ +

本小節提供您可採取的行動，來確認貢獻內容是否遵循本標準。如果您想要務實操作本標準，這部分很關鍵。

+ +

我們已嘗試調整用字，讓即使是不熟悉這類主題內容的讀者，看完之後也能夠進行基本的遵循檢查。

+ +

公共政策制定者：需要的工作

+ +

本小節主要對象是政策制定者，列出他們的角色所能採取的具體行動。

+ +

公共政策制定者設定專案的優先順序與目標，而在科技上的經驗可能沒那麼多。

+ +

管理人員：需要的工作

+ +

本小節主要對象是管理人員，列出他們的角色所能採取的具體行動。

+ +

管理人員負責監督專案的準時交付、利害關係人管理，以及服務的持續交付。因此，他們得完全依賴政策制定者、開發人員與設計師。他們需要塑造正確的文化、籌備合適的資源、提供適 +當的架構等，才能交付優良的服務。

+ +

開發人員與設計師：需要的工作

+ +

本小節主要對象是開發人員與設計師，列出他們的角色能採取的具體行動。

+ +

開發人員通常對技術比較在行，與其他角色類別相比，對服務交付的影響更大。

+ +

作用範圍限制

+ +

《公共程式標準》不是為了涵蓋程式基底的個別實作而撰寫。這代表本標準不是要告訴實作人員，該如何遵循其組織單位當地的技術性基礎建設或法律框架。

+ +

此外，雖然《公共程式標準》有引用一些標準，並且與其他標準有滿多重疊的部分，但本標準的目的是要推動協作。因此，本標準目標不在於取代品質標準，像是 ISO 25000 +認證系列，或是取代那些聚焦於安全性的標準，例如 OpenSSF 最佳實務標 +章等，而是希望能與它們能良好協同搭 +配。

+ +

《公共程式標準》的目在於促進協作，但也無法保證能夠催生出一個社群。若要建立社群，除了程式基底需要準備好進行協作以外，也需要積極主動，以及做到超越協作以外的企圖 +心。

+ + +
+ +
+ +

詞彙表

+ +

程式或程式碼 (Code)

+ +

任何明確的規則系統，包括法律、政策與規則條例（法規、法式，也可稱為程式），以及用來開發軟體的原始碼（程式碼）。兩者都是規則，有些是由人類來執行，其餘則是由機器執 +行。

+ +

程式基底 (Codebase)

+ +

任何獨立分離的統合包，內含執行部分政策或軟體所需的程式（包含原始碼與政策）、測試與文件等的整套內容。

+ +

舉例而言，這個具體形式可以是文件，或是版本控制的儲存庫。

+ +

持續整合

+ +

在軟體工程中，持續整合 (CI) 是盡可能頻繁地將所有開發人員工作中的副本，合併回程式基底開發中分支的實務作法。

+ +

不同情境

+ +

只要是不同的公家機關或不同的部門，無法透過同一個決策單位讓協作自然發生，那就算是兩個不同的情境。

+ +

一般大眾

+ +

整體民眾：程式碼與其所建立的服務的終端使用者。

+ +

舉例而言，城市的居民即視為該城市的服務、以及驅動這些服務運作的程式碼的終端使用者。

+ +

開源或開放原始碼 (Open Source)

+ +

所謂「開源」或「開放原始碼」，是根據 OSI 開放原始碼促進會發表的《開放原始碼定義》而來。

+ +

開放標準

+ +

任何符合 OSI 開放原始碼促進會《開放標準需求規範》的標準，就是開放標準。

+ +

政策

+ +

政策是一套謹慎設計的原則體系，用來引導決策並達成合理的成果。政策是一種意圖的聲明，並以程序或協定來執行。政策通常是由組織單位內的理事機構採用執行。政策能協助做出主觀 +與客觀的決策。

+ +

公共政策是政府將其政治願景，轉化成計畫與行動來取得成果的程序。

+ +

在國家層級，政策與立法（法律）通常是分開的；而在地方政府中，這兩者之間的區別通常比較模糊。

+ +

在本標準當中，「政策」一詞指的是公家機關，例如政府與自治市等，所制定與採用的政策。

+ +

公共程式 (Public Code)

+ +

公共程式，是由公家機關所開發的開放原始碼軟體，同時包含協作與重複利用所需的政策與指引。

+ +

公共程式是在公共情境下，由人類或機器所執行的電腦原始碼（例如軟體與演算法）以及公共政策兩者。

+ +

服務公眾利益的公共程式，具有開放、易懂、課責、近用、永續等特性。

+ +

透過獨立於當地情境，但仍可在當地情境下實作的方式，還有公開以文件記錄開發程序等作法，來開發公共程式。如此，公共程式能作為基礎組件提供給他人，使其得以：

+ +
    +
  • 根據其當地情境重新實作
    • +
  • 作為起點並繼續開發
    • +
  • 當作學習時的基礎
    • +
+ +

為了促進重複利用，公共程式通常放到公眾領域發行，或者採取允許他人能自由檢視、重複利用其成果，甚至產出衍生作品的開放授權。

+ +

儲存庫

+ +

儲存庫是版本控制工具，用於存放程式基底的檔案與中介資料的儲存位置。儲存庫讓多位貢獻者，得以同時對同一組檔案作業。儲存庫可以儲存一組檔案的多個版本。

+ +

原始碼 (Source Code)

+ +

人類可讀，並且能夠翻譯成機器指令的電腦程式文字。

+ +

版本控制

+ +

版本控制，是對原始碼及其相關檔案的變動行為作管理的流程。變動行為，通常是以稱為「修訂編號」（或版次等類似名稱）的代號作識別。每次修訂都會標示其改動時間以及作者， +方便追溯程式碼的演進。修訂控制系統可用來比較不同版本之間的差異，以及查看內容隨著時間經歷的變動。

+ + +
+ + + +
+ unlock +
+ + + + + + + + + + + + + + + + + + + +
+

原始碼要開放

+ +

以開放精神編寫原始碼，能改善資訊透明、提高原始碼品質、讓原始碼更容易稽核，也能促進互相協作。

+ +

這些合在一起，讓公民更有機會瞭解軟體與政策如何影響他們與公家機關的互動。

+ +

需求規定

+ +
    +
  • 任何使用中政策的所有原始碼都「必須」要公開（用於偵測詐欺的原始碼除外），且能供民眾取用。
    • +
  • 任何使用中軟體的所有原始碼都「必須」要公開（用於偵測詐欺的原始碼除外），且能供民眾取用。
    • +
  • 程式基底「禁止」包含與使用者及其組織單位，或與第三方相關的敏感性資訊。
    • +
  • 目前非使用中的任何原始碼（像是新版本、提案版本，或較舊版本）都「應該」公開。
    • +
  • 「可選擇」是否要以文件記錄一般大眾與組織單位之間可能發生的任何特定互動，其背後所採用的原始碼或 +支持的政策。
    • +
+ +

測試方式

+ +
    +
  • 確認目前使用中的每個版本都有公布原始碼在網際網路上，而且民眾不需要經過任何形式的身分核對或授權，就能在原始貢獻組織以外，查看這些原始碼。
    • +
  • 確認程式基底檔案與送交版次歷史紀錄，不包含敏感性資訊。
    • +
  • 檢查目前非使用中的原始碼是否有公開。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 制定合乎開放精神的政策。
    • +
  • 以公開透明的政策為優先。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 孕育擁抱開放、重視學習、歡迎意見回饋的文化。
    • +
  • 與外部供應商和自由工作者以開放精神的方式協作。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 審查人員在檢核每次的送交版次紀錄時，要確實核對內容沒有包含組態設定、使用者名稱或密碼、公開金鑰，或其他產品系統中使用的實名憑證等敏感性資訊。
    • +
  • 為符合上述敏感性資訊的相關規定，請明確分開資料與原始碼。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

政策與原始碼要合捆

+ +

對於想根據所在情境實作程式基底的人，或是想更進一步貢獻程式基底開發的人來說，能同時取用原始 +碼與政策文件兩者，可作為建置成品時的基礎組件。

+ +

瞭解作用範疇與該範疇的政策是基本原則，才能瞭解程式基底試圖想解決的問題是什麼，以及該如何解決這些問題的作法。

+ +

為了評估是否需要在新的情境中實作程式基底，組織單位需要瞭解必須做出改變的程序有哪些，或是如何對現有解決方案付出額外調整設定，以適應新的情境背景。

+ +

需求規定

+ +
    +
  • 程式基底「必須」包含原始碼所根據的政策。
    • +
  • 如果政策根據原始碼而來，則該原始碼「必須」包含在程式基底中，用於偵測詐騙的原始碼則可除外。
    • +
  • 政策「應該」採用機器可讀且明確的格式。
    • +
  • 持續整合測試「應該」驗證原始碼與政策是否有一致執行。
    • +
+ +

測試方式

+ +
    +
  • 與公務人員確認原始碼所根據的所有政策內容都有收錄在內。
    • +
  • 與公務人員確認政策所根據的所有原始碼都有收錄在內。
    • +
  • 確認政策內容是否能在機器上解讀。
    • +
  • 確認原始碼與政策間的執行一致性能通過持續整合測試。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 與開發人員及設計師合作，確保政策法規與原始碼之間沒有不相符之處。
    • +
  • 提供相關政策內文，以便收錄於儲存庫中；如果政策內文沒有英文版，請提供英文版摘要。務必也同時包含貴組織單 +位所選擇遵守的各項標準，以及影響貴組織單位程式基底開發或部署情境的任何組織單位流程。
    • +
  • 請提供政策相關參考資料與連結。
    • +
  • 政策內容請使用明確且機器可讀的格式，像是物件管理群體所發表的格式。
    • +
  • 追蹤政策時，請使用與追蹤原始碼相同的版本控制與文件。
    • +
  • 定期檢查，瞭解程式基底中的原始碼如何變動，以及是否仍然符合政策意圖。
    • +
  • 納入會影響社會群體、程式基底與開發目標的相關政策，包含 GDPR 一般資料保護規 +則或是歐盟網頁無障礙命 +令等此類法律義務，或者是人權政 +策，例如公家機關對機會平等的承諾等。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 讓政策制定者、開發人員與設計師持續參與，並且在整個開發過程中保持聯繫溝通。
    • +
  • 確保政策制定者、開發人員與設計師朝相同目標努力。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 熟悉並且學會貴組織單位政策制定者所使用的流程模型標記法。
    • +
  • 與政策制定者一同合作，確保政策法規與原始碼之間沒有不相符之處。
    • +
  • 針對如何讓政策文字更清楚提供意見。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

程式基底要可重複使用且可移植

+ +

編寫可重複使用且可移植的程式碼，讓政策制定者、開發人員與設計師等，能重複使用、測試與改善目前已開發的內容，並將改善貢獻 +回程式基底中，如此可提高品質、降低維護成本、增強可靠性。

+ +

以重複利用為前提籌劃設計程式基底，更容易與多方共享程式基底的目標使命、願景與範圍等。多方開發與使用的程式基底， +更可以從能自我運作的社群中獲益。

+ +

以文件記錄周全的模組構成程式基底，能夠改善重複使用與維護的能力。以文件清楚記錄用途的模組，更容易在另一種情境中重複利用。

+ +

原始碼不依賴任何貢獻者、供應商或部署底下的特定情況專用基礎架構，則其他任何貢獻者都能測試該原始碼。

+ +

需求規定

+ +
    +
  • 程式基底「必須」開發成能在不同情境中重複使用。
    • +
  • 程式基底「必須」獨立於任何採用保密、無法揭露、專有或非開放式授權的軟體或服務，以供執行與瞭解。
    • +
  • 程式基底「應該」有多方單位使用。
    • +
  • 發展路線圖「應該」有多方單位的需求影響。
    • +
  • 程式基底開發「應該」由多方單位協作。
    • +
  • 「應該」使用組態設定方式以將原始碼調整成能適應各情境的特定需求。
    • +
  • 程式基底「應該」能夠在地化。
    • +
  • 原始碼與其文件「不應該」包含特定情況專用的資訊。
    • +
  • 程式基底模組「應該」以使其能夠在其他情境中重複利用的模式撰寫文件。
    • +
  • 軟體「不應該」要求僅有單一供應商能提供的服務或平台。
    • +
+ +

測試方式

+ +
    +
  • 與另一組織單位角色與您相似的人確認，看他們是否能利用程式基底，以及需要怎麼進行。
    • +
  • 確認程式基底不需要用到任何專有或非開放式授權的軟體或服務，就能夠執行。
    • +
  • 若程式基底處於早期開發階段，尚未準備好正式上線，則檢查是否有想要尋求協作者的意圖跡象。 +
      +
    • 或是如果程式基底非常成熟與穩定，鮮少需要修正、改善或貢獻： +
        +
      • 檢查是否有多方單位，或是有在多種情境下正使用程式基底。
        • +
      • 檢查是否有以文件記錄協作所做出的成果，以及有編列相關預算。
        • +
      +
      • +
    • 若是沒有，則： +
        +
      • 檢查是否有多方單位，或是有在多種情境下正使用程式基底。
        • +
      • 檢查程式基底貢獻者是否來自多方單位。
        • +
      +
      • +
    +
    • +
  • 檢查程式基底檔案與送交版次歷史紀錄中，不包含特定情況專用的資料。
    • +
  • 檢查軟體是否可以在不使用單一供應商服務或平台的情況下，正常部署與執行。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 為您的政策撰寫清楚且足夠詳細的文件，讓他人即使不是處於同個原始背景情境也能夠理解。
    • +
  • 確保程式基底有將貴組織單位列為已知使用者。
    • +
  • 找出貴團隊想要協作的其他組織單位。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 確認利害關係人與業主能夠瞭解，程式基底是以重複利用為明確目標，因而得以減少程式碼技術債，並讓程式基底可以永續發展。
    • +
  • 確認您的團隊與其他團隊能相互協作。
    • +
+ +

開發人員與設計師：需要的工作

+ +

原始碼應該設計成：

+ +
    +
  • 能讓其他使用者與組織單位可以重複利用，而不受地方環境影響，
    • +
  • 能解決通用性質問題，而非特定問題，
    • +
  • 以邏輯上具有意義且獨立的模組構成，
    • +
  • 如此讓類似組織單位中要面對近似問題的人，都可以採用這套解決方案（或其中一部份）。
    • +
+ +

確保程式基底文件中，有說明程式的組建日期與執行時期的依賴項目。如果您的情境需要部署至專有平臺上，或者要用到專有組件，則請確保協作者可以在不用到這兩者的情況下，就能進 +行開發、使用、測試、部署等。

+ +

在每份送交版次中，審查人員要確認其中不含特定情況專用的資料，像是主機名稱、個人與組織單位資料、代符與密碼等。

+ +

延伸閱讀

+ + + +
+ +
+

歡迎貢獻者

+ +

程式基底社群的氛圍，會影響使用者選擇所要使用的程式基底。歡迎任何人成為貢獻者的社群，才能夠不斷茁壯並且持續自我 +運作。若貢獻者有明確的方法可以影響程式基底、社群目標與進展，則該社群分裂成分歧的社群的機率也較低。新參與者需要瞭解並信任程式基底社群的治理方式。

+ +

需求規定

+ +
    +
  • 程式基底必須「允許」任何人對程式基底提出修改建議。
    • +
  • 程式基底「必須」包含貢獻指引，說明歡迎貢獻的內容類型，以及貢獻者可如何參與開發，例如以「CONTRIBUTING」檔案說明。
    • +
  • 程式基底「必須」以文件記錄程式基底、貢獻內容與社群互動等的治理方式，例如以「GOVERNANCE」檔案來說明。
    • +
  • 貢獻指引「應該」以文件記錄預期由何者負擔審查貢獻內容所需的開銷費用。
    • +
  • 程式基底「應該」宣布投入其開發與維護工作的參與組織單位。
    • +
  • 程式基底「應該」要有可公開取得的發展路線圖。
    • +
  • 程式基底「應該」公布程式基底的活動統計數據。
    • +
  • 「可選擇」是否為程式基底加入貢獻者的行為守則。
    • +
+ +

測試方式

+ +
    +
  • 確認可以提交修改建議給程式基底。
    • +
  • 確認程式基底有貢獻指引。
    • +
  • 確認程式基底有清楚解釋治理架構，並包含如何影響程式基底治理的方法。
    • +
  • 確認貢獻指引是否有涵蓋預期由何者負擔審查貢獻內容的開銷費用。
    • +
  • 檢查是否有參與的組織單位名單。
    • +
  • 檢查是否有發展路線圖。
    • +
  • 檢查是否有公布活動統計數據。
    • +
  • 檢查是否有行為守則。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 為程式基底加入其他資源的清單，而這些資源可幫助政策專家、非政府組織、學者等，更能瞭解或可重複利用您的政策。
    • +
  • 考慮放入聯絡資訊，讓其他考慮合作的政策制定者能徵詢您的意見。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 確保治理架構文件內容中，有包含目前如何改變治理狀態的流程。
    • +
  • 如果社群對於治理架構應該如何改變有共識，則應該將這些構想宣告為願景寫入文件中。
    • +
  • 若有需要，確認您有編列貢獻內容審查流程的預算，且經過程式基底社群同意。
    • +
  • 確認文件有解釋每個參與組織單位所投入的內容，例如提供程式基底哪些資源，以及參與的時間長度等。
    • +
  • 支持您經驗豐富的政策制定者、開發人員與設計師，使其盡可能長久參與社群。
    • +
+ +

+ +

開發人員與設計師：需要的工作

+ +
    +
  • 快速回應請求。
    • +
  • 告知管理人員，您在支援其他貢獻者時所需的時間與資源。
    • +
  • 清楚告知貢獻者他們該如何做，才能讓貢獻內容整合到程式基底中。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

貢獻要容易

+ +

若要開發更好、更可靠且功能更豐富的軟體，使用者需要能夠為共享的程式基底修正問題、新增功能，以及提出安全性議題 +等。

+ +

共享的數位基礎建設讓協作貢獻更容易。使用者讓程式基底接受貢獻時所需付出的心力越少，則使用者越可能成為貢獻者。

+ +

需求規定

+ +
    +
  • 程式基底「必須」有個可以公開接受任何人建議的議題追蹤器。
    • +
  • 文件中「必須」同時有公開的議題追蹤器連結，以及已提交的程式基底變動的連結，例如記錄在「README」檔案中。
    • +
  • 程式基底「必須」要有能與使用者以及開發人員溝通的管道，像是設立電子郵件列表（郵遞論壇）。
    • +
  • 「必須」有透過封閉管道通報安全性問題的方法，來達成負責任的揭露。
    • +
  • 文件「必須」說明，該如何通報潛在的安全性與敏感性問題。
    • +
+ +

測試方式

+ +
    +
  • 確認有公開的議題追蹤器。
    • +
  • 確認程式基底有公開的議題追蹤器連結，以及已提交的程式基底變動的連結。
    • +
  • 確認可以使用程式基底中提到的管道，與其他使用者以及開發人員一同討論該軟體。
    • +
  • 確認有封閉的管道可通報安全性問題。
    • +
  • 確認有說明如何私下通報安全性問題。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 追蹤程式基底中的政策問題，讓相關的外部政策專家如果自願也能夠協助。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 追蹤程式基底中的管理問題，讓有相關經驗的外部管理人員如果自願也能夠協助。
    • +
  • 支持您經驗豐富的政策制定者、開發人員與設計師，使其盡可能為程式基底持續做出長久貢獻。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 與審查流程相同，務必迅速回應請求。
    • +
  • 告知管理人員，您在支援其他貢獻者時所需的時間與資源。
    • +
  • 確保人們可輕鬆找到合適的溝通管道，來詢問維護人員與利害關係人問題，例如寫在「README」文件當中。
    • +
  • 確保中介資料包含合適的聯絡資訊，例如寫在 publiccode.yml 檔案中。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

維護版本控制

+ +

版本控制主要在追蹤原始碼以及其他程 +式基底檔案歷來的變動。這能讓您為程式基底維護有條理的變動歷史文件。這是大規模協作得以運作的要素，使開發人員可以 +針對修改變動平行作業，並幫助未來的開發人員瞭解做出修改的原因。

+ +

需求規定

+ +
    +
  • 程式基底中的所有檔案皆「必須」有版本控制。
    • +
  • 所有決定皆「必須」記錄成送交版次訊息。
    • +
  • 每份送交版次訊息皆「必須」盡可能附上討論與議題連結。
    • +
  • 程式基底「應該」以分散式版本控制系統作維護。
    • +
  • 貢獻守則「應該」要求貢獻者，將相關的修改變動以群組分類方式送交。
    • +
  • 維護人員「應該」使用像是修訂版次標記，或文字標籤，來標示程式基底正式發行的版本。
    • +
  • 貢獻守則「應該」鼓勵採用能在版本控制系統中，輕鬆檢視與瞭解檔案中何處有做出更動的檔案格式。
    • +
  • 貢獻者「可選擇」是否對送交內容作簽章，並附上電子郵件信箱，以便當未來貢獻者對其內容有疑問時，可以與之前的貢獻者聯絡。
    • +
+ +

測試方式

+ +
    +
  • 確認程式基底維持在版本控制狀態中，像是使用 Git 之類的軟體。
    • +
  • 審查送交版次歷史紀錄，確認所有的送交版次訊息，皆有解釋程式碼修改變動的原因。
    • +
  • 審查送交版次歷史紀錄，確認所有送交版次訊息之中，盡可能在所有討論過修改變更的地方，包含變動內容以及連結位置（提供網址）。
    • +
  • 檢查版本控制系統是否為分散式。
    • +
  • 審查送交版次歷史紀錄，檢查是否有根據貢獻指引將相關的程式碼變動以群組分類。
    • +
  • 檢查是否可能透過像是修訂版次標記，或文字標籤，來取用程式基底中的特定版本。
    • +
  • 檢查程式基底在盡可能的情況下，檔案都是採用文字格式。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 如果因為政策改變而在程式基底中有新的版本，則請確認有在文件中清楚說明： +
      +
    • 政策改變的地方，
      • +
    • 程式基底如何因應而改變。
      • +
    +
    • +
+ +

舉例來說，為程式基底作權限管理時，如果要新增申請方類別來賦予取用權，應視為一種政策變動。

+ +

管理人員：需要的工作

+ +
    +
  • 支持政策制定者、開發人員與設計師，使其能清楚表達他們對程式基底做出的改善。確保改善程式基底不會有公關風險。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 確認版本控制系統中，有瞭解程式碼、建置與部署所需要用到的所有檔案。
    • +
  • 送交版次訊息要寫清楚，讓人一看就能瞭解送交修改的原因。
    • +
  • 使用像是修訂版次標記，或文字標籤來標示不同版本，以方便取用特定版本。
    • +
  • 送交版次訊息要寫清楚，方便之後比較各版本。
    • +
  • 在政策改變以後，與政策制定者合作說明原始碼更新的部分。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

要求審查貢獻內容

+ +

同儕審查貢獻是原始碼提升品質的關鍵，也能降低安全性風險與營運風險。

+ +

要求仔細審查貢獻，能孕育出確保貢獻都是優質、完整且能帶來價值的文化。審查原始碼能提高在原始碼加入程式基底之前， +就發現與修正潛在臭蟲與出錯的機率。得知所有原始碼都會被審查，就不會孕育出習慣怪罪他人的文化，反倒是鼓勵每個人都專注在解決方案上。

+ +

快速審查政策在於向貢獻者保證，必定在一段時間內提供意見回饋或是協作式改善，進而提高貢獻者交付貢獻內容的頻率，以及參 +與的熱度。

+ +

需求規定

+ +
    +
  • 所有被接受或是送交給程式基底正式發行版本中的貢獻內容，都「必須」經過另一位貢獻者審查。
    • +
  • 審查「必須」包含原始碼、政策、測試、文件等。
    • +
  • 如果不接受貢獻內容，審查人員「必須」提供意見回饋。
    • +
  • 審查流程「應該」確認貢獻內容遵循程式基底的標準、架構、決策安排等，以通過審查。
    • +
  • 審查內容「應該」包含執行軟體與執行程式基底測試。
    • +
  • 貢獻內容「應該」由與貢獻者不同背景情境的人來審查。
    • +
  • 版本控制系統「不應該」在程式基底的正式發行版本中，接受未經審查的貢獻內容。
    • +
  • 審查「應該」在兩個工作天內進行。
    • +
  • 「可選擇」是否由多位審查人員進行審查。
    • +
+ +

測試方式

+ +
    +
  • 確認歷史紀錄中，每個送交版次都有經過不同的貢獻者審查。
    • +
  • 確認審查內容包含原始碼、政策、測試、文件等。
    • +
  • 針對未被採用的貢獻內容，確認有適當解釋原因。
    • +
  • 檢查審查人員指引中，有包含是否遵循標準、架構、程式基底指引等指示。
    • +
  • 檢查審查人員在審查時是否有執行軟體與測試。
    • +
  • 與審查人員確認，送交版次是否有經過不同情境背景的不同貢獻者審查。
    • +
  • 檢查版本控制系統中是否有採用分支保護。
    • +
  • 檢查貢獻提交與審查之間的時間間隔。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 制定進行任何審查時，含原始碼與其他一切事物，都要恪遵「四眼原則」的政策。
    • +
  • 採用具有審查與意見回饋功能的版本控制系統，或作業流程。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 將交付妥善軟體作為共同目標。
    • +
  • 確保如原始碼、政策、文件、測試等的貢獻內容撰寫與審查，皆受到同等重視。
    • +
  • 創造歡迎所有形式的貢獻，而且每個人都能夠審查貢獻內容的文化。
    • +
  • 確保貢獻者在貢獻內容給程式基底時，不是獨自一人埋頭苦幹。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 請程式基底的其他貢獻者，審查您在貴組織單位內外的工作成果。
    • +
  • 當他人請求您審查時，請盡快回覆，並先給出需要修正之處背後的概念。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

程式基底要有目標文件

+ +

以文件清楚記錄程式基底目標，來傳達程式基底的用途目標。這能幫助利害關係人與貢獻者劃定程式基底的開發範圍。這些目 +標也能方便人們判斷，是否在當下或未來，會對此程式基底或其模組感興趣。

+ +

需求規定

+ +
    +
  • 程式基底「必須」包含描寫目標的文件，像是主旨、使命或目標陳述。開發人員與設計師需要能夠瞭解這些，他們才知道可以怎樣使用程式基底或協助貢獻。
    • +
  • 程式基底文件「應該」清楚描述政策目標與程式基底目標之間的關聯。
    • +
  • 「可選擇」是否以文件記錄給一般大眾看的程式基底目標。
    • +
+ +

測試方式

+ +
    +
  • 確認程式基底文件有包含程式基底目標，或主旨、使命等。
    • +
  • 查看政策目標與程式基底目標之間關聯的描述。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 將政策目標加入程式基底文件中，例如「README」文件當中。
    • +
  • 確保所有程式基底目標，有連結或引用為了符合〈政策與原始碼要合捆〉準則而加入的支持政策文 +件。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 將單位目標、組織目標或業務目標加入程式基底文件中，例如「README」文件當中。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 將技術與設計目標加入程式基底文件中，例如「README」文件當中。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

程式碼要有文件

+ +

文件記錄周全的原始碼能幫助人們瞭解該原始碼的作用與使用方式。文件紀錄是幫助人們快速上手如何使用程式基 +底，並做出貢獻的關鍵。

+ +

需求規定

+ +
    +
  • 程式基底的所有功能、政策及原始碼，都「必須」以可清楚瞭解的用語描述，讓懂程式基底目的用途的人也能夠理解。
    • +
  • 程式基底文件「必須」說明如何安裝與執行軟體。
    • +
  • 程式基底文件「必須」為關鍵功能舉出範例。
    • +
  • 程式基底文件「應該」包含精要的說明，讓一般大眾和記者等廣泛的利害關係人都能清楚明白。
    • +
  • 程式基底文件「應該」有一部分用來說明，如何安裝與執行原始碼的單機版；如果有必要，也應該包含測試資料集。
    • +
  • 程式基底文件「應該」包含所有功能的範例。
    • +
  • 程式碼文件「應該」描述程式基底的主要組件或模組，以及其彼此之間的關係，例如以高層架構圖表示。
    • +
  • 「應該」要有針對文件品質的持續整合測試。
    • +
  • 「可選擇」是否在程式基底文件中，包含讓使用者想要立即使用程式基底的範例。
    • +
+ +

測試方式

+ +
    +
  • 確認文件內容能讓其他利害關係人、其他公家機關的專業人士，以及一般大眾，都可以清楚明白。
    • +
  • 確認文件有說明如何安裝與執行原始碼。
    • +
  • 確認文件有包含主要功能的範例。
    • +
  • 向一般大眾的成員以及記者確認，他們是否能明白文件當中的精要說明。
    • +
  • 檢查單機版原始碼的安裝與執行的步驟說明，確認能順利執行系統。
    • +
  • 檢查文件中列舉的所有功能都包含範例。
    • +
  • 檢查文件中是否包含高層架構圖，或類似的組件關係圖表。
    • +
  • 確認整合測試有包含到程式碼文件品質，例如確認生成的文件是否正確，並檢查連結與圖片等。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 定期查看程式基底中非政策程式碼的變動情況。
    • +
  • 針對如何讓非政策文件更清楚易懂提供意見回饋。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 嘗試使用程式基底，並提供您的意見回饋來讓政策與原始碼文件改善得更加清楚。舉例來說，可以自問目前的文件是否足以說服另一個公家機關的管理人員使用這套程式基底？
    • +
  • 確保您同時瞭解政策、原始碼以及文件內容。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 定期查看程式基底中非原始碼部分的變動情況。
    • +
  • 針對如何讓非原始碼文件更清楚易懂提供意見回饋。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

使用白話的英語

+ +

英語是軟體開發領域中的實際 協作語言。

+ +

公家機關資訊需要讓所有選民都能取用。簡單且白話的語言，能讓更多人能瞭解程式碼與其功用。

+ +

翻譯可以讓更多人有機會認識程式基底。用語越是簡單明暸，製作與維護翻譯的成本就越低。

+ +

需求規定

+ +
    +
  • 程式基底的所有文件都「必須」使用英語。
    • +
  • 所有原始碼都「必須」使用英語編寫，其中政策是由機器 +解讀當作程式碼的部分則除外。
    • +
  • 任何合捆的政策如果沒有英語版本，則「必須」隨附英語版摘要。
    • +
  • 任何翻譯版本皆「必須」跟隨英語版本更新，以維持在最新狀態，反之亦然。
    • +
  • 程式基底中「不應該」使用首字母縮字、縮寫、雙關語，或法律/非英語/行業特定詞彙；如果有的話，則需要在這些用語出現之前先行解釋，或是附上解釋該用語的網頁連結。
    • +
  • 根據《網頁內容近用性無障礙指引 2》的建議，文件內容「應該」以國中識讀程度為主。
    • +
  • 「可選擇」是否提供任何程式碼、文件、測試等的翻譯版。
    • +
+ +

測試方式

+ +
    +
  • 確認程式基底文件有英語版本。
    • +
  • 確認原始碼為英語，確認任何非英語內容都是政策，或確認術語在其前方有先行說明等。
    • +
  • 確認任何非英語政策都有隨附英語版摘要。
    • +
  • 確認翻譯版與英語版內容相同。
    • +
  • 確認文件當中，沒有任何未說明的首字母縮寫字、縮寫、雙關語，或法律/非英語/行業特定詞彙等。
    • +
  • 檢查文件的拼字、文法與易讀性等。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 在過程中經常與其他管理人員、開發人員與設計師測試，確認他們是否瞭解您們正要交付的程式碼與其文件的內容。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 在團隊內部與利害關係人之間的內部溝通中，試著限制首字母縮寫字、縮寫、雙關語，或法律/非英語/行業特定詞彙的使用。如果有使用到的話，則將這些用語加入詞彙表，並且在 +使用這些詞彙的地方加上詞彙表連結。
    • +
  • 以批判性觀點看待提案與修改當中的文件與描述。如果有您看不懂的內容，很有可能其他人也同樣迷惘。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 經常與政策制定者和管理人員測試，確認他們是否瞭解您們正要交付的程式碼與其文件的內容。
    • +
  • 詢問身處不同背景情境的人（像是另一個程式基底的開發人員）是否能瞭解內容。
    • +
+ +

+ +

延伸閱讀

+ + + +
+ +
+

採用開放標準

+ +

開放標準保證可以取得使用與貢獻程式基底所需的知 +識。不僅能為不同的系統之間建立互通性，更能降低廠商套牢的可能性。開放標準如果明確，不同方就可以各自獨立開發作資料交換。

+ +

需求規定

+ +
    +
  • 程式基底如要促進資料交換的特性，就「必須」採用符合 OSI 開放原始碼促進會其《開放標準需求規範》的 +開放標準。
    • +
  • 如果有使用到任何非開放標準，則「必須」在文件中清楚記錄。
    • +
  • 程式基底選擇採用的任何標準，皆「必須」在文件中列出，並且只要有的話，就附上該標準的連結。
    • +
  • 程式基底選擇採用的任何非開放標準，皆「禁止」妨礙程式基底的協作與重複使用。
    • +
  • 如果還沒有已存在的開放標準可採用，則「應該」投入開發新標準。
    • +
  • 採用開放標準時，「應該」優先選擇可經機器測試的開放標準。
    • +
  • 採用非開放標準時，「應該」優先選擇可經機器測試的非開放標準。
    • +
+ +

測試方式

+ +
    +
  • 確認資料交換遵守 OSI 開放原始碼促進會批准的開放標準。
    • +
  • 確認若有採用任何的非開放標準，皆有清楚記錄在文件中。
    • +
  • 確認文件有清單列出程式基底所採用的標準，其中各標準有對應的有效連結；或沒有採用任何標準時，則留下聲明。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 以政策要求盡可能在任何情況下採用開放標準。
    • +
  • 禁止採購不採用開放標準的技術科技。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 考慮在原始碼審查中納入開放標準依循評估。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 將是否依循標準加入持續整合測試中。
    • +
  • 審查送交版次與儲存庫其他資源是否有參考開放標準，並交叉檢查其中有列出標準的部分。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

使用持續整合

+ +

透過自動化測試驗證，開發人員能更頻繁地將其工作成果合併至共享的分支，達成非同步協作。合併的頻率越頻繁、貢獻的規模越小，在合併時所發生的衝突就越容易解決。

+ +

自動化測試所有功能，使人更加信賴貢獻內容發揮其功用且沒有引發任何錯誤，同時讓審查人員專注在貢獻的結構與作法。測試越聚焦，就越容易辨識並瞭解所出現的問題。

+ +

以文件記錄程式基底的持續整合工作流程，能協助貢獻者瞭解對貢獻內容的期待。持續整合讓 +監管程式基底狀態變得更為簡單。

+ +

需求規定

+ +
    +
  • 原始碼中的所有功能，都「必須」有自動化測試。
    • +
  • 所有貢獻內容都「必須」先通過自動化測試，才能上傳至程式基底。
    • +
  • 程式基底「必須」有解說如何撰寫貢獻內容結構的相關指引。
    • +
  • 程式基底「必須」有能夠審查貢獻內容的活躍貢獻者。
    • +
  • 「應該」公開貢獻內容的自動化測試結果。
    • +
  • 程式基底指引「應該」指出，每次的貢獻內容都只應聚焦在單一議題上。
    • +
  • 「應該」監管原始碼測試與文件的涵蓋範圍。
    • +
  • 「可選擇」是否測試政策和文件，與原始碼之間有無一致性，或是反之亦然。
    • +
  • 「可選擇」是否測試政策和文件所採用的樣式，以及連結有無失效。
    • +
  • 「可選擇」是否使用文件中的範例來測試軟體。
    • +
+ +

測試方式

+ +
    +
  • 確認有測試可用。
    • +
  • 確認原始碼覆蓋率工具能檢查到 100% 的原始碼。
    • +
  • 確認貢獻內容只有在通過所有測試後，才會認可上傳至程式基底。
    • +
  • 確認有貢獻指引解說如何撰寫貢獻內容的結構。
    • +
  • 確認最近三個月內有貢獻內容上傳。
    • +
  • 檢查是否可以查看測試結果。
    • +
  • 檢查是否有公布原始碼覆蓋率數據。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 儘早讓管理人員、開發人員與設計師一同加入，並且讓他們持續參與您政策的制定程序。
    • +
  • 確保政策文件也有設好自動化測試。
    • +
  • 如果政策文件未能通過測試，請快速修正。
    • +
  • 確保原始碼能反映出政策的任何變動（請參閱〈維護版本控制〉）。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 確保能儘快且經常給真正的終端使用者進行測試。
    • +
  • 以頻繁整合少量部分內容的方式做專案規劃，而非久久一次繳交大量部分內容。
    • +
  • 聘請有能力處理漸進式交付，並跟得上規劃進度的顧問服務。
    • +
  • 發生重大失誤後，鼓勵公開事故報告，以及公開討論事後學到的教訓。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 協助管理人員擬定工作規劃，例如規劃成可以拆分成小部分逐次整合。
    • +
  • 協助貢獻者聚焦其貢獻內容與功能請求，讓涵蓋範圍盡可能合理地縮小。
    • +
  • 協助管理人員與政策制定者測試其貢獻內容，例如測試其貢獻內容中的失效連結或樣式。
    • +
  • 編排原始碼結構時，要將難以在測試環境下創造出來的情況，得以在測試過程中模擬出來。例如硬碟空間不足、記憶體分配失敗等資源耗盡情況，都是難以創造的典型案例。
    • +
  • 調整程式碼覆蓋率測試工具，避免在 inline 過程或其他最佳化處理時得到假警報。
    • +
  • 經常部署。
    • +
  • 至少每天整合工作內容一次。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

發行採用開放授權

+ +

採用開放且為人熟知的授權，讓任何人都可以查看原始碼，使其能瞭解運作方式、自由使用，並且能為程式基 +底做出貢獻。這也能促進供應商建立出以程式基底為中心的生態系。

+ +

明確指出程式基底中每一個檔案的授權，讓使用者能正確重複利用程式基底的部分內容，並表彰作者名稱。

+ +

需求規定

+ +
    +
  • 所有原始碼與文件，皆「必須」採用使其得以自由重複使用、自由修改、自由再次散布的授權條款。
    • +
  • 軟體原始碼「必須」採用經 OSI 開放原始碼促進會所批准，或由 FSF 自由軟體基金會所發表的自由授權條 +款。
    • +
  • 所有原始碼皆「必須」搭配授權條款檔案一併發行。
    • +
  • 「禁止」要求貢獻者將其貢獻的程式碼著作權轉讓給程式基底。
    • +
  • 程式基底中所有原始碼檔案，皆「應該」包含機器可讀的著作權聲明與授權條款標頭內容。
    • +
  • 「可選擇」是否為不同類型的原始碼與文件採用多重授權條款。
    • +
+ +

測試方式

+ + + +

公共政策制定者：需要的工作

+ +
    +
  • 制定要求原始碼必須採用開放原始碼授權的政策。
    • +
  • 制定抑制採購非開放原始碼授權程式碼，與非開放科技的政策。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 只與能採用開放原始碼授權交付、與發行其原始碼的開放原始碼軟體供應商合作。
    • +
  • 請注意，雖然創用CC授權適合用於文件作品，但其中指明「非商業性」或「禁止改作」 +的授權條款，代表「無法」自由重複使用、自由修改、自由再次散布等，因此未能符合規定。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 每當建立新的程式基底時，都要加入新的「license」授權條款檔案。
    • +
  • 每當建立新的原始碼檔案時，都要加入著作權聲明與授權條款標頭內容。
    • +
  • 每當程式基底重複利用原始碼時，都要確認原始碼的授權與程式基底的授權相容。
    • +
+ +

+ +

延伸閱讀

+ +
    +
  • 開放原始碼促進會所發表的《開放原始碼定義》，所有開放原始碼授權條款皆符合這套定義。
    • +
  • 紐西蘭CC Aotearoa《創用CC介紹動畫影 +片》。
    • +
  • 歐洲自由軟體基金會所發表的《REUSE 倡議規範》，提供規範明確、人類可讀以及機器可讀的著作權與 +授權資訊。
    • +
  • Linux 基金會所發表的 SPDX 授權條款清單，提供經標準化、且機器可讀的大多數授權條款縮寫表示 +法。
    • +
+ +
+ +
+

程式基底可查詢得到

+ +

一旦程式基底越容易被發現，更多的潛在協作者也就找得到它。不能只是發表個程式基底，然後就盼望他人找得到這套程式基 +底，更需要主動積極。

+ +

有中介資料說明檔的話，會讓程式基底更容易被發現。良好且包含永久唯一識別碼的中介資料，例如寫成 Wikidata 維基數據條目，或是放到 FSF 自由軟體基金會的軟體 +目錄列表之中（使程式基底成為語意網路中的一部份），他人就能更容易透過第三方工具參考、引用、辨別、發現程式基底。

+ +

需求規定

+ +
    +
  • 程式基底名稱「應該」要能描述說明其用途，且不包含任何首字母縮寫字、縮寫、雙關語，或組織單位品牌名稱或抬頭等。
    • +
  • 程式基底說明「應該」要簡短，幫助他人瞭解程式基底的目的與作用。
    • +
  • 維護人員「應該」將程式基底提交至相關的軟體目錄上。
    • +
  • 程式基底「應該」要架設網站，內容中以程式基底各類潛在使用者（技術人員、政策專家、管理人員等）偏好的業內用語，描述程式基底所能解決的問題。
    • +
  • 在搜尋引擎查找程式基底名稱時，「應該」能搜尋得到程式基底。
    • +
  • 在使用搜尋引擎時，如果以自然語言描述程式基底所能解決的問題，「應該」能搜尋得到程式基底。
    • +
  • 程式基底「應該」具備永久唯一識別碼，而且該項條目要提及主要貢獻者、儲存庫、位置、網站等。
    • +
  • 程式基底「應該」包含機器可讀的中介資料說明，例如採用 +publiccode.yml格式的檔案。
    • +
  • 「可選擇」是否為程式基底設置專用的網域名稱。
    • +
  • 「可選擇」是否在社群舉辦的會議中定期進行簡報。
    • +
+ +

測試方式

+ +
    +
  • 檢查程式基底名稱是否描述說明其用途，且不包含雙關語。
    • +
  • 檢查程式基底名稱是否不包含任何首字母縮寫字或縮寫，或是其首字母縮寫字或縮寫比完整名稱更熟為人知。
    • +
  • 檢查程式基底是否不包含組織單位品牌名稱或抬頭等，除非該組織單位也是程式基底社群成員。
    • +
  • 檢查程式基底儲存庫是否包含程式基底的簡短描述。
    • +
  • 檢查程式基底有刊登在相關軟體型錄上。
    • +
  • 檢查程式基底的網站有描述程式基底能夠解決的問題。
    • +
  • 檢查以程式基底名稱來作搜尋時，有超過一個的常用主流搜尋引擎，都有將程式基底列在搜尋結果中。
    • +
  • 檢查以自然語言來作搜尋，例如使用程式基底的簡短描述時，有超過一個的常用主流搜尋引擎，都將程式基底放在搜尋結果中。
    • +
  • 檢查永久唯一識別碼條目有提及主要貢獻者。
    • +
  • 檢查永久唯一識別碼條目中有包含儲存庫位置。
    • +
  • 檢查永久唯一識別碼條目有列出程式基底網站。
    • +
  • 檢查中介資料說明檔是機器可讀的格式。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 貢獻一段說明此程式基底作用的政策領域，或所處理問題的描述。
    • +
  • 請那些對程式基底不熟悉且不同領域背景的同事，來測試您的問題描述。
    • +
  • 在相關會議上作簡報，介紹程式基底如何執行政策。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 在決定專案名稱之前，先搜尋過商標資料庫，以避免名稱造成混淆或侵權的問題。
    • +
  • 在引用到程式基底的地方，都使用簡短描述，例如放到社交媒體帳號中的說明。
    • +
  • 為團隊編列內容設計與實作 SEO 搜尋引擎最佳化技能的預算。
    • +
  • 確保專案參與人員出席相關會議，或作簡報介紹。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 實作搜尋引擎最佳化，例如加入網站地圖。
    • +
  • 在引用到程式基底的地方，都使用簡短描述，例如放到儲存庫中的說明。
    • +
  • 請那些對程式基底不熟悉且不同領域背景的同事，來測試您的問題描述。
    • +
  • 推薦適合出席或作簡報介紹的會議，並且在這些會議中出席或作簡報。
    • +
+ +

+ +

延伸閱讀

+ +
    +
  • Wikidata 維基數據社群《維基數據簡 +介》。
    • +
  • FSF 自由軟體基金會《FSF 軟體目錄列表》。
    • +
  • GO FAIR 國際支援與合作辦公室所撰寫的《FAIR 科學資料管理與監督指導原 +則》，提供一份滿好的特性清單，解說哪些特性會讓資料（或中介資料）更容易讓 +機器採取行動（也因此更容易被找到）。其中的部分特性可直接套用到程式基底上，而其他無法直接套用的，我們還需要再研究程式基底與其對應的特性要怎麼處理。
    • +
+ +
+ +
+

風格要前後一致

+ +

採用前後一致的風格，讓不同環境的貢獻者能夠一同合作。用詞統一能減少貢獻者之間在溝通上的摩擦。

+ +

需求規定

+ +
    +
  • 程式基底「必須」遵守程式碼撰寫風格指引、或文件寫作風格指引，可以是程式基底社群自身的風格指引，或是程式基底 +有採用的既有風格。
    • +
  • 貢獻內容「應該」通過自動化的風格測試。
    • +
  • 風格指引「應該」描述對於較複雜的程式碼區段，如何作列內註解與為其寫下說明文件的期待。
    • +
  • 「可選擇」是否將可理解的白話英語期望加入風格指引之中。
    • +
+ +

測試方式

+ +
    +
  • 確認貢獻內容有遵循文件中指定的風格指引。
    • +
  • 檢查是否有自動化的風格測試。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 為政策與文件建立風格指引，遵守並且持續改善，同時記錄到程式基底文件中，像是「CONTRIBUTING」或 +「README」檔案。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 將書面語言、原始碼、測試、政策標準等，包含在貴組織單位對品質的定義當中。
    • +
+ +

開發人員與設計師：需要的工作

+ +

如果程式基底還沒有工程指引，或其他貢獻者指引，則請先在儲存庫中加入相關文件，像是 +「CONTRIBUTING」或「README」檔案，並描述目前在設立指引方面的進展。上述檔案的重要目的之一，在於宣達設計偏好、命名規則，以及機器不容易檢查 +的其他層面。指引應該包含貢獻的原始碼預期該符合哪些要求，才會被維護人員合併至程式基底中，包括原始碼、測 +試、文件等項目。請持續改善與擴充這份文件內容，目標讓文件朝向工程指引演進。

+ +

此外：

+ +
    +
  • 使用 linter 程式碼品質梳理工具。
    • +
  • 在程式基底中加入 linter 梳理工具的組態設定。
    • +
+ +

延伸閱讀

+ + + +
+ +
+

記錄程式基底成熟度

+ +

清楚標示程式基底的成熟度，有助於他人決定是否要使用，或為該程式基底做出貢獻。程式基底版本的成熟度，包含其依賴項 +目的成熟度。瞭解程式基底演進到什麼程度，是理解該程式基底並知道如何做出貢獻的關鍵。

+ +

需求規定

+ +
    +
  • 程式基底「必須」註明版本編號。
    • +
  • 程式基底「必須」明確以文件記錄，是否有已經準備好可供使用的版本。
    • +
  • 準備好可供使用的程式基底版本，「必須」只能依賴其他也已經準備好可供使用的程式基底版本。
    • +
  • 程式基底「應該」包含每次版本的變動紀錄，像是以「CHANGELOG」日誌格式檔記錄。
    • +
  • 「應該」要以文件記錄分配版本識別碼的方法。
    • +
  • 「可選擇」是否採用語意化版本控制編號。
    • +
+ +

測試方式

+ +
    +
  • 確認程式基底有版本編號策略，且有文件記載該策略。
    • +
  • 確認政策制定者、管理人員、開發人員與設計師等，都能清楚知道程式基底是否有準備好可供使用的版本。
    • +
  • 確認準備好可供使用的程式基底版本，並不依賴任何尚未準備好可供使用的其他程式基底的版本。
    • +
  • 確認有文件記錄程式基底的版本編號方法，並且確實遵守。
    • +
  • 確認是否有版本的變動紀錄。
    • +
+ +

公共政策制定者：需要的工作

+ +
    +
  • 制定政策時，請記住任何開發出來的原始碼都必須先經過 +測試與改善，才能夠投入服務。
    • +
  • 考慮將政策的變動註明版本編號，尤其是因而觸發新版本原始碼開發的情況。
    • +
+ +

管理人員：需要的工作

+ +
    +
  • 要確認服務依賴的程式基底版本成熟度，等同或高於該服務本身。舉例來說，正式上線的服務不要使用 beta 公測版程式基底。
    • +
+ +

開發人員與設計師：需要的工作

+ +
    +
  • 確認所有發行版，都有遵守程式基底的版本控制編號作法。
    • +
+ +

延伸閱讀

+ + + +
+ + +
+ +

貢獻此標準

+ + + + +

🙇‍♀️ 感謝您的貢獻！

+ +

我們理解這樣的標準，只有在盡可能與公共技術人員、政策制定者，以及有興趣的人士協作下才能完成。因此，我們很感謝您的意見，樂意得到回饋，以及歡迎提供改善此專案的建議。我 +們非常開放任何合作的機會。

+ +

我們歡迎每個人提出的議題，以及拉取請求。如果您不大習慣 GitHub ，也歡迎將意見回饋用電子郵件寄送到 +info@publiccode.net。

+ +

問題、建議與議題等

+ +

在發展路線圖中可查看我們勾勒的精要概覽。歡迎回報問題、建議修改，以及發問等，來協助發展。您可以到 Standard +for Public Code 的 GitHub +Issue 頁面中，為本專案提出 GitHub 議 +題。

+ +

或者，註冊加入郵遞論壇列 +表， +並寄送電子郵件到standard@lists.publiccode.net。

+ +

您不一定要修改我們的程式碼或文件，也能成為貢獻者！

+ +

為文件與程式碼提出拉取請求

+ +

如果您想要在我們的專案中，為文件或程式碼加入新內容，您應該提出拉取請求 (Pull Request，亦可簡稱 PR)。

+ +

若您從未使用過 GitHub，歡迎先認識 GitHub 作業流 +程，或是參加 GitHub +Skills 免費且優質的互動式課程，當中會介紹該如何使用 GitHub 以及 MarkDown 語法。 +MarkDown 是本專案文件所採用的撰寫語法。

+ +

本專案採用創用CC 0 1.0 通用式公眾領域貢獻宣告給予授權；這本質上代表本專案，以及您所做出的貢獻，在無論何種司法管轄情況下，都屬於公眾領域，也就是任何人都可以 +任意使用。

+ +

1. 作出您的修改

+ +

貢獻內容應該遵守《公共程式標準》自身所列出的準則規定。審查人員同時也會確保貢獻內容，符合 +公共程式的價值。此外，他們也會審查貢獻是否遵循標 +準，且與整體作品有所連貫。

+ +

本專案使用 GitFlow 分支與工作流程。 +當您對此儲存庫作分支以後，請務必依照 GitFlow 模型建立新功能分支。

+ +

將您所作的變更內容加入送交版次，並附上內容說 +明。如果需要作 +出多種類型的變更，請將相關變更依據邏輯分類，不同類型各自放在不同的送交版次中。例如：修正空白、以及文字內容更動，兩者應該放在不同的送交版次中。當新增檔案時，請選用 +容易以「diff 」檢視的檔案格式，如「.svg 」格式就勝過二進位影像。在送交版次訊息中，請記錄您所作的選擇與決策，如此未來其他人都能知道您當時的抉 +擇。

+ +

如果您是要新增程式碼，請確保您有新增與更新相關文件與測試項目，之後再提交您的拉取請求。請務必撰寫可以展示新增或修改後程式碼行為的測試項目。

+ +

適用政策

+ +

就目前而言，《公共程式標準》並非在執行任何特定的公共政策。

+ +

風格

+ +

《公共程式標準》目標使用白話的英語，而拼字採用美式英文。文字內容基本上以每句一行為原則，沒有文繞圖 +換行，來讓「diff」輸出更容易檢視。然而，我們想要強調更重要的是，您應該專注在貢獻內容上，而不是擔心拼字與排版。我們的審查流程會協助修正這一部分，也會另外再次檢查品質才推出新發行版本。

+ +

遵守的標準

+ +

這些是《公共程式標準》所採用的標準。請確保您的貢獻內容也遵守這些標準，才會更容易合併。

+ + + +

2. 拉取請求

+ +

當您提出拉取請求時，請隨附描述您想要解決的問題，以及該拉取請求所能修正的議題編號。以一個拉取請求處理單一項議題為佳。若一組變動能同時解決多項議題，則請列出所有能一併 +修正的議題編號。

+ +

3. 改善

+ +

所有貢獻都必須接受審查。Foundation for Public Code 致力於確保有維護人員能審查貢獻內容，目標是在兩個工作日內提供意見回饋。

+ +

維護人員有時候可以立即合併您的貢獻內容。不過一般來說，新的拉取請求通常需要再經過改善後，才能夠合併。其他貢獻者（或是輔助用機器人）可能會提供意見回饋。若是如此，負責 +審查您貢獻內容的維護人員，將協助您改善文件與程式碼。

+ +

一旦您的文件與程式碼通過人工審查，就會合併。

+ +

4. 慶祝

+ +

您的構想、文件與程式碼，已成為本專案的一部份。您就是我們需要的開放原始碼英雄！

+ +

誠摯歡迎您提出拉取請求，將您的名字加到 AUTHORS 檔案中，讓您所做的貢獻能銘記在本專案中。

+ +

翻譯成其他語言

+ +

《公共程式標準》沒有官方版本的翻譯，您仍可以協助本標準維護已有的社群翻譯，或是新增翻譯。

+ +

發行版本

+ +

我們有提供發行新版本，與訂購印刷版標準的專用詳細文件。

+ +

若要進一步瞭解如何使用，以及協助貢獻本專案，請參閱 README 。

+ + +
+ +
+ collaborative-development +
+ +
+ +

行為守則

+ + + + +

社群很多成員來自有行為守則的公民社會或專業背景，但有些人並非如此。本文件表達基金會對於所有社群成員，以及所有互動間的期望，無論互動是透過何種溝通管道。

+ +

來到這裡來是為了協作。

+ +

請對彼此體貼、尊重，以及有耐心。

+ +

努力做出有建設性的行為。

+ +

若有問題需要提出，請寄送電子郵件到 directors@publiccode.net。

+ + +
+ +
+ collaboration +
+ +
+ +

治理方式

+ +

本標準是 Foundation for Public Code 在為程式基底提供督導時的核心。我們依照這份文件來判斷，某個程式基底是否已經準備好讓社群共同參與開發。

+ +

這份標準由 Foundation for Public Code 職員負責維護。

+ +

我們歡迎任何人貢獻，例如提供修改建議，或是給予一般意見回饋等。

+ +

由於《公共程式標準》在我們的核心流程中，扮演至關重要的角色，所以我們會以《公共程式標準》的最高標準作要求。

+ +

我們會努力儘速回覆所有拉取請求。拉取請求使我們有機會一起合作，來改善我們的方法與這份標準。我們有可能不會接受貢獻者提出的所有修改，而我們會解釋背後的邏輯。

+ + +
+ +
+ ecosystem +
+ +
+ +

版本歷史

+ +

0.7.1 版

+ +

2023/07/31: 💄 第十六版草稿修改準則名稱，並釐清程式 code 的稱呼。

+ +
    +
  • 〈程式碼要可重複使用且可攜〉準則改名為〈程式基底要可重複使用且可移植〉。
    • +
  • 新增詞彙條目「原始碼」。
    • +
  • 對於只適用於「原始碼」意義的「程式 (code)」，現在明確以「原始碼」稱呼。
    • +
  • 將「運作的程式碼」釐清稱為「軟體」。
    • +
  • 細微修改以清楚區分「程式碼」與「程式基底」。
    • +
  • 簡化給政策制定者在〈政策與原始碼要合捆〉中的指引。
    • +
  • 釐清〈程式基底可查詢得到〉與〈程式基底要可重複使用且可移植〉的「測試方式」小節。
    • +
  • 在發行成品前的要求中，加入準則與需求規定檢查清單。
    • +
  • 提升發行流程的自動化程度。
    • +
+ +

0.7.0 版

+ +

2023年5月31日：📑第十五版新增紀錄募資審查的新規定，並釐清審查流程規定。

+ +
    +
  • 新增規定，記錄預期由何者負擔審核貢獻內容所需的開銷費用。
    • +
  • 新增規定，程式基底必須要有簡短說明。
    • +
  • 原先專注在貢獻內容是否遵循標準，現在則改為注重貢獻內容的審查。
    • +
  • 將〈程式基底可查詢得到〉中許多「必須」等級的規定，調降為「應該」等級。
    • +
  • 審查範本現在有 HTML 格式。
    • +
  • 「前言」轉換為「序文」。
    • +
  • 改善貢獻指引。
    • +
  • 改善命令稿文件紀錄。
    • +
+ +

0.6.0 版

+ +

2023年4月20日：🔀第十四版草稿新增可移植性與測試的規定，並且每個準則都有一段前言。

+ +
    +
  • 新增規定，在〈程式碼要可重複使用且可攜〉加入多方協作開發的內容。
    • +
  • 新增規定，在〈程式碼要可重複使用且可攜〉中加入依賴單一供應商的內容。
    • +
  • 新增規定，在〈使用持續整合〉中加入要發布自動化測試結果的內容。
    • +
  • 對安全性區分出兩項規定，一是要有提供方法，另一個是要有文件紀錄。
    • +
  • 重新撰寫規定，將焦點放在程式基底，而非貢獻者行為。
    • +
  • 移除「此措施辦不到的事」以及「此措施為何重要」兩個小節，改換成在每項準則中加入前言。
    • +
  • 在本標準前言中，加入通用的「此措施辦不到的事」小節。
    • +
  • 為政策制定者加入相關政策與授權相容性的指引。
    • +
  • 為開發人員與設計師新增檔案要有版本控制的相關指引。
    • +
  • 為開發人員與設計師釐清有關快速回應，以及搜尋引擎最佳化的內容。
    • +
  • 新增可近用性無障礙環境的「延伸閱讀」內容。
    • +
  • 將各準則的連結與其名稱連動。
    • +
  • 改善網頁版的導覽功能。
    • +
  • 已將「延伸閱讀」小節的工具移到社群實踐指引。
    • +
  • 將標準依循或認證相關流程移到 publiccode.net。
    • +
  • 變更審查範本格式，讓範本在發行新版後更容易更新。
    • +
  • 改善著陸引導頁文字，加入相關資源的連結。
    • +
  • 新增拼字檢查自動化測試。
    • +
  • 微調文字，讓內容更明確與一致。
    • +
  • 將 SPDX 標頭換成 yaml 標頭。
    • +
+ +

0.5.0 版

+ +

2023年1月25日：🎨第十三版草稿焦點著重在文件紀錄風格指引。

+ +
    +
  • 調整程式碼撰寫風格要求，專注於程式基底上，而非貢獻者行為。
    • +
  • 將程式基底名稱規定，從〈使用白話的英文〉移到〈程式基底可查詢得到〉。
    • +
  • 將測試程式碼的規定，從〈程式碼要有文件〉移到〈使用持續整合〉。
    • +
  • 劃分機器可讀的測試標準規定，指明程式碼的開放性比可測試性更重要。
    • +
  • 調整可查找性的測試規定，降低對搜尋引擎演算法的依賴。
    • +
  • 微調文字，讓內容更明確與一致。
    • +
+ +

0.4.1 版

+ +

2022年12月5日：📝第十二版草稿指出要以文件記錄成熟度。

+ +
    +
  • 寫下成熟度著重於程式基底是否已經可供使用，更甚於版本編號。
    • +
  • 寫下成熟度不再需要為尚未準備好可供使用的程式基底加上特定標籤。
    • +
  • 稽核流程圖現在以更容易轉譯的格式生成。
    • +
  • 改善「測試方式」指引。
    • +
  • 新增 publiccode.yml 檔案。
    • +
  • 新增審查範本。
    • +
  • 一致性連結詞彙表。
    • +
  • 在「CONTRIBUTING」中加入要遵循的實務與標準。
    • +
  • 將 Matti Schneider 加入作者群。
    • +
  • 將剩餘 SPDX 標頭加入檔案中。
    • +
  • 再稍微修改些文字，讓文字更明確。
    • +
  • 更新部分超連結。
    • +
  • 將範例移動到《社群實踐指 +引》。
    • +
+ +

0.4.0 版

+ +

2022年9月7日：🔭第十一版草稿新增可查找性準則。

+ +
    +
  • 導入新準則：程式基底可查詢得到。
    • +
  • 改善多數準則的「測試方式」小節。
    • +
  • 在〈歡迎貢獻者〉中加入發布活動統計的新規定。
    • +
  • 移除可重複使用與移植的程式碼中多餘的規定。
    • +
  • 在開放授權的定義中，加入 OSI 與 FSF 所批准的授權。
    • +
  • 重新編寫「得以」等級的相關規定，加入使用「可選擇」這個關鍵字，讓規定更明確。
    • +
  • 表達《公共程式標準》應該盡可能符合其自身規定的立場，並加入評估措施。
    • +
  • 將 SPDX 授權識別碼加入檔案中。
    • +
  • 導入新的行為守則。
    • +
  • 解釋原始碼與政策內文的差異。
    • +
  • 將規定重新調整為項目要點清單格式。
    • +
  • 告知程式基底成熟度對於重複使用時的重要性。
    • +
  • 將可查找性相關規定移動到新準則中。
    • +
  • 釐清非開放標準在程式基底中的角色。
    • +
  • 加入組建日期與執行時期依賴項目的額外指引。
    • +
  • 新增《公共程式標準》的發展路線圖。
    • +
  • 更新 Authors 檔案的結構。
    • +
  • 將唐鳳加入作者群。
    • +
  • 將準則列表加到印刷版本中。
    • +
  • 釐清標準對於政策制定者、管理人員、開發人員與設計師等不同身分間的意義。
    • +
  • 再稍微修改些文字，讓文字更明確。
    • +
  • 更新部分超連結。
    • +
+ +

0.3.0 版

+ +

2022年5月23日：🗎第十版草稿加強文件紀錄與在地化內容。

+ +
    +
  • 在〈程式碼要可重複使用且可攜〉中定下明確的在地化規定。
    • +
  • 以文件記錄治理方式的規定，從「應該」等級調升為「必須」。
    • +
  • 在貢獻指引中，將非常主觀（且難以驗證）的「貢獻內容『必須』小」的規定，改為必須紀錄貢獻所要完成的期待，並一次專注在單一議題上。
    • +
  • 社群翻譯連結現在已放到頁尾中。
    • +
  • 還原「用 Mermaid 流程圖取代業務流程 BPMN svg」。
    • +
  • 細微調整用詞，讓句子更簡單。
    • +
  • 更新部分超連結。
    • +
+ +

0.2.3 版

+ +

2022年3月15日：📜第九版草稿允許缺少官方翻譯的政策，改為提供政策的英文版摘要。

+ +
    +
  • 放寬〈使用白話的英文〉準則，加入新規定，允許合捆的政策內文如果沒有英文版，只需要加入英文版摘要，而不用翻譯全文。
    • +
  • 同樣地，在〈政策與原始碼要合捆〉中，沒有英文版的政策內文可允許提供英文版摘要。
    • +
  • 釐清〈政策與原始碼要合捆〉中，「政策」包含能影響開發與部署的流程。
    • +
  • 在〈程式碼要可重複使用且可攜〉中強調解決方案部分內容的可重複使用性。
    • +
  • 將〈程式碼要可重複使用且可攜〉當中的開發人員與設計師指引，加入部署到專有平台上的內容。
    • +
  • 在〈使用白話的英文〉中，加入管理層在面對非英語詞彙時需要做的事的提點。
    • +
  • 變更拉取請求流程圖，從業務流程 BPMN 改用 Mermaid，來讓社群翻 +譯更容易。
    • +
  • 將 Maurice Hendriks 加入作者群。
    • +
  • 將「OpenApi 規格」加入延伸閱讀。
    • +
  • 將延伸閱讀小節的特性變得更明確。
    • +
  • 再稍微修改些文字，讓文字更明確。
    • +
+ +

0.2.2 版

+ +

2021年11月29日：🏛第八版草稿認知程式碼所執行的政策，不一定是英文。

+ +
    +
  • 在「所有程式碼都必須使用英語編寫」規定中，雖然政策也算是一種程式 (code)，但可以保有例外。
    • +
  • 在〈維護版本控制〉中，新增與送交者電子郵件相關的「得以」規定。
    • +
  • 將政策制定者加入〈政策與原始碼要合捆〉指引中。
    • +
  • 將開發人員與設計師加入「風格要前後一致」指引中。
    • +
  • 新增「不同情境」到詞彙表中。
    • +
  • 將 Mauko Quiroga 與 Charlotte Heikendorf 加入 AUTHORS。
    • +
  • 新增「數位公共財」認可標章。
    • +
  • 為「準則」頁面網頁版加入「上一頁」與「下一頁」連結。
    • +
  • 將「開放標準」原則加入延伸閱讀。
    • +
  • 將「白話語言定義」加入延伸閱讀。
    • +
  • 將「語意化版本編號規範」移動為延伸閱讀參考內容。
    • +
  • 指出 publiccode.yml 是機器可讀中介資料說明的範例之一。
    • +
  • 將「您的程式基底」與「您的組織單位」改為較不具有所有格的寫法。
    • +
  • 再稍微修改些文字，讓文字更明確。
    • +
  • 新增印刷版的製作指示。
    • +
+ +

0.2.1 版

+ +

2021年3月1日：🧽第七版草稿是 0.2.0 版後的些微清理改善。

+ +
    +
  • 新增使用分散式版本控制系統的相關「應該」規定，並解釋分散式的重要性。
    • +
  • 針對未被採用的貢獻需要給予回饋，規定要比被接受的貢獻更加嚴格。
    • +
  • 明確指出著作權與授權聲明也應該要機器可讀。
    • +
  • 聲明是否為機器可讀的測試方式建議。
    • +
  • 釐清滾動發行的指引。
    • +
  • 釐清詞彙表中「版本控制」的定義。
    • +
  • 新增鼓勵貢獻、SPDX、Git 以及審查貢獻等的延伸閱讀項目。
    • +
  • 新增有關公共程式概念的影片連結。
    • +
  • 更新業務流程 BPMN 連結。
    • +
  • 減少重複連結。
    • +
  • 將 Alba Roza 與 Ngô Ngọc Đức Huy 加入作者群。
    • +
  • 再稍微修改些文字，讓文字更明確。
    • +
+ +

0.2.0 版

+ +

2020年10月26日：🎊第六版草稿拆分出一項新規定並且釐清內容。

+ +
    +
  • 將〈歡迎貢獻〉準則拆分為〈貢獻要容易〉以及〈歡迎貢獻者〉。
    • +
  • 將〈注意程式基底成熟度〉準則改名為〈記錄程式基底成熟度〉。
    • +
  • 針對多方使用的程式基底，將「必須」等級規定調降為「應該」。
    • +
  • 針對著作權轉讓，新增「禁止」規定。
    • +
  • 在可重複使用程式碼的規定中，釐清組態設定的角色。
    • +
  • 新增詞彙：持續整合、政策、儲存庫、版本控制等。
    • +
  • 將「城市」替換成「公家機關」。
    • +
  • 將貢獻者與審查人員規定分開為不同項目，以釐清程式碼中較敏感性的層面。
    • +
  • 將政策制定者、開發人員與設計師加入延伸閱讀與指引中。
    • +
  • 將 Felix Faassen 與 Arnout Engelen 加入作者群。
    • +
  • 再稍微修改些文字，讓文字更明確。
    • +
+ +

0.1.4 版

+ +

2019年11月27日：🧹第五版草稿主要是一些細部修正。

+ +
    +
  • 連結 License.md 檔案。
    • +
  • 將 Sky Bristol、Marcus Klaas de Vries 與 Jan Ainali 加入作者群。
    • +
  • 讓標點符號使用更一致，特別是項目符號列表。
    • +
  • 細部調整文字，讓內容更明確。
    • +
+ +

0.1.3 版

+ +

2019年10月8日：🍂第四版草稿僅針對秋季所作的清理修正一些小地方

+ +
    +
  • 將「持續交付」改名為「持續整合」。
    • +
  • 在語言標準中引用無障礙指導原則。
    • +
  • 改善一些樣式，與一致性修正。
    • +
+ +

0.1.2 版

+ +

2019年8月22日：🌠第三版草稿專注在提升文字品質，並且納入社群意見

+ +
    +
  • 有好幾位很棒的新貢獻者加入我們的作者群名單，讓氣象一新。
    • +
  • 所有連結都是 HTTPS。
    • +
  • 一般校對、釐清用字淺詞、修正拼字錯誤等。
    • +
  • 更新準則： +
      +
    • 在不同情境背景下重複使用的規定
      • +
    • 明確的版本控制建議
      • +
    • 多方部署的建議
      • +
    • 檔案授權標頭的建議
      • +
    • 漏洞回報的建議
      • +
    • 明確以文件記錄治理方式的建議
      • +
    +
    • +
+ +

0.1.1 版

+ +

2019年5月9日：🤔第二版草稿修正一些基本的疏漏，以及許多拼字錯誤

+ +
    +
  • 移除出現「Foundation for Public Code」的地方，我們之後可能必須改名才能成為協會。
    • +
  • 更新簡介。
    • +
  • 更新詞彙表。
    • +
  • 新增行為守則。
    • +
  • 我們建議使用 publiccode.yml 標準，方便重複使用。
    • +
+ +

0.1.0 版

+ +

2019年4月16日：🎉初版草稿已準備就緒，全新內容，而且有許多有趣的新穎理念

+ +
    +
  • 14 項準則，有各自的規定，以及相關的實施方式。
    • +
  • 精要的背景介紹，例如本標準是什麼，以及 Foundation for Public Code 如何使用此標準。
    • +
+ +

最初的版本是由阿姆斯特丹應用科學大學、阿姆斯特丹市政府，以及本基金會合作撰寫，取自 Smart Cities? Public Code! 專 +案 的部分內容。

+ + +
+ +
+ +

This license is the legal contract that allows anyone to do anything they like with the content in this entire document.

+

CC0 1.0 Universal

+ 
Creative Commons Legal Code
+
+CC0 1.0 Universal
+
+    CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE
+    LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN
+    ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS
+    INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES
+    REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS
+    PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM
+    THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED
+    HEREUNDER.
+
+Statement of Purpose
+
+The laws of most jurisdictions throughout the world automatically confer
+exclusive Copyright and Related Rights (defined below) upon the creator
+and subsequent owner(s) (each and all, an "owner") of an original work of
+authorship and/or a database (each, a "Work").
+
+Certain owners wish to permanently relinquish those rights to a Work for
+the purpose of contributing to a commons of creative, cultural and
+scientific works ("Commons") that the public can reliably and without fear
+of later claims of infringement build upon, modify, incorporate in other
+works, reuse and redistribute as freely as possible in any form whatsoever
+and for any purposes, including without limitation commercial purposes.
+These owners may contribute to the Commons to promote the ideal of a free
+culture and the further production of creative, cultural and scientific
+works, or to gain reputation or greater distribution for their Work in
+part through the use and efforts of others.
+
+For these and/or other purposes and motivations, and without any
+expectation of additional consideration or compensation, the person
+associating CC0 with a Work (the "Affirmer"), to the extent that he or she
+is an owner of Copyright and Related Rights in the Work, voluntarily
+elects to apply CC0 to the Work and publicly distribute the Work under its
+terms, with knowledge of his or her Copyright and Related Rights in the
+Work and the meaning and intended legal effect of CC0 on those rights.
+
+1. Copyright and Related Rights. A Work made available under CC0 may be
+protected by copyright and related or neighboring rights ("Copyright and
+Related Rights"). Copyright and Related Rights include, but are not
+limited to, the following:
+
+  i. the right to reproduce, adapt, distribute, perform, display,
+     communicate, and translate a Work;
+ ii. moral rights retained by the original author(s) and/or performer(s);
+iii. publicity and privacy rights pertaining to a person's image or
+     likeness depicted in a Work;
+ iv. rights protecting against unfair competition in regards to a Work,
+     subject to the limitations in paragraph 4(a), below;
+  v. rights protecting the extraction, dissemination, use and reuse of data
+     in a Work;
+ vi. database rights (such as those arising under Directive 96/9/EC of the
+     European Parliament and of the Council of 11 March 1996 on the legal
+     protection of databases, and under any national implementation
+     thereof, including any amended or successor version of such
+     directive); and
+vii. other similar, equivalent or corresponding rights throughout the
+     world based on applicable law or treaty, and any national
+     implementations thereof.
+
+2. Waiver. To the greatest extent permitted by, but not in contravention
+of, applicable law, Affirmer hereby overtly, fully, permanently,
+irrevocably and unconditionally waives, abandons, and surrenders all of
+Affirmer's Copyright and Related Rights and associated claims and causes
+of action, whether now known or unknown (including existing as well as
+future claims and causes of action), in the Work (i) in all territories
+worldwide, (ii) for the maximum duration provided by applicable law or
+treaty (including future time extensions), (iii) in any current or future
+medium and for any number of copies, and (iv) for any purpose whatsoever,
+including without limitation commercial, advertising or promotional
+purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each
+member of the public at large and to the detriment of Affirmer's heirs and
+successors, fully intending that such Waiver shall not be subject to
+revocation, rescission, cancellation, termination, or any other legal or
+equitable action to disrupt the quiet enjoyment of the Work by the public
+as contemplated by Affirmer's express Statement of Purpose.
+
+3. Public License Fallback. Should any part of the Waiver for any reason
+be judged legally invalid or ineffective under applicable law, then the
+Waiver shall be preserved to the maximum extent permitted taking into
+account Affirmer's express Statement of Purpose. In addition, to the
+extent the Waiver is so judged Affirmer hereby grants to each affected
+person a royalty-free, non transferable, non sublicensable, non exclusive,
+irrevocable and unconditional license to exercise Affirmer's Copyright and
+Related Rights in the Work (i) in all territories worldwide, (ii) for the
+maximum duration provided by applicable law or treaty (including future
+time extensions), (iii) in any current or future medium and for any number
+of copies, and (iv) for any purpose whatsoever, including without
+limitation commercial, advertising or promotional purposes (the
+"License"). The License shall be deemed effective as of the date CC0 was
+applied by Affirmer to the Work. Should any part of the License for any
+reason be judged legally invalid or ineffective under applicable law, such
+partial invalidity or ineffectiveness shall not invalidate the remainder
+of the License, and in such case Affirmer hereby affirms that he or she
+will not (i) exercise any of his or her remaining Copyright and Related
+Rights in the Work or (ii) assert any associated claims and causes of
+action with respect to the Work, in either case contrary to Affirmer's
+express Statement of Purpose.
+
+4. Limitations and Disclaimers.
+
+ a. No trademark or patent rights held by Affirmer are waived, abandoned,
+    surrendered, licensed or otherwise affected by this document.
+ b. Affirmer offers the Work as-is and makes no representations or
+    warranties of any kind concerning the Work, express, implied,
+    statutory or otherwise, including without limitation warranties of
+    title, merchantability, fitness for a particular purpose, non
+    infringement, or the absence of latent or other defects, accuracy, or
+    the present or absence of errors, whether or not discoverable, all to
+    the greatest extent permissible under applicable law.
+ c. Affirmer disclaims responsibility for clearing rights of other persons
+    that may apply to the Work or any use thereof, including without
+    limitation any person's Copyright and Related Rights in the Work.
+    Further, Affirmer disclaims responsibility for obtaining any necessary
+    consents, permissions or other rights required for any use of the
+    Work.
+ d. Affirmer understands and acknowledges that Creative Commons is not a
+    party to this document and has no duty or obligation with respect to
+    this CC0 or use of the Work.
+
+ +
+ + + diff --git a/_transed.sh b/_transed.sh new file mode 100644 index 00000000..057d9b53 --- /dev/null +++ b/_transed.sh @@ -0,0 +1,5 @@ +mkdir ./criteria +for file in ./criteria_source/*; do + po2md -p ./locales/zh_Hant/LC_MESSAGES/messages.po -s ./criteria/`basename "$file"` $file +done +bundle exec jekyll build diff --git a/criteria/bundle-policy-and-source-code.md b/criteria/bundle-policy-and-source-code.md index 39334f54..3b1d1c32 100644 --- a/criteria/bundle-policy-and-source-code.md +++ b/criteria/bundle-policy-and-source-code.md @@ -5,52 +5,61 @@ order: 2 redirect_from: - criteria/bundle-policy-and-code --- -# Bundle policy and source code -Access to both [source code](../glossary.md#source-code) and [policy](../glossary.md#policy) documentation provides building blocks for anyone to implement the codebase in their local context or contribute to the further development of the [codebase](../glossary.md#codebase). +# 政策與原始碼要合捆 -Understanding the domain and policies within that domain is fundamental to understanding what problems a codebase is trying to solve and how it sets out to solve them. +對於想根據所在情境實作程式基底的人，或是想更進一步貢獻[程式基底](../glossary.md#codebase)開發的人來說，能同時取用[原始 +碼](../glossary.md#source-code)與[政策](../glossary.md#policy)文件兩者，可作為建置成品時的基礎組件。 -To be able to evaluate whether to implement a codebase in a new context, an organization needs to understand what process changes it must choose to make or how to contribute additional configurability to the existing solution in order to adapt it to the new context. +瞭解作用範疇與該範疇的政策是基本原則，才能瞭解程式基底試圖想解決的問題是什麼，以及該如何解決這些問題的作法。 -## Requirements +為了評估是否需要在新的情境中實作程式基底，組織單位需要瞭解必須做出改變的程序有哪些，或是如何對現有解決方案付出額外調整設定，以適應新的情境背景。 -* The codebase MUST include the policy that the source code is based on. -* If a policy is based on source code, that source code MUST be included in the codebase, unless used for fraud detection. -* Policy SHOULD be provided in machine readable and unambiguous formats. -* [Continuous integration](../glossary.md#continuous-integration) tests SHOULD validate that the source code and the policy are executed coherently. +## 需求規定 -## How to test +* 程式基底「必須」包含原始碼所根據的政策。 +* 如果政策根據原始碼而來，則該原始碼「必須」包含在程式基底中，用於偵測詐騙的原始碼則可除外。 +* 政策「應該」採用機器可讀且明確的格式。 +* [持續整合](../glossary.md#continuous-integration)測試「應該」驗證原始碼與政策是否有一致執行。 -* Confirm with a civil servant that all policy that the source code is based on is included. -* Confirm with a civil servant that all source code that the policy is based on is included. -* Check if policy can be interpreted by a machine. -* Check the continuous integration tests for coherent execution of source code and policy pass. +## 測試方式 -## Public policy makers: what you need to do +* 與公務人員確認原始碼所根據的所有政策內容都有收錄在內。 +* 與公務人員確認政策所根據的所有原始碼都有收錄在內。 +* 確認政策內容是否能在機器上解讀。 +* 確認原始碼與政策間的執行一致性能通過持續整合測試。 -* Collaborate with developers and designers to make sure there is no mismatch between policy code and source code. -* Provide the relevant policy texts for inclusion in the [repository](../glossary.md#repository); if the text is not available in English, also provide an English summary. Be sure to include standards that your organization has chosen to adhere to and any organizational processes which impact the development or the deployment context of the codebase for your organization. -* Provide references and links to texts which support the policies. -* Document policy in formats that are unambiguous and machine-readable, such as those published by the [Object Management Group](https://www.omg.org/spec/). -* Track policy with [the same version control](maintain-version-control.md) and documentation used to track source code. -* Check in regularly to understand how the source code in the codebase has changed and whether it still matches the [intentions of the policy](document-codebase-objectives.md). -* Include relevant policies which impact the community, codebase, and development, including legal obligations like the [General Data Protection Regulation](https://eur-lex.europa.eu/eli/reg/2016/679/oj) or the [EU Web Accessibility Directive](https://ec.europa.eu/digital-single-market/en/web-accessibility), or human rights policies, like a public organization's commitment to equal opportunity. +## 公共政策制定者：需要的工作 -## Managers: what you need to do +* 與開發人員及設計師合作，確保政策法規與原始碼之間沒有不相符之處。 +* 提供相關政策內文，以便收錄於[儲存庫](../glossary.md#repository)中；如果政策內文沒有英文版，請提供英文版摘要。務必也同時包含貴組織單 +位所選擇遵守的各項標準，以及影響貴組織單位程式基底開發或部署情境的任何組織單位流程。 +* 請提供政策相關參考資料與連結。 +* 政策內容請使用明確且機器可讀的格式，像是[物件管理群體](https://www.omg.org/spec/)所發表的格式。 +* 追蹤政策時，請使用與追蹤原始碼[相同的版本控制](maintain-version-control.md)與文件。 +* 定期檢查，瞭解程式基底中的原始碼如何變動，以及是否仍然符合[政策意圖](document-codebase-objectives.md)。 +* 納入會影響社會群體、程式基底與開發目標的相關政策，包含 [GDPR 一般資料保護規 +則](https://eur-lex.europa.eu/eli/reg/2016/679/oj)或是[歐盟網頁無障礙命 +令](https://ec.europa.eu/digital-single-market/en/web-accessibility)等此類法律義務，或者是人權政 +策，例如公家機關對機會平等的承諾等。 -* Keep policy makers, developers and designers involved and connected throughout the whole development process. -* Make sure policy makers, developers and designers are working to the same objectives. +## 管理人員：需要的工作 -## Developers and designers: what you need to do +* 讓政策制定者、開發人員與設計師持續參與，並且在整個開發過程中保持聯繫溝通。 +* 確保政策制定者、開發人員與設計師朝相同目標努力。 -* Become familiar with and be able to use the process modelling notation that the policy makers in your organization use. -* Work together with policy makers to make sure there is no mismatch between policy code and source code. -* Give feedback on how to make policy documentation more clear. +## 開發人員與設計師：需要的工作 -## Further reading +* 熟悉並且學會貴組織單位政策制定者所使用的流程模型標記法。 +* 與政策制定者一同合作，確保政策法規與原始碼之間沒有不相符之處。 +* 針對如何讓政策文字更清楚提供意見。 -* [Business Process Model and Notation](https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation) on Wikipedia. -* [BPMN Quick Guide](https://www.bpmnquickguide.com/view-bpmn-quick-guide/) by Trisotech. -* [Decision Model and Notation](https://en.wikipedia.org/wiki/Decision_Model_and_Notation) on Wikipedia. -* [Case Management Model Notation](https://en.wikipedia.org/wiki/CMMN) on Wikipedia. +## 延伸閱讀 + +* 維基百科上的 [BPMN 業務流程模型與標記 +法](https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation)。 +* Trisotech 提供的 [BPMN 快速指 +南](https://www.bpmnquickguide.com/view-bpmn-quick-guide/)。 +* 維基百科上的 [DMN 決策模型與標記 +法](https://en.wikipedia.org/wiki/Decision_Model_and_Notation)。 +* 維基百科上的[ CMMN 案例管理模型標記法](https://en.wikipedia.org/wiki/CMMN)。 diff --git a/criteria/code-in-the-open.md b/criteria/code-in-the-open.md index b325ab2b..86f48c44 100644 --- a/criteria/code-in-the-open.md +++ b/criteria/code-in-the-open.md @@ -3,45 +3,51 @@ # SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS order: 1 --- -# Code in the open +# 原始碼要開放 -Coding in the open improves transparency, increases [source code](../glossary.md#source-code) quality, makes the source code easier to audit, and enables collaboration. +以開放精神編寫原始碼，能改善資訊透明、提高[原始碼](../glossary.md#source-code)品質、讓原始碼更容易稽核，也能促進互相協作。 -Together, this creates more opportunities for citizens to understand how software and [policy](../glossary.md#policy) impact their interactions with a public organization. +這些合在一起，讓公民更有機會瞭解軟體與[政策](../glossary.md#policy)如何影響他們與公家機關的互動。 -## Requirements +## 需求規定 -* All source code for any policy in use (unless used for fraud detection) MUST be published and publicly accessible. -* All source code for any software in use (unless used for fraud detection) MUST be published and publicly accessible. -* The codebase MUST NOT contain sensitive information regarding users, their organization or third parties. -* Any source code not currently in use (such as new versions, proposals or older versions) SHOULD be published. -* Documenting which source code or policy underpins any specific interaction the [general public](../glossary.md#general-public) may have with an organization is OPTIONAL. +* 任何使用中政策的所有原始碼都「必須」要公開（用於偵測詐欺的原始碼除外），且能供民眾取用。 +* 任何使用中軟體的所有原始碼都「必須」要公開（用於偵測詐欺的原始碼除外），且能供民眾取用。 +* 程式基底「禁止」包含與使用者及其組織單位，或與第三方相關的敏感性資訊。 +* 目前非使用中的任何原始碼（像是新版本、提案版本，或較舊版本）都「應該」公開。 +* 「可選擇」是否要以文件記錄[一般大眾](../glossary.md#general-public)與組織單位之間可能發生的任何特定互動，其背後所採用的原始碼或 +支持的政策。 -## How to test +## 測試方式 -* Confirm that the source for each version currently in use is published on the internet where it can be seen from outside the original contributing organization and without the need for any form of authentication or authorization. -* Confirm that the [codebase](../glossary.md#codebase) files and commit history do not include sensitive information. -* Check for the publication of source code not currently in use. +* 確認目前使用中的每個版本都有公布原始碼在網際網路上，而且民眾不需要經過任何形式的身分核對或授權，就能在原始貢獻組織以外，查看這些原始碼。 +* 確認[程式基底](../glossary.md#codebase)檔案與送交版次歷史紀錄，不包含敏感性資訊。 +* 檢查目前非使用中的原始碼是否有公開。 -## Public policy makers: what you need to do +## 公共政策制定者：需要的工作 -* Develop policies in the open. -* Prioritize open and transparent policies. +* 制定合乎開放精神的政策。 +* 以公開透明的政策為優先。 -## Managers: what you need to do +## 管理人員：需要的工作 -* Develop a culture that embraces openness, learning and feedback. -* Collaborate with external vendors and freelancers by working in the open. +* 孕育擁抱開放、重視學習、歡迎意見回饋的文化。 +* 與外部供應商和自由工作者以開放精神的方式協作。 -## Developers and designers: what you need to do +## 開發人員與設計師：需要的工作 -* As a reviewer, for each commit, verify that content does not include sensitive information such as configurations, usernames or passwords, public keys or other real credentials used in production systems. -* Clearly split data and source code, in order to meet the requirement about sensitive information above. +* 審查人員在檢核每次的送交版次紀錄時，要確實核對內容沒有包含組態設定、使用者名稱或密碼、公開金鑰，或其他產品系統中使用的實名憑證等敏感性資訊。 +* 為符合上述敏感性資訊的相關規定，請明確分開資料與原始碼。 -## Further reading +## 延伸閱讀 -* [Coding in the open](https://gds.blog.gov.uk/2012/10/12/coding-in-the-open/) by the UK Government Digital Service. -* [When code should be open or closed](https://www.gov.uk/government/publications/open-source-guidance/when-code-should-be-open-or-closed) by the UK Government Digital Service. -* [Security considerations when coding in the open](https://www.gov.uk/government/publications/open-source-guidance/security-considerations-when-coding-in-the-open) by the UK Government Digital Service. -* [Deploying software regularly](https://www.gov.uk/service-manual/technology/deploying-software-regularly) by the UK Government Digital Service. -* [How GDS uses GitHub](https://gdstechnology.blog.gov.uk/2014/01/27/how-we-use-github/) by the UK Government Digital Service. +* 英國政府數位服務團《[以開放精神編寫原始 +碼](https://gds.blog.gov.uk/2012/10/12/coding-in-the-open/)》。 +* 英國政府數位服務團《[程式碼應該開放或封閉的時 +機](https://www.gov.uk/government/publications/open-source-guidance/when-code-should-be-open-or-closed)》。 +* 英國政府數位服務團《[以開放精神編寫原始碼的資安考 +量](https://www.gov.uk/government/publications/open-source-guidance/security-considerations-when-coding-in-the-open)》。 +* 英國政府數位服務團《[定期部署軟 +體](https://www.gov.uk/service-manual/technology/deploying-software-regularly)》。 +* 英國政府數位服務團《[政府數位服務團如何使用 +GitHub](https://gdstechnology.blog.gov.uk/2014/01/27/how-we-use-github/)》。 diff --git a/criteria/document-codebase-maturity.md b/criteria/document-codebase-maturity.md index bb7a4692..c1f04d75 100644 --- a/criteria/document-codebase-maturity.md +++ b/criteria/document-codebase-maturity.md @@ -6,45 +6,46 @@ redirect_from: - criteria/advertise-maturity - criteria/document-maturity --- -# Document codebase maturity +# 記錄程式基底成熟度 -Clearly signalling a [codebase](../glossary.md#codebase)'s maturity helps others decide whether to use and contribute to it. -A codebase version's maturity includes the maturity of its dependencies. -Understanding how a codebase has evolved is key to understanding the codebase and how to contribute to it. +清楚標示[程式基底](../glossary.md#codebase)的成熟度，有助於他人決定是否要使用，或為該程式基底做出貢獻。程式基底版本的成熟度，包含其依賴項 +目的成熟度。瞭解程式基底演進到什麼程度，是理解該程式基底並知道如何做出貢獻的關鍵。 -## Requirements +## 需求規定 -* The codebase MUST be versioned. -* The codebase MUST prominently document whether or not there are versions of the codebase that are ready to use. -* Codebase versions that are ready to use MUST only depend on versions of other codebases that are also ready to use. -* The codebase SHOULD contain a log of changes from version to version, for example in the `CHANGELOG`. -* The method for assigning version identifiers SHOULD be documented. -* It is OPTIONAL to use semantic versioning. +* 程式基底「必須」註明版本編號。 +* 程式基底「必須」明確以文件記錄，是否有已經準備好可供使用的版本。 +* 準備好可供使用的程式基底版本，「必須」只能依賴其他也已經準備好可供使用的程式基底版本。 +* 程式基底「應該」包含每次版本的變動紀錄，像是以「`CHANGELOG`」日誌格式檔記錄。 +* 「應該」要以文件記錄分配版本識別碼的方法。 +* 「可選擇」是否採用語意化版本控制編號。 -## How to test +## 測試方式 -* Confirm that the codebase has a strategy for versioning which is documented. -* Confirm that it is obvious to policy makers, managers, developers and designers whether the codebase has versions that are ready to use. -* Confirm that ready to use versions of the codebase do not depend on any versions of other codebases that are not ready to use. -* Check that the versioning scheme of the codebase is documented and followed. -* Check that there is a log of changes. +* 確認程式基底有版本編號策略，且有文件記載該策略。 +* 確認政策制定者、管理人員、開發人員與設計師等，都能清楚知道程式基底是否有準備好可供使用的版本。 +* 確認準備好可供使用的程式基底版本，並不依賴任何尚未準備好可供使用的其他程式基底的版本。 +* 確認有文件記錄程式基底的版本編號方法，並且確實遵守。 +* 確認是否有版本的變動紀錄。 -## Public policy makers: what you need to do +## 公共政策制定者：需要的工作 -* When developing [policy](../glossary.md#policy), understand that any [source code](../glossary.md#source-code) developed needs to be tested and improved before it can be put into service. -* Consider versioning policy changes, especially when they trigger new versions of the source code. +* 制定[政策](../glossary.md#policy)時，請記住任何開發出來的[原始碼](../glossary.md#source-code)都必須先經過 +測試與改善，才能夠投入服務。 +* 考慮將政策的變動註明版本編號，尤其是因而觸發新版本原始碼開發的情況。 -## Managers: what you need to do +## 管理人員：需要的工作 -* Make sure that services only rely on versions of codebases of equal or greater maturity than the service. For example, don't use a beta version of a codebase in a production service. +* 要確認服務依賴的程式基底版本成熟度，等同或高於該服務本身。舉例來說，正式上線的服務不要使用 beta 公測版程式基底。 -## Developers and designers: what you need to do +## 開發人員與設計師：需要的工作 -* Make sure that the codebase versioning approach is followed for all releases. +* 確認所有發行版，都有遵守程式基底的版本控制編號作法。 -## Further reading +## 延伸閱讀 -* [Semantic Versioning Specification](https://semver.org/) used by many codebases to label versions. -* [Software release life cycle](https://en.wikipedia.org/wiki/Software_release_life_cycle) -* [Service Design and Delivery Process](https://www.dta.gov.au/help-and-advice/build-and-improve-services/service-design-and-delivery-process) by the Australian Digital Transformation Agency. -* [Service Manual on Agile Delivery](https://www.gov.uk/service-manual/agile-delivery) by the UK Government Digital Service. +* 許多程式基底使用「[語意化版本編號規範](https://semver.org/)」來標示版本。 +* [軟體發行生命週期](https://en.wikipedia.org/wiki/Software_release_life_cycle) +* 澳洲數位轉型局《[服務設計與交付流 +程](https://www.dta.gov.au/help-and-advice/build-and-improve-services/service-design-and-delivery-process)》。 +* 英國政府數位服務團《[敏捷交付服務手冊](https://www.gov.uk/service-manual/agile-delivery)》。 diff --git a/criteria/document-codebase-objectives.md b/criteria/document-codebase-objectives.md index d54d30eb..c1d0aca0 100644 --- a/criteria/document-codebase-objectives.md +++ b/criteria/document-codebase-objectives.md @@ -5,36 +5,38 @@ order: 8 redirect_from: - criteria/document-objectives --- -# Document codebase objectives -Clearly documenting [codebase](../glossary.md#codebase) objectives communicates the purpose of the codebase. -It helps stakeholders and contributors scope the development of the codebase. -The objectives also provide an easy way for people to decide whether this codebase, or one of its modules, is interesting for them now or in the future. +# 程式基底要有目標文件 -## Requirements +以文件清楚記錄[程式基底](../glossary.md#codebase)目標，來傳達程式基底的用途目標。這能幫助利害關係人與貢獻者劃定程式基底的開發範圍。這些目 +標也能方便人們判斷，是否在當下或未來，會對此程式基底或其模組感興趣。 -* The codebase MUST contain documentation of its objectives, like a mission and goal statement, that is understandable by developers and designers so that they can use or contribute to the codebase. -* Codebase documentation SHOULD clearly describe the connections between [policy](../glossary.md#policy) objectives and codebase objectives. -* Documenting the objectives of the codebase for the [general public](../glossary.md#general-public) is OPTIONAL. +## 需求規定 -## How to test +* 程式基底「必須」包含描寫目標的文件，像是主旨、使命或目標陳述。開發人員與設計師需要能夠瞭解這些，他們才知道可以怎樣使用程式基底或協助貢獻。 +* 程式基底文件「應該」清楚描述[政策](../glossary.md#policy)目標與程式基底目標之間的關聯。 +* 「可選擇」是否以文件記錄給[一般大眾](../glossary.md#general-public)看的程式基底目標。 -* Confirm that the codebase documentation includes the codebase objectives, mission or goal. -* Check for descriptions of connections between policy objectives and codebase objectives. +## 測試方式 -## Public policy makers: what you need to do +* 確認程式基底文件有包含程式基底目標，或主旨、使命等。 +* 查看政策目標與程式基底目標之間關聯的描述。 -* Add the policy objectives to the codebase documentation, for example in the `README`. -* Make sure that all your codebase objectives have links or references to supporting policy documents added to meet the [Bundle policy and source code](bundle-policy-and-source-code.md) criterion. +## 公共政策制定者：需要的工作 -## Managers: what you need to do +* 將政策目標加入程式基底文件中，例如「`README`」文件當中。 +* 確保所有程式基底目標，有連結或引用為了符合〈[政策與原始碼要合捆](bundle-policy-and-source-code.md)〉準則而加入的支持政策文 +件。 -* Add the organizational and business objectives to the codebase documentation, for example in the `README`. +## 管理人員：需要的工作 -## Developers and designers: what you need to do +* 將單位目標、組織目標或業務目標加入程式基底文件中，例如「`README`」文件當中。 -* Add the technology and design objectives to the codebase documentation, for example in the `README`. +## 開發人員與設計師：需要的工作 -## Further reading +* 將技術與設計目標加入程式基底文件中，例如「`README`」文件當中。 -* [How to write project objectives](http://grouper.ieee.org/groups/802/3/RTPGE/public/may12/hajduczenia_01_0512.pdf) by Marek Hajduczenia. +## 延伸閱讀 + +* Marek Hajduczenia《[如何撰寫專案目 +標](http://grouper.ieee.org/groups/802/3/RTPGE/public/may12/hajduczenia_01_0512.pdf)》。 diff --git a/criteria/document-the-code.md b/criteria/document-the-code.md index 228fb250..8247db71 100644 --- a/criteria/document-the-code.md +++ b/criteria/document-the-code.md @@ -5,49 +5,50 @@ order: 9 redirect_from: - criteria/documenting --- -# Document the code -Well documented [source code](../glossary.md#source-code) helps people to understand what the source code does and how to use it. -Documentation is essential for people to start using the [codebase](../glossary.md#codebase) and contributing to it more quickly. +# 程式碼要有文件 -## Requirements +文件記錄周全的[原始碼](../glossary.md#source-code)能幫助人們瞭解該原始碼的作用與使用方式。文件紀錄是幫助人們快速上手如何使用[程式基 +底](../glossary.md#codebase)，並做出貢獻的關鍵。 -* All of the functionality of the codebase, [policy](../glossary.md#policy) as well as source code, MUST be described in language clearly understandable for those that understand the purpose of the codebase. -* The documentation of the codebase MUST contain a description of how to install and run the software. -* The documentation of the codebase MUST contain examples demonstrating the key functionality. -* The documentation of the codebase SHOULD contain a high level description that is clearly understandable for a wide audience of stakeholders, like the [general public](../glossary.md#general-public) and journalists. -* The documentation of the codebase SHOULD contain a section describing how to install and run a standalone version of the source code, including, if necessary, a test dataset. -* The documentation of the codebase SHOULD contain examples for all functionality. -* The documentation SHOULD describe the key components or modules of the codebase and their relationships, for example as a high level architectural diagram. -* There SHOULD be [continuous integration](../glossary.md#continuous-integration) tests for the quality of the documentation. -* Including examples that make users want to immediately start using the codebase in the documentation of the codebase is OPTIONAL. +## 需求規定 -## How to test +* 程式基底的所有功能、[政策](../glossary.md#policy)及原始碼，都「必須」以可清楚瞭解的用語描述，讓懂程式基底目的用途的人也能夠理解。 +* 程式基底文件「必須」說明如何安裝與執行軟體。 +* 程式基底文件「必須」為關鍵功能舉出範例。 +* 程式基底文件「應該」包含精要的說明，讓[一般大眾](../glossary.md#general-public)和記者等廣泛的利害關係人都能清楚明白。 +* 程式基底文件「應該」有一部分用來說明，如何安裝與執行原始碼的單機版；如果有必要，也應該包含測試資料集。 +* 程式基底文件「應該」包含所有功能的範例。 +* 程式碼文件「應該」描述程式基底的主要組件或模組，以及其彼此之間的關係，例如以高層架構圖表示。 +* 「應該」要有針對文件品質的[持續整合](../glossary.md#continuous-integration)測試。 +* 「可選擇」是否在程式基底文件中，包含讓使用者想要立即使用程式基底的範例。 -* Confirm that other stakeholders, professionals from other public organizations and the general public find the documentation clear and understandable. -* Confirm that the documentation describes how to install and run the source code. -* Confirm that the documentation includes examples of the key functionality. -* Check with members of the general public and journalists if they can understand the high level description. -* Check that the instructions for how to install and run a standalone version of the source code result in a running system. -* Check that all functionality documented contains an example. -* Check that the documentation includes a high level architectural diagram or similar. -* Check that the documentation quality is part of integration testing, for example documentation is generated correctly, and links and images are tested. +## 測試方式 -## Public policy makers: what you need to do +* 確認文件內容能讓其他利害關係人、其他公家機關的專業人士，以及一般大眾，都可以清楚明白。 +* 確認文件有說明如何安裝與執行原始碼。 +* 確認文件有包含主要功能的範例。 +* 向一般大眾的成員以及記者確認，他們是否能明白文件當中的精要說明。 +* 檢查單機版原始碼的安裝與執行的步驟說明，確認能順利執行系統。 +* 檢查文件中列舉的所有功能都包含範例。 +* 檢查文件中是否包含高層架構圖，或類似的組件關係圖表。 +* 確認整合測試有包含到程式碼文件品質，例如確認生成的文件是否正確，並檢查連結與圖片等。 -* Check in regularly to understand how the non-policy code in the codebase has changed. -* Give feedback on how to make non-policy documentation more clear. +## 公共政策制定者：需要的工作 -## Managers: what you need to do +* 定期查看程式基底中非政策程式碼的變動情況。 +* 針對如何讓非政策文件更清楚易懂提供意見回饋。 -* Try to use the codebase, so your feedback can improve how clearly the policy and source code are documented. For example, is the current documentation sufficient to persuade a manager at another public organization to use this codebase? -* Make sure you understand both the policy and source code as well as the documentation. +## 管理人員：需要的工作 -## Developers and designers: what you need to do +* 嘗試使用程式基底，並提供您的意見回饋來讓政策與原始碼文件改善得更加清楚。舉例來說，可以自問目前的文件是否足以說服另一個公家機關的管理人員使用這套程式基底？ +* 確保您同時瞭解政策、原始碼以及文件內容。 -* Check in regularly to understand how the non-source code in the codebase has changed. -* Give feedback on how to make non-source documentation more clear. +## 開發人員與設計師：需要的工作 -## Further reading +* 定期查看程式基底中非原始碼部分的變動情況。 +* 針對如何讓非原始碼文件更清楚易懂提供意見回饋。 -* [Documentation guide](https://www.writethedocs.org/guide/) by Write the Docs. +## 延伸閱讀 + +* Write the Docs《[文件指南](https://www.writethedocs.org/guide/)》。 diff --git a/criteria/index.md b/criteria/index.md index 7bd1c002..d4dbee16 100644 --- a/criteria/index.md +++ b/criteria/index.md @@ -3,10 +3,11 @@ # SPDX-FileCopyrightText: 2019-2022 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS order: 0 --- -# Criteria +# 準則 {% assign sorted = site.pages | sort:"order" %} -{% for page in sorted %}{% if page.dir == "/criteria/" %}{% if page.name != "index.md" %}{% if page.title %} +{% for page in sorted %}{% if page.dir == "/criteria/" %}{% if page.name != +"index.md" %}{% if page.title %} -1. [{{page.title}}]({{page.url}}){% endif%} {% endif%} {% endif%}{% endfor %} +1. [{{page.title}}]({{page.url}}){% endif%} {% endif%} {% endif%}{% endfor %} diff --git a/criteria/maintain-version-control.md b/criteria/maintain-version-control.md index 5014df02..bb9c58d2 100644 --- a/criteria/maintain-version-control.md +++ b/criteria/maintain-version-control.md @@ -5,56 +5,61 @@ order: 6 redirect_from: - criteria/version-control-and-history --- -# Maintain version control -[Version control](../glossary.md#version-control) means keeping track of changes to the [source code](../glossary.md#source-code) and other files of the [codebase](../glossary.md#codebase) over time. -This allows you to maintain structured documentation of the history of the codebase. -This is essential for collaboration at scale, as it enables developers to work on changes in parallel and helps future developers to understand the reasons for changes. +# 維護版本控制 -## Requirements +[版本控制](../glossary.md#version-control)主要在追蹤[原始碼](../glossary.md#source-code)以及其他[程 +式基底](../glossary.md#codebase)檔案歷來的變動。這能讓您為程式基底維護有條理的變動歷史文件。這是大規模協作得以運作的要素，使開發人員可以 +針對修改變動平行作業，並幫助未來的開發人員瞭解做出修改的原因。 -* All files in the codebase MUST be version controlled. -* All decisions MUST be documented in commit messages. -* Every commit message MUST link to discussions and issues wherever possible. -* The codebase SHOULD be maintained in a distributed version control system. -* Contribution guidelines SHOULD require contributors to group relevant changes in commits. -* Maintainers SHOULD mark released versions of the codebase, for example using revision tags or textual labels. -* Contribution guidelines SHOULD encourage file formats where the changes within the files can be easily viewed and understood in the version control system. -* It is OPTIONAL for contributors to sign their commits and provide an email address, so that future contributors are able to contact past contributors with questions about their work. +## 需求規定 -## How to test +* 程式基底中的所有檔案皆「必須」有版本控制。 +* 所有決定皆「必須」記錄成送交版次訊息。 +* 每份送交版次訊息皆「必須」盡可能附上討論與議題連結。 +* 程式基底「應該」以分散式版本控制系統作維護。 +* 貢獻守則「應該」要求貢獻者，將相關的修改變動以群組分類方式送交。 +* 維護人員「應該」使用像是修訂版次標記，或文字標籤，來標示程式基底正式發行的版本。 +* 貢獻守則「應該」鼓勵採用能在版本控制系統中，輕鬆檢視與瞭解檔案中何處有做出更動的檔案格式。 +* 貢獻者「可選擇」是否對送交內容作簽章，並附上電子郵件信箱，以便當未來貢獻者對其內容有疑問時，可以與之前的貢獻者聯絡。 -* Confirm that the codebase is kept in version control using software such as Git. -* Review the commit history, confirming that all commit messages explain why the change was made. -* Review the commit history, confirming that where possible all commit messages include the discussion about the change was or where to find it (with a URL). -* Check if the version control system is distributed. -* Review the commit history, check if grouping of relevant changes in accordance with the contributing guidelines. -* Check that it is possible to access a specific version of the codebase, for example through a revision tag or a textual label. -* Check that the file formats used in the codebase are text formats where possible. +## 測試方式 -## Public policy makers: what you need to do +* 確認程式基底維持在版本控制狀態中，像是使用 Git 之類的軟體。 +* 審查送交版次歷史紀錄，確認所有的送交版次訊息，皆有解釋程式碼修改變動的原因。 +* 審查送交版次歷史紀錄，確認所有送交版次訊息之中，盡可能在所有討論過修改變更的地方，包含變動內容以及連結位置（提供網址）。 +* 檢查版本控制系統是否為分散式。 +* 審查送交版次歷史紀錄，檢查是否有根據貢獻指引將相關的程式碼變動以群組分類。 +* 檢查是否可能透過像是修訂版次標記，或文字標籤，來取用程式基底中的特定版本。 +* 檢查程式基底在盡可能的情況下，檔案都是採用文字格式。 -* If a new version of the codebase is created because of a [policy](../glossary.md#policy) change, make sure it's clear in the documentation: - * what the policy change is, - * how it's changed the codebase. +## 公共政策制定者：需要的工作 -For example, adding a new category of applicant to a codebase that manages granting permits would be considered a policy change. +* 如果因為[政策](../glossary.md#policy)改變而在程式基底中有新的版本，則請確認有在文件中清楚說明： + * 政策改變的地方， + * 程式基底如何因應而改變。 -## Managers: what you need to do +舉例來說，為程式基底作權限管理時，如果要新增申請方類別來賦予取用權，應視為一種政策變動。 -* Support policy makers, developers and designers to be clear about what improvements they're making to the codebase. Making improvements isn't a public relations risk. +## 管理人員：需要的工作 -## Developers and designers: what you need to do +* 支持政策制定者、開發人員與設計師，使其能清楚表達他們對程式基底做出的改善。確保改善程式基底不會有公關風險。 -* Make sure that all files required to understand the code, build and deploy are in the version control system. -* Write clear commit messages so that it is easy to understand why the commit was made. -* Mark different versions so that it is easy to access a specific version, for example using revision tags or textual labels. -* Write clear commit messages so that versions can be usefully compared. -* Work with policy makers to describe how the source code was updated after a policy change. +## 開發人員與設計師：需要的工作 -## Further reading +* 確認版本控制系統中，有瞭解程式碼、建置與部署所需要用到的所有檔案。 +* 送交版次訊息要寫清楚，讓人一看就能瞭解送交修改的原因。 +* 使用像是修訂版次標記，或文字標籤來標示不同版本，以方便取用特定版本。 +* 送交版次訊息要寫清楚，方便之後比較各版本。 +* 在政策改變以後，與政策制定者合作說明原始碼更新的部分。 -* [Producing OSS: Version Control Vocabulary](https://producingoss.com/en/vc.html#vc-vocabulary) by Karl Fogel. -* [Maintaining version control in coding](https://www.gov.uk/service-manual/technology/maintaining-version-control-in-coding) by the UK Government Digital Service. -* [GitHub Skills](https://skills.github.com/) by GitHub for learning how to use GitHub or refresh your skills. -* [Git Cheat Sheet](https://education.github.com/git-cheat-sheet-education.pdf) by GitHub, a list with the most common used git commands. +## 延伸閱讀 + +* Karl Fogel《[製作開放原始碼軟體：版本控制字 +彙](https://producingoss.com/en/vc.html#vc-vocabulary)》。 +* 英國政府數位服務團《[維護程式碼的版本控 +制](https://www.gov.uk/service-manual/technology/maintaining-version-control-in-coding)》。 +* GitHub 提供的「[GitHub 技能](https://skills.github.com/)」，可學習如何使用 GitHub，或是重溫您的技巧。 +* GitHub 提供的「[Git 密技 +表](https://education.github.com/git-cheat-sheet-education.pdf)」，列出了最常用的 git 命 +令。 diff --git a/criteria/make-contributing-easy.md b/criteria/make-contributing-easy.md index 049491e5..67597241 100644 --- a/criteria/make-contributing-easy.md +++ b/criteria/make-contributing-easy.md @@ -3,46 +3,48 @@ # SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS order: 5 --- -# Make contributing easy +# 貢獻要容易 -To develop better, more reliable and feature rich software, users need to be able to fix problems, add features, and address security issues of the shared [codebase](../glossary.md#codebase). +若要開發更好、更可靠且功能更豐富的軟體，使用者需要能夠為共享的[程式基底](../glossary.md#codebase)修正問題、新增功能，以及提出安全性議題 +等。 -A shared digital infrastructure makes it easier to make collaborative contributions. -The less effort it takes to make contributions that are accepted by the codebase, the more likely users are to become contributors. +共享的數位基礎建設讓協作貢獻更容易。使用者讓程式基底接受貢獻時所需付出的心力越少，則使用者越可能成為貢獻者。 -## Requirements +## 需求規定 -* The codebase MUST have a public issue tracker that accepts suggestions from anyone. -* The documentation MUST link to both the public issue tracker and submitted codebase changes, for example in a `README` file. -* The codebase MUST have communication channels for users and developers, for example email lists. -* There MUST be a way to report security issues for responsible disclosure over a closed channel. -* The documentation MUST include instructions for how to report potentially security sensitive issues. +* 程式基底「必須」有個可以公開接受任何人建議的議題追蹤器。 +* 文件中「必須」同時有公開的議題追蹤器連結，以及已提交的程式基底變動的連結，例如記錄在「`README`」檔案中。 +* 程式基底「必須」要有能與使用者以及開發人員溝通的管道，像是設立電子郵件列表（郵遞論壇）。 +* 「必須」有透過封閉管道通報安全性問題的方法，來達成負責任的揭露。 +* 文件「必須」說明，該如何通報潛在的安全性與敏感性問題。 -## How to test +## 測試方式 -* Confirm that there is a public issue tracker. -* Confirm that the codebase contains links to the public issue tracker and submitted codebase changes. -* Confirm that it is possible to participate in a discussion with other users and developers about the software using channels described in the codebase. -* Confirm that there is a closed channel for reporting security issues. -* Confirm that there are instructions for privately reporting security issues. +* 確認有公開的議題追蹤器。 +* 確認程式基底有公開的議題追蹤器連結，以及已提交的程式基底變動的連結。 +* 確認可以使用程式基底中提到的管道，與其他使用者以及開發人員一同討論該軟體。 +* 確認有封閉的管道可通報安全性問題。 +* 確認有說明如何私下通報安全性問題。 -## Public policy makers: what you need to do +## 公共政策制定者：需要的工作 -* Track [policy](../glossary.md#policy) issues in the codebase, so that a relevant external policy expert can volunteer help. +* 追蹤程式基底中的[政策](../glossary.md#policy)問題，讓相關的外部政策專家如果自願也能夠協助。 -## Managers: what you need to do +## 管理人員：需要的工作 -* Track management issues in the codebase, so that external managers with relevant experience can volunteer help. -* Support your experienced policy makers, developers and designers to keep contributing to the codebase for as long as possible. +* 追蹤程式基底中的管理問題，讓有相關經驗的外部管理人員如果自願也能夠協助。 +* 支持您經驗豐富的政策制定者、開發人員與設計師，使其盡可能為程式基底持續做出長久貢獻。 -## Developers and designers: what you need to do +## 開發人員與設計師：需要的工作 -* Just like for [reviews](require-review-of-contributions.md), make sure to respond to requests promptly. -* Keep your managers informed of the time and resources you require to support other contributors. -* Make sure that appropriate communication channels for asking maintainers and stakeholders questions are easy to locate, for instance in the README. -* Make sure that appropriate contact details are included in the metadata, for instance in the publiccode.yml file. +* 與[審查](require-review-of-contributions.md)流程相同，務必迅速回應請求。 +* 告知管理人員，您在支援其他貢獻者時所需的時間與資源。 +* 確保人們可輕鬆找到合適的溝通管道，來詢問維護人員與利害關係人問題，例如寫在「`README`」文件當中。 +* 確保中介資料包含合適的聯絡資訊，例如寫在 publiccode.yml 檔案中。 -## Further reading +## 延伸閱讀 -* [How to inspire exceptional contributions to your open-source project](https://dev.to/joelhans/how-to-inspire-exceptional-contributions-to-your-open-source-project-1ebf) by Joel Hans. -* [The benefits of coding in the open](https://gds.blog.gov.uk/2017/09/04/the-benefits-of-coding-in-the-open/) by the UK Government Digital Service. +* Joel Hans《[如何引發他人為您的開放原始碼專案做出優秀貢 +獻](https://dev.to/joelhans/how-to-inspire-exceptional-contributions-to-your-open-source-project-1ebf)》。 +* 英國政府數位服務團《[以開放精神編寫原始碼的好 +處](https://gds.blog.gov.uk/2017/09/04/the-benefits-of-coding-in-the-open/)》。 diff --git a/criteria/make-the-codebase-findable.md b/criteria/make-the-codebase-findable.md index ca2f1ce1..98ecc695 100644 --- a/criteria/make-the-codebase-findable.md +++ b/criteria/make-the-codebase-findable.md @@ -6,65 +6,70 @@ redirect_from: - criteria/findability --- -# Make the codebase findable - -The more findable a [codebase](../glossary.md#codebase) is, the more potential new collaborators will find it. -Just publishing a codebase and hoping it is found does not work, instead proactiveness is needed. - -A metadata description file increases discoverability. -Well-written metadata containing a unique and persistent identifier, such as a Wikidata item or FSF software directory listing (thus being part of the semantic web), makes the codebase easier for people to refer, cite, disambiguate and discover through third party tools. - -## Requirements - -* The name of the codebase SHOULD be descriptive and free from acronyms, abbreviations, puns or organizational branding. -* The codebase SHOULD have a short description that helps someone understand what the codebase is for or what it does. -* Maintainers SHOULD submit the codebase to relevant software catalogs. -* The codebase SHOULD have a website which describes the problem the codebase solves using the preferred jargon of different potential users of the codebase (including technologists, policy experts and managers). -* The codebase SHOULD be findable using a search engine by codebase name. -* The codebase SHOULD be findable using a search engine by describing the problem it solves in natural language. -* The codebase SHOULD have a unique and persistent identifier where the entry mentions the major contributors, [repository](../glossary.md#repository) location and website. -* The codebase SHOULD include a machine-readable metadata description, for example in a [publiccode.yml](https://github.com/publiccodeyml/publiccode.yml) file. -* A dedicated domain name for the codebase is OPTIONAL. -* Regular presentations at conferences by the community are OPTIONAL. - -## How to test - -* Check that the codebase name is descriptive and free of puns. -* Check that the codebase name is free of acronyms and abbreviations or that the acronyms or abbreviations in the name are more universally known than the longer forms. -* Check that the codebase name is free of organizational branding, unless that organization is of the codebase community itself. -* Check that the codebase repository has a short description of the codebase. -* Check for the codebase listing in relevant software catalogs. -* Check for a codebase website which describes the problem the codebase solves. -* Check that the codebase appears in the results on more than one major search engine when searching by the codebase name. -* Check that the codebase appears in the results on more than one major search engine when searching by using natural language, for instance, using the short description. -* Check unique and persistent identifier entries for mention of the major contributors. -* Check unique and persistent identifier entries for the repository location. -* Check unique and persistent identifier entries for the codebase website. -* Check for a machine-readable metadata description file. - -## Public policy makers: what you need to do - -* Contribute a description of the policy area or problem this codebase acts on or operates. -* Test your problem description with peers outside of your context who aren't familiar with the codebase. -* Present on how the codebase implements the [policy](../glossary.md#policy) at relevant conferences. - -## Managers: what you need to do - -* Search trademark databases to avoid confusion or infringement before deciding the name. -* Use the short description wherever the codebase is referenced, for instance, as social media account descriptions. -* Budget for content design and Search Engine Optimization skills in the team. -* Make sure people involved in the project present at relevant conferences. - -## Developers and designers: what you need to do - -* Search engine optimization, for instance adding a [sitemap](https://www.sitemaps.org/protocol.html). -* Use the short description wherever the codebase is referenced, for instance, as the repository description. -* Test your problem description with peers outside of your context who aren't familiar with the codebase. -* Suggest conferences to present at and present at them. +# 程式基底可查詢得到 + +一旦[程式基底](../glossary.md#codebase)越容易被發現，更多的潛在協作者也就找得到它。不能只是發表個程式基底，然後就盼望他人找得到這套程式基 +底，更需要主動積極。 + +有中介資料說明檔的話，會讓程式基底更容易被發現。良好且包含永久唯一識別碼的中介資料，例如寫成 Wikidata 維基數據條目，或是放到 FSF 自由軟體基金會的軟體 +目錄列表之中（使程式基底成為語意網路中的一部份），他人就能更容易透過第三方工具參考、引用、辨別、發現程式基底。 + +## 需求規定 + +* 程式基底名稱「應該」要能描述說明其用途，且不包含任何首字母縮寫字、縮寫、雙關語，或組織單位品牌名稱或抬頭等。 +* 程式基底說明「應該」要簡短，幫助他人瞭解程式基底的目的與作用。 +* 維護人員「應該」將程式基底提交至相關的軟體目錄上。 +* 程式基底「應該」要架設網站，內容中以程式基底各類潛在使用者（技術人員、政策專家、管理人員等）偏好的業內用語，描述程式基底所能解決的問題。 +* 在搜尋引擎查找程式基底名稱時，「應該」能搜尋得到程式基底。 +* 在使用搜尋引擎時，如果以自然語言描述程式基底所能解決的問題，「應該」能搜尋得到程式基底。 +* 程式基底「應該」具備永久唯一識別碼，而且該項條目要提及主要貢獻者、[儲存庫](../glossary.md#repository)、位置、網站等。 +* 程式基底「應該」包含機器可讀的中介資料說明，例如採用 +[publiccode.yml](https://github.com/publiccodeyml/publiccode.yml)格式的檔案。 +* 「可選擇」是否為程式基底設置專用的網域名稱。 +* 「可選擇」是否在社群舉辦的會議中定期進行簡報。 + +## 測試方式 + +* 檢查程式基底名稱是否描述說明其用途，且不包含雙關語。 +* 檢查程式基底名稱是否不包含任何首字母縮寫字或縮寫，或是其首字母縮寫字或縮寫比完整名稱更熟為人知。 +* 檢查程式基底是否不包含組織單位品牌名稱或抬頭等，除非該組織單位也是程式基底社群成員。 +* 檢查程式基底儲存庫是否包含程式基底的簡短描述。 +* 檢查程式基底有刊登在相關軟體型錄上。 +* 檢查程式基底的網站有描述程式基底能夠解決的問題。 +* 檢查以程式基底名稱來作搜尋時，有超過一個的常用主流搜尋引擎，都有將程式基底列在搜尋結果中。 +* 檢查以自然語言來作搜尋，例如使用程式基底的簡短描述時，有超過一個的常用主流搜尋引擎，都將程式基底放在搜尋結果中。 +* 檢查永久唯一識別碼條目有提及主要貢獻者。 +* 檢查永久唯一識別碼條目中有包含儲存庫位置。 +* 檢查永久唯一識別碼條目有列出程式基底網站。 +* 檢查中介資料說明檔是機器可讀的格式。 + +## 公共政策制定者：需要的工作 + +* 貢獻一段說明此程式基底作用的政策領域，或所處理問題的描述。 +* 請那些對程式基底不熟悉且不同領域背景的同事，來測試您的問題描述。 +* 在相關會議上作簡報，介紹程式基底如何執行[政策](../glossary.md#policy)。 + +## 管理人員：需要的工作 + +* 在決定專案名稱之前，先搜尋過商標資料庫，以避免名稱造成混淆或侵權的問題。 +* 在引用到程式基底的地方，都使用簡短描述，例如放到社交媒體帳號中的說明。 +* 為團隊編列內容設計與實作 SEO 搜尋引擎最佳化技能的預算。 +* 確保專案參與人員出席相關會議，或作簡報介紹。 + +## 開發人員與設計師：需要的工作 + +* 實作搜尋引擎最佳化，例如加入[網站地圖](https://www.sitemaps.org/protocol.html)。 +* 在引用到程式基底的地方，都使用簡短描述，例如放到儲存庫中的說明。 +* 請那些對程式基底不熟悉且不同領域背景的同事，來測試您的問題描述。 +* 推薦適合出席或作簡報介紹的會議，並且在這些會議中出席或作簡報。

-## Further reading -* [Introduction to Wikidata](https://www.wikidata.org/wiki/Wikidata:Introduction) by the Wikidata community. -* [FSF software directory listing](https://directory.fsf.org/wiki/Main_Page) by the Free Software Foundation. -* The [FAIR Guiding Principles for scientific data management and stewardship](https://www.go-fair.org/fair-principles/) by the GO FAIR International Support and Coordination Office provide a nice list of attributes that make (meta)data more machine actionable (and hence more findable). Some of these apply directly to codebases, while others may provoke exploration into what the codebase equivalent would be. +## 延伸閱讀 + +* Wikidata 維基數據社群《[維基數據簡 +介](https://www.wikidata.org/wiki/Wikidata:Introduction)》。 +* FSF 自由軟體基金會《[FSF 軟體目錄列表](https://directory.fsf.org/wiki/Main_Page)》。 +* GO FAIR 國際支援與合作辦公室所撰寫的《[FAIR 科學資料管理與監督指導原 +則](https://www.go-fair.org/fair-principles/)》，提供一份滿好的特性清單，解說哪些特性會讓資料（或中介資料）更容易讓 +機器採取行動（也因此更容易被找到）。其中的部分特性可直接套用到程式基底上，而其他無法直接套用的，我們還需要再研究程式基底與其對應的特性要怎麼處理。 diff --git a/criteria/make-the-codebase-reusable-and-portable.md b/criteria/make-the-codebase-reusable-and-portable.md index 5437394c..39a597a8 100644 --- a/criteria/make-the-codebase-reusable-and-portable.md +++ b/criteria/make-the-codebase-reusable-and-portable.md @@ -6,71 +6,73 @@ redirect_from: - criteria/reusable-and-portable-codebases - criteria/create-reusable-and-portable-code --- -# Make the codebase reusable and portable -Creating reusable and portable [code](../glossary.md#code) enables policy makers, developers and designers to reuse what has been developed, test it, improve it and contribute those improvements back, leading to better quality, cheaper maintenance and higher reliability. +# 程式基底要可重複使用且可移植 -Thoughtfully and purposefully designing a [codebase](../glossary.md#codebase) for reusability allows for the mission, vision and scope of the codebase to be shared by multiple parties. -Codebases developed and used by multiple parties are more likely to benefit from a self-sustaining community. +編寫可重複使用且可移植的[程式碼](../glossary.md#code)，讓政策制定者、開發人員與設計師等，能重複使用、測試與改善目前已開發的內容，並將改善貢獻 +回程式基底中，如此可提高品質、降低維護成本、增強可靠性。 -Organizing a codebase such that it is composed of well documented modules improves reusability and maintainability. -A module is easier to reuse in [another context](../glossary.md#different-contexts) if its purpose is clearly documented. +以重複利用為前提籌劃設計[程式基底](../glossary.md#codebase)，更容易與多方共享程式基底的目標使命、願景與範圍等。多方開發與使用的程式基底， +更可以從能自我運作的社群中獲益。 -Source code which does not rely on the situation-specific infrastructure of any contributor, vendor or deployment can be tested by any other contributor. +以文件記錄周全的模組構成程式基底，能夠改善重複使用與維護的能力。以文件清楚記錄用途的模組，更容易在[另一種情境](../glossary.md#different-contexts)中重複利用。 -## Requirements +原始碼不依賴任何貢獻者、供應商或部署底下的特定情況專用基礎架構，則其他任何貢獻者都能測試該原始碼。 -* The codebase MUST be developed to be reusable in different contexts. -* The codebase MUST be independent from any secret, undisclosed, proprietary or non-open licensed software or services for execution and understanding. -* The codebase SHOULD be in use by multiple parties. -* The roadmap SHOULD be influenced by the needs of multiple parties. -* The development of the codebase SHOULD be a collaboration between multiple parties. -* Configuration SHOULD be used to make [source code](../glossary.md#source-code) adapt to context specific needs. -* The codebase SHOULD be localizable. -* Source code and its documentation SHOULD NOT contain situation-specific information. -* Codebase modules SHOULD be documented in such a way as to enable reuse in codebases in other contexts. -* The software SHOULD NOT require services or platforms available from only a single vendor. +## 需求規定 -## How to test +* 程式基底「必須」開發成能在不同情境中重複使用。 +* 程式基底「必須」獨立於任何採用保密、無法揭露、專有或非開放式授權的軟體或服務，以供執行與瞭解。 +* 程式基底「應該」有多方單位使用。 +* 發展路線圖「應該」有多方單位的需求影響。 +* 程式基底開發「應該」由多方單位協作。 +* 「應該」使用組態設定方式以將[原始碼](../glossary.md#source-code)調整成能適應各情境的特定需求。 +* 程式基底「應該」能夠在地化。 +* 原始碼與其文件「不應該」包含特定情況專用的資訊。 +* 程式基底模組「應該」以使其能夠在其他情境中重複利用的模式撰寫文件。 +* 軟體「不應該」要求僅有單一供應商能提供的服務或平台。 -* Confirm with someone in a similar role at another organization if they can use the codebase and what that would entail. -* Confirm that the codebase can run without using any proprietary or non open-licensed software or services. -* If the codebase is in early development before a production-ready release, then check for evidence of ambition to obtain collaborators. - * Or if the codebase is very mature and stable with very infrequent fixes, patches, or contributions: - * Check that the codebase is in use by multiple parties or in multiple contexts. - * Check for documented and budgeted commitments of collaboration. - * Otherwise: - * Check that the codebase is in use by multiple parties or in multiple contexts. - * Check that the codebase contributors are from multiple parties. -* Check that the codebase files and commit history do not include situation-specific data. -* Check that the software can be deployed and run without services or platforms available from a single vendor. +## 測試方式 -## Public policy makers: what you need to do +* 與另一組織單位角色與您相似的人確認，看他們是否能利用程式基底，以及需要怎麼進行。 +* 確認程式基底不需要用到任何專有或非開放式授權的軟體或服務，就能夠執行。 +* 若程式基底處於早期開發階段，尚未準備好正式上線，則檢查是否有想要尋求協作者的意圖跡象。 + * 或是如果程式基底非常成熟與穩定，鮮少需要修正、改善或貢獻： + * 檢查是否有多方單位，或是有在多種情境下正使用程式基底。 + * 檢查是否有以文件記錄協作所做出的成果，以及有編列相關預算。 + * 若是沒有，則： + * 檢查是否有多方單位，或是有在多種情境下正使用程式基底。 + * 檢查程式基底貢獻者是否來自多方單位。 +* 檢查程式基底檔案與送交版次歷史紀錄中，不包含特定情況專用的資料。 +* 檢查軟體是否可以在不使用單一供應商服務或平台的情況下，正常部署與執行。 -* Document your [policy](../glossary.md#policy) with enough clarity and detail that it can be understood outside of its original context. -* Make sure your organization is listed as a known user by the codebase. -* Identify other organizations for your teams to collaborate with. +## 公共政策制定者：需要的工作 -## Managers: what you need to do +* 為您的[政策](../glossary.md#policy)撰寫清楚且足夠詳細的文件，讓他人即使不是處於同個原始背景情境也能夠理解。 +* 確保程式基底有將貴組織單位列為已知使用者。 +* 找出貴團隊想要協作的其他組織單位。 -* Make sure that stakeholders and business owners understand that reusability is an explicit codebase goal as this reduces technical debt and provides sustainability for the codebase. -* Make sure that your teams are collaborating with other teams. +## 管理人員：需要的工作 -## Developers and designers: what you need to do +* 確認利害關係人與業主能夠瞭解，程式基底是以重複利用為明確目標，因而得以減少程式碼技術債，並讓程式基底可以永續發展。 +* 確認您的團隊與其他團隊能相互協作。 -Source should be designed: +## 開發人員與設計師：需要的工作 -* for reuse by other users and organizations regardless of locale, -* to solve a general problem instead of a specific one, -* in logically meaningful and isolated modules, -* so that someone in a similar organization facing a similar problem would be able to use (parts of) the solution. +原始碼應該設計成： -Make sure that the codebase documentation describes the build-time and runtime dependencies. -If your context requires deploying to proprietary platforms or using proprietary components, make sure that collaborators can develop, use, test, and deploy without them. +* 能讓其他使用者與組織單位可以重複利用，而不受地方環境影響， +* 能解決通用性質問題，而非特定問題， +* 以邏輯上具有意義且獨立的模組構成， +* 如此讓類似組織單位中要面對近似問題的人，都可以採用這套解決方案（或其中一部份）。 -For each commit, reviewers verify that content does not include situation-specific data such as hostnames, personal and organizational data, or tokens and passwords. +確保程式基底文件中，有說明程式的組建日期與執行時期的依賴項目。如果您的情境需要部署至專有平臺上，或者要用到專有組件，則請確保協作者可以在不用到這兩者的情況下，就能進 +行開發、使用、測試、部署等。 -## Further reading +在每份送交版次中，審查人員要確認其中不含特定情況專用的資料，像是主機名稱、個人與組織單位資料、代符與密碼等。 -* [Making source code open and reusable](https://www.gov.uk/service-manual/technology/making-source-code-open-and-reusable) by the UK Government Digital Service. -* [Localization vs. Internationalization](https://www.w3.org/International/questions/qa-i18n) by the World Wide Web Consortium. +## 延伸閱讀 + +* 英國政府數位服務團《[讓原始碼開放且可重複利 +用](https://www.gov.uk/service-manual/technology/making-source-code-open-and-reusable)》。 +* W3C 全球資訊網協會《[在地化與國際化](https://www.w3.org/International/questions/qa-i18n)》。 diff --git a/criteria/publish-with-an-open-license.md b/criteria/publish-with-an-open-license.md index 1b674dcb..f001ce8e 100644 --- a/criteria/publish-with-an-open-license.md +++ b/criteria/publish-with-an-open-license.md @@ -5,50 +5,59 @@ order: 13 redirect_from: - criteria/open-licenses --- -# Publish with an open license -An open and well known license makes it possible for anyone to see the [source code](../glossary.md#source-code) in order to understand how it works, to use it freely and to contribute to the [codebase](../glossary.md#codebase). -This enables a vendor ecosystem to emerge around the codebase. +# 發行採用開放授權 -Clearly indicating the license for each file within a codebase facilitates correct reuse and attribution of parts of a codebase. +採用開放且為人熟知的授權，讓任何人都可以查看[原始碼](../glossary.md#source-code)，使其能瞭解運作方式、自由使用，並且能為[程式基 +底](../glossary.md#codebase)做出貢獻。這也能促進供應商建立出以程式基底為中心的生態系。 -## Requirements +明確指出程式基底中每一個檔案的授權，讓使用者能正確重複利用程式基底的部分內容，並表彰作者名稱。 -* All source code and documentation MUST be licensed such that it may be freely reusable, changeable and redistributable. -* Software source code MUST be licensed under an [OSI-approved or FSF Free/Libre license](https://spdx.org/licenses/). -* All source code MUST be published with a license file. -* Contributors MUST NOT be required to transfer copyright of their contributions to the codebase. -* All source code files in the codebase SHOULD include a copyright notice and a license header that are machine-readable. -* Having multiple licenses for different types of source code and documentation is OPTIONAL. +## 需求規定 -## How to test +* 所有原始碼與文件，皆「必須」採用使其得以自由重複使用、自由修改、自由再次散布的授權條款。 +* 軟體原始碼「必須」採用[經 OSI 開放原始碼促進會所批准，或由 FSF 自由軟體基金會所發表的自由授權條 +款](https://spdx.org/licenses/)。 +* 所有原始碼皆「必須」搭配授權條款檔案一併發行。 +* 「禁止」要求貢獻者將其貢獻的程式碼著作權轉讓給程式基底。 +* 程式基底中所有原始碼檔案，皆「應該」包含機器可讀的著作權聲明與授權條款標頭內容。 +* 「可選擇」是否為不同類型的原始碼與文件採用多重授權條款。 -* Confirm that the codebase is clearly licensed. -* Confirm that the license for the source code is on the [OSI-approved or FSF Free/Libre license list](https://spdx.org/licenses/) and the license for documentation [conforms to the Open Definition](https://opendefinition.org/licenses/). -* Confirm that the licenses used in the codebase are included as files. -* Confirm that contribution guidelines and [repository](../glossary.md#repository) configuration do not require transfer of copyright. -* Check for machine-readable license checking in the codebase [continuous integration](../glossary.md#continuous-integration) tests. +## 測試方式 -## Public policy makers: what you need to do +* 確認程式基底有清楚給予授權條款。 +* 確認原始碼的授權條款有列於[經 OSI 開放原始碼促進會所批准，或由 FSF 自由軟體基金會所發表的自由授權條款清 +單](https://spdx.org/licenses/)，以及文件的授權條款有[符合「開放定 +義」](https://opendefinition.org/licenses/)。 +* 確認程式基底中有包含其採用的授權條款檔案。 +* 確認貢獻指引中，以及[儲存庫](../glossary.md#repository)的組態設定中，沒有要求貢獻者轉讓著作權。 +* 在程式基底[持續整合](../glossary.md#continuous-integration)測試中，確認是否有檢查授權內容為機器可讀的檢查項目。 -* Develop [policy](../glossary.md#policy) that requires source code to be [open source](../glossary.md#open-source). -* Develop policy that disincentivizes non-open source code and technology in procurement. +## 公共政策制定者：需要的工作 -## Managers: what you need to do +* 制定要求原始碼必須採用[開放原始碼](../glossary.md#open-source)授權的[政策](../glossary.md#policy)。 +* 制定抑制採購非開放原始碼授權程式碼，與非開放科技的政策。 -* Only work with open source vendors that deliver their source code by publishing it under an open source license. -* Beware that even though [Creative Commons licenses](https://creativecommons.org/licenses/) are great for documentation, licenses that stipulate Non-Commercial or No Derivatives are NOT freely reusable, changeable and redistributable and don't fulfill these requirements. +## 管理人員：需要的工作 -## Developers and designers: what you need to do +* 只與能採用開放原始碼授權交付、與發行其原始碼的開放原始碼軟體供應商合作。 +* 請注意，雖然[創用CC授權](https://creativecommons.org/licenses/)適合用於文件作品，但其中指明「非商業性」或「禁止改作」 +的授權條款，代表「無法」自由重複使用、自由修改、自由再次散布等，因此未能符合規定。 -* Add a new `license` file to every new codebase created. -* Add a copyright notice and a license header to every new source code file created. -* When source code is being reused by the codebase, make sure that it has a license that is compatible with the license or licenses of the codebase. +## 開發人員與設計師：需要的工作 + +* 每當建立新的程式基底時，都要加入新的「`license`」授權條款檔案。 +* 每當建立新的原始碼檔案時，都要加入著作權聲明與授權條款標頭內容。 +* 每當程式基底重複利用原始碼時，都要確認原始碼的授權與程式基底的授權相容。

-## Further reading -* [Open source definition](https://opensource.org/osd) by the Open Source Initiative, all open source licenses meet this definition. -* [Animated video introduction to Creative Commons](https://creativecommons.org/about/videos/creative-commons-kiwi) by Creative Commons Aotearoa New Zealand. -* [REUSE Initiative specification](https://reuse.software/spec/) by Free Software Foundation Europe for unambiguous, human-readable and machine-readable copyright and licensing information. -* [SPDX License List](https://spdx.org/licenses/) by the Linux Foundation with standardized, machine-readable abbreviations for most licenses. +## 延伸閱讀 + +* 開放原始碼促進會所發表的《[開放原始碼定義](https://opensource.org/osd)》，所有開放原始碼授權條款皆符合這套定義。 +* 紐西蘭CC Aotearoa《[創用CC介紹動畫影 +片](https://creativecommons.org/about/videos/creative-commons-kiwi)》。 +* 歐洲自由軟體基金會所發表的《[REUSE 倡議規範](https://reuse.software/spec/)》，提供規範明確、人類可讀以及機器可讀的著作權與 +授權資訊。 +* Linux 基金會所發表的 [SPDX 授權條款清單](https://spdx.org/licenses/)，提供經標準化、且機器可讀的大多數授權條款縮寫表示 +法。 diff --git a/criteria/require-review-of-contributions.md b/criteria/require-review-of-contributions.md index fca4fc5c..905b5df2 100644 --- a/criteria/require-review-of-contributions.md +++ b/criteria/require-review-of-contributions.md @@ -5,59 +5,66 @@ order: 7 redirect_from: - criteria/require-review --- -# Require review of contributions -Peer-review of contributions is essential for [source code](../glossary.md#source-code) quality, reducing security risks and operational risks. +# 要求審查貢獻內容 -Requiring thorough review of contributions encourages a culture of making sure every contribution is of high quality, completeness and value. -Source code review increases the chance of discovering and fixing potential bugs or mistakes before they are added to the [codebase](../glossary.md#codebase). -Knowing that all source code was reviewed discourages a culture of blaming individuals, and encourages a culture of focusing on solutions. +同儕審查貢獻是[原始碼](../glossary.md#source-code)提升品質的關鍵，也能降低安全性風險與營運風險。 -A [policy](../glossary.md#policy) of prompt reviews assures contributors of a guaranteed time for feedback or collaborative improvement, which increases both rate of delivery and contributor engagement. +要求仔細審查貢獻，能孕育出確保貢獻都是優質、完整且能帶來價值的文化。審查原始碼能提高在原始碼加入[程式基底](../glossary.md#codebase)之前， +就發現與修正潛在臭蟲與出錯的機率。得知所有原始碼都會被審查，就不會孕育出習慣怪罪他人的文化，反倒是鼓勵每個人都專注在解決方案上。 -## Requirements +快速審查[政策](../glossary.md#policy)在於向貢獻者保證，必定在一段時間內提供意見回饋或是協作式改善，進而提高貢獻者交付貢獻內容的頻率，以及參 +與的熱度。 -* All contributions that are accepted or committed to release versions of the codebase MUST be reviewed by another contributor. -* Reviews MUST include source, policy, tests and documentation. -* Reviewers MUST provide feedback on all decisions to not accept a contribution. -* The review process SHOULD confirm that a contribution conforms to the standards, architecture and decisions set out in the codebase in order to pass review. -* Reviews SHOULD include running both the software and the tests of the codebase. -* Contributions SHOULD be reviewed by someone in a different context than the contributor. -* Version control systems SHOULD NOT accept non-reviewed contributions in release versions. -* Reviews SHOULD happen within two business days. -* Performing reviews by multiple reviewers is OPTIONAL. +## 需求規定 -## How to test +* 所有被接受或是送交給程式基底正式發行版本中的貢獻內容，都「必須」經過另一位貢獻者審查。 +* 審查「必須」包含原始碼、政策、測試、文件等。 +* 如果不接受貢獻內容，審查人員「必須」提供意見回饋。 +* 審查流程「應該」確認貢獻內容遵循程式基底的標準、架構、決策安排等，以通過審查。 +* 審查內容「應該」包含執行軟體與執行程式基底測試。 +* 貢獻內容「應該」由與貢獻者不同背景情境的人來審查。 +* 版本控制系統「不應該」在程式基底的正式發行版本中，接受未經審查的貢獻內容。 +* 審查「應該」在兩個工作天內進行。 +* 「可選擇」是否由多位審查人員進行審查。 -* Confirm that every commit in the history has been reviewed by a different contributor. -* Confirm that reviews include source, policy, tests and documentation. -* Confirm that rejected contributions were appropriately explained. -* Check if guidelines for reviewers include instructions to review for conformance to standards, architecture and codebase guidelines. -* Check with reviewers if they run the software and tests during review. -* Check with reviewers if commits have been reviewed by a different contributor in a different context. -* Check for use of branch protection in the [version control](../glossary.md#version-control) system. -* Check the times between contribution submission and review. +## 測試方式 -## Public policy makers: what you need to do +* 確認歷史紀錄中，每個送交版次都有經過不同的貢獻者審查。 +* 確認審查內容包含原始碼、政策、測試、文件等。 +* 針對未被採用的貢獻內容，確認有適當解釋原因。 +* 檢查審查人員指引中，有包含是否遵循標準、架構、程式基底指引等指示。 +* 檢查審查人員在審查時是否有執行軟體與測試。 +* 與審查人員確認，送交版次是否有經過不同情境背景的不同貢獻者審查。 +* 檢查[版本控制](../glossary.md#version-control)系統中是否有採用分支保護。 +* 檢查貢獻提交與審查之間的時間間隔。 -* Institute a 'four eyes' policy where everything, not just source code, is reviewed. -* Use a version control system or methodology that enables review and feedback. +## 公共政策制定者：需要的工作 -## Managers: what you need to do +* 制定進行任何審查時，含原始碼與其他一切事物，都要恪遵「四眼原則」的政策。 +* 採用具有審查與意見回饋功能的版本控制系統，或作業流程。 -* Make delivering great software a shared objective. -* Make sure writing and reviewing contributions to source, policy, documentation and tests are considered equally valuable. -* Create a culture where all contributions are welcome and everyone is empowered to review them. -* Make sure no contributor is ever alone in contributing to a codebase. +## 管理人員：需要的工作 -## Developers and designers: what you need to do +* 將交付妥善軟體作為共同目標。 +* 確保如原始碼、政策、文件、測試等的貢獻內容撰寫與審查，皆受到同等重視。 +* 創造歡迎所有形式的貢獻，而且每個人都能夠審查貢獻內容的文化。 +* 確保貢獻者在貢獻內容給程式基底時，不是獨自一人埋頭苦幹。 -* Ask other contributors on the codebase to review your work, in your organization or outside of it. -* Try to respond to others' requests for review promptly, initially providing feedback about the concept of the change. +## 開發人員與設計師：需要的工作 -## Further reading +* 請程式基底的其他貢獻者，審查您在貴組織單位內外的工作成果。 +* 當他人請求您審查時，請盡快回覆，並先給出需要修正之處背後的概念。 -* [How to review code the GDS way](https://gds-way.cloudapps.digital/manuals/code-review-guidelines.html#content) by the UK Government Digital Service. -* Branch protection on [GitHub](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches) and [GitLab](https://about.gitlab.com/blog/2014/11/26/keeping-your-code-protected/). -* [The Gentle Art of Patch Review](https://sage.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/) by Sage Sharp. -* [Measuring Engagement](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) by Mozilla. +## 延伸閱讀 + +* 英國政府數位服務團《[英國政府數位服務團程式碼審查程 +序](https://gds-way.cloudapps.digital/manuals/code-review-guidelines.html#content)》。 +* [GitHub](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches) +與 +[GitLab](https://about.gitlab.com/blog/2014/11/26/keeping-your-code-protected/) 平 +臺的分支保護說明。 +* Sage Sharp《[程式修補審查的和善藝 +術](https://sage.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/)》。 +* Mozilla《[參與度評測成 +果](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177)》。 diff --git a/criteria/use-a-coherent-style.md b/criteria/use-a-coherent-style.md index 6199ef02..a12e7e07 100644 --- a/criteria/use-a-coherent-style.md +++ b/criteria/use-a-coherent-style.md @@ -5,43 +5,45 @@ order: 15 redirect_from: - criteria/style --- -# Use a coherent style -Following a consistent and coherent style enables contributors in different environments to work together. -Unifying vocabularies reduces friction in communication between contributors. +# 風格要前後一致 -## Requirements +採用前後一致的風格，讓不同環境的貢獻者能夠一同合作。用詞統一能減少貢獻者之間在溝通上的摩擦。 -* The [codebase](../glossary.md#codebase) MUST use a coding or writing style guide, either the codebase community's own or an existing one referred to in the codebase. -* Contributions SHOULD pass automated tests on style. -* The style guide SHOULD include expectations for inline comments and documentation for non-trivial sections. -* Including expectations for [understandable English](use-plain-english.md) in the style guide is OPTIONAL. +## 需求規定 -## How to test +* [程式基底](../glossary.md#codebase)「必須」遵守程式碼撰寫風格指引、或文件寫作風格指引，可以是程式基底社群自身的風格指引，或是程式基底 +有採用的既有風格。 +* 貢獻內容「應該」通過自動化的風格測試。 +* 風格指引「應該」描述對於較複雜的程式碼區段，如何作列內註解與為其寫下說明文件的期待。 +* 「可選擇」是否將[可理解的白話英語](use-plain-english.md)期望加入風格指引之中。 -* Confirm that contributions are in line with the style guides specified in the documentation. -* Check for the presence of automated tests on style. +## 測試方式 -## Public policy makers: what you need to do +* 確認貢獻內容有遵循文件中指定的風格指引。 +* 檢查是否有自動化的風格測試。 -* Create, follow and continually improve on a style guide for [policy](../glossary.md#policy) and documentation as well as document this in the codebase, for example in the `CONTRIBUTING` or `README`. +## 公共政策制定者：需要的工作 -## Managers: what you need to do +* 為[政策](../glossary.md#policy)與文件建立風格指引，遵守並且持續改善，同時記錄到程式基底文件中，像是「`CONTRIBUTING`」或 +「`README`」檔案。 -* Include written language, source, test and policy standards in your organizational definition of quality. +## 管理人員：需要的工作 -## Developers and designers: what you need to do +* 將書面語言、原始碼、測試、政策標準等，包含在貴組織單位對品質的定義當中。 -If the codebase does not already have engineering guidelines or other contributor guidance, start by adding documentation to the [repository](../glossary.md#repository) describing whatever is being done now, for example in the `CONTRIBUTING` or `README`. -An important purpose of the file is to communicate design preferences, naming conventions, and other aspects machines can't easily check. -Guidance should include what would be expected from [source code](../glossary.md#source-code) contributions in order for them to be merged by the maintainers, including source, tests and documentation. -Continually improve upon and expand this documentation with the aim of evolving this documentation into engineering guidelines. +## 開發人員與設計師：需要的工作 -Additionally: +如果程式基底還沒有工程指引，或其他貢獻者指引，則請先在[儲存庫](../glossary.md#repository)中加入相關文件，像是 +「`CONTRIBUTING`」或「`README`」檔案，並描述目前在設立指引方面的進展。上述檔案的重要目的之一，在於宣達設計偏好、命名規則，以及機器不容易檢查 +的其他層面。指引應該包含貢獻的[原始碼](../glossary.md#source-code)預期該符合哪些要求，才會被維護人員合併至程式基底中，包括原始碼、測 +試、文件等項目。請持續改善與擴充這份文件內容，目標讓文件朝向工程指引演進。 -* Use a linter. -* Add linter configurations to the codebase. +此外： -## Further reading +* 使用 linter 程式碼品質梳理工具。 +* 在程式基底中加入 linter 梳理工具的組態設定。 -* [Programming style](https://en.wikipedia.org/wiki/Programming_style) on Wikipedia. +## 延伸閱讀 + +* 維基百科上的《[程式碼風格](https://en.wikipedia.org/wiki/Programming_style)》條目。 diff --git a/criteria/use-continuous-integration.md b/criteria/use-continuous-integration.md index d19b4789..9559693f 100644 --- a/criteria/use-continuous-integration.md +++ b/criteria/use-continuous-integration.md @@ -5,66 +5,68 @@ order: 12 redirect_from: - criteria/continuous-integration --- -# Use continuous integration -Asynchronous collaboration is enabled by developers merging their work to a shared branch frequently, verified by automated tests. -The more frequent the merging and the smaller the contribution, the easier it is to resolve merge conflicts. +# 使用持續整合 -Automated testing of all functionality provides confidence that contributions are working as intended and have not introduced errors, and allows reviewers to focus on the structure and approach of the contribution. -The more focused the test, the easier it is to clearly identify and understand errors as they arise. +透過自動化測試驗證，開發人員能更頻繁地將其工作成果合併至共享的分支，達成非同步協作。合併的頻率越頻繁、貢獻的規模越小，在合併時所發生的衝突就越容易解決。 -Documenting a codebase's [continuous integration](../glossary.md#continuous-integration) workflow helps contributors understand the expectations of contributions. -Continuous integration allows for an easier monitoring of the state of the [codebase](../glossary.md#codebase). +自動化測試所有功能，使人更加信賴貢獻內容發揮其功用且沒有引發任何錯誤，同時讓審查人員專注在貢獻的結構與作法。測試越聚焦，就越容易辨識並瞭解所出現的問題。 -## Requirements +以文件記錄程式基底的[持續整合](../glossary.md#continuous-integration)工作流程，能協助貢獻者瞭解對貢獻內容的期待。持續整合讓 +監管[程式基底](../glossary.md#codebase)狀態變得更為簡單。 -* All functionality in the [source code](../glossary.md#source-code) MUST have automated tests. -* Contributions MUST pass all automated tests before they are admitted into the codebase. -* The codebase MUST have guidelines explaining how to structure contributions. -* The codebase MUST have active contributors who can review contributions. -* Automated test results for contributions SHOULD be public. -* The codebase guidelines SHOULD state that each contribution should focus on a single issue. -* Source code test and documentation coverage SHOULD be monitored. -* Testing [policy](../glossary.md#policy) and documentation for consistency with the source and vice versa is OPTIONAL. -* Testing policy and documentation for style and broken links is OPTIONAL. -* Testing the software by using examples in the documentation is OPTIONAL. +## 需求規定 -## How to test +* [原始碼](../glossary.md#source-code)中的所有功能，都「必須」有自動化測試。 +* 所有貢獻內容都「必須」先通過自動化測試，才能上傳至程式基底。 +* 程式基底「必須」有解說如何撰寫貢獻內容結構的相關指引。 +* 程式基底「必須」有能夠審查貢獻內容的活躍貢獻者。 +* 「應該」公開貢獻內容的自動化測試結果。 +* 程式基底指引「應該」指出，每次的貢獻內容都只應聚焦在單一議題上。 +* 「應該」監管原始碼測試與文件的涵蓋範圍。 +* 「可選擇」是否測試[政策](../glossary.md#policy)和文件，與原始碼之間有無一致性，或是反之亦然。 +* 「可選擇」是否測試政策和文件所採用的樣式，以及連結有無失效。 +* 「可選擇」是否使用文件中的範例來測試軟體。 -* Confirm that there are tests present. -* Confirm that source code coverage tools check that coverage is at 100% of the source code. -* Confirm that contributions are only admitted into the codebase after all of the tests are passed. -* Confirm that contribution guidelines explain how to structure contributions. -* Confirm that there are contributions from within the last three months. -* Check that test results are viewable. -* Check if source code coverage data is published. +## 測試方式 -## Public policy makers: what you need to do +* 確認有測試可用。 +* 確認原始碼覆蓋率工具能檢查到 100% 的原始碼。 +* 確認貢獻內容只有在通過所有測試後，才會認可上傳至程式基底。 +* 確認有貢獻指引解說如何撰寫貢獻內容的結構。 +* 確認最近三個月內有貢獻內容上傳。 +* 檢查是否可以查看測試結果。 +* 檢查是否有公布原始碼覆蓋率數據。 -* Involve managers as well as developers and designers as early in the process as possible and keep them engaged throughout development of your policy. -* Make sure there are also automated tests set up for policy documentation. -* Fix policy documentation promptly if it fails a test. -* Make sure the source code reflects any changes to the policy (see [Maintain version control](maintain-version-control.md)). +## 公共政策制定者：需要的工作 -## Managers: what you need to do +* 儘早讓管理人員、開發人員與設計師一同加入，並且讓他們持續參與您政策的制定程序。 +* 確保政策文件也有設好自動化測試。 +* 如果政策文件未能通過測試，請快速修正。 +* 確保原始碼能反映出政策的任何變動（請參閱〈[維護版本控制](maintain-version-control.md)〉）。 -* Make sure to test with real end users as quickly and often as possible. -* Plan the work to integrate small parts very often instead of large parts less frequently. -* Procure consultancy services that deliver incrementally aligned with the plan. -* After a large failure, encourage publication of incident reports and public discussion of what was learned. +## 管理人員：需要的工作 -## Developers and designers: what you need to do +* 確保能儘快且經常給真正的終端使用者進行測試。 +* 以頻繁整合少量部分內容的方式做專案規劃，而非久久一次繳交大量部分內容。 +* 聘請有能力處理漸進式交付，並跟得上規劃進度的顧問服務。 +* 發生重大失誤後，鼓勵公開事故報告，以及公開討論事後學到的教訓。 -* Help managers structure the work plan such that it can be integrated as small increments. -* Help contributors limit the scope of their contributions and feature requests to be as small as reasonable. -* Help managers and policy makers test their contributions, for example by testing their contributions for broken links or style. -* Structure source code written to handle conditions which are difficult to create in a test environment in such a way that the conditions can be simulated during testing. Forms of resource exhaustion such as running out of storage space and memory allocation failure are typical examples of difficult to create conditions. -* Tune the test code coverage tools to avoid false alarms resulting from inlining or other optimizations. -* Deploy often. -* Integrate your work at least once a day. +## 開發人員與設計師：需要的工作 -## Further reading +* 協助管理人員擬定工作規劃，例如規劃成可以拆分成小部分逐次整合。 +* 協助貢獻者聚焦其貢獻內容與功能請求，讓涵蓋範圍盡可能合理地縮小。 +* 協助管理人員與政策制定者測試其貢獻內容，例如測試其貢獻內容中的失效連結或樣式。 +* 編排原始碼結構時，要將難以在測試環境下創造出來的情況，得以在測試過程中模擬出來。例如硬碟空間不足、記憶體分配失敗等資源耗盡情況，都是難以創造的典型案例。 +* 調整程式碼覆蓋率測試工具，避免在 inline 過程或其他最佳化處理時得到假警報。 +* 經常部署。 +* 至少每天整合工作內容一次。 -* [What is continuous integration](https://www.martinfowler.com/articles/continuousIntegration.html) by Martin Fowler. -* [Use continuous delivery](https://gds-way.cloudapps.digital/standards/continuous-delivery.html) by the UK Government Digital Service. -* [Quality assurance: testing your service regularly](https://www.gov.uk/service-manual/technology/quality-assurance-testing-your-service-regularly) by the UK Government Digital Service. +## 延伸閱讀 + +* Martin Fowler《[什麼是持續整 +合](https://www.martinfowler.com/articles/continuousIntegration.html)》。 +* 英國政府數位服務團《[使用持續交 +付](https://gds-way.cloudapps.digital/standards/continuous-delivery.html)》。 +* 英國政府數位服務團《[品質保證：定期測試您的服 +務](https://www.gov.uk/service-manual/technology/quality-assurance-testing-your-service-regularly)》。 diff --git a/criteria/use-open-standards.md b/criteria/use-open-standards.md index 13d26b8b..d8cae67b 100644 --- a/criteria/use-open-standards.md +++ b/criteria/use-open-standards.md @@ -5,42 +5,45 @@ order: 11 redirect_from: - criteria/open-standards --- -# Use open standards -[Open standards](../glossary.md#open-standard) guarantee access to the knowledge required to use and contribute to the [codebase](../glossary.md#codebase). -They enable interoperability between systems and reduce the risk of vendor lock-in. -Open standards which are unambiguous allow for independent development of either side of data exchange. +# 採用開放標準 -## Requirements +[開放標準](../glossary.md#open-standard)保證可以取得使用與貢獻[程式基底](../glossary.md#codebase)所需的知 +識。不僅能為不同的系統之間建立互通性，更能降低廠商套牢的可能性。開放標準如果明確，不同方就可以各自獨立開發作資料交換。 -* For features of the codebase that facilitate the exchange of data the codebase MUST use an open standard that meets the [Open Source Initiative Open Standard Requirements](https://opensource.org/osr). -* Any non-open standards used MUST be recorded clearly as such in the documentation. -* Any standard chosen for use within the codebase MUST be listed in the documentation with a link to where it is available. -* Any non-open standards chosen for use within the codebase MUST NOT hinder collaboration and reuse. -* If no existing open standard is available, effort SHOULD be put into developing one. -* Open standards that are machine testable SHOULD be preferred over open standards that are not. -* Non-open standards that are machine testable SHOULD be preferred over non-open standards that are not. +## 需求規定 -## How to test +* 程式基底如要促進資料交換的特性，就「必須」採用符合 [OSI 開放原始碼促進會其《開放標準需求規範](https://opensource.org/osr)》的 +開放標準。 +* 如果有使用到任何非開放標準，則「必須」在文件中清楚記錄。 +* 程式基底選擇採用的任何標準，皆「必須」在文件中列出，並且只要有的話，就附上該標準的連結。 +* 程式基底選擇採用的任何非開放標準，皆「禁止」妨礙程式基底的協作與重複使用。 +* 如果還沒有已存在的開放標準可採用，則「應該」投入開發新標準。 +* 採用開放標準時，「應該」優先選擇可經機器測試的開放標準。 +* 採用非開放標準時，「應該」優先選擇可經機器測試的非開放標準。 -* Confirm that data exchange follows an OSI approved open standard. -* Confirm that any non-open standards used are clearly documented as such. -* Confirm that documentation includes a list of the standards followed within the codebase, each with a working link, or a statement that no standards were chosen. +## 測試方式 -## Public policy makers: what you need to do +* 確認資料交換遵守 OSI 開放原始碼促進會批准的開放標準。 +* 確認若有採用任何的非開放標準，皆有清楚記錄在文件中。 +* 確認文件有清單列出程式基底所採用的標準，其中各標準有對應的有效連結；或沒有採用任何標準時，則留下聲明。 -* Mandate use of open standards everywhere possible. -* Prohibit procurement of technology that does not use open standards. +## 公共政策制定者：需要的工作 -## Managers: what you need to do +* 以政策要求盡可能在任何情況下採用開放標準。 +* 禁止採購不採用開放標準的技術科技。 -* Consider including open standard compliance assessment in [source code](../glossary.md#source-code) reviews. +## 管理人員：需要的工作 -## Developers and designers: what you need to do +* 考慮在[原始碼](../glossary.md#source-code)審查中納入開放標準依循評估。 -* Add [continuous integration](../glossary.md#continuous-integration) tests for compliance with the standards. -* Review the commits and other [repository](../glossary.md#repository) resources for references to standards and cross-check those with the standards listed. +## 開發人員與設計師：需要的工作 -## Further reading +* 將是否依循標準加入[持續整合](../glossary.md#continuous-integration)測試中。 +* 審查送交版次與[儲存庫](../glossary.md#repository)其他資源是否有參考開放標準，並交叉檢查其中有列出標準的部分。 -* [Open Standards principles](https://www.gov.uk/government/publications/open-standards-principles/open-standards-principles), [policy](../glossary.md#policy) paper of the UK Cabinet Office. +## 延伸閱讀 + +* 英國內閣辦公室發表的《[開放標準原 +則](https://www.gov.uk/government/publications/open-standards-principles/open-standards-principles)》 +[政策](../glossary.md#policy)報告。 diff --git a/criteria/use-plain-english.md b/criteria/use-plain-english.md index a5aee480..c6123aab 100644 --- a/criteria/use-plain-english.md +++ b/criteria/use-plain-english.md @@ -5,52 +5,58 @@ order: 10 redirect_from: - criteria/understandable-english-first --- -# Use plain English -English is the de facto language of collaboration in software development. +# 使用白話的英語 -Public sector information needs to be accessible to all its constituents. -Plain and simple language makes the [code](../glossary.md#code) and what it does easier to understand for a wider variety of people. +英語是軟體開發領域中的實際 協作語言。 -Translations further increase the possible reach of a [codebase](../glossary.md#codebase). -Language that is easy to understand lowers the cost of creating and maintaining translations. +公家機關資訊需要讓所有選民都能取用。簡單且白話的語言，能讓更多人能瞭解[程式碼](../glossary.md#code)與其功用。 -## Requirements +翻譯可以讓更多人有機會認識[程式基底](../glossary.md#codebase)。用語越是簡單明暸，製作與維護翻譯的成本就越低。 -* All codebase documentation MUST be in English. -* All [source code](../glossary.md#source-code) MUST be in English, except where [policy](../glossary.md#policy) is machine interpreted as code. -* All bundled policy not available in English MUST have an accompanying summary in English. -* Any translation MUST be up to date with the English version and vice versa. -* There SHOULD be no acronyms, abbreviations, puns or legal/non-English/domain specific terms in the codebase without an explanation preceding it or a link to an explanation. -* Documentation SHOULD aim for a lower secondary education reading level, as recommended by the [Web Content Accessibility Guidelines 2](https://www.w3.org/WAI/WCAG21/quickref/?showtechniques=315#readable). -* Providing a translation of any code, documentation or tests is OPTIONAL. +## 需求規定 -## How to test +* 程式基底的所有文件都「必須」使用英語。 +* 所有[原始碼](../glossary.md#source-code)都「必須」使用英語編寫，其中[政策](../glossary.md#policy)是由機器 +解讀當作程式碼的部分則除外。 +* 任何合捆的政策如果沒有英語版本，則「必須」隨附英語版摘要。 +* 任何翻譯版本皆「必須」跟隨英語版本更新，以維持在最新狀態，反之亦然。 +* 程式基底中「不應該」使用首字母縮字、縮寫、雙關語，或法律/非英語/行業特定詞彙；如果有的話，則需要在這些用語出現之前先行解釋，或是附上解釋該用語的網頁連結。 +* 根據《[網頁內容近用性無障礙指引 2](https://www.w3.org/WAI/WCAG21/quickref/? +showtechniques=315#readable)》的建議，文件內容「應該」以國中識讀程度為主。 +* 「可選擇」是否提供任何程式碼、文件、測試等的翻譯版。 -* Confirm that codebase documentation is available in English. -* Confirm that source code is in English, or confirm any non-English is policy or terms with preceding explanations. -* Confirm any non-English policy has an accompanying summary in English. -* Confirm that translations and the English version have the same content. -* Check that no unexplained acronyms, abbreviations, puns or legal/non-English/domain specific terms are in the documentation. -* Check the spelling, grammar and readability of the documentation. +## 測試方式 -## Public policy makers: what you need to do +* 確認程式基底文件有英語版本。 +* 確認原始碼為英語，確認任何非英語內容都是政策，或確認術語在其前方有先行說明等。 +* 確認任何非英語政策都有隨附英語版摘要。 +* 確認翻譯版與英語版內容相同。 +* 確認文件當中，沒有任何未說明的首字母縮寫字、縮寫、雙關語，或法律/非英語/行業特定詞彙等。 +* 檢查文件的拼字、文法與易讀性等。 -* Frequently test with other managers, developers and designers in the process if they understand what you are delivering and how you document it. +## 公共政策制定者：需要的工作 -## Managers: what you need to do +* 在過程中經常與其他管理人員、開發人員與設計師測試，確認他們是否瞭解您們正要交付的程式碼與其文件的內容。 -* Try to limit the use of acronyms, abbreviations, puns or legal/non-English/domain specific terms in internal communications in and between teams and stakeholders. Add any such terms to a glossary and link to it from the places they are being used. -* Be critical of documentation and descriptions in proposals and changes. If you don't understand something, others will probably also struggle with it. +## 管理人員：需要的工作 -## Developers and designers: what you need to do +* 在團隊內部與利害關係人之間的內部溝通中，試著限制首字母縮寫字、縮寫、雙關語，或法律/非英語/行業特定詞彙的使用。如果有使用到的話，則將這些用語加入詞彙表，並且在 +使用這些詞彙的地方加上詞彙表連結。 +* 以批判性觀點看待提案與修改當中的文件與描述。如果有您看不懂的內容，很有可能其他人也同樣迷惘。 -* Frequently test with policy makers and managers if they understand what you are delivering and how you document it. -* Ask someone outside of your context if they understand the content (for example, a developer working on a different codebase). +## 開發人員與設計師：需要的工作 + +* 經常與政策制定者和管理人員測試，確認他們是否瞭解您們正要交付的程式碼與其文件的內容。 +* 詢問身處不同背景情境的人（像是另一個程式基底的開發人員）是否能瞭解內容。

-## Further reading -* Meeting the [Web Content Accessibility Guidelines 2.1, Guideline 3.1 Readable](https://www.w3.org/TR/WCAG21/#readable) by W3C makes text content readable and understandable. -* The[European Union accessibility directive](https://ec.europa.eu/digital-single-market/en/web-accessibility) by the European Commission, is an example of regulation requiring high accessibility. -* [Definition of plain language](https://www.plainlanguage.gov/about/definitions/) by United States General Services Administration. +## 延伸閱讀 + +* 符合 W3C 全球資訊網協會《[網頁內容近用性無障礙指引 2.1、3.1 之可讀 +性](https://www.w3.org/TR/WCAG21/#readable)》要求，撰寫的文字內容要容易閱讀與理解。 +* 歐盟委員會的《[歐盟無障礙環境命 +令](https://ec.europa.eu/digital-single-market/en/web-accessibility)》，是高度要求無障礙環境 +的法規範例。 +* 美國總務署《[白話語言定義](https://www.plainlanguage.gov/about/definitions/)》。 diff --git a/criteria/welcome-contributors.md b/criteria/welcome-contributors.md index d8b8ce89..4f2727de 100644 --- a/criteria/welcome-contributors.md +++ b/criteria/welcome-contributors.md @@ -5,58 +5,60 @@ order: 4 redirect_from: - criteria/open-to-contributions --- -# Welcome contributors -The atmosphere in a [codebase](../glossary.md#codebase) community helps users decide to use one codebase over another. -Welcoming anyone as a contributor enables the community to grow and sustain itself over time. -A community where contributors have clear ways to influence codebase and community goals and progress is less likely to split and end up in diverging communities. -Newcomers need to understand and trust the codebase community’s governance. +# 歡迎貢獻者 -## Requirements +[程式基底](../glossary.md#codebase)社群的氛圍，會影響使用者選擇所要使用的程式基底。歡迎任何人成為貢獻者的社群，才能夠不斷茁壯並且持續自我 +運作。若貢獻者有明確的方法可以影響程式基底、社群目標與進展，則該社群分裂成分歧的社群的機率也較低。新參與者需要瞭解並信任程式基底社群的治理方式。 -* The codebase MUST allow anyone to submit suggestions for changes to the codebase. -* The codebase MUST include contribution guidelines explaining what kinds of contributions are welcome and how contributors can get involved, for example in a `CONTRIBUTING` file. -* The codebase MUST document the governance of the codebase, contributions and its community, for example in a `GOVERNANCE` file. -* The contribution guidelines SHOULD document who is expected to cover the costs of reviewing contributions. -* The codebase SHOULD advertise the committed engagement of involved organizations in the development and maintenance. -* The codebase SHOULD have a publicly available roadmap. -* The codebase SHOULD publish codebase activity statistics. -* Including a code of conduct for contributors in the codebase is OPTIONAL. +## 需求規定 -## How to test +* 程式基底必須「允許」任何人對程式基底提出修改建議。 +* 程式基底「必須」包含貢獻指引，說明歡迎貢獻的內容類型，以及貢獻者可如何參與開發，例如以「`CONTRIBUTING`」檔案說明。 +* 程式基底「必須」以文件記錄程式基底、貢獻內容與社群互動等的治理方式，例如以「`GOVERNANCE`」檔案來說明。 +* 貢獻指引「應該」以文件記錄預期由何者負擔審查貢獻內容所需的開銷費用。 +* 程式基底「應該」宣布投入其開發與維護工作的參與組織單位。 +* 程式基底「應該」要有可公開取得的發展路線圖。 +* 程式基底「應該」公布程式基底的活動統計數據。 +* 「可選擇」是否為程式基底加入貢獻者的行為守則。 -* Confirm that it is possible to submit suggestions for changes to the codebase. -* Confirm there are contribution guidelines. -* Confirm that the codebase governance is clearly explained, including how to influence codebase governance. -* Check that contributing guidelines cover who is expected to cover the costs of reviewing contributions. -* Check for a list of involved organizations. -* Check for a roadmap. -* Check for published activity statistics. -* Check for a code of conduct. +## 測試方式 -## Public policy makers: what you need to do +* 確認可以提交修改建議給程式基底。 +* 確認程式基底有貢獻指引。 +* 確認程式基底有清楚解釋治理架構，並包含如何影響程式基底治理的方法。 +* 確認貢獻指引是否有涵蓋預期由何者負擔審查貢獻內容的開銷費用。 +* 檢查是否有參與的組織單位名單。 +* 檢查是否有發展路線圖。 +* 檢查是否有公布活動統計數據。 +* 檢查是否有行為守則。 -* Add a list to the codebase of any other resources that [policy](../glossary.md#policy) experts, non-governmental organizations and academics would find useful for understanding or reusing your policy. -* Consider adding contact details so that other policy makers considering collaboration can ask you for advice. +## 公共政策制定者：需要的工作 -## Managers: what you need to do +* 為程式基底加入其他資源的清單，而這些資源可幫助[政策](../glossary.md#policy)專家、非政府組織、學者等，更能瞭解或可重複利用您的政策。 +* 考慮放入聯絡資訊，讓其他考慮合作的政策制定者能徵詢您的意見。 -* Make sure that the documentation of the governance includes the current process for how to make changes to the governance. -* If the community has some consensus about how the governance should change, then include those ideas stated as ambitions in the documentation. -* If needed, make sure you have allocated budget for the contributions review process as agreed by the codebase community. -* Make sure the documentation explains how each organization is involved in the codebase, what resources it has available for it and for how long. -* Support your experienced policy makers, developers and designers to stay part of the community for as long as possible. +## 管理人員：需要的工作 + +* 確保治理架構文件內容中，有包含目前如何改變治理狀態的流程。 +* 如果社群對於治理架構應該如何改變有共識，則應該將這些構想宣告為願景寫入文件中。 +* 若有需要，確認您有編列貢獻內容審查流程的預算，且經過程式基底社群同意。 +* 確認文件有解釋每個參與組織單位所投入的內容，例如提供程式基底哪些資源，以及參與的時間長度等。 +* 支持您經驗豐富的政策制定者、開發人員與設計師，使其盡可能長久參與社群。

-## Developers and designers: what you need to do -* Respond promptly to requests. -* Keep your managers informed of the time and resources you require to support other contributors. -* Communicate clearly to contributors what they need to do make sure their contribution can be integrated. +## 開發人員與設計師：需要的工作 + +* 快速回應請求。 +* 告知管理人員，您在支援其他貢獻者時所需的時間與資源。 +* 清楚告知貢獻者他們該如何做，才能讓貢獻內容整合到程式基底中。 -## Further reading +## 延伸閱讀 -* [Building welcoming communities](https://opensource.guide/building-community/) by Open Source Guides. -* [The Open Source Contributor Funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/) by Mike McQuaid. -* [Leadership and governance](https://opensource.guide/leadership-and-governance/) for growing [open source](../glossary.md#open-source) community projects, by Open Source Guides. -* [Building online communities](http://hintjens.com/blog:117) by Pieter Hintjens (long read!). +* 開放原始碼指引所提供的《[營造友善的社群](https://opensource.guide/building-community/)》。 +* Mike McQuaid《[開放原始碼貢獻者瓶 +頸](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/)》。 +* 開放原始碼指引針對推動[開放原始碼](../glossary.md#open-source)社群專案所寫的《[領導與治 +理](https://opensource.guide/leadership-and-governance/)》。 +* Pieter Hintjens《[打造網路社群](http://hintjens.com/blog:117)》(長篇文章！)。 diff --git a/criteria_source/bundle-policy-and-code.md b/criteria_source/bundle-policy-and-code.md new file mode 100644 index 00000000..0459e97f --- /dev/null +++ b/criteria_source/bundle-policy-and-code.md @@ -0,0 +1,57 @@ +--- +order: 2 +--- +# Bundle policy and source code + + + + +## Requirements + +* The [codebase](../glossary.md#codebase) MUST include the [policy](../glossary.md#policy) that the source [code](../glossary.md#code) is based on. +* The codebase MUST include all source code that the policy is based on, unless used for fraud detection. +* Policy SHOULD be provided in machine readable and unambiguous formats. +* [Continuous integration](../glossary.md#continuous-integration) tests SHOULD validate that the source code and the policy are executed coherently. + +## Why this is important + +Access to both the source code and the policy documents is necessary for understanding and reuse of, as well as collaboration in, a codebase. +Understanding the context and the policies in that context is fundamental to understanding what problems a codebase is trying to solve and how it sets out to solve them. +To be able to evaluate whether to adopt a codebase in a new context, an organization will need to understand what process changes it must choose to make or how to contribute additional configurability to the existing solution in order to adapt it to the new context. + +## What this does not do + +* Guarantee that a codebase will reflect the bundled policy. +* Make sure packages comply with the local technical infrastructure or legal framework of a given public organization. + +## How to test + +* Confirm with a civil servant that all policy that the source code is based on is included. +* Confirm with a civil servant that all source code that the policy is based on is included. +* Check if policy can be interpreted by a machine. +* Check the continuous integration tests for coherent execution of source code and policy pass. + +## Policy makers: what you need to do + +* Collaborate with developers and designers to ensure there is no mismatch between policy code and source code. +* Provide the relevant policy texts for inclusion in the [repository](../glossary.md#repository); if the text is not available in English, also provide an English summary. Be sure to include standards that your organization has chosen to adhere to and any organizational processes which impact the development or the deployment context of the codebase for your organization. +* Provide references and links to texts which support the policies. +* Document policy in formats that are unambiguous and machine-readable such as [Business Process Model and Notation](https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation), [Decision Model and Notation](https://en.wikipedia.org/wiki/Decision_Model_and_Notation) and [Case Management Model Notation](https://en.wikipedia.org/wiki/CMMN). +* Track policy with [the same version control](version-control-and-history.md) and documentation used to track source code. +* Check in regularly to understand how the non-policy code in the codebase has changed and whether it still matches the [intentions of the policy](document-objectives.md). + +## Management: what you need to do + +* Keep policy makers, developers and designers involved and connected throughout the whole development process. +* Make sure policy makers, developers and designers are working to the same objectives. + +## Developers and designers: what you need to do + +* Become familiar with and be able to use the process modelling notation that the policy makers in your organization use. +* Work together with policy makers to ensure there is no mismatch between policy code and source code. +* Give feedback on how to make policy documentation more clear. + +## Further reading + +* [Free online tools for building BPMN, CMMN and DMN diagrams at bmpn.io](https://bpmn.io/) by Camunda. +* [BPMN Quick Guide](https://www.bpmnquickguide.com/view-bpmn-quick-guide/) by Trisotech. diff --git a/criteria_source/code-in-the-open.md b/criteria_source/code-in-the-open.md new file mode 100644 index 00000000..5498e624 --- /dev/null +++ b/criteria_source/code-in-the-open.md @@ -0,0 +1,59 @@ +--- +order: 1 +--- +# Code in the open + + + + +## Requirements + +* All source [code](../glossary.md#code) for any [policy](../glossary.md#policy) in use (unless used for fraud detection) MUST be published and publicly accessible. +* All source code for any software in use (unless used for fraud detection) MUST be published and publicly accessible. +* Contributors MUST NOT upload sensitive information regarding users, their organization or third parties to the [repository](../glossary.md#repository). +* Any source code not currently in use (such as new versions, proposals or older versions) SHOULD be published. +* Documenting which source code or policy underpins any specific interaction the [general public](../glossary.md#general-public) may have with an organization is OPTIONAL. + +## Why this is important + +Coding in the open: + +* improves transparency +* increases code quality +* facilitates the auditing processes + +These aspects together create more opportunities for citizens to understand how software and policy impact their interactions with a public organization. + +## What this does not do + +* Make source code or policy reusable. +* Make the [codebase](../glossary.md#codebase) and the code within it understandable to as many people as possible. + +## How to test + +* Confirm that the source for each version currently in use is published on the internet where it can be seen from outside the original contributing organization and without the need for any form of authentication or authorization. +* Confirm that the codebase files and commit history do not include sensitive information. +* Check for the publication of source code not currently in use. + +## Policy makers: what you need to do + +* Develop policies in the open. +* Prioritize open and transparent policies. + +## Management: what you need to do + +* Develop a culture that embraces openness, learning and feedback. +* Collaborate with external vendors and freelancers by working in the open. + +## Developers and designers: what you need to do + +* As a reviewer, for each commit, verify that content does not include sensitive information such as configurations, usernames or passwords, public keys or other real credentials used in production systems. +* Clearly split data and code, in order to meet the requirement about sensitive information above. + +## Further reading + +* [Coding in the open](https://gds.blog.gov.uk/2012/10/12/coding-in-the-open/) by the UK Government Digital Service. +* [When code should be open or closed](https://www.gov.uk/government/publications/open-source-guidance/when-code-should-be-open-or-closed) by the UK Government Digital Service. +* [Security considerations when coding in the open](https://www.gov.uk/government/publications/open-source-guidance/security-considerations-when-coding-in-the-open) by the UK Government Digital Service. +* [Deploying software regularly](https://www.gov.uk/service-manual/technology/deploying-software-regularly) by the UK Government Digital Service. +* [How GDS uses GitHub](https://gdstechnology.blog.gov.uk/2014/01/27/how-we-use-github/) by the UK Government Digital Service. diff --git a/criteria_source/continuous-integration.md b/criteria_source/continuous-integration.md new file mode 100644 index 00000000..d45d2fba --- /dev/null +++ b/criteria_source/continuous-integration.md @@ -0,0 +1,76 @@ +--- +order: 12 +--- +# Use continuous integration + + + + +## Requirements + +* All functionality in the source [code](../glossary.md#code) MUST have automated tests. +* Contributions MUST pass all automated tests before they are admitted into the [codebase](../glossary.md#codebase). +* The codebase MUST have guidelines explaining how to structure contributions. +* The codebase MUST have active contributors. +* The codebase guidelines SHOULD state that each contribution should focus on a single issue. +* Source code test and documentation coverage SHOULD be monitored. +* Testing [policy](../glossary.md#policy) and documentation for consistency with the source and vice versa is OPTIONAL. +* Testing policy and documentation for style and broken links is OPTIONAL. + +## Why this is important + +* Using [continuous integration](../glossary.md#continuous-integration): + * allows you to quickly identify problems with the codebase, + * enables risk taking and focusing on problem solving while minimizing stress for the contributors, + * lowers barriers for new contributors by reducing the amount of understanding necessary to suggest changes, + * leads to more maintainable code, + * speeds up the development cycle. +* Smaller, more regular contributions are typically easier to evaluate and lower risk compared to large infrequent changes. +* Codebases in active development more reliably provide opportunities for collaboration and feedback. + +## What this does not do + +* Create a fault tolerant infrastructure that will work and scale perfectly. +* Create meaningful tests. +* Test for real life situations. +* Guarantee the code will deliver exactly the same policy result. + +## How to test + +* Confirm that there are tests present. +* Confirm that code coverage tools check that coverage is at 100% of the code. +* Confirm that contributions are only admitted into the codebase after all of the tests are passed. +* Confirm that contribution guidelines explain how to structure contributions. +* Confirm that there are contributions from within the last three months. +* Check if code coverage data is published. + +## Policy makers: what you need to do + +* Involve management as well as developers and designers as early in the process as possible and keep them engaged throughout development of your policy. +* Make sure there are also automated tests set up for policy documentation. +* Fix policy documentation promptly if it fails a test. +* Make sure the code reflects any changes to the policy (see [Maintain version control](version-control-and-history.md)). + +## Management: what you need to do + +* Make sure to test with real end users as quickly and often as possible. +* Plan the work to deliver small parts very often instead of large parts less frequently. +* Procure consultancy services that deliver incrementally aligned with the plan. +* After a large failure, encourage publication of incident reports and public discussion of what was learned. + +## Developers and designers: what you need to do + +* Help management structure the work plan such that it can be delivered as small increments. +* Help contributors limit the scope of their contributions and feature requests to be as small as reasonable. +* Help management and policy makers test their contributions, for example by testing their contributions for broken links or style. +* Structure code written to handle conditions which are difficult to create in a test environment in such a way that the conditions can be simulated during testing. Forms of resource exhaustion such as running out of storage space and memory allocation failure are typical examples of difficult to create conditions. +* Tune the test code coverage tools to avoid false alarms resulting from inlining or other optimizations. +* Deploy often. +* Integrate your work at least once a day. + +## Further reading + +* [What is continuous integration](https://www.martinfowler.com/articles/continuousIntegration.html) by Martin Fowler. +* [What is continuous delivery](https://www.continuousdelivery.com/) by Jez Humble. +* [Use continuous delivery](https://gds-way.cloudapps.digital/standards/continuous-delivery.html) by the UK Government Digital Service. +* [Quality assurance: testing your service regularly](https://www.gov.uk/service-manual/technology/quality-assurance-testing-your-service-regularly) by the UK Government Digital Service. diff --git a/criteria_source/document-maturity.md b/criteria_source/document-maturity.md new file mode 100644 index 00000000..fb57a06e --- /dev/null +++ b/criteria_source/document-maturity.md @@ -0,0 +1,59 @@ +--- +order: 16 +redirect_from: + - criteria/advertise-maturity +--- +# Document codebase maturity + + + + +## Requirements + +* The [codebase](../glossary.md#codebase) MUST be versioned. +* The codebase that is ready to use MUST only depend on other codebases that are also ready to use. +* The codebase that is not yet ready to use MUST have one of the labels: prototype, alpha, beta or pre-release version. +* The codebase SHOULD contain a log of changes from version to version, for example in the `CHANGELOG`. + +## Why this is important + +Clearly signalling a codebase's maturity helps others decide whether to reuse, invest in or contribute to it. + +## What this does not do + +* Guarantee that others will use the [code](../glossary.md#code). + +## How to test + +* Confirm that the codebase has a strategy for versioning which is documented. +* Confirm that it is clear where to get the newest version. +* Confirm that the codebase doesn't depend on any codebases marked with a less mature status. +* Confirm that the codebase is ready to use or labeled as prototype, alpha, beta or pre-release version. +* Check that there is a log of changes. + +## Policy makers: what you need to do + +* When developing [policy](../glossary.md#policy), understand that any code developed needs to be tested and improved before it can be put into service. +* Consider versioning policy changes, especially when they trigger new versions of the source code. + +## Management: what you need to do + +* Make sure that services only rely on codebases of equal or greater maturity than the service. For example, don't use a beta codebase in a production service or a prototype codebase in a beta service. +* If the codebase is not ready for general use, work with the developers to ensure the codebase is properly labeled: + * prototype: to test the look and feel, and to internally prove the concept of the technical possibilities, + * alpha: to do guided tests with a limited set of users, + * beta: to open up testing to a larger section of the [general public](../glossary.md#general-public), for example to test if the codebase works at scale, + * pre-release version: code that is ready to be released but hasn't received formal approval yet. + +## Developers and designers: what you need to do + +* Add a prominent header to every interface that indicates the maturity level of the code. +* Version all releases. +* Especially in 'rolling release' scenarios, the version may be automatically derived from the [version control](../glossary.md#version-control) system metadata (for example by using [git describe](https://git-scm.com/docs/git-describe)). + +## Further reading + +* [Service Design and Delivery Process](https://www.dta.gov.au/help-and-advice/build-and-improve-services/service-design-and-delivery-process) by the Australian Digital Transformation Agency. +* [Service Manual on Agile Delivery](https://www.gov.uk/service-manual/agile-delivery) by the UK Government Digital Service. +* [Semantic Versioning Specification](https://semver.org/) used by many codebases to label versions. +* [What are the Discovery, Alpha, Beta and Live stages in developing a service? [Video 0'0"59]](https://www.youtube.com/watch?v=_cyI7DMhgYc) by the UK Government Digital Service. diff --git a/criteria_source/document-objectives.md b/criteria_source/document-objectives.md new file mode 100644 index 00000000..b896b93a --- /dev/null +++ b/criteria_source/document-objectives.md @@ -0,0 +1,49 @@ +--- +order: 8 +--- +# Document codebase objectives + + + + +## Requirements + +* The [codebase](../glossary.md#codebase) MUST contain documentation of its objectives, like a mission and goal statement, that is understandable by developers and designers so that they can use or contribute to the codebase. +* Codebase documentation SHOULD clearly describe the connections between [policy](../glossary.md#policy) objectives and codebase objectives. +* Documenting the objectives of the codebase for the [general public](../glossary.md#general-public) is OPTIONAL. + +## Why this is important + +Documenting codebase objectives: + +* provides an easy way for people to decide whether this codebase, or one of its modules, is interesting for them now or in the future. +* helps scope your own development. +* clearly communicates to other stakeholders and contributors the purpose of the codebase and the modules of which it is composed. + +## What this does not do + +* Guarantee that the codebase achieves the stated objective(s). +* Guarantee contributions to the codebase. +* Prevent other codebases from attempting to achieve the same objectives. + +## How to test + +* Confirm that the codebase documentation includes the codebase objectives, mission or goal. +* Check for descriptions of connections between policy objectives and codebase objectives. + +## Policy makers: what you need to do + +* Add the policy objectives to the codebase documentation, for example in the `README`. +* Include relevant policies which impact the community, codebase, and development like value and ethics based policies, for example accessibility or equal opportunity. + +## Management: what you need to do + +* Add the organizational and business objectives to the codebase documentation, for example in the `README`. + +## Developers and designers: what you need to do + +* Add the technology and design objectives to the codebase documentation, for example in the `README`. + +## Further reading + +* [How to write project objectives](http://grouper.ieee.org/groups/802/3/RTPGE/public/may12/hajduczenia_01_0512.pdf) by Marek Hajduczenia. diff --git a/criteria_source/documenting.md b/criteria_source/documenting.md new file mode 100644 index 00000000..a7afa067 --- /dev/null +++ b/criteria_source/documenting.md @@ -0,0 +1,60 @@ +--- +order: 9 +--- +# Document the code + + + + +## Requirements + +* All of the functionality of the [codebase](../glossary.md#codebase), [policy](../glossary.md#policy) as well as source, MUST be described in language clearly understandable for those that understand the purpose of the [code](../glossary.md#code). +* The documentation of the codebase MUST contain a description of how to install and run the source code. +* The documentation of the codebase MUST contain examples demonstrating the key functionality. +* The documentation of the codebase SHOULD contain a high level description that is clearly understandable for a wide audience of stakeholders, like the [general public](../glossary.md#general-public) and journalists. +* The documentation of the codebase SHOULD contain a section describing how to install and run a standalone version of the source code, including, if necessary, a test dataset. +* The documentation of the codebase SHOULD contain examples for all functionality. +* The documentation SHOULD describe the key components or modules of the codebase and their relationships, for example as a high level architectural diagram. +* There SHOULD be [continuous integration](../glossary.md#continuous-integration) tests for the quality of the documentation. +* Including examples that make users want to immediately start using the codebase in the documentation of the codebase is OPTIONAL. +* Testing the code by using examples in the documentation is OPTIONAL. + +## Why this is important + +* Users can start using and contributing more quickly. +* You help people discover the codebase, especially people asking 'is there already code that does something like this'. +* This provides transparency into your organization and processes. + +## What this does not do + +* Contribute directly to more reusable, portable code (see [Create reusable and portable code](./reusable-and-portable-codebases.md)). + +## How to test + +* Confirm that other stakeholders, professionals from other public organizations and the general public find the documentation clear and understandable. +* Confirm that the documentation describes how to install and run the source code. +* Confirm that the documentation includes examples of the key functionality. +* Check with members of the general public and journalists if they can understand the high level description. +* Check that the instructions for how to install and run a standalone version of the source code result in a running system. +* Check that all functionality documented contains an example. +* Check that the documentation includes a high level architectural diagram or similar. +* Check that the documentation quality is part of integration testing, for example documentation is generated from code, and links and images are tested. + +## Policy makers: what you need to do + +* Check in regularly to understand how the non-policy code in the codebase has changed. +* Give feedback on how to make non-policy documentation more clear. + +## Management: what you need to do + +* Try to use the codebase. +* Make sure you understand both the policy and source code as well as the documentation. + +## Developers and designers: what you need to do + +* Check in regularly to understand how the non-source code in the codebase has changed. +* Give feedback on how to make non-source documentation more clear. + +## Further reading + +* [Documentation guide](https://www.writethedocs.org/guide/) by Write the Docs. diff --git a/criteria_source/findability.md b/criteria_source/findability.md new file mode 100644 index 00000000..34451846 --- /dev/null +++ b/criteria_source/findability.md @@ -0,0 +1,66 @@ +--- +order: 14 +--- + +# Make the codebase findable + + + + +## Requirements + +* The [codebase](../glossary.md#codebase) MUST be findable using a search engine by describing the problem it solves in natural language. +* The codebase MUST be findable using a search engine by codebase name. +* Maintainers SHOULD submit the codebase to relevant software catalogs. +* The codebase SHOULD have a website which describes the problem the codebase solves using the preferred jargon of different potential users of the codebase (including technologists, policy experts and managers). +* The codebase SHOULD have a unique and persistent identifier where the entry mentions the major contributors, [repository](../glossary.md#repository) location and website. +* The codebase SHOULD include a machine-readable metadata description, for example in a [publiccode.yml](https://github.com/publiccodeyml/publiccode.yml) file. +* A dedicated domain name for the codebase is OPTIONAL. +* Regular presentations at conferences by the community are OPTIONAL. + +## Why this is important + +* Proactiveness is needed; just publishing a codebase and hoping it's found doesn't work. +* A metadata description file increases discoverability. +* The more findable a codebase is, the more potential new collaborators will find it. +* By having well-written metadata containing a unique and persistent identifer, such as a Wikidata item or FSF software directory listing, and thus being part of the semantic web, it will be easier for other people to refer, cite, disambiguate and discover the codebase through third party tools. + +## What this does not do + +* Ensure new collaborators or replicators. + +## How to test + +* Confirm that the codebase appears in the first set of results on more than one major search engine when searching by a plain English problem description. +* Confirm that the codebase appears in the first set of results on more than one major search engine when searching by a technical problem description. +* Confirm that the codebase appears in the first set of results on more than one major search engine when searching by the codebase name. +* Check for the codebase listing in relevant software catalogs. +* Check for a codebase website which describes the problem the codebase solves. +* Check unique and persistent identifier entries for mention of the major contributors. +* Check unique and persistent identifier entries for the repository location. +* Check unique and persistent identifier entries for the codebase website. +* Check for a machine-readable metadata description file. + +## Policy makers: what you need to do + +* Contribute a description of the policy area or problem this codebase acts on or operates. +* Test your problem description with peers outside of your context who aren't familiar with the codebase. +* Present on how the codebase implements the [policy](../glossary.md#policy) at relevent conferences. + +## Management: what you need to do + +* Budget for content design and Search Engine Optimization skills in the team. +* Ensure people involved in the project present at relevant conferences. +* Search trademark databases to avoid confusion or infringement before deciding the name. + +## Developers and designers: what you need to do + +* Search engine optimization. +* Test your problem description with peers outside of your context who aren't familiar with the codebase. +* Suggest conferences to present at and present at them. + +## Further reading + +* [Introduction to Wikidata](https://www.wikidata.org/wiki/Wikidata:Introduction) by the Wikidata community. +* [FSF software directory listing](https://directory.fsf.org/wiki/Main_Page) by the Free Softare Foundation. +* The [FAIR Guiding Principles for scientific data management and stewardship](https://www.go-fair.org/fair-principles/) by the GO FAIR International Support and Coordination Office provide a nice list of attributes that make (meta)data more machine actionable (and hence more findable). Some of these apply directly to codebases, while others may provoke exploration into what the codebase equivalent would be. diff --git a/criteria_source/index.md b/criteria_source/index.md new file mode 100644 index 00000000..a76e29e4 --- /dev/null +++ b/criteria_source/index.md @@ -0,0 +1,10 @@ +# Criteria + + + + +{% assign sorted = site.pages | sort:"order" %} + +{% for page in sorted %}{% if page.dir == "/criteria/" %}{% if page.name != "index.md" %}{% if page.title %} + +1. [{{page.title}}]({{page.url}}){% endif%} {% endif%} {% endif%}{% endfor %} diff --git a/criteria_source/make-contributing-easy.md b/criteria_source/make-contributing-easy.md new file mode 100644 index 00000000..eed5999a --- /dev/null +++ b/criteria_source/make-contributing-easy.md @@ -0,0 +1,51 @@ +--- +order: 5 +--- +# Make contributing easy + + + + +## Requirements + +* The [codebase](../glossary.md#codebase) MUST have a public issue tracker that accepts suggestions from anyone. +* The codebase MUST include instructions for how to privately report security issues for responsible disclosure. +* The documentation MUST link to both the public issue tracker and submitted codebase changes, for example in a `README` file. +* The codebase MUST have communication channels for users and developers, for example email lists. +* The documentation SHOULD include instructions for how to report potentially security sensitive issues on a closed channel. + +## Why this is important + +* Enables users to fix problems and add features to the shared codebase leading to better, more reliable and feature rich software. +* Allows collaborative uptake of shared digital infrastructure. +* Helps users decide to use one codebase over another. + +## What this does not do + +* Guarantee others will reuse the codebase. + +## How to test + +* Confirm that there is a public issue tracker. +* Confirm that there are instructions for privately reporting security issues. +* Confirm that the codebase contains links to the public issue tracker and submitted codebase changes. +* Confirm that it is possible to participate in a discussion with other users and developers about the software using channels described in the codebase. + +## Policy makers: what you need to do + +* Track [policy](../glossary.md#policy) issues in the codebase, so that a relevant external policy expert can volunteer help. + +## Management: what you need to do + +* Track management issues in the codebase, so that external managers with relevant experience can volunteer help. +* Support your experienced policy makers, developers and designers to keep contributing to the codebase for as long as possible. + +## Developers and designers: what you need to do + +* Respond promptly to requests. +* Keep your management informed of the time and resources you require to support other contributors. + +## Further reading + +* [How to inspire exceptional contributions to your open-source project](https://dev.to/joelhans/how-to-inspire-exceptional-contributions-to-your-open-source-project-1ebf) by Joel Hans. +* [The benefits of coding in the open](https://gds.blog.gov.uk/2017/09/04/the-benefits-of-coding-in-the-open/) by the UK Government Digital Service. diff --git a/criteria_source/open-licenses.md b/criteria_source/open-licenses.md new file mode 100644 index 00000000..46674d1f --- /dev/null +++ b/criteria_source/open-licenses.md @@ -0,0 +1,54 @@ +--- +order: 13 +--- +# Publish with an open license + + + + +## Requirements + +* All [code](../glossary.md#code) and documentation MUST be licensed such that it may be freely reusable, changeable and redistributable. +* Software source code MUST be licensed under an [OSI-approved or FSF Free/Libre license](https://spdx.org/licenses/). +* All code MUST be published with a license file. +* Contributors MUST NOT be required to transfer copyright of their contributions to the [codebase](../glossary.md#codebase). +* All source code files in the codebase SHOULD include a copyright notice and a license header that are machine-readable. +* Having multiple licenses for different types of code and documentation is OPTIONAL. + +## Why this is important + +* Makes it possible for anyone to see the code and know that they can and how they can reuse it. + +## What this does not do + +* Prevent use of the code by any specific actors. + +## How to test + +* Confirm that the codebase is clearly licensed. +* Confirm that the license for the source code is on the [OSI-approved or FSF Free/Libre license list](https://spdx.org/licenses/) and the license for documentation [conforms to the Open Definition](https://opendefinition.org/licenses/). +* Confirm that the licenses used in the codebase are included as files. +* Confirm that contribution guidelines and [repository](../glossary.md#repository) configuration do not require transfer of copyright. +* Check for machine-readable license checking in the codebase [continuous integration](../glossary.md#continuous-integration) tests. + +## Policy makers: what you need to do + +* Develop [policy](../glossary.md#policy) that requires code to be [open source](../glossary.md#open-source). +* Develop policy that disincentivizes non-open source code and technology in procurement. + +## Management: what you need to do + +* Only work with open source vendors that deliver their code by publishing it under an open source license. +* Beware that even though [Creative Commons licenses](https://creativecommons.org/licenses/) are great for documentation, licenses that stipulate Non-Commercial or No Derivatives are NOT freely reusable, changeable and redistributable and don't fulfill these requirements. + +## Developers and designers: what you need to do + +* Add a new `license` file to every new codebase created. +* Add a copyright notice and a license header to every new source code file created. + +## Further reading + +* [Open source definition](https://opensource.org/osd) by the Open Source Initiative, all open source licenses meet this definition. +* [Animated video introduction to Creative Commons](https://creativecommons.org/about/videos/creative-commons-kiwi) by Creative Commons Aotearoa New Zealand. +* [REUSE Initiative specification](https://reuse.software/spec/) by Free Software Foundation Europe for unambiguous, human-readable and machine-readable copyright and licensing information. +* [SPDX License List](https://spdx.org/licenses/) by the Linux Foundation with standardized, machine-readable abbreviations for most licenses. diff --git a/criteria_source/open-standards.md b/criteria_source/open-standards.md new file mode 100644 index 00000000..06a262ec --- /dev/null +++ b/criteria_source/open-standards.md @@ -0,0 +1,50 @@ +--- +order: 11 +--- +# Use open standards + + + + +## Requirements + +* For features of the [codebase](../glossary.md#codebase) that facilitate the exchange of data the codebase MUST use an [open standard](../glossary.md#open-standard) that meets the [Open Source Initiative Open Standard Requirements](https://opensource.org/osr). +* Any non-open standards used MUST be recorded clearly as such in the documentation. +* Any standard chosen for use within the codebase MUST be listed in the documentation with a link to where it is available. +* Any non-open standards chosen for use within the codebase MUST NOT hinder collaboration and reuse. +* If no existing open standard is available, effort SHOULD be put into developing one. +* Standards that are machine testable SHOULD be preferred over those that are not. + +## Why this is important + +* Creates interoperability between systems. +* Reduces possible vendor lock-in. +* Guarantees access to the knowledge required to reuse and contribute to the codebase. + +## What this does not do + +* Make it understandable how to use the software. + +## How to test + +* Confirm that data exchange follows an OSI approved open standard. +* Confirm that any non-open standards used are clearly documented as such. +* Confirm that documentation includes a list of the standards followed within the codebase, each with a working link, or a statement that no standards were chosen. + +## Policy makers: what you need to do + +* Mandate use of open standards everywhere possible. +* Prohibit procurement of technology that does not use open standards. + +## Management: what you need to do + +* Consider including open standard compliance assessment in [code](../glossary.md#code) reviews. + +## Developers and designers: what you need to do + +* Add [continuous integration](../glossary.md#continuous-integration) tests for compliance with the standards. +* Review the commits and other [repository](../glossary.md#repository) resources for references to standards and cross-check those with the standards listed. + +## Further reading + +* [Open Standards principles](https://www.gov.uk/government/publications/open-standards-principles/open-standards-principles), [policy](../glossary.md#policy) paper of the UK Cabinet Office. diff --git a/criteria_source/open-to-contributions.md b/criteria_source/open-to-contributions.md new file mode 100644 index 00000000..b5a1b646 --- /dev/null +++ b/criteria_source/open-to-contributions.md @@ -0,0 +1,62 @@ +--- +order: 4 +--- +# Welcome contributors + + + + +## Requirements + +* The [codebase](../glossary.md#codebase) MUST allow anyone to submit suggestions for changes to the codebase. +* The codebase MUST include contribution guidelines explaining what kinds of contributions are welcome and how contributors can get involved, for example in a `CONTRIBUTING` file. +* The codebase MUST document the governance of the codebase, contributions and its community, for example in a `GOVERNANCE` file. +* The codebase SHOULD advertise the committed engagement of involved organizations in the development and maintenance. +* The codebase SHOULD have a publicly available roadmap. +* The codebase SHOULD publish codebase activity statistics. +* Including a code of conduct for contributors in the codebase is OPTIONAL. + +## Why this is important + +* Helps newcomers understand and trust the codebase community's leadership. +* Prevents the community that works on a codebase splitting because there is no way to influence its goals and progress, resulting in diverging communities. +* Helps users decide to use one codebase over another. + +## What this does not do + +* Guarantee others will join the community. +* Guarantee others will reuse the codebase. + +## How to test + +* Confirm that it is possible to submit suggestions for changes to the codebase. +* Confirm there are contribution guidelines. +* Confirm that the codebase governance is clearly explained, including how to influence codebase governance. +* Check for a list of involved organizations. +* Check for a roadmap. +* Check for published activity statistics. +* Check for a code of conduct. + +## Policy makers: what you need to do + +* Add a list to the codebase of any other resources that [policy](../glossary.md#policy) experts, non-governmental organizations and academics would find useful for understanding or reusing your policy. +* Consider adding contact details so that other policy makers considering collaboration can ask you for advice. + +## Management: what you need to do + +* Make sure that the documentation of the governance includes the current process for how to make changes to the governance. +* If the community has some consensus about how the governance should change, then include those ideas stated as ambitions in the documentation. +* Make sure the documentation explains how each organization is involved in the codebase, what resources it has available for it and for how long. +* Support your experienced policy makers, developers and designers to stay part of the community for as long as possible. + +## Developers and designers: what you need to do + +* Respond promptly to requests. +* Keep your management informed of the time and resources you require to support other contributors. + +## Further reading + +* [Building welcoming communities](https://opensource.guide/building-community/) by Open Source Guides. +* [The Open Source Contributor Funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/) by Mike McQuaid. +* [Leadership and governance](https://opensource.guide/leadership-and-governance/) for growing [open source](../glossary.md#open-source) community projects, by Open Source Guides. +* [Building online communities](http://hintjens.com/blog:117) by Pieter Hintjens (long read!). diff --git a/criteria_source/require-review.md b/criteria_source/require-review.md new file mode 100644 index 00000000..34608cba --- /dev/null +++ b/criteria_source/require-review.md @@ -0,0 +1,71 @@ +--- +order: 7 +--- +# Require review of contributions + + + + +## Requirements + +* All contributions that are accepted or committed to release versions of the [codebase](../glossary.md#codebase) MUST be reviewed by another contributor. +* Reviews MUST include source, [policy](../glossary.md#policy), tests and documentation. +* Reviewers MUST provide feedback on all decisions to not accept a contribution. +* Contributions SHOULD conform to the standards, architecture and decisions set out in the codebase in order to pass review. +* Reviews SHOULD include running both the [code](../glossary.md#code) and the tests of the codebase. +* Contributions SHOULD be reviewed by someone in a different context than the contributor. +* Version control systems SHOULD NOT accept non-reviewed contributions in release versions. +* Reviews SHOULD happen within two business days. +* Performing reviews by multiple reviewers is OPTIONAL. + +## Why this is important + +* Increases codebase quality. +* Reduces security risks as well as operational risks. +* Creates a culture of making every contribution great. +* Catches the most obvious mistakes that could happen. +* Gives contributors the security that their contributions are only accepted if they really add value. +* Assures contributors of a guaranteed time for feedback or collaborative improvement. +* Prompt reviews increase both rate of delivery and contributor engagement. + +## What this does not do + +* Guarantee the right solution to a problem. +* Mean that reviewers are liable. +* Absolve a contributor from writing documentation and tests. +* Provide you with the right reviewers. + +## How to test + +* Confirm that every commit in the history has been reviewed by a different contributor. +* Confirm that reviews include source, policy, tests and documentation. +* Confirm that rejected contributions were appropriately explained. +* Check if reviews cover conformance to standards, architecture and codebase guidelines. +* Check with reviewers if they run the code and tests during review. +* Check with reviewers if commits have been reviewed by a different contributor in a different context. +* Check for use of branch protection in the [version control](../glossary.md#version-control) system. +* Check the times between contribution submission and review. + +## Policy makers: what you need to do + +* Institute a 'four eyes' policy where everything, not just code, is reviewed. +* Use a version control system or methodology that enables review and feedback. + +## Management: what you need to do + +* Make delivering great code a shared objective. +* Make sure writing and reviewing contributions to source, policy, documentation and tests are considered equally valuable. +* Create a culture where all contributions are welcome and everyone is empowered to review them. +* Make sure no contributor is ever alone in contributing to a codebase. + +## Developers and designers: what you need to do + +* Ask other contributors on the codebase to review your work, in your organization or outside of it. +* Try to respond to others' requests for code review promptly, initially providing feedback about the concept of the change. + +## Further reading + +* [How to review code the GDS way](https://gds-way.cloudapps.digital/manuals/code-review-guidelines.html#content) by the UK Government Digital Service. +* Branch protection on [GitHub](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches) and [GitLab](https://about.gitlab.com/2014/11/26/keeping-your-code-protected/). +* [The Gentle Art of Patch Review](https://sage.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/) by Sage Sharp. +* [Measuring Engagement](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) by Mozilla. diff --git a/criteria_source/reusable-and-portable-codebases.md b/criteria_source/reusable-and-portable-codebases.md new file mode 100644 index 00000000..e6849ec5 --- /dev/null +++ b/criteria_source/reusable-and-portable-codebases.md @@ -0,0 +1,73 @@ +--- +order: 3 +--- +# Create reusable and portable code + + + + +## Requirements + +* The [codebase](../glossary.md#codebase) MUST be developed to be reusable in [different contexts](../glossary.md#different-contexts). +* The codebase MUST be independent from any secret, undisclosed, proprietary or non-open licensed [code](../glossary.md#code) or services for execution and understanding. +* The codebase SHOULD be in use by multiple parties. +* The roadmap SHOULD be influenced by the needs of multiple parties. +* Configuration SHOULD be used to make code adapt to context specific needs. +* The codebase SHOULD be localizable. +* Code and its documentation SHOULD NOT contain situation-specific information. +* Codebase modules SHOULD be documented in such a way as to enable reuse in codebases in other contexts. + +## Why this is important + +* Enables other policy makers, developers and designers to reuse what you've developed, to test it, to improve it and contribute those improvements back leading to better quality, cheaper maintenance and higher reliability. +* Makes the code easier for new people to understand (as it's more general). +* Makes it easier to control the mission, vision and scope of the codebase because the codebase is thoughtfully and purposefully designed for reusability. +* Codebases used by multiple parties are more likely to benefit from a self-sustaining community. +* Any contributor is able to test and contribute without relying on the situation-specific infrastructure of any other contributor or deployment. +* Composing a codebase from well documented modules improves reusability and maintainability. +* A module is easier to reuse in another context if its purpose is clearly documented. + +## What this does not do + +* Get others to reuse the codebase. +* Build a community. +* Shift responsibility for documentation, support, bug-fixing, etc. to another party. +* Guarantee that modules are generic enough to be reused in any context. + +## How to test + +* Confirm with someone in a similar role at another organization if they can reuse the codebase and what that would entail. +* Confirm that the codebase can run without using any proprietary or non open-licensed code or services. +* Check that the codebase is in use by multiple parties or in multiple contexts. +* Check that the codebase files and commit history do not include situation-specific data. + +## Policy makers: what you need to do + +* Document your [policy](../glossary.md#policy) with enough clarity and detail that it can be understood outside of its original context. +* Make sure your organization is listed as a known user by the codebase. + +## Management: what you need to do + +* Make sure that stakeholders and business owners understand that reusability is an explicit codebase goal as this reduces technical debt and provides sustainability for the codebase. + +## Developers and designers: what you need to do + +Source should be designed: + +* for reuse by other users and organizations regardless of locale, +* to solve a general problem instead of a specific one, +* in logically meaningful and isolated modules, +* so that someone in a similar organization facing a similar problem would be able to use (parts of) the solution. + +Ensure that the codebase documentation describes the build-time and runtime dependencies. +If your context requires deploying to proprietary platforms or using proprietary components, ensure that collaborators can develop, use, test, and deploy without them. + +For each commit, reviewers verify that content does not include situation-specific data such as hostnames, personal and organizational data, or tokens and passwords. + +## Further reading + +* [Making source code open and reusable](https://www.gov.uk/service-manual/technology/making-source-code-open-and-reusable) by the UK Government Digital Service. +* [OpenAPI Specification](https://spec.openapis.org/oas/latest.html) by the OpenAPI Initiative defines a standard, programming language-agnostic interface description for human and machine-readable HTTP APIs. +* [Localization vs. Internationalization](https://www.w3.org/International/questions/qa-i18n) by the World Wide Web Consortium. +* [Internationalization techniques: Authoring HTML & CSS](https://www.w3.org/International/techniques/authoring-html) by the World Wide Web Consortium. +* [GNU gettext](https://www.gnu.org/software/gettext/gettext.html) of the GNU Operating System. diff --git a/criteria_source/style.md b/criteria_source/style.md new file mode 100644 index 00000000..536ac0f1 --- /dev/null +++ b/criteria_source/style.md @@ -0,0 +1,53 @@ +--- +order: 15 +--- +# Use a coherent style + + + + +## Requirements + +* Contributions MUST adhere to either a coding or writing style guide, either the [codebase](../glossary.md#codebase) community's own or an existing one that is advertised in or part of the codebase. +* Contributions SHOULD pass automated tests on style. +* The codebase SHOULD include inline comments and documentation for non-trivial sections. +* Including sections on [understandable English](understandable-english-first.md) in the style guide is OPTIONAL. + +## Why this is important + +* Enables contributors in different environments to work together on a unified product. +* Unifying vocabularies reduces friction in communication between contributors. + +## What this does not do + +* Help contributors write well or effectively explain what they do. + +## How to test + +* Confirm that contributions are in line with the style guides specified in the documentation. +* Check for the presence of automated tests on style. + +## Policy makers: what you need to do + +* Create, follow and continually improve on a style guide for [policy](../glossary.md#policy) and documentation as well as document this in the codebase, for example in the `CONTRIBUTING` or `README`. + +## Management: what you need to do + +* Include written language, source, test and policy standards in your organizational definition of quality. + +## Developers and designers: what you need to do + +If the codebase does not already have engineering guidelines or other contributor guidance, start by adding documentation to the [repository](../glossary.md#repository) describing whatever is being done now, for example in the `CONTRIBUTING` or `README`. +An important purpose of the file is to communicate design preferences, naming conventions, and other aspects machines can't easily check. +Guidance should include what would be expected from [code](../glossary.md#code) contributions in order for them to be merged by the maintainers, including source, tests and documentation. +Continually improve upon and expand this documentation with the aim of evolving this documentation into engineering guidelines. + +Additionally: + +* Use a linter. +* Add linter configurations to the codebase. + +## Further reading + +* [List of linters](https://github.com/caramelomartins/awesome-linters) by Hugo Martins. +* [Programming style](https://en.wikipedia.org/wiki/Programming_style) on Wikipedia. diff --git a/criteria_source/understandable-english-first.md b/criteria_source/understandable-english-first.md new file mode 100644 index 00000000..fb334c34 --- /dev/null +++ b/criteria_source/understandable-english-first.md @@ -0,0 +1,58 @@ +--- +order: 10 +--- +# Use plain English + + + + +## Requirements + +* All [codebase](../glossary.md#codebase) documentation MUST be in English. +* All [code](../glossary.md#code) MUST be in English, except where [policy](../glossary.md#policy) is machine interpreted as code. +* All bundled policy not available in English MUST have an accompanying summary in English. +* Any translation MUST be up to date with the English version and vice versa. +* There SHOULD be no acronyms, abbreviations, puns or legal/non-English/domain specific terms in the codebase without an explanation preceding it or a link to an explanation. +* The name of the codebase SHOULD be descriptive and free from acronyms, abbreviations, puns or organizational branding. +* Documentation SHOULD aim for a lower secondary education reading level, as recommended by the [Web Content Accessibility Guidelines 2](https://www.w3.org/WAI/WCAG21/quickref/?showtechniques=315#readable). +* Providing a translation of any code, documentation or tests is OPTIONAL. + +## Why this is important + +* Makes the codebase and what it does understandable for a wider variety of stakeholders in multiple contexts. +* Helps with the discoverability of the codebase. +* Can help you meet the [European Union accessibility directive](https://ec.europa.eu/digital-single-market/en/web-accessibility), which requires most public sector information to be accessible. + +## What this does not do + +* Make explanations of the codebase's functionality understandable. +* Make your organization's jargon understandable without an explanation. + +## How to test + +* Confirm that codebase documentation is available in English. +* Confirm that source code is in English, or confirm any non-English is policy or terms with preceding explanations. +* Confirm any non-English policy has an accompanying summary in English. +* Confirm that translations and the English version have the same content. +* Check that no unexplained acronyms, abbreviations, puns or legal/non-English/domain specific terms are in the documentation. +* Check the spelling, grammar and readability of the documentation. + +## Policy makers: what you need to do + +* Frequently test with other management, developers and designers in the process if they understand what you are delivering and how you document it. + +## Management: what you need to do + +* Try to limit the use of acronyms, abbreviations, puns or legal/non-English/domain specific terms in internal communications in and between teams and stakeholders. Add any such terms to a glossary and link to it from the places they are being used. +* Be critical of documentation and descriptions in proposals and changes. If you don't understand something, others will probably also struggle with it. + +## Developers and designers: what you need to do + +* Frequently test with policy makers and management if they understand what you are delivering and how you document it. +* Ask someone outside of your context if they understand the content (for example, a developer working on a different codebase). + +## Further reading + +* Text of the [Web Content Accessibilty Guidelines 2.1, Guideline 3.1 Readable](https://www.w3.org/TR/WCAG21/#readable) by W3C, make text content readable and understandable. +* [Upgoer 5 text editor](https://splasho.com/upgoer5/) by Theo Sanderson, only allows 1000 most common English words. +* [Definition of plain language](https://www.plainlanguage.gov/about/definitions/) by United States General Services Administration. diff --git a/criteria_source/version-control-and-history.md b/criteria_source/version-control-and-history.md new file mode 100644 index 00000000..6529d33b --- /dev/null +++ b/criteria_source/version-control-and-history.md @@ -0,0 +1,74 @@ +--- +order: 6 +--- +# Maintain version control + + + + +## Requirements + +* The community MUST have a way to maintain [version control](../glossary.md#version-control) for the [code](../glossary.md#code). +* All files in the [codebase](../glossary.md#codebase) MUST be version controlled. +* All decisions MUST be documented in commit messages. +* Every commit message MUST link to discussions and issues wherever possible. +* The codebase SHOULD be maintained in a distributed version control system. +* Contributors SHOULD group relevant changes in commits. +* Maintainers SHOULD mark released versions of the codebase, for example using revision tags or textual labels. +* Contributors SHOULD prefer file formats where the changes within the files can be easily viewed and understood in the version control system. +* It is OPTIONAL for contributors to sign their commits and provide an email address, so that future contributors are able to contact past contributors with questions about their work. + +## Why this is important + +Version control means keeping track of changes to the code over time. This allows you to create structured documentation of the history of the codebase. This is essential for collaboration at scale. + +Distributed version control enables you to: + +* have a full copy of the code and its history +* revert to an earlier version of the codebase whenever you want to +* record your changes and the reasons why you made them, to help future developers understand the process +* compare two different versions +* work on changes in parallel as a team before merging them together +* continue to work when the network is unavailable, merging changes back with everyone else’s at a later date + +## What this does not do + +* Substitute for [advertising maturity](document-maturity.md). +* Guarantee the code executes correctly. +* Guarantee collaborators. + +## How to test + +* Confirm that the codebase is kept in version control using software such as Git. +* Review the commit history, confirming that all commit messages explain why the change was made. +* Review the commit history, confirming that where possible all commit messages include the discussion about the change was or where to find it (with a URL). +* Check if the version control system is distributed. +* Review the commit history, check if grouping of relevant changes in accordance with the contributing guidelines. +* Check that it is possible to access a specific version of the codebase, for example through a revision tag or a textual label. +* Check that the file formats used in the codebase are text formats where possible. + +## Policy makers: what you need to do + +* If a new version of the codebase is created because of a [policy](../glossary.md#policy) change, make sure it's clear in the documentation: + * what the policy change is, + * how it's changed the codebase. + +For example, adding a new category of applicant to a codebase that manages granting permits would be considered a policy change. + +## Management: what you need to do + +* Support policy makers, developers and designers to be clear about what improvements they're making to the codebase. Making improvements isn't a public relations risk. + +## Developers and designers: what you need to do + +* Write clear commit messages so that it is easy to understand why the commit was made. +* Mark different versions so that it is easy to access a specific version, for example using revision tags or textual labels. +* Write clear commit messages so that versions can be usefully compared. +* Work with policy makers to describe how the source code was updated after a policy change. + +## Further reading + +* [Producing OSS: Version Control Vocabulary](https://producingoss.com/en/vc.html#vc-vocabulary) by Karl Fogel. +* [Maintaining version control in coding](https://www.gov.uk/service-manual/technology/maintaining-version-control-in-coding) by the UK Government Digital Service. +* [GitHub Learning Lab](https://lab.github.com/) by GitHub for learning how to use it or refresh your skills. +* [Git Cheat Sheet](https://education.github.com/git-cheat-sheet-education.pdf) by GitHub, a list with the most common used git commands. diff --git a/docker.sh b/docker.sh new file mode 100644 index 00000000..b5f3ab98 --- /dev/null +++ b/docker.sh @@ -0,0 +1,9 @@ +#!/bin/bash + +path=`pwd` +docker run -d \ + -v ${path}:/var/www/html \ + -v ${path}/docker/apache-data:/etc/apache2/sites-available \ + -p 8090:80 \ + --name=standard \ + steps/standard diff --git a/docker/apache-data/000-default.conf b/docker/apache-data/000-default.conf new file mode 100644 index 00000000..72b4196e --- /dev/null +++ b/docker/apache-data/000-default.conf @@ -0,0 +1,34 @@ + + # The ServerName directive sets the request scheme, hostname and port that + # the server uses to identify itself. This is used when creating + # redirection URLs. In the context of virtual hosts, the ServerName + # specifies what hostname must appear in the request's Host: header to + # match this virtual host. For the default virtual host (this file) this + # value is not decisive as it is used as a last resort host regardless. + # However, you must set it for any further virtual host explicitly. + #ServerName www.example.com + + ServerAdmin webmaster@localhost + DocumentRoot /var/www/html/_site + + AllowOverride All + + + # Available loglevels: trace8, ..., trace1, debug, info, notice, warn, + # error, crit, alert, emerg. + # It is also possible to configure the loglevel for particular + # modules, e.g. + #LogLevel info ssl:warn + + ErrorLog ${APACHE_LOG_DIR}/error.log + CustomLog ${APACHE_LOG_DIR}/access.log combined + + # For most configuration files from conf-available/, which are + # enabled or disabled at a global level, it is possible to + # include a line for only one particular virtual host. For example the + # following line enables the CGI configuration for this host only + # after it has been globally disabled with "a2disconf". + #Include conf-available/serve-cgi-bin.conf + + +# vim: syntax=apache ts=4 sw=4 sts=4 sr noet diff --git a/docs/printing.md b/docs/printing.md index 7994c3b2..abb13962 100644 --- a/docs/printing.md +++ b/docs/printing.md @@ -1,22 +1,21 @@ -# Printing +# 印刷 -The printed Standard for Public Code is printed by Reclameland. -This guide tries to provide the relevant information to print it there or somewhere else. +《公共程式標準》是由 Reclameland 負責印刷。本指引試著提供印刷相關資訊，方便您到 Reclameland 或其他地方印刷。 -Details, mostly in order they are on the Reclameland page with the Dutch if necessary: +印刷詳細資訊（多數依照 Reclameland 網頁上的順序，依需要附上荷蘭語）： -* Form: Softcover book ([Reclameland product page](https://www.reclameland.nl/drukken/softcover-boeken)) -* Format: A4 -* Portrait or landscape: Portrait (Staand) -* Printing inside: 4/4 dual sided full color -* Inside material: 90 grams biotop -* Cover: 350 grams cover -* Printing cover: 4/0 one sided full cover -* Cover treatment: one sided matt foliated (Enke) -* Pages: pages of the inside + 4 + x, where x is 0-3 so that the sum becomes a multiple of 4 -* Individually sealed: no +* 樣式：平裝書 ([Reclameland 產品頁面](https://www.reclameland.nl/drukken/softcover-boeken)) +* 紙張尺寸：A4 +* 直向或橫向：直向 (Staand) +* 內頁印刷：正四反四 4/4，雙面全色印刷 +* 內頁材質：Biotop 90克 +* 封面：350 克封面 +* 封面印刷：正四反空 4/0，單面滿版印刷 +* 封面處理：單面霧面層剝處理 (Enke) +* 頁數：書內頁數 + 4 + x，x 是 0-3頁，讓總頁數是 4 的倍數 +* 個別封裝：無 -When these details are chosen, the cover and insides are uploaded and the order is placed payment can happen (payment ahead) after which printing starts. +一旦選定這些印刷的詳細資訊，封面與內頁就會上傳，並且下單與付費。付費後才會開始印刷。 diff --git a/docs/releasing.md b/docs/releasing.md index caada9f9..0ab61c4e 100644 --- a/docs/releasing.md +++ b/docs/releasing.md @@ -1,39 +1,48 @@ -# Releasing a new version of the Standard for public code +# 發行新版本的《公共程式標準》 -1. Review state of the 'develop' branch - - Ensure all changes intended for release are merged - - Invite a proofread of the current state of the branch - - If new dashes are introduced, check if the language can be simplified to remove them in favor of more simple sentences. If a complex sentence is needed, see if the dash can be replaced with other punctuation. If a dash is truly the best expression of ideas, then follow the [Chicago Manual of Style](https://en.wikipedia.org/wiki/Dash#En_dash_versus_em_dash). -2. Create a release branch - - From 'develop', `git switch -c "release-$MAJOR.$MINOR.$PATCH"` - - Push the branch, `git push -u origin release-$MAJOR.$MINOR.$PATCH` -3. Update the new release - - [ ] Update [`AUTHORS.md`](../AUTHORS.md) with new contributors - - [ ] Update [`CHANGELOG.md`](../CHANGELOG.md) - - [ ] Update [`roadmap.md`](roadmap.md) - - [ ] Perform extra pass on diff to the 'main' branch - - run `script/generate-review-template.sh` and commit updated `docs/review-template.html` - - update `docs/standard-for-public-code.html` with the new text from the review template, updating any status changes as a result - - Reread any section or paragraph to ensure wording changes still fit the whole and do not contain grammar or spelling errors - - Ensure [fonts](https://brand.publiccode.net/typography/) are installed, see: `script/ensure-font.sh` - - Check the rendered `.pdf` using `script/pdf.sh rc1` - - Ensure no link collisions exist - - Check the page breaks, possibly removing or adding page-break CSS, for example: `

` - - If needed, commit fixes and repeat extra pass - - [ ] Push branch, compare with 'main' branch, i.e.: `https://github.com/publiccodenet/standard/compare/main...release-$MAJOR.$MINOR.$PATCH` - - Request review from multiple reviewers, especially a proofreader - - Reviewers will create issues for shortcomings found which would not prevent release - - If needed for release, reviewers may create pull requests to resolve issues - - Re-request reviews if additional pull requests are merged into release branch - - [ ] Run the to-archive-org.sh script -4. Create GitHub release with the release notes and version number - - [ ] `git tag trigger-$MAJOR.$MINOR.$PATCH` - - [ ] `git push --tags` (see: `../.github/workflows/release-on-tag.yml`) - - [ ] delete local tag: `git tag -d trigger-$MAJOR.$MINOR.$PATCH` -5. [Send the files for print to the printer](printing.md) - - [ ] Cover file - - [ ] Inside pages PDF -6. Ping [translation](https://github.com/publiccodenet/community-translations-standard) contributors +1. 審查「develop」分支的狀態 + - 確認預計收入該次發行版的所有變更都已完成合併 + - 邀請校對該分支目前的狀態 + - 如果有引入新的破折號，檢查是否能簡化文字並且移除破折號，例如改用較簡易的句子。如果需要用到複雜的句子，檢查是否能用其他標點符號來取代破折號。如果破折號最適合用來 +表達該句子的涵義，則請遵守《[芝加哥格式手 +冊](https://en.wikipedia.org/wiki/Dash#En_dash_versus_em_dash)》的規範。 + +1. 建立發行用分支 + - 從「develop」分支下命令，`git switch -c "release-$MAJOR.$MINOR.$PATCH"` + - 推送分支，`git push -u origin release-$MAJOR.$MINOR.$PATCH` + +1. 更新本次新發行 + - [ ] 在 [`AUTHORS.md`](../AUTHORS.md) 中加入新貢獻者的資料 + - [ ] 更新 [`CHANGELOG.md`](../CHANGELOG.md) + - [ ] 更新 [`roadmap.md`](roadmap.md) + - [ ] 透過 diff 進行額外傳輸到「main」分支 + - 執行 `script/generate-review-template.sh` 並送交更新後的 `docs/review-template.html` 版次記 +錄 + - 使用審查範本中的新文字來更新 `docs/standard-for-public-code.html`，會將任何狀態變更作為結果更新 + - 重新檢查用字有變更的任何小節或段落，確保變更的字詞適合該整體內容，並且沒有文法或拼字錯誤 + - 確認有安裝[字型](https://brand.publiccode.net/typography/)，請參見：`script/ensure-font.sh` + - 使用 `script/pdf.sh rc1` 檢查轉譯出的 `.pdf` 檔 + - 確認沒有連結相衝的問題 + - 檢查文字分頁之處，可能需要移除或新增 CSS 分頁語法，像是：`

` + - 如果有需要，送交修正版次，並重複進行額外傳輸 + - [ ] 推送分支，與「main」分支比較，範例： +`https://github.com/publiccodenet/standard/compare/main...release-$MAJOR.$MINOR.$PATCH` + - 請多位審查人員（特別是校對人員）進行審查 + - 審查人員若發現不會阻礙發行的缺失，則會建立議題 + - 如果是發行所需處理的缺失，審查人員可以提交拉取請求來解決問題 + - 若有額外的拉取請求合併至發行分支，則再次請求審查 + - [ ] 執行 to-archive-org.sh 命令稿 + +1. 在 GItHub 上發行，附上發行備註與版本編號 + - [ ] `git tag trigger-$MAJOR.$MINOR.$PATCH` + - [ ] `git push --tags`（請參見：`../.github/workflows/release-on-tag.yml`） + - [ ] 移除本地端的 tag 標記：`git tag -d trigger-$MAJOR.$MINOR.$PATCH` + +1. [將檔案傳送給印刷廠商印刷](printing.md) + - [ ] 封面檔案 + - [ ] 內頁 PDF + +1. 通知[翻譯](https://github.com/publiccodenet/community-translations-standard)貢獻者 diff --git a/docs/roadmap.md b/docs/roadmap.md index 40e5f47d..55f132de 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -1,33 +1,33 @@ -# Roadmap +# 發展路線圖 -Last updated: 2023-03-08 +上次更新時間：2023-03-08 -This document intends to shed light on the current development plans of the team. -Plans change constantly as new information is absorbed by the team. +本文件旨在闡明團隊目前的開發計畫。隨著團隊吸收新資訊，這些計畫也會持續變動。 -Codebase stewards review the roadmap monthly as part of our [backlog pruning session](https://about.publiccode.net/activities/standard-maintenance/backlog-pruning.html). +程式基底執事人員每月會定期審查發展路線圖，這是我們[積累事項修整作業](https://about.publiccode.net/activities/standard-maintenance/backlog-pruning.html) +環節的一部份。 -## Current work +## 目前任務 -* As far as possible, make the standard Standard-compliant -* Certification badges +* 盡可能讓標準遵循自我標準 +* 認證標章 -## Near term +## 近期 -* Separate executive summary (issue #302) -* Physical paper checklist -* Possibly: add in the illustrations for each criterion +* 分離執行摘要 (issue #302) +* 實體紙張檢查清單 +* 可能性：為每個準則新增解說插圖 -## Longer term +## 長期 -* Add to README and index.md information (and eventually statistics) on adoption and use (issue #438) -* Becoming validated by multiple codebases -* Release version 1.0.0 after a few codebases are compliant -* Linkable requirements -* New cover art -* Register for ISBN -* List with an on-demand book printing service -* QR codes for external links in print version +* 為「README」與「index.md」加入採用與使用（之後會繼續統計）條目（議題#438號） +* 通過多個程式基底驗證 +* 在幾個程式基底遵循標準後，發行 1.0.0 版 +* 可連結的需求規範 +* 新封面設計 +* 註冊申請 ISBN 書號 +* 隨選書籍列印服務名單 +* 印刷版外部連結的 QR 二維圖碼 diff --git a/foreword.md b/foreword.md index 069f2207..19c3650c 100644 --- a/foreword.md +++ b/foreword.md @@ -4,174 +4,162 @@ redirect_from: - introduction --- -# Foreword -The Standard for Public Code is a set of criteria that support public organizations in developing and maintaining software and policy together. +# 序文 -Anyone developing public-purpose software or policy can use this standard to work towards higher quality public services that are more cost effective, with less risk and more control. +《公共程式標準》提供一套準則規範，支持公家機關一同開發與維護軟體及政策。 -This foreword introduces the term public code and explains why this is important. +任何想開發具有公眾用途的軟體或政策的人，可以利用本標準來提升公共服務品質，使其更具成本效益、風險更低，還能對系統更有掌控權。 -## Definition of public code +本序文在介紹何謂「公共程式」以及解說其重要性。 -Public code is both computer source code (such as software and algorithms) and public policy executed in a public context, by humans or machines. -It encompasses the software built to operate with and as public infrastructure, along with the arrangements for its production. -Public code is explicitly distinct from regular software because it operates under fundamentally different circumstances and expectations. +## 公共程式定義 -## Reasons for public code +公共程式，英文為 Public Code，是指人類或機器在公共情境下，所執行的電腦原始碼（像是軟體與演算法）與公共政策。公共程式的範疇，涵蓋搭配公共基礎建設一同作業 +的軟體、作為公共基礎建設運作而建置的軟體，以及產生公共程式的過程安排等。公共程式與一般軟體有明顯區別，因為其作業的環境與期待全然不同。 -There are many reasons for why public code is relevant now. +## 採用公共程式的原因 -### Software code == legal code +公共程式現在如此重要，背後有幾個原因。 -Software is public infrastructure. +### 軟體程式碼 == 法律條文 -In the 21st century, software can be considered vital public infrastructure. -It is increasingly not just the expression of existing policy but the originator of new policy, for example where algorithms decide which districts need extra social services or policing. +軟體是公共基礎建設。 -Software mechanics, algorithms and data collection have become key elements in the execution of public policies. -Computer code now executes policies that have been codified in legal code through democratic procedures. -Both forms of code set conditions for society to function according to democratically set public values, the latter executed by humans, the former by machines. -In other words, software code has increasingly started to equal legal code. +在 21 世紀，軟體可被視為重要的公共基礎建設。軟體越來越常被用於實現既有政策，甚至成為新政策的制定來源。舉例來說，演算法可以決定哪些地區需要額外的社會服務或警力 +等。 -Software should therefore be subject to the principles of democratic governance. +在公共政策的執行上，軟體運作機制、演算法與資料蒐集等，已成為關鍵要素。今日的電腦程式碼，正執行著透過民主程序制定的法規政策。程式碼與政策這兩種形式的程式，都根據民主 +程序而確立的公共價值，設立出社會的運作環境；前者由機器執行，後者則是由人類執行。換句話說，軟體程式碼，已經越來越實質趨近於法律條文的地位。 -### Traditional public software procurement +因此軟體也應該接受民主治理原則的約束。 -Current public software production methods have not served public service delivery very well. +### 傳統的公共軟體採購 -In the last decade, public organizations that purchased complete software solutions have sometimes been surprised to discover that they: +目前公共軟體的生產模式，在交付公共服務上的效率並不高。 -* can’t change their software to reflect changing policy or take advantage of new technology -* don’t have access to their data as it's locked into proprietary systems -* are asked to pay ever increasing license fees +過去近十年來，購置完整軟體解決方案的公家機關，有時甚至會很訝異地發現： -### Technological sovereignty and democratic accountability +* 他們無法修改軟體來反映政策的變動，或是改變軟體來利用新科技 +* 他們的資料都套牢在專有系統中，無法取用 +* 他們所需繳交的授權費變得越來越貴 -Public institutions, civil servants and residents deserve better. +### 技術自主權與民主課責 -We believe the software that runs our society can no longer be a black box, controlled by outside companies that keep the underlying logic on which their software operates hidden in proprietary codebases. -Instead, governments and the people they serve need technological sovereignty. -This allows them to set and control the functioning of public software, just like they are able to set and control policy that is legally formulated in laws. -Citizens and civil society actors need this software to be transparent and accountable. +公家機關、公務員與居民都值得更好的。 -The design of software as essential civic infrastructure should honor digital citizens’ rights. +我們相信支持社會運作的軟體，再也不能是黑箱，任由外部公司依隱藏在專有程式基底之下的秘密邏輯作控制。反過來說，政府，以及政府所要服務的人民，需要掌控技術自主權。技術自 +主讓他們能主導設定與控制公共軟體的運作，正如同他們能依法制定與調整政策一樣。人民與公民社會的參與者，都需要這類軟體能夠透明，且可以課責。 -### Designing truly public software +作為必要公民基礎建設的軟體，其設計應該尊重公民的數位權利。 -Public code is at the core of modern public institutions, shapes the work of civil servants and affects the lives of almost all residents. +### 設計真正的公共軟體 -Public software must therefore be: +公共程式是現代公家機構的核心，型塑了公務員的工作樣態，並且影響了幾乎所有居民的生活。 -* transparent -* accountable -* understandable for its constituents +因此公共軟體必須： -It must reflect the values of the society it serves, for example by being inclusive and non-discriminatory. +* 透明 +* 可課責 +* 讓選民能夠理解 -Most proprietary software systems currently used by public organizations do not meet these requirements. -Public code does. +必須能反映其所服務的社會價值觀，像是涵容與不歧視。 -### Values of public code +目前公家機關使用的大多數專有軟體系統，都不符合這些要求；而公共程式能夠做到。 -We consider public code to have these core values: +### 公共程式的價值 -* Inclusive -* Usable -* Open -* Legible -* Accountable -* Accessible -* Sustainable +我們認為公共程式應具有下列核心價值： -## How public code works +* 涵容 +* 好用 +* 開放 +* 易懂 +* 課責 +* 近用 +* 永續 -Public code is open source software meant for fulfilling the essential role of public organizations. -Through use, other administrations contribute back to the software, so that its development and maintenance become truly collaborative. +## 公共程式運作方式 -Being open unlocks many other things. +公共程式是旨在協助公家機關，履行其必要職責時所採用的開放原始碼軟體。透過使用，其他行政單位也能為軟體做出貢獻，因此公共程式的開發與維護，可說是真正互相協作的成果。 -Local responsibility and democratic accountability are ensured when a public organization implements and maintains their own public code. -By being open and with a broader contributor base, the software is more secure as it benefits from many eyes spotting potential flaws. -Many contributors share the maintenance work to keep it functional and modern, which reduces future technical debt. -The shared workload is more sustainable now and in the future. -Its openness makes both the code and its data more easily adaptable in the future. -The code will be easier to retool, repurpose or retire. -This all results in lower risk public infrastructure. +開放的精神能開創許多可能性。 -This pooling of resources lets public administrations give extra attention to how to customize the software so it works best in each local context, creating better user experiences for their end users (residents or citizens). +公家機關在執行與維護其自身的公共程式時，就是在確保能為地方負責，並履行民主課責。開放且貢獻者眾多的軟體，得利於有許多人在看，更容易發現潛在缺陷，因此安全性會更高。許 +多貢獻者會分攤維護工作，讓公共程式能持續運作與更新，減少未來技術債的可能。因為能有多人分攤維護工作，使得現在與未來都會更加永續。而公共程式的開放性，代表其程式碼與 +資料，在未來也更容易改寫與調整。程式碼也更容易重新利用、重新調整目標，或甚至淘汰。這一切特性都讓公共基礎建設可能遭遇的風險降到更低。 -### Economics of public code +這種將資源集中的作法，能讓公共行政單位可以有額外心力關注如何客製化軟體，來使軟體最適合當地情境的需求，為終端使用者（居民或市民）創造更佳的使用體驗。 -Public code offers a better economic model for public organizations as well as for commercial companies. -It's an alternative to traditional software procurement which increases local control and economic opportunity. +### 公共程式的經濟效應 -Designed from the start to be open, adaptable and with data portability, it can be developed by in-house staff or trusted vendors. -Because the code is open, the public administration can change vendors if they need to. -Open code increases opportunities for public learning and scrutiny, allowing the public administration to procure smaller contracts. -Smaller procurements are easier for local small and medium enterprises to bid upon. -Public administrations can use their own software purchasing to stimulate innovation and competition in their local economy. +公共程式為公家機關以及商業公司，提供更好的經濟模型。公共程式作為替代傳統軟體採購的方案，更能提升當地的掌控權並促進經濟機會。 -This can be seen as investment leading to future economic growth. -More vendors will be necessary due to growing technology demand. +公共程式從設計之初，就是要開放、適應力強、資料可攜，能夠由內部員工或信任的供應商來開發。由於原始碼開放，公共行政單位在有需要時可以更換供應商。開放原始碼讓社會大眾更 +有機會瞭解與監督公共程式，使公共行政單位得以採購小規模的合約，而地方性的中小企業就更容易參與這些小型採購案的競標。如此一來，公共行政單位就可以透過他們所需的軟體採 +購案，刺激當地經濟的創新與競爭。 -### Procuring public code +這可視為對未來經濟成長的投資。隨著科技需求成長，也將需要更多供應商。 -Public code can be used and developed by permanent in-house development teams, contractors or outsourced suppliers. -Vendors to public organizations can include public code in their bids for contracts. +### 購置公共程式 -To use existing public code, you need to specify in your budget and project design that your new solution will use that codebase. -To encourage an innovative approach to adapting the public code to your context, you could describe the service or outcome in your contract. +公共程式可由常駐的內部研發團隊、承包商或外包供應商開發。公家機關的供應商，在投標時可以在標案中納入公共程式。 -## The goals for the Standard for Public Code +若要使用既有的公共程式，您將需要在預算以及專案設計中，明確指出新的解決方案將會使用該程式基底。為了鼓勵創新，將公共程式依據您的情境背景作調整，您可在合約中描述說明服 +務內容或預期成果。 -This Standard supports developers, designers, managers and public policy makers to: +## 《公共程式標準》目標 -* develop high quality software and policy for better public service delivery -* develop codebases that can be reused across contexts and collaboratively maintained -* reduce technical debt and project failure rate -* have more granular control over, and ability to make decisions about, their IT systems -* improve vendor relationships with a better economic model +本標準在於支持開發人員、設計師、管理人員、公共政策制定者： -Potential users of codebases tested against the Standard for Public Code can expect them to be highly reusable, easily maintainable and of high quality. +* 開發出高品質的軟體與政策，來改善公共服務的交付 +* 開發出能在各種情境下重複使用，且以協作方式維護的程式基底 +* 減少技術債與專案失敗率 +* 更能精細控制其 IT 系統粒度，並做出系統相關決策 +* 以更好的經濟模型改善供應商關係 -The Standard for Public Code does this by: +如果有潛在使用者想採用經由《公共程式標準》測試過的程式基底，便可以預期這些程式基底具有方便重複利用、容易維護、高品質的特性。 -* setting out a common terminology for public code development -* establishing measures to help develop high quality public code -* providing guidance on how to fulfill its criteria and operationalize compliance +《公共程式標準》能有此效果是基於： -The Standard for Public Code is meant to be time and technology independent. +* 為公共程式開發訂立通用術語 +* 制定措施協助高品質公共程式的開發 +* 提出該如何符合準則並實作遵循的指引 -### Who this is for +《公共程式標準》設計精神就是要跨越時間與科技，不受其限制。 -The Standard for Public Code is for the people who create and reuse public code: +### 適用對象 -* public policy makers -* business and project managers -* developers and designers +《公共程式標準》適用於開發與重複使用公共程式的人： -These people work at: +* 公共政策制定者 +* 業務與專案經理 +* 開發人員與設計師 -* institutions, organizations and administrations in the public sector -* consultancies and vendors of information technology and policy services to public organizations +在以下單位服務的人： -It is not aimed at public organizations' end users (residents or citizens), journalists or academics. +* 社會機構、公家機關的組織與行政單位 +* 公家機關在資訊科技與政策服務上的顧問與供應商 -## Further reading +適用對象不含公家機關的終端使用者（居民或市民）、記者或學者等。 -* ["Modernising Public Infrastructure with Free Software" white paper](https://download.fsfe.org/campaigns/pmpc/PMPC-Modernising-with-Free-Software.pdf) by the Free Software Foundation Europe. +## 延伸閱讀 -### Videos on public code +* 歐洲自由軟體基金會所發表的[《透過自由軟體實現公共基礎設施現代化》白皮 +書](https://download.fsfe.org/campaigns/pmpc/PMPC-Modernising-with-Free-Software.pdf) 》。 -* [Collaborative Code is the Future of Cities @ DecidimFest 2019](https://www.youtube.com/watch?v=cnJtnZ9Cx1o). Talk by Ben Cerveny on the background behind the Foundation for Public Code. -* [Public Money? Public Code! - Panel @ Nextcloud Conference 2019](https://youtube.com/watch?v=QHFkD4xfd6c). Touches on topics like procurement, law and more. +### 探討公共程式的影片 -## Get involved +* [「程式協作是城市的未來」@ DecidimFest 2019](https://www.youtube.com/watch?v=cnJtnZ9Cx1o)。主講 +人 Ben Cerveny，講述 Foundation for Public Code 的背景。 +* [ 「用公共的納稅錢？做公共的程式吧！」專題討論 @ Nextcloud 大會 2019](https://youtube.com/watch? +v=QHFkD4xfd6c)。討論採購、法律等主題。 -This standard is a living document. -[Read our contributor guide](/CONTRIBUTING.md) to learn how you can make it better. +## 參與我們 -## Contact +本標準是持續成長的文件。[請讀我們的〈貢獻者指引〉](/CONTRIBUTING.md)，瞭解您可以怎麼做來讓本標準變得更好。 -For questions and more information about the Foundation for Public Code you can find us at [our website](https://publiccode.net/), email us at info@publiccode.net, or call us at +31 20 2 444 500. +## 聯絡方式 + +若有疑問，或想進一步瞭解 Foundation for Public Code，請造訪[我們的網站](https://publiccode.net/)，或是寄電子郵 +件到 info@publiccode.net，或撥打我們的電話 +31 20 2 444 500。 diff --git a/glossary.md b/glossary.md index 4cb3464e..40fe9366 100644 --- a/glossary.md +++ b/glossary.md @@ -2,85 +2,78 @@ # SPDX-License-Identifier: CC0-1.0 # SPDX-FileCopyrightText: 2019-2022 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS --- -# Glossary -## Code +# 詞彙表 -Any explicitly described system of rules. -This includes laws, policy and ordinances, as well as source code that is used to build software. -Both of these are rules, some executed by humans and others by machines. +## 程式或程式碼 (Code) -## Codebase +任何明確的規則系統，包括法律、政策與規則條例（法規、法式，也可稱為程式），以及用來開發軟體的原始碼（程式碼）。兩者都是規則，有些是由人類來執行，其餘則是由機器執 +行。 -Any discrete package of code (both source and policy), the tests and the documentation required to implement a piece of policy or software. +## 程式基底 (Codebase) -This can be, for example, a document or a version-control repository. +任何獨立分離的統合包，內含執行部分政策或軟體所需的程式（包含原始碼與政策）、測試與文件等的整套內容。 -## Continuous integration +舉例而言，這個具體形式可以是文件，或是版本控制的儲存庫。 -In software engineering, continuous integration (CI) is the practice of merging all developers' working copies to a development branch of a codebase as frequently as reasonable. +## 持續整合 -## Different contexts +在軟體工程中，持續整合 (CI) 是盡可能頻繁地將所有開發人員工作中的副本，合併回程式基底開發中分支的實務作法。 -Two contexts are different if they are different public organizations or different departments for which there is not one decision maker that could make collaboration happen naturally. +## 不同情境 -## General public +只要是不同的公家機關或不同的部門，無法透過同一個決策單位讓協作自然發生，那就算是兩個不同的情境。 -The public at large: end users of the code and the services based upon it. +## 一般大眾 -For example, a city's residents are considered end users of a city's services and of all code that powers these services. +整體民眾：程式碼與其所建立的服務的終端使用者。 -## Open source +舉例而言，城市的居民即視為該城市的服務、以及驅動這些服務運作的程式碼的終端使用者。 -Open source is defined by the Open Source Initiative in their [Open Source Definition](https://opensource.org/osd-annotated). +## 開源或開放原始碼 (Open Source) -## Open standard +所謂「開源」或「開放原始碼」，是根據 OSI 開放原始碼促進會發表的《[開放原始碼定義](https://opensource.org/osd-annotated)》而來。 -An open standard is any standard that meets the Open Source Initiative's [Open Standard Requirements](https://opensource.org/osr). +## 開放標準 -## Policy +任何符合 OSI 開放原始碼促進會《[開放標準需求規範](https://opensource.org/osr)》的標準，就是開放標準。 -A policy is a deliberate system of principles to guide decisions and achieve rational outcomes. -A policy is a statement of intent, and is implemented as a procedure or protocol. -Policies are generally adopted by a governance body within an organization. -Policies can assist in both subjective and objective decision making. +## 政策 -Public policy is the process by which governments translate their political vision into programs and actions to deliver outcomes. +政策是一套謹慎設計的原則體系，用來引導決策並達成合理的成果。政策是一種意圖的聲明，並以程序或協定來執行。政策通常是由組織單位內的理事機構採用執行。政策能協助做出主觀 +與客觀的決策。 -At the national level, policy and legislation (the law) are usually separate. -The distinction is often more blurred in local government. +公共政策是政府將其政治願景，轉化成計畫與行動來取得成果的程序。 -In the Standard the word 'policy' refers to policy created and adopted by public organizations such as governments and municipalities. +在國家層級，政策與立法（法律）通常是分開的；而在地方政府中，這兩者之間的區別通常比較模糊。 -## Public code +在本標準當中，「政策」一詞指的是公家機關，例如政府與自治市等，所制定與採用的政策。 -Public code is open source software developed by public organizations, together with the policy and guidance needed for collaboration and reuse. +## 公共程式 (Public Code) -Public code is both computer source code (such as software and algorithms) and public policy executed in a public context, by humans or machines. +公共程式，是由公家機關所開發的開放原始碼軟體，同時包含協作與重複利用所需的政策與指引。 -Public code serves the public interest, is open, legible, accountable, accessible and sustainable. +公共程式是在公共情境下，由人類或機器所執行的電腦原始碼（例如軟體與演算法）以及公共政策兩者。 -By developing public code independently from but still implementable in the local context for which it was developed, as well as documenting the development process openly, public code can provide a building block for others to: +服務公眾利益的公共程式，具有開放、易懂、課責、近用、永續等特性。 -* re-implement in their local context -* take as a starting point to continue development -* use as a basis for learning +透過獨立於當地情境，但仍可在當地情境下實作的方式，還有公開以文件記錄開發程序等作法，來開發公共程式。如此，公共程式能作為基礎組件提供給他人，使其得以： -To facilitate reuse, public code is either released into the public domain or licensed with an open license that permits others to view and reuse the work freely and to produce derivative works. +* 根據其當地情境重新實作 +* 作為起點並繼續開發 +* 當作學習時的基礎 -## Repository +為了促進重複利用，公共程式通常放到公眾領域發行，或者採取允許他人能自由檢視、重複利用其成果，甚至產出衍生作品的開放授權。 -A repository is a storage location used by version control tools for files and metadata of a codebase. -Repositories allow multiple contributors to work on the same set of files. -Repositories are able to store multiple versions of sets of files. +## 儲存庫 -## Source Code +儲存庫是版本控制工具，用於存放程式基底的檔案與中介資料的儲存位置。儲存庫讓多位貢獻者，得以同時對同一組檔案作業。儲存庫可以儲存一組檔案的多個版本。 -Human readable text of a computer program which can be translated into machine instructions. +## 原始碼 (Source Code) -## Version control +人類可讀，並且能夠翻譯成機器指令的電腦程式文字。 -Version control is the management of changes to source code and the files associated with it. -Changes are usually identified by a code, termed the *revision number* (or similar). -Each revision is associated with the time it was made and the person making the change, thus making it easier to retrace the evolution of the code. -Revision control systems can be used to compare different versions with each other and to see how content has changed over time. +## 版本控制 + +版本控制，是對原始碼及其相關檔案的變動行為作管理的流程。變動行為，通常是以稱為「*修訂編號*」（或版次等類似名稱）的代號作識別。每次修訂都會標示其改動時間以及作者， +方便追溯程式碼的演進。修訂控制系統可用來比較不同版本之間的差異，以及查看內容隨著時間經歷的變動。 diff --git a/index.md b/index.md index 1700ac9e..02cef7b7 100644 --- a/index.md +++ b/index.md @@ -3,44 +3,41 @@ # SPDX-FileCopyrightText: 2019-2022 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS toc: false --- -# Guidance for government open source collaboration +# 政府開放原始碼協作指引 -The Standard for Public Code is a set of criteria that supports public organizations in developing and maintaining software and policy together. +《公共程式標準》是一套支持公家機關一同協作開發軟體與政策，以及維護的準則。 -The Standard for Public Code provides guidance to public organizations building their own open source solutions to enable successful future collaboration and reuse by similar organizations in the public sector in other places. -It includes advice for policy makers, government managers, developers and vendors. -The Standard for Public Code supports the collaborative creation of codebases that are usable, open, legible, accountable, accessible and sustainable. -It is meant to be applicable to codebases for all levels of government, from supranational to municipal. +《公共程式標準》為那些在建構自身開放原始碼解決方案的公家機關提供指引，以便他們未來能成功與其他地方的類似公部門單位互相協作，並且重複使用各自的成果。這份標準涵蓋寫給政策制定者、政府管理人員、開發人員與供應商的建議。《公共程式標準》支持公家機關透過協作方式，創造出好用、開放、易懂、課責、近用、永續的程式基底。這份標準從設計之初，就是要用於各種不同政府層級的程式基底，小從市政府，大到超國家組織都行。 -The Standard for Public Code defines ‘[public code](glossary.md#public-code)’ as open source software developed by public organizations, together with the policy and guidance needed for collaboration and reuse. +《公共程式標準》將「[公共程式](glossary.md#public-code)」定義為：由公家機關所開發的開放原始碼軟體，同時包含協作與重複使用所需的政策與指引。 -The criteria of the Standard for Public Code are aligned with guidelines and best practices of open source software development. +《公共程式標準》當中的準則，符合開放原始碼軟體開發的指引與最佳實務。 -{% for page in site.pages %}{% if page.name == "foreword.md" %} -Additional context and background can be found in the [foreword](foreword.md). -{% endif%}{% endfor %} +{% for page in site.pages %}{% if page.name == "foreword.md" %} 其他情境與背景資訊請參閱[序文](foreword.md)。 {% endif%}{% endfor %} -## Contents +## 目次 -* [Readers guide: how to interpret this standard](readers-guide.md) -* [Glossary](glossary.md) -* [Criteria](criteria/){% assign sorted = site.pages | sort:"order" %}{% for page in sorted %}{% if page.dir == "/criteria/" %}{% if page.name != "index.md" %}{% if page.title %} - * [{{page.title}}]({{page.url}}){% endif%}{% endif%}{% endif%}{% endfor %} -* [Authors](AUTHORS.md) -* [Contributing guide](CONTRIBUTING.md) -* [Code of conduct](CODE_OF_CONDUCT.md) -* [Governance](GOVERNANCE.md) -* [Version history](CHANGELOG.md) -* [License](license.html) +* [讀者指引：如何解讀本標準](readers-guide.md) +* [詞彙表](glossary.md) +* [準則](criteria/){% assign sorted = site.pages | sort:"order" %}{% for page in +sorted %}{% if page.dir == "/criteria/" %}{% if page.name != "index.md" %}{% +if page.title %} + * [{{page.title}}]({{page.url}}){% endif%}{% endif%}{% endif%}{% endfor %} +* [作者群](AUTHORS.md) +* [貢獻指引](CONTRIBUTING.md) +* [行為守則](CODE_OF_CONDUCT.md) +* [治理方式](GOVERNANCE.md) +* [版本歷史](CHANGELOG.md) +* [授權](license.html) -## Community calls +## 社群會議 -We usually have a community call on the first Thursday of the month at 15:00 (CET/CEST). -[The agenda](https://write.publiccode.net/pads/Community-Call-Standard-for-Public-Code) is updated roughly a week before the call. -It is possible to [sign up](https://odoo.publiccode.net/survey/start/594b9243-c7e5-4bc1-8714-35137c971842) to get a call invitation emailed to you. +我們通常在每月第一個週四的 15:00 (CET/CEST) 舉辦社群會議。[議程](https://write.publiccode.net/pads/Community-Call-Standard-for-Public-Code)在會議前 +約一週的時間更新。您可以[註冊](https://odoo.publiccode.net/survey/start/594b9243-c7e5-4bc1-8714-35137c971842) +報名，會再寄送會議通話邀請函給您。 -## Other resources +## 其他資源 -* Unofficial [community translations of the Standard](https://publiccodenet.github.io/community-translations-standard/) in other languages -* [Standard compliance self assessment](https://publiccodenet.github.io/assessment-eligibility/) for public sector open source codebases -* [Standard criteria checklist](/docs/review-template.html) used by Foundation for Public Code stewards for codebase review +* 本標準非官方的其他語言[社群翻譯](https://publiccodenet.github.io/community-translations-standard/) +* 公部門開放原始碼程式基底的《[標準遵循自我評估](https://publiccodenet.github.io/assessment-eligibility/)》 +* Foundation for Public Code 執事人員用於程式基底審查的《[標準準則檢查清單](/docs/review-template.html)》 diff --git a/locales/en/LC_MESSAGES/messages.po b/locales/en/LC_MESSAGES/messages.po new file mode 100644 index 00000000..9fad8d18 --- /dev/null +++ b/locales/en/LC_MESSAGES/messages.po @@ -0,0 +1,5602 @@ +# +msgid "" +msgstr "" + +#: ./404.md:block 1 (header) +msgid "SPDX-License-Identifier: CC0-1.0" +msgstr "" + +#: ./404.md:block 2 (header) +msgid "" +"SPDX-FileCopyrightText: 2022-2023 The Foundation for Public Code " +"[info@publiccode.net](mailto:info@publiccode.net), " +"https://standard.publiccode.net/AUTHORS" +msgstr "" + +#: ./404.md:block 3 (header) +msgid "" +"layout: default\n" +"title: Page not found\n" +"toc: false" +msgstr "" + +#: ./404.md:block 4 (header) +msgid "404 Not Found" +msgstr "" + +#: ./404.md:block 5 (paragraph) +msgid "If you typed the web address, check it is correct." +msgstr "" + +#: ./404.md:block 6 (paragraph) +msgid "If you pasted the web address, check you copied the entire address." +msgstr "" + +#: ./404.md:block 7 (paragraph) +msgid "" +"If the web address is correct or you followed a link or button, email the " +"[Foundation for Public Code staff](mailto:info@publiccode.net) so we'll be " +"able to help you out, as well as correct our mistake." +msgstr "" + +#: ./AUTHORS.md:block 2 (header) +msgid "" +"SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code " +"[info@publiccode.net](mailto:info@publiccode.net), " +"https://standard.publiccode.net/AUTHORS" +msgstr "" + +#: ./AUTHORS.md:block 3 (header) +msgid "Authors" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Alba Roza, [The Foundation for Public Code](https://publiccode.net/)" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Arnout Engelen" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Arnout Schuijff, The Foundation for Public Code" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Audrey Tang, [digitalminister.tw](https://digitalminister.tw/)" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Ben Cerveny, The Foundation for Public Code" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Bert Spaan" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Boris van Hoytema, The Foundation for Public Code" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Charlotte Heikendorf" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Claus Mullie, The Foundation for Public Code" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "David Barberi" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Edo Plantinga, [Code For NL](https://codefor.nl/)" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Elena Findley-de Regt, The Foundation for Public Code" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Eric Herman, The Foundation for Public Code" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Felix Faassen, The Foundation for Public Code" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Floris Deerenberg" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Jan Ainali, The Foundation for Public Code" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Johan Groenen, Code For NL" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Marcus Klaas de Vries" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Mark van der Net, [Gemeente Amsterdam](https://www.amsterdam.nl/en/)" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "" +"Martijn de Waal, [Amsterdam University of Applied Sciences " +"(AUAS)](https://www.amsterdamuas.com/), Faculty of Digital Media and " +"Creative Industries, Lectorate of Play & Civic Media" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Matti Schneider" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Mauko Quiroga" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Maurice Hendriks, Gemeente Amsterdam" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Maurits van der Schee, Gemeente Amsterdam" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Mirjam van Tiel, The Foundation for Public Code" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Ngô Ngọc Đức Huy" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Paul Keller" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "" +"Petteri Kivimäki, [Nordic Institute for Interoperability Solutions " +"(NIIS)](https://niis.org)" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Sky Bristol" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Tamas Erkelens, Gemeente Amsterdam" +msgstr "" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Timo Slinger" +msgstr "" + +#: ./CC0-1.0.md:block 3 (header) +msgid "toc: false redirect_from: - license.html - LICENSE.html" +msgstr "" + +#: ./CC0-1.0.md:block 4 (header) +msgid "Creative Commons Zero v1.0 Universal" +msgstr "" + +#: ./CC0-1.0.md:block 6 (paragraph) +msgid "" +"This license is the legal contract that allows anyone to do anything they " +"like with the content in this entire document." +msgstr "" + +#: ./CHANGELOG.md:block 3 (header) +msgid "" +"script/release-body.sh expects VERSION in the first second-level header" +msgstr "" + +#: ./CHANGELOG.md:block 4 (header) +msgid "script/update-changelog-date.sh expects DATE-OF-RELEASE and a colon" +msgstr "" + +#: ./CHANGELOG.md:block 5 (header) +msgid "Version history" +msgstr "" + +#: ./CHANGELOG.md:block 6 (header) +msgid "Version 0.7.1" +msgstr "" + +#: ./CHANGELOG.md:block 7 (paragraph) +msgid "" +"July 31st 2023: 💄 The sixteenth draft change the name of a criterion and " +"clarifies references to code." +msgstr "" + +#: ./CHANGELOG.md:block 8 (unordered list) +msgid "" +"The criterion \"Make the codebase reusable and portable\" was renamed from " +"\"Create reusable and portable code\"." +msgstr "" + +#: ./CHANGELOG.md:block 8 (unordered list) +msgid "Added a glossary entry for \"Source Code\"." +msgstr "" + +#: ./CHANGELOG.md:block 8 (unordered list) +msgid "" +"References to \"code\" which only applied to \"source code\" now reference " +"\"source code\" explicitly." +msgstr "" + +#: ./CHANGELOG.md:block 8 (unordered list) +msgid "Clarification of \"running code\" as \"software\"." +msgstr "" + +#: ./CHANGELOG.md:block 8 (unordered list) +msgid "Minor changes to clarify \"code\" vs \"codebase\"." +msgstr "" + +#: ./CHANGELOG.md:block 8 (unordered list) +msgid "Simplify guidance to policy makers in Bundle policy and source code." +msgstr "" + +#: ./CHANGELOG.md:block 8 (unordered list) +msgid "" +"Clarify How to test sections of Make the codebase findable and Make the " +"codebase reusable and portable." +msgstr "" + +#: ./CHANGELOG.md:block 8 (unordered list) +msgid "Add a criteria and requirements checklist to the release artifacts." +msgstr "" + +#: ./CHANGELOG.md:block 8 (unordered list) +msgid "Increase automation of the release process." +msgstr "" + +#: ./CHANGELOG.md:block 9 (header) +msgid "Version 0.7.0" +msgstr "" + +#: ./CHANGELOG.md:block 10 (paragraph) +msgid "" +"May 31st 2023: 📑 the fifteenth draft adds new requirements for documenting " +"review funding and clarifies review process requirement." +msgstr "" + +#: ./CHANGELOG.md:block 11 (unordered list) +msgid "" +"Add requirement to document who is expected to cover the cost of reviewing " +"contributions." +msgstr "" + +#: ./CHANGELOG.md:block 11 (unordered list) +msgid "Add requirement to have a short description of the codebase." +msgstr "" + +#: ./CHANGELOG.md:block 11 (unordered list) +msgid "" +"Change the focus of contributions adhering to standards to focus on the " +"review of contributions." +msgstr "" + +#: ./CHANGELOG.md:block 11 (unordered list) +msgid "Relaxed MUST requirements to SHOULD in Make the codebase findable." +msgstr "" + +#: ./CHANGELOG.md:block 11 (unordered list) +msgid "Review template now in HTML format." +msgstr "" + +#: ./CHANGELOG.md:block 11 (unordered list) +msgid "Introduction converted to foreword." +msgstr "" + +#: ./CHANGELOG.md:block 11 (unordered list) +msgid "Improved contributing guidelines." +msgstr "" + +#: ./CHANGELOG.md:block 11 (unordered list) +msgid "Improved documentation of scripts." +msgstr "" + +#: ./CHANGELOG.md:block 12 (header) +msgid "Version 0.6.0" +msgstr "" + +#: ./CHANGELOG.md:block 13 (paragraph) +msgid "" +"April 20th 2023: 🔀 the fourteenth draft adds new requirements for " +"portability and tests and an introduction to each criterion." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"New requirement in Create reusable and portable code about the development " +"being a collaboration between multiple parties." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"New requirement in Create reusable and portable code about being dependent " +"on a single vendor." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"New requirement in Use continuous integration about publishing results for " +"automated tests." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Differentiating the two requirements about security to clearly be about " +"providing a method and having documentation about it." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Rephrased requirements to focus on the codebase rather than contributor " +"behavior." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Removed the sections Why this is important and What this does not do and " +"replaced with an introduction in each criterion." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Added general What this does not do section in the introduction of the " +"Standard." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Added guidance for public policy makers about related policies and license " +"compatibility." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Added guidance for developers and designers about version controlling files." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Clarified guidance for developers and designers about prompt responses and " +"search engine optimization." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "Added Further reading about accessibility." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "Aligned criteria URLs with criteria names." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "Improved navigation in the web version." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Moved tools in Further reading sections to the community implementation " +"guide." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Moved compliance or certification process to " +"[publiccode.net](https://publiccode.net)." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Change format of the review template to make it easier to update after a new" +" release." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "" +"Improved the text on the landing page and added links to related resources." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "Added spell checker automated test." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "Made minor changes to text for clarity and consistency." +msgstr "" + +#: ./CHANGELOG.md:block 14 (unordered list) +msgid "Moved SPDX headers to yaml header." +msgstr "" + +#: ./CHANGELOG.md:block 15 (header) +msgid "Version 0.5.0" +msgstr "" + +#: ./CHANGELOG.md:block 16 (paragraph) +msgid "" +"January 25th 2023: 🎨 the thirteenth draft focuses on documenting style " +"guidelines." +msgstr "" + +#: ./CHANGELOG.md:block 17 (unordered list) +msgid "" +"Adjust the coding style requirement to focus on the codebase using a style " +"guide rather than contributor behavior." +msgstr "" + +#: ./CHANGELOG.md:block 17 (unordered list) +msgid "" +"Moved requirement for codebase names to Make the codebase findable from Use " +"plain English." +msgstr "" + +#: ./CHANGELOG.md:block 17 (unordered list) +msgid "" +"Moved requirement about testing the code by using examples to Use continuous" +" integration from Document the code." +msgstr "" + +#: ./CHANGELOG.md:block 17 (unordered list) +msgid "" +"Split requirement about machine testable standards to clarify that open is " +"more important than testable." +msgstr "" + +#: ./CHANGELOG.md:block 17 (unordered list) +msgid "" +"Adjust how to test findability requirements to be less reliant on search " +"engine algorithms." +msgstr "" + +#: ./CHANGELOG.md:block 18 (header) +msgid "Version 0.4.1" +msgstr "" + +#: ./CHANGELOG.md:block 19 (paragraph) +msgid "December 5th 2022: 📝 the twelfth draft clarifies document maturity." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "" +"Document maturity focuses on whether or not versions of the codebase are " +"ready to use." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "" +"Document maturity no longer requires specific labels for codebases that are " +"not ready to use." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Audit flow image now generated from an easier to translate format." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Improved guidance on How to test." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Add publiccode.yml file." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Add review template." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Consistently link glossary terms." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Add practices and standards to follow in CONTRIBUTING." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Add Matti Schneider to Authors." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Add remaining SPDX headers to files." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Made additional minor changes to text for clarity." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "Some hyperlinks updated." +msgstr "" + +#: ./CHANGELOG.md:block 20 (unordered list) +msgid "" +"Moved examples to the [Community implementation " +"guide](https://publiccodenet.github.io/community-implementation-guide-" +"standard/)." +msgstr "" + +#: ./CHANGELOG.md:block 21 (header) +msgid "Version 0.4.0" +msgstr "" + +#: ./CHANGELOG.md:block 22 (paragraph) +msgid "" +"September 7th 2022: 🔭 the eleventh draft adds a new findability criterion." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Introduce new criterion: Make the codebase findable." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Improve How to test section for most criteria." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "" +"New requirement in Welcome contributors about publishing activity " +"statistics." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Removed redundant requirement about portable and reusable code." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "" +"Expand open license definition to include both OSI and FSF approved " +"licenses." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Rephrase MAY requirements to use the keyword OPTIONAL for clarity." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "" +"Expressed intent that the Standard for Public Code should meet its own " +"requirements where applicable and added assessment." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Add SPDX license identifiers to files." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Introduced new Code of Conduct." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Clarify distinction between source code and policy text." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Restructuring of requirements with bullet point lists." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Acknowledge the importance of codebase modularity for reuse." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Move requirements related to Findability to the new criterion." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Clarify the role of non-open standards when used in a codebase." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Additional guidance about build-time and runtime dependencies." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Added roadmap for the development of the Standard for Public Code." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Update structure of Authors file." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Add Audrey Tang to Authors." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "Added a list of criteria to the print edition." +msgstr "" + +#: ./CHANGELOG.md:block 23 (unordered list) +msgid "" +"Clarify what the standard means with policymakers, managers, developers and " +"designers." +msgstr "" + +#: ./CHANGELOG.md:block 24 (header) +msgid "Version 0.3.0" +msgstr "" + +#: ./CHANGELOG.md:block 25 (paragraph) +msgid "" +"May 23rd 2022: 🗎 the tenth draft strengthens documentation and localization." +msgstr "" + +#: ./CHANGELOG.md:block 26 (unordered list) +msgid "" +"Requirement for localization made explicit in Create reusable and portable " +"code." +msgstr "" + +#: ./CHANGELOG.md:block 26 (unordered list) +msgid "Documentation of governance changed from a SHOULD to a MUST." +msgstr "" + +#: ./CHANGELOG.md:block 26 (unordered list) +msgid "" +"Replace the very subjective (and hard to test) \"contributions MUST be " +"small\" with requirement to document expectation in contributing guidelines " +"and focus on a single issue." +msgstr "" + +#: ./CHANGELOG.md:block 26 (unordered list) +msgid "Community translations now linked in the footer." +msgstr "" + +#: ./CHANGELOG.md:block 26 (unordered list) +msgid "Revert \"Replace BPMN svg with Mermaid flowchart\"." +msgstr "" + +#: ./CHANGELOG.md:block 26 (unordered list) +msgid "Many minor clarifications to language and sentences made more simple." +msgstr "" + +#: ./CHANGELOG.md:block 27 (header) +msgid "Version 0.2.3" +msgstr "" + +#: ./CHANGELOG.md:block 28 (paragraph) +msgid "" +"March 15th 2022: 📜 the ninth draft allows English summaries for policy " +"lacking an official translation." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "" +"Relax the criterion Use plain English by adding a new requirement allows " +"bundled policy not available in English to have an accompanying summary in " +"English instead of translating the full text." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "" +"Similarly, allow for English summaries for policies not available in English" +" in Bundle policy and code." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "" +"Clarify that term 'policy' includes processes which impact development and " +"deployment in Bundle policy and code." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "" +"Emphasize reusability also on parts of the solutions in Create reusable and " +"portable code." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "" +"Expand guidance to Developers and designers in Create reusable and portable " +"code about deploying to proprietary platforms." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "" +"Add nuance to use of non-English terms in what management need to do in Use " +"plain English." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "" +"Change the pull request process diagram to use Mermaid instead of BPMN to " +"make [community translations](https://github.com/publiccodenet/community-" +"translations-standard) easier." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "Added Maurice Hendriks to AUTHORS." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "Added OpenApi Specification to further reading." +msgstr "" + +#: ./CHANGELOG.md:block 29 (unordered list) +msgid "Made the attributions in further reading sections clearer." +msgstr "" + +#: ./CHANGELOG.md:block 30 (header) +msgid "Version 0.2.2" +msgstr "" + +#: ./CHANGELOG.md:block 31 (paragraph) +msgid "" +"November 29th 2021: 🏛 the eighth draft recognizes that policy which executes" +" as code may not be in English." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "" +"Document exception to \"All code MUST be in English\" where policy is " +"interpreted as code." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "" +"Add MAY requirement regarding committer email addresses in Maintain version " +"control." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Expand guidance to Policy Makers in Bundle policy and code." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Expand guidance to Developers and designers in Use a coherent style." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Add \"Different contexts\" to glossary." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Add Mauko Quiroga and Charlotte Heikendorf to AUTHORS." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Add Digital Public Goods approval badge." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Added \"next\" and \"previous\" links to criteria pages of web version." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Add Open Standards principles to further reading." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Add Definition of plain language to further reading." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Move the Semantic Versioning Specification further reading reference." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "" +"Clarify that publiccode.yml is one example of a machine-readable metadata " +"description." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Changed \"your codebase\" and \"your organization\" to be less possessive." +msgstr "" + +#: ./CHANGELOG.md:block 32 (unordered list) +msgid "Add instructions for creating a print version." +msgstr "" + +#: ./CHANGELOG.md:block 33 (header) +msgid "Version 0.2.1" +msgstr "" + +#: ./CHANGELOG.md:block 34 (paragraph) +msgid "" +"March 1st 2021: 🧽 the seventh draft has minor cleaning up after version " +"0.2.0." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "" +"New SHOULD requirement on using a distributed version control system and why" +" distributed is important." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "" +"Feedback requirements for rejected contributions are more strict than " +"accepted ones." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "" +"Specify that copyright and license notices should also be machine-readable." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "Advice on how to test that notices be machine-readable." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "Clarify guidance for rolling releases." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "Clear up definition of version control in glossary." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "" +"Add further reading encouraging contribution, SPDX, Git and reviewing " +"contributions." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "Add links to videos about the concept of public code." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "Update BPMN link." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "Reduce link duplication." +msgstr "" + +#: ./CHANGELOG.md:block 35 (unordered list) +msgid "Add Alba Roza and Ngô Ngọc Đức Huy to authors." +msgstr "" + +#: ./CHANGELOG.md:block 36 (header) +msgid "Version 0.2.0" +msgstr "" + +#: ./CHANGELOG.md:block 37 (paragraph) +msgid "" +"October 26th 2020: 🎊 the sixth draft splits a requirement and adds clarity." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "" +"Split \"Welcome contributions\" criterion into \"Make contributing easy\" " +"and \"Welcome contributors\"." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "" +"Rename criterion \"Pay attention to codebase maturity\" to \"Document " +"codebase maturity\"." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "" +"Changed MUST to SHOULD for requirement of codebase in use by multiple " +"parties." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "Add MUST NOT requirement regarding copyright assignment." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "Clarify role of configuration in reusable code requirement." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "" +"Glossary additions: continuous integration, policy, repository, and version " +"control." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "Replace references to 'cities' with 'public organizations'." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "" +"Clarify aspects of sensitive code by separating contributor and reviewer " +"requirements into separate items." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "" +"Expand further reading, and guidance to policy makers, developers and " +"designers." +msgstr "" + +#: ./CHANGELOG.md:block 38 (unordered list) +msgid "Add Felix Faassen and Arnout Engelen to authors." +msgstr "" + +#: ./CHANGELOG.md:block 39 (header) +msgid "Version 0.1.4" +msgstr "" + +#: ./CHANGELOG.md:block 40 (paragraph) +msgid "" +"November 27th 2019: 🧹 the fifth draft consists mostly of additional minor " +"fixes." +msgstr "" + +#: ./CHANGELOG.md:block 41 (unordered list) +msgid "Linked License.md file." +msgstr "" + +#: ./CHANGELOG.md:block 41 (unordered list) +msgid "Add Sky Bristol, Marcus Klaas de Vries, and Jan Ainali to authors." +msgstr "" + +#: ./CHANGELOG.md:block 41 (unordered list) +msgid "Made punctuation more consistent, especially for bullet lists." +msgstr "" + +#: ./CHANGELOG.md:block 41 (unordered list) +msgid "Made some minor changes to text for clarity." +msgstr "" + +#: ./CHANGELOG.md:block 42 (header) +msgid "Version 0.1.3" +msgstr "" + +#: ./CHANGELOG.md:block 43 (paragraph) +msgid "" +"October 8th 2019: 🍂 the fourth draft only patches and fixes minor things for" +" the autumn cleaning" +msgstr "" + +#: ./CHANGELOG.md:block 44 (unordered list) +msgid "Renamed continuous delivery to continuous integration." +msgstr "" + +#: ./CHANGELOG.md:block 44 (unordered list) +msgid "Referencing accessibility guidelines in the language standard." +msgstr "" + +#: ./CHANGELOG.md:block 44 (unordered list) +msgid "A bunch of style and consistency fixes." +msgstr "" + +#: ./CHANGELOG.md:block 45 (header) +msgid "Version 0.1.2" +msgstr "" + +#: ./CHANGELOG.md:block 46 (paragraph) +msgid "" +"August 22th 2019: 🌠 the third draft focuses on better text and takes " +"community input" +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "With some great new contributors comes a fresh author list." +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "All links are now HTTPS." +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "General proofreading, wording clarifications, and smashed typos." +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "Updated criteria:" +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "Requirement for reuse in different contexts" +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "Recommendation for explicit versioning" +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "Recommendation for multi party development" +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "Recommendation for license headers in files" +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "Recommendation for vulnerability reporting" +msgstr "" + +#: ./CHANGELOG.md:block 47 (unordered list) +msgid "Recommendation for explicit documentation of governance" +msgstr "" + +#: ./CHANGELOG.md:block 48 (header) +msgid "Version 0.1.1" +msgstr "" + +#: ./CHANGELOG.md:block 49 (paragraph) +msgid "" +"May 9th 2019: 🤔 the second draft fixes a few basic oversights and fixes a " +"lot of typos" +msgstr "" + +#: ./CHANGELOG.md:block 50 (unordered list) +msgid "" +"Removed references to the Foundation for Public Code, we're going to have to" +" change the name in becoming an association." +msgstr "" + +#: ./CHANGELOG.md:block 50 (unordered list) +msgid "Updated the introduction." +msgstr "" + +#: ./CHANGELOG.md:block 50 (unordered list) +msgid "Updated the glossary." +msgstr "" + +#: ./CHANGELOG.md:block 50 (unordered list) +msgid "Added the code of conduct." +msgstr "" + +#: ./CHANGELOG.md:block 50 (unordered list) +msgid "We've recommended using the publiccode.yml standard for easier reuse." +msgstr "" + +#: ./CHANGELOG.md:block 51 (header) +msgid "Version 0.1.0" +msgstr "" + +#: ./CHANGELOG.md:block 52 (paragraph) +msgid "" +"April 16th 2019: 🎉 the first draft is ready, it is all brand new and has " +"snazzy new ideas in it" +msgstr "" + +#: ./CHANGELOG.md:block 53 (unordered list) +msgid "14 criteria with their requirements and how to operationalize them." +msgstr "" + +#: ./CHANGELOG.md:block 53 (unordered list) +msgid "" +"An introduction with a high level background, what this standard is, and how" +" the Foundation for Public Code will use it." +msgstr "" + +#: ./CHANGELOG.md:block 54 (paragraph) +msgid "" +"This first version was produced together with the Amsterdam University of " +"Applied Sciences and the City of Amsterdam as a part of the [Smart Cities? " +"Public Code! project](https://smartcities.publiccode.net/)." +msgstr "" + +#: ./CODE_OF_CONDUCT.md:block 1 (header) +msgid "Code of Conduct" +msgstr "" + +#: ./CODE_OF_CONDUCT.md:block 3 (paragraph) +msgid "" +"Many community members are from civic or professional environments with " +"behavioral codes yet some individuals are not. This document expresses " +"expectations of all community members and all interactions regardless of " +"communication channel." +msgstr "" + +#: ./CODE_OF_CONDUCT.md:block 4 (paragraph) +msgid "Be here to collaborate." +msgstr "" + +#: ./CODE_OF_CONDUCT.md:block 5 (paragraph) +msgid "Be considerate, respectful, and patient." +msgstr "" + +#: ./CODE_OF_CONDUCT.md:block 6 (paragraph) +msgid "Strive to be as constructive as possible." +msgstr "" + +#: ./CODE_OF_CONDUCT.md:block 7 (paragraph) +msgid "To raise a concern, please email directors@publiccode.net." +msgstr "" + +#: ./CONTRIBUTING.md:block 1 (header) +msgid "Contributing to this standard" +msgstr "" + +#: ./CONTRIBUTING.md:block 3 (paragraph) +msgid "🙇‍♀️ Thank you for contributing!" +msgstr "" + +#: ./CONTRIBUTING.md:block 4 (paragraph) +msgid "" +"We understand that a standard like this can only be set in collaboration " +"with as many public technologists, policy makers and interested folk as " +"possible. Thus we appreciate your input, enjoy feedback and welcome " +"improvements to this project and are very open to collaboration." +msgstr "" + +#: ./CONTRIBUTING.md:block 5 (paragraph) +msgid "" +"We love issues and pull requests from everyone. If you're not comfortable " +"with GitHub, you can email use your feedback at " +"[info@publiccode.net](mailto:info@publiccode.net)." +msgstr "" + +#: ./CONTRIBUTING.md:block 6 (header) +msgid "Problems, suggestions and questions in issues" +msgstr "" + +#: ./CONTRIBUTING.md:block 7 (paragraph) +msgid "" +"A high-level overview of the development that we already have sketched out " +"can be seen in the [roadmap](/docs/roadmap.md). Please help development by " +"reporting problems, suggesting changes and asking questions. To do this, you" +" can [create a GitHub issue](https://docs.github.com/en/issues/tracking-" +"your-work-with-issues/creating-an-issue) for this project in the [GitHub " +"Issues for the Standard for Public " +"Code](https://github.com/publiccodenet/standard/issues)." +msgstr "" + +#: ./CONTRIBUTING.md:block 8 (paragraph) +msgid "" +"Or, sign up to the [mailing " +"list](https://lists.publiccode.net/mailman/postorius/lists/standard.lists.publiccode.net/)" +" and send an email to " +"[standard@lists.publiccode.net](mailto:standard@lists.publiccode.net)." +msgstr "" + +#: ./CONTRIBUTING.md:block 9 (paragraph) +msgid "" +"You don't need to change any of our code or documentation to be a " +"contributor!" +msgstr "" + +#: ./CONTRIBUTING.md:block 10 (header) +msgid "Documentation and code in pull requests" +msgstr "" + +#: ./CONTRIBUTING.md:block 11 (paragraph) +msgid "" +"If you want to add to the documentation or code of one of our projects you " +"should make a pull request." +msgstr "" + +#: ./CONTRIBUTING.md:block 12 (paragraph) +msgid "" +"If you never used GitHub, get up to speed with [Understanding the GitHub " +"flow](https://docs.github.com/en/get-started/quickstart/github-flow) or " +"follow one of the great free interactive courses in [GitHub " +"Skills](https://skills.github.com/) on working with GitHub and working with " +"MarkDown, the syntax this project's documentation is in." +msgstr "" + +#: ./CONTRIBUTING.md:block 13 (paragraph) +msgid "" +"This project is licensed Creative Commons Zero v1.0 Universal, which " +"essentially means that the project, along with your contributions is in the " +"public domain in whatever jurisdiction possible, and everyone can do " +"whatever they want with it." +msgstr "" + +#: ./CONTRIBUTING.md:block 14 (header) +msgid "1. Make your changes" +msgstr "" + +#: ./CONTRIBUTING.md:block 15 (paragraph) +msgid "" +"Contributions should [follow](docs/standard-for-public-code.html) the " +"requirements set out in the criteria of the Standard for Public code itself." +" Reviewers will also be ensuring that contributions are aligned with the " +"[values of public code](foreword.md#values-of-public-code). Furthermore, " +"they will review that the contribution conforms to the " +"[standards](#standards-to-follow) and remains coherent with the overall " +"work." +msgstr "" + +#: ./CONTRIBUTING.md:block 16 (paragraph) +msgid "" +"This project uses the [GitFlow branching model and " +"workflow](https://nvie.com/posts/a-successful-git-branching-model/). When " +"you've forked this repository, please make sure to create a feature branch " +"following the GitFlow model." +msgstr "" + +#: ./CONTRIBUTING.md:block 17 (paragraph) +msgid "" +"Add your changes in commits [with a message that explains " +"them](https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-" +"message). If more than one type of change is needed, group logically related" +" changes into separate commits. For example, white-space fixes could be a " +"separate commit from text content changes. When adding new files, select " +"file formats that are easily viewed in a `diff`, for instance, `.svg` is " +"preferable to a binary image. Document choices or decisions you make in the " +"commit message, this will enable everyone to be informed of your choices in " +"the future." +msgstr "" + +#: ./CONTRIBUTING.md:block 18 (paragraph) +msgid "" +"If you are adding code, make sure you've added and updated the relevant " +"documentation and tests before you submit your pull request. Make sure to " +"write tests that show the behavior of the newly added or changed code." +msgstr "" + +#: ./CONTRIBUTING.md:block 19 (header) +msgid "Applicable policy" +msgstr "" + +#: ./CONTRIBUTING.md:block 20 (paragraph) +msgid "" +"Currently, the Standard for Public Code is not implementing any specific " +"public policy." +msgstr "" + +#: ./CONTRIBUTING.md:block 21 (header) +msgid "Style" +msgstr "" + +#: ./CONTRIBUTING.md:block 22 (paragraph) +msgid "" +"The Standard for Public Code aims to [use plain English](criteria/use-plain-" +"english.md) and we have chosen American English for spelling. Text content " +"should typically follow one line per sentence, with no line-wrap, in order " +"to make `diff` output easier to view. However, we want to emphasize that it " +"is more important that you make your contribution than worry about spelling " +"and typography. We will help you get it right in our review process and we " +"also have a separate quality check before [making a new " +"release](docs/releasing.md)." +msgstr "" + +#: ./CONTRIBUTING.md:block 23 (header) +msgid "Standards to follow" +msgstr "" + +#: ./CONTRIBUTING.md:block 24 (paragraph) +msgid "" +"These are the standards that the Standard for Public Code uses. Please make " +"sure that your contributions are aligned with them so that they can be " +"merged more easily." +msgstr "" + +#: ./CONTRIBUTING.md:block 25 (unordered list) +msgid "" +"[IETF RFC 2119](https://tools.ietf.org/html/rfc2119) - for requirement level" +" keywords" +msgstr "" + +#: ./CONTRIBUTING.md:block 25 (unordered list) +msgid "" +"[Web Content Accessibility Guidelines " +"2.1](https://www.w3.org/TR/WCAG21/#readable) - for readability" +msgstr "" + +#: ./CONTRIBUTING.md:block 26 (header) +msgid "2. Pull request" +msgstr "" + +#: ./CONTRIBUTING.md:block 27 (paragraph) +msgid "" +"When submitting the pull request, please accompany it with a description of " +"the problem you are trying to solve and the issue number that this pull " +"request fixes. It is preferred for each pull request to address a single " +"issue where possible. In some cases a single set of changes may address " +"multiple issues, in which case be sure to list all issue numbers fixed." +msgstr "" + +#: ./CONTRIBUTING.md:block 28 (header) +msgid "3. Improve" +msgstr "" + +#: ./CONTRIBUTING.md:block 29 (paragraph) +msgid "" +"All contributions have to be reviewed by someone. The Foundation for Public " +"Code has committed to make sure that maintainers are available to review " +"contributions with an aim to provide feedback within two business days." +msgstr "" + +#: ./CONTRIBUTING.md:block 30 (paragraph) +msgid "" +"It could be that your contribution can be merged immediately by a " +"maintainer. However, usually, a new pull request needs some improvements " +"before it can be merged. Other contributors (or helper robots) might have " +"feedback. If this is the case the reviewing maintainer will help you improve" +" your documentation and code." +msgstr "" + +#: ./CONTRIBUTING.md:block 31 (paragraph) +msgid "If your documentation and code have passed human review, it is merged." +msgstr "" + +#: ./CONTRIBUTING.md:block 32 (header) +msgid "4. Celebrate" +msgstr "" + +#: ./CONTRIBUTING.md:block 33 (paragraph) +msgid "" +"Your ideas, documentation and code have become an integral part of this " +"project. You are the open source hero we need!" +msgstr "" + +#: ./CONTRIBUTING.md:block 34 (paragraph) +msgid "" +"In fact, feel free to open a pull request to add your name to the " +"[`AUTHORS`](AUTHORS.md) file and get eternal attribution." +msgstr "" + +#: ./CONTRIBUTING.md:block 35 (header) +msgid "Translations in other languages" +msgstr "" + +#: ./CONTRIBUTING.md:block 36 (paragraph) +msgid "" +"While the Standard does not have any official translations, you can help " +"maintain existing and add new [community translations of the " +"Standard](https://github.com/publiccodenet/community-translations-standard)." +msgstr "" + +#: ./CONTRIBUTING.md:block 37 (header) +msgid "Releases" +msgstr "" + +#: ./CONTRIBUTING.md:block 38 (paragraph) +msgid "" +"We have dedicated documentation for creating [new " +"releases](/docs/releasing.md) and [ordering printed " +"standards](/docs/printing.md)." +msgstr "" + +#: ./CONTRIBUTING.md:block 39 (paragraph) +msgid "" +"For more information on how to use and contribute to this project, please " +"read the [`README`](README.md)." +msgstr "" + +#: ./GOVERNANCE.md:block 2 (header) +msgid "" +"SPDX-FileCopyrightText: 2019-2022 The Foundation for Public Code " +"[info@publiccode.net](mailto:info@publiccode.net), " +"https://standard.publiccode.net/AUTHORS" +msgstr "" + +#: ./GOVERNANCE.md:block 3 (header) +msgid "Governance" +msgstr "" + +#: ./GOVERNANCE.md:block 4 (paragraph) +msgid "" +"This standard lies at the core of the codebase stewardship provided by the " +"[Foundation for Public Code](https://publiccode.net/). We decide if a " +"codebase is ready for community co-development based on this document." +msgstr "" + +#: ./GOVERNANCE.md:block 5 (paragraph) +msgid "The standard is maintained by Foundation for Public Code staff." +msgstr "" + +#: ./GOVERNANCE.md:block 6 (paragraph) +msgid "" +"[We welcome contributions, such as suggestions for changes or general " +"feedback, from anyone.](/CONTRIBUTING.md)" +msgstr "" + +#: ./GOVERNANCE.md:block 7 (paragraph) +msgid "" +"Because of the important role that the Standard for Public Code has in our " +"core process we require the highest standards from the Standard." +msgstr "" + +#: ./GOVERNANCE.md:block 8 (paragraph) +msgid "" +"We will try to respond promptly to all pull requests. The pull request is an" +" opportunity to work together to improve our methods and the Standard. We " +"may not accept all changes, but we will explain our logic." +msgstr "" + +#: ./README.md:block 1 (header) +msgid "Standard for Public Code" +msgstr "" + +#: ./README.md:block 3 (paragraph) +msgid "" +"The Standard for Public Code gives public organizations a model for " +"preparing open source solutions to enable collaborations with similar public" +" organizations in other places. It includes guidance for policy makers, city" +" administrators, developers and vendors." +msgstr "" + +#: ./README.md:block 4 (paragraph) +msgid "" +"![version 0.7.1](assets/version-badge.svg) [![License: " +"CC0-1.0](https://img.shields.io/badge/License-" +"CC0_1.0-lightgrey.svg)](http://creativecommons.org/publicdomain/zero/1.0/) " +"[![Standard commitment](assets/standard-for-public-code-" +"commitment.svg)](#help-improve-this-standard)" +msgstr "" + +#: ./README.md:block 5 (paragraph) +msgid "" +"[![pages-build-" +"deployment](https://github.com/publiccodenet/standard/actions/workflows/pages/pages-" +"build-" +"deployment/badge.svg)](https://github.com/publiccodenet/standard/actions/workflows/pages/pages-" +"build-deployment) " +"[![Test](https://github.com/publiccodenet/standard/actions/workflows/test.yml/badge.svg)](https://github.com/publiccodenet/standard/actions/workflows/test.yml)" +" [![standard main badge](https://publiccodenet.github.io/publiccodenet-url-" +"check/badges/standard.publiccode.net.svg)](https://publiccodenet.github.io/publiccodenet-" +"url-check/standard.publiccode.net-url-check-look.json) [![standard develop " +"badge](https://publiccodenet.github.io/publiccodenet-url-" +"check/badges/standard.publiccode.net-" +"develop.svg)](https://publiccodenet.github.io/publiccodenet-url-" +"check/standard.publiccode.net-develop-url-check-look.json)" +msgstr "" + +#: ./README.md:block 6 (paragraph) +msgid "" +"The Standard for Public Code is in a draft format. We are preparing it for a" +" version 1.0 release. Currently, we are testing it on a small number of " +"codebases." +msgstr "" + +#: ./README.md:block 7 (header) +msgid "Applying the Standard for Public Code to your codebase" +msgstr "" + +#: ./README.md:block 8 (paragraph) +msgid "" +"If you want to apply the Standard for Public Code to your codebase, just go " +"ahead, it's an open standard and free for anyone to use. If you wish to " +"advertise the codebase community's aspiration to meet the criteria of the " +"Standard for Public Code, link the documentation of this commitment from the" +" [standard-for-public-code-commitment badge](assets/standard-for-public-" +"code-commitment.svg). To see how ready your codebase is, you can do a quick " +"[eligibility self assessment](https://publiccodenet.github.io/assessment-" +"eligibility) that will give you a rough idea of how much work you may need " +"to do to meet all criteria." +msgstr "" + +#: ./README.md:block 9 (paragraph) +msgid "" +"The standard *should* be mostly self-explanatory in how to apply it to your " +"codebase. If anything in the standard is unclear, we encourage you to open " +"an issue here so that we can help you and anyone else who feels the same as " +"you. For inspiration, look at the [community built implementation " +"guide](https://publiccodenet.github.io/community-implementation-guide-" +"standard/) which contains examples and other tips." +msgstr "" + +#: ./README.md:block 10 (paragraph) +msgid "" +"If there are any breaking changes in a new version of the Standard for " +"Public Code, the codebase stewards at the Foundation for Public Code will " +"help any implementers of the standard understand how the gaps can be closed." +msgstr "" + +#: ./README.md:block 11 (paragraph) +msgid "" +"If you want to commit your codebase to become fully compliant to the " +"standard for future certification, please contact us at " +"[info@publiccode.net](mailto:info@publiccode.net) to initiate a formal " +"[assessment](https://about.publiccode.net/activities/codebase-" +"stewardship/lifecycle-diagram.html#assessment)." +msgstr "" + +#: ./README.md:block 12 (header) +msgid "Request for contributions" +msgstr "" + +#: ./README.md:block 13 (paragraph) +msgid "" +"We believe public policy and software should be inclusive, usable, open, " +"legible, accountable, accessible and sustainable. This means we need a new " +"way of designing, developing and procuring both the source code and policy " +"documentation." +msgstr "" + +#: ./README.md:block 14 (paragraph) +msgid "" +"This standard sets a quality level for codebases that meets the needs of " +"public organizations, institutions and administrations as well as other " +"critical infrastructural services." +msgstr "" + +#: ./README.md:block 15 (paragraph) +msgid "" +"The standard lives at " +"[standard.publiccode.net](https://standard.publiccode.net/). See " +"[`index.md`](index.md) for an overview of all content." +msgstr "" + +#: ./README.md:block 16 (paragraph) +msgid "" +"[![Thumbnail for the video on the Standard for Public Code: a printed " +"version lying on a table between two " +"hands](https://img.youtube.com/vi/QWt6vB-" +"cipE/mqdefault.jpg)](https://www.youtube.com/watch?v=QWt6vB-cipE)" +msgstr "" + +#: ./README.md:block 17 (paragraph) +msgid "" +"[A video introduction to Standard for Public " +"Code](https://www.youtube.com/watch?v=QWt6vB-cipE) from Creative Commons " +"Global Summit 2020 (4:12) on YouTube." +msgstr "" + +#: ./README.md:block 18 (header) +msgid "Help improve this standard" +msgstr "" + +#: ./README.md:block 19 (paragraph) +msgid "" +"The Foundation for Public Code is committed to maintaining and developing " +"the Standard for Public Code at a level of quality that meets the standard " +"itself." +msgstr "" + +#: ./README.md:block 20 (paragraph) +msgid "" +"We are looking for people like you to [contribute](CONTRIBUTING.md) to this " +"project by suggesting improvements and helping develop it. 😊 Get started by " +"reading our [contributors guide](CONTRIBUTING.md). Since it is such a core " +"document we will accept contributions when they add significant value. We've" +" described how we govern the standard in the [governance " +"statement](GOVERNANCE.md)." +msgstr "" + +#: ./README.md:block 21 (paragraph) +msgid "" +"Please note that this project is released with a [code of " +"conduct](CODE_OF_CONDUCT.md). By participating in this project you agree to " +"abide by its terms. Please be lovely to all other community members." +msgstr "" + +#: ./README.md:block 22 (header) +msgid "Preview, build and deploy" +msgstr "" + +#: ./README.md:block 23 (paragraph) +msgid "" +"The repository builds to a static site deployed at " +"[standard.publiccode.net](https://standard.publiccode.net/). It is built " +"with [GitHub pages](https://pages.github.com) and " +"[Jekyll](https://jekyllrb.com/)." +msgstr "" + +#: ./README.md:block 24 (paragraph) +msgid "" +"The content is made to be built with [Jekyll](http://jekyllrb.com/), which " +"means you will need ruby and ruby-bundler installed, for example:" +msgstr "" + +#: ./README.md:block 26 (paragraph) +msgid "" +"If `ruby` and `bundle` are installed, one can run `bundle install` after " +"which the site can be rendered with the `script/serve.sh` script." +msgstr "" + +#: ./README.md:block 27 (header) +msgid "Testing" +msgstr "" + +#: ./README.md:block 28 (paragraph) +msgid "" +"A variety of test scripts are included. The script `script/test-all.sh` " +"wraps running of all local tests." +msgstr "" + +#: ./README.md:block 29 (paragraph) +msgid "" +"See the scripts in the " +"[script](https://github.com/publiccodenet/standard/tree/main/script) folder." +msgstr "" + +#: ./README.md:block 30 (header) +msgid "Generating a PDF of the Standard for Public Code" +msgstr "" + +#: ./README.md:block 31 (paragraph) +msgid "" +"In addition to Jekyll, generating PDFs relies upon " +"[Weasyprint](https://weasyprint.org/) and " +"[QPDF](https://github.com/qpdf/qpdf). [Pandoc](https://pandoc.org/) can be " +"used to transform PDFs into `.epub`." +msgstr "" + +#: ./README.md:block 32 (paragraph) +msgid "" +"To generate these kinds of files, the dependencies should be installed, for " +"example:" +msgstr "" + +#: ./README.md:block 34 (paragraph) +msgid "" +"The file `standard-print.html` can be converted to a nice looking PDF, along" +" with the other release files, using:" +msgstr "" + +#: ./README.md:block 36 (header) +msgid "License" +msgstr "" + +#: ./README.md:block 37 (paragraph) +msgid "© [The authors and contributors](AUTHORS.md)" +msgstr "" + +#: ./README.md:block 38 (paragraph) +msgid "" +"The standard is [licensed](LICENSE) under CC 0, which also applies to all " +"illustrations and the documentation. This means anyone can do anything with " +"it. If you contribute you also grant these rights to others. You can read " +"more about how to help in the [contributing guide](CONTRIBUTING.md)." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 3 (paragraph) +msgid "order: 2 redirect_from:" +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 4 (unordered list) +msgid "criteria/bundle-policy-and-code" +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 5 (header) +msgid "Bundle policy and source code" +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 6 (paragraph) +msgid "" +"Access to both [source code](../glossary.md#source-code) and " +"[policy](../glossary.md#policy) documentation provides building blocks for " +"anyone to implement the codebase in their local context or contribute to the" +" further development of the [codebase](../glossary.md#codebase)." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 7 (paragraph) +msgid "" +"Understanding the domain and policies within that domain is fundamental to " +"understanding what problems a codebase is trying to solve and how it sets " +"out to solve them." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 8 (paragraph) +msgid "" +"To be able to evaluate whether to implement a codebase in a new context, an " +"organization needs to understand what process changes it must choose to make" +" or how to contribute additional configurability to the existing solution in" +" order to adapt it to the new context." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 9 (header) +msgid "Requirements" +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 10 (unordered list) +msgid "The codebase MUST include the policy that the source code is based on." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 10 (unordered list) +msgid "" +"If a policy is based on source code, that source code MUST be included in " +"the codebase, unless used for fraud detection." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 10 (unordered list) +msgid "Policy SHOULD be provided in machine readable and unambiguous formats." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 10 (unordered list) +msgid "" +"[Continuous integration](../glossary.md#continuous-integration) tests SHOULD" +" validate that the source code and the policy are executed coherently." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 11 (header) +msgid "How to test" +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 12 (unordered list) +msgid "" +"Confirm with a civil servant that all policy that the source code is based " +"on is included." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 12 (unordered list) +msgid "" +"Confirm with a civil servant that all source code that the policy is based " +"on is included." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 12 (unordered list) +msgid "Check if policy can be interpreted by a machine." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 12 (unordered list) +msgid "" +"Check the continuous integration tests for coherent execution of source code" +" and policy pass." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 13 (header) +msgid "Public policy makers: what you need to do" +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Collaborate with developers and designers to make sure there is no mismatch " +"between policy code and source code." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Provide the relevant policy texts for inclusion in the " +"[repository](../glossary.md#repository); if the text is not available in " +"English, also provide an English summary. Be sure to include standards that " +"your organization has chosen to adhere to and any organizational processes " +"which impact the development or the deployment context of the codebase for " +"your organization." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "Provide references and links to texts which support the policies." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Document policy in formats that are unambiguous and machine-readable, such " +"as those published by the [Object Management " +"Group](https://www.omg.org/spec/)." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Track policy with [the same version control](maintain-version-control.md) " +"and documentation used to track source code." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Check in regularly to understand how the source code in the codebase has " +"changed and whether it still matches the [intentions of the " +"policy](document-codebase-objectives.md)." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Include relevant policies which impact the community, codebase, and " +"development, including legal obligations like the [General Data Protection " +"Regulation](https://eur-lex.europa.eu/eli/reg/2016/679/oj) or the [EU Web " +"Accessibility Directive](https://ec.europa.eu/digital-single-market/en/web-" +"accessibility), or human rights policies, like a public organization's " +"commitment to equal opportunity." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 15 (header) +msgid "Managers: what you need to do" +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 16 (unordered list) +msgid "" +"Keep policy makers, developers and designers involved and connected " +"throughout the whole development process." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 16 (unordered list) +msgid "" +"Make sure policy makers, developers and designers are working to the same " +"objectives." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 17 (header) +msgid "Developers and designers: what you need to do" +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 18 (unordered list) +msgid "" +"Become familiar with and be able to use the process modelling notation that " +"the policy makers in your organization use." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 18 (unordered list) +msgid "" +"Work together with policy makers to make sure there is no mismatch between " +"policy code and source code." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 18 (unordered list) +msgid "Give feedback on how to make policy documentation more clear." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 19 (header) +msgid "Further reading" +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 20 (unordered list) +msgid "" +"[Business Process Model and " +"Notation](https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation)" +" on Wikipedia." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 20 (unordered list) +msgid "" +"[BPMN Quick Guide](https://www.bpmnquickguide.com/view-bpmn-quick-guide/) by" +" Trisotech." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 20 (unordered list) +msgid "" +"[Decision Model and " +"Notation](https://en.wikipedia.org/wiki/Decision_Model_and_Notation) on " +"Wikipedia." +msgstr "" + +#: ./criteria/bundle-policy-and-source-code.md:block 20 (unordered list) +msgid "" +"[Case Management Model Notation](https://en.wikipedia.org/wiki/CMMN) on " +"Wikipedia." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 3 (header) +msgid "order: 1" +msgstr "" + +#: ./criteria/code-in-the-open.md:block 4 (header) +msgid "Code in the open" +msgstr "" + +#: ./criteria/code-in-the-open.md:block 5 (paragraph) +msgid "" +"Coding in the open improves transparency, increases [source " +"code](../glossary.md#source-code) quality, makes the source code easier to " +"audit, and enables collaboration." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 6 (paragraph) +msgid "" +"Together, this creates more opportunities for citizens to understand how " +"software and [policy](../glossary.md#policy) impact their interactions with " +"a public organization." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"All source code for any policy in use (unless used for fraud detection) MUST" +" be published and publicly accessible." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"All source code for any software in use (unless used for fraud detection) " +"MUST be published and publicly accessible." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"The codebase MUST NOT contain sensitive information regarding users, their " +"organization or third parties." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"Any source code not currently in use (such as new versions, proposals or " +"older versions) SHOULD be published." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"Documenting which source code or policy underpins any specific interaction " +"the [general public](../glossary.md#general-public) may have with an " +"organization is OPTIONAL." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 10 (unordered list) +msgid "" +"Confirm that the source for each version currently in use is published on " +"the internet where it can be seen from outside the original contributing " +"organization and without the need for any form of authentication or " +"authorization." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 10 (unordered list) +msgid "" +"Confirm that the [codebase](../glossary.md#codebase) files and commit " +"history do not include sensitive information." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 10 (unordered list) +msgid "Check for the publication of source code not currently in use." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 12 (unordered list) +msgid "Develop policies in the open." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 12 (unordered list) +msgid "Prioritize open and transparent policies." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 14 (unordered list) +msgid "Develop a culture that embraces openness, learning and feedback." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 14 (unordered list) +msgid "" +"Collaborate with external vendors and freelancers by working in the open." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 16 (unordered list) +msgid "" +"As a reviewer, for each commit, verify that content does not include " +"sensitive information such as configurations, usernames or passwords, public" +" keys or other real credentials used in production systems." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 16 (unordered list) +msgid "" +"Clearly split data and source code, in order to meet the requirement about " +"sensitive information above." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[Coding in the open](https://gds.blog.gov.uk/2012/10/12/coding-in-the-open/)" +" by the UK Government Digital Service." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[When code should be open or " +"closed](https://www.gov.uk/government/publications/open-source-" +"guidance/when-code-should-be-open-or-closed) by the UK Government Digital " +"Service." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[Security considerations when coding in the " +"open](https://www.gov.uk/government/publications/open-source-" +"guidance/security-considerations-when-coding-in-the-open) by the UK " +"Government Digital Service." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[Deploying software regularly](https://www.gov.uk/service-" +"manual/technology/deploying-software-regularly) by the UK Government Digital" +" Service." +msgstr "" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[How GDS uses GitHub](https://gdstechnology.blog.gov.uk/2014/01/27/how-we-" +"use-github/) by the UK Government Digital Service." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 3 (header) +msgid "" +"order: 16 redirect_from: - criteria/advertise-maturity - criteria/document-" +"maturity" +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 4 (header) +msgid "Document codebase maturity" +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 5 (paragraph) +msgid "" +"Clearly signalling a [codebase](../glossary.md#codebase)'s maturity helps " +"others decide whether to use and contribute to it. A codebase version's " +"maturity includes the maturity of its dependencies. Understanding how a " +"codebase has evolved is key to understanding the codebase and how to " +"contribute to it." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "The codebase MUST be versioned." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "" +"The codebase MUST prominently document whether or not there are versions of " +"the codebase that are ready to use." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "" +"Codebase versions that are ready to use MUST only depend on versions of " +"other codebases that are also ready to use." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "" +"The codebase SHOULD contain a log of changes from version to version, for " +"example in the `CHANGELOG`." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "The method for assigning version identifiers SHOULD be documented." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "It is OPTIONAL to use semantic versioning." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "" +"Confirm that the codebase has a strategy for versioning which is documented." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "" +"Confirm that it is obvious to policy makers, managers, developers and " +"designers whether the codebase has versions that are ready to use." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "" +"Confirm that ready to use versions of the codebase do not depend on any " +"versions of other codebases that are not ready to use." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "" +"Check that the versioning scheme of the codebase is documented and followed." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "Check that there is a log of changes." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 11 (unordered list) +msgid "" +"When developing [policy](../glossary.md#policy), understand that any [source" +" code](../glossary.md#source-code) developed needs to be tested and improved" +" before it can be put into service." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 11 (unordered list) +msgid "" +"Consider versioning policy changes, especially when they trigger new " +"versions of the source code." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 13 (unordered list) +msgid "" +"Make sure that services only rely on versions of codebases of equal or " +"greater maturity than the service. For example, don't use a beta version of " +"a codebase in a production service." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 15 (unordered list) +msgid "" +"Make sure that the codebase versioning approach is followed for all " +"releases." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 17 (unordered list) +msgid "" +"[Semantic Versioning Specification](https://semver.org/) used by many " +"codebases to label versions." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 17 (unordered list) +msgid "" +"[Software release life " +"cycle](https://en.wikipedia.org/wiki/Software_release_life_cycle)" +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 17 (unordered list) +msgid "" +"[Service Design and Delivery Process](https://www.dta.gov.au/help-and-" +"advice/build-and-improve-services/service-design-and-delivery-process) by " +"the Australian Digital Transformation Agency." +msgstr "" + +#: ./criteria/document-codebase-maturity.md:block 17 (unordered list) +msgid "" +"[Service Manual on Agile Delivery](https://www.gov.uk/service-manual/agile-" +"delivery) by the UK Government Digital Service." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 3 (paragraph) +msgid "order: 8 redirect_from:" +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 4 (unordered list) +msgid "criteria/document-objectives" +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 5 (header) +msgid "Document codebase objectives" +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 6 (paragraph) +msgid "" +"Clearly documenting [codebase](../glossary.md#codebase) objectives " +"communicates the purpose of the codebase. It helps stakeholders and " +"contributors scope the development of the codebase. The objectives also " +"provide an easy way for people to decide whether this codebase, or one of " +"its modules, is interesting for them now or in the future." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 8 (unordered list) +msgid "" +"The codebase MUST contain documentation of its objectives, like a mission " +"and goal statement, that is understandable by developers and designers so " +"that they can use or contribute to the codebase." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 8 (unordered list) +msgid "" +"Codebase documentation SHOULD clearly describe the connections between " +"[policy](../glossary.md#policy) objectives and codebase objectives." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 8 (unordered list) +msgid "" +"Documenting the objectives of the codebase for the [general " +"public](../glossary.md#general-public) is OPTIONAL." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 10 (unordered list) +msgid "" +"Confirm that the codebase documentation includes the codebase objectives, " +"mission or goal." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 10 (unordered list) +msgid "" +"Check for descriptions of connections between policy objectives and codebase" +" objectives." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 12 (unordered list) +msgid "" +"Add the policy objectives to the codebase documentation, for example in the " +"`README`." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 12 (unordered list) +msgid "" +"Make sure that all your codebase objectives have links or references to " +"supporting policy documents added to meet the [Bundle policy and source " +"code](bundle-policy-and-source-code.md) criterion." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 14 (unordered list) +msgid "" +"Add the organizational and business objectives to the codebase " +"documentation, for example in the `README`." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 16 (unordered list) +msgid "" +"Add the technology and design objectives to the codebase documentation, for " +"example in the `README`." +msgstr "" + +#: ./criteria/document-codebase-objectives.md:block 18 (unordered list) +msgid "" +"[How to write project " +"objectives](http://grouper.ieee.org/groups/802/3/RTPGE/public/may12/hajduczenia_01_0512.pdf)" +" by Marek Hajduczenia." +msgstr "" + +#: ./criteria/document-the-code.md:block 3 (paragraph) +msgid "order: 9 redirect_from:" +msgstr "" + +#: ./criteria/document-the-code.md:block 4 (unordered list) +msgid "criteria/documenting" +msgstr "" + +#: ./criteria/document-the-code.md:block 5 (header) +msgid "Document the code" +msgstr "" + +#: ./criteria/document-the-code.md:block 6 (paragraph) +msgid "" +"Well documented [source code](../glossary.md#source-code) helps people to " +"understand what the source code does and how to use it. Documentation is " +"essential for people to start using the [codebase](../glossary.md#codebase) " +"and contributing to it more quickly." +msgstr "" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"All of the functionality of the codebase, [policy](../glossary.md#policy) as" +" well as source code, MUST be described in language clearly understandable " +"for those that understand the purpose of the codebase." +msgstr "" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase MUST contain a description of how to " +"install and run the software." +msgstr "" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase MUST contain examples demonstrating the " +"key functionality." +msgstr "" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase SHOULD contain a high level description " +"that is clearly understandable for a wide audience of stakeholders, like the" +" [general public](../glossary.md#general-public) and journalists." +msgstr "" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase SHOULD contain a section describing how to" +" install and run a standalone version of the source code, including, if " +"necessary, a test dataset." +msgstr "" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase SHOULD contain examples for all " +"functionality." +msgstr "" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation SHOULD describe the key components or modules of the " +"codebase and their relationships, for example as a high level architectural " +"diagram." +msgstr "" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"There SHOULD be [continuous integration](../glossary.md#continuous-" +"integration) tests for the quality of the documentation." +msgstr "" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"Including examples that make users want to immediately start using the " +"codebase in the documentation of the codebase is OPTIONAL." +msgstr "" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Confirm that other stakeholders, professionals from other public " +"organizations and the general public find the documentation clear and " +"understandable." +msgstr "" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Confirm that the documentation describes how to install and run the source " +"code." +msgstr "" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Confirm that the documentation includes examples of the key functionality." +msgstr "" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Check with members of the general public and journalists if they can " +"understand the high level description." +msgstr "" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Check that the instructions for how to install and run a standalone version " +"of the source code result in a running system." +msgstr "" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "Check that all functionality documented contains an example." +msgstr "" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Check that the documentation includes a high level architectural diagram or " +"similar." +msgstr "" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Check that the documentation quality is part of integration testing, for " +"example documentation is generated correctly, and links and images are " +"tested." +msgstr "" + +#: ./criteria/document-the-code.md:block 12 (unordered list) +msgid "" +"Check in regularly to understand how the non-policy code in the codebase has" +" changed." +msgstr "" + +#: ./criteria/document-the-code.md:block 12 (unordered list) +msgid "Give feedback on how to make non-policy documentation more clear." +msgstr "" + +#: ./criteria/document-the-code.md:block 14 (unordered list) +msgid "" +"Try to use the codebase, so your feedback can improve how clearly the policy" +" and source code are documented. For example, is the current documentation " +"sufficient to persuade a manager at another public organization to use this " +"codebase?" +msgstr "" + +#: ./criteria/document-the-code.md:block 14 (unordered list) +msgid "" +"Make sure you understand both the policy and source code as well as the " +"documentation." +msgstr "" + +#: ./criteria/document-the-code.md:block 16 (unordered list) +msgid "" +"Check in regularly to understand how the non-source code in the codebase has" +" changed." +msgstr "" + +#: ./criteria/document-the-code.md:block 16 (unordered list) +msgid "Give feedback on how to make non-source documentation more clear." +msgstr "" + +#: ./criteria/document-the-code.md:block 18 (unordered list) +msgid "" +"[Documentation guide](https://www.writethedocs.org/guide/) by Write the " +"Docs." +msgstr "" + +#: ./criteria/index.md:block 3 (header) +msgid "order: 0" +msgstr "" + +#: ./criteria/index.md:block 4 (header) +msgid "Criteria" +msgstr "" + +#: ./criteria/index.md:block 5 (paragraph) +msgid "{% assign sorted = site.pages | sort:\"order\" %}" +msgstr "" + +#: ./criteria/index.md:block 6 (paragraph) +msgid "" +"{% for page in sorted %}{% if page.dir == \"/criteria/\" %}{% if page.name " +"!= \"index.md\" %}{% if page.title %}" +msgstr "" + +#: ./criteria/index.md:block 7 (ordered list) +msgid "" +"[{{page.title}}]({{page.url}}){% endif%} {% endif%} {% endif%}{% endfor %}" +msgstr "" + +#: ./criteria/maintain-version-control.md:block 3 (paragraph) +msgid "order: 6 redirect_from:" +msgstr "" + +#: ./criteria/maintain-version-control.md:block 4 (unordered list) +msgid "criteria/version-control-and-history" +msgstr "" + +#: ./criteria/maintain-version-control.md:block 5 (header) +msgid "Maintain version control" +msgstr "" + +#: ./criteria/maintain-version-control.md:block 6 (paragraph) +msgid "" +"[Version control](../glossary.md#version-control) means keeping track of " +"changes to the [source code](../glossary.md#source-code) and other files of " +"the [codebase](../glossary.md#codebase) over time. This allows you to " +"maintain structured documentation of the history of the codebase. This is " +"essential for collaboration at scale, as it enables developers to work on " +"changes in parallel and helps future developers to understand the reasons " +"for changes." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "All files in the codebase MUST be version controlled." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "All decisions MUST be documented in commit messages." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"Every commit message MUST link to discussions and issues wherever possible." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"The codebase SHOULD be maintained in a distributed version control system." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"Contribution guidelines SHOULD require contributors to group relevant " +"changes in commits." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"Maintainers SHOULD mark released versions of the codebase, for example using" +" revision tags or textual labels." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"Contribution guidelines SHOULD encourage file formats where the changes " +"within the files can be easily viewed and understood in the version control " +"system." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"It is OPTIONAL for contributors to sign their commits and provide an email " +"address, so that future contributors are able to contact past contributors " +"with questions about their work." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Confirm that the codebase is kept in version control using software such as " +"Git." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Review the commit history, confirming that all commit messages explain why " +"the change was made." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Review the commit history, confirming that where possible all commit " +"messages include the discussion about the change was or where to find it " +"(with a URL)." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "Check if the version control system is distributed." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Review the commit history, check if grouping of relevant changes in " +"accordance with the contributing guidelines." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Check that it is possible to access a specific version of the codebase, for " +"example through a revision tag or a textual label." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Check that the file formats used in the codebase are text formats where " +"possible." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 12 (unordered list) +msgid "" +"If a new version of the codebase is created because of a " +"[policy](../glossary.md#policy) change, make sure it's clear in the " +"documentation:" +msgstr "" + +#: ./criteria/maintain-version-control.md:block 12 (unordered list) +msgid "what the policy change is," +msgstr "" + +#: ./criteria/maintain-version-control.md:block 12 (unordered list) +msgid "how it's changed the codebase." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 13 (paragraph) +msgid "" +"For example, adding a new category of applicant to a codebase that manages " +"granting permits would be considered a policy change." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 15 (unordered list) +msgid "" +"Support policy makers, developers and designers to be clear about what " +"improvements they're making to the codebase. Making improvements isn't a " +"public relations risk." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "" +"Make sure that all files required to understand the code, build and deploy " +"are in the version control system." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "" +"Write clear commit messages so that it is easy to understand why the commit " +"was made." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "" +"Mark different versions so that it is easy to access a specific version, for" +" example using revision tags or textual labels." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "Write clear commit messages so that versions can be usefully compared." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "" +"Work with policy makers to describe how the source code was updated after a " +"policy change." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 19 (unordered list) +msgid "" +"[Producing OSS: Version Control " +"Vocabulary](https://producingoss.com/en/vc.html#vc-vocabulary) by Karl " +"Fogel." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 19 (unordered list) +msgid "" +"[Maintaining version control in coding](https://www.gov.uk/service-" +"manual/technology/maintaining-version-control-in-coding) by the UK " +"Government Digital Service." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 19 (unordered list) +msgid "" +"[GitHub Skills](https://skills.github.com/) by GitHub for learning how to " +"use GitHub or refresh your skills." +msgstr "" + +#: ./criteria/maintain-version-control.md:block 19 (unordered list) +msgid "" +"[Git Cheat Sheet](https://education.github.com/git-cheat-sheet-" +"education.pdf) by GitHub, a list with the most common used git commands." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 3 (header) +msgid "order: 5" +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 4 (header) +msgid "Make contributing easy" +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 5 (paragraph) +msgid "" +"To develop better, more reliable and feature rich software, users need to be" +" able to fix problems, add features, and address security issues of the " +"shared [codebase](../glossary.md#codebase)." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 6 (paragraph) +msgid "" +"A shared digital infrastructure makes it easier to make collaborative " +"contributions. The less effort it takes to make contributions that are " +"accepted by the codebase, the more likely users are to become contributors." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"The codebase MUST have a public issue tracker that accepts suggestions from " +"anyone." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"The documentation MUST link to both the public issue tracker and submitted " +"codebase changes, for example in a `README` file." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"The codebase MUST have communication channels for users and developers, for " +"example email lists." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"There MUST be a way to report security issues for responsible disclosure " +"over a closed channel." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"The documentation MUST include instructions for how to report potentially " +"security sensitive issues." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "Confirm that there is a public issue tracker." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "" +"Confirm that the codebase contains links to the public issue tracker and " +"submitted codebase changes." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "" +"Confirm that it is possible to participate in a discussion with other users " +"and developers about the software using channels described in the codebase." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "Confirm that there is a closed channel for reporting security issues." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "" +"Confirm that there are instructions for privately reporting security issues." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 12 (unordered list) +msgid "" +"Track [policy](../glossary.md#policy) issues in the codebase, so that a " +"relevant external policy expert can volunteer help." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 14 (unordered list) +msgid "" +"Track management issues in the codebase, so that external managers with " +"relevant experience can volunteer help." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 14 (unordered list) +msgid "" +"Support your experienced policy makers, developers and designers to keep " +"contributing to the codebase for as long as possible." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 16 (unordered list) +msgid "" +"Just like for [reviews](require-review-of-contributions.md), make sure to " +"respond to requests promptly." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 16 (unordered list) +msgid "" +"Keep your managers informed of the time and resources you require to support" +" other contributors." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 16 (unordered list) +msgid "" +"Make sure that appropriate communication channels for asking maintainers and" +" stakeholders questions are easy to locate, for instance in the README." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 16 (unordered list) +msgid "" +"Make sure that appropriate contact details are included in the metadata, for" +" instance in the publiccode.yml file." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 18 (unordered list) +msgid "" +"[How to inspire exceptional contributions to your open-source " +"project](https://dev.to/joelhans/how-to-inspire-exceptional-contributions-" +"to-your-open-source-project-1ebf) by Joel Hans." +msgstr "" + +#: ./criteria/make-contributing-easy.md:block 18 (unordered list) +msgid "" +"[The benefits of coding in the open](https://gds.blog.gov.uk/2017/09/04/the-" +"benefits-of-coding-in-the-open/) by the UK Government Digital Service." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 3 (paragraph) +msgid "order: 14 redirect_from:" +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 4 (unordered list) +msgid "criteria/findability" +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 5 (header) +msgid "Make the codebase findable" +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 6 (paragraph) +msgid "" +"The more findable a [codebase](../glossary.md#codebase) is, the more " +"potential new collaborators will find it. Just publishing a codebase and " +"hoping it is found does not work, instead proactiveness is needed." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 7 (paragraph) +msgid "" +"A metadata description file increases discoverability. Well-written metadata" +" containing a unique and persistent identifier, such as a Wikidata item or " +"FSF software directory listing (thus being part of the semantic web), makes " +"the codebase easier for people to refer, cite, disambiguate and discover " +"through third party tools." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The name of the codebase SHOULD be descriptive and free from acronyms, " +"abbreviations, puns or organizational branding." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD have a short description that helps someone understand " +"what the codebase is for or what it does." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "Maintainers SHOULD submit the codebase to relevant software catalogs." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD have a website which describes the problem the codebase " +"solves using the preferred jargon of different potential users of the " +"codebase (including technologists, policy experts and managers)." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD be findable using a search engine by codebase name." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD be findable using a search engine by describing the " +"problem it solves in natural language." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD have a unique and persistent identifier where the entry " +"mentions the major contributors, [repository](../glossary.md#repository) " +"location and website." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD include a machine-readable metadata description, for " +"example in a " +"[publiccode.yml](https://github.com/publiccodeyml/publiccode.yml) file." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "A dedicated domain name for the codebase is OPTIONAL." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "Regular presentations at conferences by the community are OPTIONAL." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "Check that the codebase name is descriptive and free of puns." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase name is free of acronyms and abbreviations or that " +"the acronyms or abbreviations in the name are more universally known than " +"the longer forms." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase name is free of organizational branding, unless that" +" organization is of the codebase community itself." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase repository has a short description of the codebase." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "Check for the codebase listing in relevant software catalogs." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check for a codebase website which describes the problem the codebase " +"solves." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase appears in the results on more than one major search" +" engine when searching by the codebase name." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase appears in the results on more than one major search" +" engine when searching by using natural language, for instance, using the " +"short description." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check unique and persistent identifier entries for mention of the major " +"contributors." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check unique and persistent identifier entries for the repository location." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check unique and persistent identifier entries for the codebase website." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "Check for a machine-readable metadata description file." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 13 (unordered list) +msgid "" +"Contribute a description of the policy area or problem this codebase acts on" +" or operates." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 13 (unordered list) +msgid "" +"Test your problem description with peers outside of your context who aren't " +"familiar with the codebase." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 13 (unordered list) +msgid "" +"Present on how the codebase implements the [policy](../glossary.md#policy) " +"at relevant conferences." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 15 (unordered list) +msgid "" +"Search trademark databases to avoid confusion or infringement before " +"deciding the name." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 15 (unordered list) +msgid "" +"Use the short description wherever the codebase is referenced, for instance," +" as social media account descriptions." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 15 (unordered list) +msgid "" +"Budget for content design and Search Engine Optimization skills in the team." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 15 (unordered list) +msgid "" +"Make sure people involved in the project present at relevant conferences." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 17 (unordered list) +msgid "" +"Search engine optimization, for instance adding a " +"[sitemap](https://www.sitemaps.org/protocol.html)." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 17 (unordered list) +msgid "" +"Use the short description wherever the codebase is referenced, for instance," +" as the repository description." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 17 (unordered list) +msgid "Suggest conferences to present at and present at them." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 19 (unordered list) +msgid "" +"[Introduction to " +"Wikidata](https://www.wikidata.org/wiki/Wikidata:Introduction) by the " +"Wikidata community." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 19 (unordered list) +msgid "" +"[FSF software directory listing](https://directory.fsf.org/wiki/Main_Page) " +"by the Free Software Foundation." +msgstr "" + +#: ./criteria/make-the-codebase-findable.md:block 19 (unordered list) +msgid "" +"The [FAIR Guiding Principles for scientific data management and " +"stewardship](https://www.go-fair.org/fair-principles/) by the GO FAIR " +"International Support and Coordination Office provide a nice list of " +"attributes that make (meta)data more machine actionable (and hence more " +"findable). Some of these apply directly to codebases, while others may " +"provoke exploration into what the codebase equivalent would be." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 3 (paragraph) +msgid "order: 3 redirect_from:" +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 4 (unordered +#: list) +msgid "criteria/reusable-and-portable-codebases" +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 4 (unordered +#: list) +msgid "criteria/create-reusable-and-portable-code" +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 5 (header) +msgid "Make the codebase reusable and portable" +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 6 (paragraph) +msgid "" +"Creating reusable and portable [code](../glossary.md#code) enables policy " +"makers, developers and designers to reuse what has been developed, test it, " +"improve it and contribute those improvements back, leading to better " +"quality, cheaper maintenance and higher reliability." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 7 (paragraph) +msgid "" +"Thoughtfully and purposefully designing a " +"[codebase](../glossary.md#codebase) for reusability allows for the mission, " +"vision and scope of the codebase to be shared by multiple parties. Codebases" +" developed and used by multiple parties are more likely to benefit from a " +"self-sustaining community." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 8 (paragraph) +msgid "" +"Organizing a codebase such that it is composed of well documented modules " +"improves reusability and maintainability. A module is easier to reuse in " +"[another context](../glossary.md#different-contexts) if its purpose is " +"clearly documented." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 9 (paragraph) +msgid "" +"Source code which does not rely on the situation-specific infrastructure of " +"any contributor, vendor or deployment can be tested by any other " +"contributor." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "The codebase MUST be developed to be reusable in different contexts." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"The codebase MUST be independent from any secret, undisclosed, proprietary " +"or non-open licensed software or services for execution and understanding." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "The codebase SHOULD be in use by multiple parties." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "The roadmap SHOULD be influenced by the needs of multiple parties." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"The development of the codebase SHOULD be a collaboration between multiple " +"parties." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"Configuration SHOULD be used to make [source code](../glossary.md#source-" +"code) adapt to context specific needs." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "The codebase SHOULD be localizable." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"Source code and its documentation SHOULD NOT contain situation-specific " +"information." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"Codebase modules SHOULD be documented in such a way as to enable reuse in " +"codebases in other contexts." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"The software SHOULD NOT require services or platforms available from only a " +"single vendor." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Confirm with someone in a similar role at another organization if they can " +"use the codebase and what that would entail." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Confirm that the codebase can run without using any proprietary or non open-" +"licensed software or services." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"If the codebase is in early development before a production-ready release, " +"then check for evidence of ambition to obtain collaborators." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Or if the codebase is very mature and stable with very infrequent fixes, " +"patches, or contributions:" +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Check that the codebase is in use by multiple parties or in multiple " +"contexts." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "Check for documented and budgeted commitments of collaboration." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "Otherwise:" +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "Check that the codebase contributors are from multiple parties." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Check that the codebase files and commit history do not include situation-" +"specific data." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Check that the software can be deployed and run without services or " +"platforms available from a single vendor." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 15 (unordered +#: list) +msgid "" +"Document your [policy](../glossary.md#policy) with enough clarity and detail" +" that it can be understood outside of its original context." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 15 (unordered +#: list) +msgid "Make sure your organization is listed as a known user by the codebase." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 15 (unordered +#: list) +msgid "Identify other organizations for your teams to collaborate with." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 17 (unordered +#: list) +msgid "" +"Make sure that stakeholders and business owners understand that reusability " +"is an explicit codebase goal as this reduces technical debt and provides " +"sustainability for the codebase." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 17 (unordered +#: list) +msgid "Make sure that your teams are collaborating with other teams." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 19 (paragraph) +msgid "Source should be designed:" +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 20 (unordered +#: list) +msgid "for reuse by other users and organizations regardless of locale," +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 20 (unordered +#: list) +msgid "to solve a general problem instead of a specific one," +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 20 (unordered +#: list) +msgid "in logically meaningful and isolated modules," +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 20 (unordered +#: list) +msgid "" +"so that someone in a similar organization facing a similar problem would be " +"able to use (parts of) the solution." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 21 (paragraph) +msgid "" +"Make sure that the codebase documentation describes the build-time and " +"runtime dependencies. If your context requires deploying to proprietary " +"platforms or using proprietary components, make sure that collaborators can " +"develop, use, test, and deploy without them." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 22 (paragraph) +msgid "" +"For each commit, reviewers verify that content does not include situation-" +"specific data such as hostnames, personal and organizational data, or tokens" +" and passwords." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 24 (unordered +#: list) +msgid "" +"[Making source code open and reusable](https://www.gov.uk/service-" +"manual/technology/making-source-code-open-and-reusable) by the UK Government" +" Digital Service." +msgstr "" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 24 (unordered +#: list) +msgid "" +"[Localization vs. " +"Internationalization](https://www.w3.org/International/questions/qa-i18n) by" +" the World Wide Web Consortium." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 3 (paragraph) +msgid "order: 13 redirect_from:" +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 4 (unordered list) +msgid "criteria/open-licenses" +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 5 (header) +msgid "Publish with an open license" +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 6 (paragraph) +msgid "" +"An open and well known license makes it possible for anyone to see the " +"[source code](../glossary.md#source-code) in order to understand how it " +"works, to use it freely and to contribute to the " +"[codebase](../glossary.md#codebase). This enables a vendor ecosystem to " +"emerge around the codebase." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 7 (paragraph) +msgid "" +"Clearly indicating the license for each file within a codebase facilitates " +"correct reuse and attribution of parts of a codebase." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"All source code and documentation MUST be licensed such that it may be " +"freely reusable, changeable and redistributable." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"Software source code MUST be licensed under an [OSI-approved or FSF " +"Free/Libre license](https://spdx.org/licenses/)." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "All source code MUST be published with a license file." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"Contributors MUST NOT be required to transfer copyright of their " +"contributions to the codebase." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"All source code files in the codebase SHOULD include a copyright notice and " +"a license header that are machine-readable." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"Having multiple licenses for different types of source code and " +"documentation is OPTIONAL." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "Confirm that the codebase is clearly licensed." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "" +"Confirm that the license for the source code is on the [OSI-approved or FSF " +"Free/Libre license list](https://spdx.org/licenses/) and the license for " +"documentation [conforms to the Open " +"Definition](https://opendefinition.org/licenses/)." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "Confirm that the licenses used in the codebase are included as files." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "" +"Confirm that contribution guidelines and " +"[repository](../glossary.md#repository) configuration do not require " +"transfer of copyright." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "" +"Check for machine-readable license checking in the codebase [continuous " +"integration](../glossary.md#continuous-integration) tests." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 13 (unordered list) +msgid "" +"Develop [policy](../glossary.md#policy) that requires source code to be " +"[open source](../glossary.md#open-source)." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 13 (unordered list) +msgid "" +"Develop policy that disincentivizes non-open source code and technology in " +"procurement." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 15 (unordered list) +msgid "" +"Only work with open source vendors that deliver their source code by " +"publishing it under an open source license." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 15 (unordered list) +msgid "" +"Beware that even though [Creative Commons " +"licenses](https://creativecommons.org/licenses/) are great for " +"documentation, licenses that stipulate Non-Commercial or No Derivatives are " +"NOT freely reusable, changeable and redistributable and don't fulfill these " +"requirements." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 17 (unordered list) +msgid "Add a new `license` file to every new codebase created." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 17 (unordered list) +msgid "" +"Add a copyright notice and a license header to every new source code file " +"created." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 17 (unordered list) +msgid "" +"When source code is being reused by the codebase, make sure that it has a " +"license that is compatible with the license or licenses of the codebase." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 19 (unordered list) +msgid "" +"[Open source definition](https://opensource.org/osd) by the Open Source " +"Initiative, all open source licenses meet this definition." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 19 (unordered list) +msgid "" +"[Animated video introduction to Creative " +"Commons](https://creativecommons.org/about/videos/creative-commons-kiwi) by " +"Creative Commons Aotearoa New Zealand." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 19 (unordered list) +msgid "" +"[REUSE Initiative specification](https://reuse.software/spec/) by Free " +"Software Foundation Europe for unambiguous, human-readable and machine-" +"readable copyright and licensing information." +msgstr "" + +#: ./criteria/publish-with-an-open-license.md:block 19 (unordered list) +msgid "" +"[SPDX License List](https://spdx.org/licenses/) by the Linux Foundation with" +" standardized, machine-readable abbreviations for most licenses." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 3 (paragraph) +msgid "order: 7 redirect_from:" +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 4 (unordered list) +msgid "criteria/require-review" +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 5 (header) +msgid "Require review of contributions" +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 6 (paragraph) +msgid "" +"Peer-review of contributions is essential for [source " +"code](../glossary.md#source-code) quality, reducing security risks and " +"operational risks." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 7 (paragraph) +msgid "" +"Requiring thorough review of contributions encourages a culture of making " +"sure every contribution is of high quality, completeness and value. Source " +"code review increases the chance of discovering and fixing potential bugs or" +" mistakes before they are added to the [codebase](../glossary.md#codebase). " +"Knowing that all source code was reviewed discourages a culture of blaming " +"individuals, and encourages a culture of focusing on solutions." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 8 (paragraph) +msgid "" +"A [policy](../glossary.md#policy) of prompt reviews assures contributors of " +"a guaranteed time for feedback or collaborative improvement, which increases" +" both rate of delivery and contributor engagement." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"All contributions that are accepted or committed to release versions of the " +"codebase MUST be reviewed by another contributor." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "Reviews MUST include source, policy, tests and documentation." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"Reviewers MUST provide feedback on all decisions to not accept a " +"contribution." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"The review process SHOULD confirm that a contribution conforms to the " +"standards, architecture and decisions set out in the codebase in order to " +"pass review." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"Reviews SHOULD include running both the software and the tests of the " +"codebase." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"Contributions SHOULD be reviewed by someone in a different context than the " +"contributor." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"Version control systems SHOULD NOT accept non-reviewed contributions in " +"release versions." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "Reviews SHOULD happen within two business days." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "Performing reviews by multiple reviewers is OPTIONAL." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "" +"Confirm that every commit in the history has been reviewed by a different " +"contributor." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "Confirm that reviews include source, policy, tests and documentation." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "Confirm that rejected contributions were appropriately explained." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "" +"Check if guidelines for reviewers include instructions to review for " +"conformance to standards, architecture and codebase guidelines." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "Check with reviewers if they run the software and tests during review." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "" +"Check with reviewers if commits have been reviewed by a different " +"contributor in a different context." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "" +"Check for use of branch protection in the [version " +"control](../glossary.md#version-control) system." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "Check the times between contribution submission and review." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 14 (unordered list) +msgid "" +"Institute a 'four eyes' policy where everything, not just source code, is " +"reviewed." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 14 (unordered list) +msgid "" +"Use a version control system or methodology that enables review and " +"feedback." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 16 (unordered list) +msgid "Make delivering great software a shared objective." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 16 (unordered list) +msgid "" +"Make sure writing and reviewing contributions to source, policy, " +"documentation and tests are considered equally valuable." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 16 (unordered list) +msgid "" +"Create a culture where all contributions are welcome and everyone is " +"empowered to review them." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 16 (unordered list) +msgid "Make sure no contributor is ever alone in contributing to a codebase." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 18 (unordered list) +msgid "" +"Ask other contributors on the codebase to review your work, in your " +"organization or outside of it." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 18 (unordered list) +msgid "" +"Try to respond to others' requests for review promptly, initially providing " +"feedback about the concept of the change." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 20 (unordered list) +msgid "" +"[How to review code the GDS way](https://gds-" +"way.cloudapps.digital/manuals/code-review-guidelines.html#content) by the UK" +" Government Digital Service." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 20 (unordered list) +msgid "" +"Branch protection on " +"[GitHub](https://docs.github.com/en/repositories/configuring-branches-and-" +"merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-" +"protected-branches) and " +"[GitLab](https://about.gitlab.com/blog/2014/11/26/keeping-your-code-" +"protected/)." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 20 (unordered list) +msgid "" +"[The Gentle Art of Patch Review](https://sage.thesharps.us/2014/09/01/the-" +"gentle-art-of-patch-review/) by Sage Sharp." +msgstr "" + +#: ./criteria/require-review-of-contributions.md:block 20 (unordered list) +msgid "" +"[Measuring " +"Engagement](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-" +"mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) by Mozilla." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 3 (paragraph) +msgid "order: 15 redirect_from:" +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 4 (unordered list) +msgid "criteria/style" +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 5 (header) +msgid "Use a coherent style" +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 6 (paragraph) +msgid "" +"Following a consistent and coherent style enables contributors in different " +"environments to work together. Unifying vocabularies reduces friction in " +"communication between contributors." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 8 (unordered list) +msgid "" +"The [codebase](../glossary.md#codebase) MUST use a coding or writing style " +"guide, either the codebase community's own or an existing one referred to in" +" the codebase." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 8 (unordered list) +msgid "Contributions SHOULD pass automated tests on style." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 8 (unordered list) +msgid "" +"The style guide SHOULD include expectations for inline comments and " +"documentation for non-trivial sections." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 8 (unordered list) +msgid "" +"Including expectations for [understandable English](use-plain-english.md) in" +" the style guide is OPTIONAL." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 10 (unordered list) +msgid "" +"Confirm that contributions are in line with the style guides specified in " +"the documentation." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 10 (unordered list) +msgid "Check for the presence of automated tests on style." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 12 (unordered list) +msgid "" +"Create, follow and continually improve on a style guide for " +"[policy](../glossary.md#policy) and documentation as well as document this " +"in the codebase, for example in the `CONTRIBUTING` or `README`." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 14 (unordered list) +msgid "" +"Include written language, source, test and policy standards in your " +"organizational definition of quality." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 16 (paragraph) +msgid "" +"If the codebase does not already have engineering guidelines or other " +"contributor guidance, start by adding documentation to the " +"[repository](../glossary.md#repository) describing whatever is being done " +"now, for example in the `CONTRIBUTING` or `README`. An important purpose of " +"the file is to communicate design preferences, naming conventions, and other" +" aspects machines can't easily check. Guidance should include what would be " +"expected from [source code](../glossary.md#source-code) contributions in " +"order for them to be merged by the maintainers, including source, tests and " +"documentation. Continually improve upon and expand this documentation with " +"the aim of evolving this documentation into engineering guidelines." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 17 (paragraph) +msgid "Additionally:" +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 18 (unordered list) +msgid "Use a linter." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 18 (unordered list) +msgid "Add linter configurations to the codebase." +msgstr "" + +#: ./criteria/use-a-coherent-style.md:block 20 (unordered list) +msgid "" +"[Programming style](https://en.wikipedia.org/wiki/Programming_style) on " +"Wikipedia." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 3 (paragraph) +msgid "order: 12 redirect_from:" +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 4 (unordered list) +msgid "criteria/continuous-integration" +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 5 (header) +msgid "Use continuous integration" +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 6 (paragraph) +msgid "" +"Asynchronous collaboration is enabled by developers merging their work to a " +"shared branch frequently, verified by automated tests. The more frequent the" +" merging and the smaller the contribution, the easier it is to resolve merge" +" conflicts." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 7 (paragraph) +msgid "" +"Automated testing of all functionality provides confidence that " +"contributions are working as intended and have not introduced errors, and " +"allows reviewers to focus on the structure and approach of the contribution." +" The more focused the test, the easier it is to clearly identify and " +"understand errors as they arise." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 8 (paragraph) +msgid "" +"Documenting a codebase's [continuous integration](../glossary.md#continuous-" +"integration) workflow helps contributors understand the expectations of " +"contributions. Continuous integration allows for an easier monitoring of the" +" state of the [codebase](../glossary.md#codebase)." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"All functionality in the [source code](../glossary.md#source-code) MUST have" +" automated tests." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"Contributions MUST pass all automated tests before they are admitted into " +"the codebase." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"The codebase MUST have guidelines explaining how to structure contributions." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"The codebase MUST have active contributors who can review contributions." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "Automated test results for contributions SHOULD be public." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"The codebase guidelines SHOULD state that each contribution should focus on " +"a single issue." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "Source code test and documentation coverage SHOULD be monitored." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"Testing [policy](../glossary.md#policy) and documentation for consistency " +"with the source and vice versa is OPTIONAL." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"Testing policy and documentation for style and broken links is OPTIONAL." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"Testing the software by using examples in the documentation is OPTIONAL." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "Confirm that there are tests present." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "" +"Confirm that source code coverage tools check that coverage is at 100% of " +"the source code." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "" +"Confirm that contributions are only admitted into the codebase after all of " +"the tests are passed." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "" +"Confirm that contribution guidelines explain how to structure contributions." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "" +"Confirm that there are contributions from within the last three months." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "Check that test results are viewable." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "Check if source code coverage data is published." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 14 (unordered list) +msgid "" +"Involve managers as well as developers and designers as early in the process" +" as possible and keep them engaged throughout development of your policy." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 14 (unordered list) +msgid "" +"Make sure there are also automated tests set up for policy documentation." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 14 (unordered list) +msgid "Fix policy documentation promptly if it fails a test." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 14 (unordered list) +msgid "" +"Make sure the source code reflects any changes to the policy (see [Maintain " +"version control](maintain-version-control.md))." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 16 (unordered list) +msgid "" +"Make sure to test with real end users as quickly and often as possible." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 16 (unordered list) +msgid "" +"Plan the work to integrate small parts very often instead of large parts " +"less frequently." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 16 (unordered list) +msgid "" +"Procure consultancy services that deliver incrementally aligned with the " +"plan." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 16 (unordered list) +msgid "" +"After a large failure, encourage publication of incident reports and public " +"discussion of what was learned." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Help managers structure the work plan such that it can be integrated as " +"small increments." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Help contributors limit the scope of their contributions and feature " +"requests to be as small as reasonable." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Help managers and policy makers test their contributions, for example by " +"testing their contributions for broken links or style." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Structure source code written to handle conditions which are difficult to " +"create in a test environment in such a way that the conditions can be " +"simulated during testing. Forms of resource exhaustion such as running out " +"of storage space and memory allocation failure are typical examples of " +"difficult to create conditions." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Tune the test code coverage tools to avoid false alarms resulting from " +"inlining or other optimizations." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "Deploy often." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "Integrate your work at least once a day." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 20 (unordered list) +msgid "" +"[What is continuous " +"integration](https://www.martinfowler.com/articles/continuousIntegration.html)" +" by Martin Fowler." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 20 (unordered list) +msgid "" +"[Use continuous delivery](https://gds-" +"way.cloudapps.digital/standards/continuous-delivery.html) by the UK " +"Government Digital Service." +msgstr "" + +#: ./criteria/use-continuous-integration.md:block 20 (unordered list) +msgid "" +"[Quality assurance: testing your service " +"regularly](https://www.gov.uk/service-manual/technology/quality-assurance-" +"testing-your-service-regularly) by the UK Government Digital Service." +msgstr "" + +#: ./criteria/use-open-standards.md:block 3 (paragraph) +msgid "order: 11 redirect_from:" +msgstr "" + +#: ./criteria/use-open-standards.md:block 4 (unordered list) +msgid "criteria/open-standards" +msgstr "" + +#: ./criteria/use-open-standards.md:block 5 (header) +msgid "Use open standards" +msgstr "" + +#: ./criteria/use-open-standards.md:block 6 (paragraph) +msgid "" +"[Open standards](../glossary.md#open-standard) guarantee access to the " +"knowledge required to use and contribute to the " +"[codebase](../glossary.md#codebase). They enable interoperability between " +"systems and reduce the risk of vendor lock-in. Open standards which are " +"unambiguous allow for independent development of either side of data " +"exchange." +msgstr "" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"For features of the codebase that facilitate the exchange of data the " +"codebase MUST use an open standard that meets the [Open Source Initiative " +"Open Standard Requirements](https://opensource.org/osr)." +msgstr "" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Any non-open standards used MUST be recorded clearly as such in the " +"documentation." +msgstr "" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Any standard chosen for use within the codebase MUST be listed in the " +"documentation with a link to where it is available." +msgstr "" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Any non-open standards chosen for use within the codebase MUST NOT hinder " +"collaboration and reuse." +msgstr "" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"If no existing open standard is available, effort SHOULD be put into " +"developing one." +msgstr "" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Open standards that are machine testable SHOULD be preferred over open " +"standards that are not." +msgstr "" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Non-open standards that are machine testable SHOULD be preferred over non-" +"open standards that are not." +msgstr "" + +#: ./criteria/use-open-standards.md:block 10 (unordered list) +msgid "Confirm that data exchange follows an OSI approved open standard." +msgstr "" + +#: ./criteria/use-open-standards.md:block 10 (unordered list) +msgid "" +"Confirm that any non-open standards used are clearly documented as such." +msgstr "" + +#: ./criteria/use-open-standards.md:block 10 (unordered list) +msgid "" +"Confirm that documentation includes a list of the standards followed within " +"the codebase, each with a working link, or a statement that no standards " +"were chosen." +msgstr "" + +#: ./criteria/use-open-standards.md:block 12 (unordered list) +msgid "Mandate use of open standards everywhere possible." +msgstr "" + +#: ./criteria/use-open-standards.md:block 12 (unordered list) +msgid "Prohibit procurement of technology that does not use open standards." +msgstr "" + +#: ./criteria/use-open-standards.md:block 14 (unordered list) +msgid "" +"Consider including open standard compliance assessment in [source " +"code](../glossary.md#source-code) reviews." +msgstr "" + +#: ./criteria/use-open-standards.md:block 16 (unordered list) +msgid "" +"Add [continuous integration](../glossary.md#continuous-integration) tests " +"for compliance with the standards." +msgstr "" + +#: ./criteria/use-open-standards.md:block 16 (unordered list) +msgid "" +"Review the commits and other [repository](../glossary.md#repository) " +"resources for references to standards and cross-check those with the " +"standards listed." +msgstr "" + +#: ./criteria/use-open-standards.md:block 18 (unordered list) +msgid "" +"[Open Standards principles](https://www.gov.uk/government/publications/open-" +"standards-principles/open-standards-principles), " +"[policy](../glossary.md#policy) paper of the UK Cabinet Office." +msgstr "" + +#: ./criteria/use-plain-english.md:block 3 (paragraph) +msgid "order: 10 redirect_from:" +msgstr "" + +#: ./criteria/use-plain-english.md:block 4 (unordered list) +msgid "criteria/understandable-english-first" +msgstr "" + +#: ./criteria/use-plain-english.md:block 5 (header) +msgid "Use plain English" +msgstr "" + +#: ./criteria/use-plain-english.md:block 6 (paragraph) +msgid "" +"English is the de facto language of collaboration in software " +"development." +msgstr "" + +#: ./criteria/use-plain-english.md:block 7 (paragraph) +msgid "" +"Public sector information needs to be accessible to all its constituents. " +"Plain and simple language makes the [code](../glossary.md#code) and what it " +"does easier to understand for a wider variety of people." +msgstr "" + +#: ./criteria/use-plain-english.md:block 8 (paragraph) +msgid "" +"Translations further increase the possible reach of a " +"[codebase](../glossary.md#codebase). Language that is easy to understand " +"lowers the cost of creating and maintaining translations." +msgstr "" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "All codebase documentation MUST be in English." +msgstr "" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"All [source code](../glossary.md#source-code) MUST be in English, except " +"where [policy](../glossary.md#policy) is machine interpreted as code." +msgstr "" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"All bundled policy not available in English MUST have an accompanying " +"summary in English." +msgstr "" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"Any translation MUST be up to date with the English version and vice versa." +msgstr "" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"There SHOULD be no acronyms, abbreviations, puns or legal/non-English/domain" +" specific terms in the codebase without an explanation preceding it or a " +"link to an explanation." +msgstr "" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"Documentation SHOULD aim for a lower secondary education reading level, as " +"recommended by the [Web Content Accessibility Guidelines " +"2](https://www.w3.org/WAI/WCAG21/quickref/?showtechniques=315#readable)." +msgstr "" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"Providing a translation of any code, documentation or tests is OPTIONAL." +msgstr "" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "Confirm that codebase documentation is available in English." +msgstr "" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "" +"Confirm that source code is in English, or confirm any non-English is policy" +" or terms with preceding explanations." +msgstr "" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "Confirm any non-English policy has an accompanying summary in English." +msgstr "" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "" +"Confirm that translations and the English version have the same content." +msgstr "" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "" +"Check that no unexplained acronyms, abbreviations, puns or legal/non-" +"English/domain specific terms are in the documentation." +msgstr "" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "Check the spelling, grammar and readability of the documentation." +msgstr "" + +#: ./criteria/use-plain-english.md:block 14 (unordered list) +msgid "" +"Frequently test with other managers, developers and designers in the process" +" if they understand what you are delivering and how you document it." +msgstr "" + +#: ./criteria/use-plain-english.md:block 16 (unordered list) +msgid "" +"Try to limit the use of acronyms, abbreviations, puns or legal/non-" +"English/domain specific terms in internal communications in and between " +"teams and stakeholders. Add any such terms to a glossary and link to it from" +" the places they are being used." +msgstr "" + +#: ./criteria/use-plain-english.md:block 16 (unordered list) +msgid "" +"Be critical of documentation and descriptions in proposals and changes. If " +"you don't understand something, others will probably also struggle with it." +msgstr "" + +#: ./criteria/use-plain-english.md:block 18 (unordered list) +msgid "" +"Frequently test with policy makers and managers if they understand what you " +"are delivering and how you document it." +msgstr "" + +#: ./criteria/use-plain-english.md:block 18 (unordered list) +msgid "" +"Ask someone outside of your context if they understand the content (for " +"example, a developer working on a different codebase)." +msgstr "" + +#: ./criteria/use-plain-english.md:block 20 (unordered list) +msgid "" +"Meeting the [Web Content Accessibility Guidelines 2.1, Guideline 3.1 " +"Readable](https://www.w3.org/TR/WCAG21/#readable) by W3C makes text content " +"readable and understandable." +msgstr "" + +#: ./criteria/use-plain-english.md:block 20 (unordered list) +msgid "" +"The[European Union accessibility directive](https://ec.europa.eu/digital-" +"single-market/en/web-accessibility) by the European Commission, is an " +"example of regulation requiring high accessibility." +msgstr "" + +#: ./criteria/use-plain-english.md:block 20 (unordered list) +msgid "" +"[Definition of plain " +"language](https://www.plainlanguage.gov/about/definitions/) by United States" +" General Services Administration." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 3 (paragraph) +msgid "order: 4 redirect_from:" +msgstr "" + +#: ./criteria/welcome-contributors.md:block 4 (unordered list) +msgid "criteria/open-to-contributions" +msgstr "" + +#: ./criteria/welcome-contributors.md:block 5 (header) +msgid "Welcome contributors" +msgstr "" + +#: ./criteria/welcome-contributors.md:block 6 (paragraph) +msgid "" +"The atmosphere in a [codebase](../glossary.md#codebase) community helps " +"users decide to use one codebase over another. Welcoming anyone as a " +"contributor enables the community to grow and sustain itself over time. A " +"community where contributors have clear ways to influence codebase and " +"community goals and progress is less likely to split and end up in diverging" +" communities. Newcomers need to understand and trust the codebase " +"community’s governance." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The codebase MUST allow anyone to submit suggestions for changes to the " +"codebase." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The codebase MUST include contribution guidelines explaining what kinds of " +"contributions are welcome and how contributors can get involved, for example" +" in a `CONTRIBUTING` file." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The codebase MUST document the governance of the codebase, contributions and" +" its community, for example in a `GOVERNANCE` file." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The contribution guidelines SHOULD document who is expected to cover the " +"costs of reviewing contributions." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The codebase SHOULD advertise the committed engagement of involved " +"organizations in the development and maintenance." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "The codebase SHOULD have a publicly available roadmap." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "The codebase SHOULD publish codebase activity statistics." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"Including a code of conduct for contributors in the codebase is OPTIONAL." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "" +"Confirm that it is possible to submit suggestions for changes to the " +"codebase." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Confirm there are contribution guidelines." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "" +"Confirm that the codebase governance is clearly explained, including how to " +"influence codebase governance." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "" +"Check that contributing guidelines cover who is expected to cover the costs " +"of reviewing contributions." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Check for a list of involved organizations." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Check for a roadmap." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Check for published activity statistics." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Check for a code of conduct." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 12 (unordered list) +msgid "" +"Add a list to the codebase of any other resources that " +"[policy](../glossary.md#policy) experts, non-governmental organizations and " +"academics would find useful for understanding or reusing your policy." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 12 (unordered list) +msgid "" +"Consider adding contact details so that other policy makers considering " +"collaboration can ask you for advice." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"Make sure that the documentation of the governance includes the current " +"process for how to make changes to the governance." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"If the community has some consensus about how the governance should change, " +"then include those ideas stated as ambitions in the documentation." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"If needed, make sure you have allocated budget for the contributions review " +"process as agreed by the codebase community." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"Make sure the documentation explains how each organization is involved in " +"the codebase, what resources it has available for it and for how long." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"Support your experienced policy makers, developers and designers to stay " +"part of the community for as long as possible." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 16 (unordered list) +msgid "Respond promptly to requests." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 16 (unordered list) +msgid "" +"Communicate clearly to contributors what they need to do make sure their " +"contribution can be integrated." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 18 (unordered list) +msgid "" +"[Building welcoming communities](https://opensource.guide/building-" +"community/) by Open Source Guides." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 18 (unordered list) +msgid "" +"[The Open Source Contributor Funnel](https://mikemcquaid.com/2018/08/14/the-" +"open-source-contributor-funnel-why-people-dont-contribute-to-your-open-" +"source-project/) by Mike McQuaid." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 18 (unordered list) +msgid "" +"[Leadership and governance](https://opensource.guide/leadership-and-" +"governance/) for growing [open source](../glossary.md#open-source) community" +" projects, by Open Source Guides." +msgstr "" + +#: ./criteria/welcome-contributors.md:block 18 (unordered list) +msgid "" +"[Building online communities](http://hintjens.com/blog:117) by Pieter " +"Hintjens (long read!)." +msgstr "" + +#: ./docs/printing.md:block 1 (header) +msgid "Printing" +msgstr "" + +#: ./docs/printing.md:block 3 (paragraph) +msgid "" +"The printed Standard for Public Code is printed by Reclameland. This guide " +"tries to provide the relevant information to print it there or somewhere " +"else." +msgstr "" + +#: ./docs/printing.md:block 4 (paragraph) +msgid "" +"Details, mostly in order they are on the Reclameland page with the Dutch if " +"necessary:" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "" +"Form: Softcover book ([Reclameland product " +"page](https://www.reclameland.nl/drukken/softcover-boeken))" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Format: A4" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Portrait or landscape: Portrait (Staand)" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Printing inside: 4/4 dual sided full color" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Inside material: 90 grams biotop" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Cover: 350 grams cover" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Printing cover: 4/0 one sided full cover" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Cover treatment: one sided matt foliated (Enke)" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "" +"Pages: pages of the inside + 4 + x, where x is 0-3 so that the sum becomes a" +" multiple of 4" +msgstr "" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Individually sealed: no" +msgstr "" + +#: ./docs/printing.md:block 6 (paragraph) +msgid "" +"When these details are chosen, the cover and insides are uploaded and the " +"order is placed payment can happen (payment ahead) after which printing " +"starts." +msgstr "" + +#: ./docs/releasing.md:block 1 (header) +msgid "Releasing a new version of the Standard for public code" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Review state of the 'develop' branch" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Ensure all changes intended for release are merged" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Invite a proofread of the current state of the branch" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"If new dashes are introduced, check if the language can be simplified to " +"remove them in favor of more simple sentences. If a complex sentence is " +"needed, see if the dash can be replaced with other punctuation. If a dash is" +" truly the best expression of ideas, then follow the [Chicago Manual of " +"Style](https://en.wikipedia.org/wiki/Dash#En_dash_versus_em_dash)." +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Create a release branch" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "From 'develop', `git switch -c \"release-$MAJOR.$MINOR.$PATCH\"`" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Push the branch, `git push -u origin release-$MAJOR.$MINOR.$PATCH`" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update the new release" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update [`AUTHORS.md`](../AUTHORS.md) with new contributors" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update [`CHANGELOG.md`](../CHANGELOG.md)" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update [`roadmap.md`](roadmap.md)" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Perform extra pass on diff to the 'main' branch" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"run `script/generate-review-template.sh` and commit updated `docs/review-" +"template.html`" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"update `docs/standard-for-public-code.html` with the new text from the " +"review template, updating any status changes as a result" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Reread any section or paragraph to ensure wording changes still fit the " +"whole and do not contain grammar or spelling errors" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Ensure [fonts](https://brand.publiccode.net/typography/) are installed, see:" +" `script/ensure-font.sh`" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Check the rendered `.pdf` using `script/pdf.sh rc1`" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Ensure no link collisions exist" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Check the page breaks, possibly removing or adding page-break CSS, for " +"example: `

`" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "If needed, commit fixes and repeat extra pass" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Push branch, compare with 'main' branch, i.e.: " +"`https://github.com/publiccodenet/standard/compare/main...release-$MAJOR.$MINOR.$PATCH`" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Request review from multiple reviewers, especially a proofreader" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Reviewers will create issues for shortcomings found which would not prevent " +"release" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"If needed for release, reviewers may create pull requests to resolve issues" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Re-request reviews if additional pull requests are merged into release " +"branch" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Run the to-archive-org.sh script" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Create GitHub release with the release notes and version number" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "`git tag trigger-$MAJOR.$MINOR.$PATCH`" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "`git push --tags` (see: `../.github/workflows/release-on-tag.yml`)" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "delete local tag: `git tag -d trigger-$MAJOR.$MINOR.$PATCH`" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "[Send the files for print to the printer](printing.md)" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Cover file" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Inside pages PDF" +msgstr "" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Ping [translation](https://github.com/publiccodenet/community-translations-" +"standard) contributors" +msgstr "" + +#: ./docs/roadmap.md:block 1 (header) +msgid "Roadmap" +msgstr "" + +#: ./docs/roadmap.md:block 3 (paragraph) +msgid "Last updated: 2023-03-08" +msgstr "" + +#: ./docs/roadmap.md:block 4 (paragraph) +msgid "" +"This document intends to shed light on the current development plans of the " +"team. Plans change constantly as new information is absorbed by the team." +msgstr "" + +#: ./docs/roadmap.md:block 5 (paragraph) +msgid "" +"Codebase stewards review the roadmap monthly as part of our [backlog pruning" +" session](https://about.publiccode.net/activities/standard-" +"maintenance/backlog-pruning.html)." +msgstr "" + +#: ./docs/roadmap.md:block 6 (header) +msgid "Current work" +msgstr "" + +#: ./docs/roadmap.md:block 7 (unordered list) +msgid "As far as possible, make the standard Standard-compliant" +msgstr "" + +#: ./docs/roadmap.md:block 7 (unordered list) +msgid "Certification badges" +msgstr "" + +#: ./docs/roadmap.md:block 8 (header) +msgid "Near term" +msgstr "" + +#: ./docs/roadmap.md:block 9 (unordered list) +msgid "Separate executive summary (issue #302)" +msgstr "" + +#: ./docs/roadmap.md:block 9 (unordered list) +msgid "Physical paper checklist" +msgstr "" + +#: ./docs/roadmap.md:block 9 (unordered list) +msgid "Possibly: add in the illustrations for each criterion" +msgstr "" + +#: ./docs/roadmap.md:block 10 (header) +msgid "Longer term" +msgstr "" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "" +"Add to README and index.md information (and eventually statistics) on " +"adoption and use (issue #438)" +msgstr "" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Becoming validated by multiple codebases" +msgstr "" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Release version 1.0.0 after a few codebases are compliant" +msgstr "" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Linkable requirements" +msgstr "" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "New cover art" +msgstr "" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Register for ISBN" +msgstr "" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "List with an on-demand book printing service" +msgstr "" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "QR codes for external links in print version" +msgstr "" + +#: ./foreword.md:block 3 (paragraph) +msgid "redirect_from:" +msgstr "" + +#: ./foreword.md:block 4 (unordered list) +msgid "introduction" +msgstr "" + +#: ./foreword.md:block 5 (header) +msgid "Foreword" +msgstr "" + +#: ./foreword.md:block 6 (paragraph) +msgid "" +"The Standard for Public Code is a set of criteria that support public " +"organizations in developing and maintaining software and policy together." +msgstr "" + +#: ./foreword.md:block 7 (paragraph) +msgid "" +"Anyone developing public-purpose software or policy can use this standard to" +" work towards higher quality public services that are more cost effective, " +"with less risk and more control." +msgstr "" + +#: ./foreword.md:block 8 (paragraph) +msgid "" +"This foreword introduces the term public code and explains why this is " +"important." +msgstr "" + +#: ./foreword.md:block 9 (header) +msgid "Definition of public code" +msgstr "" + +#: ./foreword.md:block 10 (paragraph) +msgid "" +"Public code is both computer source code (such as software and algorithms) " +"and public policy executed in a public context, by humans or machines. It " +"encompasses the software built to operate with and as public infrastructure," +" along with the arrangements for its production. Public code is explicitly " +"distinct from regular software because it operates under fundamentally " +"different circumstances and expectations." +msgstr "" + +#: ./foreword.md:block 11 (header) +msgid "Reasons for public code" +msgstr "" + +#: ./foreword.md:block 12 (paragraph) +msgid "There are many reasons for why public code is relevant now." +msgstr "" + +#: ./foreword.md:block 13 (header) +msgid "Software code == legal code" +msgstr "" + +#: ./foreword.md:block 14 (paragraph) +msgid "Software is public infrastructure." +msgstr "" + +#: ./foreword.md:block 15 (paragraph) +msgid "" +"In the 21st century, software can be considered vital public infrastructure." +" It is increasingly not just the expression of existing policy but the " +"originator of new policy, for example where algorithms decide which " +"districts need extra social services or policing." +msgstr "" + +#: ./foreword.md:block 16 (paragraph) +msgid "" +"Software mechanics, algorithms and data collection have become key elements " +"in the execution of public policies. Computer code now executes policies " +"that have been codified in legal code through democratic procedures. Both " +"forms of code set conditions for society to function according to " +"democratically set public values, the latter executed by humans, the former " +"by machines. In other words, software code has increasingly started to equal" +" legal code." +msgstr "" + +#: ./foreword.md:block 17 (paragraph) +msgid "" +"Software should therefore be subject to the principles of democratic " +"governance." +msgstr "" + +#: ./foreword.md:block 18 (header) +msgid "Traditional public software procurement" +msgstr "" + +#: ./foreword.md:block 19 (paragraph) +msgid "" +"Current public software production methods have not served public service " +"delivery very well." +msgstr "" + +#: ./foreword.md:block 20 (paragraph) +msgid "" +"In the last decade, public organizations that purchased complete software " +"solutions have sometimes been surprised to discover that they:" +msgstr "" + +#: ./foreword.md:block 21 (unordered list) +msgid "" +"can’t change their software to reflect changing policy or take advantage of " +"new technology" +msgstr "" + +#: ./foreword.md:block 21 (unordered list) +msgid "" +"don’t have access to their data as it's locked into proprietary systems" +msgstr "" + +#: ./foreword.md:block 21 (unordered list) +msgid "are asked to pay ever increasing license fees" +msgstr "" + +#: ./foreword.md:block 22 (header) +msgid "Technological sovereignty and democratic accountability" +msgstr "" + +#: ./foreword.md:block 23 (paragraph) +msgid "Public institutions, civil servants and residents deserve better." +msgstr "" + +#: ./foreword.md:block 24 (paragraph) +msgid "" +"We believe the software that runs our society can no longer be a black box, " +"controlled by outside companies that keep the underlying logic on which " +"their software operates hidden in proprietary codebases. Instead, " +"governments and the people they serve need technological sovereignty. This " +"allows them to set and control the functioning of public software, just like" +" they are able to set and control policy that is legally formulated in laws." +" Citizens and civil society actors need this software to be transparent and " +"accountable." +msgstr "" + +#: ./foreword.md:block 25 (paragraph) +msgid "" +"The design of software as essential civic infrastructure should honor " +"digital citizens’ rights." +msgstr "" + +#: ./foreword.md:block 26 (header) +msgid "Designing truly public software" +msgstr "" + +#: ./foreword.md:block 27 (paragraph) +msgid "" +"Public code is at the core of modern public institutions, shapes the work of" +" civil servants and affects the lives of almost all residents." +msgstr "" + +#: ./foreword.md:block 28 (paragraph) +msgid "Public software must therefore be:" +msgstr "" + +#: ./foreword.md:block 29 (unordered list) +msgid "transparent" +msgstr "" + +#: ./foreword.md:block 29 (unordered list) +msgid "accountable" +msgstr "" + +#: ./foreword.md:block 29 (unordered list) +msgid "understandable for its constituents" +msgstr "" + +#: ./foreword.md:block 30 (paragraph) +msgid "" +"It must reflect the values of the society it serves, for example by being " +"inclusive and non-discriminatory." +msgstr "" + +#: ./foreword.md:block 31 (paragraph) +msgid "" +"Most proprietary software systems currently used by public organizations do " +"not meet these requirements. Public code does." +msgstr "" + +#: ./foreword.md:block 32 (header) +msgid "Values of public code" +msgstr "" + +#: ./foreword.md:block 33 (paragraph) +msgid "We consider public code to have these core values:" +msgstr "" + +#: ./foreword.md:block 34 (unordered list) +msgid "Inclusive" +msgstr "" + +#: ./foreword.md:block 34 (unordered list) +msgid "Usable" +msgstr "" + +#: ./foreword.md:block 34 (unordered list) +msgid "Open" +msgstr "" + +#: ./foreword.md:block 34 (unordered list) +msgid "Legible" +msgstr "" + +#: ./foreword.md:block 34 (unordered list) +msgid "Accountable" +msgstr "" + +#: ./foreword.md:block 34 (unordered list) +msgid "Accessible" +msgstr "" + +#: ./foreword.md:block 34 (unordered list) +msgid "Sustainable" +msgstr "" + +#: ./foreword.md:block 35 (header) +msgid "How public code works" +msgstr "" + +#: ./foreword.md:block 36 (paragraph) +msgid "" +"Public code is open source software meant for fulfilling the essential role " +"of public organizations. Through use, other administrations contribute back " +"to the software, so that its development and maintenance become truly " +"collaborative." +msgstr "" + +#: ./foreword.md:block 37 (paragraph) +msgid "Being open unlocks many other things." +msgstr "" + +#: ./foreword.md:block 38 (paragraph) +msgid "" +"Local responsibility and democratic accountability are ensured when a public" +" organization implements and maintains their own public code. By being open " +"and with a broader contributor base, the software is more secure as it " +"benefits from many eyes spotting potential flaws. Many contributors share " +"the maintenance work to keep it functional and modern, which reduces future " +"technical debt. The shared workload is more sustainable now and in the " +"future. Its openness makes both the code and its data more easily adaptable " +"in the future. The code will be easier to retool, repurpose or retire. This " +"all results in lower risk public infrastructure." +msgstr "" + +#: ./foreword.md:block 39 (paragraph) +msgid "" +"This pooling of resources lets public administrations give extra attention " +"to how to customize the software so it works best in each local context, " +"creating better user experiences for their end users (residents or " +"citizens)." +msgstr "" + +#: ./foreword.md:block 40 (header) +msgid "Economics of public code" +msgstr "" + +#: ./foreword.md:block 41 (paragraph) +msgid "" +"Public code offers a better economic model for public organizations as well " +"as for commercial companies. It's an alternative to traditional software " +"procurement which increases local control and economic opportunity." +msgstr "" + +#: ./foreword.md:block 42 (paragraph) +msgid "" +"Designed from the start to be open, adaptable and with data portability, it " +"can be developed by in-house staff or trusted vendors. Because the code is " +"open, the public administration can change vendors if they need to. Open " +"code increases opportunities for public learning and scrutiny, allowing the " +"public administration to procure smaller contracts. Smaller procurements are" +" easier for local small and medium enterprises to bid upon. Public " +"administrations can use their own software purchasing to stimulate " +"innovation and competition in their local economy." +msgstr "" + +#: ./foreword.md:block 43 (paragraph) +msgid "" +"This can be seen as investment leading to future economic growth. More " +"vendors will be necessary due to growing technology demand." +msgstr "" + +#: ./foreword.md:block 44 (header) +msgid "Procuring public code" +msgstr "" + +#: ./foreword.md:block 45 (paragraph) +msgid "" +"Public code can be used and developed by permanent in-house development " +"teams, contractors or outsourced suppliers. Vendors to public organizations " +"can include public code in their bids for contracts." +msgstr "" + +#: ./foreword.md:block 46 (paragraph) +msgid "" +"To use existing public code, you need to specify in your budget and project " +"design that your new solution will use that codebase. To encourage an " +"innovative approach to adapting the public code to your context, you could " +"describe the service or outcome in your contract." +msgstr "" + +#: ./foreword.md:block 47 (header) +msgid "The goals for the Standard for Public Code" +msgstr "" + +#: ./foreword.md:block 48 (paragraph) +msgid "" +"This Standard supports developers, designers, managers and public policy " +"makers to:" +msgstr "" + +#: ./foreword.md:block 49 (unordered list) +msgid "" +"develop high quality software and policy for better public service delivery" +msgstr "" + +#: ./foreword.md:block 49 (unordered list) +msgid "" +"develop codebases that can be reused across contexts and collaboratively " +"maintained" +msgstr "" + +#: ./foreword.md:block 49 (unordered list) +msgid "reduce technical debt and project failure rate" +msgstr "" + +#: ./foreword.md:block 49 (unordered list) +msgid "" +"have more granular control over, and ability to make decisions about, their " +"IT systems" +msgstr "" + +#: ./foreword.md:block 49 (unordered list) +msgid "improve vendor relationships with a better economic model" +msgstr "" + +#: ./foreword.md:block 50 (paragraph) +msgid "" +"Potential users of codebases tested against the Standard for Public Code can" +" expect them to be highly reusable, easily maintainable and of high quality." +msgstr "" + +#: ./foreword.md:block 51 (paragraph) +msgid "The Standard for Public Code does this by:" +msgstr "" + +#: ./foreword.md:block 52 (unordered list) +msgid "setting out a common terminology for public code development" +msgstr "" + +#: ./foreword.md:block 52 (unordered list) +msgid "establishing measures to help develop high quality public code" +msgstr "" + +#: ./foreword.md:block 52 (unordered list) +msgid "" +"providing guidance on how to fulfill its criteria and operationalize " +"compliance" +msgstr "" + +#: ./foreword.md:block 53 (paragraph) +msgid "" +"The Standard for Public Code is meant to be time and technology independent." +msgstr "" + +#: ./foreword.md:block 54 (header) +msgid "Who this is for" +msgstr "" + +#: ./foreword.md:block 55 (paragraph) +msgid "" +"The Standard for Public Code is for the people who create and reuse public " +"code:" +msgstr "" + +#: ./foreword.md:block 56 (unordered list) +msgid "public policy makers" +msgstr "" + +#: ./foreword.md:block 56 (unordered list) +msgid "business and project managers" +msgstr "" + +#: ./foreword.md:block 56 (unordered list) +msgid "developers and designers" +msgstr "" + +#: ./foreword.md:block 57 (paragraph) +msgid "These people work at:" +msgstr "" + +#: ./foreword.md:block 58 (unordered list) +msgid "institutions, organizations and administrations in the public sector" +msgstr "" + +#: ./foreword.md:block 58 (unordered list) +msgid "" +"consultancies and vendors of information technology and policy services to " +"public organizations" +msgstr "" + +#: ./foreword.md:block 59 (paragraph) +msgid "" +"It is not aimed at public organizations' end users (residents or citizens), " +"journalists or academics." +msgstr "" + +#: ./foreword.md:block 61 (unordered list) +msgid "" +"[\"Modernising Public Infrastructure with Free Software\" white " +"paper](https://download.fsfe.org/campaigns/pmpc/PMPC-Modernising-with-Free-" +"Software.pdf) by the Free Software Foundation Europe." +msgstr "" + +#: ./foreword.md:block 62 (header) +msgid "Videos on public code" +msgstr "" + +#: ./foreword.md:block 63 (unordered list) +msgid "" +"[Collaborative Code is the Future of Cities @ DecidimFest " +"2019](https://www.youtube.com/watch?v=cnJtnZ9Cx1o). Talk by Ben Cerveny on " +"the background behind the Foundation for Public Code." +msgstr "" + +#: ./foreword.md:block 63 (unordered list) +msgid "" +"[Public Money? Public Code! - Panel @ Nextcloud Conference " +"2019](https://youtube.com/watch?v=QHFkD4xfd6c). Touches on topics like " +"procurement, law and more." +msgstr "" + +#: ./foreword.md:block 64 (header) +msgid "Get involved" +msgstr "" + +#: ./foreword.md:block 65 (paragraph) +msgid "" +"This standard is a living document. [Read our contributor " +"guide](/CONTRIBUTING.md) to learn how you can make it better." +msgstr "" + +#: ./foreword.md:block 66 (header) +msgid "Contact" +msgstr "" + +#: ./foreword.md:block 67 (paragraph) +msgid "" +"For questions and more information about the Foundation for Public Code you " +"can find us at [our website](https://publiccode.net/), email us at " +"info@publiccode.net, or call us at +31 20 2 444 500." +msgstr "" + +#: ./glossary.md:block 3 (header) +msgid "Glossary" +msgstr "" + +#: ./glossary.md:block 4 (header) +msgid "Code" +msgstr "" + +#: ./glossary.md:block 5 (paragraph) +msgid "" +"Any explicitly described system of rules. This includes laws, policy and " +"ordinances, as well as source code that is used to build software. Both of " +"these are rules, some executed by humans and others by machines." +msgstr "" + +#: ./glossary.md:block 6 (header) +msgid "Codebase" +msgstr "" + +#: ./glossary.md:block 7 (paragraph) +msgid "" +"Any discrete package of code (both source and policy), the tests and the " +"documentation required to implement a piece of policy or software." +msgstr "" + +#: ./glossary.md:block 8 (paragraph) +msgid "This can be, for example, a document or a version-control repository." +msgstr "" + +#: ./glossary.md:block 9 (header) +msgid "Continuous integration" +msgstr "" + +#: ./glossary.md:block 10 (paragraph) +msgid "" +"In software engineering, continuous integration (CI) is the practice of " +"merging all developers' working copies to a development branch of a codebase" +" as frequently as reasonable." +msgstr "" + +#: ./glossary.md:block 11 (header) +msgid "Different contexts" +msgstr "" + +#: ./glossary.md:block 12 (paragraph) +msgid "" +"Two contexts are different if they are different public organizations or " +"different departments for which there is not one decision maker that could " +"make collaboration happen naturally." +msgstr "" + +#: ./glossary.md:block 13 (header) +msgid "General public" +msgstr "" + +#: ./glossary.md:block 14 (paragraph) +msgid "" +"The public at large: end users of the code and the services based upon it." +msgstr "" + +#: ./glossary.md:block 15 (paragraph) +msgid "" +"For example, a city's residents are considered end users of a city's " +"services and of all code that powers these services." +msgstr "" + +#: ./glossary.md:block 16 (header) +msgid "Open source" +msgstr "" + +#: ./glossary.md:block 17 (paragraph) +msgid "" +"Open source is defined by the Open Source Initiative in their [Open Source " +"Definition](https://opensource.org/osd-annotated)." +msgstr "" + +#: ./glossary.md:block 18 (header) +msgid "Open standard" +msgstr "" + +#: ./glossary.md:block 19 (paragraph) +msgid "" +"An open standard is any standard that meets the Open Source Initiative's " +"[Open Standard Requirements](https://opensource.org/osr)." +msgstr "" + +#: ./glossary.md:block 20 (header) +msgid "Policy" +msgstr "" + +#: ./glossary.md:block 21 (paragraph) +msgid "" +"A policy is a deliberate system of principles to guide decisions and achieve" +" rational outcomes. A policy is a statement of intent, and is implemented as" +" a procedure or protocol. Policies are generally adopted by a governance " +"body within an organization. Policies can assist in both subjective and " +"objective decision making." +msgstr "" + +#: ./glossary.md:block 22 (paragraph) +msgid "" +"Public policy is the process by which governments translate their political " +"vision into programs and actions to deliver outcomes." +msgstr "" + +#: ./glossary.md:block 23 (paragraph) +msgid "" +"At the national level, policy and legislation (the law) are usually " +"separate. The distinction is often more blurred in local government." +msgstr "" + +#: ./glossary.md:block 24 (paragraph) +msgid "" +"In the Standard the word 'policy' refers to policy created and adopted by " +"public organizations such as governments and municipalities." +msgstr "" + +#: ./glossary.md:block 25 (header) +msgid "Public code" +msgstr "" + +#: ./glossary.md:block 26 (paragraph) +msgid "" +"Public code is open source software developed by public organizations, " +"together with the policy and guidance needed for collaboration and reuse." +msgstr "" + +#: ./glossary.md:block 27 (paragraph) +msgid "" +"Public code is both computer source code (such as software and algorithms) " +"and public policy executed in a public context, by humans or machines." +msgstr "" + +#: ./glossary.md:block 28 (paragraph) +msgid "" +"Public code serves the public interest, is open, legible, accountable, " +"accessible and sustainable." +msgstr "" + +#: ./glossary.md:block 29 (paragraph) +msgid "" +"By developing public code independently from but still implementable in the " +"local context for which it was developed, as well as documenting the " +"development process openly, public code can provide a building block for " +"others to:" +msgstr "" + +#: ./glossary.md:block 30 (unordered list) +msgid "re-implement in their local context" +msgstr "" + +#: ./glossary.md:block 30 (unordered list) +msgid "take as a starting point to continue development" +msgstr "" + +#: ./glossary.md:block 30 (unordered list) +msgid "use as a basis for learning" +msgstr "" + +#: ./glossary.md:block 31 (paragraph) +msgid "" +"To facilitate reuse, public code is either released into the public domain " +"or licensed with an open license that permits others to view and reuse the " +"work freely and to produce derivative works." +msgstr "" + +#: ./glossary.md:block 32 (header) +msgid "Repository" +msgstr "" + +#: ./glossary.md:block 33 (paragraph) +msgid "" +"A repository is a storage location used by version control tools for files " +"and metadata of a codebase. Repositories allow multiple contributors to work" +" on the same set of files. Repositories are able to store multiple versions " +"of sets of files." +msgstr "" + +#: ./glossary.md:block 34 (header) +msgid "Source Code" +msgstr "" + +#: ./glossary.md:block 35 (paragraph) +msgid "" +"Human readable text of a computer program which can be translated into " +"machine instructions." +msgstr "" + +#: ./glossary.md:block 36 (header) +msgid "Version control" +msgstr "" + +#: ./glossary.md:block 37 (paragraph) +msgid "" +"Version control is the management of changes to source code and the files " +"associated with it. Changes are usually identified by a code, termed the " +"*revision number* (or similar). Each revision is associated with the time it" +" was made and the person making the change, thus making it easier to retrace" +" the evolution of the code. Revision control systems can be used to compare " +"different versions with each other and to see how content has changed over " +"time." +msgstr "" + +#: ./index.md:block 3 (header) +msgid "toc: false" +msgstr "" + +#: ./index.md:block 4 (header) +msgid "Guidance for government open source collaboration" +msgstr "" + +#: ./index.md:block 5 (paragraph) +msgid "" +"The Standard for Public Code is a set of criteria that supports public " +"organizations in developing and maintaining software and policy together." +msgstr "" + +#: ./index.md:block 6 (paragraph) +msgid "" +"The Standard for Public Code provides guidance to public organizations " +"building their own open source solutions to enable successful future " +"collaboration and reuse by similar organizations in the public sector in " +"other places. It includes advice for policy makers, government managers, " +"developers and vendors. The Standard for Public Code supports the " +"collaborative creation of codebases that are usable, open, legible, " +"accountable, accessible and sustainable. It is meant to be applicable to " +"codebases for all levels of government, from supranational to municipal." +msgstr "" + +#: ./index.md:block 7 (paragraph) +msgid "" +"The Standard for Public Code defines ‘[public code](glossary.md#public-" +"code)’ as open source software developed by public organizations, together " +"with the policy and guidance needed for collaboration and reuse." +msgstr "" + +#: ./index.md:block 8 (paragraph) +msgid "" +"The criteria of the Standard for Public Code are aligned with guidelines and" +" best practices of open source software development." +msgstr "" + +#: ./index.md:block 9 (paragraph) +msgid "" +"{% for page in site.pages %}{% if page.name == \"foreword.md\" %} Additional" +" context and background can be found in the [foreword](foreword.md). {% " +"endif%}{% endfor %}" +msgstr "" + +#: ./index.md:block 10 (header) +msgid "Contents" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "[Readers guide: how to interpret this standard](readers-guide.md)" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "[Glossary](glossary.md)" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "" +"[Criteria](criteria/){% assign sorted = site.pages | sort:\"order\" %}{% for" +" page in sorted %}{% if page.dir == \"/criteria/\" %}{% if page.name != " +"\"index.md\" %}{% if page.title %}" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "" +"[{{page.title}}]({{page.url}}){% endif%}{% endif%}{% endif%}{% endfor %}" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "[Authors](AUTHORS.md)" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "[Contributing guide](CONTRIBUTING.md)" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "[Code of conduct](CODE_OF_CONDUCT.md)" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "[Governance](GOVERNANCE.md)" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "[Version history](CHANGELOG.md)" +msgstr "" + +#: ./index.md:block 11 (unordered list) +msgid "[License](license.html)" +msgstr "" + +#: ./index.md:block 12 (header) +msgid "Community calls" +msgstr "" + +#: ./index.md:block 13 (paragraph) +msgid "" +"We usually have a community call on the first Thursday of the month at 15:00" +" (CET/CEST). [The agenda](https://write.publiccode.net/pads/Community-Call-" +"Standard-for-Public-Code) is updated roughly a week before the call. It is " +"possible to [sign " +"up](https://odoo.publiccode.net/survey/start/594b9243-c7e5-4bc1-8714-35137c971842)" +" to get a call invitation emailed to you." +msgstr "" + +#: ./index.md:block 14 (header) +msgid "Other resources" +msgstr "" + +#: ./index.md:block 15 (unordered list) +msgid "" +"Unofficial [community translations of the " +"Standard](https://publiccodenet.github.io/community-translations-standard/) " +"in other languages" +msgstr "" + +#: ./index.md:block 15 (unordered list) +msgid "" +"[Standard compliance self " +"assessment](https://publiccodenet.github.io/assessment-eligibility/) for " +"public sector open source codebases" +msgstr "" + +#: ./index.md:block 15 (unordered list) +msgid "" +"[Standard criteria checklist](/docs/review-template.html) used by Foundation" +" for Public Code stewards for codebase review" +msgstr "" + +#: ./readers-guide.md:block 3 (header) +msgid "Readers guide" +msgstr "" + +#: ./readers-guide.md:block 4 (paragraph) +msgid "" +"The Standard describes a number of criteria. All criteria have consistent " +"sections that make it clear how to create great public code." +msgstr "" + +#: ./readers-guide.md:block 5 (paragraph) +msgid "" +"References to \"policy makers\", \"managers\", and \"developers and " +"designers\" apply to anyone performing duties associated with these roles, " +"regardless of their job title. It is common for individuals to have duties " +"which span multiple roles." +msgstr "" + +#: ./readers-guide.md:block 6 (paragraph) +msgid "" +"Below is a brief explanation of each of these sections and how they are used" +" within the criteria of the Standard." +msgstr "" + +#: ./readers-guide.md:block 7 (header) +msgid "Introduction" +msgstr "" + +#: ./readers-guide.md:block 8 (paragraph) +msgid "" +"This section explains what the criterion aims to achieve and why it is " +"important for a codebase's users and contributors." +msgstr "" + +#: ./readers-guide.md:block 10 (paragraph) +msgid "" +"This section lists what needs to be done in order to comply with the " +"standard." +msgstr "" + +#: ./readers-guide.md:block 11 (paragraph) +msgid "" +"The following keywords in this document are to be interpreted as described " +"in [IETF RFC 2119](https://tools.ietf.org/html/rfc2119):" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "MUST" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "MUST NOT" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "REQUIRED" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "SHALL" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "SHALL NOT" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "SHOULD" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "SHOULD NOT" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "RECOMMENDED" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "MAY" +msgstr "" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "OPTIONAL" +msgstr "" + +#: ./readers-guide.md:block 14 (paragraph) +msgid "" +"This section offers actions you can take to see if a contribution is " +"compliant with the Standard. This is key if you want to operationalize the " +"Standard." +msgstr "" + +#: ./readers-guide.md:block 15 (paragraph) +msgid "" +"We've tried to word it so that someone who is not intimately acquainted with" +" the subject matter can still do a basic check for compliance." +msgstr "" + +#: ./readers-guide.md:block 17 (paragraph) +msgid "" +"This section tries to specifically speak to policy makers by offering them " +"concrete actions they can perform in their role." +msgstr "" + +#: ./readers-guide.md:block 18 (paragraph) +msgid "" +"Public policy makers set the priorities and goals of projects and may be " +"less technologically experienced." +msgstr "" + +#: ./readers-guide.md:block 20 (paragraph) +msgid "" +"This section tries to specifically speak to managers by offering concrete " +"actions they can perform in their role." +msgstr "" + +#: ./readers-guide.md:block 21 (paragraph) +msgid "" +"Managers are responsible for on-time project delivery, stakeholder " +"management and continued delivery of the service. For this they are wholly " +"reliant on both policy makers as well as developers and designers. They need" +" to create the right culture, line up the right resources and provide the " +"right structures to deliver great services." +msgstr "" + +#: ./readers-guide.md:block 23 (paragraph) +msgid "" +"This section tries to specifically speak to developers and designers by " +"offering them concrete actions they can perform in their role." +msgstr "" + +#: ./readers-guide.md:block 24 (paragraph) +msgid "" +"Developers are usually more technically aligned and have more impact on the " +"delivery of services than the previous groups." +msgstr "" + +#: ./readers-guide.md:block 25 (header) +msgid "Limitation of scope" +msgstr "" + +#: ./readers-guide.md:block 26 (paragraph) +msgid "" +"The Standard for Public Code is not meant to cover individual " +"implementations of a codebase. This means the standard does not tell " +"implementers how to comply with their organization's local technical " +"infrastructure or legal framework." +msgstr "" + +#: ./readers-guide.md:block 27 (paragraph) +msgid "" +"Also, while the Standard for Public Code refers to several standards and has" +" considerable overlap with others, its purpose is to enable collaboration. " +"Therefore, it does not aim to replace quality standards, like the ISO 25000 " +"series, or those focusing on security, like the [OpenSSF Best Practices " +"Badge](https://github.com/coreinfrastructure/best-practices-badge), but to " +"synergize well with them." +msgstr "" + +#: ./readers-guide.md:block 28 (paragraph) +msgid "" +"And while the purpose includes enabling collaboration, it will not guarantee" +" that a community will spring into existence. That still requires " +"proactiveness and ambition beyond making the codebase collaboration ready." +msgstr "" diff --git a/locales/zh_Hant/LC_MESSAGES/messages.po b/locales/zh_Hant/LC_MESSAGES/messages.po new file mode 100644 index 00000000..ae369f9a --- /dev/null +++ b/locales/zh_Hant/LC_MESSAGES/messages.po @@ -0,0 +1,6304 @@ +msgid "" +msgstr "" +"Project-Id-Version: PACKAGE VERSION\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2023-07-30 22:44+0800\n" +"PO-Revision-Date: 2023-11-03 06:41+0000\n" +"Last-Translator: Winnie \n" +"Language-Team: Chinese (Traditional) \n" +"Language: zh_Hant\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=1; plural=0;\n" +"X-Generator: Weblate 4.18.2\n" + +# +#: ./404.md:block 1 (header) +msgid "SPDX-License-Identifier: CC0-1.0" +msgstr "SPDX-License-Identifier: CC0-1.0" + +#: ./404.md:block 2 (header) +msgid "" +"SPDX-FileCopyrightText: 2022-2023 The Foundation for Public Code " +"[info@publiccode.net](mailto:info@publiccode.net), " +"https://standard.publiccode.net/AUTHORS" +msgstr "" +"SPDX-FileCopyrightText: 2022-2023 Foundation for Public Code [info@publiccode" +".net](mailto:info@publiccode.net), https://standard.publiccode.net/AUTHORS" + +#: ./404.md:block 3 (header) +msgid "" +"layout: default\n" +"title: Page not found\n" +"toc: false" +msgstr "" +"layout: default\n" +"title: Page not found\n" +"toc: false" + +#: ./404.md:block 4 (header) +msgid "404 Not Found" +msgstr "404 找不到網頁" + +#: ./404.md:block 5 (paragraph) +msgid "If you typed the web address, check it is correct." +msgstr "如果您是手動輸入網址，請確認網址是否正確。" + +#: ./404.md:block 6 (paragraph) +msgid "If you pasted the web address, check you copied the entire address." +msgstr "如果您是複製貼上此網址，請確認是否有複製到完整的網址。" + +#: ./404.md:block 7 (paragraph) +msgid "" +"If the web address is correct or you followed a link or button, email the " +"[Foundation for Public Code staff](mailto:info@publiccode.net) so we'll be " +"able to help you out, as well as correct our mistake." +msgstr "" +"若網址正確，或您是按下連結或按鈕來的，請寫信給 [Foundation for Public Code " +"員工](mailto:info@publiccode.net)，讓我們協助您，並同時修正我們的錯誤。" + +#: ./AUTHORS.md:block 2 (header) +msgid "" +"SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code " +"[info@publiccode.net](mailto:info@publiccode.net), " +"https://standard.publiccode.net/AUTHORS" +msgstr "" +"SPDX-FileCopyrightText: 2019-2023 Foundation for Public Code [info@publiccode" +".net](mailto:info@publiccode.net), https://standard.publiccode.net/AUTHORS" + +#: ./AUTHORS.md:block 3 (header) +msgid "Authors" +msgstr "作者群" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Alba Roza, [The Foundation for Public Code](https://publiccode.net/)" +msgstr "Alba Roza，[Foundation for Public Code](https://publiccode.net/)" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Arnout Engelen" +msgstr "Arnout Engelen" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Arnout Schuijff, The Foundation for Public Code" +msgstr "Arnout Schuijff，Foundation for Public Code" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Audrey Tang, [digitalminister.tw](https://digitalminister.tw/)" +msgstr "唐鳳，[數位發展部](https://digitalminister.tw/)" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Ben Cerveny, The Foundation for Public Code" +msgstr "Ben Cerveny，Foundation for Public Code" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Bert Spaan" +msgstr "Bert Spaan" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Boris van Hoytema, The Foundation for Public Code" +msgstr "Boris van Hoytema，Foundation for Public Code" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Charlotte Heikendorf" +msgstr "Charlotte Heikendorf" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Claus Mullie, The Foundation for Public Code" +msgstr "Claus Mullie，Foundation for Public Code" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "David Barberi" +msgstr "David Barberi" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Edo Plantinga, [Code For NL](https://codefor.nl/)" +msgstr "Edo Plantinga，[Code For NL](https://codefor.nl/)" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Elena Findley-de Regt, The Foundation for Public Code" +msgstr "Elena Findley-de Regt，Foundation for Public Code" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Eric Herman, The Foundation for Public Code" +msgstr "Eric Herman，Foundation for Public Code" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Felix Faassen, The Foundation for Public Code" +msgstr "Felix Faassen，Foundation for Public Code" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Floris Deerenberg" +msgstr "Floris Deerenberg" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Jan Ainali, The Foundation for Public Code" +msgstr "Jan Ainali，Foundation for Public Code" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Johan Groenen, Code For NL" +msgstr "Johan Groenen，Code For NL" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Marcus Klaas de Vries" +msgstr "Marcus Klaas de Vries" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Mark van der Net, [Gemeente Amsterdam](https://www.amsterdam.nl/en/)" +msgstr "Mark van der Net，[阿姆斯特丹市政府](https://www.amsterdam.nl/en/)" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "" +"Martijn de Waal, [Amsterdam University of Applied Sciences " +"(AUAS)](https://www.amsterdamuas.com/), Faculty of Digital Media and " +"Creative Industries, Lectorate of Play & Civic Media" +msgstr "" +"Martijn de Waal，[阿姆斯特丹應用科技大學 (AUAS)](https://www.amsterdamuas." +"com/)，數位媒體與創意產業學院，戲劇與公民媒體系講師" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Matti Schneider" +msgstr "Matti Schneider" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Mauko Quiroga" +msgstr "Mauko Quiroga" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Maurice Hendriks, Gemeente Amsterdam" +msgstr "Maurice Hendriks， 阿姆斯特丹市政府" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Maurits van der Schee, Gemeente Amsterdam" +msgstr "Maurits van der Schee，阿姆斯特丹市政府" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Mirjam van Tiel, The Foundation for Public Code" +msgstr "Mirjam van Tiel，Foundation for Public Code" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Ngô Ngọc Đức Huy" +msgstr "Ngô Ngọc Đức Huy" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Paul Keller" +msgstr "Paul Keller" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "" +"Petteri Kivimäki, [Nordic Institute for Interoperability Solutions " +"(NIIS)](https://niis.org)" +msgstr "Petteri Kivimäki， [北歐互通性解決方案機構 (NIIS)](https://niis.org)" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Sky Bristol" +msgstr "Sky Bristol" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Tamas Erkelens, Gemeente Amsterdam" +msgstr "Tamas Erkelens，阿姆斯特丹市政府" + +#: ./AUTHORS.md:block 4 (unordered list) +msgid "Timo Slinger" +msgstr "Timo Slinger" + +#: ./CC0-1.0.md:block 3 (header) +msgid "toc: false redirect_from: - license.html - LICENSE.html" +msgstr "toc: false redirect_from: - license.html - LICENSE.html" + +#: ./CC0-1.0.md:block 4 (header) +msgid "Creative Commons Zero v1.0 Universal" +msgstr "創用 CC0 1.0 通用授權" + +#: ./CC0-1.0.md:block 6 (paragraph) +msgid "" +"This license is the legal contract that allows anyone to do anything they " +"like with the content in this entire document." +msgstr "此授權的法律契約，允許任何人任意使用本文件中的任何內容。" + +#: ./CHANGELOG.md:block 3 (header) +msgid "Version history" +msgstr "版本歷史" + +#: ./CHANGELOG.md:block 5 (header) +msgid "Version 0.7.0" +msgstr "0.7.0 版" + +#: ./CHANGELOG.md:block 6 (paragraph) +msgid "" +"May 31st 2023: 📑 the fifteenth draft adds new requirements for documenting " +"review funding and clarifies review process requirement." +msgstr "2023年5月31日：📑第十五版新增紀錄募資審查的新規定，並釐清審查流程規定。" + +#: ./CHANGELOG.md:block 7 (unordered list) +msgid "" +"Add requirement to document who is expected to cover the cost of reviewing " +"contributions." +msgstr "新增規定，記錄預期由何者負擔審核貢獻內容所需的開銷費用。" + +#: ./CHANGELOG.md:block 7 (unordered list) +msgid "Add requirement to have a short description of the codebase." +msgstr "新增規定，程式基底必須要有簡短說明。" + +#: ./CHANGELOG.md:block 7 (unordered list) +msgid "" +"Change the focus of contributions adhering to standards to focus on the " +"review of contributions." +msgstr "原先專注在貢獻內容是否遵循標準，現在則改為注重貢獻內容的審查。" + +#: ./CHANGELOG.md:block 7 (unordered list) +msgid "Relaxed MUST requirements to SHOULD in Make the codebase findable." +msgstr "將〈程式基底可查詢得到〉中許多「必須」等級的規定，調降為「應該」等級。" + +#: ./CHANGELOG.md:block 7 (unordered list) +msgid "Review template now in HTML format." +msgstr "審查範本現在有 HTML 格式。" + +#: ./CHANGELOG.md:block 7 (unordered list) +msgid "Introduction converted to foreword." +msgstr "「前言」轉換為「序文」。" + +#: ./CHANGELOG.md:block 7 (unordered list) +msgid "Improved contributing guidelines." +msgstr "改善貢獻指引。" + +#: ./CHANGELOG.md:block 7 (unordered list) +msgid "Improved documentation of scripts." +msgstr "改善命令稿文件紀錄。" + +#: ./CHANGELOG.md:block 8 (header) +msgid "Version 0.6.0" +msgstr "0.6.0 版" + +#: ./CHANGELOG.md:block 9 (paragraph) +msgid "" +"April 20th 2023: 🔀 the fourteenth draft adds new requirements for " +"portability and tests and an introduction to each criterion." +msgstr "2023年4月20日：🔀第十四版草稿新增可移植性與測試的規定，並且每個準則都有一段前" +"言。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"New requirement in Create reusable and portable code about the development " +"being a collaboration between multiple parties." +msgstr "新增規定，在〈程式碼要可重複使用且可攜〉加入多方協作開發的內容。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"New requirement in Create reusable and portable code about being dependent " +"on a single vendor." +msgstr "新增規定，在〈程式碼要可重複使用且可攜〉中加入依賴單一供應商的內容。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"New requirement in Use continuous integration about publishing results for " +"automated tests." +msgstr "新增規定，在〈使用持續整合〉中加入要發布自動化測試結果的內容。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Differentiating the two requirements about security to clearly be about " +"providing a method and having documentation about it." +msgstr "對安全性區分出兩項規定，一是要有提供方法，另一個是要有文件紀錄。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Rephrased requirements to focus on the codebase rather than contributor " +"behavior." +msgstr "重新撰寫規定，將焦點放在程式基底，而非貢獻者行為。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Removed the sections Why this is important and What this does not do and " +"replaced with an introduction in each criterion." +msgstr "移除「此措施辦不到的事」以及「此措施為何重要」兩個小節，改換成在每項準則中加" +"入前言。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Added general What this does not do section in the introduction of the " +"Standard." +msgstr "在本標準前言中，加入通用的「此措施辦不到的事」小節。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Added guidance for public policy makers about related policies and license " +"compatibility." +msgstr "為政策制定者加入相關政策與授權相容性的指引。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Added guidance for developers and designers about version controlling files." +msgstr "為開發人員與設計師新增檔案要有版本控制的相關指引。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Clarified guidance for developers and designers about prompt responses and " +"search engine optimization." +msgstr "為開發人員與設計師釐清有關快速回應，以及搜尋引擎最佳化的內容。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "Added Further reading about accessibility." +msgstr "新增可近用性無障礙環境的「延伸閱讀」內容。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "Aligned criteria URLs with criteria names." +msgstr "將各準則的連結與其名稱連動。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "Improved navigation in the web version." +msgstr "改善網頁版的導覽功能。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Moved tools in Further reading sections to the community implementation " +"guide." +msgstr "已將「延伸閱讀」小節的工具移到社群實踐指引。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Moved compliance or certification process to " +"[publiccode.net](https://publiccode.net)." +msgstr "將標準依循或認證相關流程移到 [publiccode.net](https://publiccode.net)。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Change format of the review template to make it easier to update after a new" +" release." +msgstr "變更審查範本格式，讓範本在發行新版後更容易更新。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "" +"Improved the text on the landing page and added links to related resources." +msgstr "改善著陸引導頁文字，加入相關資源的連結。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "Added spell checker automated test." +msgstr "新增拼字檢查自動化測試。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "Made minor changes to text for clarity and consistency." +msgstr "微調文字，讓內容更明確與一致。" + +#: ./CHANGELOG.md:block 10 (unordered list) +msgid "Moved SPDX headers to yaml header." +msgstr "將 SPDX 標頭換成 yaml 標頭。" + +#: ./CHANGELOG.md:block 11 (header) +msgid "Version 0.5.0" +msgstr "0.5.0 版" + +#: ./CHANGELOG.md:block 12 (paragraph) +msgid "" +"January 25th 2023: 🎨 the thirteenth draft focuses on documenting style " +"guidelines." +msgstr "2023年1月25日：🎨第十三版草稿焦點著重在文件紀錄風格指引。" + +#: ./CHANGELOG.md:block 13 (unordered list) +msgid "" +"Adjust the coding style requirement to focus on the codebase using a style " +"guide rather than contributor behavior." +msgstr "調整程式碼撰寫風格要求，專注於程式基底上，而非貢獻者行為。" + +#: ./CHANGELOG.md:block 13 (unordered list) +msgid "" +"Moved requirement for codebase names to Make the codebase findable from Use " +"plain English." +msgstr "將程式基底名稱規定，從〈使用白話的英文〉移到〈程式基底可查詢得到〉。" + +#: ./CHANGELOG.md:block 13 (unordered list) +msgid "" +"Moved requirement about testing the code by using examples to Use continuous" +" integration from Document the code." +msgstr "將測試程式碼的規定，從〈程式碼要有文件〉移到〈使用持續整合〉。" + +#: ./CHANGELOG.md:block 13 (unordered list) +msgid "" +"Split requirement about machine testable standards to clarify that open is " +"more important than testable." +msgstr "劃分機器可讀的測試標準規定，指明程式碼的開放性比可測試性更重要。" + +#: ./CHANGELOG.md:block 13 (unordered list) +msgid "" +"Adjust how to test findability requirements to be less reliant on search " +"engine algorithms." +msgstr "調整可查找性的測試規定，降低對搜尋引擎演算法的依賴。" + +#: ./CHANGELOG.md:block 14 (header) +msgid "Version 0.4.1" +msgstr "0.4.1 版" + +#: ./CHANGELOG.md:block 15 (paragraph) +msgid "December 5th 2022: 📝 the twelfth draft clarifies document maturity." +msgstr "2022年12月5日：📝第十二版草稿指出要以文件記錄成熟度。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "" +"Document maturity focuses on whether or not versions of the codebase are " +"ready to use." +msgstr "寫下成熟度著重於程式基底是否已經可供使用，更甚於版本編號。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "" +"Document maturity no longer requires specific labels for codebases that are " +"not ready to use." +msgstr "寫下成熟度不再需要為尚未準備好可供使用的程式基底加上特定標籤。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Audit flow image now generated from an easier to translate format." +msgstr "稽核流程圖現在以更容易轉譯的格式生成。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Improved guidance on How to test." +msgstr "改善「測試方式」指引。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Add publiccode.yml file." +msgstr "新增 publiccode.yml 檔案。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Add review template." +msgstr "新增審查範本。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Consistently link glossary terms." +msgstr "一致性連結詞彙表。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Add practices and standards to follow in CONTRIBUTING." +msgstr "在「CONTRIBUTING」中加入要遵循的實務與標準。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Add Matti Schneider to Authors." +msgstr "將 Matti Schneider 加入作者群。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Add remaining SPDX headers to files." +msgstr "將剩餘 SPDX 標頭加入檔案中。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Made additional minor changes to text for clarity." +msgstr "再稍微修改些文字，讓文字更明確。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "Some hyperlinks updated." +msgstr "更新部分超連結。" + +#: ./CHANGELOG.md:block 16 (unordered list) +msgid "" +"Moved examples to the [Community implementation " +"guide](https://publiccodenet.github.io/community-implementation-guide-" +"standard/)." +msgstr "" +"將範例移動到《[社群實踐指引](https://publiccodenet.github.io/" +"community-implementation-guide-standard/)》。" + +#: ./CHANGELOG.md:block 17 (header) +msgid "Version 0.4.0" +msgstr "0.4.0 版" + +#: ./CHANGELOG.md:block 18 (paragraph) +msgid "" +"September 7th 2022: 🔭 the eleventh draft adds a new findability criterion." +msgstr "2022年9月7日：🔭第十一版草稿新增可查找性準則。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Introduce new criterion: Make the codebase findable." +msgstr "導入新準則：程式基底可查詢得到。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Improve How to test section for most criteria." +msgstr "改善多數準則的「測試方式」小節。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "" +"New requirement in Welcome contributors about publishing activity " +"statistics." +msgstr "在〈歡迎貢獻者〉中加入發布活動統計的新規定。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Removed redundant requirement about portable and reusable code." +msgstr "移除可重複使用與移植的程式碼中多餘的規定。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "" +"Expand open license definition to include both OSI and FSF approved " +"licenses." +msgstr "在開放授權的定義中，加入 OSI 與 FSF 所批准的授權。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Rephrase MAY requirements to use the keyword OPTIONAL for clarity." +msgstr "重新編寫「得以」等級的相關規定，加入使用「可選擇」這個關鍵字，讓規定更明確。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "" +"Expressed intent that the Standard for Public Code should meet its own " +"requirements where applicable and added assessment." +msgstr "表達《公共程式標準》應該盡可能符合其自身規定的立場，並加入評估措施。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Add SPDX license identifiers to files." +msgstr "將 SPDX 授權識別碼加入檔案中。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Introduced new Code of Conduct." +msgstr "導入新的行為守則。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Clarify distinction between source code and policy text." +msgstr "解釋原始碼與政策內文的差異。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Restructuring of requirements with bullet point lists." +msgstr "將規定重新調整為項目要點清單格式。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Acknowledge the importance of codebase modularity for reuse." +msgstr "告知程式基底成熟度對於重複使用時的重要性。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Move requirements related to Findability to the new criterion." +msgstr "將可查找性相關規定移動到新準則中。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Clarify the role of non-open standards when used in a codebase." +msgstr "釐清非開放標準在程式基底中的角色。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Additional guidance about build-time and runtime dependencies." +msgstr "加入組建日期與執行時期依賴項目的額外指引。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Added roadmap for the development of the Standard for Public Code." +msgstr "新增《公共程式標準》的發展路線圖。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Update structure of Authors file." +msgstr "更新 Authors 檔案的結構。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Add Audrey Tang to Authors." +msgstr "將唐鳳加入作者群。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "Added a list of criteria to the print edition." +msgstr "將準則列表加到印刷版本中。" + +#: ./CHANGELOG.md:block 19 (unordered list) +msgid "" +"Clarify what the standard means with policymakers, managers, developers and " +"designers." +msgstr "釐清標準對於政策制定者、管理人員、開發人員與設計師等不同身分間的意義。" + +#: ./CHANGELOG.md:block 20 (header) +msgid "Version 0.3.0" +msgstr "0.3.0 版" + +#: ./CHANGELOG.md:block 21 (paragraph) +msgid "" +"May 23rd 2022: 🗎 the tenth draft strengthens documentation and localization." +msgstr "2022年5月23日：🗎第十版草稿加強文件紀錄與在地化內容。" + +#: ./CHANGELOG.md:block 22 (unordered list) +msgid "" +"Requirement for localization made explicit in Create reusable and portable " +"code." +msgstr "在〈程式碼要可重複使用且可攜〉中定下明確的在地化規定。" + +#: ./CHANGELOG.md:block 22 (unordered list) +msgid "Documentation of governance changed from a SHOULD to a MUST." +msgstr "以文件記錄治理方式的規定，從「應該」等級調升為「必須」。" + +#: ./CHANGELOG.md:block 22 (unordered list) +msgid "" +"Replace the very subjective (and hard to test) \"contributions MUST be " +"small\" with requirement to document expectation in contributing guidelines " +"and focus on a single issue." +msgstr "在貢獻指引中，將非常主觀（且難以驗證）的「貢獻內容『必須』小」的規定，改為必" +"須紀錄貢獻所要完成的期待，並一次專注在單一議題上。" + +#: ./CHANGELOG.md:block 22 (unordered list) +msgid "Community translations now linked in the footer." +msgstr "社群翻譯連結現在已放到頁尾中。" + +#: ./CHANGELOG.md:block 22 (unordered list) +msgid "Revert \"Replace BPMN svg with Mermaid flowchart\"." +msgstr "還原「用 Mermaid 流程圖取代業務流程 BPMN svg」。" + +#: ./CHANGELOG.md:block 22 (unordered list) +msgid "Many minor clarifications to language and sentences made more simple." +msgstr "細微調整用詞，讓句子更簡單。" + +#: ./CHANGELOG.md:block 23 (header) +msgid "Version 0.2.3" +msgstr "0.2.3 版" + +#: ./CHANGELOG.md:block 24 (paragraph) +msgid "" +"March 15th 2022: 📜 the ninth draft allows English summaries for policy " +"lacking an official translation." +msgstr "2022年3月15日：📜第九版草稿允許缺少官方翻譯的政策，改為提供政策的英文版摘要。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "" +"Relax the criterion Use plain English by adding a new requirement allows " +"bundled policy not available in English to have an accompanying summary in " +"English instead of translating the full text." +msgstr "放寬〈使用白話的英文〉準則，加入新規定，允許合捆的政策內文如果沒有英文版，只" +"需要加入英文版摘要，而不用翻譯全文。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "" +"Similarly, allow for English summaries for policies not available in English" +" in Bundle policy and code." +msgstr "同樣地，在〈政策與原始碼要合捆〉中，沒有英文版的政策內文可允許提供英文版摘要" +"。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "" +"Clarify that term 'policy' includes processes which impact development and " +"deployment in Bundle policy and code." +msgstr "釐清〈政策與原始碼要合捆〉中，「政策」包含能影響開發與部署的流程。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "" +"Emphasize reusability also on parts of the solutions in Create reusable and " +"portable code." +msgstr "在〈程式碼要可重複使用且可攜〉中強調解決方案部分內容的可重複使用性。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "" +"Expand guidance to Developers and designers in Create reusable and portable " +"code about deploying to proprietary platforms." +msgstr "將〈程式碼要可重複使用且可攜〉當中的開發人員與設計師指引，加入部署到專有平台" +"上的內容。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "" +"Add nuance to use of non-English terms in what management need to do in Use " +"plain English." +msgstr "在〈使用白話的英文〉中，加入管理層在面對非英語詞彙時需要做的事的提點。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "" +"Change the pull request process diagram to use Mermaid instead of BPMN to " +"make [community translations](https://github.com/publiccodenet/community-" +"translations-standard) easier." +msgstr "" +"變更拉取請求流程圖，從業務流程 BPMN 改用 " +"Mermaid，來讓[社群翻譯](https://github.com/publiccodenet/community-" +"translations-standard)更容易。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "Added Maurice Hendriks to AUTHORS." +msgstr "將 Maurice Hendriks 加入作者群。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "Added OpenApi Specification to further reading." +msgstr "將「OpenApi 規格」加入延伸閱讀。" + +#: ./CHANGELOG.md:block 25 (unordered list) +msgid "Made the attributions in further reading sections clearer." +msgstr "將延伸閱讀小節的特性變得更明確。" + +#: ./CHANGELOG.md:block 26 (header) +msgid "Version 0.2.2" +msgstr "0.2.2 版" + +#: ./CHANGELOG.md:block 27 (paragraph) +msgid "" +"November 29th 2021: 🏛 the eighth draft recognizes that policy which executes" +" as code may not be in English." +msgstr "2021年11月29日：🏛第八版草稿認知程式碼所執行的政策，不一定是英文。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "" +"Document exception to \"All code MUST be in English\" where policy is " +"interpreted as code." +msgstr "在「所有程式碼都必須使用英語編寫」規定中，雖然政策也算是一種程式 " +"(code)，但可以保有例外。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "" +"Add MAY requirement regarding committer email addresses in Maintain version " +"control." +msgstr "在〈維護版本控制〉中，新增與送交者電子郵件相關的「得以」規定。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Expand guidance to Policy Makers in Bundle policy and code." +msgstr "將政策制定者加入〈政策與原始碼要合捆〉指引中。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Expand guidance to Developers and designers in Use a coherent style." +msgstr "將開發人員與設計師加入「風格要前後一致」指引中。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Add \"Different contexts\" to glossary." +msgstr "新增「不同情境」到詞彙表中。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Add Mauko Quiroga and Charlotte Heikendorf to AUTHORS." +msgstr "將 Mauko Quiroga 與 Charlotte Heikendorf 加入 AUTHORS。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Add Digital Public Goods approval badge." +msgstr "新增「數位公共財」認可標章。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Added \"next\" and \"previous\" links to criteria pages of web version." +msgstr "為「準則」頁面網頁版加入「上一頁」與「下一頁」連結。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Add Open Standards principles to further reading." +msgstr "將「開放標準」原則加入延伸閱讀。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Add Definition of plain language to further reading." +msgstr "將「白話語言定義」加入延伸閱讀。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Move the Semantic Versioning Specification further reading reference." +msgstr "將「語意化版本編號規範」移動為延伸閱讀參考內容。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "" +"Clarify that publiccode.yml is one example of a machine-readable metadata " +"description." +msgstr "指出 publiccode.yml 是機器可讀中介資料說明的範例之一。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Changed \"your codebase\" and \"your organization\" to be less possessive." +msgstr "將「您的程式基底」與「您的組織單位」改為較不具有所有格的寫法。" + +#: ./CHANGELOG.md:block 28 (unordered list) +msgid "Add instructions for creating a print version." +msgstr "新增印刷版的製作指示。" + +#: ./CHANGELOG.md:block 29 (header) +msgid "Version 0.2.1" +msgstr "0.2.1 版" + +#: ./CHANGELOG.md:block 30 (paragraph) +msgid "" +"March 1st 2021: 🧽 the seventh draft has minor cleaning up after version " +"0.2.0." +msgstr "2021年3月1日：🧽第七版草稿是 0.2.0 版後的些微清理改善。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "" +"New SHOULD requirement on using a distributed version control system and why" +" distributed is important." +msgstr "新增使用分散式版本控制系統的相關「應該」規定，並解釋分散式的重要性。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "" +"Feedback requirements for rejected contributions are more strict than " +"accepted ones." +msgstr "針對未被採用的貢獻需要給予回饋，規定要比被接受的貢獻更加嚴格。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "" +"Specify that copyright and license notices should also be machine-readable." +msgstr "明確指出著作權與授權聲明也應該要機器可讀。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "Advice on how to test that notices be machine-readable." +msgstr "聲明是否為機器可讀的測試方式建議。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "Clarify guidance for rolling releases." +msgstr "釐清滾動發行的指引。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "Clear up definition of version control in glossary." +msgstr "釐清詞彙表中「版本控制」的定義。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "" +"Add further reading encouraging contribution, SPDX, Git and reviewing " +"contributions." +msgstr "新增鼓勵貢獻、SPDX、Git 以及審查貢獻等的延伸閱讀項目。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "Add links to videos about the concept of public code." +msgstr "新增有關公共程式概念的影片連結。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "Update BPMN link." +msgstr "更新業務流程 BPMN 連結。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "Reduce link duplication." +msgstr "減少重複連結。" + +#: ./CHANGELOG.md:block 31 (unordered list) +msgid "Add Alba Roza and Ngô Ngọc Đức Huy to authors." +msgstr "將 Alba Roza 與 Ngô Ngọc Đức Huy 加入作者群。" + +#: ./CHANGELOG.md:block 32 (header) +msgid "Version 0.2.0" +msgstr "0.2.0 版" + +#: ./CHANGELOG.md:block 33 (paragraph) +msgid "" +"October 26th 2020: 🎊 the sixth draft splits a requirement and adds clarity." +msgstr "2020年10月26日：🎊第六版草稿拆分出一項新規定並且釐清內容。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "" +"Split \"Welcome contributions\" criterion into \"Make contributing easy\" " +"and \"Welcome contributors\"." +msgstr "將〈歡迎貢獻〉準則拆分為〈貢獻要容易〉以及〈歡迎貢獻者〉。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "" +"Rename criterion \"Pay attention to codebase maturity\" to \"Document " +"codebase maturity\"." +msgstr "將〈注意程式基底成熟度〉準則改名為〈記錄程式基底成熟度〉。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "" +"Changed MUST to SHOULD for requirement of codebase in use by multiple " +"parties." +msgstr "針對多方使用的程式基底，將「必須」等級規定調降為「應該」。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "Add MUST NOT requirement regarding copyright assignment." +msgstr "針對著作權轉讓，新增「禁止」規定。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "Clarify role of configuration in reusable code requirement." +msgstr "在可重複使用程式碼的規定中，釐清組態設定的角色。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "" +"Glossary additions: continuous integration, policy, repository, and version " +"control." +msgstr "新增詞彙：持續整合、政策、儲存庫、版本控制等。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "Replace references to 'cities' with 'public organizations'." +msgstr "將「城市」替換成「公家機關」。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "" +"Clarify aspects of sensitive code by separating contributor and reviewer " +"requirements into separate items." +msgstr "將貢獻者與審查人員規定分開為不同項目，以釐清程式碼中較敏感性的層面。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "" +"Expand further reading, and guidance to policy makers, developers and " +"designers." +msgstr "將政策制定者、開發人員與設計師加入延伸閱讀與指引中。" + +#: ./CHANGELOG.md:block 34 (unordered list) +msgid "Add Felix Faassen and Arnout Engelen to authors." +msgstr "將 Felix Faassen 與 Arnout Engelen 加入作者群。" + +#: ./CHANGELOG.md:block 35 (header) +msgid "Version 0.1.4" +msgstr "0.1.4 版" + +#: ./CHANGELOG.md:block 36 (paragraph) +msgid "" +"November 27th 2019: 🧹 the fifth draft consists mostly of additional minor " +"fixes." +msgstr "2019年11月27日：🧹第五版草稿主要是一些細部修正。" + +#: ./CHANGELOG.md:block 37 (unordered list) +msgid "Linked License.md file." +msgstr "連結 License.md 檔案。" + +#: ./CHANGELOG.md:block 37 (unordered list) +msgid "Add Sky Bristol, Marcus Klaas de Vries, and Jan Ainali to authors." +msgstr "將 Sky Bristol、Marcus Klaas de Vries 與 Jan Ainali 加入作者群。" + +#: ./CHANGELOG.md:block 37 (unordered list) +msgid "Made punctuation more consistent, especially for bullet lists." +msgstr "讓標點符號使用更一致，特別是項目符號列表。" + +#: ./CHANGELOG.md:block 37 (unordered list) +msgid "Made some minor changes to text for clarity." +msgstr "細部調整文字，讓內容更明確。" + +#: ./CHANGELOG.md:block 38 (header) +msgid "Version 0.1.3" +msgstr "0.1.3 版" + +#: ./CHANGELOG.md:block 39 (paragraph) +msgid "" +"October 8th 2019: 🍂 the fourth draft only patches and fixes minor things for" +" the autumn cleaning" +msgstr "2019年10月8日：🍂第四版草稿僅針對秋季所作的清理修正一些小地方" + +#: ./CHANGELOG.md:block 40 (unordered list) +msgid "Renamed continuous delivery to continuous integration." +msgstr "將「持續交付」改名為「持續整合」。" + +#: ./CHANGELOG.md:block 40 (unordered list) +msgid "Referencing accessibility guidelines in the language standard." +msgstr "在語言標準中引用無障礙指導原則。" + +#: ./CHANGELOG.md:block 40 (unordered list) +msgid "A bunch of style and consistency fixes." +msgstr "改善一些樣式，與一致性修正。" + +#: ./CHANGELOG.md:block 41 (header) +msgid "Version 0.1.2" +msgstr "0.1.2 版" + +#: ./CHANGELOG.md:block 42 (paragraph) +msgid "" +"August 22th 2019: 🌠 the third draft focuses on better text and takes " +"community input" +msgstr "2019年8月22日：🌠第三版草稿專注在提升文字品質，並且納入社群意見" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "With some great new contributors comes a fresh author list." +msgstr "有好幾位很棒的新貢獻者加入我們的作者群名單，讓氣象一新。" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "All links are now HTTPS." +msgstr "所有連結都是 HTTPS。" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "General proofreading, wording clarifications, and smashed typos." +msgstr "一般校對、釐清用字淺詞、修正拼字錯誤等。" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "Updated criteria:" +msgstr "更新準則：" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "Requirement for reuse in different contexts" +msgstr "在不同情境背景下重複使用的規定" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "Recommendation for explicit versioning" +msgstr "明確的版本控制建議" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "Recommendation for multi party development" +msgstr "多方部署的建議" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "Recommendation for license headers in files" +msgstr "檔案授權標頭的建議" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "Recommendation for vulnerability reporting" +msgstr "漏洞回報的建議" + +#: ./CHANGELOG.md:block 43 (unordered list) +msgid "Recommendation for explicit documentation of governance" +msgstr "明確以文件記錄治理方式的建議" + +#: ./CHANGELOG.md:block 44 (header) +msgid "Version 0.1.1" +msgstr "0.1.1 版" + +#: ./CHANGELOG.md:block 45 (paragraph) +msgid "" +"May 9th 2019: 🤔 the second draft fixes a few basic oversights and fixes a " +"lot of typos" +msgstr "2019年5月9日：🤔第二版草稿修正一些基本的疏漏，以及許多拼字錯誤" + +#: ./CHANGELOG.md:block 46 (unordered list) +msgid "" +"Removed references to the Foundation for Public Code, we're going to have to" +" change the name in becoming an association." +msgstr "移除出現「Foundation for Public " +"Code」的地方，我們之後可能必須改名才能成為協會。" + +#: ./CHANGELOG.md:block 46 (unordered list) +msgid "Updated the introduction." +msgstr "更新簡介。" + +#: ./CHANGELOG.md:block 46 (unordered list) +msgid "Updated the glossary." +msgstr "更新詞彙表。" + +#: ./CHANGELOG.md:block 46 (unordered list) +msgid "Added the code of conduct." +msgstr "新增行為守則。" + +#: ./CHANGELOG.md:block 46 (unordered list) +msgid "We've recommended using the publiccode.yml standard for easier reuse." +msgstr "我們建議使用 publiccode.yml 標準，方便重複使用。" + +#: ./CHANGELOG.md:block 47 (header) +msgid "Version 0.1.0" +msgstr "0.1.0 版" + +#: ./CHANGELOG.md:block 48 (paragraph) +msgid "" +"April 16th 2019: 🎉 the first draft is ready, it is all brand new and has " +"snazzy new ideas in it" +msgstr "2019年4月16日：🎉初版草稿已準備就緒，全新內容，而且有許多有趣的新穎理念" + +#: ./CHANGELOG.md:block 49 (unordered list) +msgid "14 criteria with their requirements and how to operationalize them." +msgstr "14 項準則，有各自的規定，以及相關的實施方式。" + +#: ./CHANGELOG.md:block 49 (unordered list) +msgid "" +"An introduction with a high level background, what this standard is, and how" +" the Foundation for Public Code will use it." +msgstr "精要的背景介紹，例如本標準是什麼，以及 Foundation for Public Code " +"如何使用此標準。" + +#: ./CHANGELOG.md:block 50 (paragraph) +msgid "" +"This first version was produced together with the Amsterdam University of " +"Applied Sciences and the City of Amsterdam as a part of the [Smart Cities? " +"Public Code! project](https://smartcities.publiccode.net/)." +msgstr "" +"最初的版本是由阿姆斯特丹應用科學大學、阿姆斯特丹市政府，以及本基金會合作撰寫" +"，取自 [Smart Cities? Public Code! 專案](https://smartcities.publiccode.net/)" +" 的部分內容。" + +#: ./CODE_OF_CONDUCT.md:block 1 (header) +msgid "Code of Conduct" +msgstr "行為守則" + +#: ./CODE_OF_CONDUCT.md:block 3 (paragraph) +msgid "" +"Many community members are from civic or professional environments with " +"behavioral codes yet some individuals are not. This document expresses " +"expectations of all community members and all interactions regardless of " +"communication channel." +msgstr "" +"社群很多成員來自有行為守則的公民社會或專業背景，但有些人並非如此。本文件表達" +"基金會對於所有社群成員，以及所有互動間的期望，無論互動是透過何種溝通管道。" + +#: ./CODE_OF_CONDUCT.md:block 4 (paragraph) +msgid "Be here to collaborate." +msgstr "來到這裡來是為了協作。" + +#: ./CODE_OF_CONDUCT.md:block 5 (paragraph) +msgid "Be considerate, respectful, and patient." +msgstr "請對彼此體貼、尊重，以及有耐心。" + +#: ./CODE_OF_CONDUCT.md:block 6 (paragraph) +msgid "Strive to be as constructive as possible." +msgstr "努力做出有建設性的行為。" + +#: ./CODE_OF_CONDUCT.md:block 7 (paragraph) +msgid "To raise a concern, please email directors@publiccode.net." +msgstr "若有問題需要提出，請寄送電子郵件到 directors@publiccode.net。" + +#: ./CONTRIBUTING.md:block 1 (header) +msgid "Contributing to this standard" +msgstr "貢獻此標準" + +#: ./CONTRIBUTING.md:block 3 (paragraph) +msgid "🙇‍♀️ Thank you for contributing!" +msgstr "🙇‍♀️ 感謝您的貢獻！" + +#: ./CONTRIBUTING.md:block 4 (paragraph) +msgid "" +"We understand that a standard like this can only be set in collaboration " +"with as many public technologists, policy makers and interested folk as " +"possible. Thus we appreciate your input, enjoy feedback and welcome " +"improvements to this project and are very open to collaboration." +msgstr "" +"我們理解這樣的標準，只有在盡可能與公共技術人員、政策制定者，以及有興趣的人士" +"協作下才能完成。因此，我們很感謝您的意見，樂意得到回饋，以及歡迎提供改善此專" +"案的建議。我們非常開放任何合作的機會。" + +#: ./CONTRIBUTING.md:block 5 (paragraph) +msgid "" +"We love issues and pull requests from everyone. If you're not comfortable " +"with GitHub, you can email use your feedback at " +"[info@publiccode.net](mailto:info@publiccode.net)." +msgstr "" +"我們歡迎每個人提出的議題，以及拉取請求。如果您不大習慣 GitHub ，" +"也歡迎將意見回饋用電子郵件寄送到 [info@publiccode.net](mailto:info@publiccode" +".net)。" + +#: ./CONTRIBUTING.md:block 6 (header) +msgid "Problems, suggestions and questions in issues" +msgstr "問題、建議與議題等" + +#: ./CONTRIBUTING.md:block 7 (paragraph) +msgid "" +"A high-level overview of the development that we already have sketched out " +"can be seen in the [roadmap](/docs/roadmap.md). Please help development by " +"reporting problems, suggesting changes and asking questions. To do this, you" +" can [create a GitHub issue](https://docs.github.com/en/issues/tracking-" +"your-work-with-issues/creating-an-issue) for this project in the [GitHub " +"Issues for the Standard for Public " +"Code](https://github.com/publiccodenet/standard/issues)." +msgstr "" +"在[發展路線圖](/docs/roadmap.md)中可查看我們勾勒的精要概覽。歡迎回報問題、建" +"議修改，以及發問等，來協助發展。您可以到 [Standard for Public Code 的 GitHub " +"Issue](https://github.com/publiccodenet/standard/issues) 頁面中，為本專案[" +"提出 GitHub 議題](https://docs.github.com/en/issues/" +"tracking-your-work-with-issues/creating-an-issue)。" + +#: ./CONTRIBUTING.md:block 8 (paragraph) +msgid "" +"Or, sign up to the [mailing " +"list](https://lists.publiccode.net/mailman/postorius/lists/standard.lists.publiccode.net/)" +" and send an email to " +"[standard@lists.publiccode.net](mailto:standard@lists.publiccode.net)." +msgstr "" +"或者，註冊加入[郵遞論壇列表](https://lists.publiccode.net/mailman/postorius/" +"lists/standard.lists.publiccode.net/)，並寄送電子郵件到[standard@lists." +"publiccode.net](mailto:standard@lists.publiccode.net)。" + +#: ./CONTRIBUTING.md:block 9 (paragraph) +msgid "" +"You don't need to change any of our code or documentation to be a " +"contributor!" +msgstr "您不一定要修改我們的程式碼或文件，也能成為貢獻者！" + +#: ./CONTRIBUTING.md:block 10 (header) +msgid "Documentation and code in pull requests" +msgstr "為文件與程式碼提出拉取請求" + +#: ./CONTRIBUTING.md:block 11 (paragraph) +msgid "" +"If you want to add to the documentation or code of one of our projects you " +"should make a pull request." +msgstr "如果您想要在我們的專案中，為文件或程式碼加入新內容，您應該提出拉取請求 (Pull " +"Request，亦可簡稱 PR)。" + +#: ./CONTRIBUTING.md:block 12 (paragraph) +msgid "" +"If you never used GitHub, get up to speed with [Understanding the GitHub " +"flow](https://docs.github.com/en/get-started/quickstart/github-flow) or " +"follow one of the great free interactive courses in [GitHub " +"Skills](https://skills.github.com/) on working with GitHub and working with " +"MarkDown, the syntax this project's documentation is in." +msgstr "" +"若您從未使用過 GitHub，歡迎先[認識 GitHub 作業流程](https://docs.github.com/" +"en/get-started/quickstart/github-flow)，或是參加 [GitHub " +"Skills](https://skills.github.com/) 免費且優質的互動式課程，" +"當中會介紹該如何使用 GitHub 以及 MarkDown 語法。MarkDown " +"是本專案文件所採用的撰寫語法。" + +#: ./CONTRIBUTING.md:block 13 (paragraph) +msgid "" +"This project is licensed Creative Commons Zero v1.0 Universal, which " +"essentially means that the project, along with your contributions is in the " +"public domain in whatever jurisdiction possible, and everyone can do " +"whatever they want with it." +msgstr "" +"本專案採用創用CC 0 1.0 通用式公眾領域貢獻宣告給予授權；這本質上代表本專案，以" +"及您所做出的貢獻，在無論何種司法管轄情況下，都屬於公眾領域，也就是任何人都可" +"以任意使用。" + +#: ./CONTRIBUTING.md:block 14 (header) +msgid "1. Make your changes" +msgstr "1. 作出您的修改" + +#: ./CONTRIBUTING.md:block 15 (paragraph) +msgid "" +"Contributions should [follow](docs/standard-for-public-code.html) the " +"requirements set out in the criteria of the Standard for Public code itself." +" Reviewers will also be ensuring that contributions are aligned with the " +"[values of public code](foreword.md#values-of-public-code). Furthermore, " +"they will review that the contribution conforms to the " +"[standards](#standards-to-follow) and remains coherent with the overall " +"work." +msgstr "" +"貢獻內容應該[遵守](docs/standard-for-public-code.html)《公共程式標準》自身所" +"列出的準則規定。審查人員同時也會確保貢獻內容，符合[公共程式的價值](foreword." +"md#values-of-public-code)。此外，他們也會審查貢獻是否遵循[標準](#standards-" +"to-follow)，且與整體作品有所連貫。" + +#: ./CONTRIBUTING.md:block 16 (paragraph) +msgid "" +"This project uses the [GitFlow branching model and " +"workflow](https://nvie.com/posts/a-successful-git-branching-model/). When " +"you've forked this repository, please make sure to create a feature branch " +"following the GitFlow model." +msgstr "" +"本專案使用 [GitFlow 分支與工作流程](https://nvie.com/posts/" +"a-successful-git-branching-model/)。當您對此儲存庫作分支以後，請務必依照 " +"GitFlow 模型建立新功能分支。" + +#: ./CONTRIBUTING.md:block 17 (paragraph) +msgid "" +"Add your changes in commits [with a message that explains " +"them](https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-" +"message). If more than one type of change is needed, group logically related" +" changes into separate commits. For example, white-space fixes could be a " +"separate commit from text content changes. When adding new files, select " +"file formats that are easily viewed in a `diff`, for instance, `.svg` is " +"preferable to a binary image. Document choices or decisions you make in the " +"commit message, this will enable everyone to be informed of your choices in " +"the future." +msgstr "" +"將您所作的變更內容加入送交版次，[並附上內容說明](https://robots.thoughtbot." +"com/5-useful-tips-for-a-better-commit-message)。如果需要作出多種類型的變更，" +"請將相關變更依據邏輯分類，不同類型各自放在不同的送交版次中。例如：修正空白、" +"以及文字內容更動，兩者應該放在不同的送交版次中。當新增檔案時，請選用容易以「`" +"diff` 」檢視的檔案格式，如「`.svg` 」格式就勝過二進位影像。在送交版次訊息中，" +"請記錄您所作的選擇與決策，如此未來其他人都能知道您當時的抉擇。" + +#: ./CONTRIBUTING.md:block 18 (paragraph) +msgid "" +"If you are adding code, make sure you've added and updated the relevant " +"documentation and tests before you submit your pull request. Make sure to " +"write tests that show the behavior of the newly added or changed code." +msgstr "如果您是要新增程式碼，請確保您有新增與更新相關文件與測試項目，之後再提交您的" +"拉取請求。請務必撰寫可以展示新增或修改後程式碼行為的測試項目。" + +#: ./CONTRIBUTING.md:block 19 (header) +msgid "Applicable policy" +msgstr "適用政策" + +#: ./CONTRIBUTING.md:block 20 (paragraph) +msgid "" +"Currently, the Standard for Public Code is not implementing any specific " +"public policy." +msgstr "就目前而言，《公共程式標準》並非在執行任何特定的公共政策。" + +#: ./CONTRIBUTING.md:block 21 (header) +msgid "Style" +msgstr "風格" + +#: ./CONTRIBUTING.md:block 22 (paragraph) +msgid "" +"The Standard for Public Code aims to [use plain English](criteria/use-plain-" +"english.md) and we have chosen American English for spelling. Text content " +"should typically follow one line per sentence, with no line-wrap, in order " +"to make `diff` output easier to view. However, we want to emphasize that it " +"is more important that you make your contribution than worry about spelling " +"and typography. We will help you get it right in our review process and we " +"also have a separate quality check before [making a new " +"release](docs/releasing.md)." +msgstr "" +"《公共程式標準》目標[使用白話的英語](criteria/use-plain-english.md)，而拼字採" +"用美式英文。文字內容基本上以每句一行為原則，沒有文繞圖換行，來讓「`diff`」輸" +"出更容易檢視。然而，我們想要強調更重要的是，您應該專注在貢獻內容上，而不是擔" +"心拼字與排版。我們的審查流程會協助修正這一部分，也會另外再次檢查品質才[推出新" +"發行版本](docs/releasing.md)。" + +#: ./CONTRIBUTING.md:block 23 (header) +msgid "Standards to follow" +msgstr "遵守的標準" + +#: ./CONTRIBUTING.md:block 24 (paragraph) +msgid "" +"These are the standards that the Standard for Public Code uses. Please make " +"sure that your contributions are aligned with them so that they can be " +"merged more easily." +msgstr "這些是《公共程式標準》所採用的標準。請確保您的貢獻內容也遵守這些標準，才會更" +"容易合併。" + +#: ./CONTRIBUTING.md:block 25 (unordered list) +msgid "" +"[IETF RFC 2119](https://tools.ietf.org/html/rfc2119) - for requirement level" +" keywords" +msgstr "[IETF RFC 2119](https://tools.ietf.org/html/rfc2119) - 要求等級關鍵字" + +#: ./CONTRIBUTING.md:block 25 (unordered list) +msgid "" +"[Web Content Accessibility Guidelines " +"2.1](https://www.w3.org/TR/WCAG21/#readable) - for readability" +msgstr "[網頁內容可近用無障礙指引 2.1](https://www.w3.org/TR/WCAG21/#readable) - " +"易讀性" + +#: ./CONTRIBUTING.md:block 26 (header) +msgid "2. Pull request" +msgstr "2. 拉取請求" + +#: ./CONTRIBUTING.md:block 27 (paragraph) +msgid "" +"When submitting the pull request, please accompany it with a description of " +"the problem you are trying to solve and the issue number that this pull " +"request fixes. It is preferred for each pull request to address a single " +"issue where possible. In some cases a single set of changes may address " +"multiple issues, in which case be sure to list all issue numbers fixed." +msgstr "" +"當您提出拉取請求時，請隨附描述您想要解決的問題，以及該拉取請求所能修正的議題" +"編號。以一個拉取請求處理單一項議題為佳。若一組變動能同時解決多項議題，則請列" +"出所有能一併修正的議題編號。" + +#: ./CONTRIBUTING.md:block 28 (header) +msgid "3. Improve" +msgstr "3. 改善" + +#: ./CONTRIBUTING.md:block 29 (paragraph) +msgid "" +"All contributions have to be reviewed by someone. The Foundation for Public " +"Code has committed to make sure that maintainers are available to review " +"contributions with an aim to provide feedback within two business days." +msgstr "" +"所有貢獻都必須接受審查。Foundation for Public Code " +"致力於確保有維護人員能審查貢獻內容，目標是在兩個工作日內提供意見回饋。" + +#: ./CONTRIBUTING.md:block 30 (paragraph) +msgid "" +"It could be that your contribution can be merged immediately by a " +"maintainer. However, usually, a new pull request needs some improvements " +"before it can be merged. Other contributors (or helper robots) might have " +"feedback. If this is the case the reviewing maintainer will help you improve" +" your documentation and code." +msgstr "" +"維護人員有時候可以立即合併您的貢獻內容。不過一般來說，新的拉取請求通常需要再" +"經過改善後，才能夠合併。其他貢獻者（或是輔助用機器人）可能會提供意見回饋。若" +"是如此，負責審查您貢獻內容的維護人員，將協助您改善文件與程式碼。" + +#: ./CONTRIBUTING.md:block 31 (paragraph) +msgid "If your documentation and code have passed human review, it is merged." +msgstr "一旦您的文件與程式碼通過人工審查，就會合併。" + +#: ./CONTRIBUTING.md:block 32 (header) +msgid "4. Celebrate" +msgstr "4. 慶祝" + +#: ./CONTRIBUTING.md:block 33 (paragraph) +msgid "" +"Your ideas, documentation and code have become an integral part of this " +"project. You are the open source hero we need!" +msgstr "您的構想、文件與程式碼，已成為本專案的一部份。您就是我們需要的開放原始碼英雄" +"！" + +#: ./CONTRIBUTING.md:block 34 (paragraph) +msgid "" +"In fact, feel free to open a pull request to add your name to the " +"[`AUTHORS`](AUTHORS.md) file and get eternal attribution." +msgstr "誠摯歡迎您提出拉取請求，將您的名字加到 [`AUTHORS`](AUTHORS.md) " +"檔案中，讓您所做的貢獻能銘記在本專案中。" + +#: ./CONTRIBUTING.md:block 35 (header) +msgid "Translations in other languages" +msgstr "翻譯成其他語言" + +#: ./CONTRIBUTING.md:block 36 (paragraph) +msgid "" +"While the Standard does not have any official translations, you can help " +"maintain existing and add new [community translations of the " +"Standard](https://github.com/publiccodenet/community-translations-standard)." +msgstr "" +"《公共程式標準》沒有官方版本的翻譯，您仍可以協助本標準維護已有的[社群翻譯](ht" +"tps://github.com/publiccodenet/community-translations-" +"standard)，或是新增翻譯。" + +#: ./CONTRIBUTING.md:block 37 (header) +msgid "Releases" +msgstr "發行版本" + +#: ./CONTRIBUTING.md:block 38 (paragraph) +msgid "" +"We have dedicated documentation for creating [new " +"releases](/docs/releasing.md) and [ordering printed " +"standards](/docs/printing.md)." +msgstr "我們有提供[發行新版本](/docs/releasing.md)，與[訂購印刷版標準](/docs/printing" +".md)的專用詳細文件。" + +#: ./CONTRIBUTING.md:block 39 (paragraph) +msgid "" +"For more information on how to use and contribute to this project, please " +"read the [`README`](README.md)." +msgstr "若要進一步瞭解如何使用，以及協助貢獻本專案，請參閱 [`README `](README.md)。" + +#: ./GOVERNANCE.md:block 2 (header) +msgid "" +"SPDX-FileCopyrightText: 2019-2022 The Foundation for Public Code " +"[info@publiccode.net](mailto:info@publiccode.net), " +"https://standard.publiccode.net/AUTHORS" +msgstr "" +"SPDX-FileCopyrightText: 2019-2022 Foundation for Public Code[info@publiccode." +"net](mailto:info@publiccode.net), https://standard.publiccode.net/AUTHORS" + +#: ./GOVERNANCE.md:block 3 (header) +msgid "Governance" +msgstr "治理方式" + +#: ./GOVERNANCE.md:block 4 (paragraph) +msgid "" +"This standard lies at the core of the codebase stewardship provided by the " +"[Foundation for Public Code](https://publiccode.net/). We decide if a " +"codebase is ready for community co-development based on this document." +msgstr "" +"本標準是 [Foundation for Public Code](https://publiccode.net/) 在為程式基底提" +"供督導時的核心。我們依照這份文件來判斷，某個程式基底是否已經準備好讓社群共同" +"參與開發。" + +#: ./GOVERNANCE.md:block 5 (paragraph) +msgid "The standard is maintained by Foundation for Public Code staff." +msgstr "這份標準由 Foundation for Public Code 職員負責維護。" + +#: ./GOVERNANCE.md:block 6 (paragraph) +msgid "" +"[We welcome contributions, such as suggestions for changes or general " +"feedback, from anyone.](/CONTRIBUTING.md)" +msgstr "[我們歡迎任何人貢獻，例如提供修改建議，或是給予一般意見回饋等。](/CONTRIBUTIN" +"G.md)" + +#: ./GOVERNANCE.md:block 7 (paragraph) +msgid "" +"Because of the important role that the Standard for Public Code has in our " +"core process we require the highest standards from the Standard." +msgstr "由於《公共程式標準》在我們的核心流程中，扮演至關重要的角色，所以我們會以《公" +"共程式標準》的最高標準作要求。" + +#: ./GOVERNANCE.md:block 8 (paragraph) +msgid "" +"We will try to respond promptly to all pull requests. The pull request is an" +" opportunity to work together to improve our methods and the Standard. We " +"may not accept all changes, but we will explain our logic." +msgstr "" +"我們會努力儘速回覆所有拉取請求。拉取請求使我們有機會一起合作，來改善我們的方" +"法與這份標準。我們有可能不會接受貢獻者提出的所有修改，而我們會解釋背後的邏輯" +"。" + +#: ./README.md:block 1 (header) +msgid "Standard for Public Code" +msgstr "公共程式標準" + +#: ./README.md:block 3 (paragraph) +msgid "" +"The Standard for Public Code gives public organizations a model for " +"preparing open source solutions to enable collaborations with similar public" +" organizations in other places. It includes guidance for policy makers, city" +" administrators, developers and vendors." +msgstr "" +"《公共程式標準》提供公家機關一套準備開放原始碼解決方案的模型，讓他們能與其他" +"地方相似的公家機關協作。該標準包含給政策制定者、市行政官、開發人員與供應商的" +"指引。" + +#: ./README.md:block 4 (paragraph) +msgid "" +"![version 0.7.0](assets/version-badge.svg) [![License: " +"CC0-1.0](https://img.shields.io/badge/License-" +"CC0_1.0-lightgrey.svg)](http://creativecommons.org/publicdomain/zero/1.0/)" +msgstr "" +"![0.7.0版](assets/version-badge.svg) " +"[![授權：CC0-1.0](https://img.shields.io/badge/License-" +"CC0_1.0-lightgrey.svg)](http://creativecommons.org/publicdomain/zero/1.0/)" + +#: ./README.md:block 5 (paragraph) +msgid "" +"[![pages-build-" +"deployment](https://github.com/publiccodenet/standard/actions/workflows/pages/pages-" +"build-" +"deployment/badge.svg)](https://github.com/publiccodenet/standard/actions/workflows/pages/pages-" +"build-deployment) " +"[![Test](https://github.com/publiccodenet/standard/actions/workflows/test.yml/badge.svg)](https://github.com/publiccodenet/standard/actions/workflows/test.yml)" +" [![standard main badge](https://publiccodenet.github.io/publiccodenet-url-" +"check/badges/standard.publiccode.net.svg)](https://publiccodenet.github.io/publiccodenet-" +"url-check/standard.publiccode.net-url-check-look.json) [![standard develop " +"badge](https://publiccodenet.github.io/publiccodenet-url-" +"check/badges/standard.publiccode.net-" +"develop.svg)](https://publiccodenet.github.io/publiccodenet-url-" +"check/standard.publiccode.net-develop-url-check-look.json)" +msgstr "" +"[![pages-build-deployment](https://github.com/publiccodenet/standard/actions/" +"workflows/pages/pages-build-deployment/badge.svg)](https://github.com/" +"publiccodenet/standard/actions/workflows/pages/pages-build-deployment) " +"[![測試](https://github.com/publiccodenet/standard/actions/workflows/test." +"yml/badge.svg)](https://github.com/publiccodenet/standard/actions/workflows/" +"test.yml) [![standard main badge](https://publiccodenet.github.io/" +"publiccodenet-url-check/badges/standard.publiccode.net." +"svg)](https://publiccodenet.github.io/publiccodenet-url-check/standard." +"publiccode.net-url-check-look.json) [![standard develop " +"badge](https://publiccodenet.github.io/publiccodenet-url-check/badges/" +"standard.publiccode.net-develop.svg)](https://publiccodenet.github.io/" +"publiccodenet-url-check/standard.publiccode.net-develop-url-check-look.json)" + +#: ./README.md:block 6 (paragraph) +msgid "" +"The Standard for Public Code is in a draft format. We are preparing it for a" +" version 1.0 release. Currently, we are testing it on a small number of " +"codebases." +msgstr "《公共程式標準》目前為草稿階段。我們正在準備發行 1.0 " +"版，目前仍在幾個程式基底中作測試。" + +#: ./README.md:block 7 (header) +msgid "Applying the Standard for Public Code to your codebase" +msgstr "將《公共程式標準》套用到您的程式基底" + +#: ./README.md:block 8 (paragraph) +msgid "" +"If you want to apply the Standard for Public Code to your codebase, just go " +"ahead, it's an open standard and free for anyone to use. To see how ready " +"your codebase is, you can do a quick [eligibility self " +"assessment](https://publiccodenet.github.io/assessment-eligibility) that " +"will give you a rough idea of how much work you may need to do to meet all " +"criteria." +msgstr "" +"若您想要將《公共程式標準》套用到您的程式基底，就請放心去做，因為它是人人都能" +"自由採用的開放標準。若要瞭解您程式基底所達成的程度，可以做[自我資格評估](http" +"s://publiccodenet.github.io/assessment-" +"eligibility)；它能幫助您大略瞭解，如果想要滿足所有準則，還需要下多少功夫。" + +#: ./README.md:block 9 (paragraph) +msgid "" +"The standard *should* be mostly self-explanatory in how to apply it to your " +"codebase. If anything in the standard is unclear, we encourage you to open " +"an issue here so that we can help you and anyone else who feels the same as " +"you. For inspiration, look at the [community built implementation " +"guide](https://publiccodenet.github.io/community-implementation-guide-" +"standard/) which contains examples and other tips." +msgstr "" +"本標準 *應該* 足以自我解釋要如何套用到您的程式基底中。若標準中有任何不明確的" +"地方，我們鼓勵您在此開立議題，來讓我們能協助您以及其他與您抱持同樣看法的人。" +"如果需要一點靈感啟發，請參閱[社群製作的《實踐指引》](https://publiccodenet." +"github.io/community-implementation-guide-standard/)，其中包括範例與其他提示。" + +#: ./README.md:block 10 (paragraph) +msgid "" +"If there are any breaking changes in a new version of the Standard for " +"Public Code, the codebase stewards at the Foundation for Public Code will " +"help any implementers of the standard understand how the gaps can be closed." +msgstr "" +"若新版的《公共程式標準》有任何導致過去作法不再適用的改動，則 Foundation for " +"Public Code 的程式基底執事人員，會協助標準的實踐者理解該如何銜接之間的落差。" + +#: ./README.md:block 11 (paragraph) +msgid "" +"If you want to commit your codebase to become fully compliant to the " +"standard for future certification, please contact us at " +"[info@publiccode.net](mailto:info@publiccode.net) to initiate a formal " +"[assessment](https://about.publiccode.net/activities/codebase-" +"stewardship/lifecycle-diagram.html#assessment)." +msgstr "" +"若您致力讓您的程式基底完全遵循此標準，並想在未來能取得認證，請寫信與我們聯繫" +"：[info@publiccode.net](mailto:info@publiccode." +"net)，以展開正式[評估](https://about.publiccode.net/activities/" +"codebase-stewardship/lifecycle-diagram.html#assessment)。" + +#: ./README.md:block 12 (header) +msgid "Request for contributions" +msgstr "徵求貢獻" + +#: ./README.md:block 13 (paragraph) +msgid "" +"We believe public policy and software should be inclusive, usable, open, " +"legible, accountable, accessible and sustainable. This means we need a new " +"way of designing, developing and procuring both the source code and policy " +"documentation." +msgstr "" +"我們相信公共政策與公共軟體，應該具備涵容、好用、開放、易懂、課責、近用、永續" +"等特質。這代表我們需要一種新的方式，來設計、開發，以及付出心力育成原始碼和政" +"策文件。" + +#: ./README.md:block 14 (paragraph) +msgid "" +"This standard sets a quality level for codebases that meets the needs of " +"public organizations, institutions and administrations as well as other " +"critical infrastructural services." +msgstr "本標準為程式基底設立品質檢核水準，使其能滿足公家機關、社會機構、行政單位，以" +"及其他重大基礎設施服務的需求。" + +#: ./README.md:block 15 (paragraph) +msgid "" +"The standard lives at " +"[standard.publiccode.net](https://standard.publiccode.net/). See " +"[`index.md`](index.md) for an overview of all content." +msgstr "" +"本標準放在線上：[standard.publiccode.net](https://standard.publiccode.net/)。" +"請參閱 [`index.md`](index.md) 查看整體內容概覽。" + +#: ./README.md:block 16 (paragraph) +msgid "" +"[![Thumbnail for the video on the Standard for Public Code: a printed " +"version lying on a table between two " +"hands](https://img.youtube.com/vi/QWt6vB-" +"cipE/mqdefault.jpg)](https://www.youtube.com/watch?v=QWt6vB-cipE)" +msgstr "" +"[![《公共程式標準》的影片縮圖：兩隻手中間放著本標準的印刷本](https://img." +"youtube.com/vi/QWt6vB-cipE/mqdefault.jpg)](https://www.youtube.com/watch?v" +"=QWt6vB-cipE)" + +#: ./README.md:block 17 (paragraph) +msgid "" +"[A video introduction to Standard for Public " +"Code](https://www.youtube.com/watch?v=QWt6vB-cipE) from Creative Commons " +"Global Summit 2020 (4:12) on YouTube." +msgstr "" +"[《公共程式標準》的影片介紹](https://www.youtube.com/watch?v=QWt6vB-cipE)，" +"出自 Creative Commons Global Summit 2020 (4:12)，放在 YouTube 上。" + +#: ./README.md:block 18 (header) +msgid "Help improve this standard" +msgstr "幫忙改善這份標準" + +#: ./README.md:block 19 (paragraph) +msgid "" +"The Foundation for Public Code is committed to maintaining and developing " +"the Standard for Public Code at a level of quality that meets the standard " +"itself." +msgstr "Foundation for Public Code " +"致力於維護與開發《公共程式標準》，且使其同時符合該標準自身的品質水準。" + +#: ./README.md:block 20 (paragraph) +msgid "" +"We are looking for people like you to [contribute](CONTRIBUTING.md) to this " +"project by suggesting improvements and helping develop it. 😊 Get started by " +"reading our [contributors guide](CONTRIBUTING.md). Since it is such a core " +"document we will accept contributions when they add significant value. We've" +" described how we govern the standard in the [governance " +"statement](GOVERNANCE.md)." +msgstr "" +"我們正在尋找像您這樣的人，能對此專案做出[貢獻](CONTRIBUTING.md)，像是建議改善" +"方向，以及協助開發等。😊若要開始，請先參閱我們的[貢獻者指引](CONTRIBUTING.md)" +"。由於這是相當核心的文件，我們僅接受能帶來重大價值的貢獻。[治理方式聲明](GOVE" +"RNANCE.md)中有說明管理該標準的方式。" + +#: ./README.md:block 21 (paragraph) +msgid "" +"Please note that this project is released with a [code of " +"conduct](CODE_OF_CONDUCT.md). By participating in this project you agree to " +"abide by its terms. Please be lovely to all other community members." +msgstr "" +"請注意，本專案配合[行為守則](CODE_OF_CONDUCT." +"md)一同發行。如果要參加本專案，代表您同意遵守守則。請善待社群的所有其他成員。" + +#: ./README.md:block 22 (header) +msgid "Preview, build and deploy" +msgstr "預覽、建置、部署" + +#: ./README.md:block 23 (paragraph) +msgid "" +"The repository builds to a static site deployed at " +"[standard.publiccode.net](https://standard.publiccode.net/). It is built " +"with [GitHub pages](https://pages.github.com) and " +"[Jekyll](https://jekyllrb.com/)." +msgstr "" +"儲存庫會建置一個靜態網站，並部署至 [standard.publiccode.net](https://standard" +".publiccode.net/)。網站採用 [GitHub 頁面](https://pages.github.com) 與 " +"[Jekyll](https://jekyllrb.com/) 技術。" + +#: ./README.md:block 24 (paragraph) +msgid "" +"The content is made to be built with [Jekyll](http://jekyllrb.com/), which " +"means you will need ruby and ruby-bundler installed, for example:" +msgstr "" +"網站內容透過 [Jekyll](http://jekyllrb.com/) 技術建置。這代表您需要有安裝 " +"ruby 與 ruby-bundler，例如：" + +#: ./README.md:block 26 (paragraph) +msgid "" +"If `ruby` and `bundle` are installed, one can run `bundle install` after " +"which the site can be rendered with the `script/serve.sh` script." +msgstr "" +"一旦安裝好 `ruby` 與 `bundle` 後，就可以執行 `bundle install`，接著再利用 `" +"script/serve.sh` 命令稿轉譯呈現出網站成果。" + +#: ./README.md:block 27 (header) +msgid "Testing" +msgstr "測試" + +#: ./README.md:block 28 (paragraph) +msgid "" +"A variety of test scripts are included. The script `script/test-all.sh` " +"wraps running of all local tests." +msgstr "本專案內含許多測試命令稿。其中 `script/test-all.sh` " +"命令稿則統包執行所有本機測試。" + +#: ./README.md:block 29 (paragraph) +msgid "" +"See the scripts in the " +"[script](https://github.com/publiccodenet/standard/tree/main/script) folder." +msgstr "" +"請前往 [script](https://github.com/publiccodenet/standard/tree/main/script) " +"資料夾查看命令稿。" + +#: ./README.md:block 30 (header) +msgid "Generating a PDF of the Standard for Public Code" +msgstr "生成《公共程式標準》的 PDF 檔案" + +#: ./README.md:block 31 (paragraph) +msgid "" +"In addition to Jekyll, generating PDFs relies upon " +"[Weasyprint](https://weasyprint.org/) and " +"[QPDF](https://github.com/qpdf/qpdf). [Pandoc](https://pandoc.org/) can be " +"used to transform PDFs into `.epub`." +msgstr "" +"除了先前提到的 Jekyll 以外，想生成 PDF 檔，還需要依賴 " +"[Weasyprint](https://weasyprint.org/) 和 [QPDF](https://github.com/qpdf/" +"qpdf)。[Pandoc](https://pandoc.org/) 則可將 PDF 檔轉換成 `.epub` 檔。" + +#: ./README.md:block 32 (paragraph) +msgid "" +"To generate these kinds of files, the dependencies should be installed, for " +"example:" +msgstr "若要生成這類檔案，則應該要安裝依賴的軟體項目，例如：" + +#: ./README.md:block 34 (paragraph) +msgid "" +"The file `standard-print.html` can be converted to a nice looking PDF, along" +" with the other release files, using:" +msgstr "使用以下命令稿，可以將 `standard-print.html` 檔案轉換成美觀的 PDF " +"檔，同時包括其他發行用的檔案：" + +#: ./README.md:block 36 (header) +msgid "License" +msgstr "授權" + +#: ./README.md:block 37 (paragraph) +msgid "© [The authors and contributors](AUTHORS.md)" +msgstr "© [作者與貢獻者](AUTHORS.md)" + +#: ./README.md:block 38 (paragraph) +msgid "" +"The standard is [licensed](LICENSE) under CC 0, which also applies to all " +"illustrations and the documentation. This means anyone can do anything with " +"it. If you contribute you also grant these rights to others. You can read " +"more about how to help in the [contributing guide](CONTRIBUTING.md)." +msgstr "" +"本標準採用 CC0 " +"公眾領域貢獻宣告[給予授權](LICENSE)，該授權範圍涵蓋所有插圖與文件。CC0 代表任" +"何人都能任意使用這些內容。如果您是貢獻者，代表您也將這些權利賦予他人。若要進" +"一步瞭解如何協助本專案，請參閱〈[貢獻指引](CONTRIBUTING.md)〉。" + +#: ./criteria/bundle-policy-and-source-code.md:block 3 (paragraph) +msgid "order: 2 redirect_from:" +msgstr "order: 2 redirect_from:" + +#: ./criteria/bundle-policy-and-source-code.md:block 4 (unordered list) +msgid "criteria/bundle-policy-and-code" +msgstr "criteria/bundle-policy-and-code" + +#: ./criteria/bundle-policy-and-source-code.md:block 5 (header) +msgid "Bundle policy and source code" +msgstr "政策與原始碼要合捆" + +#: ./criteria/bundle-policy-and-source-code.md:block 6 (paragraph) +msgid "" +"Access to both [source code](../glossary.md#source-code) and " +"[policy](../glossary.md#policy) documentation provides building blocks for " +"anyone to implement the codebase in their local context or contribute to the" +" further development of the [codebase](../glossary.md#codebase)." +msgstr "" +"對於想根據所在情境實作程式基底的人，或是想更進一步貢獻[程式基底](../glossary." +"md#codebase)開發的人來說，能同時取用[原始碼](../glossary.md#source-" +"code)與[政策](../glossary.md#policy)文件兩者，可作為建置成品時的基礎組件。" + +#: ./criteria/bundle-policy-and-source-code.md:block 7 (paragraph) +msgid "" +"Understanding the domain and policies within that domain is fundamental to " +"understanding what problems a codebase is trying to solve and how it sets " +"out to solve them." +msgstr "瞭解作用範疇與該範疇的政策是基本原則，才能瞭解程式基底試圖想解決的問題是什麼" +"，以及該如何解決這些問題的作法。" + +#: ./criteria/bundle-policy-and-source-code.md:block 8 (paragraph) +msgid "" +"To be able to evaluate whether to implement a codebase in a new context, an " +"organization needs to understand what process changes it must choose to make" +" or how to contribute additional configurability to the existing solution in" +" order to adapt it to the new context." +msgstr "" +"為了評估是否需要在新的情境中實作程式基底，組織單位需要瞭解必須做出改變的程序" +"有哪些，或是如何對現有解決方案付出額外調整設定，以適應新的情境背景。" + +#: ./criteria/bundle-policy-and-source-code.md:block 9 (header) +msgid "Requirements" +msgstr "需求規定" + +#: ./criteria/bundle-policy-and-source-code.md:block 10 (unordered list) +msgid "The codebase MUST include the policy that the source code is based on." +msgstr "程式基底「必須」包含原始碼所根據的政策。" + +#: ./criteria/bundle-policy-and-source-code.md:block 10 (unordered list) +msgid "" +"If a policy is based on source code, that source code MUST be included in " +"the codebase, unless used for fraud detection." +msgstr "如果政策根據原始碼而來，則該原始碼「必須」包含在程式基底中，用於偵測詐騙的原" +"始碼則可除外。" + +#: ./criteria/bundle-policy-and-source-code.md:block 10 (unordered list) +msgid "Policy SHOULD be provided in machine readable and unambiguous formats." +msgstr "政策「應該」採用機器可讀且明確的格式。" + +#: ./criteria/bundle-policy-and-source-code.md:block 10 (unordered list) +msgid "" +"[Continuous integration](../glossary.md#continuous-integration) tests SHOULD" +" validate that the source code and the policy are executed coherently." +msgstr "[持續整合](../glossary.md#continuous-" +"integration)測試「應該」驗證原始碼與政策是否有一致執行。" + +#: ./criteria/bundle-policy-and-source-code.md:block 11 (header) +msgid "How to test" +msgstr "測試方式" + +#: ./criteria/bundle-policy-and-source-code.md:block 12 (unordered list) +msgid "" +"Confirm with a civil servant that all policy that the source code is based " +"on is included." +msgstr "與公務人員確認原始碼所根據的所有政策內容都有收錄在內。" + +#: ./criteria/bundle-policy-and-source-code.md:block 12 (unordered list) +msgid "" +"Confirm with a civil servant that all source code that the policy is based " +"on is included." +msgstr "與公務人員確認政策所根據的所有原始碼都有收錄在內。" + +#: ./criteria/bundle-policy-and-source-code.md:block 12 (unordered list) +msgid "Check if policy can be interpreted by a machine." +msgstr "確認政策內容是否能在機器上解讀。" + +#: ./criteria/bundle-policy-and-source-code.md:block 12 (unordered list) +msgid "" +"Check the continuous integration tests for coherent execution of source code" +" and policy pass." +msgstr "確認原始碼與政策間的執行一致性能通過持續整合測試。" + +#: ./criteria/bundle-policy-and-source-code.md:block 13 (header) +msgid "Public policy makers: what you need to do" +msgstr "公共政策制定者：需要的工作" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Collaborate with developers and designers to make sure there is no mismatch " +"between policy code and source code." +msgstr "與開發人員及設計師合作，確保政策法規與原始碼之間沒有不相符之處。" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Provide the relevant policy texts for inclusion in the " +"[repository](../glossary.md#repository); if the text is not available in " +"English, also provide an English summary. Be sure to include standards that " +"your organization has chosen to adhere to and any organizational processes " +"which impact the development or the deployment context of the codebase for " +"your organization." +msgstr "" +"提供相關政策內文，以便收錄於[儲存庫](../glossary.md#repository)中；如果政策內" +"文沒有英文版，請提供英文版摘要。務必也同時包含貴組織單位所選擇遵守的各項標準" +"，以及影響貴組織單位程式基底開發或部署情境的任何組織單位流程。" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "Provide references and links to texts which support the policies." +msgstr "請提供政策相關參考資料與連結。" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Document policy in formats that are unambiguous and machine-readable, such " +"as those published by the [Object Management " +"Group](https://www.omg.org/spec/)." +msgstr "政策內容請使用明確且機器可讀的格式，像是[物件管理群體](https://www.omg.org/" +"spec/)所發表的格式。" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Track policy with [the same version control](maintain-version-control.md) " +"and documentation used to track source code." +msgstr "追蹤政策時，請使用與追蹤原始碼[相同的版本控制](maintain-version-control." +"md)與文件。" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Check in regularly to understand how the source code in the codebase has " +"changed and whether it still matches the [intentions of the " +"policy](document-codebase-objectives.md)." +msgstr "定期檢查，瞭解程式基底中的原始碼如何變動，以及是否仍然符合[政策意圖" +"](document-codebase-objectives.md)。" + +#: ./criteria/bundle-policy-and-source-code.md:block 14 (unordered list) +msgid "" +"Include relevant policies which impact the community, codebase, and " +"development, including legal obligations like the [General Data Protection " +"Regulation](https://eur-lex.europa.eu/eli/reg/2016/679/oj) or the [EU Web " +"Accessibility Directive](https://ec.europa.eu/digital-single-market/en/web-" +"accessibility), or human rights policies, like a public organization's " +"commitment to equal opportunity." +msgstr "" +"納入會影響社會群體、程式基底與開發目標的相關政策，包含 [GDPR " +"一般資料保護規則](https://eur-lex.europa.eu/eli/reg/2016/679/" +"oj)或是[歐盟網頁無障礙命令](https://ec.europa.eu/digital-single-market/en/" +"web-accessibility)等此類法律義務，或者是人權政策，例如公家機關對機會平等的承" +"諾等。" + +#: ./criteria/bundle-policy-and-source-code.md:block 15 (header) +msgid "Managers: what you need to do" +msgstr "管理人員：需要的工作" + +#: ./criteria/bundle-policy-and-source-code.md:block 16 (unordered list) +msgid "" +"Keep policy makers, developers and designers involved and connected " +"throughout the whole development process." +msgstr "讓政策制定者、開發人員與設計師持續參與，並且在整個開發過程中保持聯繫溝通。" + +#: ./criteria/bundle-policy-and-source-code.md:block 16 (unordered list) +msgid "" +"Make sure policy makers, developers and designers are working to the same " +"objectives." +msgstr "確保政策制定者、開發人員與設計師朝相同目標努力。" + +#: ./criteria/bundle-policy-and-source-code.md:block 17 (header) +msgid "Developers and designers: what you need to do" +msgstr "開發人員與設計師：需要的工作" + +#: ./criteria/bundle-policy-and-source-code.md:block 18 (unordered list) +msgid "" +"Become familiar with and be able to use the process modelling notation that " +"the policy makers in your organization use." +msgstr "熟悉並且學會貴組織單位政策制定者所使用的流程模型標記法。" + +#: ./criteria/bundle-policy-and-source-code.md:block 18 (unordered list) +msgid "" +"Work together with policy makers to make sure there is no mismatch between " +"policy code and source code." +msgstr "與政策制定者一同合作，確保政策法規與原始碼之間沒有不相符之處。" + +#: ./criteria/bundle-policy-and-source-code.md:block 18 (unordered list) +msgid "Give feedback on how to make policy documentation more clear." +msgstr "針對如何讓政策文字更清楚提供意見。" + +#: ./criteria/bundle-policy-and-source-code.md:block 19 (header) +msgid "Further reading" +msgstr "延伸閱讀" + +#: ./criteria/bundle-policy-and-source-code.md:block 20 (unordered list) +msgid "" +"[Business Process Model and " +"Notation](https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation)" +" on Wikipedia." +msgstr "" +"維基百科上的 [BPMN 業務流程模型與標記法](https://en.wikipedia.org/wiki/" +"Business_Process_Model_and_Notation)。" + +#: ./criteria/bundle-policy-and-source-code.md:block 20 (unordered list) +msgid "" +"[BPMN Quick Guide](https://www.bpmnquickguide.com/view-bpmn-quick-guide/) by" +" Trisotech." +msgstr "" +"Trisotech 提供的 [BPMN 快速指南](https://www.bpmnquickguide.com/" +"view-bpmn-quick-guide/)。" + +#: ./criteria/bundle-policy-and-source-code.md:block 20 (unordered list) +msgid "" +"[Decision Model and " +"Notation](https://en.wikipedia.org/wiki/Decision_Model_and_Notation) on " +"Wikipedia." +msgstr "" +"維基百科上的 [DMN 決策模型與標記法](https://en.wikipedia.org/wiki/" +"Decision_Model_and_Notation)。" + +#: ./criteria/bundle-policy-and-source-code.md:block 20 (unordered list) +msgid "" +"[Case Management Model Notation](https://en.wikipedia.org/wiki/CMMN) on " +"Wikipedia." +msgstr "維基百科上的[ CMMN 案例管理模型標記法](https://en.wikipedia.org/wiki/CMMN)。" + +#: ./criteria/code-in-the-open.md:block 3 (header) +msgid "order: 1" +msgstr "order: 1" + +#: ./criteria/code-in-the-open.md:block 4 (header) +msgid "Code in the open" +msgstr "原始碼要開放" + +#: ./criteria/code-in-the-open.md:block 5 (paragraph) +msgid "" +"Coding in the open improves transparency, increases [source " +"code](../glossary.md#source-code) quality, makes the source code easier to " +"audit, and enables collaboration." +msgstr "" +"以開放精神編寫原始碼，能改善資訊透明、提高[原始碼](../glossary.md#source-" +"code)品質、讓原始碼更容易稽核，也能促進互相協作。" + +#: ./criteria/code-in-the-open.md:block 6 (paragraph) +msgid "" +"Together, this creates more opportunities for citizens to understand how " +"software and [policy](../glossary.md#policy) impact their interactions with " +"a public organization." +msgstr "這些合在一起，讓公民更有機會瞭解軟體與[政策](../glossary." +"md#policy)如何影響他們與公家機關的互動。" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"All source code for any policy in use (unless used for fraud detection) MUST" +" be published and publicly accessible." +msgstr "任何使用中政策的所有原始碼都「必須」要公開（用於偵測詐欺的原始碼除外），且能" +"供民眾取用。" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"All source code for any software in use (unless used for fraud detection) " +"MUST be published and publicly accessible." +msgstr "任何使用中軟體的所有原始碼都「必須」要公開（用於偵測詐欺的原始碼除外），且能" +"供民眾取用。" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"The codebase MUST NOT contain sensitive information regarding users, their " +"organization or third parties." +msgstr "程式基底「禁止」包含與使用者及其組織單位，或與第三方相關的敏感性資訊。" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"Any source code not currently in use (such as new versions, proposals or " +"older versions) SHOULD be published." +msgstr "目前非使用中的任何原始碼（像是新版本、提案版本，或較舊版本）都「應該」公開。" + +#: ./criteria/code-in-the-open.md:block 8 (unordered list) +msgid "" +"Documenting which source code or policy underpins any specific interaction " +"the [general public](../glossary.md#general-public) may have with an " +"organization is OPTIONAL." +msgstr "" +"「可選擇」是否要以文件記錄[一般大眾](../glossary.md#general-public)與組織單位" +"之間可能發生的任何特定互動，其背後所採用的原始碼或支持的政策。" + +#: ./criteria/code-in-the-open.md:block 10 (unordered list) +msgid "" +"Confirm that the source for each version currently in use is published on " +"the internet where it can be seen from outside the original contributing " +"organization and without the need for any form of authentication or " +"authorization." +msgstr "確認目前使用中的每個版本都有公布原始碼在網際網路上，而且民眾不需要經過任何形" +"式的身分核對或授權，就能在原始貢獻組織以外，查看這些原始碼。" + +#: ./criteria/code-in-the-open.md:block 10 (unordered list) +msgid "" +"Confirm that the [codebase](../glossary.md#codebase) files and commit " +"history do not include sensitive information." +msgstr "確認[程式基底](../glossary." +"md#codebase)檔案與送交版次歷史紀錄，不包含敏感性資訊。" + +#: ./criteria/code-in-the-open.md:block 10 (unordered list) +msgid "Check for the publication of source code not currently in use." +msgstr "檢查目前非使用中的原始碼是否有公開。" + +#: ./criteria/code-in-the-open.md:block 12 (unordered list) +msgid "Develop policies in the open." +msgstr "制定合乎開放精神的政策。" + +#: ./criteria/code-in-the-open.md:block 12 (unordered list) +msgid "Prioritize open and transparent policies." +msgstr "以公開透明的政策為優先。" + +#: ./criteria/code-in-the-open.md:block 14 (unordered list) +msgid "Develop a culture that embraces openness, learning and feedback." +msgstr "孕育擁抱開放、重視學習、歡迎意見回饋的文化。" + +#: ./criteria/code-in-the-open.md:block 14 (unordered list) +msgid "" +"Collaborate with external vendors and freelancers by working in the open." +msgstr "與外部供應商和自由工作者以開放精神的方式協作。" + +#: ./criteria/code-in-the-open.md:block 16 (unordered list) +msgid "" +"As a reviewer, for each commit, verify that content does not include " +"sensitive information such as configurations, usernames or passwords, public" +" keys or other real credentials used in production systems." +msgstr "審查人員在檢核每次的送交版次紀錄時，要確實核對內容沒有包含組態設定、使用者名" +"稱或密碼、公開金鑰，或其他產品系統中使用的實名憑證等敏感性資訊。" + +#: ./criteria/code-in-the-open.md:block 16 (unordered list) +msgid "" +"Clearly split data and source code, in order to meet the requirement about " +"sensitive information above." +msgstr "為符合上述敏感性資訊的相關規定，請明確分開資料與原始碼。" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[Coding in the open](https://gds.blog.gov.uk/2012/10/12/coding-in-the-open/)" +" by the UK Government Digital Service." +msgstr "" +"英國政府數位服務團《[以開放精神編寫原始碼](https://gds.blog.gov.uk/2012/10/12/coding-in-the-" +"open/)》。" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[When code should be open or " +"closed](https://www.gov.uk/government/publications/open-source-" +"guidance/when-code-should-be-open-or-closed) by the UK Government Digital " +"Service." +msgstr "" +"英國政府數位服務團《[程式碼應該開放或封閉的時機](https://www.gov.uk/government/publications/open-" +"source-guidance/when-code-should-be-open-or-closed)》。" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[Security considerations when coding in the " +"open](https://www.gov.uk/government/publications/open-source-" +"guidance/security-considerations-when-coding-in-the-open) by the UK " +"Government Digital Service." +msgstr "" +"英國政府數位服務團《[以開放精神編寫原始碼的資安考量](https://www.gov.uk/government/publications/open-" +"source-guidance/security-considerations-when-coding-in-the-open)》。" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[Deploying software regularly](https://www.gov.uk/service-" +"manual/technology/deploying-software-regularly) by the UK Government Digital" +" Service." +msgstr "" +"英國政府數位服務團《[定期部署軟體](https://www.gov.uk/service-manual/technology/deploying-" +"software-regularly)》。" + +#: ./criteria/code-in-the-open.md:block 18 (unordered list) +msgid "" +"[How GDS uses GitHub](https://gdstechnology.blog.gov.uk/2014/01/27/how-we-" +"use-github/) by the UK Government Digital Service." +msgstr "" +"英國政府數位服務團《[政府數位服務團如何使用 " +"GitHub](https://gdstechnology.blog.gov.uk/2014/01/27/how-we-use-github/)》。" + +#: ./criteria/document-codebase-maturity.md:block 3 (header) +msgid "" +"order: 16 redirect_from: - criteria/advertise-maturity - criteria/document-" +"maturity" +msgstr "" +"order: 16 redirect_from: - criteria/advertise-maturity - criteria/document-" +"maturity" + +#: ./criteria/document-codebase-maturity.md:block 4 (header) +msgid "Document codebase maturity" +msgstr "記錄程式基底成熟度" + +#: ./criteria/document-codebase-maturity.md:block 5 (paragraph) +msgid "" +"Clearly signalling a [codebase](../glossary.md#codebase)'s maturity helps " +"others decide whether to use and contribute to it. A codebase version's " +"maturity includes the maturity of its dependencies. Understanding how a " +"codebase has evolved is key to understanding the codebase and how to " +"contribute to it." +msgstr "" +"清楚標示[程式基底](../glossary.md#codebase)的成熟度，有助於他人決定是否要使用" +"，或為該程式基底做出貢獻。程式基底版本的成熟度，包含其依賴項目的成熟度。瞭解" +"程式基底演進到什麼程度，是理解該程式基底並知道如何做出貢獻的關鍵。" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "The codebase MUST be versioned." +msgstr "程式基底「必須」註明版本編號。" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "" +"The codebase MUST prominently document whether or not there are versions of " +"the codebase that are ready to use." +msgstr "程式基底「必須」明確以文件記錄，是否有已經準備好可供使用的版本。" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "" +"Codebase versions that are ready to use MUST only depend on versions of " +"other codebases that are also ready to use." +msgstr "準備好可供使用的程式基底版本，「必須」只能依賴其他也已經準備好可供使用的程式" +"基底版本。" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "" +"The codebase SHOULD contain a log of changes from version to version, for " +"example in the `CHANGELOG`." +msgstr "程式基底「應該」包含每次版本的變動紀錄，像是以「`CHANGELOG`」日誌格式檔記錄。" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "The method for assigning version identifiers SHOULD be documented." +msgstr "「應該」要以文件記錄分配版本識別碼的方法。" + +#: ./criteria/document-codebase-maturity.md:block 7 (unordered list) +msgid "It is OPTIONAL to use semantic versioning." +msgstr "「可選擇」是否採用語意化版本控制編號。" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "" +"Confirm that the codebase has a strategy for versioning which is documented." +msgstr "確認程式基底有版本編號策略，且有文件記載該策略。" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "" +"Confirm that it is obvious to policy makers, managers, developers and " +"designers whether the codebase has versions that are ready to use." +msgstr "確認政策制定者、管理人員、開發人員與設計師等，都能清楚知道程式基底是否有準備" +"好可供使用的版本。" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "" +"Confirm that ready to use versions of the codebase do not depend on any " +"versions of other codebases that are not ready to use." +msgstr "確認準備好可供使用的程式基底版本，並不依賴任何尚未準備好可供使用的其他程式基" +"底的版本。" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "" +"Check that the versioning scheme of the codebase is documented and followed." +msgstr "確認有文件記錄程式基底的版本編號方法，並且確實遵守。" + +#: ./criteria/document-codebase-maturity.md:block 9 (unordered list) +msgid "Check that there is a log of changes." +msgstr "確認是否有版本的變動紀錄。" + +#: ./criteria/document-codebase-maturity.md:block 11 (unordered list) +msgid "" +"When developing [policy](../glossary.md#policy), understand that any [source" +" code](../glossary.md#source-code) developed needs to be tested and improved" +" before it can be put into service." +msgstr "" +"制定[政策](../glossary.md#policy)時，請記住任何開發出來的[原始碼](../glossary" +".md#source-code)都必須先經過測試與改善，才能夠投入服務。" + +#: ./criteria/document-codebase-maturity.md:block 11 (unordered list) +msgid "" +"Consider versioning policy changes, especially when they trigger new " +"versions of the source code." +msgstr "考慮將政策的變動註明版本編號，尤其是因而觸發新版本原始碼開發的情況。" + +#: ./criteria/document-codebase-maturity.md:block 13 (unordered list) +msgid "" +"Make sure that services only rely on versions of codebases of equal or " +"greater maturity than the service. For example, don't use a beta version of " +"a codebase in a production service." +msgstr "要確認服務依賴的程式基底版本成熟度，等同或高於該服務本身。舉例來說，" +"正式上線的服務不要使用 beta 公測版程式基底。" + +#: ./criteria/document-codebase-maturity.md:block 15 (unordered list) +msgid "" +"Make sure that the codebase versioning approach is followed for all " +"releases." +msgstr "確認所有發行版，都有遵守程式基底的版本控制編號作法。" + +#: ./criteria/document-codebase-maturity.md:block 17 (unordered list) +msgid "" +"[Semantic Versioning Specification](https://semver.org/) used by many " +"codebases to label versions." +msgstr "許多程式基底使用「[語意化版本編號規範](https://semver.org/)」來標示版本。" + +#: ./criteria/document-codebase-maturity.md:block 17 (unordered list) +msgid "" +"[Software release life " +"cycle](https://en.wikipedia.org/wiki/Software_release_life_cycle)" +msgstr "[軟體發行生命週期](https://en.wikipedia.org/wiki/Software_release_life_cycle)" + +#: ./criteria/document-codebase-maturity.md:block 17 (unordered list) +msgid "" +"[Service Design and Delivery Process](https://www.dta.gov.au/help-and-" +"advice/build-and-improve-services/service-design-and-delivery-process) by " +"the Australian Digital Transformation Agency." +msgstr "" +"澳洲數位轉型局《[服務設計與交付流程](https://www.dta.gov.au/help-and-advice/build-and-" +"improve-services/service-design-and-delivery-process)》。" + +#: ./criteria/document-codebase-maturity.md:block 17 (unordered list) +msgid "" +"[Service Manual on Agile Delivery](https://www.gov.uk/service-manual/agile-" +"delivery) by the UK Government Digital Service." +msgstr "" +"英國政府數位服務團《[敏捷交付服務手冊](https://www.gov.uk/service-manual/agile-delivery)》。" + +#: ./criteria/document-codebase-objectives.md:block 3 (paragraph) +msgid "order: 8 redirect_from:" +msgstr "order: 8 redirect_from:" + +#: ./criteria/document-codebase-objectives.md:block 4 (unordered list) +msgid "criteria/document-objectives" +msgstr "criteria/document-objectives" + +#: ./criteria/document-codebase-objectives.md:block 5 (header) +msgid "Document codebase objectives" +msgstr "程式基底要有目標文件" + +#: ./criteria/document-codebase-objectives.md:block 6 (paragraph) +msgid "" +"Clearly documenting [codebase](../glossary.md#codebase) objectives " +"communicates the purpose of the codebase. It helps stakeholders and " +"contributors scope the development of the codebase. The objectives also " +"provide an easy way for people to decide whether this codebase, or one of " +"its modules, is interesting for them now or in the future." +msgstr "" +"以文件清楚記錄[程式基底](../glossary.md#codebase)目標，來傳達程式基底的用途目" +"標。這能幫助利害關係人與貢獻者劃定程式基底的開發範圍。這些目標也能方便人們判" +"斷，是否在當下或未來，會對此程式基底或其模組感興趣。" + +#: ./criteria/document-codebase-objectives.md:block 8 (unordered list) +msgid "" +"The codebase MUST contain documentation of its objectives, like a mission " +"and goal statement, that is understandable by developers and designers so " +"that they can use or contribute to the codebase." +msgstr "程式基底「必須」包含描寫目標的文件，像是主旨、使命或目標陳述。開發人員與設計" +"師需要能夠瞭解這些，他們才知道可以怎樣使用程式基底或協助貢獻。" + +#: ./criteria/document-codebase-objectives.md:block 8 (unordered list) +msgid "" +"Codebase documentation SHOULD clearly describe the connections between " +"[policy](../glossary.md#policy) objectives and codebase objectives." +msgstr "程式基底文件「應該」清楚描述[政策](../glossary." +"md#policy)目標與程式基底目標之間的關聯。" + +#: ./criteria/document-codebase-objectives.md:block 8 (unordered list) +msgid "" +"Documenting the objectives of the codebase for the [general " +"public](../glossary.md#general-public) is OPTIONAL." +msgstr "「可選擇」是否以文件記錄給[一般大眾](../glossary.md#general-" +"public)看的程式基底目標。" + +#: ./criteria/document-codebase-objectives.md:block 10 (unordered list) +msgid "" +"Confirm that the codebase documentation includes the codebase objectives, " +"mission or goal." +msgstr "確認程式基底文件有包含程式基底目標，或主旨、使命等。" + +#: ./criteria/document-codebase-objectives.md:block 10 (unordered list) +msgid "" +"Check for descriptions of connections between policy objectives and codebase" +" objectives." +msgstr "查看政策目標與程式基底目標之間關聯的描述。" + +#: ./criteria/document-codebase-objectives.md:block 12 (unordered list) +msgid "" +"Add the policy objectives to the codebase documentation, for example in the " +"`README`." +msgstr "將政策目標加入程式基底文件中，例如「`README`」文件當中。" + +#: ./criteria/document-codebase-objectives.md:block 12 (unordered list) +msgid "" +"Make sure that all your codebase objectives have links or references to " +"supporting policy documents added to meet the [Bundle policy and source " +"code](bundle-policy-and-source-code.md) criterion." +msgstr "" +"確保所有程式基底目標，有連結或引用為了符合〈[政策與原始碼要合捆](bundle-" +"policy-and-source-code.md)〉準則而加入的支持政策文件。" + +#: ./criteria/document-codebase-objectives.md:block 14 (unordered list) +msgid "" +"Add the organizational and business objectives to the codebase " +"documentation, for example in the `README`." +msgstr "將單位目標、組織目標或業務目標加入程式基底文件中，例如「`README`」文件當中。" + +#: ./criteria/document-codebase-objectives.md:block 16 (unordered list) +msgid "" +"Add the technology and design objectives to the codebase documentation, for " +"example in the `README`." +msgstr "將技術與設計目標加入程式基底文件中，例如「`README`」文件當中。" + +#: ./criteria/document-codebase-objectives.md:block 18 (unordered list) +msgid "" +"[How to write project " +"objectives](http://grouper.ieee.org/groups/802/3/RTPGE/public/may12/hajduczenia_01_0512.pdf)" +" by Marek Hajduczenia." +msgstr "" +"Marek " +"Hajduczenia《[如何撰寫專案目標](http://grouper.ieee.org/groups/802/3/RTPGE/public/may12/hajduczenia_01_0512.pdf)》。" + +#: ./criteria/document-the-code.md:block 3 (paragraph) +msgid "order: 9 redirect_from:" +msgstr "order: 9 redirect_from:" + +#: ./criteria/document-the-code.md:block 4 (unordered list) +msgid "criteria/documenting" +msgstr "criteria/documenting" + +#: ./criteria/document-the-code.md:block 5 (header) +msgid "Document the code" +msgstr "程式碼要有文件" + +#: ./criteria/document-the-code.md:block 6 (paragraph) +msgid "" +"Well documented [source code](../glossary.md#source-code) helps people to " +"understand what the source code does and how to use it. Documentation is " +"essential for people to start using the [codebase](../glossary.md#codebase) " +"and contributing to it more quickly." +msgstr "" +"文件記錄周全的[原始碼](../glossary.md#source-code)能幫助人們瞭解該原始碼的作" +"用與使用方式。文件紀錄是幫助人們快速上手如何使用[程式基底](../glossary." +"md#codebase)，並做出貢獻的關鍵。" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"All of the functionality of the codebase, [policy](../glossary.md#policy) as" +" well as source code, MUST be described in language clearly understandable " +"for those that understand the purpose of the codebase." +msgstr "" +"程式基底的所有功能、[政策](../glossary.md#policy)及原始碼，都「必須」以可清楚" +"瞭解的用語描述，讓懂程式基底目的用途的人也能夠理解。" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase MUST contain a description of how to " +"install and run the software." +msgstr "程式基底文件「必須」說明如何安裝與執行軟體。" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase MUST contain examples demonstrating the " +"key functionality." +msgstr "程式基底文件「必須」為關鍵功能舉出範例。" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase SHOULD contain a high level description " +"that is clearly understandable for a wide audience of stakeholders, like the" +" [general public](../glossary.md#general-public) and journalists." +msgstr "" +"程式基底文件「應該」包含精要的說明，讓[一般大眾](../glossary.md#general-" +"public)和記者等廣泛的利害關係人都能清楚明白。" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase SHOULD contain a section describing how to" +" install and run a standalone version of the source code, including, if " +"necessary, a test dataset." +msgstr "程式基底文件「應該」有一部分用來說明，如何安裝與執行原始碼的單機版；如果有必" +"要，也應該包含測試資料集。" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation of the codebase SHOULD contain examples for all " +"functionality." +msgstr "程式基底文件「應該」包含所有功能的範例。" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"The documentation SHOULD describe the key components or modules of the " +"codebase and their relationships, for example as a high level architectural " +"diagram." +msgstr "程式碼文件「應該」描述程式基底的主要組件或模組，以及其彼此之間的關係，例如以" +"高層架構圖表示。" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"There SHOULD be [continuous integration](../glossary.md#continuous-" +"integration) tests for the quality of the documentation." +msgstr "「應該」要有針對文件品質的[持續整合](../glossary.md#continuous-" +"integration)測試。" + +#: ./criteria/document-the-code.md:block 8 (unordered list) +msgid "" +"Including examples that make users want to immediately start using the " +"codebase in the documentation of the codebase is OPTIONAL." +msgstr "「可選擇」是否在程式基底文件中，包含讓使用者想要立即使用程式基底的範例。" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Confirm that other stakeholders, professionals from other public " +"organizations and the general public find the documentation clear and " +"understandable." +msgstr "確認文件內容能讓其他利害關係人、其他公家機關的專業人士，以及一般大眾，都可以" +"清楚明白。" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Confirm that the documentation describes how to install and run the source " +"code." +msgstr "確認文件有說明如何安裝與執行原始碼。" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Confirm that the documentation includes examples of the key functionality." +msgstr "確認文件有包含主要功能的範例。" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Check with members of the general public and journalists if they can " +"understand the high level description." +msgstr "向一般大眾的成員以及記者確認，他們是否能明白文件當中的精要說明。" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Check that the instructions for how to install and run a standalone version " +"of the source code result in a running system." +msgstr "檢查單機版原始碼的安裝與執行的步驟說明，確認能順利執行系統。" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "Check that all functionality documented contains an example." +msgstr "檢查文件中列舉的所有功能都包含範例。" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Check that the documentation includes a high level architectural diagram or " +"similar." +msgstr "檢查文件中是否包含高層架構圖，或類似的組件關係圖表。" + +#: ./criteria/document-the-code.md:block 10 (unordered list) +msgid "" +"Check that the documentation quality is part of integration testing, for " +"example documentation is generated correctly, and links and images are " +"tested." +msgstr "確認整合測試有包含到程式碼文件品質，例如確認生成的文件是否正確，並檢查連結與" +"圖片等。" + +#: ./criteria/document-the-code.md:block 12 (unordered list) +msgid "" +"Check in regularly to understand how the non-policy code in the codebase has" +" changed." +msgstr "定期查看程式基底中非政策程式碼的變動情況。" + +#: ./criteria/document-the-code.md:block 12 (unordered list) +msgid "Give feedback on how to make non-policy documentation more clear." +msgstr "針對如何讓非政策文件更清楚易懂提供意見回饋。" + +#: ./criteria/document-the-code.md:block 14 (unordered list) +msgid "" +"Try to use the codebase, so your feedback can improve how clearly the policy" +" and source code are documented. For example, is the current documentation " +"sufficient to persuade a manager at another public organization to use this " +"codebase?" +msgstr "" +"嘗試使用程式基底，並提供您的意見回饋來讓政策與原始碼文件改善得更加清楚。舉例" +"來說，可以自問目前的文件是否足以說服另一個公家機關的管理人員使用這套程式基底" +"？" + +#: ./criteria/document-the-code.md:block 14 (unordered list) +msgid "" +"Make sure you understand both the policy and source code as well as the " +"documentation." +msgstr "確保您同時瞭解政策、原始碼以及文件內容。" + +#: ./criteria/document-the-code.md:block 16 (unordered list) +msgid "" +"Check in regularly to understand how the non-source code in the codebase has" +" changed." +msgstr "定期查看程式基底中非原始碼部分的變動情況。" + +#: ./criteria/document-the-code.md:block 16 (unordered list) +msgid "Give feedback on how to make non-source documentation more clear." +msgstr "針對如何讓非原始碼文件更清楚易懂提供意見回饋。" + +#: ./criteria/document-the-code.md:block 18 (unordered list) +msgid "" +"[Documentation guide](https://www.writethedocs.org/guide/) by Write the " +"Docs." +msgstr "Write the Docs《[文件指南](https://www.writethedocs.org/guide/)》。" + +#: ./criteria/index.md:block 3 (header) +msgid "order: 0" +msgstr "order: 0" + +#: ./criteria/index.md:block 4 (header) +msgid "Criteria" +msgstr "準則" + +#: ./criteria/index.md:block 5 (paragraph) +msgid "{% assign sorted = site.pages | sort:\"order\" %}" +msgstr "{% assign sorted = site.pages | sort:\"order\" %}" + +#: ./criteria/index.md:block 6 (paragraph) +msgid "" +"{% for page in sorted %}{% if page.dir == \"/criteria/\" %}{% if page.name " +"!= \"index.md\" %}{% if page.title %}" +msgstr "" +"{% for page in sorted %}{% if page.dir == \"/criteria/\" %}{% if page.name " +"!= \"index.md\" %}{% if page.title %}" + +#: ./criteria/index.md:block 7 (ordered list) +msgid "" +"[{{page.title}}]({{page.url}}){% endif%} {% endif%} {% endif%}{% endfor %}" +msgstr "" +"[{{page.title}}]({{page.url}}){% endif%} {% endif%} {% endif%}{% endfor %}" + +#: ./criteria/maintain-version-control.md:block 3 (paragraph) +msgid "order: 6 redirect_from:" +msgstr "order: 6 redirect_from:" + +#: ./criteria/maintain-version-control.md:block 4 (unordered list) +msgid "criteria/version-control-and-history" +msgstr "criteria/version-control-and-history" + +#: ./criteria/maintain-version-control.md:block 5 (header) +msgid "Maintain version control" +msgstr "維護版本控制" + +#: ./criteria/maintain-version-control.md:block 6 (paragraph) +msgid "" +"[Version control](../glossary.md#version-control) means keeping track of " +"changes to the [source code](../glossary.md#source-code) and other files of " +"the [codebase](../glossary.md#codebase) over time. This allows you to " +"maintain structured documentation of the history of the codebase. This is " +"essential for collaboration at scale, as it enables developers to work on " +"changes in parallel and helps future developers to understand the reasons " +"for changes." +msgstr "" +"[版本控制](../glossary.md#version-control)主要在追蹤[原始碼](../glossary.md" +"#source-code)以及其他[程式基底](../glossary.md#codebase)檔案歷來的變動。這能" +"讓您為程式基底維護有條理的變動歷史文件。這是大規模協作得以運作的要素，使開發" +"人員可以針對修改變動平行作業，並幫助未來的開發人員瞭解做出修改的原因。" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "All files in the codebase MUST be version controlled." +msgstr "程式基底中的所有檔案皆「必須」有版本控制。" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "All decisions MUST be documented in commit messages." +msgstr "所有決定皆「必須」記錄成送交版次訊息。" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"Every commit message MUST link to discussions and issues wherever possible." +msgstr "每份送交版次訊息皆「必須」盡可能附上討論與議題連結。" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"The codebase SHOULD be maintained in a distributed version control system." +msgstr "程式基底「應該」以分散式版本控制系統作維護。" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"Contribution guidelines SHOULD require contributors to group relevant " +"changes in commits." +msgstr "貢獻守則「應該」要求貢獻者，將相關的修改變動以群組分類方式送交。" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"Maintainers SHOULD mark released versions of the codebase, for example using" +" revision tags or textual labels." +msgstr "維護人員「應該」使用像是修訂版次標記，或文字標籤，來標示程式基底正式發行的版" +"本。" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"Contribution guidelines SHOULD encourage file formats where the changes " +"within the files can be easily viewed and understood in the version control " +"system." +msgstr "貢獻守則「應該」鼓勵採用能在版本控制系統中，輕鬆檢視與瞭解檔案中何處有做出更" +"動的檔案格式。" + +#: ./criteria/maintain-version-control.md:block 8 (unordered list) +msgid "" +"It is OPTIONAL for contributors to sign their commits and provide an email " +"address, so that future contributors are able to contact past contributors " +"with questions about their work." +msgstr "貢獻者「可選擇」是否對送交內容作簽章，並附上電子郵件信箱，以便當未來貢獻者對" +"其內容有疑問時，可以與之前的貢獻者聯絡。" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Confirm that the codebase is kept in version control using software such as " +"Git." +msgstr "確認程式基底維持在版本控制狀態中，像是使用 Git 之類的軟體。" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Review the commit history, confirming that all commit messages explain why " +"the change was made." +msgstr "審查送交版次歷史紀錄，確認所有的送交版次訊息，皆有解釋程式碼修改變動的原因。" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Review the commit history, confirming that where possible all commit " +"messages include the discussion about the change was or where to find it " +"(with a URL)." +msgstr "審查送交版次歷史紀錄，確認所有送交版次訊息之中，盡可能在所有討論過修改變更的" +"地方，包含變動內容以及連結位置（提供網址）。" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "Check if the version control system is distributed." +msgstr "檢查版本控制系統是否為分散式。" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Review the commit history, check if grouping of relevant changes in " +"accordance with the contributing guidelines." +msgstr "審查送交版次歷史紀錄，檢查是否有根據貢獻指引將相關的程式碼變動以群組分類。" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Check that it is possible to access a specific version of the codebase, for " +"example through a revision tag or a textual label." +msgstr "檢查是否可能透過像是修訂版次標記，或文字標籤，來取用程式基底中的特定版本。" + +#: ./criteria/maintain-version-control.md:block 10 (unordered list) +msgid "" +"Check that the file formats used in the codebase are text formats where " +"possible." +msgstr "檢查程式基底在盡可能的情況下，檔案都是採用文字格式。" + +#: ./criteria/maintain-version-control.md:block 12 (unordered list) +msgid "" +"If a new version of the codebase is created because of a " +"[policy](../glossary.md#policy) change, make sure it's clear in the " +"documentation:" +msgstr "如果因為[政策](../glossary." +"md#policy)改變而在程式基底中有新的版本，則請確認有在文件中清楚說明：" + +#: ./criteria/maintain-version-control.md:block 12 (unordered list) +msgid "what the policy change is," +msgstr "政策改變的地方，" + +#: ./criteria/maintain-version-control.md:block 12 (unordered list) +msgid "how it's changed the codebase." +msgstr "程式基底如何因應而改變。" + +#: ./criteria/maintain-version-control.md:block 13 (paragraph) +msgid "" +"For example, adding a new category of applicant to a codebase that manages " +"granting permits would be considered a policy change." +msgstr "舉例來說，為程式基底作權限管理時，如果要新增申請方類別來賦予取用權，應視為一" +"種政策變動。" + +#: ./criteria/maintain-version-control.md:block 15 (unordered list) +msgid "" +"Support policy makers, developers and designers to be clear about what " +"improvements they're making to the codebase. Making improvements isn't a " +"public relations risk." +msgstr "支持政策制定者、開發人員與設計師，使其能清楚表達他們對程式基底做出的改善。確" +"保改善程式基底不會有公關風險。" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "" +"Make sure that all files required to understand the code, build and deploy " +"are in the version control system." +msgstr "確認版本控制系統中，有瞭解程式碼、建置與部署所需要用到的所有檔案。" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "" +"Write clear commit messages so that it is easy to understand why the commit " +"was made." +msgstr "送交版次訊息要寫清楚，讓人一看就能瞭解送交修改的原因。" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "" +"Mark different versions so that it is easy to access a specific version, for" +" example using revision tags or textual labels." +msgstr "使用像是修訂版次標記，或文字標籤來標示不同版本，以方便取用特定版本。" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "Write clear commit messages so that versions can be usefully compared." +msgstr "送交版次訊息要寫清楚，方便之後比較各版本。" + +#: ./criteria/maintain-version-control.md:block 17 (unordered list) +msgid "" +"Work with policy makers to describe how the source code was updated after a " +"policy change." +msgstr "在政策改變以後，與政策制定者合作說明原始碼更新的部分。" + +#: ./criteria/maintain-version-control.md:block 19 (unordered list) +msgid "" +"[Producing OSS: Version Control " +"Vocabulary](https://producingoss.com/en/vc.html#vc-vocabulary) by Karl " +"Fogel." +msgstr "" +"Karl Fogel《[製作開放原始碼軟體：版本控制字彙](https://producingoss.com/en/vc.html#vc-" +"vocabulary)》。" + +#: ./criteria/maintain-version-control.md:block 19 (unordered list) +msgid "" +"[Maintaining version control in coding](https://www.gov.uk/service-" +"manual/technology/maintaining-version-control-in-coding) by the UK " +"Government Digital Service." +msgstr "" +"英國政府數位服務團《[維護程式碼的版本控制](https://www.gov.uk/service-" +"manual/technology/maintaining-version-control-in-coding)》。" + +#: ./criteria/maintain-version-control.md:block 19 (unordered list) +msgid "" +"[GitHub Skills](https://skills.github.com/) by GitHub for learning how to " +"use GitHub or refresh your skills." +msgstr "" +"GitHub 提供的「[GitHub 技能](https://skills.github.com/)」，可學習如何使用 " +"GitHub，或是重溫您的技巧。" + +#: ./criteria/maintain-version-control.md:block 19 (unordered list) +msgid "" +"[Git Cheat Sheet](https://education.github.com/git-cheat-sheet-" +"education.pdf) by GitHub, a list with the most common used git commands." +msgstr "" +"GitHub 提供的「[Git 密技表](https://education.github.com/git-cheat-sheet-" +"education.pdf)」，列出了最常用的 git 命令。" + +#: ./criteria/make-contributing-easy.md:block 3 (header) +msgid "order: 5" +msgstr "order: 5" + +#: ./criteria/make-contributing-easy.md:block 4 (header) +msgid "Make contributing easy" +msgstr "貢獻要容易" + +#: ./criteria/make-contributing-easy.md:block 5 (paragraph) +msgid "" +"To develop better, more reliable and feature rich software, users need to be" +" able to fix problems, add features, and address security issues of the " +"shared [codebase](../glossary.md#codebase)." +msgstr "" +"若要開發更好、更可靠且功能更豐富的軟體，使用者需要能夠為共享的[程式基底](../g" +"lossary.md#codebase)修正問題、新增功能，以及提出安全性議題等。" + +#: ./criteria/make-contributing-easy.md:block 6 (paragraph) +msgid "" +"A shared digital infrastructure makes it easier to make collaborative " +"contributions. The less effort it takes to make contributions that are " +"accepted by the codebase, the more likely users are to become contributors." +msgstr "共享的數位基礎建設讓協作貢獻更容易。使用者讓程式基底接受貢獻時所需付出的心力" +"越少，則使用者越可能成為貢獻者。" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"The codebase MUST have a public issue tracker that accepts suggestions from " +"anyone." +msgstr "程式基底「必須」有個可以公開接受任何人建議的議題追蹤器。" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"The documentation MUST link to both the public issue tracker and submitted " +"codebase changes, for example in a `README` file." +msgstr "文件中「必須」同時有公開的議題追蹤器連結，以及已提交的程式基底變動的連結，例" +"如記錄在「`README`」檔案中。" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"The codebase MUST have communication channels for users and developers, for " +"example email lists." +msgstr "程式基底「必須」要有能與使用者以及開發人員溝通的管道，像是設立電子郵件列表（" +"郵遞論壇）。" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"There MUST be a way to report security issues for responsible disclosure " +"over a closed channel." +msgstr "「必須」有透過封閉管道通報安全性問題的方法，來達成負責任的揭露。" + +#: ./criteria/make-contributing-easy.md:block 8 (unordered list) +msgid "" +"The documentation MUST include instructions for how to report potentially " +"security sensitive issues." +msgstr "文件「必須」說明，該如何通報潛在的安全性與敏感性問題。" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "Confirm that there is a public issue tracker." +msgstr "確認有公開的議題追蹤器。" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "" +"Confirm that the codebase contains links to the public issue tracker and " +"submitted codebase changes." +msgstr "確認程式基底有公開的議題追蹤器連結，以及已提交的程式基底變動的連結。" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "" +"Confirm that it is possible to participate in a discussion with other users " +"and developers about the software using channels described in the codebase." +msgstr "確認可以使用程式基底中提到的管道，與其他使用者以及開發人員一同討論該軟體。" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "Confirm that there is a closed channel for reporting security issues." +msgstr "確認有封閉的管道可通報安全性問題。" + +#: ./criteria/make-contributing-easy.md:block 10 (unordered list) +msgid "" +"Confirm that there are instructions for privately reporting security issues." +msgstr "確認有說明如何私下通報安全性問題。" + +#: ./criteria/make-contributing-easy.md:block 12 (unordered list) +msgid "" +"Track [policy](../glossary.md#policy) issues in the codebase, so that a " +"relevant external policy expert can volunteer help." +msgstr "追蹤程式基底中的[政策](../glossary." +"md#policy)問題，讓相關的外部政策專家如果自願也能夠協助。" + +#: ./criteria/make-contributing-easy.md:block 14 (unordered list) +msgid "" +"Track management issues in the codebase, so that external managers with " +"relevant experience can volunteer help." +msgstr "追蹤程式基底中的管理問題，讓有相關經驗的外部管理人員如果自願也能夠協助。" + +#: ./criteria/make-contributing-easy.md:block 14 (unordered list) +msgid "" +"Support your experienced policy makers, developers and designers to keep " +"contributing to the codebase for as long as possible." +msgstr "支持您經驗豐富的政策制定者、開發人員與設計師，使其盡可能為程式基底持續做出長" +"久貢獻。" + +#: ./criteria/make-contributing-easy.md:block 16 (unordered list) +msgid "" +"Just like for [reviews](require-review-of-contributions.md), make sure to " +"respond to requests promptly." +msgstr "與[審查](require-review-of-contributions.md)流程相同，務必迅速回應請求。" + +#: ./criteria/make-contributing-easy.md:block 16 (unordered list) +msgid "" +"Keep your managers informed of the time and resources you require to support" +" other contributors." +msgstr "告知管理人員，您在支援其他貢獻者時所需的時間與資源。" + +#: ./criteria/make-contributing-easy.md:block 16 (unordered list) +msgid "" +"Make sure that appropriate communication channels for asking maintainers and" +" stakeholders questions are easy to locate, for instance in the README." +msgstr "確保人們可輕鬆找到合適的溝通管道，來詢問維護人員與利害關係人問題，例如寫在「`" +"README`」文件當中。" + +#: ./criteria/make-contributing-easy.md:block 16 (unordered list) +msgid "" +"Make sure that appropriate contact details are included in the metadata, for" +" instance in the publiccode.yml file." +msgstr "確保中介資料包含合適的聯絡資訊，例如寫在 publiccode.yml 檔案中。" + +#: ./criteria/make-contributing-easy.md:block 18 (unordered list) +msgid "" +"[How to inspire exceptional contributions to your open-source " +"project](https://dev.to/joelhans/how-to-inspire-exceptional-contributions-" +"to-your-open-source-project-1ebf) by Joel Hans." +msgstr "" +"Joel Hans《[如何引發他人為您的開放原始碼專案做出優秀貢獻](https://dev.to/joelhans/how-to-inspire-" +"exceptional-contributions-to-your-open-source-project-1ebf)》。" + +#: ./criteria/make-contributing-easy.md:block 18 (unordered list) +msgid "" +"[The benefits of coding in the open](https://gds.blog.gov.uk/2017/09/04/the-" +"benefits-of-coding-in-the-open/) by the UK Government Digital Service." +msgstr "" +"英國政府數位服務團《[以開放精神編寫原始碼的好處](https://gds.blog.gov.uk/2017/09/04/the-benefits-" +"of-coding-in-the-open/)》。" + +#: ./criteria/make-the-codebase-findable.md:block 3 (paragraph) +msgid "order: 14 redirect_from:" +msgstr "order: 14 redirect_from:" + +#: ./criteria/make-the-codebase-findable.md:block 4 (unordered list) +msgid "criteria/findability" +msgstr "criteria/findability" + +#: ./criteria/make-the-codebase-findable.md:block 5 (header) +msgid "Make the codebase findable" +msgstr "程式基底可查詢得到" + +#: ./criteria/make-the-codebase-findable.md:block 6 (paragraph) +msgid "" +"The more findable a [codebase](../glossary.md#codebase) is, the more " +"potential new collaborators will find it. Just publishing a codebase and " +"hoping it is found does not work, instead proactiveness is needed." +msgstr "" +"一旦[程式基底](../glossary.md#codebase)越容易被發現，更多的潛在協作者也就找得" +"到它。不能只是發表個程式基底，然後就盼望他人找得到這套程式基底，更需要主動積" +"極。" + +#: ./criteria/make-the-codebase-findable.md:block 7 (paragraph) +msgid "" +"A metadata description file increases discoverability. Well-written metadata" +" containing a unique and persistent identifier, such as a Wikidata item or " +"FSF software directory listing (thus being part of the semantic web), makes " +"the codebase easier for people to refer, cite, disambiguate and discover " +"through third party tools." +msgstr "" +"有中介資料說明檔的話，會讓程式基底更容易被發現。良好且包含永久唯一識別碼的中" +"介資料，例如寫成 Wikidata 維基數據條目，或是放到 FSF 自由軟體基金會的軟體目錄" +"列表之中（使程式基底成為語意網路中的一部份），他人就能更容易透過第三方工具參" +"考、引用、辨別、發現程式基底。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The name of the codebase SHOULD be descriptive and free from acronyms, " +"abbreviations, puns or organizational branding." +msgstr "程式基底名稱「應該」要能描述說明其用途，且不包含任何首字母縮寫字、縮寫、雙關" +"語，或組織單位品牌名稱或抬頭等。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD have a short description that helps someone understand " +"what the codebase is for or what it does." +msgstr "程式基底說明「應該」要簡短，幫助他人瞭解程式基底的目的與作用。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "Maintainers SHOULD submit the codebase to relevant software catalogs." +msgstr "維護人員「應該」將程式基底提交至相關的軟體目錄上。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD have a website which describes the problem the codebase " +"solves using the preferred jargon of different potential users of the " +"codebase (including technologists, policy experts and managers)." +msgstr "程式基底「應該」要架設網站，內容中以程式基底各類潛在使用者（技術人員、政策專" +"家、管理人員等）偏好的業內用語，描述程式基底所能解決的問題。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD be findable using a search engine by codebase name." +msgstr "在搜尋引擎查找程式基底名稱時，「應該」能搜尋得到程式基底。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD be findable using a search engine by describing the " +"problem it solves in natural language." +msgstr "在使用搜尋引擎時，如果以自然語言描述程式基底所能解決的問題，「應該」能搜尋得" +"到程式基底。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD have a unique and persistent identifier where the entry " +"mentions the major contributors, [repository](../glossary.md#repository) " +"location and website." +msgstr "" +"程式基底「應該」具備永久唯一識別碼，而且該項條目要提及主要貢獻者、[儲存庫](.." +"/glossary.md#repository)、位置、網站等。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "" +"The codebase SHOULD include a machine-readable metadata description, for " +"example in a " +"[publiccode.yml](https://github.com/publiccodeyml/publiccode.yml) file." +msgstr "" +"程式基底「應該」包含機器可讀的中介資料說明，例如採用[publiccode." +"yml](https://github.com/publiccodeyml/publiccode.yml)格式的檔案。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "A dedicated domain name for the codebase is OPTIONAL." +msgstr "「可選擇」是否為程式基底設置專用的網域名稱。" + +#: ./criteria/make-the-codebase-findable.md:block 9 (unordered list) +msgid "Regular presentations at conferences by the community are OPTIONAL." +msgstr "「可選擇」是否在社群舉辦的會議中定期進行簡報。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "Check that the codebase name is descriptive and free of puns." +msgstr "檢查程式基底名稱是否描述說明其用途，且不包含雙關語。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase name is free of acronyms and abbreviations or that " +"the acronyms or abbreviations in the name are more universally known than " +"the longer forms." +msgstr "檢查程式基底名稱是否不包含任何首字母縮寫字或縮寫，或是其首字母縮寫字或縮寫比" +"完整名稱更熟為人知。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase name is free of organizational branding, unless that" +" organization is of the codebase community itself." +msgstr "檢查程式基底是否不包含組織單位品牌名稱或抬頭等，除非該組織單位也是程式基底社" +"群成員。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase repository has a short description of the codebase." +msgstr "檢查程式基底儲存庫是否包含程式基底的簡短描述。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "Check for the codebase listing in relevant software catalogs." +msgstr "檢查程式基底有刊登在相關軟體型錄上。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check for a codebase website which describes the problem the codebase " +"solves." +msgstr "檢查程式基底的網站有描述程式基底能夠解決的問題。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase appears in the results on more than one major search" +" engine when searching by the codebase name." +msgstr "檢查以程式基底名稱來作搜尋時，有超過一個的常用主流搜尋引擎，都有將程式基底列" +"在搜尋結果中。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check that the codebase appears in the results on more than one major search" +" engine when searching by using natural language, for instance, using the " +"short description." +msgstr "檢查以自然語言來作搜尋，例如使用程式基底的簡短描述時，有超過一個的常用主流搜" +"尋引擎，都將程式基底放在搜尋結果中。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check unique and persistent identifier entries for mention of the major " +"contributors." +msgstr "檢查永久唯一識別碼條目有提及主要貢獻者。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check unique and persistent identifier entries for the repository location." +msgstr "檢查永久唯一識別碼條目中有包含儲存庫位置。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "" +"Check unique and persistent identifier entries for the codebase website." +msgstr "檢查永久唯一識別碼條目有列出程式基底網站。" + +#: ./criteria/make-the-codebase-findable.md:block 11 (unordered list) +msgid "Check for a machine-readable metadata description file." +msgstr "檢查中介資料說明檔是機器可讀的格式。" + +#: ./criteria/make-the-codebase-findable.md:block 13 (unordered list) +msgid "" +"Contribute a description of the policy area or problem this codebase acts on" +" or operates." +msgstr "貢獻一段說明此程式基底作用的政策領域，或所處理問題的描述。" + +#: ./criteria/make-the-codebase-findable.md:block 13 (unordered list) +msgid "" +"Test your problem description with peers outside of your context who aren't " +"familiar with the codebase." +msgstr "請那些對程式基底不熟悉且不同領域背景的同事，來測試您的問題描述。" + +#: ./criteria/make-the-codebase-findable.md:block 13 (unordered list) +msgid "" +"Present on how the codebase implements the [policy](../glossary.md#policy) " +"at relevant conferences." +msgstr "在相關會議上作簡報，介紹程式基底如何執行[政策](../glossary.md#policy)。" + +#: ./criteria/make-the-codebase-findable.md:block 15 (unordered list) +msgid "" +"Search trademark databases to avoid confusion or infringement before " +"deciding the name." +msgstr "在決定專案名稱之前，先搜尋過商標資料庫，以避免名稱造成混淆或侵權的問題。" + +#: ./criteria/make-the-codebase-findable.md:block 15 (unordered list) +msgid "" +"Use the short description wherever the codebase is referenced, for instance," +" as social media account descriptions." +msgstr "在引用到程式基底的地方，都使用簡短描述，例如放到社交媒體帳號中的說明。" + +#: ./criteria/make-the-codebase-findable.md:block 15 (unordered list) +msgid "" +"Budget for content design and Search Engine Optimization skills in the team." +msgstr "為團隊編列內容設計與實作 SEO 搜尋引擎最佳化技能的預算。" + +#: ./criteria/make-the-codebase-findable.md:block 15 (unordered list) +msgid "" +"Make sure people involved in the project present at relevant conferences." +msgstr "確保專案參與人員出席相關會議，或作簡報介紹。" + +#: ./criteria/make-the-codebase-findable.md:block 17 (unordered list) +msgid "" +"Search engine optimization, for instance adding a " +"[sitemap](https://www.sitemaps.org/protocol.html)." +msgstr "實作搜尋引擎最佳化，例如加入[網站地圖](https://www.sitemaps.org/protocol." +"html)。" + +#: ./criteria/make-the-codebase-findable.md:block 17 (unordered list) +msgid "" +"Use the short description wherever the codebase is referenced, for instance," +" as the repository description." +msgstr "在引用到程式基底的地方，都使用簡短描述，例如放到儲存庫中的說明。" + +#: ./criteria/make-the-codebase-findable.md:block 17 (unordered list) +msgid "Suggest conferences to present at and present at them." +msgstr "推薦適合出席或作簡報介紹的會議，並且在這些會議中出席或作簡報。" + +#: ./criteria/make-the-codebase-findable.md:block 19 (unordered list) +msgid "" +"[Introduction to " +"Wikidata](https://www.wikidata.org/wiki/Wikidata:Introduction) by the " +"Wikidata community." +msgstr "" +"Wikidata " +"維基數據社群《[維基數據簡介](https://www.wikidata.org/wiki/Wikidata:Introduction)》。" + +#: ./criteria/make-the-codebase-findable.md:block 19 (unordered list) +msgid "" +"[FSF software directory listing](https://directory.fsf.org/wiki/Main_Page) " +"by the Free Software Foundation." +msgstr "FSF 自由軟體基金會《[FSF 軟體目錄列表](https://directory.fsf.org/wiki/Main_Page)》。" + +#: ./criteria/make-the-codebase-findable.md:block 19 (unordered list) +msgid "" +"The [FAIR Guiding Principles for scientific data management and " +"stewardship](https://www.go-fair.org/fair-principles/) by the GO FAIR " +"International Support and Coordination Office provide a nice list of " +"attributes that make (meta)data more machine actionable (and hence more " +"findable). Some of these apply directly to codebases, while others may " +"provoke exploration into what the codebase equivalent would be." +msgstr "" +"GO FAIR 國際支援與合作辦公室所撰寫的《[FAIR " +"科學資料管理與監督指導原則](https://www.go-fair.org/fair-principles/)》，提供" +"一份滿好的特性清單，解說哪些特性會讓資料（或中介資料）更容易讓機器採取行動（" +"也因此更容易被找到）。其中的部分特性可直接套用到程式基底上，而其他無法直接套" +"用的，我們還需要再研究程式基底與其對應的特性要怎麼處理。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 3 (paragraph) +msgid "order: 3 redirect_from:" +msgstr "order: 3 redirect_from:" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 4 (unordered +#: list) +msgid "criteria/reusable-and-portable-codebases" +msgstr "criteria/reusable-and-portable-codebases" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 4 (unordered +#: list) +msgid "criteria/create-reusable-and-portable-code" +msgstr "criteria/create-reusable-and-portable-code" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 5 (header) +msgid "Make the codebase reusable and portable" +msgstr "程式基底要可重複使用且可移植" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 6 (paragraph) +msgid "" +"Creating reusable and portable [code](../glossary.md#code) enables policy " +"makers, developers and designers to reuse what has been developed, test it, " +"improve it and contribute those improvements back, leading to better " +"quality, cheaper maintenance and higher reliability." +msgstr "" +"編寫可重複使用且可移植的[程式碼](../glossary.md#code)，讓政策制定者、開發人員" +"與設計師等，能重複使用、測試與改善目前已開發的內容，並將改善貢獻回程式基底中" +"，如此可提高品質、降低維護成本、增強可靠性。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 7 (paragraph) +msgid "" +"Thoughtfully and purposefully designing a " +"[codebase](../glossary.md#codebase) for reusability allows for the mission, " +"vision and scope of the codebase to be shared by multiple parties. Codebases" +" developed and used by multiple parties are more likely to benefit from a " +"self-sustaining community." +msgstr "" +"以重複利用為前提籌劃設計[程式基底](../glossary.md#codebase)，更容易與多方共享" +"程式基底的目標使命、願景與範圍等。多方開發與使用的程式基底，更可以從能自我運" +"作的社群中獲益。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 8 (paragraph) +msgid "" +"Organizing a codebase such that it is composed of well documented modules " +"improves reusability and maintainability. A module is easier to reuse in " +"[another context](../glossary.md#different-contexts) if its purpose is " +"clearly documented." +msgstr "" +"以文件記錄周全的模組構成程式基底，能夠改善重複使用與維護的能力。以文件清楚記" +"錄用途的模組，更容易在[另一種情境](../glossary.md#different-" +"contexts)中重複利用。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 9 (paragraph) +msgid "" +"Source code which does not rely on the situation-specific infrastructure of " +"any contributor, vendor or deployment can be tested by any other " +"contributor." +msgstr "原始碼不依賴任何貢獻者、供應商或部署底下的特定情況專用基礎架構，則其他任何貢" +"獻者都能測試該原始碼。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "The codebase MUST be developed to be reusable in different contexts." +msgstr "程式基底「必須」開發成能在不同情境中重複使用。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"The codebase MUST be independent from any secret, undisclosed, proprietary " +"or non-open licensed software or services for execution and understanding." +msgstr "程式基底「必須」獨立於任何採用保密、無法揭露、專有或非開放式授權的軟體或服務" +"，以供執行與瞭解。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "The codebase SHOULD be in use by multiple parties." +msgstr "程式基底「應該」有多方單位使用。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "The roadmap SHOULD be influenced by the needs of multiple parties." +msgstr "發展路線圖「應該」有多方單位的需求影響。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"The development of the codebase SHOULD be a collaboration between multiple " +"parties." +msgstr "程式基底開發「應該」由多方單位協作。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"Configuration SHOULD be used to make [source code](../glossary.md#source-" +"code) adapt to context specific needs." +msgstr "「應該」使用組態設定方式以將[原始碼](../glossary.md#source-" +"code)調整成能適應各情境的特定需求。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "The codebase SHOULD be localizable." +msgstr "程式基底「應該」能夠在地化。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"Source code and its documentation SHOULD NOT contain situation-specific " +"information." +msgstr "原始碼與其文件「不應該」包含特定情況專用的資訊。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"Codebase modules SHOULD be documented in such a way as to enable reuse in " +"codebases in other contexts." +msgstr "程式基底模組「應該」以使其能夠在其他情境中重複利用的模式撰寫文件。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 11 (unordered +#: list) +msgid "" +"The software SHOULD NOT require services or platforms available from only a " +"single vendor." +msgstr "軟體「不應該」要求僅有單一供應商能提供的服務或平台。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Confirm with someone in a similar role at another organization if they can " +"use the codebase and what that would entail." +msgstr "與另一組織單位角色與您相似的人確認，看他們是否能利用程式基底，以及需要怎麼進" +"行。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Confirm that the codebase can run without using any proprietary or non open-" +"licensed software or services." +msgstr "確認程式基底不需要用到任何專有或非開放式授權的軟體或服務，就能夠執行。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"If the codebase is in early development before a production-ready release, " +"then check for evidence of ambition to obtain collaborators." +msgstr "若程式基底處於早期開發階段，尚未準備好正式上線，則檢查是否有想要尋求協作者的" +"意圖跡象。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Or if the codebase is very mature and stable with very infrequent fixes, " +"patches, or contributions:" +msgstr "或是如果程式基底非常成熟與穩定，鮮少需要修正、改善或貢獻：" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Check that the codebase is in use by multiple parties or in multiple " +"contexts." +msgstr "檢查是否有多方單位，或是有在多種情境下正使用程式基底。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "Check for documented and budgeted commitments of collaboration." +msgstr "檢查是否有以文件記錄協作所做出的成果，以及有編列相關預算。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "Otherwise:" +msgstr "若是沒有，則：" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "Check that the codebase contributors are from multiple parties." +msgstr "檢查程式基底貢獻者是否來自多方單位。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Check that the codebase files and commit history do not include situation-" +"specific data." +msgstr "檢查程式基底檔案與送交版次歷史紀錄中，不包含特定情況專用的資料。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 13 (unordered +#: list) +msgid "" +"Check that the software can be deployed and run without services or " +"platforms available from a single vendor." +msgstr "檢查軟體是否可以在不使用單一供應商服務或平台的情況下，正常部署與執行。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 15 (unordered +#: list) +msgid "" +"Document your [policy](../glossary.md#policy) with enough clarity and detail" +" that it can be understood outside of its original context." +msgstr "為您的[政策](../glossary.md#policy)撰寫清楚且足夠詳細的文件，讓他人即使不是處於同個原始背景情境也能夠理解。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 15 (unordered +#: list) +msgid "Make sure your organization is listed as a known user by the codebase." +msgstr "確保程式基底有將貴組織單位列為已知使用者。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 15 (unordered +#: list) +msgid "Identify other organizations for your teams to collaborate with." +msgstr "找出貴團隊想要協作的其他組織單位。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 17 (unordered +#: list) +msgid "" +"Make sure that stakeholders and business owners understand that reusability " +"is an explicit codebase goal as this reduces technical debt and provides " +"sustainability for the codebase." +msgstr "確認利害關係人與業主能夠瞭解，程式基底是以重複利用為明確目標，因而得以減少程" +"式碼技術債，並讓程式基底可以永續發展。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 17 (unordered +#: list) +msgid "Make sure that your teams are collaborating with other teams." +msgstr "確認您的團隊與其他團隊能相互協作。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 19 (paragraph) +msgid "Source should be designed:" +msgstr "原始碼應該設計成：" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 20 (unordered +#: list) +msgid "for reuse by other users and organizations regardless of locale," +msgstr "能讓其他使用者與組織單位可以重複利用，而不受地方環境影響，" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 20 (unordered +#: list) +msgid "to solve a general problem instead of a specific one," +msgstr "能解決通用性質問題，而非特定問題，" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 20 (unordered +#: list) +msgid "in logically meaningful and isolated modules," +msgstr "以邏輯上具有意義且獨立的模組構成，" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 20 (unordered +#: list) +msgid "" +"so that someone in a similar organization facing a similar problem would be " +"able to use (parts of) the solution." +msgstr "如此讓類似組織單位中要面對近似問題的人，都可以採用這套解決方案（或其中一部份）。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 21 (paragraph) +msgid "" +"Make sure that the codebase documentation describes the build-time and " +"runtime dependencies. If your context requires deploying to proprietary " +"platforms or using proprietary components, make sure that collaborators can " +"develop, use, test, and deploy without them." +msgstr "" +"確保程式基底文件中，有說明程式的組建日期與執行時期的依賴項目。如果您的情境需" +"要部署至專有平臺上，或者要用到專有組件，則請確保協作者可以在不用到這兩者的情" +"況下，就能進行開發、使用、測試、部署等。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 22 (paragraph) +msgid "" +"For each commit, reviewers verify that content does not include situation-" +"specific data such as hostnames, personal and organizational data, or tokens" +" and passwords." +msgstr "在每份送交版次中，審查人員要確認其中不含特定情況專用的資料，像是主機名稱、個" +"人與組織單位資料、代符與密碼等。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 24 (unordered +#: list) +msgid "" +"[Making source code open and reusable](https://www.gov.uk/service-" +"manual/technology/making-source-code-open-and-reusable) by the UK Government" +" Digital Service." +msgstr "" +"英國政府數位服務團《[讓原始碼開放且可重複利用](https://www.gov.uk/service-" +"manual/technology/making-source-code-open-and-reusable)》。" + +#: ./criteria/make-the-codebase-reusable-and-portable.md:block 24 (unordered +#: list) +msgid "" +"[Localization vs. " +"Internationalization](https://www.w3.org/International/questions/qa-i18n) by" +" the World Wide Web Consortium." +msgstr "" +"W3C 全球資訊網協會《[在地化與國際化](https://www.w3.org/International/questions/qa-i18n)》。" + +#: ./criteria/publish-with-an-open-license.md:block 3 (paragraph) +msgid "order: 13 redirect_from:" +msgstr "order: 13 redirect_from:" + +#: ./criteria/publish-with-an-open-license.md:block 4 (unordered list) +msgid "criteria/open-licenses" +msgstr "criteria/open-licenses" + +#: ./criteria/publish-with-an-open-license.md:block 5 (header) +msgid "Publish with an open license" +msgstr "發行採用開放授權" + +#: ./criteria/publish-with-an-open-license.md:block 6 (paragraph) +msgid "" +"An open and well known license makes it possible for anyone to see the " +"[source code](../glossary.md#source-code) in order to understand how it " +"works, to use it freely and to contribute to the " +"[codebase](../glossary.md#codebase). This enables a vendor ecosystem to " +"emerge around the codebase." +msgstr "" +"採用開放且為人熟知的授權，讓任何人都可以查看[原始碼](../glossary.md#source-" +"code)，使其能瞭解運作方式、自由使用，並且能為[程式基底](../glossary." +"md#codebase)做出貢獻。這也能促進供應商建立出以程式基底為中心的生態系。" + +#: ./criteria/publish-with-an-open-license.md:block 7 (paragraph) +msgid "" +"Clearly indicating the license for each file within a codebase facilitates " +"correct reuse and attribution of parts of a codebase." +msgstr "明確指出程式基底中每一個檔案的授權，讓使用者能正確重複利用程式基底的部分內容" +"，並表彰作者名稱。" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"All source code and documentation MUST be licensed such that it may be " +"freely reusable, changeable and redistributable." +msgstr "所有原始碼與文件，皆「必須」採用使其得以自由重複使用、自由修改、自由再次散布" +"的授權條款。" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"Software source code MUST be licensed under an [OSI-approved or FSF " +"Free/Libre license](https://spdx.org/licenses/)." +msgstr "" +"軟體原始碼「必須」採用[經 OSI 開放原始碼促進會所批准，或由 FSF " +"自由軟體基金會所發表的自由授權條款](https://spdx.org/licenses/)。" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "All source code MUST be published with a license file." +msgstr "所有原始碼皆「必須」搭配授權條款檔案一併發行。" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"Contributors MUST NOT be required to transfer copyright of their " +"contributions to the codebase." +msgstr "「禁止」要求貢獻者將其貢獻的程式碼著作權轉讓給程式基底。" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"All source code files in the codebase SHOULD include a copyright notice and " +"a license header that are machine-readable." +msgstr "程式基底中所有原始碼檔案，皆「應該」包含機器可讀的著作權聲明與授權條款標頭內" +"容。" + +#: ./criteria/publish-with-an-open-license.md:block 9 (unordered list) +msgid "" +"Having multiple licenses for different types of source code and " +"documentation is OPTIONAL." +msgstr "「可選擇」是否為不同類型的原始碼與文件採用多重授權條款。" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "Confirm that the codebase is clearly licensed." +msgstr "確認程式基底有清楚給予授權條款。" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "" +"Confirm that the license for the source code is on the [OSI-approved or FSF " +"Free/Libre license list](https://spdx.org/licenses/) and the license for " +"documentation [conforms to the Open " +"Definition](https://opendefinition.org/licenses/)." +msgstr "" +"確認原始碼的授權條款有列於[經 OSI 開放原始碼促進會所批准，或由 FSF " +"自由軟體基金會所發表的自由授權條款清單](https://spdx.org/licenses/)，以及文件的授權條款有[符合「開放定義」](https://opendefinition.org/licenses/)。" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "Confirm that the licenses used in the codebase are included as files." +msgstr "確認程式基底中有包含其採用的授權條款檔案。" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "" +"Confirm that contribution guidelines and " +"[repository](../glossary.md#repository) configuration do not require " +"transfer of copyright." +msgstr "確認貢獻指引中，以及[儲存庫](../glossary." +"md#repository)的組態設定中，沒有要求貢獻者轉讓著作權。" + +#: ./criteria/publish-with-an-open-license.md:block 11 (unordered list) +msgid "" +"Check for machine-readable license checking in the codebase [continuous " +"integration](../glossary.md#continuous-integration) tests." +msgstr "" +"在程式基底[持續整合](../glossary.md#continuous-" +"integration)測試中，確認是否有檢查授權內容為機器可讀的檢查項目。" + +#: ./criteria/publish-with-an-open-license.md:block 13 (unordered list) +msgid "" +"Develop [policy](../glossary.md#policy) that requires source code to be " +"[open source](../glossary.md#open-source)." +msgstr "" +"制定要求原始碼必須採用[開放原始碼](../glossary.md#open-" +"source)授權的[政策](../glossary.md#policy)。" + +#: ./criteria/publish-with-an-open-license.md:block 13 (unordered list) +msgid "" +"Develop policy that disincentivizes non-open source code and technology in " +"procurement." +msgstr "制定抑制採購非開放原始碼授權程式碼，與非開放科技的政策。" + +#: ./criteria/publish-with-an-open-license.md:block 15 (unordered list) +msgid "" +"Only work with open source vendors that deliver their source code by " +"publishing it under an open source license." +msgstr "只與能採用開放原始碼授權交付、與發行其原始碼的開放原始碼軟體供應商合作。" + +#: ./criteria/publish-with-an-open-license.md:block 15 (unordered list) +msgid "" +"Beware that even though [Creative Commons " +"licenses](https://creativecommons.org/licenses/) are great for " +"documentation, licenses that stipulate Non-Commercial or No Derivatives are " +"NOT freely reusable, changeable and redistributable and don't fulfill these " +"requirements." +msgstr "" +"請注意，雖然[創用CC授權](https://creativecommons.org/licenses/)適合用於文件作品，但其中指明「非商業性」或「禁止改作」的授權條款，代表「無法」自由重複使用、自由修改、自由再次散布等，因此未能符合規定。" + +#: ./criteria/publish-with-an-open-license.md:block 17 (unordered list) +msgid "Add a new `license` file to every new codebase created." +msgstr "每當建立新的程式基底時，都要加入新的「`license`」授權條款檔案。" + +#: ./criteria/publish-with-an-open-license.md:block 17 (unordered list) +msgid "" +"Add a copyright notice and a license header to every new source code file " +"created." +msgstr "每當建立新的原始碼檔案時，都要加入著作權聲明與授權條款標頭內容。" + +#: ./criteria/publish-with-an-open-license.md:block 17 (unordered list) +msgid "" +"When source code is being reused by the codebase, make sure that it has a " +"license that is compatible with the license or licenses of the codebase." +msgstr "每當程式基底重複利用原始碼時，都要確認原始碼的授權與程式基底的授權相容。" + +#: ./criteria/publish-with-an-open-license.md:block 19 (unordered list) +msgid "" +"[Open source definition](https://opensource.org/osd) by the Open Source " +"Initiative, all open source licenses meet this definition." +msgstr "" +"開放原始碼促進會所發表的《[開放原始碼定義](https://opensource.org/osd)》，所有開放原始碼授權條款皆符合這套定義。" + +#: ./criteria/publish-with-an-open-license.md:block 19 (unordered list) +msgid "" +"[Animated video introduction to Creative " +"Commons](https://creativecommons.org/about/videos/creative-commons-kiwi) by " +"Creative Commons Aotearoa New Zealand." +msgstr "" +"紐西蘭CC Aotearoa《[創用CC介紹動畫影片](https://creativecommons.org/about/" +"videos/creative-commons-kiwi)》。" + +#: ./criteria/publish-with-an-open-license.md:block 19 (unordered list) +msgid "" +"[REUSE Initiative specification](https://reuse.software/spec/) by Free " +"Software Foundation Europe for unambiguous, human-readable and machine-" +"readable copyright and licensing information." +msgstr "" +"歐洲自由軟體基金會所發表的《[REUSE 倡議規範](https://reuse.software/spec/" +")》，提供規範明確、人類可讀以及機器可讀的著作權與授權資訊。" + +#: ./criteria/publish-with-an-open-license.md:block 19 (unordered list) +msgid "" +"[SPDX License List](https://spdx.org/licenses/) by the Linux Foundation with" +" standardized, machine-readable abbreviations for most licenses." +msgstr "" +"Linux 基金會所發表的 [SPDX 授權條款清單](https://spdx.org/licenses/" +")，提供經標準化、且機器可讀的大多數授權條款縮寫表示法。" + +#: ./criteria/require-review-of-contributions.md:block 3 (paragraph) +msgid "order: 7 redirect_from:" +msgstr "order: 7 redirect_from:" + +#: ./criteria/require-review-of-contributions.md:block 4 (unordered list) +msgid "criteria/require-review" +msgstr "criteria/require-review" + +#: ./criteria/require-review-of-contributions.md:block 5 (header) +msgid "Require review of contributions" +msgstr "要求審查貢獻內容" + +#: ./criteria/require-review-of-contributions.md:block 6 (paragraph) +msgid "" +"Peer-review of contributions is essential for [source " +"code](../glossary.md#source-code) quality, reducing security risks and " +"operational risks." +msgstr "同儕審查貢獻是[原始碼](../glossary.md#source-" +"code)提升品質的關鍵，也能降低安全性風險與營運風險。" + +#: ./criteria/require-review-of-contributions.md:block 7 (paragraph) +msgid "" +"Requiring thorough review of contributions encourages a culture of making " +"sure every contribution is of high quality, completeness and value. Source " +"code review increases the chance of discovering and fixing potential bugs or" +" mistakes before they are added to the [codebase](../glossary.md#codebase). " +"Knowing that all source code was reviewed discourages a culture of blaming " +"individuals, and encourages a culture of focusing on solutions." +msgstr "" +"要求仔細審查貢獻，能孕育出確保貢獻都是優質、完整且能帶來價值的文化。審查原始" +"碼能提高在原始碼加入[程式基底](../glossary.md#codebase)之前，就發現與修正潛在" +"臭蟲與出錯的機率。得知所有原始碼都會被審查，就不會孕育出習慣怪罪他人的文化，" +"反倒是鼓勵每個人都專注在解決方案上。" + +#: ./criteria/require-review-of-contributions.md:block 8 (paragraph) +msgid "" +"A [policy](../glossary.md#policy) of prompt reviews assures contributors of " +"a guaranteed time for feedback or collaborative improvement, which increases" +" both rate of delivery and contributor engagement." +msgstr "" +"快速審查[政策](../glossary.md#policy)在於向貢獻者保證，必定在一段時間內提供意" +"見回饋或是協作式改善，進而提高貢獻者交付貢獻內容的頻率，以及參與的熱度。" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"All contributions that are accepted or committed to release versions of the " +"codebase MUST be reviewed by another contributor." +msgstr "所有被接受或是送交給程式基底正式發行版本中的貢獻內容，都「必須」經過另一位貢" +"獻者審查。" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "Reviews MUST include source, policy, tests and documentation." +msgstr "審查「必須」包含原始碼、政策、測試、文件等。" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"Reviewers MUST provide feedback on all decisions to not accept a " +"contribution." +msgstr "如果不接受貢獻內容，審查人員「必須」提供意見回饋。" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"The review process SHOULD confirm that a contribution conforms to the " +"standards, architecture and decisions set out in the codebase in order to " +"pass review." +msgstr "審查流程「應該」確認貢獻內容遵循程式基底的標準、架構、決策安排等，以通過審查" +"。" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"Reviews SHOULD include running both the software and the tests of the " +"codebase." +msgstr "審查內容「應該」包含執行軟體與執行程式基底測試。" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"Contributions SHOULD be reviewed by someone in a different context than the " +"contributor." +msgstr "貢獻內容「應該」由與貢獻者不同背景情境的人來審查。" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "" +"Version control systems SHOULD NOT accept non-reviewed contributions in " +"release versions." +msgstr "版本控制系統「不應該」在程式基底的正式發行版本中，接受未經審查的貢獻內容。" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "Reviews SHOULD happen within two business days." +msgstr "審查「應該」在兩個工作天內進行。" + +#: ./criteria/require-review-of-contributions.md:block 10 (unordered list) +msgid "Performing reviews by multiple reviewers is OPTIONAL." +msgstr "「可選擇」是否由多位審查人員進行審查。" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "" +"Confirm that every commit in the history has been reviewed by a different " +"contributor." +msgstr "確認歷史紀錄中，每個送交版次都有經過不同的貢獻者審查。" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "Confirm that reviews include source, policy, tests and documentation." +msgstr "確認審查內容包含原始碼、政策、測試、文件等。" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "Confirm that rejected contributions were appropriately explained." +msgstr "針對未被採用的貢獻內容，確認有適當解釋原因。" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "" +"Check if guidelines for reviewers include instructions to review for " +"conformance to standards, architecture and codebase guidelines." +msgstr "檢查審查人員指引中，有包含是否遵循標準、架構、程式基底指引等指示。" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "Check with reviewers if they run the software and tests during review." +msgstr "檢查審查人員在審查時是否有執行軟體與測試。" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "" +"Check with reviewers if commits have been reviewed by a different " +"contributor in a different context." +msgstr "與審查人員確認，送交版次是否有經過不同情境背景的不同貢獻者審查。" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "" +"Check for use of branch protection in the [version " +"control](../glossary.md#version-control) system." +msgstr "檢查[版本控制](../glossary.md#version-control)系統中是否有採用分支保護。" + +#: ./criteria/require-review-of-contributions.md:block 12 (unordered list) +msgid "Check the times between contribution submission and review." +msgstr "檢查貢獻提交與審查之間的時間間隔。" + +#: ./criteria/require-review-of-contributions.md:block 14 (unordered list) +msgid "" +"Institute a 'four eyes' policy where everything, not just source code, is " +"reviewed." +msgstr "制定進行任何審查時，含原始碼與其他一切事物，都要恪遵「四眼原則」的政策。" + +#: ./criteria/require-review-of-contributions.md:block 14 (unordered list) +msgid "" +"Use a version control system or methodology that enables review and " +"feedback." +msgstr "採用具有審查與意見回饋功能的版本控制系統，或作業流程。" + +#: ./criteria/require-review-of-contributions.md:block 16 (unordered list) +msgid "Make delivering great software a shared objective." +msgstr "將交付妥善軟體作為共同目標。" + +#: ./criteria/require-review-of-contributions.md:block 16 (unordered list) +msgid "" +"Make sure writing and reviewing contributions to source, policy, " +"documentation and tests are considered equally valuable." +msgstr "確保如原始碼、政策、文件、測試等的貢獻內容撰寫與審查，皆受到同等重視。" + +#: ./criteria/require-review-of-contributions.md:block 16 (unordered list) +msgid "" +"Create a culture where all contributions are welcome and everyone is " +"empowered to review them." +msgstr "創造歡迎所有形式的貢獻，而且每個人都能夠審查貢獻內容的文化。" + +#: ./criteria/require-review-of-contributions.md:block 16 (unordered list) +msgid "Make sure no contributor is ever alone in contributing to a codebase." +msgstr "確保貢獻者在貢獻內容給程式基底時，不是獨自一人埋頭苦幹。" + +#: ./criteria/require-review-of-contributions.md:block 18 (unordered list) +msgid "" +"Ask other contributors on the codebase to review your work, in your " +"organization or outside of it." +msgstr "請程式基底的其他貢獻者，審查您在貴組織單位內外的工作成果。" + +#: ./criteria/require-review-of-contributions.md:block 18 (unordered list) +msgid "" +"Try to respond to others' requests for review promptly, initially providing " +"feedback about the concept of the change." +msgstr "當他人請求您審查時，請盡快回覆，並先給出需要修正之處背後的概念。" + +#: ./criteria/require-review-of-contributions.md:block 20 (unordered list) +msgid "" +"[How to review code the GDS way](https://gds-" +"way.cloudapps.digital/manuals/code-review-guidelines.html#content) by the UK" +" Government Digital Service." +msgstr "" +"英國政府數位服務團《[英國政府數位服務團程式碼審查程序](https://gds-way.cloudapps.digital/manuals/code-" +"review-guidelines.html#content)》。" + +#: ./criteria/require-review-of-contributions.md:block 20 (unordered list) +msgid "" +"Branch protection on " +"[GitHub](https://docs.github.com/en/repositories/configuring-branches-and-" +"merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-" +"protected-branches) and " +"[GitLab](https://about.gitlab.com/blog/2014/11/26/keeping-your-code-" +"protected/)." +msgstr "" +"[GitHub](https://docs.github.com/en/repositories/configuring-branches-and-" +"merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-" +"protected-branches) 與 " +"[GitLab](https://about.gitlab.com/blog/2014/11/26/keeping-your-code-" +"protected/) 平臺的分支保護說明。" + +#: ./criteria/require-review-of-contributions.md:block 20 (unordered list) +msgid "" +"[The Gentle Art of Patch Review](https://sage.thesharps.us/2014/09/01/the-" +"gentle-art-of-patch-review/) by Sage Sharp." +msgstr "" +"Sage Sharp《[程式修補審查的和善藝術](https://sage.thesharps.us/2014/09/01/the-gentle-" +"art-of-patch-review/)》。" + +#: ./criteria/require-review-of-contributions.md:block 20 (unordered list) +msgid "" +"[Measuring " +"Engagement](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-" +"mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) by Mozilla." +msgstr "" +"Mozilla《[參與度評測成果](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-" +"mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177)》。" + +#: ./criteria/use-a-coherent-style.md:block 3 (paragraph) +msgid "order: 15 redirect_from:" +msgstr "order: 15 redirect_from:" + +#: ./criteria/use-a-coherent-style.md:block 4 (unordered list) +msgid "criteria/style" +msgstr "criteria/style" + +#: ./criteria/use-a-coherent-style.md:block 5 (header) +msgid "Use a coherent style" +msgstr "風格要前後一致" + +#: ./criteria/use-a-coherent-style.md:block 6 (paragraph) +msgid "" +"Following a consistent and coherent style enables contributors in different " +"environments to work together. Unifying vocabularies reduces friction in " +"communication between contributors." +msgstr "採用前後一致的風格，讓不同環境的貢獻者能夠一同合作。用詞統一能減少貢獻者之間" +"在溝通上的摩擦。" + +#: ./criteria/use-a-coherent-style.md:block 8 (unordered list) +msgid "" +"The [codebase](../glossary.md#codebase) MUST use a coding or writing style " +"guide, either the codebase community's own or an existing one referred to in" +" the codebase." +msgstr "" +"[程式基底](../glossary.md#codebase)「必須」遵守程式碼撰寫風格指引、或文件寫作" +"風格指引，可以是程式基底社群自身的風格指引，或是程式基底有採用的既有風格。" + +#: ./criteria/use-a-coherent-style.md:block 8 (unordered list) +msgid "Contributions SHOULD pass automated tests on style." +msgstr "貢獻內容「應該」通過自動化的風格測試。" + +#: ./criteria/use-a-coherent-style.md:block 8 (unordered list) +msgid "" +"The style guide SHOULD include expectations for inline comments and " +"documentation for non-trivial sections." +msgstr "風格指引「應該」描述對於較複雜的程式碼區段，如何作列內註解與為其寫下說明文件" +"的期待。" + +#: ./criteria/use-a-coherent-style.md:block 8 (unordered list) +msgid "" +"Including expectations for [understandable English](use-plain-english.md) in" +" the style guide is OPTIONAL." +msgstr "「可選擇」是否將[可理解的白話英語](use-plain-english." +"md)期望加入風格指引之中。" + +#: ./criteria/use-a-coherent-style.md:block 10 (unordered list) +msgid "" +"Confirm that contributions are in line with the style guides specified in " +"the documentation." +msgstr "確認貢獻內容有遵循文件中指定的風格指引。" + +#: ./criteria/use-a-coherent-style.md:block 10 (unordered list) +msgid "Check for the presence of automated tests on style." +msgstr "檢查是否有自動化的風格測試。" + +#: ./criteria/use-a-coherent-style.md:block 12 (unordered list) +msgid "" +"Create, follow and continually improve on a style guide for " +"[policy](../glossary.md#policy) and documentation as well as document this " +"in the codebase, for example in the `CONTRIBUTING` or `README`." +msgstr "" +"為[政策](../glossary.md#policy)與文件建立風格指引，遵守並且持續改善，同時記錄" +"到程式基底文件中，像是「`CONTRIBUTING`」或「`README`」檔案。" + +#: ./criteria/use-a-coherent-style.md:block 14 (unordered list) +msgid "" +"Include written language, source, test and policy standards in your " +"organizational definition of quality." +msgstr "將書面語言、原始碼、測試、政策標準等，包含在貴組織單位對品質的定義當中。" + +#: ./criteria/use-a-coherent-style.md:block 16 (paragraph) +msgid "" +"If the codebase does not already have engineering guidelines or other " +"contributor guidance, start by adding documentation to the " +"[repository](../glossary.md#repository) describing whatever is being done " +"now, for example in the `CONTRIBUTING` or `README`. An important purpose of " +"the file is to communicate design preferences, naming conventions, and other" +" aspects machines can't easily check. Guidance should include what would be " +"expected from [source code](../glossary.md#source-code) contributions in " +"order for them to be merged by the maintainers, including source, tests and " +"documentation. Continually improve upon and expand this documentation with " +"the aim of evolving this documentation into engineering guidelines." +msgstr "" +"如果程式基底還沒有工程指引，或其他貢獻者指引，則請先在[儲存庫](../glossary.md" +"#repository)中加入相關文件，像是「`CONTRIBUTING`」或「`README`」檔案，並描述" +"目前在設立指引方面的進展。上述檔案的重要目的之一，在於宣達設計偏好、命名規則" +"，以及機器不容易檢查的其他層面。指引應該包含貢獻的[原始碼](../glossary.md" +"#source-code)預期該符合哪些要求，才會被維護人員合併至程式基底中，包括原始碼、" +"測試、文件等項目。請持續改善與擴充這份文件內容，目標讓文件朝向工程指引演進。" + +#: ./criteria/use-a-coherent-style.md:block 17 (paragraph) +msgid "Additionally:" +msgstr "此外：" + +#: ./criteria/use-a-coherent-style.md:block 18 (unordered list) +msgid "Use a linter." +msgstr "使用 linter 程式碼品質梳理工具。" + +#: ./criteria/use-a-coherent-style.md:block 18 (unordered list) +msgid "Add linter configurations to the codebase." +msgstr "在程式基底中加入 linter 梳理工具的組態設定。" + +#: ./criteria/use-a-coherent-style.md:block 20 (unordered list) +msgid "" +"[Programming style](https://en.wikipedia.org/wiki/Programming_style) on " +"Wikipedia." +msgstr "維基百科上的《[程式碼風格](https://en.wikipedia.org/wiki/" +"Programming_style)》條目。" + +#: ./criteria/use-continuous-integration.md:block 3 (paragraph) +msgid "order: 12 redirect_from:" +msgstr "order: 12 redirect_from:" + +#: ./criteria/use-continuous-integration.md:block 4 (unordered list) +msgid "criteria/continuous-integration" +msgstr "criteria/continuous-integration" + +#: ./criteria/use-continuous-integration.md:block 5 (header) +msgid "Use continuous integration" +msgstr "使用持續整合" + +#: ./criteria/use-continuous-integration.md:block 6 (paragraph) +msgid "" +"Asynchronous collaboration is enabled by developers merging their work to a " +"shared branch frequently, verified by automated tests. The more frequent the" +" merging and the smaller the contribution, the easier it is to resolve merge" +" conflicts." +msgstr "" +"透過自動化測試驗證，開發人員能更頻繁地將其工作成果合併至共享的分支，達成非同" +"步協作。合併的頻率越頻繁、貢獻的規模越小，在合併時所發生的衝突就越容易解決。" + +#: ./criteria/use-continuous-integration.md:block 7 (paragraph) +msgid "" +"Automated testing of all functionality provides confidence that " +"contributions are working as intended and have not introduced errors, and " +"allows reviewers to focus on the structure and approach of the contribution." +" The more focused the test, the easier it is to clearly identify and " +"understand errors as they arise." +msgstr "" +"自動化測試所有功能，使人更加信賴貢獻內容發揮其功用且沒有引發任何錯誤，同時讓" +"審查人員專注在貢獻的結構與作法。測試越聚焦，就越容易辨識並瞭解所出現的問題。" + +#: ./criteria/use-continuous-integration.md:block 8 (paragraph) +msgid "" +"Documenting a codebase's [continuous integration](../glossary.md#continuous-" +"integration) workflow helps contributors understand the expectations of " +"contributions. Continuous integration allows for an easier monitoring of the" +" state of the [codebase](../glossary.md#codebase)." +msgstr "" +"以文件記錄程式基底的[持續整合](../glossary.md#continuous-integration)工作流程" +"，能協助貢獻者瞭解對貢獻內容的期待。持續整合讓監管[程式基底](../glossary." +"md#codebase)狀態變得更為簡單。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"All functionality in the [source code](../glossary.md#source-code) MUST have" +" automated tests." +msgstr "[原始碼](../glossary.md#source-code)中的所有功能，都「必須」有自動化測試。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"Contributions MUST pass all automated tests before they are admitted into " +"the codebase." +msgstr "所有貢獻內容都「必須」先通過自動化測試，才能上傳至程式基底。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"The codebase MUST have guidelines explaining how to structure contributions." +msgstr "程式基底「必須」有解說如何撰寫貢獻內容結構的相關指引。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"The codebase MUST have active contributors who can review contributions." +msgstr "程式基底「必須」有能夠審查貢獻內容的活躍貢獻者。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "Automated test results for contributions SHOULD be public." +msgstr "「應該」公開貢獻內容的自動化測試結果。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"The codebase guidelines SHOULD state that each contribution should focus on " +"a single issue." +msgstr "程式基底指引「應該」指出，每次的貢獻內容都只應聚焦在單一議題上。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "Source code test and documentation coverage SHOULD be monitored." +msgstr "「應該」監管原始碼測試與文件的涵蓋範圍。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"Testing [policy](../glossary.md#policy) and documentation for consistency " +"with the source and vice versa is OPTIONAL." +msgstr "「可選擇」是否測試[政策](../glossary." +"md#policy)和文件，與原始碼之間有無一致性，或是反之亦然。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"Testing policy and documentation for style and broken links is OPTIONAL." +msgstr "「可選擇」是否測試政策和文件所採用的樣式，以及連結有無失效。" + +#: ./criteria/use-continuous-integration.md:block 10 (unordered list) +msgid "" +"Testing the software by using examples in the documentation is OPTIONAL." +msgstr "「可選擇」是否使用文件中的範例來測試軟體。" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "Confirm that there are tests present." +msgstr "確認有測試可用。" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "" +"Confirm that source code coverage tools check that coverage is at 100% of " +"the source code." +msgstr "確認原始碼覆蓋率工具能檢查到 100% 的原始碼。" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "" +"Confirm that contributions are only admitted into the codebase after all of " +"the tests are passed." +msgstr "確認貢獻內容只有在通過所有測試後，才會認可上傳至程式基底。" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "" +"Confirm that contribution guidelines explain how to structure contributions." +msgstr "確認有貢獻指引解說如何撰寫貢獻內容的結構。" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "" +"Confirm that there are contributions from within the last three months." +msgstr "確認最近三個月內有貢獻內容上傳。" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "Check that test results are viewable." +msgstr "檢查是否可以查看測試結果。" + +#: ./criteria/use-continuous-integration.md:block 12 (unordered list) +msgid "Check if source code coverage data is published." +msgstr "檢查是否有公布原始碼覆蓋率數據。" + +#: ./criteria/use-continuous-integration.md:block 14 (unordered list) +msgid "" +"Involve managers as well as developers and designers as early in the process" +" as possible and keep them engaged throughout development of your policy." +msgstr "儘早讓管理人員、開發人員與設計師一同加入，並且讓他們持續參與您政策的制定程序。" + +#: ./criteria/use-continuous-integration.md:block 14 (unordered list) +msgid "" +"Make sure there are also automated tests set up for policy documentation." +msgstr "確保政策文件也有設好自動化測試。" + +#: ./criteria/use-continuous-integration.md:block 14 (unordered list) +msgid "Fix policy documentation promptly if it fails a test." +msgstr "如果政策文件未能通過測試，請快速修正。" + +#: ./criteria/use-continuous-integration.md:block 14 (unordered list) +msgid "" +"Make sure the source code reflects any changes to the policy (see [Maintain " +"version control](maintain-version-control.md))." +msgstr "確保原始碼能反映出政策的任何變動（請參閱〈[維護版本控制](maintain-version-" +"control.md)〉）。" + +#: ./criteria/use-continuous-integration.md:block 16 (unordered list) +msgid "" +"Make sure to test with real end users as quickly and often as possible." +msgstr "確保能儘快且經常給真正的終端使用者進行測試。" + +#: ./criteria/use-continuous-integration.md:block 16 (unordered list) +msgid "" +"Plan the work to integrate small parts very often instead of large parts " +"less frequently." +msgstr "以頻繁整合少量部分內容的方式做專案規劃，而非久久一次繳交大量部分內容。" + +#: ./criteria/use-continuous-integration.md:block 16 (unordered list) +msgid "" +"Procure consultancy services that deliver incrementally aligned with the " +"plan." +msgstr "聘請有能力處理漸進式交付，並跟得上規劃進度的顧問服務。" + +#: ./criteria/use-continuous-integration.md:block 16 (unordered list) +msgid "" +"After a large failure, encourage publication of incident reports and public " +"discussion of what was learned." +msgstr "發生重大失誤後，鼓勵公開事故報告，以及公開討論事後學到的教訓。" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Help managers structure the work plan such that it can be integrated as " +"small increments." +msgstr "協助管理人員擬定工作規劃，例如規劃成可以拆分成小部分逐次整合。" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Help contributors limit the scope of their contributions and feature " +"requests to be as small as reasonable." +msgstr "協助貢獻者聚焦其貢獻內容與功能請求，讓涵蓋範圍盡可能合理地縮小。" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Help managers and policy makers test their contributions, for example by " +"testing their contributions for broken links or style." +msgstr "協助管理人員與政策制定者測試其貢獻內容，例如測試其貢獻內容中的失效連結或樣式。" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Structure source code written to handle conditions which are difficult to " +"create in a test environment in such a way that the conditions can be " +"simulated during testing. Forms of resource exhaustion such as running out " +"of storage space and memory allocation failure are typical examples of " +"difficult to create conditions." +msgstr "" +"編排原始碼結構時，要將難以在測試環境下創造出來的情況，得以在測試過程中模擬出" +"來。例如硬碟空間不足、記憶體分配失敗等資源耗盡情況，都是難以創造的典型案例。" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "" +"Tune the test code coverage tools to avoid false alarms resulting from " +"inlining or other optimizations." +msgstr "調整程式碼覆蓋率測試工具，避免在 inline 過程或其他最佳化處理時得到假警報。" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "Deploy often." +msgstr "經常部署。" + +#: ./criteria/use-continuous-integration.md:block 18 (unordered list) +msgid "Integrate your work at least once a day." +msgstr "至少每天整合工作內容一次。" + +#: ./criteria/use-continuous-integration.md:block 20 (unordered list) +msgid "" +"[What is continuous " +"integration](https://www.martinfowler.com/articles/continuousIntegration.html)" +" by Martin Fowler." +msgstr "" +"Martin " +"Fowler《[什麼是持續整合](https://www.martinfowler.com/articles/continuousIntegration.html)》。" + +#: ./criteria/use-continuous-integration.md:block 20 (unordered list) +msgid "" +"[Use continuous delivery](https://gds-" +"way.cloudapps.digital/standards/continuous-delivery.html) by the UK " +"Government Digital Service." +msgstr "" +"英國政府數位服務團《[使用持續交付](https://gds-way.cloudapps.digital/standards/continuous-" +"delivery.html)》。" + +#: ./criteria/use-continuous-integration.md:block 20 (unordered list) +msgid "" +"[Quality assurance: testing your service " +"regularly](https://www.gov.uk/service-manual/technology/quality-assurance-" +"testing-your-service-regularly) by the UK Government Digital Service." +msgstr "" +"英國政府數位服務團《[品質保證：定期測試您的服務](https://www.gov.uk/service-" +"manual/technology/quality-assurance-testing-your-service-regularly)》。" + +#: ./criteria/use-open-standards.md:block 3 (paragraph) +msgid "order: 11 redirect_from:" +msgstr "order: 11 redirect_from:" + +#: ./criteria/use-open-standards.md:block 4 (unordered list) +msgid "criteria/open-standards" +msgstr "criteria/open-standards" + +#: ./criteria/use-open-standards.md:block 5 (header) +msgid "Use open standards" +msgstr "採用開放標準" + +#: ./criteria/use-open-standards.md:block 6 (paragraph) +msgid "" +"[Open standards](../glossary.md#open-standard) guarantee access to the " +"knowledge required to use and contribute to the " +"[codebase](../glossary.md#codebase). They enable interoperability between " +"systems and reduce the risk of vendor lock-in. Open standards which are " +"unambiguous allow for independent development of either side of data " +"exchange." +msgstr "" +"[開放標準](../glossary.md#open-" +"standard)保證可以取得使用與貢獻[程式基底](../glossary.md#codebase)所需的知識" +"。不僅能為不同的系統之間建立互通性，更能降低廠商套牢的可能性。開放標準如果明" +"確，不同方就可以各自獨立開發作資料交換。" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"For features of the codebase that facilitate the exchange of data the " +"codebase MUST use an open standard that meets the [Open Source Initiative " +"Open Standard Requirements](https://opensource.org/osr)." +msgstr "" +"程式基底如要促進資料交換的特性，就「必須」採用符合 [OSI " +"開放原始碼促進會其《開放標準需求規範](https://opensource.org/" +"osr)》的開放標準。" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Any non-open standards used MUST be recorded clearly as such in the " +"documentation." +msgstr "如果有使用到任何非開放標準，則「必須」在文件中清楚記錄。" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Any standard chosen for use within the codebase MUST be listed in the " +"documentation with a link to where it is available." +msgstr "程式基底選擇採用的任何標準，皆「必須」在文件中列出，並且只要有的話，就附上該" +"標準的連結。" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Any non-open standards chosen for use within the codebase MUST NOT hinder " +"collaboration and reuse." +msgstr "程式基底選擇採用的任何非開放標準，皆「禁止」妨礙程式基底的協作與重複使用。" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"If no existing open standard is available, effort SHOULD be put into " +"developing one." +msgstr "如果還沒有已存在的開放標準可採用，則「應該」投入開發新標準。" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Open standards that are machine testable SHOULD be preferred over open " +"standards that are not." +msgstr "採用開放標準時，「應該」優先選擇可經機器測試的開放標準。" + +#: ./criteria/use-open-standards.md:block 8 (unordered list) +msgid "" +"Non-open standards that are machine testable SHOULD be preferred over non-" +"open standards that are not." +msgstr "採用非開放標準時，「應該」優先選擇可經機器測試的非開放標準。" + +#: ./criteria/use-open-standards.md:block 10 (unordered list) +msgid "Confirm that data exchange follows an OSI approved open standard." +msgstr "確認資料交換遵守 OSI 開放原始碼促進會批准的開放標準。" + +#: ./criteria/use-open-standards.md:block 10 (unordered list) +msgid "" +"Confirm that any non-open standards used are clearly documented as such." +msgstr "確認若有採用任何的非開放標準，皆有清楚記錄在文件中。" + +#: ./criteria/use-open-standards.md:block 10 (unordered list) +msgid "" +"Confirm that documentation includes a list of the standards followed within " +"the codebase, each with a working link, or a statement that no standards " +"were chosen." +msgstr "確認文件有清單列出程式基底所採用的標準，其中各標準有對應的有效連結；或沒有採" +"用任何標準時，則留下聲明。" + +#: ./criteria/use-open-standards.md:block 12 (unordered list) +msgid "Mandate use of open standards everywhere possible." +msgstr "以政策要求盡可能在任何情況下採用開放標準。" + +#: ./criteria/use-open-standards.md:block 12 (unordered list) +msgid "Prohibit procurement of technology that does not use open standards." +msgstr "禁止採購不採用開放標準的技術科技。" + +#: ./criteria/use-open-standards.md:block 14 (unordered list) +msgid "" +"Consider including open standard compliance assessment in [source " +"code](../glossary.md#source-code) reviews." +msgstr "考慮在[原始碼](../glossary.md#source-code)審查中納入開放標準依循評估。" + +#: ./criteria/use-open-standards.md:block 16 (unordered list) +msgid "" +"Add [continuous integration](../glossary.md#continuous-integration) tests " +"for compliance with the standards." +msgstr "將是否依循標準加入[持續整合](../glossary.md#continuous-integration)測試中。" + +#: ./criteria/use-open-standards.md:block 16 (unordered list) +msgid "" +"Review the commits and other [repository](../glossary.md#repository) " +"resources for references to standards and cross-check those with the " +"standards listed." +msgstr "審查送交版次與[儲存庫](../glossary." +"md#repository)其他資源是否有參考開放標準，並交叉檢查其中有列出標準的部分。" + +#: ./criteria/use-open-standards.md:block 18 (unordered list) +msgid "" +"[Open Standards principles](https://www.gov.uk/government/publications/open-" +"standards-principles/open-standards-principles), " +"[policy](../glossary.md#policy) paper of the UK Cabinet Office." +msgstr "" +"英國內閣辦公室發表的《[開放標準原則](https://www.gov.uk/government/publications/open-" +"standards-principles/open-standards-" +"principles)》[政策](../glossary.md#policy)報告。" + +#: ./criteria/use-plain-english.md:block 3 (paragraph) +msgid "order: 10 redirect_from:" +msgstr "order: 10 redirect_from:" + +#: ./criteria/use-plain-english.md:block 4 (unordered list) +msgid "criteria/understandable-english-first" +msgstr "criteria/understandable-english-first" + +#: ./criteria/use-plain-english.md:block 5 (header) +msgid "Use plain English" +msgstr "使用白話的英語" + +#: ./criteria/use-plain-english.md:block 6 (paragraph) +msgid "" +"English is the de facto language of collaboration in software " +"development." +msgstr "英語是軟體開發領域中的實際 協作語言。" + +#: ./criteria/use-plain-english.md:block 7 (paragraph) +msgid "" +"Public sector information needs to be accessible to all its constituents. " +"Plain and simple language makes the [code](../glossary.md#code) and what it " +"does easier to understand for a wider variety of people." +msgstr "公家機關資訊需要讓所有選民都能取用。簡單且白話的語言，能讓更多人能瞭解[程式碼" +"](../glossary.md#code)與其功用。" + +#: ./criteria/use-plain-english.md:block 8 (paragraph) +msgid "" +"Translations further increase the possible reach of a " +"[codebase](../glossary.md#codebase). Language that is easy to understand " +"lowers the cost of creating and maintaining translations." +msgstr "翻譯可以讓更多人有機會認識[程式基底](../glossary." +"md#codebase)。用語越是簡單明暸，製作與維護翻譯的成本就越低。" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "All codebase documentation MUST be in English." +msgstr "程式基底的所有文件都「必須」使用英語。" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"All [source code](../glossary.md#source-code) MUST be in English, except " +"where [policy](../glossary.md#policy) is machine interpreted as code." +msgstr "" +"所有[原始碼](../glossary.md#source-" +"code)都「必須」使用英語編寫，其中[政策](../glossary." +"md#policy)是由機器解讀當作程式碼的部分則除外。" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"All bundled policy not available in English MUST have an accompanying " +"summary in English." +msgstr "任何合捆的政策如果沒有英語版本，則「必須」隨附英語版摘要。" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"Any translation MUST be up to date with the English version and vice versa." +msgstr "任何翻譯版本皆「必須」跟隨英語版本更新，以維持在最新狀態，反之亦然。" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"There SHOULD be no acronyms, abbreviations, puns or legal/non-English/domain" +" specific terms in the codebase without an explanation preceding it or a " +"link to an explanation." +msgstr "" +"程式基底中「不應該」使用首字母縮字、縮寫、雙關語，或法律/非英語/行業特定詞彙" +"；如果有的話，則需要在這些用語出現之前先行解釋，或是附上解釋該用語的網頁連結" +"。" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"Documentation SHOULD aim for a lower secondary education reading level, as " +"recommended by the [Web Content Accessibility Guidelines " +"2](https://www.w3.org/WAI/WCAG21/quickref/?showtechniques=315#readable)." +msgstr "" +"根據《[網頁內容近用性無障礙指引 2](https://www.w3.org/WAI/WCAG21/quickref/" +"?showtechniques=315#readable)》的建議，文件內容「應該」以國中識讀程度為主。" + +#: ./criteria/use-plain-english.md:block 10 (unordered list) +msgid "" +"Providing a translation of any code, documentation or tests is OPTIONAL." +msgstr "「可選擇」是否提供任何程式碼、文件、測試等的翻譯版。" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "Confirm that codebase documentation is available in English." +msgstr "確認程式基底文件有英語版本。" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "" +"Confirm that source code is in English, or confirm any non-English is policy" +" or terms with preceding explanations." +msgstr "確認原始碼為英語，確認任何非英語內容都是政策，或確認術語在其前方有先行說明等。" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "Confirm any non-English policy has an accompanying summary in English." +msgstr "確認任何非英語政策都有隨附英語版摘要。" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "" +"Confirm that translations and the English version have the same content." +msgstr "確認翻譯版與英語版內容相同。" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "" +"Check that no unexplained acronyms, abbreviations, puns or legal/non-" +"English/domain specific terms are in the documentation." +msgstr "確認文件當中，沒有任何未說明的首字母縮寫字、縮寫、雙關語，或法律/非英語/行業特定詞彙等。" + +#: ./criteria/use-plain-english.md:block 12 (unordered list) +msgid "Check the spelling, grammar and readability of the documentation." +msgstr "檢查文件的拼字、文法與易讀性等。" + +#: ./criteria/use-plain-english.md:block 14 (unordered list) +msgid "" +"Frequently test with other managers, developers and designers in the process" +" if they understand what you are delivering and how you document it." +msgstr "在過程中經常與其他管理人員、開發人員與設計師測試，確認他們是否瞭解您們正要交付的程式碼與其文件的內容。" + +#: ./criteria/use-plain-english.md:block 16 (unordered list) +msgid "" +"Try to limit the use of acronyms, abbreviations, puns or legal/non-" +"English/domain specific terms in internal communications in and between " +"teams and stakeholders. Add any such terms to a glossary and link to it from" +" the places they are being used." +msgstr "" +"在團隊內部與利害關係人之間的內部溝通中，試著限制首字母縮寫字、縮寫、雙關語，或法律/非英語/行業特定詞彙的使用。如果有使用到的話，則將這些用語加入詞彙表，並且在使用這些詞彙的地方加上詞彙表連結。" + +#: ./criteria/use-plain-english.md:block 16 (unordered list) +msgid "" +"Be critical of documentation and descriptions in proposals and changes. If " +"you don't understand something, others will probably also struggle with it." +msgstr "以批判性觀點看待提案與修改當中的文件與描述。如果有您看不懂的內容，很有可能其他人也同樣迷惘。" + +#: ./criteria/use-plain-english.md:block 18 (unordered list) +msgid "" +"Frequently test with policy makers and managers if they understand what you " +"are delivering and how you document it." +msgstr "經常與政策制定者和管理人員測試，確認他們是否瞭解您們正要交付的程式碼與其文件的內容。" + +#: ./criteria/use-plain-english.md:block 18 (unordered list) +msgid "" +"Ask someone outside of your context if they understand the content (for " +"example, a developer working on a different codebase)." +msgstr "詢問身處不同背景情境的人（像是另一個程式基底的開發人員）是否能瞭解內容。" + +#: ./criteria/use-plain-english.md:block 20 (unordered list) +msgid "" +"Meeting the [Web Content Accessibility Guidelines 2.1, Guideline 3.1 " +"Readable](https://www.w3.org/TR/WCAG21/#readable) by W3C makes text content " +"readable and understandable." +msgstr "" +"符合 W3C 全球資訊網協會《[網頁內容近用性無障礙指引 2.1、3.1 " +"之可讀性](https://www.w3.org/TR/WCAG21/" +"#readable)》要求，撰寫的文字內容要容易閱讀與理解。" + +#: ./criteria/use-plain-english.md:block 20 (unordered list) +msgid "" +"The[European Union accessibility directive](https://ec.europa.eu/digital-" +"single-market/en/web-accessibility) by the European Commission, is an " +"example of regulation requiring high accessibility." +msgstr "" +"歐盟委員會的《[歐盟無障礙環境命令](https://ec.europa.eu/" +"digital-single-market/en/web-" +"accessibility)》，是高度要求無障礙環境的法規範例。" + +#: ./criteria/use-plain-english.md:block 20 (unordered list) +msgid "" +"[Definition of plain " +"language](https://www.plainlanguage.gov/about/definitions/) by United States" +" General Services Administration." +msgstr "美國總務署《[白話語言定義](https://www.plainlanguage.gov/about/definitions/)》。" + +#: ./criteria/welcome-contributors.md:block 3 (paragraph) +msgid "order: 4 redirect_from:" +msgstr "order: 4 redirect_from:" + +#: ./criteria/welcome-contributors.md:block 4 (unordered list) +msgid "criteria/open-to-contributions" +msgstr "criteria/open-to-contributions" + +#: ./criteria/welcome-contributors.md:block 5 (header) +msgid "Welcome contributors" +msgstr "歡迎貢獻者" + +#: ./criteria/welcome-contributors.md:block 6 (paragraph) +msgid "" +"The atmosphere in a [codebase](../glossary.md#codebase) community helps " +"users decide to use one codebase over another. Welcoming anyone as a " +"contributor enables the community to grow and sustain itself over time. A " +"community where contributors have clear ways to influence codebase and " +"community goals and progress is less likely to split and end up in diverging" +" communities. Newcomers need to understand and trust the codebase " +"community’s governance." +msgstr "" +"[程式基底](../glossary.md#codebase)社群的氛圍，會影響使用者選擇所要使用的程式" +"基底。歡迎任何人成為貢獻者的社群，才能夠不斷茁壯並且持續自我運作。若貢獻者有" +"明確的方法可以影響程式基底、社群目標與進展，則該社群分裂成分歧的社群的機率也" +"較低。新參與者需要瞭解並信任程式基底社群的治理方式。" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The codebase MUST allow anyone to submit suggestions for changes to the " +"codebase." +msgstr "程式基底必須「允許」任何人對程式基底提出修改建議。" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The codebase MUST include contribution guidelines explaining what kinds of " +"contributions are welcome and how contributors can get involved, for example" +" in a `CONTRIBUTING` file." +msgstr "程式基底「必須」包含貢獻指引，說明歡迎貢獻的內容類型，以及貢獻者可如何參與開" +"發，例如以「`CONTRIBUTING`」檔案說明。" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The codebase MUST document the governance of the codebase, contributions and" +" its community, for example in a `GOVERNANCE` file." +msgstr "程式基底「必須」以文件記錄程式基底、貢獻內容與社群互動等的治理方式，例如以「`" +"GOVERNANCE`」檔案來說明。" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The contribution guidelines SHOULD document who is expected to cover the " +"costs of reviewing contributions." +msgstr "貢獻指引「應該」以文件記錄預期由何者負擔審查貢獻內容所需的開銷費用。" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"The codebase SHOULD advertise the committed engagement of involved " +"organizations in the development and maintenance." +msgstr "程式基底「應該」宣布投入其開發與維護工作的參與組織單位。" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "The codebase SHOULD have a publicly available roadmap." +msgstr "程式基底「應該」要有可公開取得的發展路線圖。" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "The codebase SHOULD publish codebase activity statistics." +msgstr "程式基底「應該」公布程式基底的活動統計數據。" + +#: ./criteria/welcome-contributors.md:block 8 (unordered list) +msgid "" +"Including a code of conduct for contributors in the codebase is OPTIONAL." +msgstr "「可選擇」是否為程式基底加入貢獻者的行為守則。" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "" +"Confirm that it is possible to submit suggestions for changes to the " +"codebase." +msgstr "確認可以提交修改建議給程式基底。" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Confirm there are contribution guidelines." +msgstr "確認程式基底有貢獻指引。" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "" +"Confirm that the codebase governance is clearly explained, including how to " +"influence codebase governance." +msgstr "確認程式基底有清楚解釋治理架構，並包含如何影響程式基底治理的方法。" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "" +"Check that contributing guidelines cover who is expected to cover the costs " +"of reviewing contributions." +msgstr "確認貢獻指引是否有涵蓋預期由何者負擔審查貢獻內容的開銷費用。" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Check for a list of involved organizations." +msgstr "檢查是否有參與的組織單位名單。" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Check for a roadmap." +msgstr "檢查是否有發展路線圖。" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Check for published activity statistics." +msgstr "檢查是否有公布活動統計數據。" + +#: ./criteria/welcome-contributors.md:block 10 (unordered list) +msgid "Check for a code of conduct." +msgstr "檢查是否有行為守則。" + +#: ./criteria/welcome-contributors.md:block 12 (unordered list) +msgid "" +"Add a list to the codebase of any other resources that " +"[policy](../glossary.md#policy) experts, non-governmental organizations and " +"academics would find useful for understanding or reusing your policy." +msgstr "" +"為程式基底加入其他資源的清單，而這些資源可幫助[政策](../glossary." +"md#policy)專家、非政府組織、學者等，更能瞭解或可重複利用您的政策。" + +#: ./criteria/welcome-contributors.md:block 12 (unordered list) +msgid "" +"Consider adding contact details so that other policy makers considering " +"collaboration can ask you for advice." +msgstr "考慮放入聯絡資訊，讓其他考慮合作的政策制定者能徵詢您的意見。" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"Make sure that the documentation of the governance includes the current " +"process for how to make changes to the governance." +msgstr "確保治理架構文件內容中，有包含目前如何改變治理狀態的流程。" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"If the community has some consensus about how the governance should change, " +"then include those ideas stated as ambitions in the documentation." +msgstr "如果社群對於治理架構應該如何改變有共識，則應該將這些構想宣告為願景寫入文件中。" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"If needed, make sure you have allocated budget for the contributions review " +"process as agreed by the codebase community." +msgstr "若有需要，確認您有編列貢獻內容審查流程的預算，且經過程式基底社群同意。" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"Make sure the documentation explains how each organization is involved in " +"the codebase, what resources it has available for it and for how long." +msgstr "確認文件有解釋每個參與組織單位所投入的內容，例如提供程式基底哪些資源，以及參" +"與的時間長度等。" + +#: ./criteria/welcome-contributors.md:block 14 (unordered list) +msgid "" +"Support your experienced policy makers, developers and designers to stay " +"part of the community for as long as possible." +msgstr "支持您經驗豐富的政策制定者、開發人員與設計師，使其盡可能長久參與社群。" + +#: ./criteria/welcome-contributors.md:block 16 (unordered list) +msgid "Respond promptly to requests." +msgstr "快速回應請求。" + +#: ./criteria/welcome-contributors.md:block 16 (unordered list) +msgid "" +"Communicate clearly to contributors what they need to do make sure their " +"contribution can be integrated." +msgstr "清楚告知貢獻者他們該如何做，才能讓貢獻內容整合到程式基底中。" + +#: ./criteria/welcome-contributors.md:block 18 (unordered list) +msgid "" +"[Building welcoming communities](https://opensource.guide/building-" +"community/) by Open Source Guides." +msgstr "開放原始碼指引所提供的《[營造友善的社群](https://opensource.guide/" +"building-community/)》。" + +#: ./criteria/welcome-contributors.md:block 18 (unordered list) +msgid "" +"[The Open Source Contributor Funnel](https://mikemcquaid.com/2018/08/14/the-" +"open-source-contributor-funnel-why-people-dont-contribute-to-your-open-" +"source-project/) by Mike McQuaid." +msgstr "" +"Mike McQuaid《[開放原始碼貢獻者瓶頸](https://mikemcquaid.com/2018/08/14/the-open-" +"source-contributor-funnel-why-people-dont-contribute-to-your-open-source-" +"project/)》。" + +#: ./criteria/welcome-contributors.md:block 18 (unordered list) +msgid "" +"[Leadership and governance](https://opensource.guide/leadership-and-" +"governance/) for growing [open source](../glossary.md#open-source) community" +" projects, by Open Source Guides." +msgstr "" +"開放原始碼指引針對推動[開放原始碼](../glossary.md#open-" +"source)社群專案所寫的《[領導與治理](https://opensource.guide/" +"leadership-and-governance/)》。" + +#: ./criteria/welcome-contributors.md:block 18 (unordered list) +msgid "" +"[Building online communities](http://hintjens.com/blog:117) by Pieter " +"Hintjens (long read!)." +msgstr "Pieter Hintjens《[打造網路社群](http://hintjens.com/blog:117)》(長篇文章！)。" + +#: ./docs/printing.md:block 1 (header) +msgid "Printing" +msgstr "印刷" + +#: ./docs/printing.md:block 3 (paragraph) +msgid "" +"The printed Standard for Public Code is printed by Reclameland. This guide " +"tries to provide the relevant information to print it there or somewhere " +"else." +msgstr "《公共程式標準》是由 Reclameland 負責印刷。本指引試著提供印刷相關資訊，" +"方便您到 Reclameland 或其他地方印刷。" + +#: ./docs/printing.md:block 4 (paragraph) +msgid "" +"Details, mostly in order they are on the Reclameland page with the Dutch if " +"necessary:" +msgstr "印刷詳細資訊（多數依照 Reclameland 網頁上的順序，依需要附上荷蘭語）：" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "" +"Form: Softcover book ([Reclameland product " +"page](https://www.reclameland.nl/drukken/softcover-boeken))" +msgstr "" +"樣式：平裝書 ([Reclameland 產品頁面](https://www.reclameland.nl/drukken/" +"softcover-boeken))" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Format: A4" +msgstr "紙張尺寸：A4" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Portrait or landscape: Portrait (Staand)" +msgstr "直向或橫向：直向 (Staand)" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Printing inside: 4/4 dual sided full color" +msgstr "內頁印刷：正四反四 4/4，雙面全色印刷" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Inside material: 90 grams biotop" +msgstr "內頁材質：Biotop 90克" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Cover: 350 grams cover" +msgstr "封面：350 克封面" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Printing cover: 4/0 one sided full cover" +msgstr "封面印刷：正四反空 4/0，單面滿版印刷" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Cover treatment: one sided matt foliated (Enke)" +msgstr "封面處理：單面霧面層剝處理 (Enke)" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "" +"Pages: pages of the inside + 4 + x, where x is 0-3 so that the sum becomes a" +" multiple of 4" +msgstr "頁數：書內頁數 + 4 + x，x 是 0-3頁，讓總頁數是 4 的倍數" + +#: ./docs/printing.md:block 5 (unordered list) +msgid "Individually sealed: no" +msgstr "個別封裝：無" + +#: ./docs/printing.md:block 6 (paragraph) +msgid "" +"When these details are chosen, the cover and insides are uploaded and the " +"order is placed payment can happen (payment ahead) after which printing " +"starts." +msgstr "一旦選定這些印刷的詳細資訊，封面與內頁就會上傳，並且下單與付費。付費後才會開始印刷。" + +#: ./docs/releasing.md:block 1 (header) +msgid "Releasing a new version of the Standard for public code" +msgstr "發行新版本的《公共程式標準》" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Review state of the 'develop' branch" +msgstr "審查「develop」分支的狀態" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Ensure all changes intended for release are merged" +msgstr "確認預計收入該次發行版的所有變更都已完成合併" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Invite a proofread of the current state of the branch" +msgstr "邀請校對該分支目前的狀態" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"If new dashes are introduced, check if the language can be simplified to " +"remove them in favor of more simple sentences. If a complex sentence is " +"needed, see if the dash can be replaced with other punctuation. If a dash is" +" truly the best expression of ideas, then follow the [Chicago Manual of " +"Style](https://en.wikipedia.org/wiki/Dash#En_dash_versus_em_dash)." +msgstr "" +"如果有引入新的破折號，檢查是否能簡化文字並且移除破折號，例如改用較簡易的句子" +"。如果需要用到複雜的句子，檢查是否能用其他標點符號來取代破折號。如果破折號最" +"適合用來表達該句子的涵義，則請遵守《[芝加哥格式手冊](https://en.wikipedia." +"org/wiki/Dash#En_dash_versus_em_dash)》的規範。" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Create a release branch" +msgstr "建立發行用分支" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "From 'develop', `git switch -c \"release-$MAJOR.$MINOR.$PATCH\"`" +msgstr "從「develop」分支下命令，`git switch -c \"release-$MAJOR.$MINOR.$PATCH\"`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Push the branch, `git push -u origin release-$MAJOR.$MINOR.$PATCH`" +msgstr "推送分支，`git push -u origin release-$MAJOR.$MINOR.$PATCH`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update the new release" +msgstr "更新本次新發行" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Update version number in `_config.yml`, `README.md` and `publiccode.yml`" +msgstr "更新 `_config.yml`、`README.md` 與 `publiccode.yml` 中的版本編號" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update `assets/version-badge.svg` with `script/make-version-badge.sh`" +msgstr "使用 `script/make-version-badge.sh` 更新 `assets/version-badge.svg`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update releaseDate in `publiccode.yml`" +msgstr "更新 `publiccode.yml` 當中的 releaseDate 日期" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update [`AUTHORS.md`](../AUTHORS.md) with new contributors" +msgstr "在 [`AUTHORS.md`](../AUTHORS.md) 中加入新貢獻者的資料" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update [`CHANGELOG.md`](../CHANGELOG.md)" +msgstr "更新 [`CHANGELOG.md`](../CHANGELOG.md)" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Perform extra pass on diff to the 'main' branch" +msgstr "透過 diff 進行額外傳輸到「main」分支" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"run `script/generate-review-template.sh` and commit updated `docs/review-" +"template.html`" +msgstr "" +"執行 `script/generate-review-template.sh` 並送交更新後的 `docs/review-" +"template.html` 版次記錄" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"update `docs/standard-for-public-code.md` with the new text from the review " +"template, updating any status changes as a result" +msgstr "用審查範本中的新文字來更新 `docs/standard-for-public-code." +"md`，根據成果更新所有的狀態變更" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Reread any section or paragraph to ensure wording changes still fit the " +"whole and do not contain grammar or spelling errors" +msgstr "重新檢查用字有變更的任何小節或段落，確保變更的字詞適合該整體內容，並且沒有文" +"法或拼字錯誤" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Ensure [fonts](https://brand.publiccode.net/typography/) are installed, see:" +" `script/ensure-font.sh`" +msgstr "" +"確認有安裝[字型](https://brand.publiccode.net/typography/)，請參見：`script/" +"ensure-font.sh`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Check the rendered `.pdf` using `script/pdf.sh rc1`" +msgstr "使用 `script/pdf.sh rc1` 檢查轉譯出的 `.pdf` 檔" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Ensure no link collisions exist" +msgstr "確認沒有連結相衝的問題" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Check the page breaks, possibly removing or adding page-break CSS, for " +"example: `

`" +msgstr "" +"檢查文字分頁之處，可能需要移除或新增 CSS 分頁語法，像是：`

`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "If needed, commit fixes and repeat extra pass" +msgstr "如果有需要，送交修正版次，並重複進行額外傳輸" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Push branch, open a pull request to the 'main' branch" +msgstr "推送分支，對 「main」分支提出拉取請求" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Request review from multiple reviewers, especially a proofreader" +msgstr "請多位審查人員（特別是校對人員）進行審查" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Reviewers will create issues for shortcomings found which would not prevent " +"release" +msgstr "審查人員若發現不會阻礙發行的缺失，則會建立議題" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"If needed for release, reviewers may create pull requests to resolve issues" +msgstr "如果是發行所需處理的缺失，審查人員可以提交拉取請求來解決問題" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Re-request reviews if additional pull requests are merged into release " +"branch" +msgstr "若有額外的拉取請求合併至發行分支，則再次請求審查" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Run the to-archive-org.sh script" +msgstr "執行 to-archive-org.sh 命令稿" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Once reviews are complete, merge to 'main'" +msgstr "當審查完成後，合併回「main」" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Create GitHub release with the release notes and version number" +msgstr "在 GItHub 上發行，附上發行備註與版本編號" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Switch to the 'main' branch, `git pull` and `git status`" +msgstr "切換至「main」分支，`git pull` 然後 `git status`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "`git tag $MAJOR.$MINOR.$PATCH`" +msgstr "`git tag $MAJOR.$MINOR.$PATCH`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "`git push --tags` (see: `../.github/workflows/release-on-tag.yml`)" +msgstr "`git push --tags`（請參見：`../.github/workflows/release-on-tag.yml`）" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Trigger a rebuild of gh-pages" +msgstr "觸發 gh-pages 重建" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "`git switch -c rebuild-gh-pages-$MAJOR.$MINOR.$PATCH`" +msgstr "`git switch -c rebuild-gh-pages-$MAJOR.$MINOR.$PATCH`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "`git commit --allow-empty -m\"Rebuild GH Pages $MAJOR.$MINOR.$PATCH\"`" +msgstr "`git commit --allow-empty -m\"Rebuild GH Pages $MAJOR.$MINOR.$PATCH\"`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "`git push -u origin rebuild-gh-pages-$MAJOR.$MINOR.$PATCH`" +msgstr "`git push -u origin rebuild-gh-pages-$MAJOR.$MINOR.$PATCH`" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Open a pull request from this branch to `main`" +msgstr "從此分支向「main」提出拉取請求" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Approve and merge PR (containing empty commit)" +msgstr "批准與合併 PR （包含空白的送交版次）" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Update 'develop' with a merge from 'main'" +msgstr "將「develop」透過合併更新「main」" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "[Send the files for print to the printer](printing.md)" +msgstr "[將檔案傳送給印刷廠商印刷](printing.md)" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Cover file" +msgstr "封面檔案" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "Inside pages PDF" +msgstr "內頁 PDF" + +#: ./docs/releasing.md:block 3 (ordered list) +msgid "" +"Ping [translation](https://github.com/publiccodenet/community-translations-" +"standard) contributors" +msgstr "" +"通知[翻譯](https://github.com/publiccodenet/community-translations-" +"standard)貢獻者" + +#: ./docs/roadmap.md:block 1 (header) +msgid "Roadmap" +msgstr "發展路線圖" + +#: ./docs/roadmap.md:block 3 (paragraph) +msgid "Last updated: 2023-03-08" +msgstr "上次更新時間：2023-03-08" + +#: ./docs/roadmap.md:block 4 (paragraph) +msgid "" +"This document intends to shed light on the current development plans of the " +"team. Plans change constantly as new information is absorbed by the team." +msgstr "本文件旨在闡明團隊目前的開發計畫。隨著團隊吸收新資訊，這些計畫也會持續變動。" + +#: ./docs/roadmap.md:block 5 (paragraph) +msgid "" +"Codebase stewards review the roadmap monthly as part of our [backlog pruning" +" session](https://about.publiccode.net/activities/standard-" +"maintenance/backlog-pruning.html)." +msgstr "" +"程式基底執事人員每月會定期審查發展路線圖，這是我們[積累事項修整作業](https://" +"about.publiccode.net/activities/standard-maintenance/backlog-pruning." +"html)環節的一部份。" + +#: ./docs/roadmap.md:block 6 (header) +msgid "Current work" +msgstr "目前任務" + +#: ./docs/roadmap.md:block 7 (unordered list) +msgid "As far as possible, make the standard Standard-compliant" +msgstr "盡可能讓標準遵循自我標準" + +#: ./docs/roadmap.md:block 8 (header) +msgid "Near term" +msgstr "近期" + +#: ./docs/roadmap.md:block 9 (unordered list) +msgid "Separate executive summary" +msgstr "分離執行摘要" + +#: ./docs/roadmap.md:block 9 (unordered list) +msgid "" +"Clarify \"code\" as \"source code\" or \"policy code\" when specific to one," +" issue #208" +msgstr "#208號議題：將程式碼或規則之「code」清楚區分為「原始碼」或是「政策法規」" + +#: ./docs/roadmap.md:block 9 (unordered list) +msgid "Possibly: add in the illustrations for each criterion" +msgstr "可能性：為每個準則新增解說插圖" + +#: ./docs/roadmap.md:block 10 (header) +msgid "Longer term" +msgstr "長期" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Certification badges" +msgstr "認證標章" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "" +"Add to README and index.md information (and eventually statistics) on " +"adoption and use (issue #438)" +msgstr "為「README」與「index.md」加入採用與使用（之後會繼續統計）條目（議題#438號）" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Physical paper checklist" +msgstr "實體紙張檢查清單" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Becoming validated by multiple codebases" +msgstr "通過多個程式基底驗證" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Release version 1.0.0 after a few codebases are compliant" +msgstr "在幾個程式基底遵循標準後，發行 1.0.0 版" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Linkable requirements" +msgstr "可連結的需求規範" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "New cover art" +msgstr "新封面設計" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "Register for ISBN" +msgstr "註冊申請 ISBN 書號" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "List with an on-demand book printing service" +msgstr "隨選書籍列印服務名單" + +#: ./docs/roadmap.md:block 11 (unordered list) +msgid "QR codes for external links in print version" +msgstr "印刷版外部連結的 QR 二維圖碼" + +#: ./foreword.md:block 3 (paragraph) +msgid "redirect_from:" +msgstr "redirect_from:" + +#: ./foreword.md:block 4 (unordered list) +msgid "introduction" +msgstr "前言" + +#: ./foreword.md:block 5 (header) +msgid "Foreword" +msgstr "序文" + +#: ./foreword.md:block 6 (paragraph) +msgid "" +"The Standard for Public Code is a set of criteria that support public " +"organizations in developing and maintaining software and policy together." +msgstr "《公共程式標準》提供一套準則規範，支持公家機關一同開發與維護軟體及政策。" + +#: ./foreword.md:block 7 (paragraph) +msgid "" +"Anyone developing public-purpose software or policy can use this standard to" +" work towards higher quality public services that are more cost effective, " +"with less risk and more control." +msgstr "任何想開發具有公眾用途的軟體或政策的人，可以利用本標準來提升公共服務品質，使" +"其更具成本效益、風險更低，還能對系統更有掌控權。" + +#: ./foreword.md:block 8 (paragraph) +msgid "" +"This foreword introduces the term public code and explains why this is " +"important." +msgstr "本序文在介紹何謂「公共程式」以及解說其重要性。" + +#: ./foreword.md:block 9 (header) +msgid "Definition of public code" +msgstr "公共程式定義" + +#: ./foreword.md:block 10 (paragraph) +msgid "" +"Public code is both computer source code (such as software and algorithms) " +"and public policy executed in a public context, by humans or machines. It " +"encompasses the software built to operate with and as public infrastructure," +" along with the arrangements for its production. Public code is explicitly " +"distinct from regular software because it operates under fundamentally " +"different circumstances and expectations." +msgstr "" +"公共程式，英文為 Public Code，是指人類或機器在公共情境下，所執行的電腦原始碼" +"（像是軟體與演算法）與公共政策。公共程式的範疇，涵蓋搭配公共基礎建設一同作業" +"的軟體、作為公共基礎建設運作而建置的軟體，以及產生公共程式的過程安排等。公共" +"程式與一般軟體有明顯區別，因為其作業的環境與期待全然不同。" + +#: ./foreword.md:block 11 (header) +msgid "Reasons for public code" +msgstr "採用公共程式的原因" + +#: ./foreword.md:block 12 (paragraph) +msgid "There are many reasons for why public code is relevant now." +msgstr "公共程式現在如此重要，背後有幾個原因。" + +#: ./foreword.md:block 13 (header) +msgid "Software code == legal code" +msgstr "軟體程式碼 == 法律條文" + +#: ./foreword.md:block 14 (paragraph) +msgid "Software is public infrastructure." +msgstr "軟體是公共基礎建設。" + +#: ./foreword.md:block 15 (paragraph) +msgid "" +"In the 21st century, software can be considered vital public infrastructure." +" It is increasingly not just the expression of existing policy but the " +"originator of new policy, for example where algorithms decide which " +"districts need extra social services or policing." +msgstr "" +"在 21 世紀，軟體可被視為重要的公共基礎建設。軟體越來越常被用於實現既有政策，" +"甚至成為新政策的制定來源。舉例來說，演算法可以決定哪些地區需要額外的社會服務" +"或警力等。" + +#: ./foreword.md:block 16 (paragraph) +msgid "" +"Software mechanics, algorithms and data collection have become key elements " +"in the execution of public policies. Computer code now executes policies " +"that have been codified in legal code through democratic procedures. Both " +"forms of code set conditions for society to function according to " +"democratically set public values, the latter executed by humans, the former " +"by machines. In other words, software code has increasingly started to equal" +" legal code." +msgstr "" +"在公共政策的執行上，軟體運作機制、演算法與資料蒐集等，已成為關鍵要素。今日的" +"電腦程式碼，正執行著透過民主程序制定的法規政策。程式碼與政策這兩種形式的程式" +"，都根據民主程序而確立的公共價值，設立出社會的運作環境；前者由機器執行，後者" +"則是由人類執行。換句話說，軟體程式碼，已經越來越實質趨近於法律條文的地位。" + +#: ./foreword.md:block 17 (paragraph) +msgid "" +"Software should therefore be subject to the principles of democratic " +"governance." +msgstr "因此軟體也應該接受民主治理原則的約束。" + +#: ./foreword.md:block 18 (header) +msgid "Traditional public software procurement" +msgstr "傳統的公共軟體採購" + +#: ./foreword.md:block 19 (paragraph) +msgid "" +"Current public software production methods have not served public service " +"delivery very well." +msgstr "目前公共軟體的生產模式，在交付公共服務上的效率並不高。" + +#: ./foreword.md:block 20 (paragraph) +msgid "" +"In the last decade, public organizations that purchased complete software " +"solutions have sometimes been surprised to discover that they:" +msgstr "過去近十年來，購置完整軟體解決方案的公家機關，有時甚至會很訝異地發現：" + +#: ./foreword.md:block 21 (unordered list) +msgid "" +"can’t change their software to reflect changing policy or take advantage of " +"new technology" +msgstr "他們無法修改軟體來反映政策的變動，或是改變軟體來利用新科技" + +#: ./foreword.md:block 21 (unordered list) +msgid "" +"don’t have access to their data as it's locked into proprietary systems" +msgstr "他們的資料都套牢在專有系統中，無法取用" + +#: ./foreword.md:block 21 (unordered list) +msgid "are asked to pay ever increasing license fees" +msgstr "他們所需繳交的授權費變得越來越貴" + +#: ./foreword.md:block 22 (header) +msgid "Technological sovereignty and democratic accountability" +msgstr "技術自主權與民主課責" + +#: ./foreword.md:block 23 (paragraph) +msgid "Public institutions, civil servants and residents deserve better." +msgstr "公家機關、公務員與居民都值得更好的。" + +#: ./foreword.md:block 24 (paragraph) +msgid "" +"We believe the software that runs our society can no longer be a black box, " +"controlled by outside companies that keep the underlying logic on which " +"their software operates hidden in proprietary codebases. Instead, " +"governments and the people they serve need technological sovereignty. This " +"allows them to set and control the functioning of public software, just like" +" they are able to set and control policy that is legally formulated in laws." +" Citizens and civil society actors need this software to be transparent and " +"accountable." +msgstr "" +"我們相信支持社會運作的軟體，再也不能是黑箱，任由外部公司依隱藏在專有程式基底" +"之下的秘密邏輯作控制。反過來說，政府，以及政府所要服務的人民，需要掌控技術自" +"主權。技術自主讓他們能主導設定與控制公共軟體的運作，正如同他們能依法制定與調" +"整政策一樣。人民與公民社會的參與者，都需要這類軟體能夠透明，且可以課責。" + +#: ./foreword.md:block 25 (paragraph) +msgid "" +"The design of software as essential civic infrastructure should honor " +"digital citizens’ rights." +msgstr "作為必要公民基礎建設的軟體，其設計應該尊重公民的數位權利。" + +#: ./foreword.md:block 26 (header) +msgid "Designing truly public software" +msgstr "設計真正的公共軟體" + +#: ./foreword.md:block 27 (paragraph) +msgid "" +"Public code is at the core of modern public institutions, shapes the work of" +" civil servants and affects the lives of almost all residents." +msgstr "公共程式是現代公家機構的核心，型塑了公務員的工作樣態，並且影響了幾乎所有居民" +"的生活。" + +#: ./foreword.md:block 28 (paragraph) +msgid "Public software must therefore be:" +msgstr "因此公共軟體必須：" + +#: ./foreword.md:block 29 (unordered list) +msgid "transparent" +msgstr "透明" + +#: ./foreword.md:block 29 (unordered list) +msgid "accountable" +msgstr "可課責" + +#: ./foreword.md:block 29 (unordered list) +msgid "understandable for its constituents" +msgstr "讓選民能夠理解" + +#: ./foreword.md:block 30 (paragraph) +msgid "" +"It must reflect the values of the society it serves, for example by being " +"inclusive and non-discriminatory." +msgstr "必須能反映其所服務的社會價值觀，像是涵容與不歧視。" + +#: ./foreword.md:block 31 (paragraph) +msgid "" +"Most proprietary software systems currently used by public organizations do " +"not meet these requirements. Public code does." +msgstr "目前公家機關使用的大多數專有軟體系統，都不符合這些要求；而公共程式能夠做到。" + +#: ./foreword.md:block 32 (header) +msgid "Values of public code" +msgstr "公共程式的價值" + +#: ./foreword.md:block 33 (paragraph) +msgid "We consider public code to have these core values:" +msgstr "我們認為公共程式應具有下列核心價值：" + +#: ./foreword.md:block 34 (unordered list) +msgid "Inclusive" +msgstr "涵容" + +#: ./foreword.md:block 34 (unordered list) +msgid "Usable" +msgstr "好用" + +#: ./foreword.md:block 34 (unordered list) +msgid "Open" +msgstr "開放" + +#: ./foreword.md:block 34 (unordered list) +msgid "Legible" +msgstr "易懂" + +#: ./foreword.md:block 34 (unordered list) +msgid "Accountable" +msgstr "課責" + +#: ./foreword.md:block 34 (unordered list) +msgid "Accessible" +msgstr "近用" + +#: ./foreword.md:block 34 (unordered list) +msgid "Sustainable" +msgstr "永續" + +#: ./foreword.md:block 35 (header) +msgid "How public code works" +msgstr "公共程式運作方式" + +#: ./foreword.md:block 36 (paragraph) +msgid "" +"Public code is open source software meant for fulfilling the essential role " +"of public organizations. Through use, other administrations contribute back " +"to the software, so that its development and maintenance become truly " +"collaborative." +msgstr "" +"公共程式是旨在協助公家機關，履行其必要職責時所採用的開放原始碼軟體。透過使用" +"，其他行政單位也能為軟體做出貢獻，因此公共程式的開發與維護，可說是真正互相協" +"作的成果。" + +#: ./foreword.md:block 37 (paragraph) +msgid "Being open unlocks many other things." +msgstr "開放的精神能開創許多可能性。" + +#: ./foreword.md:block 38 (paragraph) +msgid "" +"Local responsibility and democratic accountability are ensured when a public" +" organization implements and maintains their own public code. By being open " +"and with a broader contributor base, the software is more secure as it " +"benefits from many eyes spotting potential flaws. Many contributors share " +"the maintenance work to keep it functional and modern, which reduces future " +"technical debt. The shared workload is more sustainable now and in the " +"future. Its openness makes both the code and its data more easily adaptable " +"in the future. The code will be easier to retool, repurpose or retire. This " +"all results in lower risk public infrastructure." +msgstr "" +"公家機關在執行與維護其自身的公共程式時，就是在確保能為地方負責，並履行民主課" +"責。開放且貢獻者眾多的軟體，得利於有許多人在看，更容易發現潛在缺陷，因此安全" +"性會更高。許多貢獻者會分攤維護工作，讓公共程式能持續運作與更新，減少未來技術" +"債的可能。因為能有多人分攤維護工作，使得現在與未來都會更加永續。而公共程式的" +"開放性，代表其程式碼與資料，在未來也更容易改寫與調整。程式碼也更容易重新利用" +"、重新調整目標，或甚至淘汰。這一切特性都讓公共基礎建設可能遭遇的風險降到更低" +"。" + +#: ./foreword.md:block 39 (paragraph) +msgid "" +"This pooling of resources lets public administrations give extra attention " +"to how to customize the software so it works best in each local context, " +"creating better user experiences for their end users (residents or " +"citizens)." +msgstr "" +"這種將資源集中的作法，能讓公共行政單位可以有額外心力關注如何客製化軟體，來使" +"軟體最適合當地情境的需求，為終端使用者（居民或市民）創造更佳的使用體驗。" + +#: ./foreword.md:block 40 (header) +msgid "Economics of public code" +msgstr "公共程式的經濟效應" + +#: ./foreword.md:block 41 (paragraph) +msgid "" +"Public code offers a better economic model for public organizations as well " +"as for commercial companies. It's an alternative to traditional software " +"procurement which increases local control and economic opportunity." +msgstr "公共程式為公家機關以及商業公司，提供更好的經濟模型。公共程式作為替代傳統軟體" +"採購的方案，更能提升當地的掌控權並促進經濟機會。" + +#: ./foreword.md:block 42 (paragraph) +msgid "" +"Designed from the start to be open, adaptable and with data portability, it " +"can be developed by in-house staff or trusted vendors. Because the code is " +"open, the public administration can change vendors if they need to. Open " +"code increases opportunities for public learning and scrutiny, allowing the " +"public administration to procure smaller contracts. Smaller procurements are" +" easier for local small and medium enterprises to bid upon. Public " +"administrations can use their own software purchasing to stimulate " +"innovation and competition in their local economy." +msgstr "" +"公共程式從設計之初，就是要開放、適應力強、資料可攜，能夠由內部員工或信任的供" +"應商來開發。由於原始碼開放，公共行政單位在有需要時可以更換供應商。開放原始碼" +"讓社會大眾更有機會瞭解與監督公共程式，使公共行政單位得以採購小規模的合約，而" +"地方性的中小企業就更容易參與這些小型採購案的競標。如此一來，公共行政單位就可" +"以透過他們所需的軟體採購案，刺激當地經濟的創新與競爭。" + +#: ./foreword.md:block 43 (paragraph) +msgid "" +"This can be seen as investment leading to future economic growth. More " +"vendors will be necessary due to growing technology demand." +msgstr "這可視為對未來經濟成長的投資。隨著科技需求成長，也將需要更多供應商。" + +#: ./foreword.md:block 44 (header) +msgid "Procuring public code" +msgstr "購置公共程式" + +#: ./foreword.md:block 45 (paragraph) +msgid "" +"Public code can be used and developed by permanent in-house development " +"teams, contractors or outsourced suppliers. Vendors to public organizations " +"can include public code in their bids for contracts." +msgstr "公共程式可由常駐的內部研發團隊、承包商或外包供應商開發。公家機關的供應商，在" +"投標時可以在標案中納入公共程式。" + +#: ./foreword.md:block 46 (paragraph) +msgid "" +"To use existing public code, you need to specify in your budget and project " +"design that your new solution will use that codebase. To encourage an " +"innovative approach to adapting the public code to your context, you could " +"describe the service or outcome in your contract." +msgstr "" +"若要使用既有的公共程式，您將需要在預算以及專案設計中，明確指出新的解決方案將" +"會使用該程式基底。為了鼓勵創新，將公共程式依據您的情境背景作調整，您可在合約" +"中描述說明服務內容或預期成果。" + +#: ./foreword.md:block 47 (header) +msgid "The goals for the Standard for Public Code" +msgstr "《公共程式標準》目標" + +#: ./foreword.md:block 48 (paragraph) +msgid "" +"This Standard supports developers, designers, managers and public policy " +"makers to:" +msgstr "本標準在於支持開發人員、設計師、管理人員、公共政策制定者：" + +#: ./foreword.md:block 49 (unordered list) +msgid "" +"develop high quality software and policy for better public service delivery" +msgstr "開發出高品質的軟體與政策，來改善公共服務的交付" + +#: ./foreword.md:block 49 (unordered list) +msgid "" +"develop codebases that can be reused across contexts and collaboratively " +"maintained" +msgstr "開發出能在各種情境下重複使用，且以協作方式維護的程式基底" + +#: ./foreword.md:block 49 (unordered list) +msgid "reduce technical debt and project failure rate" +msgstr "減少技術債與專案失敗率" + +#: ./foreword.md:block 49 (unordered list) +msgid "" +"have more granular control over, and ability to make decisions about, their " +"IT systems" +msgstr "更能精細控制其 IT 系統粒度，並做出系統相關決策" + +#: ./foreword.md:block 49 (unordered list) +msgid "improve vendor relationships with a better economic model" +msgstr "以更好的經濟模型改善供應商關係" + +#: ./foreword.md:block 50 (paragraph) +msgid "" +"Potential users of codebases tested against the Standard for Public Code can" +" expect them to be highly reusable, easily maintainable and of high quality." +msgstr "如果有潛在使用者想採用經由《公共程式標準》測試過的程式基底，便可以預期這些程" +"式基底具有方便重複利用、容易維護、高品質的特性。" + +#: ./foreword.md:block 51 (paragraph) +msgid "The Standard for Public Code does this by:" +msgstr "《公共程式標準》能有此效果是基於：" + +#: ./foreword.md:block 52 (unordered list) +msgid "setting out a common terminology for public code development" +msgstr "為公共程式開發訂立通用術語" + +#: ./foreword.md:block 52 (unordered list) +msgid "establishing measures to help develop high quality public code" +msgstr "制定措施協助高品質公共程式的開發" + +#: ./foreword.md:block 52 (unordered list) +msgid "" +"providing guidance on how to fulfill its criteria and operationalize " +"compliance" +msgstr "提出該如何符合準則並實作遵循的指引" + +#: ./foreword.md:block 53 (paragraph) +msgid "" +"The Standard for Public Code is meant to be time and technology independent." +msgstr "《公共程式標準》設計精神就是要跨越時間與科技，不受其限制。" + +#: ./foreword.md:block 54 (header) +msgid "Who this is for" +msgstr "適用對象" + +#: ./foreword.md:block 55 (paragraph) +msgid "" +"The Standard for Public Code is for the people who create and reuse public " +"code:" +msgstr "《公共程式標準》適用於開發與重複使用公共程式的人：" + +#: ./foreword.md:block 56 (unordered list) +msgid "public policy makers" +msgstr "公共政策制定者" + +#: ./foreword.md:block 56 (unordered list) +msgid "business and project managers" +msgstr "業務與專案經理" + +#: ./foreword.md:block 56 (unordered list) +msgid "developers and designers" +msgstr "開發人員與設計師" + +#: ./foreword.md:block 57 (paragraph) +msgid "These people work at:" +msgstr "在以下單位服務的人：" + +#: ./foreword.md:block 58 (unordered list) +msgid "institutions, organizations and administrations in the public sector" +msgstr "社會機構、公家機關的組織與行政單位" + +#: ./foreword.md:block 58 (unordered list) +msgid "" +"consultancies and vendors of information technology and policy services to " +"public organizations" +msgstr "公家機關在資訊科技與政策服務上的顧問與供應商" + +#: ./foreword.md:block 59 (paragraph) +msgid "" +"It is not aimed at public organizations' end users (residents or citizens), " +"journalists or academics." +msgstr "適用對象不含公家機關的終端使用者（居民或市民）、記者或學者等。" + +#: ./foreword.md:block 61 (unordered list) +msgid "" +"[\"Modernising Public Infrastructure with Free Software\" white " +"paper](https://download.fsfe.org/campaigns/pmpc/PMPC-Modernising-with-Free-" +"Software.pdf) by the Free Software Foundation Europe." +msgstr "" +"歐洲自由軟體基金會所發表的[《透過自由軟體實現公共基礎設施現代化》白皮書](http" +"s://download.fsfe.org/campaigns/pmpc/PMPC-Modernising-with-Free-Software.pdf)" +" 》。" + +#: ./foreword.md:block 62 (header) +msgid "Videos on public code" +msgstr "探討公共程式的影片" + +#: ./foreword.md:block 63 (unordered list) +msgid "" +"[Collaborative Code is the Future of Cities @ DecidimFest " +"2019](https://www.youtube.com/watch?v=cnJtnZ9Cx1o). Talk by Ben Cerveny on " +"the background behind the Foundation for Public Code." +msgstr "" +"[「程式協作是城市的未來」@ DecidimFest 2019](https://www.youtube.com/" +"watch?v=cnJtnZ9Cx1o)。主講人 Ben Cerveny，講述 Foundation for Public Code " +"的背景。" + +#: ./foreword.md:block 63 (unordered list) +msgid "" +"[Public Money? Public Code! - Panel @ Nextcloud Conference " +"2019](https://youtube.com/watch?v=QHFkD4xfd6c). Touches on topics like " +"procurement, law and more." +msgstr "" +"[ 「用公共的納稅錢？做公共的程式吧！」專題討論 @ Nextcloud 大會 " +"2019](https://youtube.com/watch?v=QHFkD4xfd6c)。討論採購、法律等主題。" + +#: ./foreword.md:block 64 (header) +msgid "Get involved" +msgstr "參與我們" + +#: ./foreword.md:block 65 (paragraph) +msgid "" +"This standard is a living document. [Read our contributor " +"guide](/CONTRIBUTING.md) to learn how you can make it better." +msgstr "本標準是持續成長的文件。[請讀我們的〈貢獻者指引〉](/CONTRIBUTING." +"md)，瞭解您可以怎麼做來讓本標準變得更好。" + +#: ./foreword.md:block 66 (header) +msgid "Contact" +msgstr "聯絡方式" + +#: ./foreword.md:block 67 (paragraph) +msgid "" +"For questions and more information about the Foundation for Public Code you " +"can find us at [our website](https://publiccode.net/), email us at " +"info@publiccode.net, or call us at +31 20 2 444 500." +msgstr "" +"若有疑問，或想進一步瞭解 Foundation for Public " +"Code，請造訪[我們的網站](https://publiccode.net/)，或是寄電子郵件到 " +"info@publiccode.net，或撥打我們的電話 +31 20 2 444 500。" + +#: ./glossary.md:block 3 (header) +msgid "Glossary" +msgstr "詞彙表" + +#: ./glossary.md:block 4 (header) +msgid "Code" +msgstr "程式或程式碼 (Code)" + +#: ./glossary.md:block 5 (paragraph) +msgid "" +"Any explicitly described system of rules. This includes laws, policy and " +"ordinances, as well as source code that is used to build software. Both of " +"these are rules, some executed by humans and others by machines." +msgstr "" +"任何明確的規則系統，包括法律、政策與規則條例（法規、法式，也可稱為程式），以" +"及用來開發軟體的原始碼（程式碼）。兩者都是規則，有些是由人類來執行，其餘則是" +"由機器執行。" + +#: ./glossary.md:block 6 (header) +msgid "Codebase" +msgstr "程式基底 (Codebase)" + +#: ./glossary.md:block 7 (paragraph) +msgid "" +"Any discrete package of code (both source and policy), the tests and the " +"documentation required to implement a piece of policy or software." +msgstr "任何獨立分離的統合包，內含執行部分政策或軟體所需的程式（包含原始碼與政策）、" +"測試與文件等的整套內容。" + +#: ./glossary.md:block 8 (paragraph) +msgid "This can be, for example, a document or a version-control repository." +msgstr "舉例而言，這個具體形式可以是文件，或是版本控制的儲存庫。" + +#: ./glossary.md:block 9 (header) +msgid "Continuous integration" +msgstr "持續整合" + +#: ./glossary.md:block 10 (paragraph) +msgid "" +"In software engineering, continuous integration (CI) is the practice of " +"merging all developers' working copies to a development branch of a codebase" +" as frequently as reasonable." +msgstr "在軟體工程中，持續整合 (CI) 是盡可能頻繁地將所有開發人員工作中的副本，合併回" +"程式基底開發中分支的實務作法。" + +#: ./glossary.md:block 11 (header) +msgid "Different contexts" +msgstr "不同情境" + +#: ./glossary.md:block 12 (paragraph) +msgid "" +"Two contexts are different if they are different public organizations or " +"different departments for which there is not one decision maker that could " +"make collaboration happen naturally." +msgstr "只要是不同的公家機關或不同的部門，無法透過同一個決策單位讓協作自然發生，那就" +"算是兩個不同的情境。" + +#: ./glossary.md:block 13 (header) +msgid "General public" +msgstr "一般大眾" + +#: ./glossary.md:block 14 (paragraph) +msgid "" +"The public at large: end users of the code and the services based upon it." +msgstr "整體民眾：程式碼與其所建立的服務的終端使用者。" + +#: ./glossary.md:block 15 (paragraph) +msgid "" +"For example, a city's residents are considered end users of a city's " +"services and of all code that powers these services." +msgstr "舉例而言，城市的居民即視為該城市的服務、以及驅動這些服務運作的程式碼的終端使" +"用者。" + +#: ./glossary.md:block 16 (header) +msgid "Open source" +msgstr "開源或開放原始碼 (Open Source)" + +#: ./glossary.md:block 17 (paragraph) +msgid "" +"Open source is defined by the Open Source Initiative in their [Open Source " +"Definition](https://opensource.org/osd-annotated)." +msgstr "" +"所謂「開源」或「開放原始碼」，是根據 OSI " +"開放原始碼促進會發表的《[開放原始碼定義](https://opensource.org/osd-" +"annotated)》而來。" + +#: ./glossary.md:block 18 (header) +msgid "Open standard" +msgstr "開放標準" + +#: ./glossary.md:block 19 (paragraph) +msgid "" +"An open standard is any standard that meets the Open Source Initiative's " +"[Open Standard Requirements](https://opensource.org/osr)." +msgstr "任何符合 OSI 開放原始碼促進會《[開放標準需求規範](https://opensource.org/" +"osr)》的標準，就是開放標準。" + +#: ./glossary.md:block 20 (header) +msgid "Policy" +msgstr "政策" + +#: ./glossary.md:block 21 (paragraph) +msgid "" +"A policy is a deliberate system of principles to guide decisions and achieve" +" rational outcomes. A policy is a statement of intent, and is implemented as" +" a procedure or protocol. Policies are generally adopted by a governance " +"body within an organization. Policies can assist in both subjective and " +"objective decision making." +msgstr "" +"政策是一套謹慎設計的原則體系，用來引導決策並達成合理的成果。政策是一種意圖的" +"聲明，並以程序或協定來執行。政策通常是由組織單位內的理事機構採用執行。政策能" +"協助做出主觀與客觀的決策。" + +#: ./glossary.md:block 22 (paragraph) +msgid "" +"Public policy is the process by which governments translate their political " +"vision into programs and actions to deliver outcomes." +msgstr "公共政策是政府將其政治願景，轉化成計畫與行動來取得成果的程序。" + +#: ./glossary.md:block 23 (paragraph) +msgid "" +"At the national level, policy and legislation (the law) are usually " +"separate. The distinction is often more blurred in local government." +msgstr "在國家層級，政策與立法（法律）通常是分開的；而在地方政府中，這兩者之間的區別" +"通常比較模糊。" + +#: ./glossary.md:block 24 (paragraph) +msgid "" +"In the Standard the word 'policy' refers to policy created and adopted by " +"public organizations such as governments and municipalities." +msgstr "在本標準當中，「政策」一詞指的是公家機關，例如政府與自治市等，所制定與採用的" +"政策。" + +#: ./glossary.md:block 25 (header) +msgid "Public code" +msgstr "公共程式 (Public Code)" + +#: ./glossary.md:block 26 (paragraph) +msgid "" +"Public code is open source software developed by public organizations, " +"together with the policy and guidance needed for collaboration and reuse." +msgstr "公共程式，是由公家機關所開發的開放原始碼軟體，同時包含協作與重複利用所需的政" +"策與指引。" + +#: ./glossary.md:block 27 (paragraph) +msgid "" +"Public code is both computer source code (such as software and algorithms) " +"and public policy executed in a public context, by humans or machines." +msgstr "公共程式是在公共情境下，由人類或機器所執行的電腦原始碼（例如軟體與演算法）以" +"及公共政策兩者。" + +#: ./glossary.md:block 28 (paragraph) +msgid "" +"Public code serves the public interest, is open, legible, accountable, " +"accessible and sustainable." +msgstr "服務公眾利益的公共程式，具有開放、易懂、課責、近用、永續等特性。" + +#: ./glossary.md:block 29 (paragraph) +msgid "" +"By developing public code independently from but still implementable in the " +"local context for which it was developed, as well as documenting the " +"development process openly, public code can provide a building block for " +"others to:" +msgstr "" +"透過獨立於當地情境，但仍可在當地情境下實作的方式，還有公開以文件記錄開發程序" +"等作法，來開發公共程式。如此，公共程式能作為基礎組件提供給他人，使其得以：" + +#: ./glossary.md:block 30 (unordered list) +msgid "re-implement in their local context" +msgstr "根據其當地情境重新實作" + +#: ./glossary.md:block 30 (unordered list) +msgid "take as a starting point to continue development" +msgstr "作為起點並繼續開發" + +#: ./glossary.md:block 30 (unordered list) +msgid "use as a basis for learning" +msgstr "當作學習時的基礎" + +#: ./glossary.md:block 31 (paragraph) +msgid "" +"To facilitate reuse, public code is either released into the public domain " +"or licensed with an open license that permits others to view and reuse the " +"work freely and to produce derivative works." +msgstr "為了促進重複利用，公共程式通常放到公眾領域發行，或者採取允許他人能自由檢視、" +"重複利用其成果，甚至產出衍生作品的開放授權。" + +#: ./glossary.md:block 32 (header) +msgid "Repository" +msgstr "儲存庫" + +#: ./glossary.md:block 33 (paragraph) +msgid "" +"A repository is a storage location used by version control tools for files " +"and metadata of a codebase. Repositories allow multiple contributors to work" +" on the same set of files. Repositories are able to store multiple versions " +"of sets of files." +msgstr "" +"儲存庫是版本控制工具，用於存放程式基底的檔案與中介資料的儲存位置。儲存庫讓多" +"位貢獻者，得以同時對同一組檔案作業。儲存庫可以儲存一組檔案的多個版本。" + +#: ./glossary.md:block 34 (header) +msgid "Source Code" +msgstr "原始碼 (Source Code)" + +#: ./glossary.md:block 35 (paragraph) +msgid "" +"Human readable text of a computer program which can be translated into " +"machine instructions." +msgstr "人類可讀，並且能夠翻譯成機器指令的電腦程式文字。" + +#: ./glossary.md:block 36 (header) +msgid "Version control" +msgstr "版本控制" + +#: ./glossary.md:block 37 (paragraph) +msgid "" +"Version control is the management of changes to source code and the files " +"associated with it. Changes are usually identified by a code, termed the " +"*revision number* (or similar). Each revision is associated with the time it" +" was made and the person making the change, thus making it easier to retrace" +" the evolution of the code. Revision control systems can be used to compare " +"different versions with each other and to see how content has changed over " +"time." +msgstr "" +"版本控制，是對原始碼及其相關檔案的變動行為作管理的流程。變動行為，通常是以稱" +"為「*修訂編號*」（或版次等類似名稱）的代號作識別。每次修訂都會標示其改動時間" +"以及作者，方便追溯程式碼的演進。修訂控制系統可用來比較不同版本之間的差異，以" +"及查看內容隨著時間經歷的變動。" + +#: ./index.md:block 3 (header) +msgid "toc: false" +msgstr "toc: false" + +#: ./index.md:block 4 (header) +msgid "Guidance for government open source collaboration" +msgstr "政府開放原始碼協作指引" + +#: ./index.md:block 5 (paragraph) +msgid "" +"The Standard for Public Code is a set of criteria that supports public " +"organizations in developing and maintaining software and policy together." +msgstr "《公共程式標準》是一套支持公家機關一同協作開發軟體與政策，以及維護的準則。" + +#: ./index.md:block 6 (paragraph) +msgid "" +"The Standard for Public Code provides guidance to public organizations " +"building their own open source solutions to enable successful future " +"collaboration and reuse by similar organizations in the public sector in " +"other places. It includes advice for policy makers, government managers, " +"developers and vendors. The Standard for Public Code supports the " +"collaborative creation of codebases that are usable, open, legible, " +"accountable, accessible and sustainable. It is meant to be applicable to " +"codebases for all levels of government, from supranational to municipal." +msgstr "" +"《公共程式標準》為那些在建構自身開放原始碼解決方案的公家機關提供指引，以便他" +"們未來能成功與其他地方的類似公部門單位互相協作，並且重複使用各自的成果。這份" +"標準涵蓋寫給政策制定者、政府管理人員、開發人員與供應商的建議。《公共程式標準" +"》支持公家機關透過協作方式，創造出好用、開放、易懂、課責、近用、永續的程式基" +"底。這份標準從設計之初，就是要用於各種不同政府層級的程式基底，小從市政府，大" +"到超國家組織都行。" + +#: ./index.md:block 7 (paragraph) +msgid "" +"The Standard for Public Code defines ‘[public code](glossary.md#public-" +"code)’ as open source software developed by public organizations, together " +"with the policy and guidance needed for collaboration and reuse." +msgstr "" +"《公共程式標準》將「[公共程式](glossary.md#public-code)」定義為：由公家機關所" +"開發的開放原始碼軟體，同時包含協作與重複使用所需的政策與指引。" + +#: ./index.md:block 8 (paragraph) +msgid "" +"The criteria of the Standard for Public Code are aligned with guidelines and" +" best practices of open source software development." +msgstr "《公共程式標準》當中的準則，符合開放原始碼軟體開發的指引與最佳實務。" + +#: ./index.md:block 9 (paragraph) +msgid "" +"{% for page in site.pages %}{% if page.name == \"foreword.md\" %} Additional" +" context and background can be found in the [foreword](foreword.md). {% " +"endif%}{% endfor %}" +msgstr "" +"{% for page in site.pages %}{% if page.name == \"foreword.md\" %} " +"其他情境與背景資訊請參閱[序文](foreword.md)。 {% endif%}{% endfor %}" + +#: ./index.md:block 10 (header) +msgid "Contents" +msgstr "目次" + +#: ./index.md:block 11 (unordered list) +msgid "[Readers guide: how to interpret this standard](readers-guide.md)" +msgstr "[讀者指引：如何解讀本標準](readers-guide.md)" + +#: ./index.md:block 11 (unordered list) +msgid "[Glossary](glossary.md)" +msgstr "[詞彙表](glossary.md)" + +#: ./index.md:block 11 (unordered list) +msgid "" +"[Criteria](criteria/){% assign sorted = site.pages | sort:\"order\" %}{% for" +" page in sorted %}{% if page.dir == \"/criteria/\" %}{% if page.name != " +"\"index.md\" %}{% if page.title %}" +msgstr "" +"[準則](criteria/){% assign sorted = site.pages | sort:\"order\" %}{% for " +"page in sorted %}{% if page.dir == \"/criteria/\" %}{% if page.name != " +"\"index.md\" %}{% if page.title %}" + +#: ./index.md:block 11 (unordered list) +msgid "" +"[{{page.title}}]({{page.url}}){% endif%}{% endif%}{% endif%}{% endfor %}" +msgstr "" +"[{{page.title}}]({{page.url}}){% endif%}{% endif%}{% endif%}{% endfor %}" + +#: ./index.md:block 11 (unordered list) +msgid "[Authors](AUTHORS.md)" +msgstr "[作者群](AUTHORS.md)" + +#: ./index.md:block 11 (unordered list) +msgid "[Contributing guide](CONTRIBUTING.md)" +msgstr "[貢獻指引](CONTRIBUTING.md)" + +#: ./index.md:block 11 (unordered list) +msgid "[Code of conduct](CODE_OF_CONDUCT.md)" +msgstr "[行為守則](CODE_OF_CONDUCT.md)" + +#: ./index.md:block 11 (unordered list) +msgid "[Governance](GOVERNANCE.md)" +msgstr "[治理方式](GOVERNANCE.md)" + +#: ./index.md:block 11 (unordered list) +msgid "[Version history](CHANGELOG.md)" +msgstr "[版本歷史](CHANGELOG.md)" + +#: ./index.md:block 11 (unordered list) +msgid "[License](license.html)" +msgstr "[授權](license.html)" + +#: ./index.md:block 12 (header) +msgid "Community calls" +msgstr "社群會議" + +#: ./index.md:block 13 (paragraph) +msgid "" +"We usually have a community call on the first Thursday of the month at 15:00" +" (CET/CEST). [The agenda](https://write.publiccode.net/pads/Community-Call-" +"Standard-for-Public-Code) is updated roughly a week before the call. It is " +"possible to [sign " +"up](https://odoo.publiccode.net/survey/start/594b9243-c7e5-4bc1-8714-35137c971842)" +" to get a call invitation emailed to you." +msgstr "" +"我們通常在每月第一個週四的 15:00 (CET/CEST) " +"舉辦社群會議。[議程](https://write.publiccode.net/pads/Community-Call-" +"Standard-for-Public-Code)在會議前約一週的時間更新。您可以[註冊](https://odoo." +"publiccode.net/survey/start/" +"594b9243-c7e5-4bc1-8714-35137c971842)報名，會再寄送會議通話邀請函給您。" + +#: ./index.md:block 14 (header) +msgid "Other resources" +msgstr "其他資源" + +#: ./index.md:block 15 (unordered list) +msgid "" +"Unofficial [community translations of the " +"Standard](https://publiccodenet.github.io/community-translations-standard/) " +"in other languages" +msgstr "" +"本標準非官方的其他語言[社群翻譯](https://publiccodenet.github.io/" +"community-translations-standard/)" + +#: ./index.md:block 15 (unordered list) +msgid "" +"[Standard compliance self " +"assessment](https://publiccodenet.github.io/assessment-eligibility/) for " +"public sector open source codebases" +msgstr "" +"公部門開放原始碼程式基底的《[標準遵循自我評估](https://publiccodenet.github." +"io/assessment-eligibility/)》" + +#: ./index.md:block 15 (unordered list) +msgid "" +"[Standard criteria " +"checklist](https://github.com/publiccodenet/standard/blob/develop/docs/review-" +"template.html) used by Foundation for Public Code stewards for codebase " +"review" +msgstr "" +"Foundation for Public Code " +"執事人員審查程式基底時所使用的《[本標準準則檢查清單](https://github.com/" +"publiccodenet/standard/blob/develop/docs/review-template.html)》" + +#: ./readers-guide.md:block 3 (header) +msgid "Readers guide" +msgstr "讀者指引" + +#: ./readers-guide.md:block 4 (paragraph) +msgid "" +"The Standard describes a number of criteria. All criteria have consistent " +"sections that make it clear how to create great public code." +msgstr "本標準描述說明許多準則。所有準則各小節結構維持一致，來讓讀者清楚明白如何開發" +"良好的公共程式。" + +#: ./readers-guide.md:block 5 (paragraph) +msgid "" +"References to \"policy makers\", \"managers\", and \"developers and " +"designers\" apply to anyone performing duties associated with these roles, " +"regardless of their job title. It is common for individuals to have duties " +"which span multiple roles." +msgstr "「政策制定者」、「管理人員」以及「開發人員與設計師」的稱呼，係指任何履行這些" +"角色職責的人，不受其職稱限制。常見同時承擔多個角色職責的人。" + +#: ./readers-guide.md:block 6 (paragraph) +msgid "" +"Below is a brief explanation of each of these sections and how they are used" +" within the criteria of the Standard." +msgstr "以下是各小節的簡要介紹，以及在本標準準則中的作用。" + +#: ./readers-guide.md:block 7 (header) +msgid "Introduction" +msgstr "前言" + +#: ./readers-guide.md:block 8 (paragraph) +msgid "" +"This section explains what the criterion aims to achieve and why it is " +"important for a codebase's users and contributors." +msgstr "本小節說明這些準則想達成的目的，以及為何會對程式基底使用者與貢獻者來說這麼重" +"要的原因。" + +#: ./readers-guide.md:block 10 (paragraph) +msgid "" +"This section lists what needs to be done in order to comply with the " +"standard." +msgstr "這個小節列出如果要遵循本標準，需要完成哪些事項。" + +#: ./readers-guide.md:block 11 (paragraph) +msgid "" +"The following keywords in this document are to be interpreted as described " +"in [IETF RFC 2119](https://tools.ietf.org/html/rfc2119):" +msgstr "" +"本文件中的下列關鍵字，請以《[IETF RFC 2119](https://tools.ietf.org/html/" +"rfc2119)》的描述作解釋：" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "MUST" +msgstr "必須" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "MUST NOT" +msgstr "禁止" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "REQUIRED" +msgstr "要求" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "SHALL" +msgstr "應當" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "SHALL NOT" +msgstr "不得" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "SHOULD" +msgstr "應該" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "SHOULD NOT" +msgstr "不該" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "RECOMMENDED" +msgstr "建議" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "MAY" +msgstr "得以" + +#: ./readers-guide.md:block 12 (unordered list) +msgid "OPTIONAL" +msgstr "可選擇" + +#: ./readers-guide.md:block 14 (paragraph) +msgid "" +"This section offers actions you can take to see if a contribution is " +"compliant with the Standard. This is key if you want to operationalize the " +"Standard." +msgstr "本小節提供您可採取的行動，來確認貢獻內容是否遵循本標準。如果您想要務實操作本" +"標準，這部分很關鍵。" + +#: ./readers-guide.md:block 15 (paragraph) +msgid "" +"We've tried to word it so that someone who is not intimately acquainted with" +" the subject matter can still do a basic check for compliance." +msgstr "我們已嘗試調整用字，讓即使是不熟悉這類主題內容的讀者，看完之後也能夠進行基本" +"的遵循檢查。" + +#: ./readers-guide.md:block 17 (paragraph) +msgid "" +"This section tries to specifically speak to policy makers by offering them " +"concrete actions they can perform in their role." +msgstr "本小節主要對象是政策制定者，列出他們的角色所能採取的具體行動。" + +#: ./readers-guide.md:block 18 (paragraph) +msgid "" +"Public policy makers set the priorities and goals of projects and may be " +"less technologically experienced." +msgstr "公共政策制定者設定專案的優先順序與目標，而在科技上的經驗可能沒那麼多。" + +#: ./readers-guide.md:block 20 (paragraph) +msgid "" +"This section tries to specifically speak to managers by offering concrete " +"actions they can perform in their role." +msgstr "本小節主要對象是管理人員，列出他們的角色所能採取的具體行動。" + +#: ./readers-guide.md:block 21 (paragraph) +msgid "" +"Managers are responsible for on-time project delivery, stakeholder " +"management and continued delivery of the service. For this they are wholly " +"reliant on both policy makers as well as developers and designers. They need" +" to create the right culture, line up the right resources and provide the " +"right structures to deliver great services." +msgstr "" +"管理人員負責監督專案的準時交付、利害關係人管理，以及服務的持續交付。因此，他" +"們得完全依賴政策制定者、開發人員與設計師。他們需要塑造正確的文化、籌備合適的" +"資源、提供適當的架構等，才能交付優良的服務。" + +#: ./readers-guide.md:block 23 (paragraph) +msgid "" +"This section tries to specifically speak to developers and designers by " +"offering them concrete actions they can perform in their role." +msgstr "本小節主要對象是開發人員與設計師，列出他們的角色能採取的具體行動。" + +#: ./readers-guide.md:block 24 (paragraph) +msgid "" +"Developers are usually more technically aligned and have more impact on the " +"delivery of services than the previous groups." +msgstr "開發人員通常對技術比較在行，與其他角色類別相比，對服務交付的影響更大。" + +#: ./readers-guide.md:block 25 (header) +msgid "Limitation of scope" +msgstr "作用範圍限制" + +#: ./readers-guide.md:block 26 (paragraph) +msgid "" +"The Standard for Public Code is not meant to cover individual " +"implementations of a codebase. This means the standard does not tell " +"implementers how to comply with their organization's local technical " +"infrastructure or legal framework." +msgstr "《公共程式標準》不是為了涵蓋程式基底的個別實作而撰寫。這代表本標準不是要告訴" +"實作人員，該如何遵循其組織單位當地的技術性基礎建設或法律框架。" + +#: ./readers-guide.md:block 27 (paragraph) +msgid "" +"Also, while the Standard for Public Code refers to several standards and has" +" considerable overlap with others, its purpose is to enable collaboration. " +"Therefore, it does not aim to replace quality standards, like the ISO 25000 " +"series, or those focusing on security, like the [OpenSSF Best Practices " +"Badge](https://github.com/coreinfrastructure/best-practices-badge), but to " +"synergize well with them." +msgstr "" +"此外，雖然《公共程式標準》有引用一些標準，並且與其他標準有滿多重疊的部分，但" +"本標準的目的是要推動協作。因此，本標準目標不在於取代品質標準，像是 ISO 25000 " +"認證系列，或是取代那些聚焦於安全性的標準，例如 [OpenSSF " +"最佳實務標章](https://github.com/coreinfrastructure/best-practices-" +"badge)等，而是希望能與它們能良好協同搭配。" + +#: ./readers-guide.md:block 28 (paragraph) +msgid "" +"And while the purpose includes enabling collaboration, it will not guarantee" +" that a community will spring into existence. That still requires " +"proactiveness and ambition beyond making the codebase collaboration ready." +msgstr "" +"《公共程式標準》的目在於促進協作，但也無法保證能夠催生出一個社群。若要建立社" +"群，除了程式基底需要準備好進行協作以外，也需要積極主動，以及做到超越協作以外" +"的企圖心。" + +msgid "" +"script/release-body.sh expects VERSION in the first second-level header" +msgstr "script/release-body.sh 預期 VERSION 放在第一個第二層的標頭中" + +msgid "script/update-changelog-date.sh expects DATE-OF-RELEASE and a colon" +msgstr "script/update-changelog-date.sh 預期 DATE-OF-RELEASE 與一個冒號「:」" + +msgid "Version 0.7.1" +msgstr "0.7.1 版" + +msgid "" +"July 31st 2023: 💄 The sixteenth draft change the name of a criterion and " +"clarifies references to code." +msgstr "2023/07/31: 💄 第十六版草稿修改準則名稱，並釐清程式 code 的稱呼。" + +msgid "" +"The criterion \"Make the codebase reusable and portable\" was renamed from " +"\"Create reusable and portable code\"." +msgstr "〈程式碼要可重複使用且可攜〉準則改名為〈程式基底要可重複使用且可移植〉。" + +msgid "Added a glossary entry for \"Source Code\"." +msgstr "新增詞彙條目「原始碼」。" + +msgid "" +"References to \"code\" which only applied to \"source code\" now reference " +"\"source code\" explicitly." +msgstr "對於只適用於「原始碼」意義的「程式 (code)」，現在明確以「原始碼」稱呼。" + +msgid "Clarification of \"running code\" as \"software\"." +msgstr "將「運作的程式碼」釐清稱為「軟體」。" + +msgid "Minor changes to clarify \"code\" vs \"codebase\"." +msgstr "細微修改以清楚區分「程式碼」與「程式基底」。" + +msgid "Simplify guidance to policy makers in Bundle policy and source code." +msgstr "簡化給政策制定者在〈政策與原始碼要合捆〉中的指引。" + +msgid "" +"Clarify How to test sections of Make the codebase findable and Make the " +"codebase reusable and portable." +msgstr "釐清〈程式基底可查詢得到〉與〈程式基底要可重複使用且可移植〉的「測試方式」小" +"節。" + +msgid "Add a criteria and requirements checklist to the release artifacts." +msgstr "在發行成品前的要求中，加入準則與需求規定檢查清單。" + +msgid "Increase automation of the release process." +msgstr "提升發行流程的自動化程度。" + +msgid "" +"![version 0.7.1](assets/version-badge.svg) [![License: " +"CC0-1.0](https://img.shields.io/badge/License-" +"CC0_1.0-lightgrey.svg)](http://creativecommons.org/publicdomain/zero/1.0/) " +"[![Standard commitment](assets/standard-for-public-code-" +"commitment.svg)](#help-improve-this-standard)" +msgstr "" +"![version 0.7.1](assets/version-badge.svg) [![License: CC0-1.0](https://img." +"shields.io/badge/License-CC0_1.0-lightgrey.svg)](http://creativecommons.org/" +"publicdomain/zero/1.0/) [![標準承諾](assets/standard-for-public-code-" +"commitment.svg)](#help-improve-this-standard)" + +msgid "" +"If you want to apply the Standard for Public Code to your codebase, just go " +"ahead, it's an open standard and free for anyone to use. If you wish to " +"advertise the codebase community's aspiration to meet the criteria of the " +"Standard for Public Code, link the documentation of this commitment from the" +" [standard-for-public-code-commitment badge](assets/standard-for-public-" +"code-commitment.svg). To see how ready your codebase is, you can do a quick " +"[eligibility self assessment](https://publiccodenet.github.io/assessment-" +"eligibility) that will give you a rough idea of how much work you may need " +"to do to meet all criteria." +msgstr "" +"若您想要將《公共程式標準》套用您的程式基底，就請放心去做，因為它是人人都能自" +"由採用的開放標準。如果您希望宣傳程式基底社群達成《公共程式標準》準則要求時的" +"熱誠，請使用 [standard-for-public-code-commitment 徽章](assets/standard-for-" +"public-code-commitment.svg)連結到這份承諾文件。若要瞭解您程式基底所達成的程度" +"，可以做[自我資格評估](https://publiccodenet.github.io/assessment-" +"eligibility)；它能幫助您大略瞭解，如果想要滿足所有準則，還需要下多少功夫。" + +msgid "Update [`roadmap.md`](roadmap.md)" +msgstr "更新 [`roadmap.md`](roadmap.md)" + +msgid "" +"update `docs/standard-for-public-code.html` with the new text from the " +"review template, updating any status changes as a result" +msgstr "使用審查範本中的新文字來更新 `docs/standard-for-public-code." +"html`，會將任何狀態變更作為結果更新" + +msgid "" +"Push branch, compare with 'main' branch, i.e.: " +"`https://github.com/publiccodenet/standard/compare/main...release-$MAJOR.$MINOR.$PATCH`" +msgstr "" +"推送分支，與「main」分支比較，範例：`https://github.com/publiccodenet/" +"standard/compare/main...release-$MAJOR.$MINOR.$PATCH`" + +msgid "`git tag trigger-$MAJOR.$MINOR.$PATCH`" +msgstr "`git tag trigger-$MAJOR.$MINOR.$PATCH`" + +msgid "delete local tag: `git tag -d trigger-$MAJOR.$MINOR.$PATCH`" +msgstr "移除本地端的 tag 標記：`git tag -d trigger-$MAJOR.$MINOR.$PATCH`" + +msgid "Separate executive summary (issue #302)" +msgstr "分離執行摘要 (issue #302)" + +msgid "" +"[Standard criteria checklist](/docs/review-template.html) used by Foundation" +" for Public Code stewards for codebase review" +msgstr "" +"Foundation for Public Code 執事人員用於程式基底審查的《[標準準則檢查清單](/" +"docs/review-template.html)》" diff --git a/note.txt b/note.txt new file mode 100644 index 00000000..5b6150cb --- /dev/null +++ b/note.txt @@ -0,0 +1,7 @@ +(use docker) +1. 切換branch: i18n +2. 更新翻譯: git pull +3. 合併到: branch: ru8tp6 +4. 執行腳本: po2md.py(移除上一次的_site) +5. 處理jekyll-theme +6. 用github, git remote fetch \ No newline at end of file diff --git a/origin_source/404.md b/origin_source/404.md new file mode 100644 index 00000000..7a4a22bd --- /dev/null +++ b/origin_source/404.md @@ -0,0 +1,15 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2022-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +layout: default +title: Page not found +toc: false +--- + +# 404 Not Found + +If you typed the web address, check it is correct. + +If you pasted the web address, check you copied the entire address. + +If the web address is correct or you followed a link or button, email the [Foundation for Public Code staff](mailto:info@publiccode.net) so we'll be able to help you out, as well as correct our mistake. diff --git a/origin_source/AUTHORS.md b/origin_source/AUTHORS.md new file mode 100644 index 00000000..ef7f3f3a --- /dev/null +++ b/origin_source/AUTHORS.md @@ -0,0 +1,37 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +--- +# Authors + +* Alba Roza, [The Foundation for Public Code](https://publiccode.net/) +* Arnout Engelen +* Arnout Schuijff, The Foundation for Public Code +* Audrey Tang, [digitalminister.tw](https://digitalminister.tw/) +* Ben Cerveny, The Foundation for Public Code +* Bert Spaan +* Boris van Hoytema, The Foundation for Public Code +* Charlotte Heikendorf +* Claus Mullie, The Foundation for Public Code +* David Barberi +* Edo Plantinga, [Code For NL](https://codefor.nl/) +* Elena Findley-de Regt, The Foundation for Public Code +* Eric Herman, The Foundation for Public Code +* Felix Faassen, The Foundation for Public Code +* Floris Deerenberg +* Jan Ainali, The Foundation for Public Code +* Johan Groenen, Code For NL +* Marcus Klaas de Vries +* Mark van der Net, [Gemeente Amsterdam](https://www.amsterdam.nl/en/) +* Martijn de Waal, [Amsterdam University of Applied Sciences (AUAS)](https://www.amsterdamuas.com/), Faculty of Digital Media and Creative Industries, Lectorate of Play & Civic Media +* Matti Schneider +* Mauko Quiroga +* Maurice Hendriks, Gemeente Amsterdam +* Maurits van der Schee, Gemeente Amsterdam +* Mirjam van Tiel, The Foundation for Public Code +* Ngô Ngọc Đức Huy +* Paul Keller +* Petteri Kivimäki, [Nordic Institute for Interoperability Solutions (NIIS)](https://niis.org) +* Sky Bristol +* Tamas Erkelens, Gemeente Amsterdam +* Timo Slinger diff --git a/origin_source/CC0-1.0.md b/origin_source/CC0-1.0.md new file mode 100644 index 00000000..7cadbfc4 --- /dev/null +++ b/origin_source/CC0-1.0.md @@ -0,0 +1,19 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2022-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +toc: false +redirect_from: + - license.html + - LICENSE.html +--- + +# Creative Commons Zero v1.0 Universal + + + + +This license is the legal contract that allows anyone to do anything they like with the content in this entire document. + +```text +{% include_relative LICENSE %} +``` diff --git a/origin_source/CHANGELOG.md b/origin_source/CHANGELOG.md new file mode 100644 index 00000000..8464dc27 --- /dev/null +++ b/origin_source/CHANGELOG.md @@ -0,0 +1,247 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +# script/release-body.sh expects VERSION in the first second-level header +# script/update-changelog-date.sh expects DATE-OF-RELEASE and a colon +--- +# Version history + +## Version 0.7.1 + +July 31st 2023: 💄 The sixteenth draft change the name of a criterion and clarifies references to code. + +* The criterion "Make the codebase reusable and portable" was renamed from "Create reusable and portable code". +* Added a glossary entry for "Source Code". +* References to "code" which only applied to "source code" now reference "source code" explicitly. +* Clarification of "running code" as "software". +* Minor changes to clarify "code" vs "codebase". +* Simplify guidance to policy makers in Bundle policy and source code. +* Clarify How to test sections of Make the codebase findable and Make the codebase reusable and portable. +* Add a criteria and requirements checklist to the release artifacts. +* Increase automation of the release process. + +## Version 0.7.0 + +May 31st 2023: 📑 the fifteenth draft adds new requirements for documenting review funding and clarifies review process requirement. + +* Add requirement to document who is expected to cover the cost of reviewing contributions. +* Add requirement to have a short description of the codebase. +* Change the focus of contributions adhering to standards to focus on the review of contributions. +* Relaxed MUST requirements to SHOULD in Make the codebase findable. +* Review template now in HTML format. +* Introduction converted to foreword. +* Improved contributing guidelines. +* Improved documentation of scripts. + +## Version 0.6.0 + +April 20th 2023: 🔀 the fourteenth draft adds new requirements for portability and tests and an introduction to each criterion. + +* New requirement in Create reusable and portable code about the development being a collaboration between multiple parties. +* New requirement in Create reusable and portable code about being dependent on a single vendor. +* New requirement in Use continuous integration about publishing results for automated tests. +* Differentiating the two requirements about security to clearly be about providing a method and having documentation about it. +* Rephrased requirements to focus on the codebase rather than contributor behavior. +* Removed the sections Why this is important and What this does not do and replaced with an introduction in each criterion. +* Added general What this does not do section in the introduction of the Standard. +* Added guidance for public policy makers about related policies and license compatibility. +* Added guidance for developers and designers about version controlling files. +* Clarified guidance for developers and designers about prompt responses and search engine optimization. +* Added Further reading about accessibility. +* Aligned criteria URLs with criteria names. +* Improved navigation in the web version. +* Moved tools in Further reading sections to the community implementation guide. +* Moved compliance or certification process to [publiccode.net](https://publiccode.net). +* Change format of the review template to make it easier to update after a new release. +* Improved the text on the landing page and added links to related resources. +* Added spell checker automated test. +* Made minor changes to text for clarity and consistency. +* Moved SPDX headers to yaml header. + +## Version 0.5.0 + +January 25th 2023: 🎨 the thirteenth draft focuses on documenting style guidelines. + +* Adjust the coding style requirement to focus on the codebase using a style guide rather than contributor behavior. +* Moved requirement for codebase names to Make the codebase findable from Use plain English. +* Moved requirement about testing the code by using examples to Use continuous integration from Document the code. +* Split requirement about machine testable standards to clarify that open is more important than testable. +* Adjust how to test findability requirements to be less reliant on search engine algorithms. +* Made minor changes to text for clarity and consistency. + +## Version 0.4.1 + +December 5th 2022: 📝 the twelfth draft clarifies document maturity. + +* Document maturity focuses on whether or not versions of the codebase are ready to use. +* Document maturity no longer requires specific labels for codebases that are not ready to use. +* Audit flow image now generated from an easier to translate format. +* Improved guidance on How to test. +* Add publiccode.yml file. +* Add review template. +* Consistently link glossary terms. +* Add practices and standards to follow in CONTRIBUTING. +* Add Matti Schneider to Authors. +* Add remaining SPDX headers to files. +* Made additional minor changes to text for clarity. +* Some hyperlinks updated. +* Moved examples to the [Community implementation guide](https://publiccodenet.github.io/community-implementation-guide-standard/). + +## Version 0.4.0 + +September 7th 2022: 🔭 the eleventh draft adds a new findability criterion. + +* Introduce new criterion: Make the codebase findable. +* Improve How to test section for most criteria. +* New requirement in Welcome contributors about publishing activity statistics. +* Removed redundant requirement about portable and reusable code. +* Expand open license definition to include both OSI and FSF approved licenses. +* Rephrase MAY requirements to use the keyword OPTIONAL for clarity. +* Expressed intent that the Standard for Public Code should meet its own requirements where applicable and added assessment. +* Add SPDX license identifiers to files. +* Introduced new Code of Conduct. +* Clarify distinction between source code and policy text. +* Restructuring of requirements with bullet point lists. +* Acknowledge the importance of codebase modularity for reuse. +* Move requirements related to Findability to the new criterion. +* Clarify the role of non-open standards when used in a codebase. +* Additional guidance about build-time and runtime dependencies. +* Added roadmap for the development of the Standard for Public Code. +* Update structure of Authors file. +* Add Audrey Tang to Authors. +* Added a list of criteria to the print edition. +* Clarify what the standard means with policymakers, managers, developers and designers. +* Made additional minor changes to text for clarity. +* Some hyperlinks updated. + +## Version 0.3.0 + +May 23rd 2022: 🗎 the tenth draft strengthens documentation and localization. + +* Requirement for localization made explicit in Create reusable and portable code. +* Documentation of governance changed from a SHOULD to a MUST. +* Replace the very subjective (and hard to test) "contributions MUST be small" with requirement to document expectation in contributing guidelines and focus on a single issue. +* Community translations now linked in the footer. +* Revert "Replace BPMN svg with Mermaid flowchart". +* Many minor clarifications to language and sentences made more simple. +* Some hyperlinks updated. + +## Version 0.2.3 + +March 15th 2022: 📜 the ninth draft allows English summaries for policy lacking an official translation. + +* Relax the criterion Use plain English by adding a new requirement allows bundled policy not available in English to have an accompanying summary in English instead of translating the full text. +* Similarly, allow for English summaries for policies not available in English in Bundle policy and code. +* Clarify that term 'policy' includes processes which impact development and deployment in Bundle policy and code. +* Emphasize reusability also on parts of the solutions in Create reusable and portable code. +* Expand guidance to Developers and designers in Create reusable and portable code about deploying to proprietary platforms. +* Add nuance to use of non-English terms in what management need to do in Use plain English. +* Change the pull request process diagram to use Mermaid instead of BPMN to make [community translations](https://github.com/publiccodenet/community-translations-standard) easier. +* Added Maurice Hendriks to AUTHORS. +* Added OpenApi Specification to further reading. +* Made the attributions in further reading sections clearer. +* Made additional minor changes to text for clarity. + +## Version 0.2.2 + +November 29th 2021: 🏛 the eighth draft recognizes that policy which executes as code may not be in English. + +* Document exception to "All code MUST be in English" where policy is interpreted as code. +* Add MAY requirement regarding committer email addresses in Maintain version control. +* Expand guidance to Policy Makers in Bundle policy and code. +* Expand guidance to Developers and designers in Use a coherent style. +* Add "Different contexts" to glossary. +* Add Mauko Quiroga and Charlotte Heikendorf to AUTHORS. +* Add Digital Public Goods approval badge. +* Added "next" and "previous" links to criteria pages of web version. +* Add Open Standards principles to further reading. +* Add Definition of plain language to further reading. +* Move the Semantic Versioning Specification further reading reference. +* Clarify that publiccode.yml is one example of a machine-readable metadata description. +* Changed "your codebase" and "your organization" to be less possessive. +* Made additional minor changes to text for clarity. +* Add instructions for creating a print version. + +## Version 0.2.1 + +March 1st 2021: 🧽 the seventh draft has minor cleaning up after version 0.2.0. + +* New SHOULD requirement on using a distributed version control system and why distributed is important. +* Feedback requirements for rejected contributions are more strict than accepted ones. +* Specify that copyright and license notices should also be machine-readable. +* Advice on how to test that notices be machine-readable. +* Clarify guidance for rolling releases. +* Clear up definition of version control in glossary. +* Add further reading encouraging contribution, SPDX, Git and reviewing contributions. +* Add links to videos about the concept of public code. +* Update BPMN link. +* Reduce link duplication. +* Add Alba Roza and Ngô Ngọc Đức Huy to authors. +* Made additional minor changes to text for clarity. + +## Version 0.2.0 + +October 26th 2020: 🎊 the sixth draft splits a requirement and adds clarity. + +* Split "Welcome contributions" criterion into "Make contributing easy" and "Welcome contributors". +* Rename criterion "Pay attention to codebase maturity" to "Document codebase maturity". +* Changed MUST to SHOULD for requirement of codebase in use by multiple parties. +* Add MUST NOT requirement regarding copyright assignment. +* Clarify role of configuration in reusable code requirement. +* Glossary additions: continuous integration, policy, repository, and version control. +* Replace references to 'cities' with 'public organizations'. +* Clarify aspects of sensitive code by separating contributor and reviewer requirements into separate items. +* Expand further reading, and guidance to policy makers, developers and designers. +* Add Felix Faassen and Arnout Engelen to authors. +* Made additional minor changes to text for clarity. + +## Version 0.1.4 + +November 27th 2019: 🧹 the fifth draft consists mostly of additional minor fixes. + +* Linked License.md file. +* Add Sky Bristol, Marcus Klaas de Vries, and Jan Ainali to authors. +* Made punctuation more consistent, especially for bullet lists. +* Made some minor changes to text for clarity. + +## Version 0.1.3 + +October 8th 2019: 🍂 the fourth draft only patches and fixes minor things for the autumn cleaning + +* Renamed continuous delivery to continuous integration. +* Referencing accessibility guidelines in the language standard. +* A bunch of style and consistency fixes. + +## Version 0.1.2 + +August 22th 2019: 🌠 the third draft focuses on better text and takes community input + +* With some great new contributors comes a fresh author list. +* All links are now HTTPS. +* General proofreading, wording clarifications, and smashed typos. +* Updated criteria: + * Requirement for reuse in different contexts + * Recommendation for explicit versioning + * Recommendation for multi party development + * Recommendation for license headers in files + * Recommendation for vulnerability reporting + * Recommendation for explicit documentation of governance + +## Version 0.1.1 + +May 9th 2019: 🤔 the second draft fixes a few basic oversights and fixes a lot of typos + +* Removed references to the Foundation for Public Code, we're going to have to change the name in becoming an association. +* Updated the introduction. +* Updated the glossary. +* Added the code of conduct. +* We've recommended using the publiccode.yml standard for easier reuse. + +## Version 0.1.0 + +April 16th 2019: 🎉 the first draft is ready, it is all brand new and has snazzy new ideas in it + +* 14 criteria with their requirements and how to operationalize them. +* An introduction with a high level background, what this standard is, and how the Foundation for Public Code will use it. + +This first version was produced together with the Amsterdam University of Applied Sciences and the City of Amsterdam as a part of the [Smart Cities? Public Code! project](https://smartcities.publiccode.net/). diff --git a/origin_source/CODE_OF_CONDUCT.md b/origin_source/CODE_OF_CONDUCT.md new file mode 100644 index 00000000..b63243fd --- /dev/null +++ b/origin_source/CODE_OF_CONDUCT.md @@ -0,0 +1,15 @@ +# Code of Conduct + + + + +Many community members are from civic or professional environments with behavioral codes yet some individuals are not. +This document expresses expectations of all community members and all interactions regardless of communication channel. + +Be here to collaborate. + +Be considerate, respectful, and patient. + +Strive to be as constructive as possible. + +To raise a concern, please email directors@publiccode.net. diff --git a/origin_source/CONTRIBUTING.md b/origin_source/CONTRIBUTING.md new file mode 100644 index 00000000..07c6fbab --- /dev/null +++ b/origin_source/CONTRIBUTING.md @@ -0,0 +1,103 @@ +# Contributing to this standard + + + + +🙇‍♀️ Thank you for contributing! + +We understand that a standard like this can only be set in collaboration with as many public technologists, policy makers and interested folk as possible. +Thus we appreciate your input, enjoy feedback and welcome improvements to this project and are very open to collaboration. + +We love issues and pull requests from everyone. +If you're not comfortable with GitHub, you can email use your feedback at . + +## Problems, suggestions and questions in issues + +A high-level overview of the development that we already have sketched out can be seen in the [roadmap](/docs/roadmap.md). +Please help development by reporting problems, suggesting changes and asking questions. +To do this, you can [create a GitHub issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue) for this project in the [GitHub Issues for the Standard for Public Code](https://github.com/publiccodenet/standard/issues). + +Or, sign up to the [mailing list](https://lists.publiccode.net/mailman/postorius/lists/standard.lists.publiccode.net/) and send an email to +[standard@lists.publiccode.net](mailto:standard@lists.publiccode.net). + +You don't need to change any of our code or documentation to be a contributor! + +## Documentation and code in pull requests + +If you want to add to the documentation or code of one of our projects you should make a pull request. + +If you never used GitHub, get up to speed with [Understanding the GitHub flow](https://docs.github.com/en/get-started/quickstart/github-flow) or follow one of the great free interactive courses in [GitHub Skills](https://skills.github.com/) on working with GitHub and working with MarkDown, the syntax this project's documentation is in. + +This project is licensed Creative Commons Zero v1.0 Universal, which essentially means that the project, along with your contributions is in the public domain in whatever jurisdiction possible, and everyone can do whatever they want with it. + +### 1. Make your changes + +Contributions should [follow](docs/standard-for-public-code.html) the requirements set out in the criteria of the Standard for Public code itself. +Reviewers will also be ensuring that contributions are aligned with the [values of public code](foreword.md#values-of-public-code). +Furthermore, they will review that the contribution conforms to the [standards](#standards-to-follow) and remains coherent with the overall work. + +This project uses the [GitFlow branching model and workflow](https://nvie.com/posts/a-successful-git-branching-model/). +When you've forked this repository, please make sure to create a feature branch following the GitFlow model. + +Add your changes in commits [with a message that explains them](https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message). +If more than one type of change is needed, group logically related changes into separate commits. +For example, white-space fixes could be a separate commit from text content changes. +When adding new files, select file formats that are easily viewed in a `diff`, for instance, `.svg` is preferable to a binary image. +Document choices or decisions you make in the commit message, this will enable everyone to be informed of your choices in the future. + +If you are adding code, make sure you've added and updated the relevant documentation and tests before you submit your pull request. +Make sure to write tests that show the behavior of the newly added or changed code. + +#### Applicable policy + +Currently, the Standard for Public Code is not implementing any specific public policy. + +#### Style + +The Standard for Public Code aims to [use plain English](criteria/use-plain-english.md) and we have chosen American English for spelling. +Text content should typically follow one line per sentence, with no line-wrap, in order to make `diff` output easier to view. +However, we want to emphasize that it is more important that you make your contribution than worry about spelling and typography. +We will help you get it right in our review process and we also have a separate quality check before [making a new release](docs/releasing.md). + +#### Standards to follow + +These are the standards that the Standard for Public Code uses. +Please make sure that your contributions are aligned with them so that they can be merged more easily. + +* [IETF RFC 2119](https://tools.ietf.org/html/rfc2119) - for requirement level keywords +* [Web Content Accessibility Guidelines 2.1](https://www.w3.org/TR/WCAG21/#readable) - for readability + +### 2. Pull request + +When submitting the pull request, please accompany it with a description of the problem you are trying to solve and the issue number that this pull request fixes. +It is preferred for each pull request to address a single issue where possible. +In some cases a single set of changes may address multiple issues, in which case be sure to list all issue numbers fixed. + +### 3. Improve + +All contributions have to be reviewed by someone. +The Foundation for Public Code has committed to make sure that maintainers are available to review contributions with an aim to provide feedback within two business days. + +It could be that your contribution can be merged immediately by a maintainer. +However, usually, a new pull request needs some improvements before it can be merged. +Other contributors (or helper robots) might have feedback. +If this is the case the reviewing maintainer will help you improve your documentation and code. + +If your documentation and code have passed human review, it is merged. + +### 4. Celebrate + +Your ideas, documentation and code have become an integral part of this project. +You are the open source hero we need! + +In fact, feel free to open a pull request to add your name to the [`AUTHORS`](AUTHORS.md) file and get eternal attribution. + +## Translations in other languages + +While the Standard does not have any official translations, you can help maintain existing and add new [community translations of the Standard](https://github.com/publiccodenet/community-translations-standard). + +## Releases + +We have dedicated documentation for creating [new releases](/docs/releasing.md) and [ordering printed standards](/docs/printing.md). + +For more information on how to use and contribute to this project, please read the [`README`](README.md). diff --git a/origin_source/GOVERNANCE.md b/origin_source/GOVERNANCE.md new file mode 100644 index 00000000..3a0cfd12 --- /dev/null +++ b/origin_source/GOVERNANCE.md @@ -0,0 +1,18 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2022 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +--- +# Governance + +This standard lies at the core of the codebase stewardship provided by the [Foundation for Public Code](https://publiccode.net/). +We decide if a codebase is ready for community co-development based on this document. + +The standard is maintained by Foundation for Public Code staff. + +[We welcome contributions, such as suggestions for changes or general feedback, from anyone.](/CONTRIBUTING.md) + +Because of the important role that the Standard for Public Code has in our core process we require the highest standards from the Standard. + +We will try to respond promptly to all pull requests. +The pull request is an opportunity to work together to improve our methods and the Standard. +We may not accept all changes, but we will explain our logic. diff --git a/origin_source/README.md b/origin_source/README.md new file mode 100644 index 00000000..b90f5e3c --- /dev/null +++ b/origin_source/README.md @@ -0,0 +1,107 @@ +# Standard for Public Code + + + + +The Standard for Public Code gives public organizations a model for preparing open source solutions to enable collaborations with similar public organizations in other places. +It includes guidance for policy makers, city administrators, developers and vendors. + +![version 0.7.1](assets/version-badge.svg) +[![License: CC0-1.0](https://img.shields.io/badge/License-CC0_1.0-lightgrey.svg)](http://creativecommons.org/publicdomain/zero/1.0/) +[![Standard commitment](assets/standard-for-public-code-commitment.svg)](#help-improve-this-standard) + +[![pages-build-deployment](https://github.com/publiccodenet/standard/actions/workflows/pages/pages-build-deployment/badge.svg)](https://github.com/publiccodenet/standard/actions/workflows/pages/pages-build-deployment) +[![Test](https://github.com/publiccodenet/standard/actions/workflows/test.yml/badge.svg)](https://github.com/publiccodenet/standard/actions/workflows/test.yml) +[![standard main badge](https://publiccodenet.github.io/publiccodenet-url-check/badges/standard.publiccode.net.svg)](https://publiccodenet.github.io/publiccodenet-url-check/standard.publiccode.net-url-check-look.json) +[![standard develop badge](https://publiccodenet.github.io/publiccodenet-url-check/badges/standard.publiccode.net-develop.svg)](https://publiccodenet.github.io/publiccodenet-url-check/standard.publiccode.net-develop-url-check-look.json) + +The Standard for Public Code is in a draft format. +We are preparing it for a version 1.0 release. +Currently, we are testing it on a small number of codebases. + +## Applying the Standard for Public Code to your codebase + +If you want to apply the Standard for Public Code to your codebase, just go ahead, it's an open standard and free for anyone to use. +If you wish to advertise the codebase community's aspiration to meet the criteria of the Standard for Public Code, link the documentation of this commitment from the [standard-for-public-code-commitment badge](assets/standard-for-public-code-commitment.svg). +To see how ready your codebase is, you can do a quick [eligibility self assessment](https://publiccodenet.github.io/assessment-eligibility) that will give you a rough idea of how much work you may need to do to meet all criteria. + +The standard *should* be mostly self-explanatory in how to apply it to your codebase. +If anything in the standard is unclear, we encourage you to open an issue here so that we can help you and anyone else who feels the same as you. +For inspiration, look at the [community built implementation guide](https://publiccodenet.github.io/community-implementation-guide-standard/) which contains examples and other tips. + +If there are any breaking changes in a new version of the Standard for Public Code, the codebase stewards at the Foundation for Public Code will help any implementers of the standard understand how the gaps can be closed. + +If you want to commit your codebase to become fully compliant to the standard for future certification, please contact us at to initiate a formal [assessment](https://about.publiccode.net/activities/codebase-stewardship/lifecycle-diagram.html#assessment). + +## Request for contributions + +We believe public policy and software should be inclusive, usable, open, legible, accountable, accessible and sustainable. +This means we need a new way of designing, developing and procuring both the source code and policy documentation. + +This standard sets a quality level for codebases that meets the needs of public organizations, institutions and administrations as well as other critical infrastructural services. + +The standard lives at [standard.publiccode.net](https://standard.publiccode.net/). +See [`index.md`](index.md) for an overview of all content. + +[![Thumbnail for the video on the Standard for Public Code: a printed version lying on a table between two hands](https://img.youtube.com/vi/QWt6vB-cipE/mqdefault.jpg)](https://www.youtube.com/watch?v=QWt6vB-cipE) + +[A video introduction to Standard for Public Code](https://www.youtube.com/watch?v=QWt6vB-cipE) from Creative Commons Global Summit 2020 (4:12) on YouTube. + +## Help improve this standard + +The Foundation for Public Code is committed to maintaining and developing the Standard for Public Code at a level of quality that meets the standard itself. + +We are looking for people like you to [contribute](CONTRIBUTING.md) to this project by suggesting improvements and helping develop it. 😊 +Get started by reading our [contributors guide](CONTRIBUTING.md). +Since it is such a core document we will accept contributions when they add significant value. +We've described how we govern the standard in the [governance statement](GOVERNANCE.md). + +Please note that this project is released with a [code of conduct](CODE_OF_CONDUCT.md). +By participating in this project you agree to abide by its terms. +Please be lovely to all other community members. + +## Preview, build and deploy + +The repository builds to a static site deployed at [standard.publiccode.net](https://standard.publiccode.net/). +It is built with [GitHub pages](https://pages.github.com) and [Jekyll](https://jekyllrb.com/). + +The content is made to be built with [Jekyll](http://jekyllrb.com/), which means you will need ruby and ruby-bundler installed, for example: + +```bash +sudo apt-get install -y ruby ruby-bundler +``` + +If `ruby` and `bundle` are installed, one can run `bundle install` after which the site can be rendered with the `script/serve.sh` script. + +### Testing + +A variety of test scripts are included. +The script `script/test-all.sh` wraps running of all local tests. + +See the scripts in the [script](https://github.com/publiccodenet/standard/tree/main/script) folder. + +### Generating a PDF of the Standard for Public Code + +In addition to Jekyll, generating PDFs relies upon [Weasyprint](https://weasyprint.org/) and [QPDF](https://github.com/qpdf/qpdf). +[Pandoc](https://pandoc.org/) can be used to transform PDFs into `.epub`. + +To generate these kinds of files, the dependencies should be installed, for example: + +```bash +sudo apt-get install -y pandoc qpdf weasyprint +``` + +The file `standard-print.html` can be converted to a nice looking PDF, along with the other release files, using: + +```bash +script/pdf.sh +``` + +## License + +© [The authors and contributors](AUTHORS.md) + +The standard is [licensed](LICENSE) under CC 0, which also applies to all illustrations and the documentation. +This means anyone can do anything with it. +If you contribute you also grant these rights to others. +You can read more about how to help in the [contributing guide](CONTRIBUTING.md). diff --git a/origin_source/criteria/bundle-policy-and-source-code.md b/origin_source/criteria/bundle-policy-and-source-code.md new file mode 100644 index 00000000..39334f54 --- /dev/null +++ b/origin_source/criteria/bundle-policy-and-source-code.md @@ -0,0 +1,56 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +order: 2 +redirect_from: + - criteria/bundle-policy-and-code +--- +# Bundle policy and source code + +Access to both [source code](../glossary.md#source-code) and [policy](../glossary.md#policy) documentation provides building blocks for anyone to implement the codebase in their local context or contribute to the further development of the [codebase](../glossary.md#codebase). + +Understanding the domain and policies within that domain is fundamental to understanding what problems a codebase is trying to solve and how it sets out to solve them. + +To be able to evaluate whether to implement a codebase in a new context, an organization needs to understand what process changes it must choose to make or how to contribute additional configurability to the existing solution in order to adapt it to the new context. + +## Requirements + +* The codebase MUST include the policy that the source code is based on. +* If a policy is based on source code, that source code MUST be included in the codebase, unless used for fraud detection. +* Policy SHOULD be provided in machine readable and unambiguous formats. +* [Continuous integration](../glossary.md#continuous-integration) tests SHOULD validate that the source code and the policy are executed coherently. + +## How to test + +* Confirm with a civil servant that all policy that the source code is based on is included. +* Confirm with a civil servant that all source code that the policy is based on is included. +* Check if policy can be interpreted by a machine. +* Check the continuous integration tests for coherent execution of source code and policy pass. + +## Public policy makers: what you need to do + +* Collaborate with developers and designers to make sure there is no mismatch between policy code and source code. +* Provide the relevant policy texts for inclusion in the [repository](../glossary.md#repository); if the text is not available in English, also provide an English summary. Be sure to include standards that your organization has chosen to adhere to and any organizational processes which impact the development or the deployment context of the codebase for your organization. +* Provide references and links to texts which support the policies. +* Document policy in formats that are unambiguous and machine-readable, such as those published by the [Object Management Group](https://www.omg.org/spec/). +* Track policy with [the same version control](maintain-version-control.md) and documentation used to track source code. +* Check in regularly to understand how the source code in the codebase has changed and whether it still matches the [intentions of the policy](document-codebase-objectives.md). +* Include relevant policies which impact the community, codebase, and development, including legal obligations like the [General Data Protection Regulation](https://eur-lex.europa.eu/eli/reg/2016/679/oj) or the [EU Web Accessibility Directive](https://ec.europa.eu/digital-single-market/en/web-accessibility), or human rights policies, like a public organization's commitment to equal opportunity. + +## Managers: what you need to do + +* Keep policy makers, developers and designers involved and connected throughout the whole development process. +* Make sure policy makers, developers and designers are working to the same objectives. + +## Developers and designers: what you need to do + +* Become familiar with and be able to use the process modelling notation that the policy makers in your organization use. +* Work together with policy makers to make sure there is no mismatch between policy code and source code. +* Give feedback on how to make policy documentation more clear. + +## Further reading + +* [Business Process Model and Notation](https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation) on Wikipedia. +* [BPMN Quick Guide](https://www.bpmnquickguide.com/view-bpmn-quick-guide/) by Trisotech. +* [Decision Model and Notation](https://en.wikipedia.org/wiki/Decision_Model_and_Notation) on Wikipedia. +* [Case Management Model Notation](https://en.wikipedia.org/wiki/CMMN) on Wikipedia. diff --git a/origin_source/criteria/code-in-the-open.md b/origin_source/criteria/code-in-the-open.md new file mode 100644 index 00000000..b325ab2b --- /dev/null +++ b/origin_source/criteria/code-in-the-open.md @@ -0,0 +1,47 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +order: 1 +--- +# Code in the open + +Coding in the open improves transparency, increases [source code](../glossary.md#source-code) quality, makes the source code easier to audit, and enables collaboration. + +Together, this creates more opportunities for citizens to understand how software and [policy](../glossary.md#policy) impact their interactions with a public organization. + +## Requirements + +* All source code for any policy in use (unless used for fraud detection) MUST be published and publicly accessible. +* All source code for any software in use (unless used for fraud detection) MUST be published and publicly accessible. +* The codebase MUST NOT contain sensitive information regarding users, their organization or third parties. +* Any source code not currently in use (such as new versions, proposals or older versions) SHOULD be published. +* Documenting which source code or policy underpins any specific interaction the [general public](../glossary.md#general-public) may have with an organization is OPTIONAL. + +## How to test + +* Confirm that the source for each version currently in use is published on the internet where it can be seen from outside the original contributing organization and without the need for any form of authentication or authorization. +* Confirm that the [codebase](../glossary.md#codebase) files and commit history do not include sensitive information. +* Check for the publication of source code not currently in use. + +## Public policy makers: what you need to do + +* Develop policies in the open. +* Prioritize open and transparent policies. + +## Managers: what you need to do + +* Develop a culture that embraces openness, learning and feedback. +* Collaborate with external vendors and freelancers by working in the open. + +## Developers and designers: what you need to do + +* As a reviewer, for each commit, verify that content does not include sensitive information such as configurations, usernames or passwords, public keys or other real credentials used in production systems. +* Clearly split data and source code, in order to meet the requirement about sensitive information above. + +## Further reading + +* [Coding in the open](https://gds.blog.gov.uk/2012/10/12/coding-in-the-open/) by the UK Government Digital Service. +* [When code should be open or closed](https://www.gov.uk/government/publications/open-source-guidance/when-code-should-be-open-or-closed) by the UK Government Digital Service. +* [Security considerations when coding in the open](https://www.gov.uk/government/publications/open-source-guidance/security-considerations-when-coding-in-the-open) by the UK Government Digital Service. +* [Deploying software regularly](https://www.gov.uk/service-manual/technology/deploying-software-regularly) by the UK Government Digital Service. +* [How GDS uses GitHub](https://gdstechnology.blog.gov.uk/2014/01/27/how-we-use-github/) by the UK Government Digital Service. diff --git a/origin_source/criteria/document-codebase-maturity.md b/origin_source/criteria/document-codebase-maturity.md new file mode 100644 index 00000000..bb7a4692 --- /dev/null +++ b/origin_source/criteria/document-codebase-maturity.md @@ -0,0 +1,50 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +order: 16 +redirect_from: + - criteria/advertise-maturity + - criteria/document-maturity +--- +# Document codebase maturity + +Clearly signalling a [codebase](../glossary.md#codebase)'s maturity helps others decide whether to use and contribute to it. +A codebase version's maturity includes the maturity of its dependencies. +Understanding how a codebase has evolved is key to understanding the codebase and how to contribute to it. + +## Requirements + +* The codebase MUST be versioned. +* The codebase MUST prominently document whether or not there are versions of the codebase that are ready to use. +* Codebase versions that are ready to use MUST only depend on versions of other codebases that are also ready to use. +* The codebase SHOULD contain a log of changes from version to version, for example in the `CHANGELOG`. +* The method for assigning version identifiers SHOULD be documented. +* It is OPTIONAL to use semantic versioning. + +## How to test + +* Confirm that the codebase has a strategy for versioning which is documented. +* Confirm that it is obvious to policy makers, managers, developers and designers whether the codebase has versions that are ready to use. +* Confirm that ready to use versions of the codebase do not depend on any versions of other codebases that are not ready to use. +* Check that the versioning scheme of the codebase is documented and followed. +* Check that there is a log of changes. + +## Public policy makers: what you need to do + +* When developing [policy](../glossary.md#policy), understand that any [source code](../glossary.md#source-code) developed needs to be tested and improved before it can be put into service. +* Consider versioning policy changes, especially when they trigger new versions of the source code. + +## Managers: what you need to do + +* Make sure that services only rely on versions of codebases of equal or greater maturity than the service. For example, don't use a beta version of a codebase in a production service. + +## Developers and designers: what you need to do + +* Make sure that the codebase versioning approach is followed for all releases. + +## Further reading + +* [Semantic Versioning Specification](https://semver.org/) used by many codebases to label versions. +* [Software release life cycle](https://en.wikipedia.org/wiki/Software_release_life_cycle) +* [Service Design and Delivery Process](https://www.dta.gov.au/help-and-advice/build-and-improve-services/service-design-and-delivery-process) by the Australian Digital Transformation Agency. +* [Service Manual on Agile Delivery](https://www.gov.uk/service-manual/agile-delivery) by the UK Government Digital Service. diff --git a/origin_source/criteria/document-codebase-objectives.md b/origin_source/criteria/document-codebase-objectives.md new file mode 100644 index 00000000..d54d30eb --- /dev/null +++ b/origin_source/criteria/document-codebase-objectives.md @@ -0,0 +1,40 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +order: 8 +redirect_from: + - criteria/document-objectives +--- +# Document codebase objectives + +Clearly documenting [codebase](../glossary.md#codebase) objectives communicates the purpose of the codebase. +It helps stakeholders and contributors scope the development of the codebase. +The objectives also provide an easy way for people to decide whether this codebase, or one of its modules, is interesting for them now or in the future. + +## Requirements + +* The codebase MUST contain documentation of its objectives, like a mission and goal statement, that is understandable by developers and designers so that they can use or contribute to the codebase. +* Codebase documentation SHOULD clearly describe the connections between [policy](../glossary.md#policy) objectives and codebase objectives. +* Documenting the objectives of the codebase for the [general public](../glossary.md#general-public) is OPTIONAL. + +## How to test + +* Confirm that the codebase documentation includes the codebase objectives, mission or goal. +* Check for descriptions of connections between policy objectives and codebase objectives. + +## Public policy makers: what you need to do + +* Add the policy objectives to the codebase documentation, for example in the `README`. +* Make sure that all your codebase objectives have links or references to supporting policy documents added to meet the [Bundle policy and source code](bundle-policy-and-source-code.md) criterion. + +## Managers: what you need to do + +* Add the organizational and business objectives to the codebase documentation, for example in the `README`. + +## Developers and designers: what you need to do + +* Add the technology and design objectives to the codebase documentation, for example in the `README`. + +## Further reading + +* [How to write project objectives](http://grouper.ieee.org/groups/802/3/RTPGE/public/may12/hajduczenia_01_0512.pdf) by Marek Hajduczenia. diff --git a/origin_source/criteria/document-the-code.md b/origin_source/criteria/document-the-code.md new file mode 100644 index 00000000..b4e6b601 --- /dev/null +++ b/origin_source/criteria/document-the-code.md @@ -0,0 +1,53 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +order: 9 +redirect_from: + - criteria/documenting +--- +# 程式碼有文件 + +Well documented [source code](../glossary.md#source-code) helps people to understand what the source code does and how to use it. +Documentation is essential for people to start using the [codebase](../glossary.md#codebase) and contributing to it more quickly. + +## 需求規範 + +* All of the functionality of the codebase, [policy](../glossary.md#policy) as well as source code, MUST be described in language clearly understandable for those that understand the purpose of the codebase. +* The documentation of the codebase MUST contain a description of how to install and run the software. +* The documentation of the codebase MUST contain examples demonstrating the key functionality. +* The documentation of the codebase SHOULD contain a high level description that is clearly understandable for a wide audience of stakeholders, like the [general public](../glossary.md#general-public) and journalists. +* The documentation of the codebase SHOULD contain a section describing how to install and run a standalone version of the source code, including, if necessary, a test dataset. +* The documentation of the codebase SHOULD contain examples for all functionality. +* The documentation SHOULD describe the key components or modules of the codebase and their relationships, for example as a high level architectural diagram. +* There SHOULD be [continuous integration](../glossary.md#continuous-integration) tests for the quality of the documentation. +* Including examples that make users want to immediately start using the codebase in the documentation of the codebase is OPTIONAL. + +## 測試方式 + +* Confirm that other stakeholders, professionals from other public organizations and the general public find the documentation clear and understandable. +* Confirm that the documentation describes how to install and run the source code. +* Confirm that the documentation includes examples of the key functionality. +* Check with members of the general public and journalists if they can understand the high level description. +* Check that the instructions for how to install and run a standalone version of the source code result in a running system. +* Check that all functionality documented contains an example. +* Check that the documentation includes a high level architectural diagram or similar. +* Check that the documentation quality is part of integration testing, for example documentation is generated correctly, and links and images are tested. + +## Public policy makers: what you need to do + +* 定期查看代碼庫的非政策程式碼的變動情況。 +* 針對如何讓非政策文件更清楚易懂提供意見回饋。 + +## Managers: what you need to do + +* Try to use the codebase, so your feedback can improve how clearly the policy and source code are documented. For example, is the current documentation sufficient to persuade a manager at another public organization to use this codebase? +* Make sure you understand both the policy and source code as well as the documentation. + +## 開發人員與設計師：需要的工作 + +* 定期查看代碼庫中非原始碼部分的變動情況。 +* 針對如何讓非原始碼文件更清楚易懂提供意見回饋。 + +## 延伸閱讀 + +* Write the Docs《[文件指南](https://www.writethedocs.org/guide/)》。 diff --git a/origin_source/criteria/index.md b/origin_source/criteria/index.md new file mode 100644 index 00000000..7bd1c002 --- /dev/null +++ b/origin_source/criteria/index.md @@ -0,0 +1,12 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2022 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +order: 0 +--- +# Criteria + +{% assign sorted = site.pages | sort:"order" %} + +{% for page in sorted %}{% if page.dir == "/criteria/" %}{% if page.name != "index.md" %}{% if page.title %} + +1. [{{page.title}}]({{page.url}}){% endif%} {% endif%} {% endif%}{% endfor %} diff --git a/origin_source/criteria/maintain-version-control.md b/origin_source/criteria/maintain-version-control.md new file mode 100644 index 00000000..82ba2fd6 --- /dev/null +++ b/origin_source/criteria/maintain-version-control.md @@ -0,0 +1,61 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +order: 6 +redirect_from: + - criteria/version-control-and-history +--- + +# 維護版本控制 + +[Version control](../glossary.md#version-control) means keeping track of changes to the [source code](../glossary.md#source-code) and other files of the [codebase](../glossary.md#codebase) over time. +This allows you to maintain structured documentation of the history of the codebase. +This is essential for collaboration at scale, as it enables developers to work on changes in parallel and helps future developers to understand the reasons for changes. + +## 需求規範 + +* All files in the codebase MUST be version controlled. +* All decisions MUST be documented in commit messages. +* Every commit message MUST link to discussions and issues wherever possible. +* The codebase SHOULD be maintained in a distributed version control system. +* Contribution guidelines SHOULD require contributors to group relevant changes in commits. +* Maintainers SHOULD mark released versions of the codebase, for example using revision tags or textual labels. +* Contribution guidelines SHOULD encourage file formats where the changes within the files can be easily viewed and understood in the version control system. +* It is OPTIONAL for contributors to sign their commits and provide an email address, so that future contributors are able to contact past contributors with questions about their work. + +## How to test + +* 確認代碼庫維持在版本控制狀態中，像是使用 Git 之類的軟體。 +* 審查提交內容歷史紀錄，確認所有的提交訊息皆有解釋之前程式碼修改變動的原因。 +* 審查提交內容歷史紀錄，確認所有提交訊息之中，盡可能在所有討論過修改變更的地方，包含變動內容以及連結位置（提供網址）。 +* 檢查版本控制系統是否為分散式。 +* 審查提交內容歷史紀錄，檢查是否有根據貢獻指南將相關的程式碼變動以群組分類。 +* 檢查是否可能透過像是修訂版次標記，或文字標籤，來存取代碼庫中的特定版本。 +* 檢查代碼庫在可能的情況下，檔案都是採用文字格式。 + +## Public policy makers: what you need to do + +* 如果因為[政策](../glossary.md#policy)改變而在代碼庫中有新的版本，則請確認有在文件中清楚說明： + * 政策改變的地方， + * 代碼庫如何因應而改變。 + +舉例來說，在做權限管理賦予取用權的代碼庫中，如果要新增申請方類別，就會視為政策變動。 + +## Managers: what you need to do + +* 支持政策制定者、開發人員與設計師，使其能清楚表達他們對代碼庫做出的改善。確保改善代碼庫不會有公關風險。 + +## 開發人員與設計師：需要的工作 + +* Make sure that all files required to understand the code, build and deploy are in the version control system. +* Write clear commit messages so that it is easy to understand why the commit was made. +* Mark different versions so that it is easy to access a specific version, for example using revision tags or textual labels. +* Write clear commit messages so that versions can be usefully compared. +* Work with policy makers to describe how the source code was updated after a policy change. + +## 延伸閱讀 + +* [Producing OSS: Version Control Vocabulary](https://producingoss.com/en/vc.html#vc-vocabulary) by Karl Fogel. +* [Maintaining version control in coding](https://www.gov.uk/service-manual/technology/maintaining-version-control-in-coding) by the UK Government Digital Service. +* [GitHub Skills](https://skills.github.com/) by GitHub for learning how to use GitHub or refresh your skills. +* [Git Cheat Sheet](https://education.github.com/git-cheat-sheet-education.pdf) by GitHub, a list with the most common used git commands. diff --git a/origin_source/criteria/make-contributing-easy.md b/origin_source/criteria/make-contributing-easy.md new file mode 100644 index 00000000..049491e5 --- /dev/null +++ b/origin_source/criteria/make-contributing-easy.md @@ -0,0 +1,48 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +order: 5 +--- +# Make contributing easy + +To develop better, more reliable and feature rich software, users need to be able to fix problems, add features, and address security issues of the shared [codebase](../glossary.md#codebase). + +A shared digital infrastructure makes it easier to make collaborative contributions. +The less effort it takes to make contributions that are accepted by the codebase, the more likely users are to become contributors. + +## Requirements + +* The codebase MUST have a public issue tracker that accepts suggestions from anyone. +* The documentation MUST link to both the public issue tracker and submitted codebase changes, for example in a `README` file. +* The codebase MUST have communication channels for users and developers, for example email lists. +* There MUST be a way to report security issues for responsible disclosure over a closed channel. +* The documentation MUST include instructions for how to report potentially security sensitive issues. + +## How to test + +* Confirm that there is a public issue tracker. +* Confirm that the codebase contains links to the public issue tracker and submitted codebase changes. +* Confirm that it is possible to participate in a discussion with other users and developers about the software using channels described in the codebase. +* Confirm that there is a closed channel for reporting security issues. +* Confirm that there are instructions for privately reporting security issues. + +## Public policy makers: what you need to do + +* Track [policy](../glossary.md#policy) issues in the codebase, so that a relevant external policy expert can volunteer help. + +## Managers: what you need to do + +* Track management issues in the codebase, so that external managers with relevant experience can volunteer help. +* Support your experienced policy makers, developers and designers to keep contributing to the codebase for as long as possible. + +## Developers and designers: what you need to do + +* Just like for [reviews](require-review-of-contributions.md), make sure to respond to requests promptly. +* Keep your managers informed of the time and resources you require to support other contributors. +* Make sure that appropriate communication channels for asking maintainers and stakeholders questions are easy to locate, for instance in the README. +* Make sure that appropriate contact details are included in the metadata, for instance in the publiccode.yml file. + +## Further reading + +* [How to inspire exceptional contributions to your open-source project](https://dev.to/joelhans/how-to-inspire-exceptional-contributions-to-your-open-source-project-1ebf) by Joel Hans. +* [The benefits of coding in the open](https://gds.blog.gov.uk/2017/09/04/the-benefits-of-coding-in-the-open/) by the UK Government Digital Service. diff --git a/origin_source/criteria/make-the-codebase-findable.md b/origin_source/criteria/make-the-codebase-findable.md new file mode 100644 index 00000000..24615fd5 --- /dev/null +++ b/origin_source/criteria/make-the-codebase-findable.md @@ -0,0 +1,70 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2022-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +order: 14 +redirect_from: + - criteria/findability +--- +# 代碼庫可查詢得到 + +The more findable a [codebase](../glossary.md#codebase) is, the more potential new collaborators will find it. +Just publishing a codebase and hoping it is found does not work, instead proactiveness is needed. + +A metadata description file increases discoverability. +Well-written metadata containing a unique and persistent identifier, such as a Wikidata item or FSF software directory listing (thus being part of the semantic web), makes the codebase easier for people to refer, cite, disambiguate and discover through third party tools. + +## 需求規範 + +* The name of the codebase SHOULD be descriptive and free from acronyms, abbreviations, puns or organizational branding. +* The codebase SHOULD have a short description that helps someone understand what the codebase is for or what it does. +* Maintainers SHOULD submit the codebase to relevant software catalogs. +* The codebase SHOULD have a website which describes the problem the codebase solves using the preferred jargon of different potential users of the codebase (including technologists, policy experts and managers). +* The codebase SHOULD be findable using a search engine by codebase name. +* The codebase SHOULD be findable using a search engine by describing the problem it solves in natural language. +* The codebase SHOULD have a unique and persistent identifier where the entry mentions the major contributors, [repository](../glossary.md#repository) location and website. +* The codebase SHOULD include a machine-readable metadata description, for example in a [publiccode.yml](https://github.com/publiccodeyml/publiccode.yml) file. +* A dedicated domain name for the codebase is OPTIONAL. +* Regular presentations at conferences by the community are OPTIONAL. + +## How to test + +* Check that the codebase name is descriptive and free of puns. +* Check that the codebase name is free of acronyms and abbreviations or that the acronyms or abbreviations in the name are more universally known than the longer forms. +* Check that the codebase name is free of organizational branding, unless that organization is of the codebase community itself. +* Check that the codebase repository has a short description of the codebase. +* Check for the codebase listing in relevant software catalogs. +* Check for a codebase website which describes the problem the codebase solves. +* Check that the codebase appears in the results on more than one major search engine when searching by the codebase name. +* Check that the codebase appears in the results on more than one major search engine when searching by using natural language, for instance, using the short description. +* Check unique and persistent identifier entries for mention of the major contributors. +* Check unique and persistent identifier entries for the repository location. +* Check unique and persistent identifier entries for the codebase website. +* Check for a machine-readable metadata description file. + +## Public policy makers: what you need to do + +* Contribute a description of the policy area or problem this codebase acts on or operates. +* Test your problem description with peers outside of your context who aren't familiar with the codebase. +* Present on how the codebase implements the [policy](../glossary.md#policy) at relevant conferences. + +## Managers: what you need to do + +* Search trademark databases to avoid confusion or infringement before deciding the name. +* Use the short description wherever the codebase is referenced, for instance, as social media account descriptions. +* Budget for content design and Search Engine Optimization skills in the team. +* Make sure people involved in the project present at relevant conferences. + +## 開發人員與設計師：需要的工作 + +* Search engine optimization, for instance adding a [sitemap](https://www.sitemaps.org/protocol.html). +* Use the short description wherever the codebase is referenced, for instance, as the repository description. +* Test your problem description with peers outside of your context who aren't familiar with the codebase. +* Suggest conferences to present at and present at them. + +

+ +## Further reading + +* [Introduction to Wikidata](https://www.wikidata.org/wiki/Wikidata:Introduction) by the Wikidata community. +* [FSF software directory listing](https://directory.fsf.org/wiki/Main_Page) by the Free Software Foundation. +* The [FAIR Guiding Principles for scientific data management and stewardship](https://www.go-fair.org/fair-principles/) by the GO FAIR International Support and Coordination Office provide a nice list of attributes that make (meta)data more machine actionable (and hence more findable). Some of these apply directly to codebases, while others may provoke exploration into what the codebase equivalent would be. diff --git a/origin_source/criteria/make-the-codebase-reusable-and-portable.md b/origin_source/criteria/make-the-codebase-reusable-and-portable.md new file mode 100644 index 00000000..5437394c --- /dev/null +++ b/origin_source/criteria/make-the-codebase-reusable-and-portable.md @@ -0,0 +1,76 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +order: 3 +redirect_from: + - criteria/reusable-and-portable-codebases + - criteria/create-reusable-and-portable-code +--- +# Make the codebase reusable and portable + +Creating reusable and portable [code](../glossary.md#code) enables policy makers, developers and designers to reuse what has been developed, test it, improve it and contribute those improvements back, leading to better quality, cheaper maintenance and higher reliability. + +Thoughtfully and purposefully designing a [codebase](../glossary.md#codebase) for reusability allows for the mission, vision and scope of the codebase to be shared by multiple parties. +Codebases developed and used by multiple parties are more likely to benefit from a self-sustaining community. + +Organizing a codebase such that it is composed of well documented modules improves reusability and maintainability. +A module is easier to reuse in [another context](../glossary.md#different-contexts) if its purpose is clearly documented. + +Source code which does not rely on the situation-specific infrastructure of any contributor, vendor or deployment can be tested by any other contributor. + +## Requirements + +* The codebase MUST be developed to be reusable in different contexts. +* The codebase MUST be independent from any secret, undisclosed, proprietary or non-open licensed software or services for execution and understanding. +* The codebase SHOULD be in use by multiple parties. +* The roadmap SHOULD be influenced by the needs of multiple parties. +* The development of the codebase SHOULD be a collaboration between multiple parties. +* Configuration SHOULD be used to make [source code](../glossary.md#source-code) adapt to context specific needs. +* The codebase SHOULD be localizable. +* Source code and its documentation SHOULD NOT contain situation-specific information. +* Codebase modules SHOULD be documented in such a way as to enable reuse in codebases in other contexts. +* The software SHOULD NOT require services or platforms available from only a single vendor. + +## How to test + +* Confirm with someone in a similar role at another organization if they can use the codebase and what that would entail. +* Confirm that the codebase can run without using any proprietary or non open-licensed software or services. +* If the codebase is in early development before a production-ready release, then check for evidence of ambition to obtain collaborators. + * Or if the codebase is very mature and stable with very infrequent fixes, patches, or contributions: + * Check that the codebase is in use by multiple parties or in multiple contexts. + * Check for documented and budgeted commitments of collaboration. + * Otherwise: + * Check that the codebase is in use by multiple parties or in multiple contexts. + * Check that the codebase contributors are from multiple parties. +* Check that the codebase files and commit history do not include situation-specific data. +* Check that the software can be deployed and run without services or platforms available from a single vendor. + +## Public policy makers: what you need to do + +* Document your [policy](../glossary.md#policy) with enough clarity and detail that it can be understood outside of its original context. +* Make sure your organization is listed as a known user by the codebase. +* Identify other organizations for your teams to collaborate with. + +## Managers: what you need to do + +* Make sure that stakeholders and business owners understand that reusability is an explicit codebase goal as this reduces technical debt and provides sustainability for the codebase. +* Make sure that your teams are collaborating with other teams. + +## Developers and designers: what you need to do + +Source should be designed: + +* for reuse by other users and organizations regardless of locale, +* to solve a general problem instead of a specific one, +* in logically meaningful and isolated modules, +* so that someone in a similar organization facing a similar problem would be able to use (parts of) the solution. + +Make sure that the codebase documentation describes the build-time and runtime dependencies. +If your context requires deploying to proprietary platforms or using proprietary components, make sure that collaborators can develop, use, test, and deploy without them. + +For each commit, reviewers verify that content does not include situation-specific data such as hostnames, personal and organizational data, or tokens and passwords. + +## Further reading + +* [Making source code open and reusable](https://www.gov.uk/service-manual/technology/making-source-code-open-and-reusable) by the UK Government Digital Service. +* [Localization vs. Internationalization](https://www.w3.org/International/questions/qa-i18n) by the World Wide Web Consortium. diff --git a/origin_source/criteria/publish-with-an-open-license.md b/origin_source/criteria/publish-with-an-open-license.md new file mode 100644 index 00000000..91e9b29a --- /dev/null +++ b/origin_source/criteria/publish-with-an-open-license.md @@ -0,0 +1,56 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +order: 13 +redirect_from: + - criteria/open-licenses +--- +# 發行採用開放授權 + +An open and well known license makes it possible for anyone to see the [source code](../glossary.md#source-code) in order to understand how it works, to use it freely and to contribute to the [codebase](../glossary.md#codebase). +This enables a vendor ecosystem to emerge around the codebase. + +Clearly indicating the license for each file within a codebase facilitates correct reuse and attribution of parts of a codebase. + +## 需求規範 + +* All source code and documentation MUST be licensed such that it may be freely reusable, changeable and redistributable. +* Software source code MUST be licensed under an [OSI-approved or FSF Free/Libre license](https://spdx.org/licenses/). +* All source code MUST be published with a license file. +* Contributors MUST NOT be required to transfer copyright of their contributions to the codebase. +* All source code files in the codebase SHOULD include a copyright notice and a license header that are machine-readable. +* Having multiple licenses for different types of source code and documentation is OPTIONAL. + +## 測試方式 + +* 確認代碼庫有清楚給予授權條款。 +* 確認原始碼的授權條款有列於[經 OSI 開放原始碼促進會所批准，或由 FSF 自由軟體基金會所發表的自由授權條款清單](https://spdx.org/licenses/)，以及文件的授權條款有 +[符合「開放定義」](https://opendefinition.org/licenses/)。 +* 確認代碼庫中有包含其採用的授權條款檔案。 +* 確認貢獻指南中，以及[儲存庫](../glossary.md#repository)的組態設定中，沒有求貢獻者轉讓著作權。 +* 在代碼庫[持續整合](../glossary.md#continuous-integration)測試中，確認是否有檢查授權內容為機器可讀的檢查項目。 + +## Public policy makers: what you need to do + +* Develop [policy](../glossary.md#policy) that requires source code to be [open source](../glossary.md#open-source). +* Develop policy that disincentivizes non-open source code and technology in procurement. + +## Managers: what you need to do + +* Only work with open source vendors that deliver their source code by publishing it under an open source license. +* Beware that even though [Creative Commons licenses](https://creativecommons.org/licenses/) are great for documentation, licenses that stipulate Non-Commercial or No Derivatives are NOT freely reusable, changeable and redistributable and don't fulfill these requirements. + +## 開發人員與設計師：需要的工作 + +* Add a new `license` file to every new codebase created. +* Add a copyright notice and a license header to every new source code file created. +* When source code is being reused by the codebase, make sure that it has a license that is compatible with the license or licenses of the codebase. + +

+ +## 延伸閱讀 + +* 開放原始碼促進會所發表的《[開放原始碼定義](https://opensource.org/osd)》，所有開放原始碼授權條款皆符合這套定義。 +* 紐西蘭CC Aotearoa《[創用CC介紹動畫影片](https://creativecommons.org/about/videos/creative-commons-kiwi)》。 +* 歐洲自由軟體基金會所發表的《[REUSE 倡議規範](https://reuse.software/spec/)》提供規範明確、人類可讀以及機器可讀的著作權與授權資訊。 +* Linux 基金會所發表的 [SPDX 授權條款清單](https://spdx.org/licenses/)提供經標準化、且機器可讀的大多數授權條款縮寫表示法。 diff --git a/origin_source/criteria/require-review-of-contributions.md b/origin_source/criteria/require-review-of-contributions.md new file mode 100644 index 00000000..01a97801 --- /dev/null +++ b/origin_source/criteria/require-review-of-contributions.md @@ -0,0 +1,64 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +order: 7 +redirect_from: + - criteria/require-review +--- + +# 要求審查貢獻內容 + +Peer-review of contributions is essential for [source code](../glossary.md#source-code) quality, reducing security risks and operational risks. + +Requiring thorough review of contributions encourages a culture of making sure every contribution is of high quality, completeness and value. +Source code review increases the chance of discovering and fixing potential bugs or mistakes before they are added to the [codebase](../glossary.md#codebase). +Knowing that all source code was reviewed discourages a culture of blaming individuals, and encourages a culture of focusing on solutions. + +A [policy](../glossary.md#policy) of prompt reviews assures contributors of a guaranteed time for feedback or collaborative improvement, which increases both rate of delivery and contributor engagement. + +## 需求規範 + +* All contributions that are accepted or committed to release versions of the codebase MUST be reviewed by another contributor. +* Reviews MUST include source, policy, tests and documentation. +* Reviewers MUST provide feedback on all decisions to not accept a contribution. +* The review process SHOULD confirm that a contribution conforms to the standards, architecture and decisions set out in the codebase in order to pass review. +* Reviews SHOULD include running both the software and the tests of the codebase. +* Contributions SHOULD be reviewed by someone in a different context than the contributor. +* Version control systems SHOULD NOT accept non-reviewed contributions in release versions. +* Reviews SHOULD happen within two business days. +* Performing reviews by multiple reviewers is OPTIONAL. + +## How to test + +* Confirm that every commit in the history has been reviewed by a different contributor. +* Confirm that reviews include source, policy, tests and documentation. +* Confirm that rejected contributions were appropriately explained. +* Check if guidelines for reviewers include instructions to review for conformance to standards, architecture and codebase guidelines. +* Check with reviewers if they run the software and tests during review. +* Check with reviewers if commits have been reviewed by a different contributor in a different context. +* Check for use of branch protection in the [version control](../glossary.md#version-control) system. +* Check the times between contribution submission and review. + +## Public policy makers: what you need to do + +* Institute a 'four eyes' policy where everything, not just source code, is reviewed. +* Use a version control system or methodology that enables review and feedback. + +## Managers: what you need to do + +* Make delivering great software a shared objective. +* Make sure writing and reviewing contributions to source, policy, documentation and tests are considered equally valuable. +* Create a culture where all contributions are welcome and everyone is empowered to review them. +* Make sure no contributor is ever alone in contributing to a codebase. + +## 開發人員與設計師：需要的工作 + +* Ask other contributors on the codebase to review your work, in your organization or outside of it. +* Try to respond to others' requests for review promptly, initially providing feedback about the concept of the change. + +## 延伸閱讀 + +* [How to review code the GDS way](https://gds-way.cloudapps.digital/manuals/code-review-guidelines.html#content) by the UK Government Digital Service. +* Branch protection on [GitHub](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches) and [GitLab](https://about.gitlab.com/blog/2014/11/26/keeping-your-code-protected/). +* [The Gentle Art of Patch Review](https://sage.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/) by Sage Sharp. +* [Measuring Engagement](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) by Mozilla. diff --git a/origin_source/criteria/use-a-coherent-style.md b/origin_source/criteria/use-a-coherent-style.md new file mode 100644 index 00000000..fbcf0edd --- /dev/null +++ b/origin_source/criteria/use-a-coherent-style.md @@ -0,0 +1,49 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +order: 15 +redirect_from: + - criteria/style +--- + +# 風格要前後一致 + +Following a consistent and coherent style enables contributors in different environments to work together. +Unifying vocabularies reduces friction in communication between contributors. + +## 需求規範 + +* The [codebase](../glossary.md#codebase) MUST use a coding or writing style guide, either the codebase community's own or an existing one referred to in the codebase. +* Contributions SHOULD pass automated tests on style. +* The style guide SHOULD include expectations for inline comments and documentation for non-trivial sections. +* Including expectations for [understandable English](use-plain-english.md) in the style guide is OPTIONAL. + +## 測試方式 + +* 確認貢獻內容有遵循文件中指定的風格指南。 +* 檢查是否有自動化的風格測試。 + +## Public policy makers: what you need to do + +* 為[政策](../glossary.md#policy)與文件建立風格指南，遵守並且持續改善，同時記錄到代碼庫文件中，像是「`CONTRIBUTING`」或「 +`README`」檔案。 + +## Managers: what you need to do + +* 將書面語言、原始碼、測試、政策標準等，包含在貴組織單位對品質的定義當中。 + +## 開發人員與設計師：需要的工作 + +If the codebase does not already have engineering guidelines or other contributor guidance, start by adding documentation to the [repository](../glossary.md#repository) describing whatever is being done now, for example in the `CONTRIBUTING` or `README`. +An important purpose of the file is to communicate design preferences, naming conventions, and other aspects machines can't easily check. +Guidance should include what would be expected from [source code](../glossary.md#source-code) contributions in order for them to be merged by the maintainers, including source, tests and documentation. +Continually improve upon and expand this documentation with the aim of evolving this documentation into engineering guidelines. + +此外： + +* 使用程式碼品質分析工具 (linter)。 +* 在代碼庫中加入程式碼品質分析工具的組態設定。 + +## 延伸閱讀 + +* [Programming style](https://en.wikipedia.org/wiki/Programming_style) on Wikipedia. diff --git a/origin_source/criteria/use-continuous-integration.md b/origin_source/criteria/use-continuous-integration.md new file mode 100644 index 00000000..d19b4789 --- /dev/null +++ b/origin_source/criteria/use-continuous-integration.md @@ -0,0 +1,70 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +order: 12 +redirect_from: + - criteria/continuous-integration +--- +# Use continuous integration + +Asynchronous collaboration is enabled by developers merging their work to a shared branch frequently, verified by automated tests. +The more frequent the merging and the smaller the contribution, the easier it is to resolve merge conflicts. + +Automated testing of all functionality provides confidence that contributions are working as intended and have not introduced errors, and allows reviewers to focus on the structure and approach of the contribution. +The more focused the test, the easier it is to clearly identify and understand errors as they arise. + +Documenting a codebase's [continuous integration](../glossary.md#continuous-integration) workflow helps contributors understand the expectations of contributions. +Continuous integration allows for an easier monitoring of the state of the [codebase](../glossary.md#codebase). + +## Requirements + +* All functionality in the [source code](../glossary.md#source-code) MUST have automated tests. +* Contributions MUST pass all automated tests before they are admitted into the codebase. +* The codebase MUST have guidelines explaining how to structure contributions. +* The codebase MUST have active contributors who can review contributions. +* Automated test results for contributions SHOULD be public. +* The codebase guidelines SHOULD state that each contribution should focus on a single issue. +* Source code test and documentation coverage SHOULD be monitored. +* Testing [policy](../glossary.md#policy) and documentation for consistency with the source and vice versa is OPTIONAL. +* Testing policy and documentation for style and broken links is OPTIONAL. +* Testing the software by using examples in the documentation is OPTIONAL. + +## How to test + +* Confirm that there are tests present. +* Confirm that source code coverage tools check that coverage is at 100% of the source code. +* Confirm that contributions are only admitted into the codebase after all of the tests are passed. +* Confirm that contribution guidelines explain how to structure contributions. +* Confirm that there are contributions from within the last three months. +* Check that test results are viewable. +* Check if source code coverage data is published. + +## Public policy makers: what you need to do + +* Involve managers as well as developers and designers as early in the process as possible and keep them engaged throughout development of your policy. +* Make sure there are also automated tests set up for policy documentation. +* Fix policy documentation promptly if it fails a test. +* Make sure the source code reflects any changes to the policy (see [Maintain version control](maintain-version-control.md)). + +## Managers: what you need to do + +* Make sure to test with real end users as quickly and often as possible. +* Plan the work to integrate small parts very often instead of large parts less frequently. +* Procure consultancy services that deliver incrementally aligned with the plan. +* After a large failure, encourage publication of incident reports and public discussion of what was learned. + +## Developers and designers: what you need to do + +* Help managers structure the work plan such that it can be integrated as small increments. +* Help contributors limit the scope of their contributions and feature requests to be as small as reasonable. +* Help managers and policy makers test their contributions, for example by testing their contributions for broken links or style. +* Structure source code written to handle conditions which are difficult to create in a test environment in such a way that the conditions can be simulated during testing. Forms of resource exhaustion such as running out of storage space and memory allocation failure are typical examples of difficult to create conditions. +* Tune the test code coverage tools to avoid false alarms resulting from inlining or other optimizations. +* Deploy often. +* Integrate your work at least once a day. + +## Further reading + +* [What is continuous integration](https://www.martinfowler.com/articles/continuousIntegration.html) by Martin Fowler. +* [Use continuous delivery](https://gds-way.cloudapps.digital/standards/continuous-delivery.html) by the UK Government Digital Service. +* [Quality assurance: testing your service regularly](https://www.gov.uk/service-manual/technology/quality-assurance-testing-your-service-regularly) by the UK Government Digital Service. diff --git a/origin_source/criteria/use-open-standards.md b/origin_source/criteria/use-open-standards.md new file mode 100644 index 00000000..c37010cc --- /dev/null +++ b/origin_source/criteria/use-open-standards.md @@ -0,0 +1,48 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +order: 11 +redirect_from: + - criteria/open-standards +--- + +# 採用開放標準 + +[Open standards](../glossary.md#open-standard) guarantee access to the knowledge required to use and contribute to the [codebase](../glossary.md#codebase). +They enable interoperability between systems and reduce the risk of vendor lock-in. +Open standards which are unambiguous allow for independent development of either side of data exchange. + +## 需求規範 + +* For features of the codebase that facilitate the exchange of data the codebase MUST use an open standard that meets the [Open Source Initiative Open Standard Requirements](https://opensource.org/osr). +* Any non-open standards used MUST be recorded clearly as such in the documentation. +* Any standard chosen for use within the codebase MUST be listed in the documentation with a link to where it is available. +* Any non-open standards chosen for use within the codebase MUST NOT hinder collaboration and reuse. +* If no existing open standard is available, effort SHOULD be put into developing one. +* Open standards that are machine testable SHOULD be preferred over open standards that are not. +* Non-open standards that are machine testable SHOULD be preferred over non-open standards that are not. + +## 測試方式 + +* 確認資料交換遵守 OSI 開放原始碼促進會批准的開放標準。 +* 確認若有採用任何的非開放標準，皆有清楚記錄在文件中。 +* 確認文件有清單列出代碼庫所採用的標準，其中各標準有對應的有效連結；或沒有採用任何標準時，則留下聲明。 + +## Public policy makers: what you need to do + +* 以政策要求盡可能在任何情況下使用開放標準。 +* 禁止採購不採用開放標準的技術科技。 + +## Managers: what you need to do + +* Consider including open standard compliance assessment in [source code](../glossary.md#source-code) reviews. + +## 開發人員與設計師：需要的工作 + +* 將是否依循標準加入[持續整合](../glossary.md#continuous-integration)測試中。 +* 審查提交紀錄與其他[儲存庫](../glossary.md#repository)資源是否有參考開放標準，並交叉檢查其中有列出標準的部分。 + +## 延伸閱讀 + +* 英國內閣辦公室發表的《[開放標準原則](https://www.gov.uk/government/publications/open-standards-principles/open-standards-principles)》 +[政策](../glossary.md#policy)報告。 diff --git a/origin_source/criteria/use-plain-english.md b/origin_source/criteria/use-plain-english.md new file mode 100644 index 00000000..c8b7d4cc --- /dev/null +++ b/origin_source/criteria/use-plain-english.md @@ -0,0 +1,58 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +order: 10 +redirect_from: + - criteria/understandable-english-first +--- + +# 使用白話的英語 + +English is the de facto language of collaboration in software development. + +Public sector information needs to be accessible to all its constituents. +Plain and simple language makes the [code](../glossary.md#code) and what it does easier to understand for a wider variety of people. + +Translations further increase the possible reach of a [codebase](../glossary.md#codebase). +Language that is easy to understand lowers the cost of creating and maintaining translations. + +## 需求規範 + +* All codebase documentation MUST be in English. +* All [source code](../glossary.md#source-code) MUST be in English, except where [policy](../glossary.md#policy) is machine interpreted as code. +* All bundled policy not available in English MUST have an accompanying summary in English. +* Any translation MUST be up to date with the English version and vice versa. +* There SHOULD be no acronyms, abbreviations, puns or legal/non-English/domain specific terms in the codebase without an explanation preceding it or a link to an explanation. +* Documentation SHOULD aim for a lower secondary education reading level, as recommended by the [Web Content Accessibility Guidelines 2](https://www.w3.org/WAI/WCAG21/quickref/?showtechniques=315#readable). +* Providing a translation of any code, documentation or tests is OPTIONAL. + +## How to test + +* 確認代碼庫文件有英語版本。 +* 確認原始碼為英語，確認任何非英語內容都是政策，或確認術語在其前方有先行說明等。 +* 確認任何非英語政策都有隨附英語版摘要。 +* 確認翻譯版與英語版內容相同。 +* 確認文件當中，沒有任何未說明的首字母縮寫字、縮寫、雙關語，或法律/非英語/行業特定詞彙等。 +* 檢查文件的拼字、文法與易讀性等。 + +## Public policy makers: what you need to do + +* Frequently test with other managers, developers and designers in the process if they understand what you are delivering and how you document it. + +## Managers: what you need to do + +* 在團隊內部與利害關係人之間的內部溝通中，試著限制首字母縮寫字、縮寫、雙關語，或法律/非英語/行業特定詞彙的使用。如果有使用到的話，則將這些用語加入詞彙表，並且在使用這些詞彙的地方加上詞彙表連結。 +* 以批判性觀點看待提案與修改當中的文件與描述。如果有您看不懂的內容，很有可能其他人也同樣迷惘。 + +## 開發人員與設計師：需要的工作 + +* Frequently test with policy makers and managers if they understand what you are delivering and how you document it. +* Ask someone outside of your context if they understand the content (for example, a developer working on a different codebase). + +

+ +## Further reading + +* Meeting the [Web Content Accessibility Guidelines 2.1, Guideline 3.1 Readable](https://www.w3.org/TR/WCAG21/#readable) by W3C makes text content readable and understandable. +* The[European Union accessibility directive](https://ec.europa.eu/digital-single-market/en/web-accessibility) by the European Commission, is an example of regulation requiring high accessibility. +* [Definition of plain language](https://www.plainlanguage.gov/about/definitions/) by United States General Services Administration. diff --git a/origin_source/criteria/welcome-contributors.md b/origin_source/criteria/welcome-contributors.md new file mode 100644 index 00000000..0f877d20 --- /dev/null +++ b/origin_source/criteria/welcome-contributors.md @@ -0,0 +1,64 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +order: 4 +redirect_from: + - criteria/open-to-contributions +--- + +# 歡迎貢獻者 + +The atmosphere in a [codebase](../glossary.md#codebase) community helps users decide to use one codebase over another. +Welcoming anyone as a contributor enables the community to grow and sustain itself over time. +A community where contributors have clear ways to influence codebase and community goals and progress is less likely to split and end up in diverging communities. +Newcomers need to understand and trust the codebase community’s governance. + +## 需求規範 + +* The codebase MUST allow anyone to submit suggestions for changes to the codebase. +* The codebase MUST include contribution guidelines explaining what kinds of contributions are welcome and how contributors can get involved, for example in a `CONTRIBUTING` file. +* The codebase MUST document the governance of the codebase, contributions and its community, for example in a `GOVERNANCE` file. +* The contribution guidelines SHOULD document who is expected to cover the costs of reviewing contributions. +* The codebase SHOULD advertise the committed engagement of involved organizations in the development and maintenance. +* The codebase SHOULD have a publicly available roadmap. +* The codebase SHOULD publish codebase activity statistics. +* Including a code of conduct for contributors in the codebase is OPTIONAL. + +## How to test + +* Confirm that it is possible to submit suggestions for changes to the codebase. +* Confirm there are contribution guidelines. +* Confirm that the codebase governance is clearly explained, including how to influence codebase governance. +* Check that contributing guidelines cover who is expected to cover the costs of reviewing contributions. +* Check for a list of involved organizations. +* Check for a roadmap. +* Check for published activity statistics. +* Check for a code of conduct. + +## Public policy makers: what you need to do + +* 為代碼庫加入其他資源的清單，而這些資源可幫助[政策](../glossary.md#policy)專家、非政府組織、學者等，更能瞭解或可重複利用您的政策。 +* 考慮放入聯絡資訊，讓其他考慮合作的政策制定者能徵詢您的意見。 + +## Managers: what you need to do + +* Make sure that the documentation of the governance includes the current process for how to make changes to the governance. +* If the community has some consensus about how the governance should change, then include those ideas stated as ambitions in the documentation. +* If needed, make sure you have allocated budget for the contributions review process as agreed by the codebase community. +* Make sure the documentation explains how each organization is involved in the codebase, what resources it has available for it and for how long. +* Support your experienced policy makers, developers and designers to stay part of the community for as long as possible. + +

+ +## Developers and designers: what you need to do + +* Respond promptly to requests. +* Keep your managers informed of the time and resources you require to support other contributors. +* Communicate clearly to contributors what they need to do make sure their contribution can be integrated. + +## 延伸閱讀 + +* 開放原始碼指南所提供的《[營造友善的社群](https://opensource.guide/building-community/)》。 +* Mike McQuaid《[開放原始碼貢獻者瓶頸](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/)》。 +* 開放原始碼指南為成長中的[開放原始碼](../glossary.md#open-source)社群專案所寫的《[領導與治理](https://opensource.guide/leadership-and-governance/)》。 +* Pieter Hintjens《[打造網路社群](http://hintjens.com/blog:117)》(長篇文章！)。 diff --git a/origin_source/docs/printing.md b/origin_source/docs/printing.md new file mode 100644 index 00000000..7994c3b2 --- /dev/null +++ b/origin_source/docs/printing.md @@ -0,0 +1,22 @@ +# Printing + + + + +The printed Standard for Public Code is printed by Reclameland. +This guide tries to provide the relevant information to print it there or somewhere else. + +Details, mostly in order they are on the Reclameland page with the Dutch if necessary: + +* Form: Softcover book ([Reclameland product page](https://www.reclameland.nl/drukken/softcover-boeken)) +* Format: A4 +* Portrait or landscape: Portrait (Staand) +* Printing inside: 4/4 dual sided full color +* Inside material: 90 grams biotop +* Cover: 350 grams cover +* Printing cover: 4/0 one sided full cover +* Cover treatment: one sided matt foliated (Enke) +* Pages: pages of the inside + 4 + x, where x is 0-3 so that the sum becomes a multiple of 4 +* Individually sealed: no + +When these details are chosen, the cover and insides are uploaded and the order is placed payment can happen (payment ahead) after which printing starts. diff --git a/origin_source/docs/releasing.md b/origin_source/docs/releasing.md new file mode 100644 index 00000000..caada9f9 --- /dev/null +++ b/origin_source/docs/releasing.md @@ -0,0 +1,39 @@ +# Releasing a new version of the Standard for public code + + + + +1. Review state of the 'develop' branch + - Ensure all changes intended for release are merged + - Invite a proofread of the current state of the branch + - If new dashes are introduced, check if the language can be simplified to remove them in favor of more simple sentences. If a complex sentence is needed, see if the dash can be replaced with other punctuation. If a dash is truly the best expression of ideas, then follow the [Chicago Manual of Style](https://en.wikipedia.org/wiki/Dash#En_dash_versus_em_dash). +2. Create a release branch + - From 'develop', `git switch -c "release-$MAJOR.$MINOR.$PATCH"` + - Push the branch, `git push -u origin release-$MAJOR.$MINOR.$PATCH` +3. Update the new release + - [ ] Update [`AUTHORS.md`](../AUTHORS.md) with new contributors + - [ ] Update [`CHANGELOG.md`](../CHANGELOG.md) + - [ ] Update [`roadmap.md`](roadmap.md) + - [ ] Perform extra pass on diff to the 'main' branch + - run `script/generate-review-template.sh` and commit updated `docs/review-template.html` + - update `docs/standard-for-public-code.html` with the new text from the review template, updating any status changes as a result + - Reread any section or paragraph to ensure wording changes still fit the whole and do not contain grammar or spelling errors + - Ensure [fonts](https://brand.publiccode.net/typography/) are installed, see: `script/ensure-font.sh` + - Check the rendered `.pdf` using `script/pdf.sh rc1` + - Ensure no link collisions exist + - Check the page breaks, possibly removing or adding page-break CSS, for example: `

` + - If needed, commit fixes and repeat extra pass + - [ ] Push branch, compare with 'main' branch, i.e.: `https://github.com/publiccodenet/standard/compare/main...release-$MAJOR.$MINOR.$PATCH` + - Request review from multiple reviewers, especially a proofreader + - Reviewers will create issues for shortcomings found which would not prevent release + - If needed for release, reviewers may create pull requests to resolve issues + - Re-request reviews if additional pull requests are merged into release branch + - [ ] Run the to-archive-org.sh script +4. Create GitHub release with the release notes and version number + - [ ] `git tag trigger-$MAJOR.$MINOR.$PATCH` + - [ ] `git push --tags` (see: `../.github/workflows/release-on-tag.yml`) + - [ ] delete local tag: `git tag -d trigger-$MAJOR.$MINOR.$PATCH` +5. [Send the files for print to the printer](printing.md) + - [ ] Cover file + - [ ] Inside pages PDF +6. Ping [translation](https://github.com/publiccodenet/community-translations-standard) contributors diff --git a/origin_source/docs/roadmap.md b/origin_source/docs/roadmap.md new file mode 100644 index 00000000..40e5f47d --- /dev/null +++ b/origin_source/docs/roadmap.md @@ -0,0 +1,33 @@ +# Roadmap + + + + +Last updated: 2023-03-08 + +This document intends to shed light on the current development plans of the team. +Plans change constantly as new information is absorbed by the team. + +Codebase stewards review the roadmap monthly as part of our [backlog pruning session](https://about.publiccode.net/activities/standard-maintenance/backlog-pruning.html). + +## Current work + +* As far as possible, make the standard Standard-compliant +* Certification badges + +## Near term + +* Separate executive summary (issue #302) +* Physical paper checklist +* Possibly: add in the illustrations for each criterion + +## Longer term + +* Add to README and index.md information (and eventually statistics) on adoption and use (issue #438) +* Becoming validated by multiple codebases +* Release version 1.0.0 after a few codebases are compliant +* Linkable requirements +* New cover art +* Register for ISBN +* List with an on-demand book printing service +* QR codes for external links in print version diff --git a/origin_source/foreword.md b/origin_source/foreword.md new file mode 100644 index 00000000..069f2207 --- /dev/null +++ b/origin_source/foreword.md @@ -0,0 +1,177 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +redirect_from: + - introduction +--- +# Foreword + +The Standard for Public Code is a set of criteria that support public organizations in developing and maintaining software and policy together. + +Anyone developing public-purpose software or policy can use this standard to work towards higher quality public services that are more cost effective, with less risk and more control. + +This foreword introduces the term public code and explains why this is important. + +## Definition of public code + +Public code is both computer source code (such as software and algorithms) and public policy executed in a public context, by humans or machines. +It encompasses the software built to operate with and as public infrastructure, along with the arrangements for its production. +Public code is explicitly distinct from regular software because it operates under fundamentally different circumstances and expectations. + +## Reasons for public code + +There are many reasons for why public code is relevant now. + +### Software code == legal code + +Software is public infrastructure. + +In the 21st century, software can be considered vital public infrastructure. +It is increasingly not just the expression of existing policy but the originator of new policy, for example where algorithms decide which districts need extra social services or policing. + +Software mechanics, algorithms and data collection have become key elements in the execution of public policies. +Computer code now executes policies that have been codified in legal code through democratic procedures. +Both forms of code set conditions for society to function according to democratically set public values, the latter executed by humans, the former by machines. +In other words, software code has increasingly started to equal legal code. + +Software should therefore be subject to the principles of democratic governance. + +### Traditional public software procurement + +Current public software production methods have not served public service delivery very well. + +In the last decade, public organizations that purchased complete software solutions have sometimes been surprised to discover that they: + +* can’t change their software to reflect changing policy or take advantage of new technology +* don’t have access to their data as it's locked into proprietary systems +* are asked to pay ever increasing license fees + +### Technological sovereignty and democratic accountability + +Public institutions, civil servants and residents deserve better. + +We believe the software that runs our society can no longer be a black box, controlled by outside companies that keep the underlying logic on which their software operates hidden in proprietary codebases. +Instead, governments and the people they serve need technological sovereignty. +This allows them to set and control the functioning of public software, just like they are able to set and control policy that is legally formulated in laws. +Citizens and civil society actors need this software to be transparent and accountable. + +The design of software as essential civic infrastructure should honor digital citizens’ rights. + +### Designing truly public software + +Public code is at the core of modern public institutions, shapes the work of civil servants and affects the lives of almost all residents. + +Public software must therefore be: + +* transparent +* accountable +* understandable for its constituents + +It must reflect the values of the society it serves, for example by being inclusive and non-discriminatory. + +Most proprietary software systems currently used by public organizations do not meet these requirements. +Public code does. + +### Values of public code + +We consider public code to have these core values: + +* Inclusive +* Usable +* Open +* Legible +* Accountable +* Accessible +* Sustainable + +## How public code works + +Public code is open source software meant for fulfilling the essential role of public organizations. +Through use, other administrations contribute back to the software, so that its development and maintenance become truly collaborative. + +Being open unlocks many other things. + +Local responsibility and democratic accountability are ensured when a public organization implements and maintains their own public code. +By being open and with a broader contributor base, the software is more secure as it benefits from many eyes spotting potential flaws. +Many contributors share the maintenance work to keep it functional and modern, which reduces future technical debt. +The shared workload is more sustainable now and in the future. +Its openness makes both the code and its data more easily adaptable in the future. +The code will be easier to retool, repurpose or retire. +This all results in lower risk public infrastructure. + +This pooling of resources lets public administrations give extra attention to how to customize the software so it works best in each local context, creating better user experiences for their end users (residents or citizens). + +### Economics of public code + +Public code offers a better economic model for public organizations as well as for commercial companies. +It's an alternative to traditional software procurement which increases local control and economic opportunity. + +Designed from the start to be open, adaptable and with data portability, it can be developed by in-house staff or trusted vendors. +Because the code is open, the public administration can change vendors if they need to. +Open code increases opportunities for public learning and scrutiny, allowing the public administration to procure smaller contracts. +Smaller procurements are easier for local small and medium enterprises to bid upon. +Public administrations can use their own software purchasing to stimulate innovation and competition in their local economy. + +This can be seen as investment leading to future economic growth. +More vendors will be necessary due to growing technology demand. + +### Procuring public code + +Public code can be used and developed by permanent in-house development teams, contractors or outsourced suppliers. +Vendors to public organizations can include public code in their bids for contracts. + +To use existing public code, you need to specify in your budget and project design that your new solution will use that codebase. +To encourage an innovative approach to adapting the public code to your context, you could describe the service or outcome in your contract. + +## The goals for the Standard for Public Code + +This Standard supports developers, designers, managers and public policy makers to: + +* develop high quality software and policy for better public service delivery +* develop codebases that can be reused across contexts and collaboratively maintained +* reduce technical debt and project failure rate +* have more granular control over, and ability to make decisions about, their IT systems +* improve vendor relationships with a better economic model + +Potential users of codebases tested against the Standard for Public Code can expect them to be highly reusable, easily maintainable and of high quality. + +The Standard for Public Code does this by: + +* setting out a common terminology for public code development +* establishing measures to help develop high quality public code +* providing guidance on how to fulfill its criteria and operationalize compliance + +The Standard for Public Code is meant to be time and technology independent. + +### Who this is for + +The Standard for Public Code is for the people who create and reuse public code: + +* public policy makers +* business and project managers +* developers and designers + +These people work at: + +* institutions, organizations and administrations in the public sector +* consultancies and vendors of information technology and policy services to public organizations + +It is not aimed at public organizations' end users (residents or citizens), journalists or academics. + +## Further reading + +* ["Modernising Public Infrastructure with Free Software" white paper](https://download.fsfe.org/campaigns/pmpc/PMPC-Modernising-with-Free-Software.pdf) by the Free Software Foundation Europe. + +### Videos on public code + +* [Collaborative Code is the Future of Cities @ DecidimFest 2019](https://www.youtube.com/watch?v=cnJtnZ9Cx1o). Talk by Ben Cerveny on the background behind the Foundation for Public Code. +* [Public Money? Public Code! - Panel @ Nextcloud Conference 2019](https://youtube.com/watch?v=QHFkD4xfd6c). Touches on topics like procurement, law and more. + +## Get involved + +This standard is a living document. +[Read our contributor guide](/CONTRIBUTING.md) to learn how you can make it better. + +## Contact + +For questions and more information about the Foundation for Public Code you can find us at [our website](https://publiccode.net/), email us at info@publiccode.net, or call us at +31 20 2 444 500. diff --git a/origin_source/glossary.md b/origin_source/glossary.md new file mode 100644 index 00000000..4cb3464e --- /dev/null +++ b/origin_source/glossary.md @@ -0,0 +1,86 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2022 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +--- +# Glossary + +## Code + +Any explicitly described system of rules. +This includes laws, policy and ordinances, as well as source code that is used to build software. +Both of these are rules, some executed by humans and others by machines. + +## Codebase + +Any discrete package of code (both source and policy), the tests and the documentation required to implement a piece of policy or software. + +This can be, for example, a document or a version-control repository. + +## Continuous integration + +In software engineering, continuous integration (CI) is the practice of merging all developers' working copies to a development branch of a codebase as frequently as reasonable. + +## Different contexts + +Two contexts are different if they are different public organizations or different departments for which there is not one decision maker that could make collaboration happen naturally. + +## General public + +The public at large: end users of the code and the services based upon it. + +For example, a city's residents are considered end users of a city's services and of all code that powers these services. + +## Open source + +Open source is defined by the Open Source Initiative in their [Open Source Definition](https://opensource.org/osd-annotated). + +## Open standard + +An open standard is any standard that meets the Open Source Initiative's [Open Standard Requirements](https://opensource.org/osr). + +## Policy + +A policy is a deliberate system of principles to guide decisions and achieve rational outcomes. +A policy is a statement of intent, and is implemented as a procedure or protocol. +Policies are generally adopted by a governance body within an organization. +Policies can assist in both subjective and objective decision making. + +Public policy is the process by which governments translate their political vision into programs and actions to deliver outcomes. + +At the national level, policy and legislation (the law) are usually separate. +The distinction is often more blurred in local government. + +In the Standard the word 'policy' refers to policy created and adopted by public organizations such as governments and municipalities. + +## Public code + +Public code is open source software developed by public organizations, together with the policy and guidance needed for collaboration and reuse. + +Public code is both computer source code (such as software and algorithms) and public policy executed in a public context, by humans or machines. + +Public code serves the public interest, is open, legible, accountable, accessible and sustainable. + +By developing public code independently from but still implementable in the local context for which it was developed, as well as documenting the development process openly, public code can provide a building block for others to: + +* re-implement in their local context +* take as a starting point to continue development +* use as a basis for learning + +To facilitate reuse, public code is either released into the public domain or licensed with an open license that permits others to view and reuse the work freely and to produce derivative works. + +## Repository + +A repository is a storage location used by version control tools for files and metadata of a codebase. +Repositories allow multiple contributors to work on the same set of files. +Repositories are able to store multiple versions of sets of files. + +## Source Code + +Human readable text of a computer program which can be translated into machine instructions. + +## Version control + +Version control is the management of changes to source code and the files associated with it. +Changes are usually identified by a code, termed the *revision number* (or similar). +Each revision is associated with the time it was made and the person making the change, thus making it easier to retrace the evolution of the code. +Revision control systems can be used to compare different versions with each other and to see how content has changed over time. diff --git a/origin_source/index.md b/origin_source/index.md new file mode 100644 index 00000000..1700ac9e --- /dev/null +++ b/origin_source/index.md @@ -0,0 +1,46 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2022 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +toc: false +--- +# Guidance for government open source collaboration + +The Standard for Public Code is a set of criteria that supports public organizations in developing and maintaining software and policy together. + +The Standard for Public Code provides guidance to public organizations building their own open source solutions to enable successful future collaboration and reuse by similar organizations in the public sector in other places. +It includes advice for policy makers, government managers, developers and vendors. +The Standard for Public Code supports the collaborative creation of codebases that are usable, open, legible, accountable, accessible and sustainable. +It is meant to be applicable to codebases for all levels of government, from supranational to municipal. + +The Standard for Public Code defines ‘[public code](glossary.md#public-code)’ as open source software developed by public organizations, together with the policy and guidance needed for collaboration and reuse. + +The criteria of the Standard for Public Code are aligned with guidelines and best practices of open source software development. + +{% for page in site.pages %}{% if page.name == "foreword.md" %} +Additional context and background can be found in the [foreword](foreword.md). +{% endif%}{% endfor %} + +## Contents + +* [Readers guide: how to interpret this standard](readers-guide.md) +* [Glossary](glossary.md) +* [Criteria](criteria/){% assign sorted = site.pages | sort:"order" %}{% for page in sorted %}{% if page.dir == "/criteria/" %}{% if page.name != "index.md" %}{% if page.title %} + * [{{page.title}}]({{page.url}}){% endif%}{% endif%}{% endif%}{% endfor %} +* [Authors](AUTHORS.md) +* [Contributing guide](CONTRIBUTING.md) +* [Code of conduct](CODE_OF_CONDUCT.md) +* [Governance](GOVERNANCE.md) +* [Version history](CHANGELOG.md) +* [License](license.html) + +## Community calls + +We usually have a community call on the first Thursday of the month at 15:00 (CET/CEST). +[The agenda](https://write.publiccode.net/pads/Community-Call-Standard-for-Public-Code) is updated roughly a week before the call. +It is possible to [sign up](https://odoo.publiccode.net/survey/start/594b9243-c7e5-4bc1-8714-35137c971842) to get a call invitation emailed to you. + +## Other resources + +* Unofficial [community translations of the Standard](https://publiccodenet.github.io/community-translations-standard/) in other languages +* [Standard compliance self assessment](https://publiccodenet.github.io/assessment-eligibility/) for public sector open source codebases +* [Standard criteria checklist](/docs/review-template.html) used by Foundation for Public Code stewards for codebase review diff --git a/origin_source/readers-guide.md b/origin_source/readers-guide.md new file mode 100644 index 00000000..9a6208ab --- /dev/null +++ b/origin_source/readers-guide.md @@ -0,0 +1,72 @@ +--- +# SPDX-License-Identifier: CC0-1.0 +# SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS +--- +# Readers guide + +The Standard describes a number of criteria. +All criteria have consistent sections that make it clear how to create great public code. + +References to "policy makers", "managers", and "developers and designers" apply to anyone performing duties associated with these roles, regardless of their job title. +It is common for individuals to have duties which span multiple roles. + +Below is a brief explanation of each of these sections and how they are used within the criteria of the Standard. + +## Introduction + +This section explains what the criterion aims to achieve and why it is important for a codebase's users and contributors. + +## Requirements + +This section lists what needs to be done in order to comply with the standard. + +The following keywords in this document are to be interpreted as described in [IETF RFC 2119](https://tools.ietf.org/html/rfc2119): + +* MUST +* MUST NOT +* REQUIRED +* SHALL +* SHALL NOT +* SHOULD +* SHOULD NOT +* RECOMMENDED +* MAY +* OPTIONAL + +## How to test + +This section offers actions you can take to see if a contribution is compliant with the Standard. +This is key if you want to operationalize the Standard. + +We've tried to word it so that someone who is not intimately acquainted with the subject matter can still do a basic check for compliance. + +## Public policy makers: what you need to do + +This section tries to specifically speak to policy makers by offering them concrete actions they can perform in their role. + +Public policy makers set the priorities and goals of projects and may be less technologically experienced. + +## Managers: what you need to do + +This section tries to specifically speak to managers by offering concrete actions they can perform in their role. + +Managers are responsible for on-time project delivery, stakeholder management and continued delivery of the service. +For this they are wholly reliant on both policy makers as well as developers and designers. +They need to create the right culture, line up the right resources and provide the right structures to deliver great services. + +## Developers and designers: what you need to do + +This section tries to specifically speak to developers and designers by offering them concrete actions they can perform in their role. + +Developers are usually more technically aligned and have more impact on the delivery of services than the previous groups. + +## Limitation of scope + +The Standard for Public Code is not meant to cover individual implementations of a codebase. +This means the standard does not tell implementers how to comply with their organization's local technical infrastructure or legal framework. + +Also, while the Standard for Public Code refers to several standards and has considerable overlap with others, its purpose is to enable collaboration. +Therefore, it does not aim to replace quality standards, like the ISO 25000 series, or those focusing on security, like the [OpenSSF Best Practices Badge](https://github.com/coreinfrastructure/best-practices-badge), but to synergize well with them. + +And while the purpose includes enabling collaboration, it will not guarantee that a community will spring into existence. +That still requires proactiveness and ambition beyond making the codebase collaboration ready. diff --git a/python/po2md.py b/python/po2md.py new file mode 100644 index 00000000..3cd0cd10 --- /dev/null +++ b/python/po2md.py @@ -0,0 +1,102 @@ +import os +import shutil +import subprocess + +PROJECT_FOLDER = "./" +SOURCE_FOLDER = "./origin_source" + +def main(): + root_path = "./" + source_path = "./origin_source" + + # 1. get all md file + md_files = find_md_files(PROJECT_FOLDER) + + # 2. filter origin file + md_files = [file for file in md_files if not file.startswith(SOURCE_FOLDER)] + + # 3A. backup md file (只有主程式更新的時候，才需要複製一次) + # backup_md_files(md_files) + + # 3B. restore md file + restore_md_files(md_files) + + # 4. run po2md + for file in md_files: + full_target_path = os.path.join(SOURCE_FOLDER, os.path.relpath(file, PROJECT_FOLDER)) + do_po2md(source_file=full_target_path, target_file=file) + + # 4. update md file + update_md_file(SOURCE_FOLDER) + + + + +def find_md_files(folder_path) -> list: + md_files = [] + for root, dirs, files in os.walk(folder_path): + md_files += [os.path.join(root, file) for file in files if file.endswith('.md')] + return md_files + +# 複製原始檔案 +def backup_md_files(files): + if not os.path.exists(SOURCE_FOLDER): + os.makedirs(SOURCE_FOLDER) + + for file in files: + # 建立目標資料夾的完整路徑 + full_target_path = os.path.join(SOURCE_FOLDER, os.path.relpath(file, PROJECT_FOLDER)) + if not os.path.exists(os.path.dirname(full_target_path)): + os.makedirs(os.path.dirname(full_target_path)) + + # 複製檔案到目標資料夾 + shutil.copy2(file, full_target_path) + +# 還原原始檔案 +def restore_md_files(files): + for file in files: + full_target_path = os.path.join(SOURCE_FOLDER, os.path.relpath(file, PROJECT_FOLDER)) + shutil.copy2(full_target_path, file) + + +def do_po2md(source_file, target_file): + locale_file = "locales/zh_Hant/LC_MESSAGES/messages.po" + cmd = f"po2md -p {locale_file} -s {target_file} {source_file}" + result = subprocess.run(cmd, shell=True, capture_output=True, text=True) + if result.returncode != 0: + print("錯誤訊息：") + print(result.stderr) + exit() + +def update_md_file(source_path): + source_marker = "---" + target_marker = "***" + + source_files = find_md_files(source_path) + for file in source_files: + with open(file, 'r') as infile: + file_content = infile.read() + + start_index = file_content.find(source_marker) + end_index = file_content.find(source_marker, start_index + len(source_marker)) + copied_content = file_content[start_index:end_index + len(source_marker)] + + + with open(file[len(source_path) + 1:], 'r') as infile: + file_content = infile.read() + + start_index = file_content.find(target_marker) + end_index = file_content.find(target_marker, start_index + len(target_marker)) + if end_index == -1: + print(file) + continue + + new_content = copied_content + file_content[end_index + len(target_marker):] + + with open(file[len(source_path) + 1:], 'w') as outfile: + outfile.write(new_content) + + + +if __name__ == '__main__': + main() \ No newline at end of file diff --git a/python/update_po.py b/python/update_po.py new file mode 100644 index 00000000..b8df8924 --- /dev/null +++ b/python/update_po.py @@ -0,0 +1,34 @@ +import os +import shutil +import subprocess +import polib + + +def main(): + locals_en = 'locales/en/LC_MESSAGES/messages.po' + locals_zh = 'locales/zh_Hant/LC_MESSAGES/messages.po' + en_po = polib.pofile(locals_en) + zh_po = polib.pofile(locals_zh) + + zh_msgids = set(entry.msgid for entry in zh_po) + + # 遍歷 en.po 中的每一個 entry + for entry in en_po: + # 如果 en.po 中的 msgid 不在 zh.po 中 + if entry.msgid not in zh_msgids: + # 創建一個新的 POEntry 對象 + new_entry = polib.POEntry( + msgid=entry.msgid, + msgstr='', # 初始為空字符串 + ) + # 將新的 entry 添加到 zh.po 中 + zh_po.append(new_entry) + + # 儲存更新後的 zh.po 檔案 + zh_po.save(locals_zh) + + + + +if __name__ == '__main__': + main() \ No newline at end of file diff --git a/readers-guide.md b/readers-guide.md index 9a6208ab..62c20c45 100644 --- a/readers-guide.md +++ b/readers-guide.md @@ -2,71 +2,69 @@ # SPDX-License-Identifier: CC0-1.0 # SPDX-FileCopyrightText: 2019-2023 The Foundation for Public Code , https://standard.publiccode.net/AUTHORS --- -# Readers guide -The Standard describes a number of criteria. -All criteria have consistent sections that make it clear how to create great public code. +# 讀者指引 -References to "policy makers", "managers", and "developers and designers" apply to anyone performing duties associated with these roles, regardless of their job title. -It is common for individuals to have duties which span multiple roles. +本標準描述說明許多準則。所有準則各小節結構維持一致，來讓讀者清楚明白如何開發良好的公共程式。 -Below is a brief explanation of each of these sections and how they are used within the criteria of the Standard. +「政策制定者」、「管理人員」以及「開發人員與設計師」的稱呼，係指任何履行這些角色職責的人，不受其職稱限制。常見同時承擔多個角色職責的人。 -## Introduction +以下是各小節的簡要介紹，以及在本標準準則中的作用。 -This section explains what the criterion aims to achieve and why it is important for a codebase's users and contributors. +## 前言 -## Requirements +本小節說明這些準則想達成的目的，以及為何會對程式基底使用者與貢獻者來說這麼重要的原因。 -This section lists what needs to be done in order to comply with the standard. +## 需求規定 -The following keywords in this document are to be interpreted as described in [IETF RFC 2119](https://tools.ietf.org/html/rfc2119): +這個小節列出如果要遵循本標準，需要完成哪些事項。 -* MUST -* MUST NOT -* REQUIRED -* SHALL -* SHALL NOT -* SHOULD -* SHOULD NOT -* RECOMMENDED -* MAY -* OPTIONAL +本文件中的下列關鍵字，請以《[IETF RFC 2119](https://tools.ietf.org/html/rfc2119)》的描述作解釋： -## How to test +* 必須 +* 禁止 +* 要求 +* 應當 +* 不得 +* 應該 +* 不該 +* 建議 +* 得以 +* 可選擇 -This section offers actions you can take to see if a contribution is compliant with the Standard. -This is key if you want to operationalize the Standard. +## 測試方式 -We've tried to word it so that someone who is not intimately acquainted with the subject matter can still do a basic check for compliance. +本小節提供您可採取的行動，來確認貢獻內容是否遵循本標準。如果您想要務實操作本標準，這部分很關鍵。 -## Public policy makers: what you need to do +我們已嘗試調整用字，讓即使是不熟悉這類主題內容的讀者，看完之後也能夠進行基本的遵循檢查。 -This section tries to specifically speak to policy makers by offering them concrete actions they can perform in their role. +## 公共政策制定者：需要的工作 -Public policy makers set the priorities and goals of projects and may be less technologically experienced. +本小節主要對象是政策制定者，列出他們的角色所能採取的具體行動。 -## Managers: what you need to do +公共政策制定者設定專案的優先順序與目標，而在科技上的經驗可能沒那麼多。 -This section tries to specifically speak to managers by offering concrete actions they can perform in their role. +## 管理人員：需要的工作 -Managers are responsible for on-time project delivery, stakeholder management and continued delivery of the service. -For this they are wholly reliant on both policy makers as well as developers and designers. -They need to create the right culture, line up the right resources and provide the right structures to deliver great services. +本小節主要對象是管理人員，列出他們的角色所能採取的具體行動。 -## Developers and designers: what you need to do +管理人員負責監督專案的準時交付、利害關係人管理，以及服務的持續交付。因此，他們得完全依賴政策制定者、開發人員與設計師。他們需要塑造正確的文化、籌備合適的資源、提供適 +當的架構等，才能交付優良的服務。 -This section tries to specifically speak to developers and designers by offering them concrete actions they can perform in their role. +## 開發人員與設計師：需要的工作 -Developers are usually more technically aligned and have more impact on the delivery of services than the previous groups. +本小節主要對象是開發人員與設計師，列出他們的角色能採取的具體行動。 -## Limitation of scope +開發人員通常對技術比較在行，與其他角色類別相比，對服務交付的影響更大。 -The Standard for Public Code is not meant to cover individual implementations of a codebase. -This means the standard does not tell implementers how to comply with their organization's local technical infrastructure or legal framework. +## 作用範圍限制 -Also, while the Standard for Public Code refers to several standards and has considerable overlap with others, its purpose is to enable collaboration. -Therefore, it does not aim to replace quality standards, like the ISO 25000 series, or those focusing on security, like the [OpenSSF Best Practices Badge](https://github.com/coreinfrastructure/best-practices-badge), but to synergize well with them. +《公共程式標準》不是為了涵蓋程式基底的個別實作而撰寫。這代表本標準不是要告訴實作人員，該如何遵循其組織單位當地的技術性基礎建設或法律框架。 -And while the purpose includes enabling collaboration, it will not guarantee that a community will spring into existence. -That still requires proactiveness and ambition beyond making the codebase collaboration ready. +此外，雖然《公共程式標準》有引用一些標準，並且與其他標準有滿多重疊的部分，但本標準的目的是要推動協作。因此，本標準目標不在於取代品質標準，像是 ISO 25000 +認證系列，或是取代那些聚焦於安全性的標準，例如 [OpenSSF 最佳實務標 +章](https://github.com/coreinfrastructure/best-practices-badge)等，而是希望能與它們能良好協同搭 +配。 + +《公共程式標準》的目在於促進協作，但也無法保證能夠催生出一個社群。若要建立社群，除了程式基底需要準備好進行協作以外，也需要積極主動，以及做到超越協作以外的企圖 +心。 diff --git a/script/serve.sh b/script/serve.sh index 49fff946..94cea3a2 100755 --- a/script/serve.sh +++ b/script/serve.sh @@ -12,4 +12,5 @@ if [ "_${PAGES_REPO_NWO}_" == "__" ]; then export PAGES_REPO_NWO=publiccodenet/standard fi -bundle exec jekyll serve --livereload +#bundle exec jekyll serve --livereload --host 127.0.0.1 --port 6015 +bundle exec jekyll serve --host https://lyzez5.toomore.net --port 6015