Update [p5.js KO] steward_guidelines.md

connect:server 이후 부분 1차 번역 업로드합니다

contributor_docs/ko/[p5.js KO] steward_guidelines.md

@@ -239,143 +239,144 @@ A few small detailed steps are left out here; you can check out the browserify b
 connect:server
 ```
 
-This step spins up a local server hosting the test files and built source code files so that automated tests can be run in Chrome.
+이 단계에서는 테스트 파일과 빌드된 소스 코드 파일을 호스팅하는 로컬 서버를 가동하여 Chrome에서 자동화된 테스트를 실행할 수 있도록 합니다.
 
 ```
 mochaChrome
 ```
 
-This step is defined in [./tasks/test/mocha-chrome.js](tasks/test/mocha-chrome.js). It uses Puppeteer to spin up a headless version of Chrome that can be remote controlled and runs the tests associated with the HTML files in the `./test` folder, which includes testing the unminified and minified version of the library against the unit test suites as well as testing all reference examples.
+이 단계는 [./tasks/test/mocha-chrome.js](tasks/test/mocha-chrome.js)에 정의되어 있습니다. Puppeteer를 사용해 원격 제어가 가능한 Chrome의 헤드리스 버전을 가동하고, `./test` 폴더에 있는 HTML 파일과 관련된 테스트를 실행합니다. 여기에는 라이브러리의 축소되지 않은 버전과 축소된 버전을 단위 테스트(unit test) 모음에 대해 테스트하는 것은 물론, 모든 참조 예제를 테스트하는 것도 포함되어 있습니다. 
 
 ```
 mochaTest
 ```
 
-This step differs from `mochaChrome` in that it is run in node.js instead of in Chrome and only tests a small subset of features in the library. Most features in p5.js will require a browser environment, so this set of tests should only be expanded if the new tests really don't need a browser environment.
+이 단계는 Chrome 대신 node.js에서 실행되고 라이브러리의 기능 중 일부만 테스트한다는 점에서 `mochaChrome`과 차이가 있습니다. 대부분의 p5.js 기능은 브라우저 환경이 필요하므로 이 테스트 세트는 새로운 테스트에 브라우저 환경이 필요하지 않을 때만 확장해야 합니다.
 
 ```
 nyc:report
 ```
 
-Finally, after all builds and tests are complete, this step will gather the test coverage report while `mochaChrome` was testing the full version of the library and print the test coverage data to the console. Test coverage for p5.js is mainly for monitoring and having some additional data points; having 100% test coverage is not a goal.
+마지막으로, 모든 빌드와 테스트가 완료되면 이 단계에서는 `mochaChrome`이 전체 라이브러리 버전을 테스트하는 동안 테스트 커버리지 보고서를 수집하고, 테스트 범위 데이터를 콘솔에 출력합니다. p5.js의 테스트 커버리지는 주로 추가적인 데이터 포인트를 모니터링하고 확보하는 것으로, 테스트 커버리지 100%를 목표로 하지는 않습니다.
 
-And that covers the default task in the Gruntfile.js configuration!
+그리고 그것은 Gruntfile.js 구성의 기본 작업을 다루고 있습니다!
 
 
-### Miscellaneous tasks
+### 기타 작업
 
-All of the steps can be run directly with `npx grunt [step]`. There are also a few tasks that are not covered above but could be useful in certain cases.
+모든 단계는 `npx grunt [step]`으로 직접 실행할 수 있습니다. 위에서 다루지는 않았지만 특정 상황에서 유용할 수 있는 몇 가지 작업도 있습니다.
 
 ```
 grunt yui:dev
 ```
 
-This task will run the documentation and library builds described above, followed by spinning up a web server that serves a functionally similar version of the reference page you will find on the website on [http://localhost:9001/docs/reference/](http://localhost:9001/docs/reference/). It will then monitor the source code for changes and rebuild the documentation and library.
+이 작업은 위에 설명된 문서 및 라이브러리 빌드를 실행한 다음, [http://localhost:9001/docs/reference/](http://localhost:9001/docs/reference/)의 웹사이트에서 찾을 수 있는 참조 페이지와 유사한 기능을 가진 버전을 제공하는 웹 서버를 가동합니다. 그런 다음 소스 코드의 변경점을 모니터링하고 문서와 라이브러리를 다시 빌드합니다.
+
+`grunt` `yui:dev`는 인라인 문서의 참조 작업을 할 때 유용한데, 빌드된 파일을 p5.js 저장소(repository)에서 로컬 p5.js-웹사이트 저장소로 이동할 필요도, 변경사항이 생길 때마다 웹사이트를 다시 빌드할 필요도 없기 때문입니다. 그저 브라우저에서 약간 단순화된 참조 버전으로 변경사항을 미리 보면 됩니다. 이렇게 하면 변경사항이 웹사이트에 더욱 올바르게 표시될 것이라는 확신을 가질 수도 있습니다. 이는 인라인 문서를 수정하는 경우에만 해당된다는 것을 알아두세요. 스타일 및 레이아웃 작업을 포함한 참조 페이지 자체에 대한 변경사항은 웹사이트 저장소에서 생기고 테스트해야 합니다.
 
-`grunt` `yui:dev` is useful when you are working on the reference in the inline documentation because you don't have to move built files from the p5.js repository to a local p5.js-website repository and rebuild the website each time you make a change, and you can just preview your changes with this slightly simplified version of the reference in your browser. This way, you can also be more confident that the changes you made are likely to show up correctly on the website. Note that this is only meant for modifications to the inline documentation; changes to the reference page itself, including styling and layout, should be made and tested on the website repository.
 
 ```
 grunt watch
 grunt watch:main
 grunt watch:quick
 ```
 
-The watch tasks will watch a series of files for changes and run associated tasks to build the reference or the library according to what files have changed. These tasks all do the same thing, with the only difference being the scope.
+Watch 작업은 여러 파일의 변경사항을 감시하고, 관련 작업을 실행하여 변경된 파일에 따라 참조나 라이브러리를 빌드합니다. 이러한 작업은 범위의 차이를 제외하면 모두 동일한 작업을 수행합니다. 
 
-The `watch` task will run all builds and tests similar to running the full default task on detecting changes in the source code.
+`watch` 작업은 소스 코드의 변경사항을 감지할 때 전체 기본 작업을 실행하는 것과 비슷한 모든 빌드와 테스트를 실행합니다. 
 
-The `watch:main` task will run the library build and tests but not rebuild the reference on detecting changes in the source code.
+`watch:main` 작업은 라이브러리 빌드와 테스트를 실행하지만, 소스 코드의 변경사항을 감지해도 참조를 다시 빌드하지는 않습니다.
 
-The `watch:quick` task will run the library build only on detecting changes in the source code.
+`watch:quick` 작업은 소스 코드의 변경사항이 감지된 경우에만 라이브러리 빌드를 실행합니다.
 
-Depending on what you are working on, choosing the most minimal watch task here can save you from having to manually run a rebuild whenever you want to make some changes.
+작업 중인 내용에 따라 가장 적은 감시 작업이 일어나는 것을 선택한다면 변경사항을 만들고 싶을 때마다 수동으로 다시 빌드를 하지 않아도 됩니다.
 
 ---
 
 
-## Release process
+## 배포 과정
 
-Please see [release\_process.md](release_process.md).
+[release\_process.md](release_process.md)를 확인하세요.
 
 ---
 
 
-## Tips & tricks
+## 팁과 요령
 
-Sometimes, the number of issues and PR that require review can get a bit overwhelming.  While we try to put in place processes that make things easier, there are some tips and tricks that you can utilize to help with reviewing issues and PRs.
+때때로 검토가 필요한 이슈와 PR의 수가 너무 많아질 수도 있습니다. 저희가 이를 더 쉽게 만드는 과정을 마련하려는 동안 이슈와 PR을 검토하는 데 도움이 될 만한 몇 가지 팁과 요령을 알려드립니다.
 
 
-### Reply templates
+### 회신(Reply) 양식
 
-A handy GitHub feature that you can use is the [Saved Replies](https://docs.github.com/en/get-started/writing-on-github/working-with-saved-replies/about-saved-replies) feature, which is available to use when authoring a reply to issues or pull requests. Some of the workflow described above may require responding to issues or PRs with identical or very similar replies (redirecting questions to the forum, accepting an issue for fixing, etc.), and using Saved Replies can just ever so slightly make this more efficient.
+사용할 수 있는 편리한 깃허브(GitHub) 기능은 이슈 또는 풀 요청(pull request)에 대한 회신을 작성할 떄 사용할 수 있는 [저장된 회신](https://docs.github.com/en/get-started/writing-on-github/working-with-saved-replies/about-saved-replies) 기능입니다. 위에 설명된 작업 흐름(workflow) 중 일부는 동일하거나 매우 유사한 답변(포럼으로 질문을 리디렉션하거나, 수정을 위한 이슈 수락 등)으로 이슈 또는 PR에 응답해야 할 수도 있는데, **저장된 회신**을 사용하면 이 작업의 효율이 조금 더 올라갈 수 있습니다.
 
-Below are some of the Saved Replies that are being used by p5.js maintainers. You can use them yourself or create your own!
+다음은 p5.js 메인테이너가 사용하는 **저장된 회신**의 일부입니다. 이를 사용하거나 직접 만들어 보세요!
 
 
-##### Closing: Can’t Reproduce
+##### 종결: 재현할 수 없음
 
-> We're not able to reproduce this, but please feel free to reopen if you can provide a code sample that demonstrates the issue. Thanks!
+> 이것을 재현할 수는 없지만, 이 이슈를 보여줄 수 있는 샘플 코드를 제공할 수 있다면 다시 열어주세요. 감사합니다!
 
 
-##### Closing: Need Snippet
+##### 종결: 스니펫 필요
 
-> I'm closing this for organizational purposes. Please reopen if you can provide a code snippet that illustrates the issue. Thanks!
+> 조직적인 목적으로 이 이슈를 종결합니다. 이 이슈를 설명하는 코드 스니펫을 제공할 수 있다면 다시 열어주세요. 감사합니다!
 
 
-##### Closing: Use the Forum
+##### 종결: 포럼 사용
 
-> The GitHub issues here are a good place for bugs and issues with the p5.js library itself. For questions about writing your own code, tests, or following tutorials, the [forum](https://discourse.processing.org/) is the best place to post. Thanks!
+> 이 깃허브 이슈는 p5.js 라이브러리 자체의 버그나 이슈를 올리기에 좋은 곳입니다. 여러분의 코드나 테스트, 또는 튜토리얼을 따라하는 것에 대한 질문을 하고 싶다면 [포럼](https://discourse.processing.org/)만한 곳이 없을 거에요. 감사합니다!
 
 
-##### Closing: GSOC
+##### 종결: GSOC
 
-> Thanks! The best place to discuss GSOC proposals is on our [forum](https://discourse.processing.org/c/summer-of-code).
+> 감사합니다! GSOC 제안을 논의하고 싶다면 우리의 [포럼](https://discourse.processing.org/c/summer-of-code)만한 곳이 없답니다.
 
 
-##### Closing: Access
+##### 종결: 접근성
 
-> I'm not seeing a lot of interest in this feature, and we don't have a clear explanation of how it [expands access](access.md), so I will close this for now. If an access statement can be added to the issue request, please feel welcome to reopen.
+> 저는 이 기능에 큰 관심이 없고, 어떻게 [접근성을 확장](access.md)하는지에 대한 명확한 설명이 없으므로 일단 이 이슈를 종결하겠습니다. 이슈 요청에 접근성 설명을 추가할 수 있게 되면 언제든지 다시 열어주세요.
 
-> We do not see a further explanation of how this issue [expands access](access.md), so I will close this issue for now. If a more detailed access statement can be added to the feature request, please feel welcome to reopen it. Thank you!
+> 이 이슈로 인해 어떻게 [접근성이 확장](access.md)되는지에 대한 추가 설명이 없으므로 일단 이 이슈를 종결하겠습니다. 기능 요청에 더 자세한 접근성 설명을 추가할 수 있게 되면 언제든지 다시 열어주세요. 감사합니다!
 
 
-##### Closing: Addon
+##### 종결: 애드온
 
-> I think this function is beyond the scope of the p5.js API (we try to keep it as minimal as possible), but it could be a great starting point for an addon library. See the docs here for how to create an addon: [https://github.com/processing/p5.js/blob/main/contributor\_docs/creating\_libraries.md](creating_libraries.md)
+> 저는 이 기능이 p5.js API의 범위를 벗어나는 것이라고 생각하지만 (최소한의 크기를 유지하고 싶어요), 애드온 라이브러리를 만드는 좋은 시작점이 될 것 같습니다. 애드온을 생성하는 방법을 알고 싶다면 이 문서를 확인해 보세요. [https://github.com/processing/p5.js/blob/main/contributor\_docs/creating\_libraries.md](creating_libraries.md)
 
 
-##### Closing PR: Need Issue First
+##### PR 종결: 이슈가 먼저 필요함
 
-> Thank you. As a reminder, issues need to be opened before pull requests are opened and tagged with the issue. This is necessary for tracking development and keeping discussion clear. Thanks!
+> 감사합니다. 참고로, 풀 요청(pull request)을 게시하고 이슈에 태그를 지정하기 전에 먼저 이슈를 게시해야 합니다. 이는 개발을 추적하고 토론을 명확하게 유지하는 데 필요해요. 감사합니다!
 
 
-##### Approve issue for fixing
+##### 이슈 해결 승인
 
-> You can go ahead with a fix. Thanks.
+> 계속 해결해도 됩니다. 감사합니다!
 
 
-##### Merged PR
+##### PR 병합
 
-> Looks good. Thanks!
+> 괜찮아 보이는데요? 감사합니다!
 
 
-### GitHub CLI
+### 깃허브 CLI
 
-Reviewing a complex PR can be difficult with complex git commands required to get the PR's version of code locally for you to test. Fortunately, the [GitHub CLI](https://cli.github.com/) tool can help greatly with this process and more.
+테스트할 PR의 코드 버전을 로컬로 가져오는 데 필요한 복잡한 git 명령어를 사용하면 복잡한 PR을 검토하는 게 어려울 수 있습니다. 다행히도 [깃허브 CLI](https://cli.github.com/)가 이 과정에서 큰 도움을 줄 수 있겠군요.
 
-After installing the CLI and logging in, reviewing a PR locally can be done by running the command `gh pr checkout [pull_request_id]`, and the process of fetching a remote fork, creating a branch, and checking out the branch are all done automatically for you. Going back to the main branch will be the same as switching a branch by running `git checkout main`. You can even leave a comment in the PR from the CLI without needing to visit the webpage at all!
+CLI를 설치하고 로그인하고 `gh pr checkout [pull_request_id]` 명령어를 실행하면 로컬에서 PR 검토가 가능하며, 원격 포크 가져오기, 브랜치 생성, 브랜치 체크아웃 과정이 모두 자동으로 수행됩니다. main 브랜치로 돌아가는 것은 `git checkout main`으로 브랜치를 전환하는 것과 같습니다. 심지어 웹사이트를 방문하지 않고도 CLI에서 PR에 댓글을 남길 수도 있습니다!
 
-There are many other commands available in the GitHub CLI as well that you may or may not find useful, but it is a good tool to have around in any case.
+깃허브 CLI에는 유용할 수도, 그렇지 않을 수도 있는 수많은 명령어가 있지만, 여전히 사용하기에 좋은 도구입니다.
 
 
-### Managing notifications
+### 알림 관리
 
-Instead of manually monitoring the "Issues" or "Pull Requests" tabs of the repo for new issues or PRs, you can "watch" the repo by clicking on the "Watch" button with an eye icon on the top of the repo page opposite the repo name.
+새로운 이슈나 PR에 대해 **이슈** 나 **풀 요청** 탭을 수동으로 감시하지 말고, 저장소 이름 맞은편 저장소 페이지 상단에 눈 아이콘이 있는 **보기(Watch)** 버튼을 클릭하여 저장소를 감시할 수 있습니다.
 
-![Cropped screenshot of the top right corner of a GitHub repository page showing a series of buttons in the center from left to right: Sponsor, Watch, Fork, Starred.](images/github-repo-metrics.png)
+![왼쪽에서 오른쪽으로 중앙에 있는 Sponsor, Watch, Fork, Starring 등의 버튼을 포함한 깃허브(GitHub) 저장소 페이지의 오른쪽 상단을 잘라낸 스크린샷](images/github-repo-metrics.png)
 
-By watching a repo, events such as new issues, new pull requests, mentions of your user handle, and other activities you subscribed to on the repo will be sent as notifications to your [notification page](https://github.com/notifications), where they can be marked as read or dismissed much like an email inbox.
+저장소 보기를 활성화하면, 새 이슈, 풀 요청, 사용자 핸들에 대한 언급 및 저장소에서 구독한 다른 활동과 같은 이벤트가 [알림 페이지](https://github.com/notifications)에 알림으로 전송되며, 이메일의 받은 편지함과 비슷하게 _읽음_, _삭제됨_ 으로 표시될 수 있습니다.
 
-In some cases, you may receive emails from GitHub about events in the repo you are watching as well, and you can customize these (including unsubscribing from them completely) from your [notifications settings page](https://github.com/settings/notifications).
+경우에 따라 보기가 활성화된 저장소에 대한 이메일을 GitHub로부터 수신할 수도 있으며, [알림 설정 페이지](https://github.com/settings/notifications)에서 (아예 구독 취소하는 것을 포함한) 사용자 설정을 할 수 있습니다.
 
-Setting these up to fit the way you work can be the difference between having to find relevant issues/PRs to review manually and being overwhelmed by endless notifications from GitHub. A good balance is required here. As a starting suggestion, stewards should watch this repo for "Issues" and "Pull Requests" and set it to only receive emails on "Participating, @mentions and custom."
+작업 방식에 맞게 이를 설정하고 싶다면, 검토할 관련 이슈 및 PR을 수동으로 찾아야 하는 귀찮음과, 깃허브의 끝없는 알림 속에서의 압도 사이에서 어떤 것을 선택할 것인지에 대한 기로에 서 있게 됩니다. 여기에는 균형 잡힌 선택이 필요한데, 만약 처음이라면 스튜어드는 **이슈**와 **풀 요청**에 대해 이 저장소에 **보기**를 활성화하고, "참여, @멘션 및 사용자 정의"에 대한 이메일만 수신하도록 설정하는 것을 추천합니다.