├── CLA.md ├── LICENSE ├── README.md ├── __archive ├── coding conversion.md └── jupyter-governance-based │ ├── Governance_bak.md │ ├── README.md │ ├── code_of_conduct_hanu.ko.md │ ├── governance_hanu.ko.md │ ├── newsubprojects_hanu.ko.md │ ├── papers_hanu.ko.md │ ├── people_hanu.ko.md │ ├── projectlicense_hanu.ko.md │ └── trademarks_hanu.ko.md ├── assets ├── images │ └── git-workflow.png └── logo │ └── hanu-logo-temp.png ├── code-of-conduct.md ├── communication └── README.md ├── contributing ├── README.md ├── developing.md ├── github-workflow.md └── pull-requests.md ├── developing ├── README.md ├── build.md ├── ci-cd.md ├── coding-convention.md ├── hanu-cicd-flow-v4.jpg ├── release.md └── test.md └── governance ├── README.md ├── committee └── README.md ├── election.md ├── group.md ├── membership.md ├── repository.md └── sig ├── README.md ├── sig-arm ├── CONTRIBUTING.md ├── README.md └── charter-sig-arm.md └── sig-charter-template.md /CLA.md: -------------------------------------------------------------------------------- 1 | # Contributor License Agreement (준비 중) 2 | 3 | HANU에 속한 오픈소스SW 프로젝트들의 Code Repository에 기여해주셔서 감사합니다. 4 | 5 | HANU 프로젝트에서는 여러분들의 기여를 커뮤니티내 모든 분들이 자유롭게 사용할 수 있도록 CLA (Contributor License Agreement)를 준비하고 있습니다. 6 | 7 | 준비가 되는데로 이 페이지를 통해서 자세한 내용을 알려드리도록 하겠습니다. 8 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # HANU Community Guide (작성 중) 2 | 3 | HANU Community에 오신 것을 환영합니다! 4 | 5 | - [HANU Community Guide (작성 중)](#hanu-community-guide-작성-중) 6 | - [HANU (HAm kke NU rim; 함께 누림)](#hanu-ham-kke-nu-rim-함께-누림) 7 | - [프로젝트 소개](#프로젝트-소개) 8 | - [TACOPLAY](#tacoplay) 9 | - [DECAPOD (DEClarative APplication Orchestration & Delivery)](#decapod-declarative-application-orchestration--delivery) 10 | - [HANUCTL (Incubation)](#hanuctl-incubation) 11 | - [Governance](#governance) 12 | - [How to Use](#how-to-use) 13 | - [How to Develop](#how-to-develop) 14 | - [How to Contribute](#how-to-contribute) 15 | - [Communication](#communication) 16 | - [License](#license) 17 | - [Support](#support) 18 | 19 | 20 | **현재 Governance와 커뮤니티 운영을 위해 필요한 내용들을 정리하여 문서화 진행하고 있습니다.** 21 | 22 | ## HANU (HAm kke NU rim; 함께 누림) 23 | HANU 프로젝트는 Open Infrastructure 및 Cloud Native Computing과 관련된 다양한 기술들을 오픈소스SW로 개발하고, 이와 관련된 커뮤니티를 구성하고 활성화 하기 위한 공간입니다. 24 | 25 | ## 프로젝트 소개 26 | 27 | HANU에는 여러 개의 오픈소스SW 프로젝트들이 있습니다. HANU의 프로젝트들은 각각 고유의 기능/구조적 특징을 가지면서, 필요 시 서로 연계할 수 있도록 되어 있습니다. 28 | 29 | HANU의 프로젝트는 두 개로 나뉘어 집니다. 첫번째로 Incubation Project로 시작이 되며, 그 이후 충분한 기능적 완성도와 안성정을 갖추게 되면 Stable Project로 전환 될 수 있습니다. 30 | 31 | Incubation Project는 누구든지 생성을 제안할 수 있으며, Technical Committee에서 결정합니다. 32 | 33 | ### TACOPLAY 34 | 35 | Ansible기반의 Baremetal, Docker, Kubernetes 설치 자동화 기능을 제공하며, 설치된 Kubernetes 상에서 Airship Armada 혹은 decapod를 활용하여 컨테이너화된 OpenStack 이나 LMA (Logging, Monitoring, Alerting), 혹은 추가 Add-on tools 들을 설치할 수 있는 ansible playbook들을 제공합니다. 36 | 37 | ### DECAPOD (DEClarative APplication Orchestration & Delivery) 38 | 39 | Kustomize 기반의 YAML Document 구조화 및 관리 기능과 Helm과 Argo를 기반 기술로 한 Declarative Application 배포 및 라이프사이클 관리 소프트웨어입니다. 40 | 41 | ### HANUCTL (Incubation) 42 | 43 | TACOPLAY를 대체하는 Kubernetes Cluster-API 기반의 Cloud Native Infrastructure Lifecycle Management Controller입니다. 44 | 45 | 46 | ## Governance 47 | 48 | HANU Community는 오픈소스의 협업과 공유 정신에 따라 누구든지 참여할 수 있으며, 모든 의사결정은 투명하게 공개됩니다. 이러한 원칙을 지속하기 위해 Membership과 Group에 대한 Governance 체계를 구축하였으며, HANU에 속한 모든 프로젝트는 이러한 Governance 체계에 따라 운영됩니다. 자세한 내용은 [Governance](governance/README.md)를 살펴보세요. 49 | 50 | ## How to Use 51 | 52 | HANU Community 내 Project는 각각의 README에서 사용/설치/운영 방법을 자세히 소개합니다. 53 | 54 | > `need-to-improve` 55 | > * DECAPOD : 56 | > * ... : 57 | > * ... : 58 | 59 | ## How to Develop 60 | 61 | HANU Commnity 내 Project를 개발하기 위해 숙지해야할 사항이 있습니다. [빌드 가이드](developing/build.md), [테스트 가이드](develop/test.md), 코드 컨벤션, [CI/CD](developing/README.md), 릴리즈에 대한 상세한 내용은 [이곳](developing/README.md)을 참고하세요. 62 | 63 | ## How to Contribute 64 | 65 | HANU Community는 모든 소스 코드와 문서를 완전히 공개하고 커뮤니티 구성원이 협업하여 개발하는 오픈소스 개발 방식을 따릅니다. 여러분의 소중한 기여로 HANU Community의 Project는 성장할 수 있습니다. 66 | 67 | 여기서는 HANU Project에 기여하기 위한 방법을 자세히 설명합니다. : [Contributing](contributing/README.md) 68 | 69 | 70 | ## Communication 71 | 72 | HANU Community는 Project별로 Mailing List와 Slack 채널을 통해 소통하고 있습니다. 73 | 74 | 각 Project의 Mailing List 및 Slack 채널 정보는 다음 페이지에서 확인하세요. : [Communication](communication/README.md) 75 | 76 | 77 | ## License 78 | 79 | HANU Community는 모든 Project는 다음 라이선스에 따라 배포합니다. 80 | * 소스 코드 : [Apache-2.0](https://spdx.org/licenses/Apache-2.0.html) 81 | * 소스 코드 이 외의 콘텐츠 (문서, 이미지 등) : [CC-BY-4.0](https://spdx.org/licenses/CC-BY-4.0.html) 82 | 83 | 84 | ## Support 85 | 86 | HANU Community 운영과 관련한 문의/요청이 있을 경우 [Issue](https://github.com/openinfradev/community/issues/new)를 생성해서 의견 남겨 주세요. 87 | 88 | -------------------------------------------------------------------------------- /__archive/coding conversion.md: -------------------------------------------------------------------------------- 1 | # (필요에 따라 아래 항목들을 수정하여 사용하세요~^^) 2 | # Coding Conversion 3 | 4 | **Table of Contents** 5 | 6 | 7 | 8 | 9 | ## Overview 10 | 11 | 12 | 13 | ## Coding conversion and Running the Tests 14 | 15 | 16 | ### Cleaning up 17 | 18 | 19 | 20 | ## Advanced testing 21 | 22 | ### Extracting a specific version of Kubernetes 23 | 24 | 25 | 26 | ### Version-skewed and upgrade testing 27 | 28 | 29 | #### Test jobs naming convention 30 | 31 | 32 | ### Viper configuration and hierarchichal test parameters. 33 | 34 | 35 | ### Conformance tests 36 | 37 | 38 | ## Continuous Integration 39 | 40 | 41 | 42 | ### What is CI? 43 | 44 | 45 | 46 | ### What runs in CI? 47 | 48 | 49 | 50 | #### Non-default tests 51 | 52 | 53 | 54 | ### The PR-builder 55 | 56 | 57 | 58 | ### Adding a test to CI 59 | 60 | 61 | 62 | **NOTE:** 63 | 64 | ### Moving a test out of CI 65 | 66 | 67 | ## Performance Evaluation 68 | 69 | 70 | 71 | ## One More Thing 72 | 73 | 74 | 75 | **HAPPY Coding!** 76 | 77 | -------------------------------------------------------------------------------- /__archive/jupyter-governance-based/Governance_bak.md: -------------------------------------------------------------------------------- 1 | ## Our Mission 2 | HANU는 오픈스택과 쿠버네티스 upstream project를 기반으로, 국내 기업과 엔지니어들이 주축이 되어, 그 project를 국내에서 활성화하여 upstream에 기여하는것에 그 가치를 둔다. 3 | 4 | 또한 국내 기업과 엔지니어들이 협업하여, 국내에 지원체계를 구축하여 오픈소스 생태계를 확장하는데 기여한다. 5 | 6 | 7 | 8 | ## Principles and Goals 9 | 본 조직의 목적과 원칙에 대한 정의 10 | 11 | 12 | 13 | 14 | 15 | 16 | ## Code of Conduct 17 | 자세한 내용은 [Code of Conduct](code-of-conduct.m)를 참조하십시오. 18 | 19 | 20 | 21 | ## Organization 22 | 23 | 24 | 25 | 26 | ## Operation Guide 27 | - Logging and Monitoring 28 | - Maintenance, Failure and Debugging 29 | - (Network) Trouble Shooting 30 | - Backup and Recovery 31 | - Configuration and Upgrade 32 | 33 | 34 | 35 | 36 | ## Build and Release 37 | 38 | 39 | 40 | 41 | ## Contributions 42 | 43 | 44 | 45 | 46 | 47 | 48 | ## Repository 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | ## Contact 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | -------------------------------------------------------------------------------- /__archive/jupyter-governance-based/README.md: -------------------------------------------------------------------------------- 1 | # HANU Project Governance 2 | 3 | 이 저장소의 목적은 HANU 프로젝트가 비공식적으로 사용한 거버넌스 프로세스르 공식화 하는 것입니다. 4 | 이 문서는 오픈 소스 협업 개발과 영리 또는 비영리 단체가 자금을 제공 할 수있는 업무 간의 관계를 포함하여 의사 결정 방법과 커뮤니티의 다양한 요소가 상호 작용하는 방식을 설명합니다. 5 | 6 | 거버넌스 문서는 https://github.com/openinfradev/community-draft 에서 확인할 수 있습니다. 7 | 8 | ## 목차 9 | * [메인 거버넌스 문서](governance_hanu.ko.md) 10 | * [현재 운영 협의회 및 파트너](people_hanu.ko.md) 11 | * [서브 프로젝트 인큐베이션 프로세스](newsubprojects_hanu.ko.md) 12 | * [관련 학술 논무 작성 절차](papers_hanu.ko.md) 13 | * [코드 라이센스](projectlicense_hanu.ko.md) 14 | * [프로젝트 행동 수칙](code_of_conduct_hanu.ko.md) 15 | -------------------------------------------------------------------------------- /__archive/jupyter-governance-based/code_of_conduct_hanu.ko.md: -------------------------------------------------------------------------------- 1 | # 프로젝트 HANU 행동 수칙 2 | 3 | 프로젝트 HANU는 전 세계의 사람들로 구성된 참여하고 존중하는 커뮤니티입니다. 귀하의 참여는 우리의 사명을 발전시키고 연구 및 교육에서 저널리즘, 산업 및 그 이상에 이르는 광범위한 커뮤니티에 서비스를 제공하는 개방형 플랫폼을 만드는 데 도움이됩니다. 4 | 5 | 당연히 이것은 복잡한 문제에 대한 다양한 아이디어와 관점을 의미합니다. 상충되는 견해에 대한 의견 불일치와 건전한 논의는 환영합니다. 어려운 문제에 대한 최상의 해결책은 단일 각도에서 거의 나오지 않습니다. 그러나 불일치는 침략의 변명이 아닙니다. 인간은 불일치를 개인적으로 쉽게 받아들이고 궁극적으로 공동체를 타락시키는 행동으로 편향되는 경향이 있습니다. 이것은 많은 인간 행동의 신호를 이용할 수없는 언어 및 문화적 격차를 통한 온라인 커뮤니케이션에서 특히 심각합니다. 우리는 여기서 이러한 도전에 직면하여 건강한 공동체를 지원하기위한 일련의 원칙과 프로세스를 개괄하고 있습니다. 6 | 7 | 기본적으로 우리는 모든 사람을 위해 생산적이고 괴롭힘이없는 환경을 조성하기 위해 노력하고 있습니다. 이 규범을 고려할 수없는 철저한 목록이 아니라 의도 된 정신으로 가져 가십시오. 우리 모두와 우리가 참여하는 지역 사회를 더 풍요롭게하는 데 도움이되는 안내서입니다. 8 | 9 | 중요 : 우리 커뮤니티 회원으로서 귀하는 또한 이러한 가치의 청지기이기도합니다. 모든 문제가 공식적인 프로세스를 통해 해결 될 필요는 없으며, 온라인 포럼이나 직접 방문하는 빠르고 친근하지만 명확한 단어는 오해와 이관을 해결하는 데 도움이 될 수 있습니다. 10 | 11 | 그러나 때로는 이러한 비공식적 인 프로세스가 부적절 할 수 있습니다. 작동하지 않거나, 누군가에게 긴급하거나 위험이 있으며, 아무도 공개적으로 개입하지 않으며 공개적으로 말하는 것이 불편한 경우 등이 있습니다. 이러한 이유로 인해 구조화 된 후속 조치 우리는 필요할 수 있으며 여기에 그 수단을 제공합니다. 우리는 Conduct@hanu.org 로 이메일을 보내 거나이 양식을 작성하여 보고서를 환영합니다 . 자세한 내용은보고 지침 (온라인 및 개인 상황)을 참조하십시오. 12 | 13 | 이 코드는 Project HANU가 관리하는 모든 공간 (IPython 포함)에서 창립자, 개발자, 멘토 및 새로운 커뮤니티 회원에게 동일하게 적용됩니다. 여기에는 메일 링리스트, GitHub 조직, 대화방, 개인 이벤트, 담화 커뮤니티 포럼 및 프로젝트 팀이 만든 기타 포럼이 포함됩니다. 또한이 공간 외부에서이 코드를 위반하면 해당 공간에 참여하는 사람의 능력에 영향을 줄 수 있습니다. 14 | 15 | ## 예상되는 행동 16 | 17 | 다음과 같은 원칙, 지침 및 조치를 따르거나 피함으로써 HANU를 환영하고 생산적인 커뮤니티로 만들 수 있습니다. 질문이 있으시면 Conduct@hanu.org 의 행동 강령위원회에 연락하십시오 . 18 | 19 | 1. **친절과 인내심**. 20 | 21 | 2. **환영하는 태도**. 우리는 모든 배경과 정체성을 가진 사람들을 환영하고 지원하는 공동체가되기 위해 노력합니다. 여기에는 인종, 민족, 문화, 출신 국가, 피부색, 이민 상태, 사회 및 경제 계층, 교육 수준, 성별, 성적 취향, 성별 정체성 및 표현, 나이, 신체적 외모, 가족이 포함되지만 이에 국한되지 않습니다. 상태, 기술 또는 직업 선택, 학문 분야, 종교, 정신 능력 및 신체 능력. 22 | 23 | 3. **서로에 대하 배려**. 당신의 일은 다른 사람들에 의해 사용될 것이며, 당신은 다른 사람들의 일에 의존 할 것입니다. 모든 결정은 사용자와 동료에게 영향을 미치므로 결정을 내릴 때 이러한 결과를 고려해야합니다. 우리는 전세계 커뮤니티라는 것을 기억하십시오. 다른 기본 언어 또는 문화적 배경을 가진 사람과 의사 소통을하고있을 수 있습니다. 24 | 25 | 4. **존경과 경청**. 우리 모두가 항상 동의하는 것은 아니지만, 불일치가 나쁜 행동이나 나쁜 태도에 대한 변명은 아닙니다. 우리 모두 지금 약간의 좌절감을 경험할 수도 있지만, 그 좌절을 개인적인 공격으로 바꿀 수는 없습니다. 사람들이 불편하거나 위협을 느끼는 커뮤니티는 생산적인 커뮤니티가 아니라는 것을 기억하는 것이 중요합니다. 26 | 27 | 5. **겸손한 의사소통**. 다른 사람들에게 친절하십시오. 다른 커뮤니티 회원을 모욕하거나 내려 놓지 마십시오. 괴롭힘 및 기타 배타적 행동은 허용되지 않습니다. 여기에는 다음이 포함되지만 이에 국한되지는 않습니다. 28 | 29 | * 다른 사람에 대한 폭력적인 위협 또는 폭력적인 언어 30 | * 차별적 농담과 언어 31 | * 성적으로 노골적이거나 폭력적인 자료 게시 32 | * 다른 사람의 개인 식별 정보 게시 (또는 게시 위협) 33 | * 개인적인 모욕, 특히 인종 차별이나 성 차별적 용어를 사용하는 사람들 34 | * 반갑지 않은 성적 관심 35 | * 위의 행동을 옹호하거나 장려 36 | * 다른 사람들의 반복 된 괴롭힘. 일반적으로 누군가가 중지를 요청하면 중지하십시오. 37 | 6. **기대**. 커뮤니티 회원이 프로젝트에서 시간을 어떻게 보내는지 선택하십시오. 다른 사람의 시간에 대한 요구보다 당신의 기대에 대한 신중한 질문이 바람직합니다. 38 | 39 | 7. **리더쉽에 대한 배려 및 존중**. 사회적 및 기술적 불일치는 항상 발생하며 HANU도 예외는 아닙니다. 다른 사람들이 어디에서 왔는지 이해하려고 노력하십시오. 그들의 관점에서 질문을 보면 새로운 길을 찾는 데 도움이 될 수 있습니다. 실수를 저지르는 것은 인간이라는 것을 잊지 마십시오. 서로를 비난한다고해서 우리를 어느 곳으로도 데려 갈 수는 없지만 실수로부터 배우면 더 나은 해결책을 찾을 수 있습니다. 40 | 41 | 8. **겸손과 사과**. 종종 상황을 악화시킬 수 있으며, 누군가에게 미안하다고 말하는 것은 자동적으로 죄의 인정을 암시하지 않는 공감 행위입니다. 42 | 43 | ## 부적절한 행동에 대한 대응 44 | 45 | 어떤 경우에는 개인이 온라인 또는 직접 상황에서 CoC를 위반할 수 있습니다. 커뮤니티 구성원이 해당 조치가 커뮤니티에 유해한 것으로 간주되면 상황을 해소하기 위해 즉시 조치를 취할 수 있습니다. 여기에는 스레드 잠금, 커뮤니티 포럼에서 사용자의 계정 일시 중지, 회의 중단 호출 또는 일반적으로 상황을 에스컬레이션하는 등 개인이 아닌 상황에 대한 조치가 포함됩니다. 사건을 CoC위원회에보고하여 조치를 수행하십시오. 46 | 47 | 사건이 신체적 위험과 관련이 있거나 다른 사람의 안전에 대한 위협 (예 : 폭력의 위협)과 관련이있는 경우, 커뮤니티의 모든 구성원은 커뮤니티 구성원의 안전을 보호하기 위해 일방적으로 행동해야합니다. 여기에는 법 집행 기관, HANU 커뮤니티의 다른 구성원 또는 다른 현지 직원과의 연락이 포함될 수 있습니다. 48 | 49 | 개별 커뮤니티 회원이 일방적으로 행동하는 상황에서는 24 시간 이내에 Conduct@hanu.orgreporting _online) 으로 이메일을 보내 최대한 빨리 행동 강령위원회에 알려야합니다 . 50 | 51 | ## 보고 52 | 53 | 누군가 행동 강령을 위반했다고 생각되면이를 적시에보고하십시오. 행동 강령 위반은 모든 사람의 공동체 가치를 낮추고 우리는 심각하게 생각합니다. 54 | 55 | Conduct@hanu.org 로 이메일을 보내 거나이 양식을 작성 하여 보고서를 제출할 수 있습니다 . 이벤트에서 직접보고하는 방법에 대한 자세한 내용은보고 지침을 참조하십시오. 56 | 57 | 온라인 양식은 보고서를 익명으로 유지하거나 직접 연락을 요청하는 옵션을 제공합니다. 익명의 보고서를 후속 조치 할 수는 없지만 적절한 조치를 취합니다. 58 | 59 | ## 시행 60 | 61 | 집행에 관한 정보는 집행 매뉴얼을 참조하십시오. 62 | 63 | Speak Up!의 원본 텍스트 제공 Project HANU에 의해 수정 된 Django Projects. 우리는 쉽게 재사용 할 수 있도록 공개 라이센스 조건에 따라 이러한 자료를 제공 한 프로젝트에 감사합니다. 64 | 65 | 이 페이지의 모든 컨텐츠는 Creative Commons Attribution 라이센스에 따라 라이센스가 부여됩니다. 66 | -------------------------------------------------------------------------------- /__archive/jupyter-governance-based/governance_hanu.ko.md: -------------------------------------------------------------------------------- 1 | 2 | # 주요 거버넌스 문서 3 | 4 | 아래 거버넌스 섹션에 정의 된 역할의 개인 및 기관 목록과 함께이 문서의 공식 버전은 다음 프로젝트 거버넌스 리포지토리에 포함되어 있습니다. 5 | 6 | [https://github.com/openinfradev/community-draft](https://github.com/openinfradev/community-draft) 7 | 8 | ## 프로젝트 9 | 10 | 11 | HANU 프로젝트 (The Project)는 TACO과 관련된 오픈 소스 소프트웨어 프로젝트입니다. 12 | 이 프로젝트의 목표는 오픈 소스 소프트웨어를 개발하고 재현 가능한 탐색 및 대화형 컴퓨팅을 위한 공개 및 공개 웹 사이트 및 서비스를 배포하는 것입니다. 13 | The Project에서 개발 한 소프트웨어는 공개적으로 개발되고 [HANU GitHub 조직] (https://github.com/hanu) 및 [HANU GitHub에 따라 공개 GitHub 저장소에서 호스팅되는 Apache (또는 유사한) 오픈 소스 라이센스로 배포됩니다] (https://github.com/hanu). 14 | 프로젝트 소프트웨어의 예로는 HANU Notebook, HANU Terminal, HANU.parallel, HANU Hub 등이 될 수 있습니다. 15 | 프로젝트가 운영하는 서비스는 hanu.org 또는 hanu.org 도메인에서 호스팅되는 공개 웹 사이트 및 웹 서비스로 구성될 예정입니다. 16 | 프로젝트 서비스의 서비스 예시는 HANU 및 HANU 웹 사이트 ([https://hanu.org] (https://hanu.org) 및 [https://hanu.org] (https://hanu.org)가 포함됩니다. ) 및 HANU 공동 실험실 ([https://colaboratory.hanu.org] (https://colaboratory.hanu.org)). 17 | 18 | 이 프로젝트는 컨트리뷰터(Contributor)라고하는 <>에 의해 개발되었습니다. 19 | 기고자는 코드, 문서, 디자인 또는 기타 작업을 하나 이상의 프로젝트 저장소에 기고 한 개인입니다. 20 | 누구나 기여자가 될 수 있습니다. 21 | 기고자는 모든 법인과 제휴하거나 전혀 관계가 없습니다. 22 | 기고자는 GitHub 풀 요청 및 문제를 제출, 검토 및 논의하고 GitHub, Google+, Hackpad, Gitter 대화방 및 메일 목록에 대한 공개 및 공개 프로젝트 토론에 참여함으로써 프로젝트에 참여합니다. 23 | 프로젝트 참여의 기초는 개방성과 투명성입니다. 24 | 기본 HANU 저장소에 대한 현재 기고자 목록은 다음과 같습니다. 25 | 26 | [https://github.com/hanu/hanu/graphs/contributors](https://github.com/hanu/hanu/graphs/contributors) 27 | 28 | HANU 및 HANU 프로젝트의 다른 리포지토리 로그에 많은 다른 기고자가 있습니다. 29 | 프로젝트 커뮤니티는 프로젝트의 모든 기고자와 사용자로 구성됩니다. 30 | 기고자는 더 큰 프로젝트 커뮤니티를 대신하여 일하며 책임을지며 기고자와 사용자 간의 장벽을 최대한 낮게 유지하려고 노력합니다. 31 | 이 프로젝트는 공식 후원사 역할을하는 TACO와 공식적으로 연계되어 있으며 프로젝트 상표 및 기타 지적 재산을 보유 할 수 있으며 프로젝트 관리에 도움이됩니다. 기부 및 모회사 법인으로 활동합니다. 32 | 33 | ## 거버넌스 34 | 35 | 이 섹션에서는 프로젝트의 거버넌스 및 리더십 모델에 대해 설명합니다. 36 | 37 | 프로젝트 거버넌스의 기초는 다음과 같습니다. 38 | 39 | - 개방성 및 투명성 40 | - 적극적인 기여 41 | - 기관 중립 42 | 43 | 전통적으로, 프로젝트 리더십은 <<개발조직>> 및 핵심 개발자라고 하는 기고자 서브셋에 의해 제공되었습니다.이 개발자는 Project GitHub 리포지토리에 대한 "커밋 권한"을 수신하여 적극적이고 일관된 기여를 인정했습니다. 44 | 일반적으로 모든 프로젝트 결정은 커뮤니티의 의견을 수렴 한 핵심 개발자 간의 합의를 통해 이루어집니다. 45 | <<개발조직>>은 핵심 개발자를 무시하고 문제에 대한 최종 결정을 내릴 수는 없지만 드물게 선택합니다. 46 | 이러한 접근 방식이 우리에게 도움이되었지만 프로젝트가 성장하고 더 많은 법적 및 재정적 결정에 직면하고 다른 기관과 상호 작용함에 따라보다 공식적인 거버넌스 모델이 필요합니다. 47 | 발전 프로젝트 리더십은 <<개발조직>>과 운영위원회로 구성됩니다. 48 | 우리는이 거버넌스 모델을 방향 변경 대신 이미하고있는 일의 공식화로 본다. 49 | 50 | ### 최상위 협의회 51 | 52 | 최상위 협의회은 프로젝트에 대한 모든 최종 결정을 내릴 권한이 있습니다. 53 | 54 | <<내용 추가>> 55 | 56 | ### 운영 협의회 57 | 58 | 이 프로젝트에는 품질과 수량면에서 상당한 기여를하고 1년 이상 지속되는 프로젝트 기여자로 구성된 운영위원회가 있습니다. 59 | 이사회의 전반적인 역할은 <<개발조직>>과의 협력을 통해 기술적으로나 공동체로서 프로젝트의 장기적인 안녕을 지역 사회로부터 정보를 얻는 것입니다. 60 | 일상적인 프로젝트 활동 동안, 협의회 구성원은 다른 모든 기고자 및 커뮤니티와 동료로서 모든 토론, 코드 검토 및 기타 프로젝트 활동에 참여합니다. 61 | 이러한 일상 활동에서 평의회 회원은 평의회 회원 자격을 통해 특별한 권한이나 특권이 없습니다. 62 | 그러나 협의회 구성원이 기술 및 프로젝트 방향으로 유용한 경험을 제공하여 잠재적으로 경험이 부족한 기여자에게 유용한 지침을 제공 할 프로젝트 소프트웨어 및 서비스에 대한 기여도 및 품질과 양으로 인해 기여할 것으로 예상됩니다. 63 | 운영 협의회와 그 구성원은 특정 상황에서 특별한 역할을합니다. 64 | 특히 이사회는 : 65 | 66 | - 프로젝트의 전체 범위, 비전 및 방향에 대한 결정을 내립니다. 67 | - 다른 조직이나 개인과 전략적 협업에 대한 결정을 내립니다. 68 | - 특정 기술 문제, 기능, 버그 및 풀 요청에 대한 결정을 내립니다. 그것들은 코드 검토 프로세스를 안내하고 풀 요청을 병합하는 주요 메커니즘입니다. 69 | - 프로젝트에서 실행되는 서비스에 대해 결정하고 프로젝트 및 커뮤니티의 이익을 위해 해당 서비스를 관리합니다. 70 | - 정기적 인 커뮤니티 토론으로 합리적인 시간 내에 문제에 대한 합의가 이루어지지 않을 때 결정하십시오. 71 | 72 | #### 위원회 회원 73 | 74 | 운영 협의회 회원 자격을 얻으려면 개인이 품질과 수량이 상당하고 1년 이상 지속되는 기여를 한 프로젝트 기고자 여야합니다. 75 | 잠재적 협의회 회원은 기존 협의회 회원이 지명하고 기존 협의회에서 투표합니다. 76 | 성공적인 투표를 바탕으로, 새로 선출 된 회원은 그 자격으로 봉사하도록 초대됩니다. 77 | 위원회는 2014년 말 기준으로 작년에 크게 활동 한 기존 핵심 개발자들로 구성되었습니다. 78 | 이사회는 잠재적 인 회원을 고려할 때 자신의 기여에 대한 포괄적 인 견해를 가진 후보자를 검토 할 것입니다. 79 | 여기에는 코드, 코드 검토, 인프라 작업, 메일 링리스트 및 채팅 참여, 커뮤니티 지원 / 빌딩, 교육 및 봉사 활동, 디자인 작업 등이 포함됩니다. 80 | 우리는 의도적으로 프로젝트의 전체적인 복지보다는 메트릭에 영향을 미치는 행동을 장려하지 않기 위해 임의의 정량적 메트릭 81 | (예 :“이 레포에서 100 커밋”)을 설정하지 않습니다. 82 | 우리는 팀의 다양한 배경, 견해 및 재능을 장려하고자하므로,위원회 회원 자격을 평가할 유일한 척도로 코드를 명시 적으로 정의하지 않습니다. 83 | 협의회 구성원이 1년 동안 프로젝트에서 활동하지 않으면, 협의회의 해임으로 간주됩니다. 84 | 제거하기 전에 <<개발조직>>은 비 활동 회원에게 접근하여 활동에 복귀 할 계획인지 확인합니다. 85 | 그렇지 않은 경우,위원회 투표시 즉시 제거됩니다. 86 | 그들이 곧 적극적인 참여로 돌아갈 계획이라면 1년의 유예 기간이 주어질 것입니다. 87 | 해당 기간 내에 적극적으로 참여하지 않으면 추가 유예 기간없이 이사회의 투표에 의해 제거됩니다. 88 | 다른 모든 프로젝트 기고자와 마찬가지로 향후 모든 시의회 의원은 언제라도 다시 멤버십을 고려할 수 있습니다. 89 | 은퇴 한 협의회 구성원은 협의회에서 활동 한 기간을 인정하여 프로젝트 웹 사이트에 표시됩니다. 90 | 이사회는 프로젝트의 복지에 적극적으로 해가되고 의사 소통 및 분쟁 해결 시도가 실패한 경우 <<개발조직>> 이외의 현 회원을 퇴출시킬 권리를 보유합니다. 91 | 92 | #### 이해의 상충 93 | 94 | <<개발조직>> 및 자문위원은 다양한 회사, 대학 및 비영리 단체에서 고용 될 것으로 예상됩니다. 95 | 이로 인해 회원은 이해의 충돌을 겪을 수 있습니다. 96 | 이러한 이해 상충에는 다음이 포함되지만 이에 국한되지는 않습니다. 97 | 98 | - 프로젝트 외부에서 프로젝트에 대한 업무에 영향을 줄 수있는 프로젝트 외부의 투자, 고용 또는 계약 업무와 같은 재정적 이해. 99 | - 프로젝트 작업에 잠재적으로 유출 될 수있는 고용주의 독점 정보에 액세스합니다. 100 | - 개인이 프로젝트 자원으로부터 개인적으로 이점을 얻지 만 프로젝트에 이익이 없거나 단점이있는 문제. 101 | 102 | <<개발조직>>을 포함한 이사회의 모든 구성원은 그들이 가질 수있는 모든 이해 상충을 이사회 나머지에 공개해야한다. 103 | 특정 문제에 대해 이해 상충이있는 회원은 해당 문제에 대한 협의회의 토론에 참여할 수 있지만 해당 문제에 대한 투표는 거부해야합니다. 104 | <<개발조직>>이 특정 결정에 대해 자신을 취소 한 경우 해당 결정에 대한 대체 <<개발조직>>을 지정합니다. 105 | 106 | #### 위원회의 개인 커뮤니케이션 107 | 108 | 특별히 요구되지 않는 한, 모든 협의회 토론 및 활동은 공개되며 프로젝트 기고자 및 커뮤니티와의 공동 작업 및 토론으로 수행됩니다. 109 | 시의회는 개인 사안 목록을 가지고 있으며 이는 특정 사안이 개인 정보 보호를 필요로 할 때만 사용됩니다. 110 | 개인 커뮤니케이션 및 의사 결정이 필요한 경우,위원회는 공개 인터넷에 게시해서는 안되는 개인 / 개인 / 민감한 정보를 얻은 후이를 커뮤니티에 요약하기 위해 최선을 다할 것입니다. 111 | 112 | #### 소위원회 113 | 위원회는 프로젝트의 특정 측면에 대한 리더십과 지침을 제공하는 소위원회를 만들 수 있습니다. 114 | 위원회 전체와 마찬가지로 소위원회는 프라이버시가 특별히 요구되지 않는 한 공개적이고 공개적인 방식으로 업무를 수행해야합니다. 115 | 개인 소위원회 커뮤니케이션은 특별히 요청하지 않는 한위원회의 주요 개인 메일 링리스트에서 이루어져야합니다. 116 | 질문 : <<개발조직>>이 소위원회에 있지 않은 경우에도 여전히 재정의 권한이 있습니까? 117 | 118 | 제안 : 그들은하고 있지만, 대부분 그 역할을 담당하는 대표를 임명해야하며,위원회가 해당 대표자의 결정에 동의하지 않고 팀 내에서 결의가 불가능한 경우에만 명시적인 <<개발조직>> 개입이 요구됩니다. 119 | 이는 <<개발조직>>이 문자 그대로 다른 사람에게 자신의 권한을 완전히 포기하는 특정 결정 (또는 recusal 상황)에 대한 <<개발조직>> 대리인과 다릅니다. 120 | Linus Torvalds가 그의“거짓말”모델과 함께 사용하는 것과 비슷합니다. 121 | 122 | 123 | ## 기관 파트너 및 자금 124 | 125 | 운영위원회는 이 프로젝트의 주요 리더십입니다. 126 | 외부 기관, 개인 또는 법인은 기고자 및 협의회 회원으로 프로젝트에 참여하는 것 이외의 다른 프로젝트를 소유, 통제, 소집 또는 영향력을 행사할 수있는 능력이 없습니다. 127 | 그러나 기관이 프로젝트의 주요 자금 조달 메커니즘이기 때문에 프로젝트에 기관의 참여를 공식적으로 인정하는 것이 중요합니다. 128 | 이들은 기관 파트너입니다. 129 | 기관 기고자 (Institutional Contributor)는 기관 파트너의 공식 업무의 일부로 프로젝트에 기여하는 개별 프로젝트 기고자입니다. 130 | 마찬가지로, 기관 협의회 회원은 기관 파트너의 공식 업무의 일부로 프로젝트에 기여하는 모든 프로젝트 운영 협의회 회원입니다. 131 | 이러한 정의에 따라 기관 파트너는 미국 또는 다른 기관에서 하나 이상의 기관 기고자 또는 기관 협의회 회원을 고용하는 것으로 알려진 공인 법인입니다. 132 | 기관 파트너는 영리 또는 비영리 단체 일 수 있습니다. 133 | 기관은 공식 업무의 일환으로 프로젝트에 적극적으로 기여하는 개인을 고용함으로써 기관 파트너가 될 수 있습니다. 134 | 다른 방법으로, 기관 파트너가 프로젝트에 영향을 줄 수있는 유일한 방법은 다른 기여자 및 평의회 구성원 커뮤니티와 동등한 조건으로 프로젝트의 열린 개발에 적극적으로 기여하는 것입니다. 135 | 기관 적 맥락에서 HANU 소프트웨어 또는 서비스를 사용한다고해서 기업이 기관 파트너가 될 수는 없습니다. 136 | 금융 선물은 기업이 기관 파트너가 될 수 없습니다. 137 | 기관이 기관 파트너십 자격이되면 운영위원회는 파트너십을 지명하고 승인해야합니다. 138 | 기존 기관 파트너에 더 이상 기고 직원이없는 경우 다른 직원이 기고하기 위해 1년의 유예 기간이 부여됩니다. 139 | 기관 파트너는 법적 수단을 통해 프로젝트 작업에 대한 자금을 자유롭게 추구 할 수 있습니다. 140 | 여기에는 민간 재단과 기부자로부터 돈을 모으는 비영리 단체 또는 프로젝트 소프트웨어 및 서비스를 활용하는 독점 제품 및 서비스를 구축하는 영리 회사가 포함될 수 있습니다. 141 | 기관 파트너가 프로젝트를 수행하기 위해 취득한 자금을 기관 자금이라고합니다. 142 | 그러나 기관 파트너가 얻은 자금은 프로젝트 <<개발조직>> 및 운영위원회를 재정의 할 수 없습니다. 143 | 파트너가 HANU 작업을 수행 할 자금을 보유하고 있고위원회가 해당 작업을 프로젝트로 추구하지 않기로 결정한 경우 파트너는 자유롭게 프로젝트를 추구 할 수 있습니다. 144 | 그러나이 상황에서 파트너 작업의 해당 부분은 HANU 우산 아래에 있지 않으며 공식적인 관계를 나타내는 방식으로 프로젝트 상표를 사용할 수 없습니다. 145 | 기관의 기여를 인정하기 위해 다음과 같은 두 가지 수준의 기관 파트너가 있습니다. 146 | 147 | ** 계층 1 ** = 하나 이상의 기관 협의회 회원이있는 기관 148 | 149 | - HANU 웹 사이트에서 대화 및 티셔츠로 인정 받았습니다. 150 | - HANU 웹 사이트, 대화 및 티셔츠를 통해 자체 자금 출처를 확인할 수 있습니다. 151 | - (계획된) 연간 HANU Project Retreat에서 개최되는 연례 기관 파트너 워크샵에 무제한 참여. 152 | 이를 통해 기관 파트너는 프로젝트 기고자 또는 협의회 회원이 아니더라도 원하는만큼 많은 직원과 자금 출처 및 협력자를 초대 할 수 있습니다. 153 | - 자문위원의 참여를 통해 프로젝트에 영향을 미치는 능력. 154 | - 2년에 걸친 HANU 개발자 회의에 협의회 회원을 초대합니다. 155 | 156 | ** 계층 2 ** = 하나 이상의 기관 기고자가있는 기관 157 | 158 | - 1단계 파트너와 동일한 혜택이지만 다음과 같은 이점이 있습니다. 159 | - 기관 참여자 만 기관 파트너 워크샵 및 2년마다 HANU 개발자 미팅에 초대됩니다. 160 | 161 | 162 | ## 거버넌스 문서 변경 163 | 164 | 거버넌스 문서에 대한 변경 사항은 GitHub 풀 요청을 통해 [https://github.com/openinfradev/community-draft](https://github.com/openinfradev/community-draft)의 프로젝트 거버넌스 문서 GitHub 저장소에 제출됩니다. 165 | 풀 요청은 대중의 의견과 검토에 따라 지역 사회에서 합의 된 목표와 함께 수정됩니다. 166 | 이 공개 기간이 지나면 Steering Council 멤버는 Steering Council에 변경 사항을 비준하고 풀 요청을 병합 (제안 된 변경 사항을 수락 함)하거나 풀 요청을 병합하지 않고 닫을 것을 제안합니다 (제안 된 변경 사항 거부). 167 | 회원은 수락 또는 거부를 위해 제안 된 풀 요청에 최종 커밋 해시를 명시하고 풀 요청을 간략하게 요약해야합니다. 168 | 모든 투표는 투표 시작 후 4 주로 제한됩니다. 169 | 4 주가 지나면 투표의 2/3가 찬성 인 경우 (가장 가까운 정수로 반올림 된 투표의 비율) 제안이 통과됩니다. 그렇지 않으면 제안이 거부되고 PR이 마감됩니다. 170 | 4 주제 한 이전에, 운영위원회의 80% 이상이 투표하고 2/3 표가 찬성하면 (가장 가까운 정수로 반올림 된 투표의 비율) 제안이 통과됩니다. 171 | <<개발조직>>은 프로젝트에서 궁극적 인 권한을 가지므로 <<개발조직>>은 변경을 수락 또는 거부하거나 운영위원회 결정을 무시할 때 단독으로 행동 할 권한이 있습니다. 172 | -------------------------------------------------------------------------------- /__archive/jupyter-governance-based/newsubprojects_hanu.ko.md: -------------------------------------------------------------------------------- 1 | # 새로운 서브 프로젝트 프로세스 2 | 3 | Project HANU는 HANU 거버넌스, 라이센스 및 기여 모델을 따르는 개발 팀이있는 GitHub 저장소 인 하위 프로젝트 세트로 구성됩니다. 공식적으로 지원 및 유지 관리되는 하위 프로젝트는 다음 GitHub 조직에서 호스팅됩니다. 4 | 5 | * [github.com/hanu](https://github.com/hanu) 6 | * [github.com/hanuhub](https://github.com/hanuhub) 7 | * [github.com/hanulab](https://github.com/hanulab) 8 | * [github.com/hanu-resources](https://github.com/hanu-resources) 9 | * [github.com/hanu-widgets](https://github.com/hanu-widgets) 10 | * [github.com/ipython](https://github.com/ipython) 11 | 12 | 이 문서는 새로운 하위 프로젝트가 다른 위치에서 이들 조직으로 생성되거나이 조직으로 이동되는 프로세스를 설명합니다. 새로운 서브 프로젝트를 생성하는 방법은 두 가지가 있습니다 : 13 | 14 | 1. [직접 서브 프로젝트 생성] 15 | * 예를 들어, 기존 서브 프로젝트에 기고자가 관련이 있지만 분리 가능한 코드를위한 새로운 Git 리포지토리를 생성하기로 결정한 경우 16 | 2. [기존 외부 서브 프로젝트의 통합] 17 | * 예를 들어, github.com/hanu-incubator의 프로젝트에 참여한 사람이 공식 HANU 조직 중 하나로 통합 제안서를 제출하고 운영위원회의 승인을받는 경우 18 | * 예를 들어, 제 3 자 프로젝트에 참여한 사람이 통합 제안서를 제출하고 운영위원회의 승인을받는 경우 19 | 20 | github.com/hanu-incubator의 프로젝트는 아래의 기준을 충족하고이 문서의 뒷부분에 설명 된 통합 프로세스를 거치기 전까지 공식적으로 지원되고 유지 관리되는 하위 프로젝트로 간주되지 않습니다. 21 | 22 | 공식 하위 프로젝트의 기준 23 | 24 | 하위 프로젝트를 평가하여 공식 HANU 조직 중 하나에 통합하는 데 다음 기준이 사용됩니다. 서브 프로젝트를 개발하는 사람에 관계없이 서브 프로젝트에 적용됩니다. 하위 프로젝트는 다음을 수행해야합니다. 25 | 26 | * 향후 개발을위한 지속 가능한 모델을 제공하는 적극적인 개발자 커뮤니티를 보유하십시오. 27 | * 활발한 사용자 커뮤니티가 있습니다. 28 | * 적절한 기술로 호스팅 된 문서 및 테스트와 함께 견고한 소프트웨어 엔지니어링을 사용하십시오 (문서 및 Travis 읽기는 사용할 수있는 기술의 예입니다). 29 | * 지속적인 성장과 발전을 보여줍니다. 30 | * 다른 공식 하위 프로젝트와 잘 통합하십시오. 31 | * 여기에 설명 된 HANU 거버넌스 및 기여 모델에 따라 개발하십시오. 32 | * 범위가 잘 정의되어 있어야합니다. 33 | * pip, conda, npm, bower, docker 등과 같은 적절한 기술을 사용하여 포장하십시오. 34 | * 일반적인 지침으로, 우리는 프로젝트에 경쟁하는 서브 프로젝트를 통합하는 것보다 기존 서브 프로젝트의 개선을 지원합니다. 35 | 36 | 하위 프로젝트를 공식 하위 프로젝트로 평가할 때 가장 중요한 질문은 다음과 같습니다. 커뮤니티와 운영위원회에서 하위 프로젝트를 공식적으로 개발하고 유지하기로 합의 하는가? 37 | 38 | 공식적인 서브 프로젝트 생성을위한 두 가지 경로가 이제 상세합니다. 39 | 40 | 41 | ## 다이렉트 서브 프로젝트 생성 42 | 43 | 44 | 45 | ## 기존 외부 하위 프로젝트의 통합 46 | 47 | 다른 경우, 통합을 위해 제안 된 서브 프로젝트는 공식 HANU 조직 외부에서 한동안 오픈 소스 소프트웨어로 존재하고 개발되었을 것입니다. 이 섹션에서는 이러한 기존 외부 하위 프로젝트의 통합 프로세스에 대해 설명합니다. 이 프로세스는 hanu-incubator GitHub 조직 (아래 참조)에서 인큐베이션 된 하위 프로젝트, 다른 GitHub 조직에서 개발 된 하위 프로젝트 또는 다른 공공 장소에서 오픈 소스 소프트웨어로 개발 된 하위 프로젝트에 적용됩니다. 48 | 49 | 50 | 51 | ### 법인 설립 52 | 53 | 기존의 외부 서브 프로젝트를 주요 HANU 조직 중 하나에 통합하려면 다음 제안 프로세스가 사용됩니다. 54 | 55 | 1. 서브 프로젝트 팀은 HANU / enhancement-proposals 저장소에 대해 주요 HANU 조직 중 하나에 서브 프로젝트를 포함시키기위한 개선 제안과 함께 풀 요청을 제출해야합니다. 개선 제안은 하위 프로젝트가 위의 각 기준을 어떻게 충족시키는 지 설명해야합니다. 56 | 2. 통합 제안은 해당 풀 요청을 사용하여 커뮤니티에서 논의됩니다. 57 | 3. 운영 협의회 (SC)의 합의에 의해 추천이 이루어집니다. 58 | 59 | **타임 라인 :** SC는 신속하게 결정을 내릴 수 있도록 모든 노력을 기울여야합니다. 제안서에 대한 활발한 토론과 의견이 있다면 계속 진행해야하며 목소리가 들립니다. 그러나 모든 사람이 투표하기를 기다리는 불필요한 지연을 피하려면 다음 지침을 사용해야합니다. 60 | 61 | * 제안에 따라 잠재적 이의 제기를 위해 일주일을 허용하십시오 (물론 명시 적 동의는 물론). 이의가 없으면 침묵을 동의로 취급하십시오. 62 | 63 | * 한 달이 지났는데도 계속해서 활발한 의견 차이가있을 경우 프로젝트가 졸업 준비가되지 않았다는 강력한 신호로 취급되어야합니다 (필요한 경우 BDFL 선언은 여전히 ​​수락 요청을하는 데 사용될 수 있습니다). 64 | 65 | 운영위원회의 가능한 권장 사항은 다음과 같습니다. 66 | 67 | * 기존 공식 Suproject에 통합. 68 | * 새로운 공식 하위 프로젝트로 통합. 69 | * 향후 내부 통합을 준비하기 위해 팀이 취할 수있는 단계에 대한 권장 사항과 함께 추가 내부 또는 외부 인큐베이션 (아래 참조). 70 | 71 | 72 | ### 법인 73 | 74 | 기존 외부 서브 프로젝트가 새로운 공식 서브 프로젝트로 통합되면 다음 단계가 수행됩니다. 75 | 76 | 1. 저장소는 HANU GitHub 주요 조직 중 하나로 이전됩니다. 77 | 2. 하위 프로젝트 팀에 하위 프로젝트 저장소에 대한 읽기 / 쓰기 권한이있는 하위 프로젝트에 대한 GitHub 팀이 생성됩니다. 78 | 3. 팀은 새로운 하위 프로젝트에 대한 공지와 함께 주피터 목록으로 이메일을 보냅니다. 79 | 4.이 통제 저장소에서 유지 보수되는 표준 Project HANU LICENSE 파일이 저장소에 추가됩니다. 80 | 5. 개별 파일의 저작권 고지는 Project HANU 라이센스에 설명 된 표준 형식으로 업데이트해야합니다. 81 | 82 | 83 | ## 서브 프로젝트의 인큐베이션 84 | 85 | 인큐베이션은 초기 HANU 공식 조직 외부에서 개발중인 하위 프로젝트 프로세스를 말합니다. 인큐베이션은 다음과 같은 특성을 가진 새로운 하위 프로젝트에 권장됩니다. 86 | 87 | * 탐구가 필요한 중요한 답이없는 기술적 질문 또는 불확실성. 88 | * 커뮤니티와 관련이없는 완전히 새로운 방향, 범위 또는 아이디어. 89 | 서브 프로젝트가 나머지 HANU와 어떻게 통합되는지 명확하지 않은 중요한 기존 코드 기반. 90 | 인큐베이션은 또한 더 넓은 커뮤니티가 주요 GitHub 조직의 안정적이고 공식적으로 지원 및 유지 관리되는 서브 프로젝트와 향후 포함을 위해 새롭게 개발되고있는 새로운 노력을 쉽게 구분할 수 있도록합니다. 91 | 92 | 부화가 특정 하위 프로젝트에 적합한 지에 대한 질문이있는 경우 관심있는 당사자는 주피터 목록에 대한 토론을 시작하여 커뮤니티 및 운영위원회 의견을 수렴해야합니다. 93 | 94 | 95 | 96 | ### [hanu-incubator] (https://github.com/hanu-incubator) 조직에서의 인큐베이션 97 | 98 | 99 | 주피터 인큐베이터 조직에서 인큐베이션의 목표는 다음과 같습니다. 100 | 101 | 기고자는 개인 및 조직의 기고 제한을 준수하면서 코드를 HANU 커뮤니티에 빠르고 쉽게 노출시킬 수 있습니다. 102 | * 기고자는 커뮤니티 및 운영위원회와 협력하여 피드백을 조기에 수집하여 명확하고 간결한 통합 제안을 개발하고 개선하는 데 도움이 될 수 있습니다. 103 | * 커뮤니티가 공식적으로 지원되는 서브 프로젝트와 커뮤니티 회원이 추구하는 실험적인 서브 프로젝트를 구별 할 수 있도록합니다. 104 | 105 | 106 | 인큐베이터 프로젝트를위한 리포지토리 관리 정책 107 | 108 | 프로젝트는 때때로 다양한 아이디어를 탐구하기 위해 새로운 저장소를 생성하기를 원할 수 있습니다. 이에 대한 기본 정책은 다음과 같습니다. 109 | 110 | * 프로젝트 이름이 foo 인 경우 추가 인증을 요구하지 않고 foo-X라는 이름의 새 리포지토리를 만들 수 있습니다. 이 프로젝트는 더 넓은 HANU 채널에 대한 레포를 발표할지 여부가 충분한 관심이 있다고 생각하는지 여부를 결정할 수 있습니다 (분명히 이러한 레포지토리는 모두 공개되어 참여할 수 있습니다). 111 | 112 | * 프로젝트가 bar라는 이름의 repo (다른 사람이 관심을 가질 수있는 최상위 이름)를 만들려면 주피터 목록에 게시해야합니다. 이 제안은 누군가가 심각한 이의를 제기하지 않는 한 이러한 요청은 가능한 한 신속하게 승인 될 것이라는 가정하에 논의 될 것입니다. 113 | 114 | 인큐베이션을위한 제안 115 | 116 | 하위 프로젝트 팀은 인큐베이션 제안서를 제출하여 주피터 인큐베이터 인큐베이션 프로세스를 시작할 수 있습니다. 이 프로세스는 가볍고 빠르게 설계되었습니다. 117 | 118 | 1. 제안자는 주피터 인큐베이터 / 제안서에 풀 요청을 제출하여 인큐베이션 신청서를 작성해야합니다. 119 | 2. 제안자는 주피터 메일 링리스트에 게시하여 커뮤니티에 자신의 의도를 발표해야합니다. 120 | 3. 제안 된 하위 프로젝트에는 운영 운영 협의회 회원 인 옹호자가 있어야합니다. 지지자의 역할은 하위 프로젝트 팀을 HANU 커뮤니티에 소개하고 인큐베이션 프로세스를 통해 그들을 돕는 것입니다. 옹호자가 서브 프로젝트의 실제 개발 및 설계에 관여 할 수 있지만 반드시 그럴 필요는 없습니다. 121 | 4. 부화 제안은 지역 사회가 논의하고 운영위원회의 합의에 의해 승인 또는 거부 될 것이다. 122 | 5. 승인되면 제안서 풀 요청이 병합되고 거부되면 요청이 마감됩니다. 123 | 124 | ### 인큐베이션 기간 125 | 126 | 주피터 인큐베이터 조직에서 하위 프로젝트의 인큐베이션이 승인되면 다음 단계가 수행됩니다. 127 | 128 | 1. GitHub 리포지토리는 hanu-incubator 조직에 생성됩니다 129 | 2. GitHub 팀은 Advocate를 포함하여 리포지토리에 대한 읽기 / 쓰기 액세스 권한으로 생성됩니다. 130 | 3.이 통제 저장소에서 유지 보수되는 표준 HANU LICENSE 파일이 새 저장소에 추가됩니다. 131 | 4. 운영 협의회 회원이 새로 Jucubter 목록에 부화 한 하위 프로젝트를 발표 할 것입니다. 132 | 133 | 잠복기의 목표는 서브 프로젝트가 활발한 개발자 및 사용자 커뮤니티를 개발할 것임을 입증하는 것입니다. 인큐베이션에 필요한 특정 시간은 없지만 대부분의 하위 프로젝트는 최소 6 개월에서 1 년 동안 인큐베이션 될 것으로 예상됩니다. 134 | 135 | 136 | ## 외부 인큐베이션 137 | 138 | 주피터 인큐베이터 조직 외부에서 인큐베이션도 가능합니다. 이 경우 공식적인 프로세스는 없습니다. 모든 개인 또는 조직은 자신의 개인 GitHub (또는 다른 VCS) 저장소에서 새 프로젝트를 작성하고 자신이 원하는대로 개발할 수 있습니다. 외부에서 생성되고 인큐베이션 된 하위 프로젝트가 공식 HANU 조직의 일부가 되려면이 문서의 맨 위에 나열된 기준을 충족해야하며 동일한 통합 프로세스를 따라야합니다. 139 | -------------------------------------------------------------------------------- /__archive/jupyter-governance-based/papers_hanu.ko.md: -------------------------------------------------------------------------------- 1 | # HANU 관련 학술 논문 작성 절차 2 | 3 | 이 문서는 HANU 관련 학술 논문을 작성하는 데 사용되는 프로세스를 설명하며 일반적으로 동료 검토 저널에 제출됩니다. 회의가 서면 절차를 게시하지 않는 한 회의에 제출 된 대화 및 포스터는 포함되지 않습니다. 4 | 5 | 한편으로 HANU Project의 주요 초점은 오픈 소스 소프트웨어 제작에 있습니다. 우리는 사용자를 즐겁게하는 코드 작성에 매우 중점을두고 있습니다. 반면에 HANU (및 IPython)는 연구 및 동료 간행물이 주요 초점이되는 학계 환경에서 나왔습니다. 오늘날까지 많은 핵심 기고자들은 학업 및 활동적인 연구 프로그램을 가지고 있습니다. 이 강조는 또한 모든 과학 연구 분야에서 HANU의 사용에 반영됩니다. 따라서 HANU는 사용자를위한 소프트웨어 작성에 중점을 두었음에도 불구하고 연구원이 사용할 수있는 도구로 남아 있습니다. 6 | 7 | 연구, 많은 HANU 기고자들의 지속적인 학업 경력 및 컴퓨팅 연구에 영향을 미치기를 원한다는 점을 감안할 때 HANU 자체에 대해 동료 검토 논문을 작성하고 게시하는 것이 중요합니다. 대규모 오픈 소스 커뮤니티에서 이러한 논문을 작성하면 많은 연구 협력과 비교하여 많은 차이점이 있습니다. 8 | 9 | ## 원칙 10 | 우리는 다음과 같은 일반적인 원칙을 염두에두고 논문을 작성하는 프로세스를 만들려고 노력했습니다. 11 | 12 | **Inclusivity and generosity in authorship.** 수백 명의 개인이 다른 HANU 하위 프로젝트에 기여했습니다. 이러한 기여는 코드, 디자인, 문서화, 토론, 대화 / 자습서 제공 등을 포함합니다. 우리는 가능한 한 많은 기여자에게 저작자 권한과 책임을 넓히고 자합니다. 13 | **Clear, explicit criteria for authorship.** 관대하면서도 개인을 저자로 포함시키기위한 구체적이고 구체적이며 감사 가능한 기준이 필요합니다. 14 | *Openness.** 논문 작성 과정은 나머지 프로젝트 작업과 같은 방식으로 열려 있어야합니다. 따라서 우리의 모든 논문은 GitHub에 공개적으로 작성되었습니다. 15 | **Accountability.** 논문의 저자가되는 것은 특권이지만 책임도 포함됩니다. 아래에 설명 된 구체적인 프로세스는 이러한 책임을 설명합니다. 16 | 17 | 우리는 다른 유형의 저널에 논문을 작성하고 제출할 것으로 기대합니다. 각기 다른 저널에는 이러한 원칙을 적절히 구현하는 약간 다른 구체적인 프로세스가 있습니다. 18 | 19 | ## Author ordering 20 | 일부 학문 분야에서 저자 순서는 개인의 기여 수준과 중요성을 암시 적으로 전달하는 데 사용됩니다. 우리는 이것이 오도되고 잘못 인도되었다고 강하게 느낍니다. 이로 인해 모든 HANU 논문은 다음 저자 주문 정책을 사용합니다. 21 | 22 | * 첫 번째 저자는 "HANU Project"로 표시됩니다. 23 | * 개별 저자는 알파벳 순서로 따라갑니다. 과 24 | * 주문에 대한 명시 적 진술이 논문에 포함됩니다. 25 | 26 | 첫 번째 저자를 "HANU Project"로 나열하는 것은 약어 인용에서 저자 목록이 "HANU Project 등"이라는 의미이므로 중요합니다. 알파벳순으로 저자의 이름을 인위적으로 보여주기보다는 이것은 논문에 다수의 저자가있는 고 에너지 물리학과 같은 학문 분야에서 일반적인 관행입니다. 27 | 28 | ## JOSS (Open Source Software) 저널 프로세스 29 | JOSS (Journal of Open Source Software)는 연구 관련 소프트웨어에 대해 동료가 검토하고 개발자에게 친숙한 저널입니다. JOSS는 다음과 같은 점에서 독특합니다. 30 | 31 | 각 논문은 단일 GitHub 저장소와 연관되어 있습니다. 32 | 소프트웨어 자체의 주요 연구 인공물. 과 33 | 이 문서 자체는 소프트웨어의 GitHub 리포지토리에있는 비교적 간단한 마크 다운 파일로 소프트웨어의 세부 정보를 자체 문서로 연기합니다. 34 | 우리는 사용자 중심의 주요 하위 프로젝트 (노트북, HANULab, HANUHub, nbconvert, ipywidgets 등) 각각에 대해 JOSS 논문을 발행하고자합니다. 이러한 모든 문서는 여기에 설명 된 프로세스를 사용해야합니다. 35 | 36 | ### JOSS 저작 기준 37 | 38 | JOSS 논문에 대한 우리의 저작권 기준은 ICMJE의 기준에서 비롯됩니다. 39 | 40 | * 소프트웨어의 개념, 설계 또는 구현에 실질적인 기여; 여기에는 코딩, 시각 디자인, 문서, 테스트, 토론 및 기타 기여가 포함됩니다. 과 41 | * 출판 될 버전의 최종 승인; 과 42 | * 작업의 모든 부분의 정확성 또는 무결성과 관련된 질문이 적절하게 조사되고 해결 될 수 있도록 작업의 모든 측면에 대해 책임을 져야합니다. 43 | 44 | 이러한 책임과 약속을 충족시키고 기꺼이 받아들이려는 사람은 누구나 JOSS 간행물의 저자가 될 수 있습니다. 45 | 46 | ### JOSS 프로세스 47 | 48 | HANU 관련 JOSS 논문을 작성하려면 다음 프로세스를 사용해야합니다. 49 | 50 | #### 1. Someone agrees to be the Coordinator for a paper 51 | 52 | 단일 JOSS 용지는 단일 HANU 리포지토리와 연결됩니다. 코디네이터는 일반적으로 선임 프로젝트 기고자, 운영 협의회 멤버 또는 해당 하위 프로젝트의 리더가됩니다. 53 | 54 | 코디네이터의 역할은 해당 논문에 대해이 프로세스를 구현하는 것입니다. JOSS 논문을 직접 작성할 필요는 없지만, 논문 작성을 조직하기 위해 커뮤니티와 협력 할 것입니다. 55 | 56 | #### 2. Open an issue and announce the writing of the paper 57 | 58 | 코디네이터는 해당 저장소에 대한 논문 작성을 구성하기 위해 이슈를 연 다음, 논문이 진행 중이며 누구나 이슈에 대한 링크를 통해 기여할 수 있음을 HANU Google 그룹에 발표해야합니다. 59 | 60 | #### 3. Draft the paper in the repository 61 | 62 | 이 시점에서 코디네이터는 실제 논문을 작성해야합니다. 63 | 64 | JOSS Author Guidelines는 JOSS 논문의 형식과 요구 사항을 자세히 설명합니다. 일반적으로 이것은 저장소의 루트에 paper.md 및 paper.bib라는 두 개의 파일을 가진 paper 서브 디렉토리를 작성하는 것을 포함합니다. 풀 요청 및 코드 검토를 위해 표준 프로세스를 사용하여 논문을 작성해야합니다. 65 | 66 | #### 3. Email potential authors 67 | 68 | 논문의 최종 초안이 저장소에 병합되면 코디네이터는 논문의 모든 잠재적 저자에게 이메일을 보내 참여하도록 초대해야합니다. 일반적으로 여기에는 두 개 이상의 이메일이 포함됩니다. 69 | 70 | * 리포지토리의 Git 로그에 나열된 모든 기고자를 개별적으로 이메일로 보냅니다. 이 목록은 Git 명령 `git log --all --format='%cN 71 | <%cE>' | sort -u`. 72 | * 주피터 Google 그룹에 이메일을 보내 Git 로그에없는 사람들을 포함시킵니다. 73 | 74 | 또한 코디네이터는 학술 출판물을 처음 접하는 학생들, 우리가 논문을 쓰는 이유를 설명하고 참여하도록 격려하는 학생과 같은 개인에게 개인 이메일을 보내야합니다. 이러한 개인 이메일은 해당되는 경우 개인의 멘토 또는 조언자를 참조해야합니다. 75 | 76 | 이 두 이메일 모두 다음을 포함해야합니다. 77 | 78 | * 상기 JOSS 저작 기준의 완전 사본; 79 | * 논문의 저자가되기 위해 각 개인이 완료해야하는 작업에 대한 설명; 80 | * 해당 작업을 완료하기위한 구체적인 마감일 (최소 2주)과 81 | * 저장소에있는 Paper의 마크 다운 파일에 대한 링크. 82 | 83 | 각 개인이 완료해야하는 작업은 다음과 같습니다. 84 | 85 | * ORCID에 계정을 만드십시오. 86 | * 서류에 이름, ORCID id 및 소속을 추가하여 PR을 저장소에 제출하십시오. 87 | * 논문 내용에 대한 수정 사항을 제공합니다. 88 | * PR의 의견에, 그들의 작업에 대한 그들의 기여를 간략하게 설명하십시오. 과 89 | * PR의 의견에, 그들이 논문을 읽었으며 출판에 동의한다는 확인을 제공하십시오. 90 | 91 | 마감일이 다가 오면 코디네이터는 잠재적 인 저자에게 작업을 완료하도록 상기시켜야합니다. 92 | 93 | #### 4. Final submission 94 | 95 | 작성자가 과제를 완료해야하는 기한이 지났 으면 코디네이터는 저자가 알파벳 순서로 나열되도록해야합니다. 그런 다음 코디네이터는 논문을 제출할 수 있습니다. 96 | 97 | ### 전통적 학술 논문 처리 98 | 99 | 다른 (JOSS 이외의) 저널에 제출 된 논문은 일반적으로 더 길고 작성하는 데 더 많은 시간이 걸립니다. 또한 일반적으로 hanu-resources GitHub 조직의 전용 저장소에서 작성됩니다. 이러한 요인으로 인해 프로세스가 약간 다릅니다. 100 | 101 | ### 권한 기준 102 | 103 | 비 JOSS 논문의 저작자 기준은 모든 저자가 논문의 작성 및 편집에 적극적으로 참여해야한다는 점에서 JOSS와 약간 다릅니다. 104 | 105 | 논문에 대한 우리의 저자 기준은 ICMJE의 것에서 파생됩니다. 106 | 107 | * 소프트웨어의 개념, 설계 또는 구현에 실질적인 기여; 여기에는 코딩, 시각 디자인, 문서, 테스트, 토론 및 기타 기여가 포함됩니다. 과 108 | * 중요한 지적 내용을 위해 작품을 작성하거나 비판적으로 수정; 과 109 | * 출판 될 버전의 최종 승인; 과 110 | * 작업의 모든 부분의 정확성 또는 무결성과 관련된 질문이 적절하게 조사되고 해결 될 수 있도록 작업의 모든 측면에 대해 책임을 져야합니다. 111 | 112 | 이러한 책임과 약속을 충족시키고 기꺼이 받아들이려는 사람은 누구나 당사의 간행물에 대한 저자가 될 수 있습니다. 113 | 114 | 이 두 번째 책임은 모든 저자가 원고 작성에 적극적으로 참여한다는 것을 의미합니다. 우리는 모든 공동 저자가 논문 작성에 똑같이 그리고 같은 방식으로 기여하지는 않는다는 것을 알고 있습니다. 또한 다수의 공동 저자가있는 논문의 경우, 주요 공동 작성은 소규모 공동 저자 그룹이 수행하고 다른 공동 저자는 편집 작업 및 토론에 기여할 것으로 예상합니다. 그러나 모든 경우에 어떤 방식 으로든 적극적인 참여가 여전히 요구됩니다. 115 | 116 | ### 프로세스 117 | 118 | 비 JOSS 용지를 작성하기위한 자세한 프로세스를 작성하기 전에 위의 JOSS 용지 프로세스를 시도하고 더 긴 양식 용지를 위해이를 수정하는 방법을 확인하려고합니다. 일반적으로, 우리는이 논문을 작성하기 위해 SymPy 프로젝트에서 사용 된 프로세스를 면밀히 따를 것으로 기대합니다. 119 | -------------------------------------------------------------------------------- /__archive/jupyter-governance-based/people_hanu.ko.md: -------------------------------------------------------------------------------- 1 | # 운영 협의회 및 기관 파트너 2 | 3 | 이름 뒤에 GitHub 사용자 이름이옵니다. 4 | test 5 | ## 운영 협의회 6 | 7 | 이름순으로 알파벳순 : 8 | 9 | 10 | ### 퇴직 협의회 위원 11 | 12 | 13 | ### 소위원회 14 | 15 | 16 | ## 기관 파트너 17 | 18 | ### 1 단계 19 | 20 | 기관 협의회 구성원은 각 기관에 기록되어 있습니다. 21 | 22 | <<추가 필요>> 23 | 24 | 25 | ### 2 단계 26 | 27 | <<추가 필요>> 28 | 29 | ## 새로운 운영 협의회 회원 30 | 31 | 신입 회원이 운영 협의회에 가입하면 다음과 같은 일이 수행됩니다. 32 | - 메일 링리스트에 새 회원을 발표 33 | -새로운 멤버를 Github 조직의 조직 소유자로 만듭니다. 34 | -새 멤버를 통제 저장소의 목록에 추가하고 필요한 경우 기관 파트너 목록에 소속을 추가하십시오. 35 | -웹 사이트 에서 운영 협의회 회원 목록에 새 회원을 추가하십시오. 36 | -------------------------------------------------------------------------------- /__archive/jupyter-governance-based/projectlicense_hanu.ko.md: -------------------------------------------------------------------------------- 1 | # Licensing terms for Project HANU code 2 | 이 프로젝트는 다음과 같이 3-Clause BSD 라이센스 (New 또는 Revised 또는 Modified BSD 라이센스 또는 BSD-3-Clause 라이센스라고도 함)의 조건에 따라 라이센스가 부여됩니다. 3 | 4 | Copyright (c) YEAR Project HANU Contributors. 5 | All rights reserved. 6 | 7 | 다음 조건이 충족되는 경우 수정하거나 수정하지 않고 소스 및 이진 형식으로 재배포 및 사용할 수 있습니다. 8 | 9 | 1. 소스 코드의 재배포에는 위의 저작권 표시,이 조건 목록 및 다음 면책 사항이 유지되어야합니다. 10 | 2. 이진 형식으로 재배포 할 경우 위의 저작권 표시,이 조건 목록 및 배포와 함께 제공된 설명서 또는 기타 자료의 다음 고지 사항을 재현해야합니다. 11 | 3. 특정 사전 서면 허가없이 저작권 소유자의 이름이나 제공자의 이름을 사용하여이 소프트웨어에서 파생 된 제품을 보증하거나 홍보 할 수 없습니다. 12 | 이 소프트웨어는 저작권 소유자 및 배포자에 의해 "있는 그대로"제공되며, 명시 적 또는 묵시적 보증을 포함하되 이에 국한되지는 않지만 상품성 및 특정 목적에의 적합성에 대한 묵시적 보증은 이에 제한되지 않습니다. 어떠한 경우에도 저작권 소유자 또는 제공자는 직접적, 간접적, 우발적, 특수적, 간접적 또는 결과적 손해에 대해 책임을지지 않습니다 (대체 상품 또는 서비스의 제조, 데이터 손실, 사용 손실, 데이터 손실). 또는 사업 중단) 계약, 엄격 책임 또는 불법 행위 (어떠한 태만 또는 기타 포함)에 관계없이 본 소프트웨어를 사용하지 않더라도 본 소프트웨어를 사용하지 않더라도 발생하는 책임 이론에 의해 발생합니다. 13 | 14 | ## Explanation of Project HANU copyright policy 15 | 16 | 프로젝트 HANU는 공유 저작권 모델을 사용합니다. 각 기고자는 Project HANU에 대한 기고에 대한 저작권을 유지합니다. 이러한 기여는 일반적으로 리포지토리의 변경 사항입니다. 따라서 Project HANU 소스 코드는 전체적으로 한 사람이나 기관의 저작권이 아닙니다. 대신, Project HANU 소스 코드는 컨트 리뷰 터의 공동 저작권입니다. 개별 기고자가 특정 저작권이있는 변경 또는 기고에 대한 기록을 유지하려면 Project HANU 리포지토리 중 하나에 변경 사항을 적용 할 때 변경 내용을 커밋 메시지에 표시해야합니다. 17 | 18 | 19 | 이를 염두에두고 모든 소스 코드 파일에서 다음 배너를 사용하여 저작권 및 라이센스 조항을 표시해야합니다. 20 | 21 | # Copyright (c) Project HANU Contributors. 22 | # Distributed under the terms of the 3-Clause BSD License. 23 | -------------------------------------------------------------------------------- /__archive/jupyter-governance-based/trademarks_hanu.ko.md: -------------------------------------------------------------------------------- 1 | # 상표 사용 2 | 정책이 문서의 목적은 HANU 상표의 허용 된 사용을 명확히하는 것입니다. 3 | 커뮤니티가 상표를 자유롭게 사용하도록 권장하면서 상표를 법적으로 보호하는 매우 관대 한 정책을 구현하고자합니다. 4 | 5 | 일반적으로 : 6 | - HANU를 나타 내기 위해 HANU 이름 또는 HANU 로고를 사용하는 경우 일반적으로 허용되며 허가를 요청할 필요가 없습니다. 7 | 8 | 가장 일반적인 경우에 대한 자세한 내용은 [승인이 필요없는 용도]섹션을 참조하십시오. 9 | 추가 질문이 있다면 [HANU 상표위원회]에 문의하십시오. 10 | 11 | 12 | 13 | ## 소개 14 | 이 문서는 상표 사용에 관한 Project HANU ( "HANU")의 정책을 간략하게 설명합니다. 15 | Project HANU 상표를 사용하려면이 정책을 준수해야합니다. 16 | 17 | "HANU"는 HANU Project의 상표이며 HANU Project의 일부입니다. 18 | 19 | HANU 로고 (여러 변형)는 HANU Project의 상표입니다. 20 | 21 | "HANUDays", "HANULab", "HANUHub", "HANU Notebook"과 같은 HANU 프로젝트 또는 이벤트를 나타내는 파생 단어 표시도이 정책의 적용을받습니다. 22 | 23 | 오픈 소스 소프트웨어에 적용되는 모든 상표는 특정 법적 요구 사항에 따라 사용해야합니다. 24 | 이러한 요구 사항을 충족하지 않으면 상표가 위험에 처하거나 손실 될 수 있습니다. 25 | 이러한 요구 사항 중 하나는 상표 소유자 (이 경우 HANU Project)가 상표 사용에 대한 표준을 유지하고 해당 표준을 위반하는 당사자에 대해 조치를 취하여 상표의 허용 가능한 사용을 강제하는 것입니다. 26 | 27 | 상표법은 주로 상표권자보다는 대중을 보호하는 방법입니다. 28 | 즉, 소비자를 혼동하는 상표 사용은 법으로 허용되지 않습니다. 29 | 이 경우 "소비자"에는 개발자 및 사용자 커뮤니티 또는 HANU 서비스, 소프트웨어 또는 응용 프로그램을 사용할 가능성이있는 사람이 포함됩니다. 30 | 상표의 소유자로서 마크가 올바르게 사용되도록 커뮤니티가 혼동되지 않도록해야합니다. 31 | 그것이 우리가 폴리싱되지 않은 상표가 위험에 처하거나 잃어 버렸다고 말할 때 우리가 의미하는 것입니다. 32 | 상표가 더 이상 커뮤니티에 특정 수준의 품질을 나타내지 않거나 더 이상 상표가있는 제품의 출처임을 나타내지 않으면 해당 상표의 가치가 사라집니다. 33 | 34 | 기본 프로젝트 HANU의 상표 정책은 상표, 특히 "HANU"라는 단어 마크, HANU 로고 및 해당 마크의 변형 사용에 대한 가이드 라인입니다. 35 | 이 정책은 HANU 및 HANU Project가 상표에 대해 일반적으로 승인 한 용도를 설명합니다. 36 | 그러나이 정책을 위반하거나 HANU의 명성 또는 상표를 손상 시키거나 HANU Project를 책임에 노출시킬 수있는 조치를 취하는 경우 HANU Project는이 정책에서 허용되는 용도에 관계없이 HANU 상표의 모든 사용을 중단하도록 요구할 수 있습니다. 37 | 38 | 39 | ## 일반 목표 40 | 41 | 일반적으로 "HANU"라는 단어 표시와 HANU 로고를 최소한의 제한으로 사용하여 HANU 이벤트, 소프트웨어 또는 서비스를 나타냅니다. 42 | 43 | 다음 상표를 사용하지 않기를 바랍니다. 44 | 45 | -기타 이벤트, 소프트웨어 또는 서비스를 언급 46 | -오해의 소지가 있거나 타사 이벤트, 소프트웨어 또는 서비스가 Project HANU와 연관되어 있음을 암시 할 수있는 방식 47 | -Project HANU에서 만든 소프트웨어가 오픈 소스이고 HANU를 무료로 사용할 수 있는지에 대해 커뮤니티를 혼란스럽게하는 방식 48 | 49 | ## 승인이 필요없는 용도 50 | 51 | 모든 상표는 "명목상 사용 규칙"의 적용을받으며, 상표를 사용하여 상표 보유자와 최소한의 관계를 유지하면서 상표 소유자의 이름을 지정할 수 있습니다. 52 | 따라서 소프트웨어 또는 서비스가 HANU 소프트웨어와 통합되거나 HANU 소프트웨어를 사용하거나 HANU 소프트웨어와 호환되거나 HANU 소프트웨어가 포함되어 있음을 항상 진술 할 수 있습니다. 53 | 이 경우 사전 승인없이 "HANU"라는 단어 또는 변경되지 않은 로고를 사용하여이를 나타낼 수 있습니다. 54 | 55 | 이것은 비상업적 용도와 상업적 용도 모두에 해당됩니다. 56 | 이 조항은이 정책의 다른 조항보다 우선합니다. 57 | 그러나 의도 한 상표 사용에 대해 의문이있는 경우 [HANU 상표위원회] []에 문의하십시오. 58 | 59 | ### 상품에 HANU 상표 사용 60 | HANU 상표를 사용하여 제품의 HANU를 언급 *하면 * [승인 할 필요가없는 용도] (# uses-that-ever-require-approval)가 적용됩니다. 61 | 스티커, 모자, 머그잔, 티셔츠 및 기타 물리적 상품에 HANU 상표 (로고 및 워드 마크)를 사용하여 프로젝트와 더 광범위한 오픈 소스 생태계를 홍보하는 것이 좋습니다. 62 | 이러한 용도로는 명시적인 승인이 필요하지 않습니다. 63 | 64 | 1. 공식 HANU 브랜드 가이드 라인을 준수. 65 | 2. 상품은 무료로 제공. 66 | 67 | 우리는 (자신을 포함한) 모든 사람이 수요를 충족시키기에 충분한 양으로 상품을 제공 할 여유가 없다는 것을 이해합니다. 68 | 이 때문에 HANU Project를 통해 프로젝트로 돌아가는 수익으로 HANU 브랜드 상품을 구매할 공식 장소를 만드는 데 커뮤니티의 도움이 필요합니다. 69 | 도움이 필요하면 [HANU Google Group] []에서 Google에 문의하시기 바랍니다. 70 | 명시 적 승인없이 HANU 브랜드 상품을 판매하는 것은 허용되지 않습니다. 71 | 72 | ## 승인이 필요한 용도 73 | 74 | 제품 또는 회사 이름으로 HANU 상표를 상업적으로 사용하려면 먼저 Project HANU의 승인을 받아야합니다. 75 | "HANU Company"라는 회사 또는 "HANU Hosting"또는 "HANU Cloud"제품과 같은 일부 사용은 거부됩니다. 76 | HANU가 오픈 소스인지 상업용인지 또는 제품이나 조직이 Project HANU와 관련이 있거나 후원을 받는지 여부에 대해 지나치게 광범위하거나 혼동되기 때문입니다. 77 | 상업적 또는 비상업적 목적으로 파생 된 (수정 된) 로고 사용은 먼저 Project HANU의 승인을 받아야합니다. 78 | 혼동을 일으킬 수 있으므로 일반적으로이 작업을 수행 할 수 없습니다. 79 | 80 | 81 | ## 상표 사용 방법 82 | HANU 상표의 많은 사용은 아래 예에 표시된보다 구체적인 규칙에 따라 결정되지만 다음 기본 지침은 거의 모든 HANU 상표 사용에 적용됩니다. 83 | 84 | 1. HANU 상표가 등록되었습니다. 85 | 이 마크는 HANU [브랜드 지침] []에 따라 사용해야하며 등록 상표에 "(r)"또는 "®"기호가 붙어 있어야합니다. 86 | 이것은 제거되거나 가려 질 수 없으며 항상 로고와 함께 포함되어야합니다. 87 | 전자 우편, 온라인 토론, 비 그래픽 광고 (허용 된 경우) 및 학술 논문과 같이 해당 표시가 일반적으로 포함되지 않은 모든 상황에서 이 요구 사항이 면제됩니다. 88 | 가능하면 이 심볼을 사용하는 것이 좋지만 비상업적이며 비공식적 인 많은 용도에서는 생략 할 수 있습니다. 89 | 90 | 2. "HANU"라는 단어 또는 HANU 로고가 특정 상황에서 사용되는 경우 다음과 같은 문구를 사용해야합니다. 91 | > "HANU"및 HANU 로고는 HANU Project의 상표 또는 등록 상표입니다. \ 92 | > ___________에서 허가없이 사용합니다. 93 | 94 | 3. 웹 사이트 및 문서의 경우 "법적 진술"페이지에있을 수 있습니다. 95 | 브로셔 및 출판 기사의 경우이 진술은 선택 사항입니다. 96 | 이 자료는 특히 출판 된 자료에 사용하는 것이 좋지만 비상업적이거나 비공식적 인 용도로는 생략 할 수 있습니다. 97 | 98 | 4. 상표를 동사로 사용하지 마십시오 ( "HANU your software!"). 99 | 100 | 101 | ## 사용 예시 102 | 103 | 우리는 다음 용도에 대한 특정 규칙을 가지고 있습니다. 104 | 105 | 1. "HANU"라는 단어를 텍스트로 사용하거나 타사 로고 및 상표의 텍스트로 사용합니다. 106 | 2. HANU 제공 로고 변형 중 하나를 변경되지 않은 형태로 사용합니다. 107 | 108 | 다음 규칙은 이러한 각 클래스에서 상표 사용에 적용됩니다. 109 | 110 | ### 단어 "HANU" 111 | - neo4hanu, hanu-spark, hanu-fortran-kernel과 같이 자유롭게 배포되는 제품 이름에 "HANU"라는 단어를 할 때 사용 및 적합성을 언급 한다면 허용됩니다. 112 | 상용 제품의 경우 HANU 상표위원회에 문의하십시오. 113 | - 회사 이름에 "HANU"라는 단어 사용-HANU 상표위원회의 사전 서면 승인을 통해서만 허용됩니다. 114 | - 무료 배포 응용 프로그램의 일부로 HANU 소프트웨어를 재배포 할 때 "HANU"라는 단어 사용이 허용됨. HANU 소프트웨어의 표준 버전이 수정 된 경우이를 명확하게 표시해 115 | 합니다. 상업적 배포의 경우, 위의 "승인이 필요없는 사용"섹션에 설명 된 명목상의 사용 규칙에 따라 사용하지 않는 경우 HANU에 허가를 요청하십시오. 116 | - 자유롭게 참여하거나 참석할 수있는 사용자 그룹 및 회의 이름에 "HANU"라는 단어 사용 (예 : "HANU Meetup")-HANU 소프트웨어를 참조하는 경우 허용됩니다. 다른 용도에는 허가가 필요합니다. 117 | - "HANU Journal"및 "HANU Cookbook"과 같은 서적 또는 출판물 이름에 "HANU"라는 단어 사용은 HANU 소프트웨어를 언급 할 경우 허용됩니다. 118 | - 웹 사이트, 브로셔, 문서 및 제품 패키징에 "HANU"라는 단어 사용은 HANU 소프트웨어를 언급 할 경우 허용됩니다. TM 기호 사용에 대한 위의 규칙을 따르십시오. 119 | - 광고에서 "HANU"라는 단어 사용은 대부분의 경우 위의 "승인이 필요없는 사용"섹션에 설명 된 명목상의 사용 규칙에 따라 허용됩니다. 사전 허가가 있는 광고에서만 다른 용도로 사용합니다. 120 | - 이메일에서 비공식적으로 "HANU"라는 단어 사용은 TM 기호없이 허용됩니다. 121 | - 학술 논문, 논문 및 서적에서 "HANU"라는 단어 사용은 TM 기호없이 허용됩니다. 122 | - 다른 상표에서 "HANU"라는 단어 사용은 위에서 설명한 것을 제외하고 HANU의 사전 서면 허가 없이는 사용할 수 없습니다. 123 | - 도메인 이름에 "HANU"라는 단어 사용은 "hanu.example.com"및 "example.com/hanu"와 같은 하위 도메인 및 URL 경로에서 허용됩니다. 124 | "hanucloud.com"또는 "hostedhanu.horse"와 같은 기본 도메인에서는 사용할 수 없습니다. 125 | 126 | -------------------------------------------------------------------------------- /assets/images/git-workflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openinfradev/community/423b2e767ebe835a62adc6d838a8d76dad54c509/assets/images/git-workflow.png -------------------------------------------------------------------------------- /assets/logo/hanu-logo-temp.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openinfradev/community/423b2e767ebe835a62adc6d838a8d76dad54c509/assets/logo/hanu-logo-temp.png -------------------------------------------------------------------------------- /code-of-conduct.md: -------------------------------------------------------------------------------- 1 | # HANU 커뮤니티 행동 강령 v2.0 2 | 3 | ## 서약 4 | 5 | 우리는 구성원, 기여자 및 리더로서 커뮤니티에 참여하여 6 | 연령, 신체 크기, 눈에 보이거나 보이지 않는 장애, 민족성, 성별, 성 정체성과 표현, 7 | 경력, 학력, 사회 경제적 지위, 국적, 외모, 인종, 종교 8 | 또는 성적 정체성과 성적 성향에 관계없이 모든 사람을 차별하지 않을 것을 서약한다. 9 | 10 | 우리는 개방적이고 친근하며 다양하고 포용적이며 건강한 커뮤니티에 기여하는 11 | 방식으로 행동하고 상호작용할 것을 서약한다. 12 | 13 | ## 표준 14 | 15 | 커뮤니티의 긍정적인 환경을 위해 기여자가 해야 할 행동은 다음과 같다: 16 | 17 | * 다른 사람들에 대한 친절과 공감 표현 18 | * 서로 다른 의견 및 관점, 경험에 대한 존중 19 | * 건설적인 피드백을 제공 및 열린 마음으로 수락 20 | * 책임을 받아들이고 실수로 인해 영향을 받은 사람들에게 사과하며 21 | 경험을 통해 배움 22 | * 개인뿐만 아닌 전체 커뮤니티를 위한 최선의 방법에 집중 23 | 24 | 25 | 하지말아야 할 행동은 다음과 같다: 26 | 27 | * 성적인 언어와 이미지 사용, 성적 관심이나 어떤 종류의 접근 28 | * 소모적인 논쟁, 모욕적 또는 비하하는 댓글과 개인적 또는 정치적인 공격 29 | * 공개적이거나 개인적인 괴롭힘 30 | * 동의없는 집주소 또는 이메일 주소 등의 개인 정보의 공개 31 | * 부적절한 것으로 간주될 수 있는 다른 행위 32 | 33 | ## 집행 책임 34 | 35 | 커뮤니티 리더는 허용되는 행동의 기준을 명확히 하고 집행할 책임이 있으며 36 | 부적절하다고 여겨지는 모든 행동, 위협, 공격 또는 피해에 대해 적절하고 37 | 공정한 행동을 취한다. 38 | 39 | 프로젝트 유지자는 이 행동 강령을 따르지 않은 댓글, 커밋, 코드, 위키 편집, 40 | 이슈와 그 외 다른 기여를 삭제, 수정 또는 거부할 권리와 책임이 있다. 또한, 41 | 부적당하거나 험악하거나 공격적이거나 해롭다고 생각하는 다른 행동을 한 기여자를 42 | 일시적 또는 영구적으로 퇴장시킬 수 있다. 43 | 44 | 커뮤니티 리더는 이 행동 강령을 따르지 않는 댓글, 커밋, 코드, 위키 편집, 45 | 이슈와 그 외 다른 기여를 삭제, 수정 또는 거부할 권리와 책임이 있으며, 46 | 적절한 경우 중재적 의사결정에 대한 이유를 전달할 것이다. 47 | 48 | ## 범위 49 | 50 | 이 행동 강령은 개인이 공개 영역에서 커뮤니티를 공식적으로 대표할 때를 51 | 포함하여 모든 커뮤니티 영역에 적용된다. 52 | 커뮤니티 대표의 예로 공식 이메일 주소 사용, 공식 소셜 미디어 계정을 통한 게시, 53 | 온/오프라인 이벤트에서 임명된 대표자의 활동이 있다. 54 | 55 | ## 집행 56 | 57 | 모욕적이거나 괴롭힘 또는 그 외 하지말아야 할 행동을 발견하면 58 | [연락 방법 입력]을 통해 집행 책임이 있는 커뮤니티 리더에게 보고한다. 59 | 모든 불만사항은 신속하고 공정하게 검토되고 조사될 것이다. 60 | 61 | 커뮤니티 리더는 사건의 보고자의 사생활과 안전을 존중할 의무가 있다. 62 | 63 | ## 집행 지침 64 | 65 | 커뮤니티 리더는 행동 강령 위반으로 간주되는 행동에 대한 결과를 결정할 때, 66 | 다음의 커뮤니티 영향 지침을 준수한다: 67 | 68 | ### 1. 정정 69 | 70 | **커뮤니티 영향**: 커뮤니티 내 부적절한 언어 사용이나 71 | 비전문적인 행동 또는 불쾌함을 주는 행동. 72 | 73 | **결과**: 커뮤니티 리더가 별도로 위반에 대한 명확성과 부적절함에 대한 74 | 이유를 설명하고 서면 경고. 75 | 공개 사과를 요청할 수 있다. 76 | 77 | ### 2. 경고 78 | 79 | **커뮤니티 영향**: 단일 사고 또는 연속된 행동 위반. 80 | 81 | **결과**: 지속적인 행동에 대한 결과에 대해 경고. 82 | 특정 기간동안 행동 강령을 시행하는 사람들과의 원치 않는 상호작용을 포함한 83 | 관련된 사람들과의 상호작용 금지. 소셜 미디어와 같은 외부 채널뿐만 아닌 84 | 커뮤니티 공간에서의 상호작용도 금지된다. 85 | 이 조항을 위반하면 일시적 혹은 영구적으로 제재로 이어질 수 있다. 86 | 87 | ### 3. 일시적인 제재 88 | 89 | **커뮤니티 영향**: 지속적으로 부적절한 행동을 포함한 90 | 심각한 커뮤니티 기준 위반. 91 | 92 | **결과**: 특정 기간동안 커뮤니티와의 어떠한 종류의 상호작용이나 93 | 공개적 소통이 일시적 제재. 94 | 이 기간동안 행동 강령을 시행하는 사람들과의 원치 않는 상호작용을 포함한 95 | 관련된 사람들과의 상호작용 금지. 소셜 미디어와 같은 외부 채널뿐만 아닌 96 | 커뮤니티 공간에서의 상호작용도 금지된다. 97 | 이 조항을 위반하면 일시적 혹은 영구적으로 제재로 이어질 수 있다. 98 | 99 | ### 4. 영구 제재 100 | 101 | **커뮤니티 영향**: 지속적인 부적절한 행동, 개인적인 괴롭힘 또는 102 | 개인의 계급에 대한 공격이나 폄하를 포함한 커뮤니티 표준 위반 패턴을 보임. 103 | 104 | **결과**: 커뮤니티와의 모든 종류의 공개적 교류를 영구적으로 제재. 105 | 106 | ## 참고 107 | 108 | 본 행동 강령은 [기여자 규약][homepage] 의 2.0 버전을 기준으로 작성되었습니다. 2.0버전에 대한 내용은 109 | [https://www.contributor-covenant.org/ko/version/2/0/code-of-conduct.html][v2.0] 에서 110 | 확인할 수 있습니다. 111 | 112 | ## Reporting 가이드라인 113 | 114 | 만약 커뮤니티 행동 강령을 위반하는 사례가 있다고 생각하신다면, Community의 이슈 (https://github.com/openinfradev/community/issues/new)로 등록하여 알려주시기 바랍니다. 직접적인 연락이 필요하시다면 다음 메일주소 (안재석, bluejay.ahn@gmail.com) 로 연락 주시기 바랍니다. 115 | -------------------------------------------------------------------------------- /communication/README.md: -------------------------------------------------------------------------------- 1 | > 커뮤니케이션 채널 설명 2 | > Contact Point 정보 제공 3 | > 회의록 등록 -------------------------------------------------------------------------------- /contributing/README.md: -------------------------------------------------------------------------------- 1 | # How to Contribute 2 | 3 | HANU Community에 오신 모든 분들을 열렬히 환영합니다!!! :DDDDD 4 | 5 | HANU는 모든 소스 코드와 문서를 완전히 공개하고 커뮤니티 구성원이 협업하여 개발하는 오픈소스 개발 방식을 따릅니다. 여러분의 소중한 기여로 HANU Community의 Project는 성장할 수 있습니다. 6 | 7 | 여기서는 HANU Community에 기여하기 위한 방법을 자세히 설명합니다. 8 | 9 | - [How to Contribute](#how-to-contribute) 10 | - [Prerequisites](#prerequisites) 11 | - [Sign the CLA](#sign-the-cla) 12 | - [Code of Conduct](#code-of-conduct) 13 | - [개발 환경 구축](#개발-환경-구축) 14 | - [GitHub Workflow](#github-workflow) 15 | - [Testing](#testing) 16 | - [Pull Request 프로세스](#pull-request-프로세스) 17 | - [Code Review](#code-review) 18 | - [Security](#security) 19 | - [Documentation](#documentation) 20 | - [Issue 관리 / 분류](#issue-관리--분류) 21 | 22 | ## Prerequisites 23 | 24 | HANU Community에 기여하기 전에 몇가지 확인해야 할 사항들이 있습니다. 25 | 26 | ### Sign the CLA 27 | 28 | HANU Community는 예기치 않은 법적 문제를 방지하기 위해 기여자에게 [Contributor License Agreement](../CLA.md)의 서명을 받고 있습니다. 기여자가 CLA에 서명함으로 HANU Community의 모든 Project는 누구나 법적인 문제 없이 자유롭게 사용하고 배포할 수 있게 됩니다. 29 | 30 | ### Code of Conduct 31 | 32 | HANU Community는 모든 구성원을 환영하고 존중합니다. 이러한 문화와 환경이 지속되기 위해 모든 구성원은 [Code of Conduct / 행동 강령](../code-of-conduct.md)을 준수해야 합니다. 꼭 주의 깊게 읽고 따라주시기 바랍니다. 33 | 34 | ## 개발 환경 구축 35 | 36 | [Development Guide](../developing/README.md)에서는 개발 환경 구축, 빌드, 테스트 등 개발에 참여하기 위해 필요한 내용을 자세히 안내합니다. 37 | 38 | 39 | ## GitHub Workflow 40 | 41 | HANU Community는 GitHub Workflow에 따라 기여를 제출하고 검토 및 Merge합니다. 42 | 43 | 다음 페이지에서 HANU Community의 [GitHub Workflow](github-workflow.md)를 확인하세요. 44 | 45 | 46 | ## Testing 47 | 48 | HANU Community의 신뢰성과 안정성을 위해 모든 기여자는 기여를 제출하기 전에 Test를 수행해야 합니다. HANU Community는 다음과 같은 형태의 Test를 수행하고 있습니다. 49 | 50 | * Unit Test 51 | * Integration Test 52 | * End-to-end ("e2e") Test 53 | 54 | Test와 관련한 자세한 사항은 다음 페이지를 참고하세요. : [Testing Guide](../developing/test.md) 55 | 56 | 57 | ## Pull Request 프로세스 58 | 59 | HANU Community에 Pull Request를 제출하면 어떤일이 벌어질까요? 60 | 61 | 어떤 Pull Request가 쉽게 merge가 될 수 있을까요? 62 | 63 | 이에 대한 자세한 설명을 다음 페이지에서 참고하세요. : [Pull Request 프로세스](pull-requests.md) 64 | 65 | 66 | ## Code Review 67 | 68 | Code Review는 Code의 가독성과 품질을 높여서 신뢰할 수 있는 HANU Community의 Project가 되기 위해 꼭 필요한 절차입니다. 69 | 70 | Code Review 과정의 절차와 역할은 각각 다음 페이지에서 확인하실 수 있습니다. 71 | 72 | * 절차 : [Pull Request 프로세스](pull-requests.md) 73 | * 역할 : [Membership](../governance/membership.md) 74 | 75 | Reviewer에게 좋은 Review 결과를 얻기 위해서는 다음 사항을 유념하세요. 76 | 77 | * [Coding Convention](../developing/coding-convention.md)을 따르세요. 78 | * [Commit Message](https://chris.beams.io/posts/git-commit/)는 간단 명료하면서도 Reviewer가 변경 사항을 쉽게 이해할 수 있도록 충분한 정보를 포함하여 작성하세요. 79 | * 변경 사항이 많다면 이를 논리적인 일련의 작은 패치로 나누어서 변경 사항을 이해하기 쉽게 만드세요. 80 | 81 | 82 | ## Security 83 | 84 | > `need-to-improve` > 85 | > * 보안취약점 이슈에 대해 어떻게 관리할 지에 대한 검토 필요. 86 | > * 참고 : https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md 87 | > * 필요한 시점에 작성합니다. 88 | 89 | ## Documentation 90 | 91 | > `need-to-improve` > 92 | > * User Guide를 위한 웹사이트를 구축한다면, 문서화에 기여하는 방법을 여기에 추가해야함 93 | > * 필요한 시점에 작성합니다. 94 | 95 | 96 | ## Issue 관리 / 분류 97 | 98 | > `need-to-improve` > 99 | > * Issue 분류 체계를 가지고 갈 것인지 검토 필요. 100 | > * 참고 자료 : https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md 101 | > * 필요한 시점에 작성합니다. 102 | 103 | ## 104 | 105 | 106 | --- 107 | 108 | HANU Community에서의 기여 과정에 문의나 의견이 있을 경우 [Issue](https://github.com/openinfradev/community/issues/new)를 생성해주세요. 109 | -------------------------------------------------------------------------------- /contributing/developing.md: -------------------------------------------------------------------------------- 1 | Developing on HANU project 2 | ============================== 3 | 4 | HANU 프로젝트는 오픈소스 프로젝트로 여러분의 기여와 의견을 적극적으로 환영합니다. :blush: 5 | 6 | 이 문서는 HANU Project의 개발 체계에 대해 설명합니다. 7 | 8 | Github Issue 9 | ------------ 10 | * Bug Report, Feature Request 는 모두 Github Issue로 등록되어야 합니다. 11 | * Issue 등록 시, 제공되는 Issue Template에 맞게 정보를 작성하지 않으면 정보 부족으로 Issue가 Closed 될 수 있습니다. 12 | * 채택된 Issue는 Label이 추가됩니다. 13 | 14 | Code Contribution 15 | ----------------- 16 | > Note: 먼저 Github Issue로 등록되어 Labeling 된 이후, 아래 단계를 시작합니다. 17 | > Issue가 없는 PR을 Reject 됩니다. 18 | 19 | 1. Origin Repo를 Fork하여 개발합니다. 참고: [fork-a-repo guide](https://help.github.com/articles/fork-a-repo) 20 | 2. forked repository에서 개발이 완료되면, Pull Request로 Merge 요청을 합니다. 참고: [submit a pull request](https://help.github.com/articles/using-pull-requests) 21 | 3. PR이 생성되면 CI pipeline(github action, jenkins pipeline 등)이 실행됩니다. CI Pipeline 실패 시, 문제를 수정하여 commit 해야합니다. 22 | 4. CI Pipeline이 통과되면, 1명 이상의 review approval을 받아 Merge됩니다. 23 | 24 | CI Pipeline 25 | ----------- 26 | HANU Project에서는 github action과 jenkins를 사용하고 있습니다. 27 | 28 | ### Github Action 29 | code build, unit test, docker image build & push 와 같은 대부분의 CI 작업을 커버하고 있습니다. 30 | 31 | 각 프로젝트의 .github/workflows 밑에서 파이프라인을 확인할 수 있습니다. 32 | 33 | ### Jenkins 34 | [tacoplay](https://github.com/openinfradev/tacoplay) 프로젝트와 같이 인프라에 지속적으로 배포 테스트를 하는 경우에 사용합니다. 35 | 36 | 현재 1개의 CI Pipeline이 있습니다. 37 | - PR 생성 및 업데이트 시, CI용 인프라에 ansible playbook 배포 테스트 38 | 39 | Project Release 40 | --------------- 41 | Release 주기는 아직 `미정`입니다. 42 | 43 | Release는 Tag로 관리되며, Release Note로 변경사항을 확인할 수 있습니다. 44 | 45 | 46 | 개발 Agenda & 논의 사항 공유 47 | ----------------------- 48 | Google Docs에 월 정기 회의 회의록을 공유합니다. 49 | 50 | Slack Channel을 통해 실시간으로 소통할 수 있습니다. 51 | 52 | -------------------------------------------------------------------------------- /contributing/github-workflow.md: -------------------------------------------------------------------------------- 1 | # GitHub Workflow 2 | 3 | HANU Community는 GitHub Workflow에 따라 기여를 제출하고 검토 및 Merge합니다. 4 | 5 | ![github-workflow](../assets/images/git-workflow.png) 6 | 7 | 여기서는 HANU Community의 대표적인 Project인 tacoplay를 예시로 GitHub Workflow를 설명합니다. 8 | 9 | - [GitHub Workflow](#github-workflow) 10 | - [GitHub Workflow example](#github-workflow-example) 11 | - [Step 1. Fork](#step-1-fork) 12 | - [Step 2. Clone](#step-2-clone) 13 | - [Step 3. Fetch / Rebase](#step-3-fetch--rebase) 14 | - [Step 4. Create a branch](#step-4-create-a-branch) 15 | - [Step 5. Commit](#step-5-commit) 16 | - [Step 6. Push](#step-6-push) 17 | - [Step 7. Create a Pull Request](#step-7-create-a-pull-request) 18 | - [Code Review](#code-review) 19 | - [Merge](#merge) 20 | - [Revert Commit](#revert-commit) 21 | 22 | ## GitHub Workflow example 23 | 24 | ### Step 1. Fork 25 | 26 | 1. GitHub에 본인 계정으로 로그인 후 https://github.com/openinfradev/tacoplay 를 방문하세요. 27 | 2. 우측 상단의 `Fork` 버튼을 클릭해서 tacoplay를 본인 계정으로 Fork 하세요. 28 | 29 | ### Step 2. Clone 30 | 31 | Fork한 본인 계정의 Repository를 Local로 Clone 하고, upstream repository를 추가하세요. 32 | 33 | ``` 34 | mkdir -p $working_dir 35 | cd $working_dir 36 | git clone https://github.com/$user/tacoplay.git 37 | 38 | cd $working_dir/tacoplay 39 | git remote add upstream https://github.com/openinfradev/tacoplay.git 40 | 41 | # Never push to upstream main 42 | git remote set-url --push upstream no_push 43 | 44 | # Confirm that your remotes make sense: 45 | git remote -v 46 | ``` 47 | 48 | ### Step 3. Fetch / Rebase 49 | 50 | (Clone후 시간이 지난 시점이라면) main branch를 최신 상태로 유지합니다. 51 | 52 | fetch를 수행하고, upstream에 변경 사항이 있을 경우 경우 rebase하여 main branch를 최신 상태로 유지합니다. 53 | 54 | ``` 55 | cd $working_dir/tacoplay 56 | git fetch upstream 57 | git checkout main 58 | git rebase upstream/main 59 | ``` 60 | 61 | fetch/rebase 대신 pull을 사용하지 마세요. git pull은 merge를 수행하면서 commit history를 지저분해지게 할 수 있기 때문입니다. 62 | 63 | 64 | ### Step 4. Create a branch 65 | 66 | 이 상태에서 myfeature branch를 생성합니다. 67 | 68 | ``` 69 | git checkout -b myfeature 70 | ``` 71 | 72 | myfeature branch에서 코드 수정 작업을 합니다. 73 | 74 | 75 | ### Step 5. Commit 76 | 77 | 수정 사항을 commit 하세요. commit message는 가능한 자세히 작성합니다. 78 | 79 | ``` 80 | git add --all 81 | git commit 82 | ``` 83 | 84 | ### Step 6. Push 85 | 86 | 생성한 commit을 origin에 push하세요. 87 | 88 | ``` 89 | git push -f ${your_remote_name} myfeature 90 | ``` 91 | 92 | ### Step 7. Create a Pull Request 93 | 94 | 1. GitHub에 로그인해서 본인 계정의 Fork한 repository로 갑니다. : https://github.com/$user/tacoplay 95 | 2. `myfeature` branch 옆의 `Compare & Pull Request` 버튼을 클릭하세요. 96 | 3. Pull Request하여 수정 사항의 리뷰를 요청합니다. Pull Request에 관련한 세부 사항은 다음 안내를 참고하세요. : [Pull Request](pull-requests.md) 97 | 98 | ## Code Review 99 | 100 | Pull Request가 Open되면 한명 이상의 Reviewer에게 할당 됩니다. Reviewer는 수정 사항에 대해 Coding Style부터 버그 유무 등 Review를 수행하여 merge 여부를 결정합니다. 101 | 102 | Review 결과 수정이 필요한 사항은 `myfeature` branch 상에서 수행합니다. 103 | 104 | ## Merge 105 | 106 | Reviewer와 Approval의 승인을 받으면 자동으로 merge가 진행됩니다. 107 | 108 | ## Revert Commit 109 | 110 | Commit을 revert하고자 할때는 다음 안내를 따르세요. 111 | 112 | * Revert용 branch를 생성하고, upstream과 sync를 맞추세요. 113 | 114 | ``` 115 | # create a branch 116 | git checkout -b myrevert 117 | 118 | # sync the branch with upstream 119 | git fetch upstream 120 | git rebase upstream/main 121 | ``` 122 | 123 | * revert하고자 하는 commit이 124 | * 복수의 commit일 경우 125 | ``` 126 | # SHA is the hash of the merge commit you wish to revert 127 | git revert -m 1 SHA 128 | ``` 129 | * 하나의 commit일 경우 130 | ``` 131 | # SHA is the hash of the single commit you wish to revert 132 | git revert SHA 133 | ``` 134 | * 이 명령은 변경사항을 revert한 새로운 commit을 생성합니다. 이 commit을 push하세요. 135 | ``` 136 | git push ${your_remote_name} myrevert 137 | ``` 138 | * 이제 [Create a Pull Request](#step-7-create-a-pull-request) 합니다. 139 | 140 | 141 | --- 142 | 143 | HANU Community에서의 GitHub Workflow 과정에 문의나 의견이 있을 경우 [Issue](https://github.com/openinfradev/community/issues/new)를 생성해주세요. 144 | -------------------------------------------------------------------------------- /contributing/pull-requests.md: -------------------------------------------------------------------------------- 1 | # Pull Request process 2 | 3 | > `need-to-improve` 추가 작성 필요 (다음 페이지 참고 가능 : https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md) 4 | 5 | -------------------------------------------------------------------------------- /developing/README.md: -------------------------------------------------------------------------------- 1 | # Development Guide 2 | 3 | HANU Community 개발자 여러분! 4 | 5 | HANU는 모든 소스 코드 뿐만 아니라 전체 개발 과정을 자세히 문서화하여 GitHub에 공개하고 있습니다. 누구나 HANU에 관심이 있는 분은 아래 문서들을 참고하여 개발에 참여하여 자신의 역량을 쌓을 수 있을 뿐만 아니라 한국의 오픈소스 생태계에 기여할 수 있습니다. HANU는 한국의 오픈소스 개발자 분들과 함께합니다! 6 | 7 | HANU Community에는 여러개의 Project가 있으며 모두 공통적으로 아래의 개발 절차를 준수합니다. 8 | 9 | - [Development Guide](#development-guide) 10 | - [How to Build](#how-to-build) 11 | - [Testing Guide](#testing-guide) 12 | - [Coding Convention](#coding-convention) 13 | - [CI/CD](#cicd) 14 | - [Release](#release) 15 | 16 | ## How to Build 17 | 18 | HANU Community의 주요 Project는 Docker 기반 빌드 환경을 제공합니다. 19 | 20 | 다음 페이지에 Project Build를 위한 공통적으로 설치가 요구되는 사항을 정리하였으니 참고하세요. [How to Build](./build.md) 21 | 22 | ## Testing Guide 23 | 24 | HANU Community의 주요 Project는 다음과 같은 Test를 통해 개발/배포합니다. 기여를 준비하는 오픈소스 개발자 분들은 자신의 개발 결과가 HANU의 Project에 이상없이 반영할 수 있을지에 대해 Unit Test와 Integration Test를 통해 확인할 수 있습니다. 25 | 26 | HANU의 Project는 Master Branch의 안정성 유지를 위해 Unit Test, Integration Test, End-to-End Test에 통과한 Pull Request만을 Merge합니다. 27 | 28 | * Unit Test 29 | * Integration Test 30 | * End-to-End Test 31 | 32 | 각 Test의 절차 및 요구사항을 다음 페이지에서 자세히 설명합니다. : [Testing Guide](test.md) 33 | 34 | 35 | ## Coding Convention 36 | 37 | HANU Community내 Project의 소스 코드 작성 시 준수해야 할 Coding Style 있습니다. HANU Project 소스 코드의 일관성과 가독성을 위해 기여자 분들은 가능한 이 Coding Convention을 따라주세요. : [Coding Convention](coding-convention.md) 38 | 39 | 40 | ## CI/CD 41 | 42 | HANU Community는 Continuous Integration / Continuous Deployment를 위한 자동화 환경을 구축하고 있습니다. HANU의 CI/CD에 대한 자세한 사항은 다음 페이지를 참고하세요. : [CI/CD](ci-cd.md) 43 | 44 | 45 | ## Release 46 | 47 | HANU Community내 Project의 Release 정책과 절차에 대한 자세한 내용은 다음 페이지를 참고하세요. : [Release](release.md) 48 | 49 | --- 50 | 51 | HANU Community에서의 개발 과정에 문의나 의견이 있을 경우 [Issue](https://github.com/openinfradev/community/issues/new)를 생성해주세요. 52 | -------------------------------------------------------------------------------- /developing/build.md: -------------------------------------------------------------------------------- 1 | # How to Build 2 | 3 | 여기서는 HANU Community의 주요 Project를 Build하기 위해 공통적으로 요구되는 사항을 제공합니다. 4 | 5 | ## Docker로 빌드하기 6 | 7 | HANU는 보다 쉽고 빠른 빌드 환경을 제공하기 위해 [Docker](https://www.docker.com/)를 사용합니다. Docker를 이용한 빌드 절차는 다음과 같습니다. 8 | 9 | > `need-to-improve` 추가 작성 필요 (다음 페이지 참고 가능 : https://github.com/kubernetes/kubernetes/blob/a1b4b29ac0320deda594c3afc6b0adcb824d1bfa/build/README.md) 10 | 11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 | 22 | ## Local에서 빌드하기 23 | 24 | Docker를 통해 빌드하는 것 보다는 수고스러울 수 있지만 Local에 빌드 환경을 구축하여 개발하는게 필요할 때도 있습니다. 아래에서는 Linux, Windowns 및 macOS에서 빌드하기 위한 HW/SW 요구사항 및 절차를 설명합니다. 25 | 26 | 27 | > `need-to-improve` 추가 작성 필요 (다음 페이지 참고 가능 : [#building-kubernetes-on-a-local-osshell-environment](https://github.com/kubernetes/community/blob/master/contributors/devel/development.md#building-kubernetes-on-a-local-osshell-environment)) 28 | 29 |
30 |
31 |
32 |
33 |
34 |
35 |
36 |
37 |
38 |
39 | 40 | --- 41 | 42 | 빌드 과정에 문의나 의견이 있을 경우 [Issue](https://github.com/openinfradev/community/issues/new)를 생성해주세요. -------------------------------------------------------------------------------- /developing/ci-cd.md: -------------------------------------------------------------------------------- 1 | # CI / CD 2 | 3 | ### Overview 4 | HANU의 CI/CD pipeline 은 Taco 및 관련 인프라, application 등을 빌드, 배포, 테스트하는 일련의 단계들로 구성되어 있으며, SKT에서 기존에 사용하던 Jenkins 기반의 CI 체계를 참고하여 github 환경에 맞게 새롭게 구성하였습니다. 자체개발한 tacoplay라는 ansible playbook을 사용해 taco cluster를 배포하고, 그 위에 logging/monitoring toolchain, openstack cloud platform을 비롯한 여러 application 등을 배포하고 검증하는 flow로 이루어져 있습니다. 5 | 6 | Application 배포를 위해서 decapod라는 배포 체계를 사용하게 되며, 각 application 별 배포 설정은 yaml 포맷의 manifest로 관리됩니다. 7 | 8 | 모든 코드 수정은 pull request 형태로 제출되어, 기본적인 테스트를 거친 후 human review를 거쳐 main branch에 반영되며, 각각의 컴포넌트 별 테스트 외에 주기적으로 여러 컴포넌트들이 결합되어 수행되는 통합 테스트를 거치게 됩니다. 9 | 10 |
11 | 12 | ### Overall Flow 13 | cicd-flow
14 | 15 | - Deploy-taco job은 주기적으로 kubernetes cluster의 배포를 테스트하며, 배포 성공시 새롭게 배포된 kubernetes cluster를 cluster pool에 계속 추가합니다. Tacoplay repositoy에 새로운 PR(pull request)이 제출될 경우에도 최소한의 배포 테스트를 거친 후에 수정한 내용이 main branch에 merge됩니다. 16 | - Decapod-site-yaml 또는 hanu-site-yaml repository에 새로운 PR이 제출될 경우, lint-decapod-yaml job이 자동으로 수행되며, lint test 등 최소한의 validation 작업을 거친 후 수정한 내용이 main branch에 merge됩니다. 17 | - 실제로 application을 배포하는 deploy-apps job의 경우, kubernetes cluster pool 에서 random으로 cluster를 할당 받은 후 upstream charts와 image, 그리고 앞에서 준비된 decapod yaml 파일을 사용하여 application 배포를 수행하게 됩니다. 18 | 19 |
20 | 21 | ### Job Type 22 | 테스트는 job의 성격에 따라 jenkins job 또는 github action의 형태로 수행됩니다. 23 | 24 | - Jenkins job 형태로 수행되는 프로젝트의 경우, 최상위 디렉토리의 Jenkinsfile이라는 파일에 의해 job이 정의되며, (Eg, https://github.com/openinfradev/tacoplay/blob/main/Jenkinsfile) 25 | - github action의 경우 '.github/workflows' 라는 파일에 job 내용이 정의됩니다. (Eg, https://github.com/openinfradev/kustomize-helm-transformer/blob/main/.github/workflows/run-kustomize.yml) 26 | 27 |
28 | 29 | ### 주요 Job List 30 | 현재 개발 또는 동작 중인 주요 job들은 다음과 같습니다. 31 | 32 | | Job명 | Repository명 | 설명 | 타입 33 | |--------------------|----------------------------------------------------------------------------|-----------------------------------------------|------------ 34 | | deploy-taco | [tacoplay](https://github.com/openinfradev/tacoplay/blob/main/Jenkinsfile) | tacoplay playbook을 사용하여 taco cluster 배포| Jenkins job 35 | | deploy-apps | hanu-site-yaml (private) | decapod toolset 을 사용하여 taco 클러스터 위에 application 배포 (openstack, LMA 등) | Jenkins job 36 | | lint-decapod-yaml | {decapod,hanu}-site-yaml | (common한 내용을 담고 있는) base yaml과 site yaml를 조합시 오류가 없는지 검증 | Github action 37 | | promote (release) | [hanu-ci-jobs](https://github.com/openinfradev/hanu-ci-jobs/blob/main/promote/Jenkinsfile) | 통합테스트 등 검증 완료 후 version release | Jenkins job 38 | | validate-XXX | [hanu-ci-jobs] (TBU) | kubernetes 및 기타 application들이 정상 동작하는지 검증 | Jenkins job 39 | -------------------------------------------------------------------------------- /developing/coding-convention.md: -------------------------------------------------------------------------------- 1 | 2 | # Coding Convention 3 | 4 | HANU Community내 Project의 소스 코드 작성 시 준수해야 할 Coding Style 있습니다. HANU Project 소스 코드의 일관성과 가독성을 위해 기여자 분들은 가능한 이 Coding Convention을 따라주세요. 5 | 6 | 7 | ## Code Convention 8 | 9 | > `need-to-improve` 다음 페이지를 참고하여 Code Convention에 대해 추가 작성이 필요합니다. : [#code-conventions](https://github.com/kubernetes/community/blob/master/contributors/guide/coding-conventions.md#code-conventions) 10 | 11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 | 23 | ## Directory / File Convention 24 | 25 | > `need-to-improve` 다음 페이지를 참고하여 Directory / File convention에 대해 추가 작성이 필요합니다. : [#directory-and-file-conventions](https://github.com/kubernetes/community/blob/master/contributors/guide/coding-conventions.md#directory-and-file-conventions) 26 | 27 | 28 |
29 |
30 |
31 |
32 |
33 |
34 |
35 |
36 |
37 |
-------------------------------------------------------------------------------- /developing/hanu-cicd-flow-v4.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openinfradev/community/423b2e767ebe835a62adc6d838a8d76dad54c509/developing/hanu-cicd-flow-v4.jpg -------------------------------------------------------------------------------- /developing/release.md: -------------------------------------------------------------------------------- 1 | # Release 2 | 3 | > `need-to-improve` > 4 | > * HANU의 Release 정책 및 방법에 대한 설명 5 | > * 필요한 시점에 작성합니다. 6 | > * 참고 : https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/release.md 7 | -------------------------------------------------------------------------------- /developing/test.md: -------------------------------------------------------------------------------- 1 | # Testing Guide 2 | 3 | - [Testing Guide](#testing-guide) 4 | - [Unit Test](#unit-test) 5 | - [Integration tests](#integration-tests) 6 | - [End-to-End tests](#end-to-end-tests) 7 | 8 | HANU Community의 주요 Project는 다음과 같은 Test를 통해 개발/배포합니다. 기여를 준비하는 오픈소스 개발자 분들은 자신의 개발 결과가 HANU의 Project에 이상없이 반영할 수 있을지에 대해 Unit Test와 Integration Test를 통해 확인할 수 있습니다. 9 | 10 | HANU의 Project는 Master Branch의 안정성 유지를 위해 Unit Test, Integration Test, End-to-End Test에 통과한 Pull Request만을 Merge합니다. 11 | 12 | ## Unit Test 13 | 14 | Unit Test는 특정 모듈이 의도된 대로 정상적인 동작을 하는지 테스트 절차입니다. HANU Project의 모든 Package나 주요 파일은 Unit Test를 작성하고 수행해야 합니다. 15 | 16 | Unit Test 소스 코드는 해당 Package 내 소스 코드와 함께 위치합니다. 17 | 18 | 새로운 Package나 주요 기능을 추가한 경우 반드시 Unit Test에도 추가해야 합니다. 19 | 20 | > `need-to-improve` 다음 사항에 대한 확인 및 추가 작성이 필요합니다. 21 | > 22 | > * Unit Test 수행 환경 구축 23 | > * Unit Test 개발 가이드 작성 24 | > * Unit Test 수행 방법 가이드 문서 작성 25 | > 26 | > 가이드 문서는 다음 페이지를 참고할 수 있습니다. : [#unit-tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-testing/testing.md#unit-tests) 27 | 28 |
29 |
30 |
31 |
32 |
33 |
34 |
35 |
36 |
37 |
38 | 39 | ## Integration tests 40 | 41 | Integration Test는 각각의 Package들이 상호작용하여 정상적인 동작을 하는지 테스트하는 절차입니다. Unit Test를 완료한 후에는 Integration Test를 수행하여 복잡한 상황에서 모든 기능이 정상적으로 수행하는지 확인합니다. 42 | 43 | Integration Test에 대한 방법은 다음과 같습니다. 44 | 45 | 46 | > `need-to-improve` 다음 사항에 대한 확인 및 추가 작성이 필요합니다. 47 | > 48 | > * Integration Test 수행 환경 구축 49 | > * Integration Test 수행 방법 가이드 작성 50 | > 51 | > 다음 페이지를 참고할 수 있습니다. : [Integration tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-testing/integration-tests.md) 52 | 53 |
54 |
55 |
56 |
57 |
58 |
59 |
60 |
61 |
62 |
63 | 64 | 65 | ## End-to-End tests 66 | 67 | End-to-End Test (e2e)는 각 시스템 간 동작을 테스트하는 과정입니다. Unit Test와 Integration Test에 통과하였다고 해도 HANU와 같이 분산 환경에서의 여러 시스템이 맞물려서 동작하는 경우, e2e Test에서 문제가 발생하는 경우가 적지 않습니다. 68 | 69 | e2e Test를 통해 HANU Project의 일관되고 안정적인 동작을 보장할 수 있습니다. 70 | 71 | e2e Test의 절차 및 방법은 다음과 같습니다. 72 | 73 | 74 | 75 | > `need-to-improve` 다음 사항에 대한 확인 및 추가 작성이 필요합니다. 76 | > 77 | > * e2e Test 수행 환경 구축 78 | > * e2e Test 수행 방법 가이드 작성 79 | > 80 | > 다음 페이지를 참고할 수 있습니다. : [e2e tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-testing/e2e-tests.md) 81 | 82 |
83 |
84 |
85 |
86 |
87 |
88 |
89 |
90 |
91 |
92 | 93 | --- 94 | HANU Community에서의 Test 과정에 문의나 의견이 있을 경우 [Issue](https://github.com/openinfradev/community/issues/new)를 생성해주세요. 95 | 96 | -------------------------------------------------------------------------------- /governance/README.md: -------------------------------------------------------------------------------- 1 | # HANU Governance 2 | 3 | HANU Governance에 대해 소개합니다. 4 | 5 | - [HANU Governance](#hanu-governance) 6 | - [Our Mission](#our-mission) 7 | - [Principles](#principles) 8 | - [Code of Conduct](#code-of-conduct) 9 | - [Organization](#organization) 10 | - [Membership](#membership) 11 | - [Repository](#repository) 12 | 13 | 14 | ## Our Mission 15 | HANU는 OpenStack를 중심으로 한 [Open Infrastructure](https://openinfra.dev/projects/) 산하 프로젝트들과 Kubernetes를 중심으로 한 [Cloud Native Computing](https://www.cncf.io/) 산하의 프로젝트들을 쉽게 활용할 수 있는 환경을 만들고, 필요한 기술을 오픈소스SW로 개발하여 공유할 수 있는 국내 Community를 만들어 확장합니다. 또한, 글로벌 Upstream 프로젝트에 기여할 수 공동체를 만들어 국내의 오픈소스 생태계 활성화에 기여합니다. 16 | 17 | 18 | ## Principles 19 | 20 | HANU는 다음 원칙을 준수합니다. 21 | 22 | * 공개 : HANU는 모든 소스 코드를 [Apache-2.0](https://spdx.org/licenses/Apache-2.0.html)으로 공개한 오픈소스 입니다. 23 | * 환영과 존중 : HANU는 [Code of Conduct](#code-of-conduct) 준수하는 모든 구성원을 환영하고 존중합니다. 24 | * 투명성 : HANUd의 모든 개발 과정은 투명하게 공개합니다. 25 | * 조율 : 창의적인 아이디어와 기여는 기술적 방향성과 프로젝트 목표에 따라 조율이 될 수 있습니다. 26 | * 회식 : HANU는 한국의 독특한 문화인 회식을 주기적으로 시행합니다. 단, 회식자리에서 발생한 협업, 조율, 아이디어들도 역시 투명하게 문서화하여 공개합니다. 27 | 28 | ## Code of Conduct 29 | 30 | HANU의 모든 구성원은 [HANU Code of Conduct](../code-of-conduct.md)를 준수해야 합니다. 31 | 32 | 33 | ## Organization 34 | 35 | HANU의 효과적인 운영을 위해 아래와 같은 Group을 운영합니다. 36 | 37 | * 기술 위원회 (Technical Committee) 38 | * SIG (Special Interest Group) 39 | * Project 40 | 41 | Group에 대한 자세한 사항은 다음 페이지를 참고하세요. : [Group](./group.md) 42 | 43 | 44 | ## Membership 45 | 46 | HANU의 Membership은 아래와 같은 역할로 구성됩니다. 47 | 48 | * Member 49 | * Contributor 50 | * Committer 51 | 52 | Membership에 대한 자세한 내용은 다음 페이지를 참고하세요. : [Membership](./membership.md) 53 | 54 | 55 | ## Repository 56 | 57 | HANU의 모든 활동은 GitHub에 투명하게 공개합니다. 58 | 59 | * HANU의 GitHub은 여기에 있습니다. : [https://github.com/openinfradev](https://github.com/openinfradev) 60 | 61 | 이 곳의 모든 Repository는 [HANU Repository Policy](./repository.md)에 따라 생성/관리/삭제됩니다. 62 | 63 | 64 | HANU의 Governance에 대해 문의나 의견이 있을 경우 [Issue](https://github.com/openinfradev/community/issues/new)를 생성해주세요. 65 | -------------------------------------------------------------------------------- /governance/committee/README.md: -------------------------------------------------------------------------------- 1 | # Technical Committee 2 | 3 | -------------------------------------------------------------------------------- /governance/election.md: -------------------------------------------------------------------------------- 1 | # 선거 2 | 3 | > 참고 : https://github.com/kubernetes/community/tree/master/events/elections 4 | 5 | 운영위원회 멤버는 선거를 통해 선출합니다. 이를 위한 선거 방식은 다음과 같습니다. 6 | 7 | - [선거](#선거) 8 | - [투표 자격](#투표-자격) 9 | - [입후보 자격](#입후보-자격) 10 | - [선거 과정](#선거-과정) 11 | - [최대 참여 제한](#최대-참여-제한) 12 | - [선거 주기](#선거-주기) 13 | - [선거 일정 및 운영](#선거-일정-및-운영) 14 | - [선거 관리관 선발](#선거-관리관-선발) 15 | - [공석](#공석) 16 | 17 | ## 투표 자격 18 | - 작년 한해 동안 프로젝트에 50개 이상 기여 (이슈 생성, PR 생성, Comment 등 Github 활동 , 참고 : [devstats developer activity counts dashboard](https://k8s.devstats.cncf.io/d/13/developer-activity-counts-by-repository-group?orgId=1&var-period_name=Last%20year&var-metric=contributions&var-repogroup_name=All).) 19 | - 위의 기준을 충족하지는 못하지만, 예외 투표 신청 (예: [voting exception form](https://www.surveymonkey.com/r/k8s-sc-election-2019))을 제출하고, 과반수 찬성 시 투표 참여 가능 20 | 21 | ## 입후보 자격 22 | - 추천 혹은 자원자 23 | - 각각 다른 조직의 3명의 투표 자격자에 의해 승인 (투표 자격이 있는 후보자는 자체 승인 할 수 있음) 24 | 25 | ## 선거 과정 26 | 선거는 [IRV method](https://en.wikipedia.org/wiki/Instant-runoff_voting) (Instant-runoff voting : 즉시 결선 투표) 방법으로 [CIVS](http://civs.cs.cornell.edu/)에서 시간 제한 [Condorcet](https://en.wikipedia.org/wiki/Condorcet_method) 순위를 사용하여 실시되면, 최고 득표자가 오픈된 의석에 선출됩니다. 27 | 28 | ## 최대 참여 제한 29 | 다양성을 장려하기 위해 운영위원회에는 한 회사에서 1/3 이상의 멤버가 참여할 수 없습니다. 30 | 31 | ## 선거 주기 32 | - 운영위원회 멤버는 2년 임기로 선출하며, 4회 연임(8년)이 가능합니다. 33 | - 선거 주기는 멤버의 연속성을 위해 매년 약 절반의 의석이 재선되도록 조정합니다. 34 | 35 | ## 선거 일정 및 운영 36 | 운영위원회는 선거를 운영할 선거관리관을 선발해 선거 일정을 수립합니다. 대략적인 선거 일정은 다음과 같습니다. (선거 절차 : [election procedure](https://git.k8s.io/community/events/elections/README.md)) 37 | 38 | - 7월말 39 | - 선거관리관 선발 40 | - 투표권자 자격 기준 수립 41 | - 선거 준비 42 | - 9월 43 | - 공천기간, 선거 44 | - 10월 45 | - 선거 종료 46 | - 선거 결과 발표 47 | 48 | ## 선거 관리관 선발 49 | 운영위원회는 다음 기준에 따라 3명의 선거 관리관을 선정합니다. 50 | 51 | - 투표 자격이 있어야 합니다. 52 | - 두 명은 이전 선거 관리관 경험자 중 선발하고, 나머지 한 명은 미경험자로 선발합니다. 53 | - 각각 소속이 달라야 합니다. 같은 회사에서 2명 이상 선발할 수 없습니다. 54 | 55 | 선거 관리관은 선거 절차에 따라 선거를 관리합니다. (2020년 선거 : https://github.com/kubernetes/community/tree/master/events/elections/2020) 56 | 57 | ## 공석 58 | 선출된 운원위원회 멤버가 사퇴할 경우, 이전 선거에서 다음으로 많은 표를 얻은 후보에게 의석이 제공됩니다. 이 과정은 의석이 채워질 때까지 계속됩니다. 59 | 60 | 그래도 의석이 채워지지 않을 경우, 해당 직책에 대한 특별 선거를 가능한 빨리 개최합니다. 61 | 62 | 특별선거에서 선출된 운영위원회 멤버는 남은 기간에 관계 없이 이전 멤버의 남은 임기를 수행합니다. -------------------------------------------------------------------------------- /governance/group.md: -------------------------------------------------------------------------------- 1 | # Group 2 | 3 | - [Group](#group) 4 | - [기술 위원회 (Technical Committee)](#기술-위원회-technical-committee) 5 | - [주요 역할](#주요-역할) 6 | - [SIG (Special Interest Group)](#sig-special-interest-group) 7 | - [Project](#project) 8 | 9 | 10 | ## 기술 위원회 (Technical Committee) 11 | ### 주요 역할 12 | - Project-level governance 13 | - Project-level 정책 관리 (예: Code of Conduct) 14 | - 최종 의사 결정 15 | - 하위 조직 관리 16 | 17 | 기술 위원회는 산하 프로젝트의 PTL들과 매년 선거를 통해서 선출된 멤버로 이루어 집니다. 18 | 선거 방법은 다음 페이지를 참고하세요. : [HANU 선거 절차](election.md) 19 | 20 | ## SIG (Special Interest Group) 21 | 22 | HANU의 SIG는 프로젝트 외에 Cloud Native Infrastructure와 관련하여 특정 주제에 대한 테스트, 논의, 스터디 등을 수행하기 위한 그룹입니다. 23 | 24 | 누구나 SIG 결성을 제안할 수 있으며, Technical Committee가 승인 여부를 결정합니다. 25 | 26 | HANU의 SIG에 대한 자세한 사항은 다음 페이지를 참고하세요. : [HANU SIG](./sig/README.md) 27 | 28 | ## Project 29 | ... (내용 추가 작성 예정 - haksung) 30 | 31 | > (필요 시, Working / Uesr Group 추가) 32 | > ## Working Groups 33 | > Working Group은 여러 SIG에 걸친 주제에 대한 토론 / 작업을 용이하게 하기 위한 커뮤니티입니다. 34 | > 35 | > ## User Groups 36 | > User Group은 SIG나 Working Group에 적합하지는 않지만, 사용자와 관련이 있는 주제를 다룹니다. (예: continuos delivery) 37 | 38 | 39 | -------------------------------------------------------------------------------- /governance/membership.md: -------------------------------------------------------------------------------- 1 | # Membership 2 | - [Membership](#membership) 3 | - [Member](#member) 4 | - [Contributor](#contributor) 5 | - [요구사항](#요구사항) 6 | - [책임과 권한](#책임과-권한) 7 | - [Committer](#committer) 8 | - [요구 사항](#요구-사항) 9 | - [책임과 권한](#책임과-권한-1) 10 | 11 | 12 | HANU의 프로젝트에는 다음과 같은 역할의 참여자가 있습니다. 13 | 14 | | Role | Responsibilities | Requirements | Defined by | 15 | | -----| ---------------- | ------------ | -------| 16 | | [Member](#member) | HANU에 참여하는 전원 | | 17 | | [Contributor](#contributor) | 코드, 문서 등 Github repository에 직접적인 기여를 한 자| 프로젝트 내 Review와 저작 이력이 있는 Member | * 등록 방법 추가 필요 (예: [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md) file reviewer entry) | 18 | | [Committer](#committer) | 프로젝트에 대한 기술 지휘권을 갖고 코드에 대한 리뷰와 Merge 권한을 가진 자 | 기술적 목표와 방향에 대한 깊이 이해하고 경험이 풍부하며 적극적인 Contributor | * 등록 방법 추가 필요 (예: [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md) file approver entry) | 19 | 20 | 각 역할에 대한 요구사항, 책임 및 권한은 다음과 같습니다. 21 | 22 | ## Member 23 | 24 | HANU는 오픈소스의 협업과 공유 정신에 따라 누구든지 참여할 수 있으며, HANU의 행동 강령([Code of Conduct](../code-of-conduct.md))을 준수하는 모든 참여 인원은 HANU의 Member입니다. 25 | 26 | * Member는 HANU 내 여러 프로젝트의 사용자로서 프로젝트에 목적을 부여하고, 기능, 버그 리포트 등의 방법으로 피드백을 제공함으로써 프로젝트를 발전시키는 데 도움을 줄 수 있습니다. 27 | * 이처럼 Member는 HANU의 성장과 발전에 가장 중요한 구성원입니다. 28 | 29 | ## Contributor 30 | 31 | Contributor는 코드, 문서화 등의 방법으로 HANU에 지속해서 공헌한 기여자입니다. 32 | * Issue와 PR을 자신에게 Assign 할 수 있고, SIG에 참여할 수 있습니다.  33 | * Contributor는 는 GitHub organization의 Member로 등록됩니다.  34 | 35 | ### 요구사항 36 | - Github 계정에서 [two-factor authentication](https://help.github.com/articles/about-two-factor-authentication) 활성화합니다. 37 | - 프로젝트에 다음과 같은 형태의  기여를 합니다. 38 | - GitHub에서 PR 작성 또는 Review 39 | - GitHub에서 Issue 생성 또는 Comment 작성 40 | - SIG, Project 등 커뮤니티 내 토론 (미팅, Slack, 메일링 리스트 등)에 기여 41 | 메일링리스트 가입합니다. 42 | - [contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)를 숙독합니다. 43 | - 하나 이상의 프로젝트에 적극적으로 기여합니다. 44 | - 2명의 Committer로부터 후원을 받습니다. 45 | - Committer인 후원자는 예비 Contributor와 긴밀하게 작업한 이력이 있어야 함. (예: code/design/proposal review, issue 조율 등) 46 | - 각 후원자는 다른 조직 소속이어야 함 47 | - [community](https://github.com/openinfradev/community) repository에 "REQUEST: New membership for "이라는 제목의 Issue를 생성합니다. (* issue template 신규 생성 필요 (예: [k8s issue tempalte](https://github.com/kubernetes/org/issues/new?template=membership.md&title=REQUEST%3A%20New%20membership%20for%20%3Cyour-GH-handle%3E))) 48 | - 이때 후원자를 멘션 표시(@mentioned) 합니다. 49 | - 체크리스트의 모든 항목을 완료합니다. (* 체크리스트 신규 생성 필요 (예: [preview the current version of the template](https://git.k8s.io/org/.github/ISSUE_TEMPLATE/membership.md))) 50 | - 후원자에게 +1을 체크하도록 요청합니다.  51 | - 후원자 응답이 완료되면 GitHub 관리팀 (* HANU GitHub 관리 조직 생성 필요 - 예: [Kubernetes GitHub Admin team](https://github.com/kubernetes/community/blob/master/github-management/README.md#github-administration-team))이 검토하고, 누락된 정보가 있으면 보완을 요청합니다.  52 | 53 | ### 책임과 권한 54 | - 할당된 Issue와 PR에 대응합니다.  55 | - 기여한 코드의 active owner로서 다음에 대한 책임을 갖습니다. 56 | - 버그나 이슈를 해결합니다.  57 | - 테스트에 항상 통과될 수 있게 합니다. 58 | - Contributor는 오픈된 PR에 대해  /lgtm를 할 수 있습니다.  59 | - Issue나 PR을 자신에게 할당될 수 있습니다. 60 | - Member는 Contributor를 /cd @username 하여 review를 요청할 수 있습니다.  61 | 62 | 63 | ## Committer 64 | 65 | Committer는 프로젝트에 대한 기술 지휘권을 가지며 기여된 코드를 Review하고 Approve 할 수 있습니다. 프로젝트의 건전성에 대한 올바른 판단과 책임을 보여 주어야 합니다. 기술 방향을 설정하고, 설계에 대한 결정을 내리거나 승인해야 합니다. Committer는 코드 품질과 정확성에 초점을 맞춰서 Review를 하고, Approval을 위해 다음과 같은 부분까지도 고려해야 합니다. 66 | - 양방향 호환성 67 | - API 및 Flag Convention 68 | - 민감한 성능 및 정확성 문제 69 | - 시스템의 다른 부분과 상호작용 70 | 71 | Committer 목록은 OWNER 파일 내 Committer entry에 기록됩니다. 72 | 73 | 참고 : 기여한 코드가 수락되려면 지정된 Contributor의 Review와 더불어 한 명 이상의 Committer의 Approval이 필요합니다. 74 | 75 | ### 요구 사항 76 | Committer가 되기 위한 요구 사항은 다음과 같습니다. 77 | - 프로젝트의 기술적 목표와 방향에 대한 깊은 이해 78 | - 프로젝트의 기술 영역에 대한 깊은 이해 79 | - Contributor가 된 이후 3개월 이상 된 자 80 | - 최소 5개의 실질적인 PR에 대한 메인 Reviewer 81 | - 최소 30개 이상의 PR에 대한 Review 혹은 Merge 82 | - 자원하거나 혹은 프로젝트 내 다른 Committer에 의해 추천될 수 있음 83 | 84 | Committer가 되기 위한 Project별 세부 과정은 Project의 헌장에 정의되어야 합니다. 85 | 86 | 87 | ### 책임과 권한 88 | - 프로젝트에 대한 기술 설계 결정을 내리고 승인합니다. 89 | - 프로젝트의 기술적 방향과 우선순위를 설정합니다. 90 | - Milestone과 Release를 정의합니다. 91 | - 프로젝트 내 Contributor, Member의 멘토가 되어 가이드합니다. 92 | - 프로젝트의 지속적인 건전성을 보장합니다. 93 | - 안정적인 Release를 위한 적절한 테스트 coverage를 지정합니다. 94 | - 토론 및 의사결정이 건전한 프로세스에 의해 수행되도록 합니다. 95 | - 다른 프로젝트의 Committer와 협력하여 전체적으로 프로젝트의 전반적인 건전성과 성공을 유지합니다. 96 | - 대규모 코드 기여를 수락하기 위해서는 Committer의 Review와 Approval이 필요합니다. 97 | - 프로젝트 품질 관리를 책임지고 code reviews를 충실히 수행합니다. 98 | - 다른 기능과의 종속성, 양방향 호환성, API 및 flag 정의 등과 같은 전체적인 영향에 중점으로 검토합니다. 99 | - 코드 기여 수락 요청에 대해 Approve 합니다. 100 | -------------------------------------------------------------------------------- /governance/repository.md: -------------------------------------------------------------------------------- 1 | # Repository Guidelines 2 | 3 | > `need-to-improve` 4 | > 참고 : https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md 5 | 6 | 7 | 이 문서는 GitHub 저장소 생성 및 삭제 방법 그리고 OpenStack project 연결 구조에 관해 개략적으로 설명합니다. 8 | 9 | 본 페이지의 목적 및 이동/변경/생성 관련 규정 10 | 11 | 12 | - [Repository Guidelines](#repository-guidelines) 13 | - [Associated Repositories](#associated-repositories) 14 | - [Goals](#goals) 15 | - [Rules](#rules) 16 | - [SIG repositories](#sig-repositories) 17 | - [Goals](#goals-1) 18 | - [Rules for new repositories](#rules-for-new-repositories) 19 | - [Rules for donated repositories](#rules-for-donated-repositories) 20 | - [Core Repositories](#core-repositories) 21 | - [Goals](#goals-2) 22 | - [Rules](#rules-1) 23 | - [Removing Repositories](#removing-repositories) 24 | - [FAQ](#faq) 25 | 26 | ## Associated Repositories 27 | 28 | 설명 29 | 30 | 31 | ### Goals 32 | 33 | 설명 34 | 35 | 36 | ### Rules 37 | 38 | 설명 39 | 40 | 41 | ## SIG repositories 42 | 43 | 44 | 설명 45 | 46 | ### Goals 47 | 48 | 설명 49 | 50 | ### Rules for new repositories 51 | 52 | * 53 | * 54 | 55 | ### Rules for donated repositories 56 | 57 | 설명 58 | 59 | 60 | 조건 61 | 62 | * 63 | * 64 | 65 | 66 | ## Core Repositories 67 | 68 | 설명 69 | 70 | ### Goals 71 | 72 | 설명 73 | 74 | ### Rules 75 | 76 | * 77 | * 78 | 79 | ## Removing Repositories 80 | 설명 81 | 82 | 83 | ## FAQ 84 | * 85 | * 86 | 87 | 88 | **질문 1** 89 | 90 | 답변1 91 | 92 | 93 | **질문2** 94 | 95 | 답변2 96 | 97 | 98 | 99 | 100 | 맺는말 (if needed) 101 | 102 | 103 | 104 | -------------------------------------------------------------------------------- /governance/sig/README.md: -------------------------------------------------------------------------------- 1 | # HANU SIG (Special Interest Group) 2 | 3 | - [HANU SIG (Special Interest Group)](#hanu-sig-special-interest-group) 4 | - [HANU SIG](#hanu-sig) 5 | - [생성 절차](#생성-절차) 6 | - [가이드라인](#가이드라인) 7 | - [리더](#리더) 8 | 9 | HANU의 SIG는 프로젝트 외에 Cloud Native Infrastructure와 관련하여 특정 주제에 대한 테스트, 논의, 스터디 등을 수행하기 위한 그룹입니다. 10 | 11 | ## HANU SIG 12 | 13 | 현재 HANU에는 다음의 SIG가 활동하고 있습니다. 14 | 15 | - [ARM SIG](sig-arm/README.md) : ARM 서버에 Kubernetes 적용 등 Cloud Infra 구축에 필요한 서버들을 새롭게 정의하기 위한 SIG 입니다. 16 | 17 | ## 생성 절차 18 | 19 | HANU의 멤버라면 누구나 SIG 결성을 제안할 수 있으며, Technical Committee가 승인 여부를 결정합니다. SIG 생성 절차는 다음과 같습니다. 20 | 21 | 1. 신규 SIG 생성 제안자(리더)는 다음 두개 파일을 생성/변경합니다. 22 | 1. 헌장 파일 23 | - SIG에는 범위(주제, 코드 저장소, 디렉토리), 책임, 권한 영역, 리더쉽 역할 / 결정방법 및 충돌 해결 방법을 정의한 헌장이 있어야 합니다. 24 | - [SIG 헌장 template 파일](sig-charter-template.md)을 Copy하여 community/governance/sig/sig-YOURSIG/charter.md을 만듭니다. 25 | - 생성한 Your SIG용 헌장(charter.md)의 내용을 채웁니다. (예: [charter-sig-arm.md](sig-arm/charter-sig-arm.md)) 26 | 2. sigs.yaml 파일 27 | - sigs.yaml 파일에 신규 SIG의 내용을 적용하여 업데이트합니다. 28 | 2. 생성/변경한 두개의 파일로 Pull Request를 생성하여 Technical Comittee에 Review를 요청합니다. 29 | - 이때 Title은 "SIG Charter Proposal: YOURSIG"로 지정합니다. 일반적으로 일주일 이내에 피드백을 받을 수 있습니다. 30 | 3. 승인되면, Technical Comittee는 PR을 merge합니다. 31 | 4. SIG 생성이 완료되었습니다. 다음 가이드라인에 따라 SIG 활동을 수행합니다. 32 | 33 | ## 가이드라인 34 | SIG의 활동을 표준화하고, 투명성을 극대화하기 위하여 HANU의 SIG는 다음 사항을 따라야 합니다. 35 | - SIG에서의 소통은 투명하고 공개적이어야 합다. 다른 구성원이 회의, 토론, 결정에 대한 모든 기록을 열람할 수 있어야 합니다. 36 | - 커뮤니케이션은 개인 이메일 대신 공식 커뮤니케이션 [채널](../communication/README.md)을 사용합니다. 37 | - 3주마다 최소 30분 동안 정기적으로 미팅을 가집니다. 38 | - 회의는 녹화하고, Community YouTube playlist에 공개합니다. (예: https://www.youtube.com/channel/UCZ2bu0qutTOM0tHYa_jkIwg) 39 | - 최소 1년에 한번 메일링리스트를 통해 활동을 보고합니다. 40 | 41 | ## 리더 42 | SIG에는 적어도 1명 이상의 리더가 있어야 합니다. SIG 리더는 다른 SIG, 기술 위원회와 의사 소통 및 조정을 담당하며 다음의 역할을 수행합니다. 43 | - 헌장을 작성하거나 개선합니다. 44 | - 작업의 우선순위를 결정하는 방식을 정의합니다. 45 | - 현재 Release에 대한 SIG 개선 사항을 식별, 추적 및 유지합니다. 46 | - SIG 정보 (예: https://github.com/kubernetes/community/blob/master/sigs.yaml)를 항상 최신으로 유지합니다. 47 | - 미팅을 주관하고, 결과를 공개합니다. 48 | - SIG로의 기여 방법을 CONTRIBUTING.md에 작성하여 공개합니다. 49 | - 업데이트 사항을 커뮤니티 미팅 시 보고합니다. (예: https://github.com/kubernetes/community/blob/master/events/community-meeting.md) 50 | - 연간 활동 사항을 연간 리포트에 제출합니다. (예: https://github.com/kubernetes/community/blob/master/committee-steering/governance/annual-reports.md) 51 | 52 | -------------------------------------------------------------------------------- /governance/sig/sig-arm/CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # ARM SIG CONTRIBUTING 2 | 3 | > ARM SIG에 기여하고자 하는 참여자들을 위한 안내 4 | 5 | - [ARM SIG CONTRIBUTING](#arm-sig-contributing) -------------------------------------------------------------------------------- /governance/sig/sig-arm/README.md: -------------------------------------------------------------------------------- 1 | # ARM SIG 2 | 3 | - [ARM SIG](#arm-sig) 4 | - [ARM SIG 헌장](#arm-sig-헌장) 5 | - [Mission Statement](#mission-statement) 6 | - [Meetings](#meetings) 7 | - [Lead](#lead) 8 | - [Contact](#contact) 9 | - [Subprojects](#subprojects) 10 | 11 | 12 | ARM SIG는 ARM 서버에 Kubernetes 적용 등 Cloud Infra 구축에 필요한 서버들을 새롭게 정의하기 위한 SIG 입니다. 13 | 14 | ## ARM SIG 헌장 15 | 16 | [ARM SIG 헌장](./charter-sig-arm.md)은 ARM Special Interest Group의 범위와 거버넌스를 정의합니다. 17 | 18 | ## Mission Statement 19 | 20 | - ARM SIG의 목표는 Cloud Infra 구축에 필요한 서버들을 새롭게 정의하는 것입니다. 21 | - 컴퓨팅 연산 성능, 스토리지 수용 성능, 네트워크 가용 성능 등 인프라를 구성하는 주요 성능 요구사항을 수집 / 분석하여 표준화된 데이터를 정립하고, 22 | - 이를 토대로 단일하고 획일적인 형태의 서버에서 벗어나 엣지 컴퓨팅부터 클라우드에 이르기까지 각 인프라 구성과 목적에 최적화된 서버를 혁신적인 방법으로 구현하고 이를 공개하여 적용하는 데에 도움을 주고자 합니다. 23 | - 우리 그룹은 다양한 개발 요구 사항들과 목적에 맞는 동작 시나리오(Use Case)들을 새롭게 정의하고, 특정 업체, 특정 지역, 특정 환경에 종속적이지 않은 글로벌 표준화를 이끌어 내어 다양한 오픈소스 프로젝트와 커뮤니티 활동을 지원합니다. 24 | 25 | ## Meetings 26 | ... 27 | 28 | ## Lead 29 | ... 30 | 31 | ## Contact 32 | ... 33 | 34 | ## Subprojects 35 | ... 36 | -------------------------------------------------------------------------------- /governance/sig/sig-arm/charter-sig-arm.md: -------------------------------------------------------------------------------- 1 | # ARM Special Interest Group 헌장 2 | 3 | 이 헌장은 ARM SIG의 범위와 역할 및 책임을 정의한다. 4 | 5 | ## 범위 6 | 7 | > YOURSIG가 무엇을 하는지 2-3개의 문장으로 작성합니다. 8 | > HANU에 처음 참여한 구성원에게 YOURSIG의 일을 설명해 주세요. 9 | 10 | ### 포함 내용 11 | 12 | > 아래의 예와 같이 ARM SIG가 포함하는 세부 내용을 작성합니다. 13 | 14 | #### Code, Binaries and Services 15 | 16 | - list of what qualifies a piece of code, binary or service 17 | - as falling into the scope of this SIG 18 | - e.g. *clis for working with Kubernetes APIs*, 19 | - *CI for kubernetes repos*, etc 20 | - **This is NOT** a list of specific code locations, 21 | - or projects those go in [SIG Subprojects] 22 | 23 | #### Cross-cutting and Externally Facing Processes 24 | 25 | - list of the non-internal processes 26 | - that are owned by this SIG 27 | - e.g. qualifying and cutting a Kubernetes release, 28 | - organizing mentorship programs, etc 29 | 30 | ### 포함하지 않는 내용 31 | 32 | > 필요할 경우, ARM SIG에 포함되는 것으로 혼동할 수 있지만, 실제로는 해당하지 않는 사항들을 작성합니다. 33 | > 이는 참여자들에게 혼란을 줄여줄 수 있습니다. 34 | 35 | 36 | ## 역할 및 조직 관리 37 | 38 | ARM SIG는 [SIG-README](../README.md)에 정의된 가이드라인 및 리더의 역할을 준수한다. 39 | 40 | ### 추가적인 리더의 책임 41 | 42 | > 필요 시 작성합니다. 43 | 44 | - list of any additional responsibilities 45 | - of Leads 46 | 47 | ### [README](README.md)과 상이한 내용 48 | 49 | > 필요 시 작성합니다. 50 | 51 | - list of other ways this SIG's roles and governance differ from 52 | - the outline 53 | -------------------------------------------------------------------------------- /governance/sig/sig-charter-template.md: -------------------------------------------------------------------------------- 1 | # SIG YOURSIG 헌장 2 | 3 | 이 헌장은 [YOURSIG]의 범위와 역할 및 책임을 정의한다. 4 | 5 | ## 범위 6 | 7 | > YOURSIG가 무엇을 하는지 2-3개의 문장으로 작성합니다. 8 | > HANU에 처음 참여한 구성원에게 YOURSIG의 일을 설명해 주세요. 9 | 10 | ### 포함 내용 11 | 12 | > 아래의 예와 같이 [YOURSIG]가 포함하는 세부 내용을 작성합니다. 13 | 14 | #### Code, Binaries and Services 15 | 16 | - list of what qualifies a piece of code, binary or service 17 | - as falling into the scope of this SIG 18 | - e.g. *clis for working with Kubernetes APIs*, 19 | - *CI for kubernetes repos*, etc 20 | - **This is NOT** a list of specific code locations, 21 | - or projects those go in [SIG Subprojects] 22 | 23 | #### Cross-cutting and Externally Facing Processes 24 | 25 | - list of the non-internal processes 26 | - that are owned by this SIG 27 | - e.g. qualifying and cutting a Kubernetes release, 28 | - organizing mentorship programs, etc 29 | 30 | ### 포함하지 않는 내용 31 | 32 | > 필요할 경우, [YOURSIG]에 포함되는 것으로 혼동할 수 있지만, 실제로는 해당하지 않는 사항들을 작성합니다. 33 | > 이는 참여자들에게 혼란을 줄여줄 수 있습니다. 34 | 35 | 36 | ## 역할 및 조직 관리 37 | 38 | [YOURSIG]는 [README](README.md)에 정의된 가이드라인 및 리더의 역할을 준수한다. 39 | 40 | ### 추가적인 리더의 책임 41 | 42 | > 필요 시 작성합니다. 43 | 44 | - list of any additional responsibilities 45 | - of Leads 46 | 47 | ### [README](README.md)과 상이한 내용 48 | 49 | > 필요 시 작성합니다. 50 | 51 | - list of other ways this SIG's roles and governance differ from 52 | - the outline 53 | --------------------------------------------------------------------------------