[p5.js KO] steward_guidelines.md #6874
Conversation
|
🎉 Thanks for opening this pull request! Please check out our contributing guidelines if you haven't already. And be sure to add yourself to the list of contributors on the readme page! |
|
@yinhwa @designerSejinOH 이렇게 올리면 되는 건가요..? |
|
@Orwiss 네 성훈님 감사합니다 ㅎㅎㅎ 현우님 @ienground 님도 같이 여기서 작업하시면됩니다! |
|
@Orwiss 넵넵!! 👍👍🔥🔥 |
|
뒷부분 커밋을 진행하려고 하는데 Participants에 들어가 있지 않아서 그런지 파일 수정이 되지 않네요. |
|
Hi @Qianqianye @limzykenneth ! We're trying to have 2 contributors (@Orwiss & @ienground) share the same PR post (of the same MD file) for translation. This happened because we have 5 KO translators to work on 4 MD files; also because direct editing on a PR post was allowed to everyone until a few days ago. So then I thought that 2+ contributors can share their commits (working on different parts of the MD file) on the same PR. But now the direct editing seems only available for the author. Could you kindly check in with this? Thank you! |
|
@yinhwa @Orwiss @ienground For multiple people to work on the same PR, the way it works is basically have multiple people working on the same fork that the PR is filed with, ie. I see that this PR is on @Orwiss fork and for @ienground to also work on this PR, @ienground will need to be given write access to @Orwiss fork. As long as commits are pushed to the same fork, the PR will update regardless of who made the commit. You can see how to give repo access here: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-teams-and-people-with-access-to-your-repository |
|
Thank you @limzykenneth so much for the detailed explanation🙏🙏 We'll share & follow your guidelines! @Orwiss 성훈님은 위의 케네스님 댓글 가이드라인을 참고하셔서, 현재 PR fork 인 Orwiss:Orwiss-patch-1 에 대한 쓰기 권한을 @ienground 현우님께 공유해주시면 되겠습니다! 공유 이후에 현우님이 작업 시작이 가능합니다. |
connect:server 이후 부분 1차 번역 업로드합니다
|
@ienground 리포지토리 접근 초대드렸는데 확인 부탁드립니다!! |
|
@ienground 준비된 현우님😂😂 초스피드 커밋 감사합니다. 오늘밤 10시 이후 올려주신 내용 1차 리뷰와 WebGL 2차 리뷰, 총 2건 진행하겠습니다! @Orwiss 성훈님의 경우, 1차 번역 커밋 후 @designerSejinOH 세진님이 1차 리뷰를, 저는 2차 리뷰를 담당할 예정입니다! 모두 발빠른 처리 감사드립니다 🤩🤩 |
| nyc:report | ||
| ``` | ||
|
|
||
| 마지막으로, 모든 빌드와 테스트가 완료되면 이 단계에서는 `mochaChrome`이 전체 라이브러리 버전을 테스트하는 동안 테스트 커버리지 보고서를 수집하고, 테스트 범위 데이터를 콘솔에 출력합니다. p5.js의 테스트 커버리지는 주로 추가적인 데이터 포인트를 모니터링하고 확보하는 것으로, 테스트 커버리지 100%를 목표로 하지는 않습니다. |
There was a problem hiding this comment.
테스트 커버리지 : 테스트 적용 범위, 테스트 범위 등이 있으나 가장 많이 쓰이는 단어 같아서 적용합니다.
data points : 데이터 포인트로 일단 그대로 합니다..
|
|
||
| 이 작업은 위에 설명된 문서 및 라이브러리 빌드를 실행한 다음, [http://localhost:9001/docs/reference/](http://localhost:9001/docs/reference/)의 웹사이트에서 찾을 수 있는 참조 페이지와 유사한 기능을 가진 버전을 제공하는 웹 서버를 가동합니다. 그런 다음 소스 코드의 변경점을 모니터링하고 문서와 라이브러리를 다시 빌드합니다. | ||
|
|
||
| `grunt` `yui:dev`는 인라인 문서의 참조 작업을 할 때 유용한데, 빌드된 파일을 p5.js 저장소(repository)에서 로컬 p5.js-웹사이트 저장소로 이동할 필요도, 변경사항이 생길 때마다 웹사이트를 다시 빌드할 필요도 없기 때문입니다. 그저 브라우저에서 약간 단순화된 참조 버전으로 변경사항을 미리 보면 됩니다. 이렇게 하면 변경사항이 웹사이트에 더욱 올바르게 표시될 것이라는 확신을 가질 수도 있습니다. 이는 인라인 문서를 수정하는 경우에만 해당된다는 것을 알아두세요. 스타일 및 레이아웃 작업을 포함한 참조 페이지 자체에 대한 변경사항은 웹사이트 저장소에서 생기고 테스트해야 합니다. |
There was a problem hiding this comment.
스타일링 → 일단은 스타일 작업이라고 하겠습니다.
변경사항은 웹사이트 저장소에서 생기고? 만들고?
| grunt watch:quick | ||
| ``` | ||
|
|
||
| Watch 작업은 여러 파일의 변경사항을 감시하고, 관련 작업을 실행하여 변경된 파일에 따라 참조나 라이브러리를 빌드합니다. 이러한 작업은 범위의 차이를 제외하면 모두 동일한 작업을 수행합니다. |
There was a problem hiding this comment.
watch task : 이게 이곳에서 사용하는 고유 명사인지 번역하기가 조심스럽습니다. 일단은 원문 그대로 두겠습니다.
There was a problem hiding this comment.
Watch 는 (깃 콘솔창에 출력되는) 고유명사 맞습니다! 저도 우선은 이렇게 두는 것에 한표입니다 ㅎㅎ
워치(Watch)라고 표기하는 것도 가능할 것 같습니다.
| --- | ||
|
|
||
|
|
||
| ## 팁과 요령 |
There was a problem hiding this comment.
trick : 트릭이라 하기는 일단 좀 그래서 요령 정도로 번역했습니다.
여기서 이 we가 p5.js 개발자라고 생각해서 일단 ‘저희가’를 넣었습니다만, 문맥 확인이 조금 더 필요해 보입니다.
| 때때로 검토가 필요한 이슈와 PR의 수가 너무 많아질 수도 있습니다. 저희가 이를 더 쉽게 만드는 과정을 마련하려는 동안 이슈와 PR을 검토하는 데 도움이 될 만한 몇 가지 팁과 요령을 알려드립니다. | ||
|
|
||
|
|
||
| ### 회신(Reply) 양식 |
There was a problem hiding this comment.
template → 양식. 이것도 병기를 해야 할지..
There was a problem hiding this comment.
회신(Reply) 양식
->
회신 양식 (Reply templates)
원문 병기하시면 되겠습니다!
|
|
||
| ##### 종결: 스니펫 필요 | ||
|
|
||
| > 조직적인 목적으로 이 이슈를 종결합니다. 이 이슈를 설명하는 코드 스니펫을 제공할 수 있다면 다시 열어주세요. 감사합니다! |
There was a problem hiding this comment.
organizational purpose : 조직적인 목적? 의미를 잘 모르겠는데.. 번역이 어렵습니다.
There was a problem hiding this comment.
I'm closing this for organizational purposes. Please reopen if you can provide a code snippet that illustrates the issue. Thanks!
조직 운영 및 관리 차원에서 이 이슈를 종결합니다. 이 이슈를 설명하는 코드 스니펫을 제공할 수 있다면 다시 열어주세요. 감사합니다!
처럼 한번 의역해봤습니다...ㅎㅎ
|
|
||
| ##### 종결: 접근성 | ||
|
|
||
| > 저는 이 기능에 큰 관심이 없고, 어떻게 [접근성을 확장](access.md)하는지에 대한 명확한 설명이 없으므로 일단 이 이슈를 종결하겠습니다. 이슈 요청에 접근성 설명을 추가할 수 있게 되면 언제든지 다시 열어주세요. |
There was a problem hiding this comment.
access.md 원본이 따로 번역이 되어 있지 않아서 접근성 확장 정도로 번역합니다.
|
|
||
|  | ||
|
|
||
| 저장소 보기를 활성화하면, 새 이슈, 풀 요청, 사용자 핸들에 대한 언급 및 저장소에서 구독한 다른 활동과 같은 이벤트가 [알림 페이지](https://github.com/notifications)에 알림으로 전송되며, 이메일의 받은 편지함과 비슷하게 _읽음_, _삭제됨_ 으로 표시될 수 있습니다. |
There was a problem hiding this comment.
repo를 watching한다는 것은 보기도 맞지만, watch 버튼을 활성화한다는 의미가 더 크므로 그렇게 번역합니다.
사용자 핸들의 적절한 번역어가 있을까요?
There was a problem hiding this comment.
사용자 핸들은 우선은 러프하게는 사용자 도구...?도 가능할 것같지만 개인적으로는 핸들도 무방한것 같습니다 ㅎㅎ
|
|
||
| 저장소 보기를 활성화하면, 새 이슈, 풀 요청, 사용자 핸들에 대한 언급 및 저장소에서 구독한 다른 활동과 같은 이벤트가 [알림 페이지](https://github.com/notifications)에 알림으로 전송되며, 이메일의 받은 편지함과 비슷하게 _읽음_, _삭제됨_ 으로 표시될 수 있습니다. | ||
|
|
||
| 경우에 따라 보기가 활성화된 저장소에 대한 이메일을 GitHub로부터 수신할 수도 있으며, [알림 설정 페이지](https://github.com/settings/notifications)에서 (아예 구독 취소하는 것을 포함한) 사용자 설정을 할 수 있습니다. |
There was a problem hiding this comment.
알림 커스터마이즈 → 알림 사용자 설정 정도로 바꾸었습니다.
|
|
||
| 경우에 따라 보기가 활성화된 저장소에 대한 이메일을 GitHub로부터 수신할 수도 있으며, [알림 설정 페이지](https://github.com/settings/notifications)에서 (아예 구독 취소하는 것을 포함한) 사용자 설정을 할 수 있습니다. | ||
|
|
||
| 작업 방식에 맞게 이를 설정하고 싶다면, 검토할 관련 이슈 및 PR을 수동으로 찾아야 하는 귀찮음과, 깃허브의 끝없는 알림 속에서의 압도 사이에서 어떤 것을 선택할 것인지에 대한 기로에 서 있게 됩니다. 여기에는 균형 잡힌 선택이 필요한데, 만약 처음이라면 스튜어드는 **이슈**와 **풀 요청**에 대해 이 저장소에 **보기**를 활성화하고, "참여, @멘션 및 사용자 정의"에 대한 이메일만 수신하도록 설정하는 것을 추천합니다. |
There was a problem hiding this comment.
마지막 문단은 의역이 많습니다. 관련하여 한번 봐주시면 감사하겠습니다.
There was a problem hiding this comment.
@ienground 현우님의 초스피드+고퀄 번역😎에 따른 1차 리뷰 완료하였습니다 (1차 리뷰 소요시간: 8:20-10:13 약 2시간...)
1차 리뷰 코멘트를 참고하시어 추가 커밋해주시면 2차 리뷰는 세진님 @designerSejinOH 이 진행예정입니다 :) 거의 다왔네요!! 감사합니다!
| nyc:report | ||
| ``` | ||
|
|
||
| 마지막으로, 모든 빌드와 테스트가 완료되면 이 단계에서는 `mochaChrome`이 전체 라이브러리 버전을 테스트하는 동안 테스트 커버리지 보고서를 수집하고, 테스트 범위 데이터를 콘솔에 출력합니다. p5.js의 테스트 커버리지는 주로 추가적인 데이터 포인트를 모니터링하고 확보하는 것으로, 테스트 커버리지 100%를 목표로 하지는 않습니다. |
There was a problem hiding this comment.
mochaChrome이 전체 라이브러리 버전을 테스트하는 동안 테스트 커버리지 보고서를 수집하고, 테스트 범위 데이터를 콘솔에 출력합니다.
-> 문장 순서가 바뀌었지만 흐름상 현우님이 작성해주신 편이 나은것 같습니다!
|
|
||
| 마지막으로, 모든 빌드와 테스트가 완료되면 이 단계에서는 `mochaChrome`이 전체 라이브러리 버전을 테스트하는 동안 테스트 커버리지 보고서를 수집하고, 테스트 범위 데이터를 콘솔에 출력합니다. p5.js의 테스트 커버리지는 주로 추가적인 데이터 포인트를 모니터링하고 확보하는 것으로, 테스트 커버리지 100%를 목표로 하지는 않습니다. | ||
|
|
||
| 그리고 그것은 Gruntfile.js 구성의 기본 작업을 다루고 있습니다! |
There was a problem hiding this comment.
아래와같은 약간의 의역도 가능할 것 같습니다 :)
-> 그리고 여기까지가 Gruntfile.js 의 기본적인 실행 작업입니다.
또는
-> 여기까지(/이상) [우리는] Gruntfile.js 의 기본적인 실행 작업을 다루어 보았습니다.
configuration은 정말 단 한번도 제가 한글로 바꿔말해본적이 없는 단어네요 😅 우선은 '실행'이라고 임의 번역 해보았습니다.
There was a problem hiding this comment.
참고: 대괄호 [] 표기는 생략 또는 선택가능한 내용 표기해둔 것입니다!
There was a problem hiding this comment.
개발 쪽에서는 보통 환경 구성에서의 configuration을 의미하고 있습니다.
환경 구성(configuration) 으로 병기해보겠습니다!
| grunt yui:dev | ||
| ``` | ||
|
|
||
| 이 작업은 위에 설명된 문서 및 라이브러리 빌드를 실행한 다음, [http://localhost:9001/docs/reference/](http://localhost:9001/docs/reference/)의 웹사이트에서 찾을 수 있는 참조 페이지와 유사한 기능을 가진 버전을 제공하는 웹 서버를 가동합니다. 그런 다음 소스 코드의 변경점을 모니터링하고 문서와 라이브러리를 다시 빌드합니다. |
There was a problem hiding this comment.
아래와같은 문장 고려하실 수 있겠습니다!
~실행한 다음, http://localhost:9001/docs/reference/와 기능적으로 유사한 [버전의] 레퍼런스 페이지를 제공하는[/위한] 웹서버를 가동합니다.
또는, 이처럼 문장이 긴 경우에는 우리나라 문장 구조에 맞춰 끊어내셔도 무방합니다!
~실행한 다음, 웹서버를 가동합니다. 이 웹서버는 http://localhost:9001/docs/reference/와 기능적으로 유사한 [버전의] 레퍼런스 페이지를 제공합니다.
|
|
||
| 이 작업은 위에 설명된 문서 및 라이브러리 빌드를 실행한 다음, [http://localhost:9001/docs/reference/](http://localhost:9001/docs/reference/)의 웹사이트에서 찾을 수 있는 참조 페이지와 유사한 기능을 가진 버전을 제공하는 웹 서버를 가동합니다. 그런 다음 소스 코드의 변경점을 모니터링하고 문서와 라이브러리를 다시 빌드합니다. | ||
|
|
||
| `grunt` `yui:dev`는 인라인 문서의 참조 작업을 할 때 유용한데, 빌드된 파일을 p5.js 저장소(repository)에서 로컬 p5.js-웹사이트 저장소로 이동할 필요도, 변경사항이 생길 때마다 웹사이트를 다시 빌드할 필요도 없기 때문입니다. 그저 브라우저에서 약간 단순화된 참조 버전으로 변경사항을 미리 보면 됩니다. 이렇게 하면 변경사항이 웹사이트에 더욱 올바르게 표시될 것이라는 확신을 가질 수도 있습니다. 이는 인라인 문서를 수정하는 경우에만 해당된다는 것을 알아두세요. 스타일 및 레이아웃 작업을 포함한 참조 페이지 자체에 대한 변경사항은 웹사이트 저장소에서 생기고 테스트해야 합니다. |
There was a problem hiding this comment.
p5.js-웹사이트 -> p5.js 웹사이트
이유: 국문법 의거시 하이픈은 불필요
|
|
||
| 이 작업은 위에 설명된 문서 및 라이브러리 빌드를 실행한 다음, [http://localhost:9001/docs/reference/](http://localhost:9001/docs/reference/)의 웹사이트에서 찾을 수 있는 참조 페이지와 유사한 기능을 가진 버전을 제공하는 웹 서버를 가동합니다. 그런 다음 소스 코드의 변경점을 모니터링하고 문서와 라이브러리를 다시 빌드합니다. | ||
|
|
||
| `grunt` `yui:dev`는 인라인 문서의 참조 작업을 할 때 유용한데, 빌드된 파일을 p5.js 저장소(repository)에서 로컬 p5.js-웹사이트 저장소로 이동할 필요도, 변경사항이 생길 때마다 웹사이트를 다시 빌드할 필요도 없기 때문입니다. 그저 브라우저에서 약간 단순화된 참조 버전으로 변경사항을 미리 보면 됩니다. 이렇게 하면 변경사항이 웹사이트에 더욱 올바르게 표시될 것이라는 확신을 가질 수도 있습니다. 이는 인라인 문서를 수정하는 경우에만 해당된다는 것을 알아두세요. 스타일 및 레이아웃 작업을 포함한 참조 페이지 자체에 대한 변경사항은 웹사이트 저장소에서 생기고 테스트해야 합니다. |
There was a problem hiding this comment.
이렇게 하면 변경사항이 웹사이트에 더욱 올바르게 표시될 것이라는 확신을 가질 수도 있습니다.
->
이렇게 하면 웹사이트에 변경사항이 올바르게 표시되는지 여부를 확인할 수 있습니다.
위같은 방식으로 최대한 목적어절을 줄이는 것도 좋겠습니다 :)
|
|
||
| ### 깃허브 CLI | ||
|
|
||
| 테스트할 PR의 코드 버전을 로컬로 가져오는 데 필요한 복잡한 git 명령어를 사용하면 복잡한 PR을 검토하는 게 어려울 수 있습니다. 다행히도 [깃허브 CLI](https://cli.github.com/)가 이 과정에서 큰 도움을 줄 수 있겠군요. |
There was a problem hiding this comment.
테스트할 PR의 코드 버전을 로컬로 가져오는 데 필요한 복잡한 git 명령어를 사용하면 복잡한 PR을 검토하는 게 어려울 수 있습니다.
->
코드가 복잡한 PR의 경우, 여러분이 로컬에서 테스트한 코드 버전을 git 명령어로 가져오면 검토가 어려울 수 있습니다. 다행히도~
어떠실까요!
|
|
||
| ### 알림 관리 | ||
|
|
||
| 새로운 이슈나 PR에 대해 **이슈** 나 **풀 요청** 탭을 수동으로 감시하지 말고, 저장소 이름 맞은편 저장소 페이지 상단에 눈 아이콘이 있는 **보기(Watch)** 버튼을 클릭하여 저장소를 감시할 수 있습니다. |
There was a problem hiding this comment.
감시하지 말고, -> 확인하는 대신,
맞은편 -> 반대편 (이 조금더 이해가 빠르지않으려나 싶어서 남겨봅니다 ㅎㅎ)
감시할 수 있습니다. -> 확인할 수 있습니다.
- 감시 -> 확인을 추천드립니다! 아무래도 오픈 소스 커뮤니티들은 어떤 어떤 지배/위계문화 역사를 함의하는 단어에 민감한 편인것같아요 ㅎㅎ 그래서 예전에도 프로세싱 커뮤니티에서는 'master'가 주인/노예 관계를 암시한다는 이유로 master branch -> main branch 로 재명명한 바 있습니다. (깃허브 전역에도 퍼져서 지금은 아예 디폴트명이 된것 같구요!)
|
|
||
| 새로운 이슈나 PR에 대해 **이슈** 나 **풀 요청** 탭을 수동으로 감시하지 말고, 저장소 이름 맞은편 저장소 페이지 상단에 눈 아이콘이 있는 **보기(Watch)** 버튼을 클릭하여 저장소를 감시할 수 있습니다. | ||
|
|
||
|  |
There was a problem hiding this comment.
앗 이미지 alt text는 번역 범위에 해당하지 않습니다 ㅎㅎ
원문으로 변경 부탁드립니다!
|
|
||
|  | ||
|
|
||
| 저장소 보기를 활성화하면, 새 이슈, 풀 요청, 사용자 핸들에 대한 언급 및 저장소에서 구독한 다른 활동과 같은 이벤트가 [알림 페이지](https://github.com/notifications)에 알림으로 전송되며, 이메일의 받은 편지함과 비슷하게 _읽음_, _삭제됨_ 으로 표시될 수 있습니다. |
There was a problem hiding this comment.
사용자 핸들은 우선은 러프하게는 사용자 도구...?도 가능할 것같지만 개인적으로는 핸들도 무방한것 같습니다 ㅎㅎ
|
|
||
| 경우에 따라 보기가 활성화된 저장소에 대한 이메일을 GitHub로부터 수신할 수도 있으며, [알림 설정 페이지](https://github.com/settings/notifications)에서 (아예 구독 취소하는 것을 포함한) 사용자 설정을 할 수 있습니다. | ||
|
|
||
| 작업 방식에 맞게 이를 설정하고 싶다면, 검토할 관련 이슈 및 PR을 수동으로 찾아야 하는 귀찮음과, 깃허브의 끝없는 알림 속에서의 압도 사이에서 어떤 것을 선택할 것인지에 대한 기로에 서 있게 됩니다. 여기에는 균형 잡힌 선택이 필요한데, 만약 처음이라면 스튜어드는 **이슈**와 **풀 요청**에 대해 이 저장소에 **보기**를 활성화하고, "참여, @멘션 및 사용자 정의"에 대한 이메일만 수신하도록 설정하는 것을 추천합니다. |
There was a problem hiding this comment.
멋진 의역입니다 ㅎㅎㅎ
작업 방식에 맞게 이를 설정하고 싶다면, 검토할 관련 이슈 및 PR을 수동으로 찾아야 하는 귀찮음과, 깃허브의 끝없는 알림 속에서의 압도 사이에서 어떤 것을 선택할 것인지에 대한 기로에 서 있게 됩니다.
-> 알맞는 알림 방식을 선택하는 과정에서, 여러분은 이슈 및 PR 검토 필요 사안을 직접 찾아내야하는 번거로움과 깃허브의 끝없는 알림 압박 사이에 서 있게 됩니다.
처럼 문장을 조금만 간결하게 작성해주시면 더욱 좋을것 같습니다 :)!! 너무 고생많으셨습니다 감사합니다!!
First Update
|
@designerSejinOH @yinhwa 시간이 부족해서 전부 올리지 못했는데 오늘 오후에 다시 한번 나머지 부분 커밋하겠습니다! |
connect:server 뒷부분 1차 피드백 반영
|
connect:server 이후 부분 1차 피드백 반영하여 수정했습니다! |
Sunghun upload more
| 3. Feature enhancements must be approved by at least one steward or maintainer before work should begin toward a PR. The PR review process for feature enhancement is documented below. | ||
| 1. 새로운 기능 요청과 마찬가지로 기능 향상은 p5.js에 대한 접근성을 높이는 경우에만 허용되어야 합니다. [위 섹션](http://guidelines.md#feature-request)의 1번 항목을 참고해주세요. | ||
| 2. 기능 향상에 대한 포함? 기준은 기능 요청의 경우와 비슷하지만, 잠재적인 호환되지 않는 변경 사항(breaking changes)을 특히 주의해야 합니다. | ||
| - 기존 기능을 수정하는 경우, 모든 이전의 유효하고 문서화된 함수 시그니처가 같은 방식으로 동작해야 합니다. |
There was a problem hiding this comment.
all previous valid and documented function signatures
내용이 잘 이해가 되지 않아 보이는 대로 '모든 이전의 유효하고 문서화된 함수 시그니처' 정도로 적었지만..!
의견 주시면 감사하겠습니다!
There was a problem hiding this comment.
기존 함수를 수정하는 경우, 모든 이전의 유효하고 문서화된 함수 시그니처(function signature, 함수의 원형에 명시되는 매개변수 리스트)는 동일한 방식으로 작동해야 합니다.
-> 이렇게 변경하는 건 어떨까요?
There was a problem hiding this comment.
함수 시그니처에 대한 설명까지 적자는 의견일까요?
일단은 같이 표기하겠습니다!
| - If multiple changes are required, don’t add single-line comments many times. Instead, follow the procedure documented [here](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request) to make multiple-line comments and a single request for changes. | ||
| - If line comments are just for clarification or discussion, choose “Comment” instead of "Request changes":\ | ||
| - 여러 번 변경이 필요한 경우 한 줄 주석(single-line comments)을 여러 번 추가하지 마세요. 대신 문서화된 [이 곳](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)에 절차에 따라 여러 줄 주석(multiple-line comments)과 한 번의 요청으로 변경하세요. | ||
| - 행 주석(line comments)이 설명이나 토론을 위한 것이라면, “변경 요청(Request changes)” 대신 “답글(Comment)”을 선택해 주세요:\ |
There was a problem hiding this comment.
한 줄 주석, 여러 줄 주석 하다가 행 주석이라고 하려니 어색해서 의견 요청드립니다!
There was a problem hiding this comment.
"줄별 주석(line comments)"는 어떨까요?
There was a problem hiding this comment.
줄별 주석이라 표현한 사례는 못 찾았지만..😢
그래도 더 나은 표현이라 생각해 줄별 주석으로 작성했습니다!!
|
@Orwiss 성훈님 1차 작업 커밋 완료하신걸까요? 완료하신거라면 1차 리뷰 제가 바로 진행하겠습니다..! |
|
아직 빠진 부분이 조금 있는데 지금 수정할 수가 없어서 리뷰 후에 수정하면서 같이 작성해도 될까요? |
@ienground |
@Orwiss 아하 그러면 완료하시면 알려주세요! 리뷰 먼저 시작하면 혼동이 있을 것 같아서요! |
|
이 리포에 대한 인화님이 쓰신 커멘트에 대해서긴 한데, |
|
@designerSejinOH 최대한 빠르게 작성해보겠습니다..! |
Sunghun Commit 1
| 2. 버그를 복사할 수 있는 경우: | ||
| - 특정 버그를 고치는 최선의 방법을 찾기 위해 약간의 논의가 필요할 수 있습니다. 때로는 간단할 수도 있고 때로는 까다로울 수도 있습니다. 사례별로 이러한 결정을 내릴 때는 [p5.js 디자인 원칙](design_principles.md)를 참조하세요. | ||
| - 이슈 작성자가 수정에 기여할 의향이 있는 경우: | ||
| - 이슈 작성자가 코멘트를 남기 이슈에 할당하여 이슈 수정을 승인합니다. “담당자(Assignee)” 우측에 있는 톱니바퀴 버튼을 사용하세요. |
There was a problem hiding this comment.
48번째 줄 "Approve the issue for fixing by the issue author by leaving a comment and assigning them to the issue." 번역이 매끄럽지 않아 조언 주시면 감사하겠습니다!
There was a problem hiding this comment.
이슈 작성자가 문제를 수정할 수 있도록 코멘트를 남기고 그들에게 이슈를 할당하여 승인하세요. "담당자(Assignee)" 옆 오른쪽에 있는 톱니바퀴 버튼을 사용하세요.
-> 이렇게 고치는건 어떨까요?
|
@designerSejinOH 1차 커밋 완료하였습니다..! 리뷰 진행해주시면 감사하겠습니다!! |
지금 윤영님(PR 작성자)과 예원님 PR 같은 경우도 예원님에게 코멘트 Conversation Resolve 버튼이 안 보이더라구요... 저희가 남긴 코멘트가 PR 작성자에게 남긴 코멘트라고 인식이 되서 작성자만 Resolve가 가능한듯 합니다... 우선 본 PR 작성자인 성훈님께 해당 코멘트들을 최종 Approve 전에 resolve를 부탁드리는 방식으로 진행하겠습니다!! ㅜ |
깃허브 공식문서에서는 PR게시자 로컬 repo에대한 쓰기권한 있으면 resolve 가능한것으로 나오긴하는데 저는 어제 쓰기 권한자체가 좀 늦게 부여되더라구요 초대 수락해도... |
그리고 approve자체는 리뷰 코멘트 resolve 안해도 할 수 있는걸로 알고 있어서 공동기여자님들 resolve 버튼안뜬다면 클릭없이 그냥 진행할게요! @designerSejinOH @Orwiss @ienground @YewonCALLI @yunyoungJang |
|
다음 협업에는 이런 부분들을 반영해서 조율을 해야겠네요. ㅠㅠ 저는 모두 콜라보레이터로 add했는데 제가 더 진행해야하는 부분이 있을까요? |
윤영님 협업자 추가 잘 해주셨어요! 몇가지 기능에있어서 협업자들 권한이 로딩이 느린건지 파악이안되는 상태일뿐... ㅎㅎ 윤영님+예원님 이번주차 과제는 머징 요청들어갔습니다 :) 고생하셨습니다! |
There was a problem hiding this comment.
@Orwiss 성훈님! 번역 작업 고생 많으셨습니다!! 기술적인 이야기와 깃허브 사용법에 대한 내용이 많아 어려우셨을텐데도 잘 번역해주셔서 감사합니다!!! 성훈님 1차 리뷰는 완료되어, @yinhwa 인화님께서 2차 리뷰를 진행해주실 예정입니다 :)
(1차 리뷰 24.03.20 18:30-21:00, 1시간 30분 소요)
@ienground 현우님 부분도 2차 리뷰 완료하였습니다!! 현우님 부분은 2차 수정사항은 없을 것 같습니다..! 역시 잘 번역해주신 것 같습니다 :)
(1차 리뷰 24.03.20 21:00-21:40, 40분 소요)
| - 그렇지 않으면 버그 보고서가 위치할 곳에 대한 답변을 (직접 연결되는 링크와 함께) 남기고 문제를 닫습니다. | ||
| - 버그 보고를 검토하는 첫 번째 단계는 버그 복사를 위해 충분한 정보가 제공되는지 확인하고, 제공되는 경우에, 설명된 대로 버그 복제를 시도하는 것입니다. | ||
| 2. 버그를 복사할 수 있는 경우: | ||
| - 특정 버그를 고치는 최선의 방법을 찾기 위해 약간의 논의가 필요할 수 있습니다. 때로는 간단할 수도 있고 때로는 까다로울 수도 있습니다. 사례별로 이러한 결정을 내릴 때는 [p5.js 디자인 원칙](design_principles.md)를 참조하세요. |
There was a problem hiding this comment.
사례별로 이러한 결정을 내릴 때는 p5.js 디자인 원칙를 참조하세요.
->
이러한 결정을 사례별로 내릴 때는 p5.js 디자인 원칙을 참조해 주십시오.
| 2. 버그를 복사할 수 있는 경우: | ||
| - 특정 버그를 고치는 최선의 방법을 찾기 위해 약간의 논의가 필요할 수 있습니다. 때로는 간단할 수도 있고 때로는 까다로울 수도 있습니다. 사례별로 이러한 결정을 내릴 때는 [p5.js 디자인 원칙](design_principles.md)를 참조하세요. | ||
| - 이슈 작성자가 수정에 기여할 의향이 있는 경우: | ||
| - 이슈 작성자가 코멘트를 남기 이슈에 할당하여 이슈 수정을 승인합니다. “담당자(Assignee)” 우측에 있는 톱니바퀴 버튼을 사용하세요. |
There was a problem hiding this comment.
이슈 작성자가 문제를 수정할 수 있도록 코멘트를 남기고 그들에게 이슈를 할당하여 승인하세요. "담당자(Assignee)" 옆 오른쪽에 있는 톱니바퀴 버튼을 사용하세요.
-> 이렇게 고치는건 어떨까요?
There was a problem hiding this comment.
시간 관계상 2차 리뷰 (소요시간: 22:00-00:00, 2시간) 곧바로 진행하였습니다. 한 줄 한 줄 노고가 느껴지는 성훈님 @Orwiss 의 번역과 세진님 @designerSejinOH 리뷰에 감사드립니다 ㅎㅎ
성훈님께서는 1차+2차 리뷰 모두 반영하여 최종 커밋해주시면 되겠습니다. 이로 바로 승인 처리하겠습니다 :) 감사합니다!
| - `uglify`는 `browserify:min` 의 출력 파일을 가져와 최종적으로 p5.min.js로 최소화합니다 (이 단계의 구성은 메인 Gruntfile.js에 있습니다). | ||
| - 테스트 코드 커버리지(code coverage) 보고를 위해 추가된 코드를 제외하고 `browserify:test`는 전체 p5.js와 동일한 버전으로 빌드하고 있습니다 ([Istanbul](https://istanbul.js.org/)을 사용합니다). | ||
|
|
||
| 먼저, `fs.readFileSync()` node.js 전용 코드의 사용은 `brfs-babel`을 사용하여 파일의 실제 내용으로 대체됩니다. 이는 WebGL 코드에서 별도의 파일로 작성된 소스 코드로부터 셰이더(shader) 코드를 삽입(inline)하기 위해 사용됩니다. |
There was a problem hiding this comment.
먼저, node.js 전용 코드인 fs.readFileSync() 대신, brfs-babel을 통해 실제 파일 내용로 대체합니다. 이는 WebGL 코드에서 주로 활용됩니다. 별도의 파일로 작성된 소스 코드로부터 셰이더(shader) 코드를 삽입(inline)하는 식입니다.
~처럼 문장 구분해서 의역해도 좋을것 같습니다!
|
|
||
| 먼저, `fs.readFileSync()` node.js 전용 코드의 사용은 `brfs-babel`을 사용하여 파일의 실제 내용으로 대체됩니다. 이는 WebGL 코드에서 별도의 파일로 작성된 소스 코드로부터 셰이더(shader) 코드를 삽입(inline)하기 위해 사용됩니다. | ||
|
|
||
| 다음으로, node_modules의 모든 종속성(dependency)을 포함한 소스 코드가 Babel을 사용하여 package.json에서 정의된 Browserslist 요구 사항에 맞춰 트랜스파일(transpile)하고, ES6 import문(import statement)을 browserify가 이해하는 CommonJS require()로 변환합니다. 이를 통해 브라우저 호환성에 대한 걱정 없이 ES6 이상에서 사용할 수 있는 최신 구문(syntax)을 사용할 수 있게 됩니다. |
|
|
||
| 번들링(bundling) 후, 번들링된 코드가 파일에 기록되기 전까지 코드는 `pretty-fast`를 통해 전달됩니다. 최소화할 것이 아니라면, 최종 포맷이 좀 더 일관되도록 정리되어야 합니다 (원하는 경우 p5.js 소스 코드를 읽고 검사할 수 있을 것으로 예상됩니다). | ||
|
|
||
| 이 곳에 몇 가지 세부 단계가 나와 있습니다; 위에 링크된 browserify 빌드 정의 파일을 확인하여 모든 내용을 자세히 확인할 수 있습니다. |
Sunghun 2nd
|
@yinhwa @designerSejinOH 의견 주신 것들 반영해서 2차 커밋 완료했습니다!! |
minor grammar changes
|
@yinhwa 코멘트가 보이지 않아서 수정하지 못하고 놓친 것들이 몇 가지 있는데 혹시 어떻게 하면 될까요..! |
저는 지금 성훈님 추가 코멘트가 어디간건지 안보여서 답변을 못하고 있어요 ㅜㅜㅋㅋㅋㅋ 이메일로는 추가 댓글 남기신거 봤거든요! 우선은 1+2차 리뷰 코멘트 내용 거의 다 반영하신건 깃헙상 확인하였고, 추가 논의주신 건에 대해서는 성훈님이 제안주신 내용으로 반영후 직접 수정해서 승인하겠습니다! |
|
@yinhwa 넵 일단은..! 수습해주셔서 감사드리고... |
|
@Orwiss 아고 수습이아니라 협업입니다😂😂 댓글 안보이는건 깃헙 자체 버그인것같은데 원저작자인 성훈님의 동의없이는 제가 수정할수는없고 + 우선은 크리티컬한 이슈들은 아닌것같아 우선은 쓰루하겠습니다! 그리고 태평양시간대 기준으로는 20일 자정까지 아직 5시간은 족히 남았습니다...ㅎㅎㅎ 빠르게 해주셔서 감사드립니다!! |
There was a problem hiding this comment.
Hi @Qianqianye @limzykenneth we're ready to merge here too :) This is our final PR to be merged (with one more PR waiting in line) yay!
Thanks @Orwiss @ienground for your hard works on the detailed translation 😎😎 @designerSejinOH
|
Looks great, thanks @Orwiss @designerSejinOH @yinhwa 💗 |
|
I've put up a pull request to add @Orwiss! 🎉 |
Changes: Copy original steward_guidelines.md
PR Checklist
npm run lintpasses