├── README.md ├── LICENSE └── meetings └── 2023-06-14.md /README.md: -------------------------------------------------------------------------------- 1 | # ko-translation-team 2 | 3 | ## 목표 4 | 5 | 공통으로 사용할 수 있는 IT 용어집을 만드는 것 6 | 7 | ## 소개 8 | 9 | 기술 용어 번역에 대해 개인 혹은 집단마다 다른 용어를 사용하는 경우가 많습니다. 이러한 혼란을 해결하고 기술 용어의 표준화와 그 과정을 기록하기 위해, 기술 용어에 대한 번역 안내서를 만들고자 현재 저장소를 생성했습니다. 10 | 11 | [ko-translation-team Discussions](https://github.com/orgs/ko-translation-team/discussions)과 [디스코드 KO Translation Team](#)을 통해 기여에 참여하실 수 있습니다. 12 | 13 | ## 용어 추가 지침 14 | 15 | 아래 지침에 따라 용어를 추가할 수 있습니다. 16 | 17 | 1. [용어 안내서]()에 추가할 단어가 있는지 확인합니다. 18 | 2. [Github Discussions](https://github.com/orgs/ko-translation-team/discussions)에 논의중인 단어가 있는지 검색합니다. 19 | 3. [단어 토론](https://github.com/orgs/ko-translation-team/discussions/new?category=%EB%8B%A8%EC%96%B4-%ED%86%A0%EB%A1%A0)에서 새로운 글을 아래 형식으로 생성해주세요. 20 | 21 | ```markdown 22 | ## --- 23 | ``` 24 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2023 ko-translation-team 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /meetings/2023-06-14.md: -------------------------------------------------------------------------------- 1 | # 2023-06-14 회의록 2 | 3 | --- 4 | 5 | **참여자** 6 | 7 | | Name | Abbreviation | 8 | | ---------- | ------------ | 9 | | finalchild | FC | 10 | | hochan222 | HC | 11 | | narumir | NR | 12 | | RanolP | RP | 13 | | roooot | RT | 14 | | TeJAVA | TJ | 15 | 16 | ## 서론 17 | 18 | HC: ko-translation-team 프로젝트는 만들어진지 얼마되지 않아서, 아직 어떻게 운영할지에 대해 정해진 것이 없습니다. 이번 회의는 앞으로의 방향성과 중점을 두고 진행할 일들을 정하고, 역할을 나누어 **기술 용어 안내서를 만들기 위해 필요한 일들이 무엇이 있을지 논의**하여 지금보다 진척도가 있으면 좋을 듯하여 자리를 마련했습니다. 우선, 사람들에게 최소한의 기여를 이끌어 낼 수 있는 상태를 만들어야 한다고 생각합니다. 현재 [ko-translation-team/glossary](https://github.com/ko-translation-team/glossary) 저장소의 Readme.md를 보면 어떻게 기여를 할지 조차 막막합니다. 최소한의 기여를 하기 위해 어떤 일들을 하면 좋을지에 대한 안내는 있어야 한다고 생각합니다. 논의할 여지가 없는 "보편적인 기술 용어"를 먼저 정의하거나, 필수적으로 확인해야하는 사항(예: 국립국어원 사이트등)이나 단어 선정을 위해 조사해야할 사항에 대한 규칙등의 일들이 있습니다. 19 | 20 | ## 용어집을 만들기 위한 지침 21 | 22 | HC: 어떤 주제를 먼저 고려하면 좋을까요? 23 | 24 | NR: 용어집을 만들때도 특정 기술이나 it 용어중에서도 보면 보안쪽이나 개발쪽이나 하드웨어, 인베디드 쪽에서 같은 용어지만 다르게 불리는 경우가 있습니다. 따라서, 이런 부분들을 명시를 하는것이 좋지 않을까 생각하고 있습니다. 번역어를 단일로 정하는 것은 완전하게는 힘들거라 생각합니다. 팀이 만들어진 이유가 공통화된 표준 기술 용어를 만들기로 했는데, 분야마다 불릴 수 있는 것이 달라서 코멘트 정도는 달아둘 수 있으면 좋지 않을까 생각하고 있습니다. 25 | 26 | HC: 같은 용어지만 다르게 불리는 경우에 대해서는 단어를 섹션 별로 나누어서 정의를 하거나 메모를 남겨두면 좋을듯 합니다. MDN에도 동일한 사례가 있는데, module의 경우 용어에 대해 사용 사례에 따라 다른 카테고리로 분리해서 용어집을 만들고 있습니다. 27 | 28 | RP: 디스코드에서 모임이 시작되기전에 [저장소의 토론](https://github.com/orgs/ko-translation-team/discussions/1)에서 어느정도 의견을 받았었는데, 관련된 내용을 말씀드리겠습니다. 한가지 단어라도 품사가 다르게 활용되면 의미가 바뀌는 사례들이 있어서, 한단어랑 하나의 번역어가 완전하게 대응할 수 없으니까 영단어의 우리가 흔히 사전에서 본다면 1번, 2번, 3번 뜻이 있듯이 번역어를 정할 때도 1번 의미에 대해서는 어떤 번역어, 2번 의미에 대해서는 어떤 번역어 이런식으로 관리를 하면 괜찮지 않을까에 대한 의견이 있었습니다. 29 | 30 | FC: 이 프로젝트의 목표가 어느정도 통일된 용어집을 만들긴해야하는데, 현실적으로 지금 존재하고 있는 사례들만 수합하더라도 많은 충돌하는 용례들이 나올것입니다. 그 과정에서 저희가 무조건 단어 하나만을 등제하기는 힘들다고 생각합니다. 따라서, 등재하는 번역어들에 대해 여러가지의 카테고리 나눠서 어떤 것은 "권고"가 될 수도 있고, 어떤 것은 "사례"가 될 수 도 있는데, 이런 어느정도 수준까지 등재하고 얼마나 많이 등재할 수 있는지에 대해 지침이 필요하다고 생각합니다. 31 | 32 | RT: 우선, 단어집이 어떻게 활용되면 좋을지 그림들을 그려보면 좋겠습니다. 번역자들이 참조하고 각 커뮤니티에서 번역을 할 때 참조를 하게될텐데, 저희가 어떤 단일한 것을 제시한다고해서 강제가 될 수 없을 뿐더러 각 커뮤니티나 사용되는 곳에서 그런것들이 자연스럽게 받아들여지지 않을 것 같습니다. 따라서, 특정한 상황에서 "권고한다" 또는 음차, 권고 이런 아이디어들이 있었고 이러한 이유들로 우리가 권고한다의 통일안들을 만들어가되 선택지 다양하게 제시를 하는 방안들이 좋을것 같습니다. 33 | 34 | HC: 선택지를 여러가지 마련하는 것까지는 괜찮다고 생각합니다. 저장소 내에서 한가지 권고 사항을 정하는 것이 좋을지, 여러가지 선택지들이 있다고 남겨두는 것이 좋을지 고민이 됩니다. 앞서 RP님께서 말씀해주신 1번, 2번, 3번 뜻처럼 다른 카테고리에서 사용되는 단어들에 대해서는 여러가지 의미로 사용될 수 있지만, 한가지 카테고리 분야에서 명확히 한가지 쓰임새로 사용되는 용어에 대해서는 권고로 한 가지를 정하는것이 좋다고 생각합니다. 여러가지 커뮤니티에서 어색한 단어들이 선정이 될 수도 있지만, 일단 우선적으로 이 저장소가 만들어진 이유가 용어가 통일되지 않아서, 기준이 없어서 여러 커뮤니티마다 고민을 하고 정해서 사용되어 왔기 떄문에 이 저장소의 의의는 기준을 마련해는 것에 있다고 생각합니다. 35 | 36 | FC: 찬성 의견입니다. 37 | 38 | RP: 권고 / 널리 쓰임 정도만 처음엔 생각해도 될 것 같습니다. (예: 꾸러미 - 권고, 패키지 - 널리 쓰임) 39 | 40 | HC: 동의합니다. 말씀해주신 방향성이 좋다고 생각합니다. 다만, 한가지 권고사항을 선택하는 것이 매우 어려운 일이라고 생각합니다. 적절한 이유가 있어야하고 관련 근거가 명확해야지 정해진 후에 다른 기여자들이 PR로 기존에 정해진 것과 상반된 의견을 주셨을 때, 정리된 근거들로 반박할 수 있어야 합니다. 국립 국어원 사이트에서 이렇게 명시되어 있다와 같은 어떤 것들을 봐야한다는 그런 절차들을 먼저 지침으로 정하는 것이 좋아 보입니다. 국립 국어원외에 다른 어떤 것들을 지침으로 정하면 좋을까요? 혹은 이 의견에 대해서 어떻게 생각하시는지 궁금합니다. 41 | 42 | RP: 저는 [정보통신 용어사전 http://word.tta.or.kr/main.do](http://word.tta.or.kr/main.do)를 주로 사용했습니다. 43 | 44 | RT: 방향성 2가지 있어 보입니다. 먼저, (1)기준을 만들고 기준에 따라서 작업들을 해나가는 방법, (2)단어부터 먼저 모아서 어떤식으로 사용되고 있지 어떤 옵션들이 있지? 어떤것을 선택해야할지 고민하는 과정 중에서 기준을 만들어갈 수 있는 방법입니다. 어느 하나만을 선택하기 보다는 상황에 따라 두가지 방법 모두 고려하면 좋겠습니다. 기준들을 고민하는 동시에 단어들을 고려하다보면 딱 하나의 기준이 맞지 않을 수 있기도 하고 단어마다 기준이 다 다를수 있다고 생각합니다. 45 | 46 | FC: 프로젝트 자체를 github에 저장소를 파고 있는데, Git의 PR을 주방법으로 삼기에는 토론이 용이하지 않을 수 있다고 생각합니다. Git으로 편찬을 하는것까지는 좋은데 단어 하나하나 자료를 모으고 어떤 대안들이 있는지 찾아가는 단계에서 github가 나은 대안인가?에 대해 의문이 들었습니다. 여러가지 중에 하나를 결국 골라야합니다. 많은 대안들이 있고 사람들이 많은 용례를 찾으며 그 과정으로 투표나 프로젝트 리더식등을 통해 한쪽으로 권고안을 정해야합니다. PR 단위로 어떤 분이 PR 3개를 보고 이 대안이 좋습니다와 같은 방식보다는 단어 각각에 대해서 논거를 따져야하기 떄문에 그런 측면도 고민해보면 좋을것 같습니다. 47 | 48 | HC: 현재 저장소를 생성한 이유는 단어에 대해 의견이 올라온다면 누군가(팀이나 개인)는 그 의견을 결정해야하고, 의견을 결정하는 과정 중에서 가장 효율적인 방법이 Github이라고 생각해서 였습니다. Pull Request로 각각의 나뉘어진 대화창들이 만들어 질 수 있고, 하나의 PR이 얼마나 오래 지속될지는 모르지만 하나의 PR안에서 충분히 논의가 될 수 있다고 생각합니다. 만약, 말씀해주신 투표나 전체적인 사람들의 의견을 여쭙고자 하는 방향성이라면 PR만으로도 충분히 의사 결정에 도달 할 수 있다고 생각합니다. 예를들어 glossary 단어에 대해 PR이 생성이 되었다고 해서 반드시 10명의 의견이 수렴해야만 등재가 되기 보다는 어느 정도의 충분히 합리적인 근거가 있다면 우선 병합을 진행하고 이것에 대한 의사결정은 PR로 충분하다고 생각합니다. 또한, 병합한 다음에 피드백을 새로운 PR로 받는 것이 전체 완성도를 높이는 데에도 좋습니다. 또한, 기여자의 기여 가능한 시간이 항상 일정하지 않기 떄문에, 방치되지 않기 위해 시스템적으로 원활한 기여의 기록들을 남기기에도 Github가 적절하다고 생각합니다. Github가 적절하지 않다고 생각한다면 다른 대안이 있을지 궁금합니다. 트렐로나 다른 좋은 플랫폼이 있을까요? 49 | 50 | FC: 제가 생각한 가장 적합한 도구는 노션이라고 생각합니다. 노션을 통해 주로 번역 작업을 클라우드에서 해왔습니다. 문자열 집합이 정해져 있을때, 주기적으로 업데이트하는등의 작업에 유용합니다. 저희 같은 경우 추가적인 단어를 번역자들이 넣어야하니까 Crowdin 플랫폼은 UI가 부족하다고 느꼈고, 단어 하나에 대해서도 하나의 번역어만 정하는것이아닌 여러가지 근거와 의견들을 나열하는 문서를 만드는 작업이여서 기성 번역 플랫폼들이 좋지 못하다고 느꼈습니다. 다른 대안으로는 와같이 새로은 프런트엔드를 만들어 버리는 방법도 있는데, 프로젝트가 어느정도 커지면 고려해볼 만한 방법이지만 시작부터 플랫폼을 새로 하나 만들자 하면 저희의 모멘텀이 사라질 수 있어서 지금 당장은 배제한다면 남은건 Notion입니다. Notion은 데이터 베이스 기능이 있고 각각의 항목에 대해 문서 만드는 것이 가능하고, 각각의 항목에 대해서 정리된 뷰를 보거나 조금 더 확장해서 더 많은 제안과 근거들을 보거나 할 수 있습니다. 그러고 나서 프로젝트 관리자분들이 주기적으로 github 저장소에 정리하는게 가장 적합하다고 느낍니다. 51 | 52 | RP: PR이라는 것이 만든 사람이 있어서, 기본적으로는 만든 사람이 commit하는것에 따라서 본문 내용이 수정되는 방식인데요. 아무래도 발제한 사람이 부재한 상황에서는 커뮤니티에 기여한 사람들이 거기에 기여를 한다해도 본문에 반영되기까지 오래 걸릴 수 밖에 없고, 그렇다면 차라리 토론에 적합한 Github Discussion을 사용하고 그 이후에 Discussion을 통해 나온 결론을 PR로 만드는 방법이 더 합리인 흐름이라고 생각합니다. 53 | 54 | HC: 두 분께서 말씀해주신 내용을 정리드리면, 우선 공통적으로 PR 생성 이전에 단어에 대한 의견 정리 수단이 별도로 있고, 결론을 PR을 통해 반영하는 것이 좋다는 의견이 공통되어 보입니다. Github가 최종적인 수단이 되지만, 그전에 중간 수단이 있으면 좋을듯 합니다. 55 | 56 | RT: 단어별 토론은 issue로, 정책적인 논의는 Discussion으로 등과 같이 분리해도 좋을 것 같네요. 57 | 58 | RP: Discussion의 좋은 점이 제목에 원어를 적고 해당 Discussion에 대해 댓글은 번역어로 대댓글로 그 근거를 논하는 식으로 depth를 만들 수 있어요 59 | 60 | HC: RP님 의견에 동의합니다. 생각보다 Github Discussion의 시스템이 잘 되어 있습니다. 카테고리도 나눌 수 있고, 하나의 토론 내에서도 커멘트끼리도 분리 가능하다는 장점이 있습니다. 만약 Notion을 사용한다면, Github Discussion의 대체재로 역할을 할것같은데 초기 설정 비용이 클지 궁금합니다. 61 | 62 | FC: Github Discussion이 잘 되어있다고 한다면, 논의가 직접적으로 이루어지는 장소로는 Discord나 Discussion 어느 쪽이든 상관 없다고 생각합니다. Notion을 사용하는 이유는 그런 측면보다는 문서를 만들때 얼마나 잘 간결하게 볼 수 있게 혹은 얼마나 잘 기록과 근거들을 남길 수 있게 정리할지에 대한 측면이 크다고 생각합니다. 노션을 사용하지 않는다면 단순한 마크다운 형태로 생성해서 그것을 프로젝트의 끝으로 하기보다는 예쁘게 결과물이 나올 수 있는 형태가 되면 좋겠습니다. 63 | 64 | RP: machine-readable한 포맷도 출력으로 나오면 좋을 것 같기는 해요. (한국어 lint를 만든다든지) 65 | 66 | ## 용어집에 필수적으로 들어가면 좋을 요소 67 | 68 | HC: 용어집에 필수적으로 들어가면 좋을 요소와 정보 형태는 어떤 방향이 좋을까요? Webpack 한국 번역 공식 문서에서는 하나의 단어에 대한 번역어, 음차, 비고등을 JSON 포맷으로 만들어 두고 다른 사람들이 JSON을 가지고 웹사이트등을 만든다던지 하는 방식으로 활용할 수 있도록 하고 있습니다. 단순 마크다운 보다는 단어들이 어느정도 정해진다면 조금 더 보기 편한 Gitbook같은 형태나 Notion등 보기좋은 수단이 있으면 좋을듯 합니다. 형식에 대해서는 어떻게 보여질지에 대한 수단이라고 생각해서 단어가 다 정리되어 있다면 그것들은 굉장히 크지 않은 작업이라고 생각합니다. 보여지는 것들이 예쁘게 출력될 수 있도록 어떤 정보들이 필수적으로 들어가면 좋을지 먼저 정하면 좋을듯합니다. 어떤 정보들이 필수적으로 들어가고, 어떤 정보들이 부가적으로 들어가면 좋을지 의견 부탁드립니다. 이전 Github Discussion에서 논의된 내용 중에서는 alice님께서 원어, 음차, 번역어, 비고를 말씀해주셨습니다. 그 밑의 의견으로는 권고 사항 한가지는 정하면 좋을 듯해서 음차를 포함하더라도 부가적인 Section으로 넘어가는 것이 좋을것같다는 의견이 있었습니다. 69 | 70 | FC: 실용적으로 쓸 무언가가 나오려라면 권고안을 하나로 만드는 방법에 대해서 이야기를 했는데, alice님이 넣어주신 단순히 번역어와 음차만 했을 때, 저희의 권고안이 음차일 경우도 존재하기 떄문에 한국어로 모두 권고하기에 어려운점이 많을 것으로 생각합니다. 조금 더 시간이 들더라도 major한 단어들에 대해서는 음차, 일반적으로 사용되는 것보다도 조금 더 한국어스럽게 번역한 단어가 있는 컬럼이 있으면 좋을 것 같습니다. 마지막으로 "권고안" 컬럼까지 세가지 컬럼이 필수적으로 있어야한다고 생각합니다. 71 | 72 | HC: 말씀해주신 의견은 번역어, 음차, 비고에서 권고안이 하나 더 추가되면 좋겠다는 의견으로 이해해도 좋을까요? 73 | 74 | FC: 네 그렇게 있으면 조금 더 한국어에 충실한 번역어도 안심하고 제안 가능할듯합니다. 75 | 76 | RP: 기본적으로 원어는 하나입니다. (가이드면 가이드, 메모리면 메모리에 대해서 번역을 할테니까요) 원어가 정해지면 음차로 바꾸는것도 일대일 대응이 되니까 같이 두지만, 그 어휘가 하나의 의미로만 쓰이는건 아닙니다. 예를들어, 가이드는 안내서, 안내자로 사용될 수 있습니다. 맥락에 따라 조금씩 달라야하니까 일단 한국어로 대응하는 어휘 목록은 형태가 목록일 수 밖에 없고, 그런 상태에서 어떤 단어를 번역하려는 것이 대해 간략한 설명이 필요하니까 원래 의미를 적어둘 필요가 있습니다. 그 의미에 대해서 여러 개의 한국어 번역 제안이 있을 수 있는데 그 역시 목록으로 관리되어야 합니다. 번역어의 성질, "권고안으로서 채택이 되었다.", "다른 어휘랑 중복이 될 수 있어서 주의해야한다.", "음차에 대한 정도다등" 간략한 정보를 제공할 수 있어야하고, 실질적으로 사람이 읽을 정보로써 근거/ 장단점 들어가면 좋을듯합니다. 너프하게는 아래와 같은 구조를 제안합니다. 77 | 78 | ``` 79 | 표제어 { 80 | 원어, 81 | 음차, 82 | 대응 어휘 목록 [ 83 | 원 의미, 84 | 번역어 목록 { 85 | 번역된 표제어, 86 | 태그 [ 권고 | 중복 주의 | 음차 | ... ], 87 | 근거 / 장단점, 88 | } 89 | ] 90 | } 91 | ``` 92 | 93 | FC: 각 용어에 대해서 용어의 정의를 확실하게 알 수 있는 (아마도 영문인) 링크도 달아주면 좋을듯 합니다. 용어가 어떤 뜻인지 설명을 하는 프로젝트는 아니지만, 무엇에 대해 논의하고 있는지 확실히 정의해두는 편이 좋고, 그 과정에서 사람들이 생각하는 용어의 정의가 달랐다던지를 파악하기 위해서 중요하다고 생각합니다. 나중에 읽는 사람들 측면에서도 모르는 단어인데 했을 때 바로 링크를 찾아서 이 용어에 대해서 이 사람들이 번역을 하고 있었구나 알 수 있을 것 같습니다. RP님이 올려주신 내용중에 대응 어휘 목록의 원의미는 어떤것이 들어가는 항목일까요? 94 | 95 | RP: 링크를 달아서 단어의 의미가 딱 하나 존재하는 경우도 있을 수 있겠지만, React에는 이런의미, Vue에서는 이런 의미로 사용되는 등 같은 어휘이지만 다른 의미로 사용되는 경우가 있을 수 있습니다. 그런 경우 구분을 위해 간략하게 설명 적어두는 용도의 필드로 사용하면 좋지 않을까 생각을 했습니다. 파챠님이 제안하신것처럼 링크 정보랑 같이 보안해서 사용하면 좋을듯 합니다. 96 | 97 | FC: 영어로는 하나의 단어인데 너무 뜻이 차이나는 단어는 표제어를 분리하는 것이 일반적이다. 그런데 여기저기 불려서 사용되는 용어들이 있습니다. 예를들면, Property 이런 단어가 있다고 할때, 기본적인뜻은 공유하는데 Prop, attribute, field 등 많은 라이브러리에서 섞어서 사용합니다. 그랬을 때 현실적으로 분리해서 번역하기가 어려운 측면이 있고, 대응 어휘 목록등 그런경우에 어떻게 해야할지에 대해 일찍부터 정하면 좋겠습니다. 98 | 99 | RP: n : m 관계면 모델링하기가 좀 불편하긴 하네요 손으로 편집할 수 있으려나. 100 | 101 | HC: 개인적인 생각은 n : m의 경우가 그렇게 많지 않을것 같습니다. 만들어봐야 알듯한데 세부적으로 근거를 가지고 분류를 하다보면 왠만해서는 일대일 대응이 될듯해서 사례가 그렇게 많지 않을것 같습니다. 그런 사례가 있다고 해서 별도의 섹션을 만드는 방향을 가지면 괜찮을 듯 합니다. 102 | 103 | NR: 말씀하셨던것처럼 그런부분에서는 코멘트만 달아도 좋을 것 같습니다. 104 | 105 | ## 용어집 정보 형태 106 | 107 | HC: 앞서 이야기 나눈 필수 요소들이 정의가 되었을 때, 어딘가에 정리되어야 합니다. (1) json, 마크다운, notion와 같은 형식으로 정리하고, 해당 정보를 가지고 (2) 웹사이트 만든다던지, notion으로 예쁘게 잘 꾸며서 정리한다던지의 작업을 진행 할 수 있다고 생각합니다. 용어집에 필수적으로 들어가면 좋을 요소들을 정리하는 방식과 정리된 정보들을 활용하여 에쁘게 보여지는 방식으로 나눌 수 있을것 같습니다. 전자부터 의견 부탁드립니다. 개인적으로 가장 우선적으로 생각나는 것은 마크다운과, json 밖에 없어서 두 가지를 동시에 진행하는건 좋을것 같습니다. 108 | 109 | NR: 가장 좋은 건 json 형식이라고 생각하고 있습니다. 110 | 111 | FC: notion에서 json 형태로 자동 변환이 가능하다면 가장 편해 보이기는 해요. notion API로 데이터베이스 긁어오면 가능할것같은데 Notion을 깊게 사용하지 않아서 조사해보아야 합니다. 결국엔 JSON 비슷한 방식으로 진행할 것이고 machine-readable하게 하면 그게 그거라고 생각합니다. "프로젝트 참여하는 입장에서 제일 편한건뭘까?"에 대해 고민하는 것이 가장 중요하다고 생각합니다. Github 상에서만 사용한다면 JSON 생편집하는것도 좋을듯합니다. 112 | 113 | HC: Github에 굳이 한정할 필요는 없다고 생각합니다. 더 편하고 좋은 방법이 있으면 기반은 Github에서 하되 이용하는건 자유롭게 이용하는것이 좋을 듯 합니다. 114 | 115 | NR: 일단 프로그램에서 읽기가 쉽다는 2번으로 넘어가기가 가장 좋다고 생각합니다. 116 | 117 | RP: 이런것을 이전에 시도한 사람들이 없다보니까 저희가 도구를 직접 만들어야 쓰기 제일 편할것같은데 아무래도 바닥부터 만드는것은 힘들것같아서 Headless builder같은 라이브러리를 이용해서 최대한 공수를 적게 유지하면서 편집하면서 기본적인 기능은 다 가능하도록 관리할 수 있으면 좋을듯합니다. JSON을 single source of truth로 유지할 수 있으면 좋고 plasmic 같은 headless ui builder로 페이지를 뚝딱 만들면 좋긴 할 것 같은데 제가 안 써봐서 모르겠네요. 편집하는데 기본적인 기능은 다 되도록 관리하는게 좋아 보입니다. 118 | 119 | TJ: 이 작업을 완료하기까지 시간이 얼마나 걸릴까요..? 120 | 121 | HC: 개인적으로 전체 완성되는 시간은 굉장히 오래 걸리고, 어쩌면 끝나지 않을 것이라고 생각합니다. 그렇기 때문에 일부 반영되는 단어들만이라도 전체에 반영시켜 확장해 나가는 방향성이 좋다고 생각합니다. 122 | 123 | TJ: 추후에 데이터베이스화하는 등의 처리를 고려한다면 결과적으로는 json화하는 형태가 좋다고 생각합니다. 다만... RanolP님의 말씀대로 편집을 어떻게 해야하는지가 난제겠네요. 124 | 125 | RP: JSON을 single source of truth로 유지할 수 있으면 좋고 plasmic 같은 headless ui builder로 페이지를 뚝딱 만들면 좋긴 할 것 같은데 제가 안 써봐서 모르겠네요. 126 | https://github.com/plasmicapp/plasmic 편집하는데 기본적인 기능은 다되도록 관리하는게 좋아보임. 127 | 128 | NR: 사실 JSON 편집이 불편하다고 해도 한 용어에 대해서 하는 것이기 때문에 이게 기여에 문제가 될거 같지는 않다고 생각합니다. 대부분 개발자다보니까 웹페이지 플랫폼은 좋은데 기여나 이런것들을 위해 플랫폼을 만들다보면 프로젝트 하나만을 위해 있는 사람들이 아니여서 만들다가 포기하는 사람들이 많다고 생각합니다. 따라서, 이런 것들을 만드는것보다는 JSON을 사용하는 것이 좋다고 생각합니다. JSON 편집이 불편하더라도 한 용어에 대해서만 기여를 하는 것이기 떄문에 기여에 오랜시간이 걸리고 불편할 것이라고 생각하지 않습니다. RP님 말씀처럼 스키마 잘 정의 되어있으면 좋을것같습니다. 129 | 130 | RP: JSON 스키마 같은 거 잘 정의하면 자동완성까진 되니까 그럭저럭 쓸만할수도 있긴 하겠습니다. 131 | 132 | FC: 스키마 자체는 JSON 스키마는 무조건 만들게 될듯합니다. JSON을 기반으로 자동완성을 만들면 용어하나를 추가할 때마다 열심히 탭을 눌러서 하나의 탬플릿을 만든 뒤 용어의 이름을 적고등 이렇게 하게 될것같습니다. 아직 notion에 미련이 있습니다. 노션 안쓰면 작은 기여를 어떻게 모을것인가에 대해 생각을 해보아야 한다고 생각합니다. 결국 엄청나게 많은 의견들이 있을것이고 PR을 만드는 사람이 잘 스왑을 해도 여러 사람들이 동시다발적으로 기여하는것에 비해서는 포맷에 담기는 제안들의 수나 PR 넣은 이후에 이 단어 하나에대해 들어오는 기여를 하나의 PR로 처리하기에는 힘들다고 생각합니다. 모든 사람들이 repo를 가지고 PR을 생성할것 같지도 않습니다. 프로젝트에서 몇분은 쌓이는 이슈를 다 바라보고 있다가 한번에 합리적으로 보이는 것들을 모아서 PR을 만들고 머지하는 분들이 있으면 좋을것 같습니다. 그게 한가지고 중간에 말한것중에 이 프로젝트의 기여자가 아무리 많아도 모든 사람들이 JSON 포멧을 가지고 편집하는것을 기대할 수 없다는 것입니다. 133 | 134 | HC: 중간 정리를 하겠습니다. JSON 형식을 사용하는것은 모두 찬성할 정도로 굉장히 좋은 의견이라서 필수적으로 있으면 좋겠지만, JSON으로만 사용하는 것은 기여의 허들이나 시간적으로도 유지보수 혹은 PR을 관리하는데 큰 어려움이 있을것이다라는 의견이 있고, 그 의견들을 바탕으로 다양한 의견이 존재하고 있습니다. FC님께 궁금한 사항이 한가지 있습니다. 사실 Notion을 사용해도 좋다고 생각합니다. JSON 형태와 그것을 활용하여 간편하게 최종적으로 보여지는 산출물과는 별도로 중간 과정에서 간단하게 참고할 수 있을만한 형태는 반드시 있어야한다고 생각합니다. 그것이 마크다운일수도 있고, Notion이 될 수도 있다고 생각하는데 그런것들을 고려하지 않더라도 Notion이 필요한 이유가 하나의 단어가 재정되기까지 여러가지 의견을 취합하거나 그런 의견들을 관리하기 위함이라고도 말씀해주셔서 사실 Notion을 많이 사용해보지 않아서, 의견이 와닿지 않는 분들도 있으실듯합니다. 간략하게 화면 공유를 통해서 그런 기능들을 소개시켜주실 수 있는지 궁금합니다. 135 | 136 | FC: 생각하기에 가장 편집에 용의한 형태는 Notion table 입니다. Notion table 상에서 엔터만 치면 새로운 row가 만들어지는 방식이고, 그 문서에서 커멘트를 달 수 있다던가하는 WYSIWYG 에디터의 따뜻한 기능들이 기여 허들을 낮추는데 상당히 도움이 된다고 생각합니다. Notion API 중에는 Data를 가져오는 API가 있어서, Table 자체가 Database로 기능하는데 그런것 때문에 스크립트만 잘 작성하면 그런것들을 json화 하는것은 굉장히 쉽습니다. 지금 Notion으로 작성하면 툴이 완성이 되면 바로 JSON으로 변경 할 수 있다는 점이 JSON화 하는것을 고려한 이유입니다. 투표기능 추가 여부는 불확실합니다. 137 | 138 | HC: 궁금한 사항이 한가지 더 있습니다. 기여하는 사람들의 편의도 말씀해주셨는데, Notion의 기초 지식이 없는 상태에서 저장소를 발견하여 Notion에 기여를 주신다고 하실 때, 제가 알기로는 Notion 아이디를 만들고 그 아이디를 요청하여 권한을 얻는 과정이 필요할것 같은데 그런 허들에 대해서는 좋은 방법이 있을까요? 139 | 140 | RP: 저는 노션이 권한 관리 면에서 좀 우려가 되긴 합니다. 문서 편집 권한을 다 주면 남의 기록을 악의적으로든 실수로든 지우기가 너무 쉽지 않을지.. 141 | 142 | FC: 조사가 된 상태에서 말씀드린건 아니여서 최종적인 포맷은 JSON으로 확정이 된것같아서 JSON으로 편집하는 도구를 말씀해드린것이여서 위 사항들에 대해서는 해보고나서 Notion을 추천할 가치가 있겠다고 생각이되면 나중에 주제를 꺼내보도록 하겠습니다. 143 | 144 | NR: FC님이 말씀을 해주신 것들은 규모가 필요한 상태에 대한 이야기가 대부분일듯합니다. 어느정도 쌓여서 그정도의 도구들이 필요한 상태가 되려면 거의 그때쯤이면 프로젝트가 마무리 단계라고 생각합니다. 자동완성 기능이라던지 이런것들은 사실 Typescript의 type을 어느정도 보여줄 수 있는걸로 알고있는데, type을 만들어 놓고하면 개발자들만 사용하겠지만 크게 문제가 되지 않을것같다고 생각합니다. FC님이 말씀하신 내용들은 규모 커진 뒤 토론하는것이 더 적합할것같다고 생각하고 있습니다. 145 | 146 | FC: machine-readable한 포멧 유지해가며 사용한다면, 언제든지 툴은 옮길 수 있어서 동의합니다. 147 | 148 | RP: schema만 잘 관리된다면 에디터는 사실 큰 상관이 없을 것 같습니다. 노션이든 자체 제작이든 데이터만 잘 편집하면 된다고 생각합니다. 149 | 150 | ## 용어집 보여지는 방법 151 | 152 | HC: 기여자들마다 관심있는 분야가 다 다르니까 어느정도 방향성은 정해놓으면 잠재적인 기여를 이끌 수 있다고 생각합니다. 방향성을 정한다고 한다면 어떤 것들이 좋을까요? 현재 이야기 나온 것들은 Notion, 웹사이트, 마크다운이 있습니다. 세가지에서 벗어나는 범주가 있을까요? 153 | 154 | RP: 저는 노션이든 뭐든 웹사이트/앱 형태로 배포하는 것이 편의성 면에서 좋다고 생각합니당 노션으로 관리를 한다더라도 이런 라이브러리를 쓰면 웹사이트화시키기 용이하다고 생각합니다. 155 | 156 | FC: 보여주기는 어느쪽이든 저희가 편하기만 하면 될 것 같아요. 157 | 158 | RT: Asciidoc을 쓰면 output 포맷을 조금 더 유연하게 선택할 수도 있을 것 같네요. 159 | 160 | RP: 사실 뭐 검색이랑 열람만 잘 되면 뭐든 괜찮지 않을까요 ㅋㅋㅋ json을 가공해서 markdown/asciidoc을 생성해내는 건 쉬우니까 js 스크립트 대여섯개면 끝날 것 같아요 161 | 162 | HC: 처음 기여하시는 분들도 JSON 형태보다는 Markdown 형태로 간단하게라도 정리가 되어있다면 접근성이 좋아질듯한데 우선 markdown으로 정리하는건 어떤가요? 마크다운을 기본으로 하되 RP님께서 말씀해주신 스크립트를 개발하는 방향으로 진행하면 좋을 듯합니다. 163 | 164 | ## 디렉토리 구조 165 | 166 | HC: 지금까지 나온 이야기들은 아래 4가지로 정리 할 수 있습니다. 4가지 내에서도 좋고 그 외에 고민해볼만한 주제들이 있을까요? 167 | 168 | - 권고안, 지침 169 | - 용어 정의 형식 170 | - (1) 데이터 형식 171 | - (2) 보여주기 프로젝트 172 | 173 | RP: 디렉토리 구조는 어떻게 구성하나요? 174 | 175 | HC: 하나의 단어를 추가한다고 했을때, 용어집, 지침서(권고안), json, 회의록, README.md 파일들이 필요해보입니다. 어떤 파일이 필요한지 정하고 디렉토리 구성을 정하면 좋을듯합니다. 176 | 177 | RP: 별로 중요한 건 아닌데 단어가 너무 많아지면 폴더 하나에 전부 저장하다간 스크롤이 엄청 길어질 것 같아요 178 | 179 | HC: 그렇다면 우선은 하나의 glossary 파일을 만들기보다는 Javascript, CSS 수준에서 파일을 나누고 Javascript 내에서도 파일 크기가 커지면 분리하는 형태는 어떤가요? 처음부터 너무 세부적으로 나누기에는 과도하게 나누는것 같습니다. 180 | 181 | FC: 파일을 잘 분리할 수 있으면 좋겠는데, IT 용어들이 대부분 여러 분야에 걸쳐 쓰여서, 특정 분야 관리하는 관리자 분들이 있다면 어느선에서 어느선까지 분류하는것이 애매합니다. 182 | 183 | RP: 마크다운 파일을 관리하다보면 PR에서 merge conflict가 발생하기 쉬운 구조라고 생각합니다. 왜냐하면 테이블같은경우 마크다운으로 편집할 때, 테이블 셀을 수정하면 공백문자가 많이 들어가고 그것때문에 의도치 않게 수정을 하는 경험을 많이 했어서 이런것들을 예를들어 소스코드는 못생기게 보이지만 그대로 적용한다와 같은 형식 측면에서 머지 컨플릭트를 피하기 위한 최소한의 규칙이 있어야한다고 생각합니다. 184 | 185 | RT: 각 단어마다 파일을 둬도 문제 없지 않을까요? 186 | 187 | NR: 알파벳 기준으로 나누어도 좋을거 같습니다. 188 | 189 | FC: 저희가 특정 단어를 source of truth인 JSON 중 어디에 둘지는 힘든 문제라고 생각하고, 특정 주제의 단어들을 모아 보는 보여주기 페이지에서는 그냥 겹치는 용어들은 여러 군데서 보여 주는 것으로 해결될 것 같습니다. 머지 컨플릭트를 막으려고 한다면 단어마다 파일을 두는것도 나쁘지 않다고 생각합니다. 190 | 191 | HC: 머지 컨플릭트는 컨플릭트가 발생할 소지가 높다고 생각하기 때문에 해당 의견에 동의합니다. 다만, 이슈나 디스커션을 통해서 모두 논의 및 정의한 뒤 진짜 최종적인 것들만 PR을 만들면 괜찮지 않을까 생각이 됩니다. 아직 해당 단어에 대해서 이슈나 디스커션이 존재한다면 PR은 closed 하는 방법으로요. 192 | 193 | RP: 단어별로 나눈다면 여러 의미로 쓰이는 용어를 중복해서 기재할 때 고민을 해볼 필요가 있을 것 같아요 194 | `type - 타입 이론에서 형 195 | type - 타이핑하다 196 | type - 폰트 typeface` 197 | 198 | HC: RP님의 의견은 각각에 대해서 하나의 파일로 만들지, 여러 개의 파일로 만들지에 대한 의견으로 이해했습니다. 개인적인 생각은 하나의 파일로 다뤄졌으면 좋을것같고, 각 단어마다 파일을 나눈다고 했을 때, 전체적으로 단어를 검색할 일이 있을것 같은데 폴더 내에서 찾는 편이 접근성이 좋을지에 대해서도 생각하면 좋을듯 합니다. 199 | 200 | FC: 보여주기 페이지를 만들 때, 특정 주제의 단어들을 모아 보여준다고 했을 때 단어의 reference가 필요한데 그때 RD님께서 말씀하신 프로그래밍 언어에서 사용하는 type에 대한 규약을 정해서 하나의 identifier를 만들면 좋지 않을까 생각했습니다. 201 | `pl/type 202 | 그래도 겹치면 pl/type/1 203 | 정도의 identifier가 만들어질 것 같아요` 204 | 205 | RP: namespace를 만든다면, 단어를 어디로 분류해야함에 대한 논의가 진행되어야해서 에자일하지 못하게 느릿느릿하게 가야한다고 생각합니다. type 파일 하나에 모두 적기에도 분류가 제대로 안되어있다는 인상을 받을 수 있을것 같습니다. 뜻이 많은 단어는 편집하기에 버거워지지 않을까하는 걱정이 있습니다. 206 | 207 | FC: 분류 문제가 있다보니까 namespace를 만드는것은 쓸대 없는 고민을 야기할 가능성이 있다는 것에 대해 동의합니다. 그냥 json에 key를 만들어서 특정 태그 만들어서 보여주는 방식이면, 보여주기 페이지를 별도로 관리할 인력도 줄어서 좋다고 생각한다. 단어의 여러가지 뜻이 있을 때 파일을 나눌 것이냐 말 것이냐에 대해서는 안나누는것이 좋다고 생각한다. 안나눴을 때 스키마 안에 배열 구조를 넣기보다는 하나의 통째로된 스키마 여러 개써서 최상위 배열로 만들면 되지 않을까하는 생각이 있습니다. 이름, 음차 그 뒤에 배열이 붙는것도 나쁘지 않다고 생각합니다. 208 | 209 | ### 결론 210 | 211 | HC: 주제를 아래 5가지로 정리할 수 있을것 같습니다. 아래 주제들에 대해서 인원을 배정해서, 주제를 맡아서 진행하면 저장소 진전이 지금보다 빠르게 있을것 같아서 제안 드립니다. 예를들어, 한 주제에 대해서 이슈나 디스커션을 만들었을 때, 배정된 인원은 적어도 그 디스커션 안에서 다른 기여자들보다 활발하게 답글을 작성하는 느낌으로 자원하시는 분에 대해서 인원을 분배하고자 합니다. 212 | 213 | - 디렉토리 구조 214 | - 권고안, 지침 215 | - 용어 정의 형식 216 | - (1) 형식 217 | - (2) 보여주기 프로젝트 218 | 219 | RP: 디렉토리 구조는 느긋하게 논의해봐도 좋을 것 같고, 권고안 같은 것도 그냥 찾으면 다 나와서 느긋하게 할 수 있을 것 같은데, 형식의 합의가 가장 먼저 이루어지는 게 좋을 것 같아요. 형식 만들어지면 구체적 사례가 만들어지니 이후에 논의를 할 때 도움이 되지 않을까 하는 생각이 있다. 220 | 221 | HC: 형식은 용어 정의 형식을 말씀해주시는 것같 은데 이것에 대해 자원하실 분이 있을까요? 222 | 223 | FC: RP님께서 제안을 잘해주신것같아서 아마 Discussion을 추훙에 진행해도 크게 달라지진 않을듯합니다. 제가 자원해보겠습니다. 224 | 225 | HC: 첫 이슈나 디스커션 틀을 제가 작성한 뒤에 FC님께서 작성하시는 방향이 편하실지, 처음부터 FC님께서 작성해주시는 것이 편하실지 궁금합니다. 226 | 227 | FC: 틀은 먼저 쓰실 수 있으신 만큼 작성해주시면 기반으로 이슈 열어보도록 하겠습니다. 228 | 229 | HC: (중략) 추가적으로 자원하실 분들이 없으시다면 다른 기여자 분들의 의견을 받을 수 있게 이슈 생성해두겠습니다. 230 | 231 | RP: 제가 이런 프젝을 했어서 권고안이나 그런 거 베이스로 떼오기도 쓰기에 좋을 것 같아요 232 | 233 | HC: 만들게 된다면 Discussion이 좋을지 Issue가 좋을지 고민이 됩니다. 개인적으로는 Discussion이 좋아보입니다. 234 | 235 | HC: 마지막으로 회의를 마치기 전에 주실 의견 있으신 분이 있을까요? 없다면 회의를 마치겠습니다. 236 | 237 | RP: 그러고 보면 기여자 명시 면에서 고민이 좀 있습니다. 디스커션에서 단어를 논의한다면, 실제로 논의에 참여하는 사람과 정리하는 사람이 나뉘게될 가능성이 있다고 생각합니다. 보통 정리하는 사람만 PR을 만들게 되니까 기여자로 등록이 되게 되는데요. 이런 측면에서는 토론에 참여한 사람들도 기여자들 리스팅될 수 있는 장치가 있으면 좋을것 같습니다. 238 | 239 | HC: 동의합니다. 해당 의견에 대해서는 commit 메세지에 개행 두번 뒤에 아이디 이메일을 추가하는 방법으로 해결할 수 있어서 해당 방법으로 진행하면 좋을듯합니다. 240 | 241 | RP: 기여 가이드에 작성되면 좋을듯합니다. 242 | 243 | FC: 그렇게 하게되면 많은 commit에 unverified가 뜨게 될텐데 어쩔수 없다고 생각합니다. 그걸 위해서 다른 것을 하기보다는 떠도 감수하는게 맞지 않나싶습니다. 244 | 245 | HC: 아니면 따로 기여자들을 배열로 관리해도 좋을것같은데 그것도 유지보수 측면에서 안좋기 때문에 커밋메시지에 같이 추가하는 방식이 좋을것같습니다. 246 | --------------------------------------------------------------------------------